OSPF for IPv6
Extracted elements (28)
Addressing semantics have been removed from OSPF packets and core LSA types (router-LSAs, network-LSAs), creating a network-protocol-independent core. IPv6 addresses appear only in LSA payloads carried by Link State Update packets. Router IDs, Area IDs, and LS IDs remain 32-bit values that can no longer be assigned as IPv6 addresses.
MOSPF (Multicast Extensions to OSPF) has been deprecated from OSPFv3 because it was only partially specified in RFC 2740, the specification was insufficient for implementation, and there are no known implementations. Associated protocol fields (MC-bit in Options, MT-bit in router-LSA link descriptions) have been deprecated.
OSPFv3 runs per-link rather than per-IP-subnet because IPv6 allows multiple subnets on a single link and permits two nodes to communicate directly even without a shared IPv6 prefix. This required replacing 'network'/'subnet' terminology with 'link' and changing how Hello packets and network-LSAs are constructed.
The stub-area restriction on flooding unknown LSAs (from RFC 2740) has been deprecated in RFC 5340. OSPFv3 routers now flood link- and area-scope LSAs with unknown types and U-bit=1 throughout stub and NSSA areas, removing the concern that uncontrolled LSAs could exhaust stub routers' capacity.
OSPFv3 implementations based on RFC 2740 will fully interoperate with RFC 5340 implementations since all protocol additions and changes are backward compatible. However, RFC 2740 routers that still enforce the deprecated stub-area unknown-LSA flooding restriction may not propagate newly defined LSA types with U-bit=1.
Any encapsulating IPv6 Authentication Headers and Encapsulating Security Payloads MUST be processed and/or verified to ensure integrity and authentication/confidentiality of OSPF routing exchanges before the OSPF packet header is processed.
Before sending a Hello packet, the interface's Interface ID MUST be copied into the Hello packet. Hello packets no longer contain a network mask field, and DR/BDR choices are encoded as Router IDs rather than IP interface addresses. Unrecognized bits in the Hello packet's Options field should be cleared.
In OSPFv3, neighboring routers on all link types (broadcast, NBMA, point-to-point, point-to-multipoint) are always identified solely by their OSPF Router ID. The Router ID 0.0.0.0 is reserved and SHOULD NOT be used.
Link-local addresses MUST NOT be advertised in inter-area-prefix-LSAs, AS-external-LSAs, NSSA-LSAs, or intra-area-prefix-LSAs. Link-local addresses only appear in link-LSAs.
On all OSPF interfaces except virtual links, OSPF packets MUST be sent using the interface's associated link-local unicast address as the source address. On virtual links, a global scope IPv6 address MUST be used as the source address for OSPF protocol packets.
Router interface information MAY be spread across multiple router-LSAs for a given area. Receivers MUST concatenate all router-LSAs originated by a given router when running the SPF calculation. Multiple router-LSAs from the same router are distinguished by their Link State ID fields.
When receiving an OSPFv3 packet, the version number MUST specify protocol version 3, and the IPv6 Upper-Layer checksum covering the entire OSPF packet and prepended IPv6 pseudo-header must be verified. The Area ID and Instance ID in the header MUST match a configured interface or satisfy virtual link criteria; failing packets SHOULD be discarded.
An Instance ID field in the OSPF packet header and interface data structures enables multiple independent OSPF protocol instances to run on a single link, keeping separate routing domains distinct even when sharing physical links. The Instance ID defaults to 0 and solely affects packet reception.
LSA flooding scope is now explicitly encoded in the LS type field with three defined scopes: link-local (flooded only on the originating link, used by link-LSAs), area scope (flooded throughout a single OSPF area, used by router-LSAs, network-LSAs, inter-area-prefix-LSAs, inter-area-router-LSAs, intra-area-prefix-LSAs), and AS scope (flooded throughout the routing domain, used by AS-external-LSAs).
OSPFv3 supports multiple interfaces from the same router attached to the same physical link using a Standby Interface state (Section 4.9). Only one interface per router per link is the Active interface; others are in Standby state, suppressing adjacency formation and LSA origination except as needed for topology accuracy.
The AS-External-LSA (LS type 0x4005) has AS flooding scope and describes a path to a prefix external to the AS. Forwarding address and external route tag are optional, present only when the F-bit and T-bit are set respectively. A Referenced LS Type field and optional Referenced Link State ID support attaching additional route attributes (e.g., BGP path attributes) via a referenced LSA.
The Inter-Area-Prefix-LSA (LS type 0x2003, formerly type-3 summary-LSA) has area flooding scope and describes an IPv6 prefix external to the area but internal to the AS. The Link State ID carries no addressing semantics and merely distinguishes multiple LSAs from the same ABR. Link-local addresses MUST never be advertised in this LSA type.
The Intra-Area-Prefix-LSA (LS type 0x2009) has area flooding scope and carries all IPv6 prefix information that in OSPFv2 was embedded in router-LSAs and network-LSAs. It references either a network-LSA (for transit link prefixes) or a router-LSA (for stub network/router prefixes) via Referenced LS Type, Referenced Link State ID, and Referenced Advertising Router fields.
The Link-LSA (LS type 0x0008) has link-local flooding scope and serves three purposes: (1) provides the router's link-local address to all routers on the link for next-hop calculation, (2) informs neighbors of IPv6 prefixes to associate with the link, and (3) advertises Options bits for inclusion in the link's network-LSA. Link-LSAs SHOULD NOT be originated for virtual links.
The Network-LSA (LS type 0x2002) has area flooding scope and is originated by the link's Designated Router. Unlike its IPv4 counterpart, it contains no network mask or prefix information (moved to Intra-Area-Prefix-LSAs). Its Link State ID is set to the Designated Router's Interface ID on the link, and its Options field is the logical OR of Options from all fully adjacent neighbors' link-LSAs.
The Router-LSA (LS type 0x2001) has area flooding scope and describes a router's interfaces to an area in a network-protocol-independent manner using 16-byte link descriptions containing Type, Metric, Interface ID, Neighbor Interface ID, and Neighbor Router ID. Host routes and stub prefixes are no longer included; they appear in intra-area-prefix-LSAs instead.
Unknown LSA types are handled based on the U-bit in the LS type field: if U=0, the LSA is treated as having link-local flooding scope; if U=1, the LSA is stored and flooded as if the type were understood. The IPv4 behavior of discarding unknown types is explicitly not supported because it causes problems when the Designated Router supports fewer capabilities than other routers on the link.
Section 7 addresses IANA considerations for OSPFv3 including deprecation of MOSPF-related fields. OSPFv3 defines new LSA type codepoints (0x2001 router-LSA, 0x2002 network-LSA, 0x2003 inter-area-prefix-LSA, 0x2004 inter-area-router-LSA, 0x4005 AS-external-LSA, 0x2007 NSSA-LSA, 0x0008 link-LSA, 0x2009 intra-area-prefix-LSA) with the upper 3 bits of the 16-bit LS type encoding the U-bit and flooding scope.
Authentication has been entirely removed from the OSPFv3 protocol itself; the AuType and Authentication fields present in OSPFv2 are gone. OSPFv3 relies on IPv6's Authentication Header (AH) and Encapsulating Security Payload (ESP) as described in [OSPFV3-AUTH] for integrity, authentication, and confidentiality. Corruption protection uses the standard IPv6 Upper-Layer checksum covering the entire OSPF packet and the prepended IPv6 pseudo-header.
OSPFv3 is encapsulated directly in IPv6 with the Next Header field of the immediately encapsulating IPv6 header set to 89. IPv6 prefixes in LSAs are represented as [PrefixLength (8-bit), PrefixOptions (8-bit), Address Prefix] with the prefix field padded to a 32-bit word boundary. The default route is expressed as a prefix with length 0.
The IPv6 prefix PrefixOptions field is 8 bits attached to each prefix in LSA bodies. Key bits include: NU (bit 0x01, no unicast—do not use prefix for unicast forwarding), LA (bit 0x02, prefix is a local address on the advertising router), P (bit 0x08, propagate NSSA prefix to AS external), and DN (bit 0x10, down bit for VPN loop prevention).
The LSA LS type field has been expanded from 8 to 16 bits. The high-order bit (U-bit) encodes handling of unknown types: 0 = treat as link-local flooding scope, 1 = store and flood as if type understood. The next two bits encode flooding scope: 00=link-local, 01=area, 10=AS. The Options field was removed from the 20-byte LSA header, expanded to 24 bits, and moved into the bodies of router-LSAs, network-LSAs, inter-area-router-LSAs, and link-LSAs.
The OSPFv3 packet header sets the version number to 3, expands the Options field to 24 bits, removes Authentication and AuType fields, and adds an Instance ID field. Two new Options bits are added: the R-bit (clear means router participates in topology without forwarding transit traffic) and the V6-bit (clear means router does not forward IPv6 datagrams but may forward other protocols).