Support of Address Families in OSPFv3
updated by
Extracted elements (23)
Existing OSPFv3 LSAs (defined for IPv6 unicast prefixes) are reused for advertising prefixes from other AFs without modification, because each prefix already includes a Length field enabling advertisement of different-length prefixes. No new LSA types are required.
Hello packet processing is modified to only establish adjacencies with routers that have the AF-bit set, preventing black-holing that could occur if a non-capable router is included in an SPF-calculated path for a non-IPv6 AF.
IPv4 next-hop addresses are preferable over IPv6 link-local next hops for IPv4 AFs because PIM RPF lookups require the PIM neighbor address and next-hop to both be IPv4, and troubleshooting is easier when prefix and next-hop are in the same AF.
Multiple OSPFv3 instances are used to support multiple address families by mapping each AF to a separate Instance ID. This approach introduces no new protocol mechanisms, minimizes extensions, simplifies implementation, and preserves the existing instance/area/interface configuration model.
All protocol modifications in this specification apply only to non-IPv6-unicast AFs using multiple OSPFv3 instances and are not applicable to IPv6 unicast topologies. Non-capable routers operating in an IPv6 unicast topology are unaffected. Gradual deployment of new AFs does not disturb existing OSPFv3 routing domains because non-capable routers will not form adjacencies in non-IPv6-unicast instances (no AF-bit set in their Hello Options).
An implementation SHOULD resolve layer 3 to layer 2 mappings via ARP or Neighbor Discovery for a Direct Interface Address (DIA) even if the IPv4 address is not on the same subnet as the router's interface IP address.
For IPv4 unicast and IPv4 multicast AFs, the Forwarding Address in AS-external-LSAs and NSSA-LSAs MUST encode an IPv4 address placed in the first 32 bits of the 128-bit Forwarding Address field, with the remaining bits set to zero.
For IPv4 unicast and multicast AFs, the link's IPv4 address MUST be advertised in the 'link local address' field of the IPv4 instance's Link-LSA, placed in the first 32 bits. The remaining bits MUST be set to zero.
For non-IPv6 AFs, the MTU in the Database Description packet MUST always contain the MTU corresponding to the advertised address family (e.g., the IPv4 MTU when the instance corresponds to an IPv4 AF). Both the AF MTU and the IPv6 MTU used for OSPFv3 packet sizing MUST be considered.
If the IPv6 and IPv4 MTUs differ, the M6-bit MUST be set for non-IPv6 address families. An OSPFv3 router SHOULD NOT set the M6-bit if its IPv6 MTU and address-family-specific MTU are the same.
If the M6-bit is set in a received Database Description packet for a non-IPv6 address family, the receiving router MUST NOT check the Interface MTU in the packet against the receiving interface's IPv6 MTU.
IPv6 MUST be enabled on an OSPFv3 link even if the link is not participating in any IPv6 AFs, because OSPFv3 runs on top of IPv6 and uses IPv6 link-local addresses for control packets.
OSPFv3 control packets sent over virtual links MUST have a global IPv6 address associated with the virtual link for correct forwarding by intermediate hops. Virtual links are therefore not supported in AFs other than IPv6 unicast.
Prefixes that do not conform to the address family of an OSPFv3 instance MUST NOT be used in the route computation for that instance.
When an OSPFv3 router is supporting address families as described in this specification, it MUST set the AF-bit in the OSPFv3 Options field of Hello packets, Database Description packets, and LSAs.
When an OSPFv3 router participates in an AF (sets the AF-bit in Options), it MUST discard Hello packets that have the AF-bit clear in the Options field. The sole exception is the base IPv6 unicast AF, where this check MUST NOT be done for backward compatibility.
A new AF-bit is added to the OSPFv3 Options field to indicate that a router supports multiple address families as defined in this specification. The existing V6-bit is only applicable to the IPv6 unicast AF and is ignored in other AFs.
A new M6-bit (IPv6 MTU bit) is defined in the OSPFv3 Database Description packet flags field (octets 20-23). When set, it indicates the sender uses a different IPv6 MTU than the address-family-specific MTU, and the AF MTU in the packet MUST NOT be checked against the local IPv6 MTU.
The OSPFv3 Instance ID number space is partitioned by address family: 0-31 for IPv6 unicast, 32-63 for IPv6 multicast, 64-95 for IPv4 unicast, 96-127 for IPv4 multicast, and 128-255 unassigned. The first value in each range is the default for that AF.
IANA created the 'OSPFv3 Instance ID Address Family Values' registry mapping OSPFv3 Instance IDs 0-127 to specific address families (0-31 IPv6 unicast, 32-63 IPv6 multicast, 64-95 IPv4 unicast, 96-127 IPv4 multicast). Instance IDs 128-255 are unassigned and require a Standards Track RFC for assignment.
The AF-bit was assigned from the OSPFv3 Options registry, the M6-bit was assigned from the DD Packet Flags registry, and TLV type 17 for the IPv6 MTU TLV was assigned from the OSPF LLS TLVs registry.
When multiple OSPFv3 instances share the same interface, they MUST all use the same IPsec Security Association (SA) because SA selectors do not provide selection based on OSPFv3 header fields such as the Instance ID. This is a restriction documented in RFC 4552 Section 8.
The IPv6 MTU TLV (type 17, length 4 bytes) is carried optionally in the LLS block. It conveys the interface's IPv6 MTU as a 32-bit value and is used when the M6-bit is set. Only one instance of this TLV MAY appear in the LLS block.