OSPFv3 over IPv4 for IPv6 Transition
updates
- rfc-5838 — Support of Address Families in OSPFv3
Extracted elements (17)
Some deployed link-layer equipment (notably VSAT and serial-line hardware) only supports IPv4 EtherType (0x0800) and ARP (0x0806), rejecting IPv6 frames (EtherType 0x86dd) in hardware filters. OSPFv3 over IPv4 allows these devices to participate in an OSPFv3 routing domain without hardware upgrades, deferring equipment replacement costs.
The RFC 5838 restriction that OSPFv3 virtual links are only supported in the IPv6 address family was imposed because IPv4 destinations were not considered routable in an IPv6-presumed internet. This document relaxes that restriction: virtual links in IPv4 address families are now permitted provided the transport is also IPv4, making the constraint transport-symmetric rather than address-family-absolute.
Transporting OSPFv3 over IPv4 simplifies the transition from IPv4-only to dual-stack or IPv6-only routing domains. It allows operators to deploy and test OSPFv3 on existing IPv4 infrastructure, consolidating future protocol extensions on OSPFv3 while allowing OSPFv2 to enter maintenance mode, rather than requiring a flag-day cutover.
An OSPFv3 packet encapsulated in a 20-octet IPv4 header is shorter than one encapsulated in an IPv6 header; therefore the IPv6 link MTU is always sufficient for the IPv4-encapsulated form. If the link MTU is nonetheless insufficient, OSPFv3 may rely on IPv4 fragmentation and reassembly per RFC 791.
BFD (RFC 5881) cannot be used for OSPFv3 adjacency loss detection when adjacencies are formed across different IPv4 subnets, because BFD for single-hop IPv4/IPv6 is restricted to a single subnet.
When OSPFv2 and OSPFv3-over-IPv4 coexist on the same link, both processes receive each other's packets (same protocol number 89, same multicast groups). Packets are silently dropped after version-field validation; implementations should suppress the resulting SNMP bad-packet notifications to avoid spurious alerts.
An OSPFv3 router implementation MAY support adjacencies with OSPFv3 neighbors on different IPv4 subnets. If cross-subnet adjacencies are supported, the IPv4 data plane MUST resolve IPv4 addresses to Layer 2 addresses using ARP on multi-access networks and point-to-point over LAN (RFC 5309) for direct next hops.
For OSPFv3 over IPv4, the source address of each transmitted packet MUST be the primary IPv4 address of the outgoing interface. All OSPFv3 routers on the link should share the same IPv4 subnet for transport to function correctly.
Implementations of OSPFv3 over IPv4 transport SHOULD implement separate counters for protocol mismatch (OSPFv2 packet received by OSPFv3 process and vice versa) and SHOULD provide means to suppress the relevant SNMP bad-packet notifications defined in RFC 4750 and RFC 5643.
In OSPF routing domains that require virtual links, the IP transport MUST match the address family (IPv4 or IPv6). Specifically, if IPv4 transport is used for IPv6 address families, virtual links cannot be supported.
When an OSPFv3-over-IPv4 packet is sent to AllSPFRouters, the IPv4 destination address field MUST be 224.0.0.5. When sent to AllDRouters, the IPv4 destination address MUST be 224.0.0.6.
OSPFv2 and OSPFv3 share IP protocol number 89 and place the OSPF version field at the same offset in the packet header. When both run over IPv4, mismatched packets are delivered to both processes by the socket layer but dropped upon version field validation, distinguishing OSPFv2 (version 2) from OSPFv3 (version 3).
OSPFv3 virtual links in the IPv4 unicast address family are now supported when the transport is also IPv4. This is accomplished by setting the IPv4 destination address to a reachable IPv4 unicast address for the virtual link endpoint, relaxing the restriction in Section 2.8 of RFC 5838.
OSPFv3 normally relies on IPsec (RFC 4301) for authentication and confidentiality, but RFC 4552 specifies IPsec use only for OSPFv3 over IPv6. Running OSPFv3 over IPv4 transport requires additional work analogous to the OSPFv2 IPsec specification; no equivalent standard currently exists.
When using the optional OSPFv3 Authentication Trailer (RFC 7166) with IPv4 encapsulation, the Apad value used in the authentication data calculation must be formed by placing the IPv4 source address in the first 4 octets followed by the repeating pattern 0x878FE1F3 for the remaining (L-4)/4 32-bit words, where L is the hash length in octets. All other Authentication Trailer generation and validation logic remains unchanged.
OSPFv3 packets are encapsulated directly within IPv4 packets as the payload, omitting the IPv6 header. The IPv4 Protocol field is set to 89, and the OSPFv3 header Version field is set to 3. An optional OSPF LLS extension data block may trail the OSPFv3 body within the same IPv4 packet.
The pseudo-header used for OSPFv3 checksum calculation over IPv4 contains: 32-bit IPv4 source address, 32-bit IPv4 destination address, 8-bit zero pad, 8-bit Protocol field (89), and 16-bit OSPFv3 packet length from the OSPFv3 header. This format mirrors the UDP pseudo-header defined in RFC 768.