OSPF for IPv6
obsoleted by
- rfc-5340 — OSPF for IPv6
Extracted elements (26)
Addressing semantics have been removed from OSPF packet headers and from Router-LSAs and Network-LSAs, leaving a network-protocol-independent core. IPv6 addresses appear only in LSA payloads carried by Link State Update packets; Router IDs, Area IDs, and Link State IDs remain 32-bit values that can no longer be assigned as IPv6 addresses.
Authentication has been removed from OSPF itself because IPv6 already provides the Authentication Header (AH) and Encapsulating Security Payload (ESP) for integrity and confidentiality. The AuType and Authentication fields present in OSPFv2 have been deleted from the packet header and all interface/area structures.
Link-local addresses are distributed in Link-LSAs rather than in Router-LSAs (as IPv4 interface addresses were) because they are only needed on the local link for next-hop calculation and do not need to be flooded beyond the link. This is more efficient and also handles NBMA links where non-DR routers do not necessarily exchange Hellos.
OSPF for IPv6 runs on a per-link basis rather than per-IP-subnet because IPv6 allows multiple subnets on a single link and two nodes may communicate directly without a common IPv6 prefix. The term 'link' replaces 'subnet' and 'network' throughout the protocol.
The OSPFv2 behavior of discarding unknown LSA types is not supported because it causes problems when the Designated Router supports fewer capabilities than other routers on the link. The U-bit mechanism allows unknown LSA types to propagate without disrupting routers that do not recognize them.
OSPFv3 requires an IPv6 protocol stack but all fundamental OSPF mechanisms remain unchanged from OSPFv2: flooding, DR election, area support, SPF calculations, interface and neighbor state machines, adjacency formation, and on-demand circuit, NSSA, and MOSPF optional capabilities are all preserved with identical semantics.
An LSA with an unrecognized LS type MUST NOT be flooded into or throughout a stub area unless both (a) its flooding scope is area or link-local AND (b) its U-bit is 0. This prevents unrecognized LSAs from inflating stub area link-state databases beyond router capacity.
AS-external-LSAs (LS type 0x4005) MUST NOT be flooded into or throughout stub areas, consistent with OSPFv2 behavior. The forwarding address is included only when the F-bit is set; the external route tag is present only when the T-bit is set; link-local addresses MUST NOT appear as prefixes.
Link-local addresses MUST NOT be advertised in Inter-Area-Prefix-LSAs, AS-external-LSAs, or Intra-Area-Prefix-LSAs. Link-local addresses are permitted only in Link-LSAs.
Neighboring routers on any link type MUST always be identified by their OSPF Router ID; IPv4 behavior of identifying broadcast/NBMA neighbors by IP address is not used. The Router ID 0.0.0.0 is reserved and SHOULD NOT be assigned.
On all OSPF interfaces except virtual links, OSPF packets MUST be sent using the interface's link-local unicast address as the IPv6 source. Virtual links MUST use a global-scope or site-local IPv6 address as source.
Packets addressed to AllDRouters SHOULD only be accepted if the receiving interface is in DR or Backup Designated Router state.
When receiving an OSPF packet, the router MUST verify: version number equals 3, IPv6 checksum is valid, Area ID matches the receiving interface or the backbone (for virtual link packets), and Instance ID matches the receiving interface's Instance ID. Packets failing any check MUST be discarded.
An Instance ID field in the OSPF packet header allows multiple separate OSPF protocol instances to run on a single link. Instance ID defaults to 0 and affects only reception of OSPF packets, cleanly replacing the haphazard IPv4 practice of reusing authentication fields for instance separation.
Network-LSAs (LS type 0x2002) no longer carry a Network Mask; all prefix information has moved to Intra-Area-Prefix-LSAs. The Link State ID is set to the Designated Router's Interface ID on the link. The Options field is the logical OR of Options from all Link-LSAs on the link, so a capability is asserted if any router on the link requests it.
Router-LSAs (LS type 0x2001) contain no IP addresses; topology is expressed as 16-byte link descriptions with fields Type, Metric, Interface ID, Neighbor Interface ID, and Neighbor Router ID. A router may originate multiple Router-LSAs per area (distinguished by Link State ID); SPF calculation MUST concatenate all Router-LSAs from a given router.
Seven LSA types are defined: Router-LSA (0x2001, area scope), Network-LSA (0x2002, area scope), Inter-Area-Prefix-LSA (0x2003, area scope), Inter-Area-Router-LSA (0x2004, area scope), AS-external-LSA (0x4005, AS scope), Link-LSA (0x0008, link-local scope), and Intra-Area-Prefix-LSA (0x2009, area scope). The names of IPv4 type-3 and type-4 summary-LSAs have been changed to Inter-Area-Prefix-LSA and Inter-Area-Router-LSA respectively.
The Intra-Area-Prefix-LSA (LS type 0x2009, area scope) carries all IPv6 prefix information that OSPFv2 embedded in Router-LSAs and Network-LSAs. It references either a Network-LSA (to associate prefixes with a transit link) or a Router-LSA (to associate prefixes with a router). Multiple instances per router are distinguished by Link State ID.
The Link-LSA (LS type 0x0008, link-local scope) serves three purposes: (1) distributes the originating router's link-local address to all other routers on the link for next-hop calculation; (2) informs other routers of IPv6 prefixes to associate with the link; and (3) allows the router to assert Options bits in the Network-LSA for the link.
The LS type field has been expanded from 8 to 16 bits: the top two bits encode flooding scope (00=link-local, 01=area, 10=AS, 11=reserved) and the next bit is the U-bit governing unknown LSA handling. If U-bit=0, unrecognized LSA types are treated as having link-local flooding scope; if U-bit=1, they are stored and flooded as if understood.
The LSA header retains its 20-byte size but the Options field has been removed (moved into specific LSA bodies) and the LS type field expanded to 16 bits occupying the former Options space. LS Age, Advertising Router, LS Sequence Number, LS Checksum, and Length fields remain unchanged from OSPFv2.
The OSPF version number is 3. The Options field in Hello and Database Description packets has been expanded to 24 bits. Two new option bits are defined: the R-bit (clear means the router participates in topology distribution without forwarding transit traffic) and the V6-bit (clear means the router does not forward IPv6 datagrams, even if R-bit is set).
Three flooding scopes are encoded in the upper bits of the 16-bit LS type field: link-local scope (flooded only on the originating link, used for Link-LSAs), area scope (flooded throughout a single OSPF area, used for Router-, Network-, Inter-Area-Prefix-, Inter-Area-Router-, and Intra-Area-Prefix-LSAs), and AS scope (flooded throughout the routing domain, used for AS-external-LSAs).
OSPF for IPv6 relies entirely on IPv6's Authentication Header (RFC 2402) and Encapsulating Security Payload (RFC 2406) to ensure integrity, authentication, and confidentiality of routing exchanges. Accidental data corruption is detected by the standard IPv6 16-bit one's complement checksum covering the entire OSPF packet and the prepended IPv6 pseudo-header.
IPv6 prefixes in LSAs are encoded as [PrefixLength (8 bits), PrefixOptions (8 bits), Address Prefix (variable, padded to the next 32-bit boundary)] instead of the IPv4 [address, mask] encoding. The default route is expressed as a prefix with PrefixLength 0.
The OSPFv3 packet header contains: Version (8 bits, value 3), Type (8 bits), Packet Length (16 bits), Router ID (32 bits), Area ID (32 bits), Checksum (16-bit IPv6 one's complement over the packet plus IPv6 pseudo-header), Instance ID (8 bits), and a reserved byte. It is encapsulated directly in IPv6 with Next Header value 89.