RFC 5185, "OSPF Multi-Area Adjacency", May 2008Source of RFC: ospf (rtg)
Errata ID: 3595
Publication Format(s) : TEXT
Reported By: Marek Karasek
Date Reported: 2013-04-17
Rejected by: Stewart Bryant
Date Rejected: 2013-05-06
Section 4 says:
A link-LSA SHOULD NOT be advertised for a multi-area adjacency. The neighbor's IPv6 link local address can be learned in other ways, e.g., it can be extracted from the IPv6 header of Hello packets received over the multi-area adjacency. The neighbor IPv6 link local address is required for the OSPFv3 route next-hop calculation on multi-access networks (refer to Section 22.214.171.124 of [OSPFV3]).
It should say:
OSPFv3 supports two Address Families (AF), AF IPv6 and AF IPv4, using separate instances [RFC 5338]. The route calculation differs for the IPv4 and IPv6 address families with respect to the next-hop determination. OSPFv3 instances supporting an IPv6 AF SHOULD learn the IPv6 next-hop address from the IPv6 Header source address and SHOULD NOT advertise a Link-LSA for a multi-area adjacency. However, for OSPFv3 instances supporting an IPv4 AF, the next-hop address cannot be learned from the OSPFv3 hellos and require advertisement of the Link-LSA. Hence, OSPFv3 instances supporting an IPv4 AF SHOULD advertise a Link-LSA for the a multi-area adjacency (refer to section 2.5 of [RFC 5838]). If the Link-LSA is not advertised, the OSPFv3 instance MAY learn the IPv4 next-hop address from the Link-LSA advertised on the primary adjacency.
RFC5185 describes next-hop calculation which is not applicable to OSPFv3 process supporting AF IPv4 as defined in RFC5838. Errata defines how RFC5838 OSPFv3 process supporting AF IPv4 calculates next-hop address on multi-area interface.
This is a technical change and is thus cannot be addressed through the errata process. The correct process for addressing this concern is by writing a draft that updates RFC5158 and testing whether there is OSPF WG and IETF consensus for publication of the proposed update.