skip to content

How does OSPFv3 route IPv4 prefixes using RFC 5838 address families, and why must IPv6 still be enabled on every link that carries them?

level: seniorimportance: nice to knowfreq 7%

answer

  1. one instance per address family
  2. Instance ID ranges
  3. same LSAs, prefix length does the work
  4. an IPv4 next hop in the Link-LSA
  5. control packets still ride IPv6

basics

~20 s

RFC 5838 maps each address family to its own OSPFv3 instance by Instance ID, 64 to 95 for IPv4 unicast. IPv4 prefixes ride in the existing LSAs, but the protocol's packets still travel between IPv6 link-local addresses.

solid answer

~50 s

OSPFv3 already supports several instances per link through the `Instance ID`, and its router- and network-LSAs carry no addresses. **RFC 5838** builds on both: each address family is a separate instance with its own adjacencies, database and SPF, chosen by Instance ID range, `0`-`31` IPv6 unicast, `32`-`63` IPv6 multicast, `64`-`95` IPv4 unicast, `96`-`127` IPv4 multicast, the first value of each being the default. No new LSA types are needed; the prefix-length field lets the existing LSAs carry IPv4 prefixes. Routers set the new `AF-bit` and drop Hellos without it, except in the base IPv6 unicast family, so a router that does not understand address families never joins an IPv4 path. An IPv4 next hop goes in the first 32 bits of the Link-LSA's link-local address field. OSPFv3 still runs over IPv6 link-local addresses, so IPv6 must be enabled on the link.

go deeper

for a junior

Recall that OSPFv3 can carry IPv4 routes as a separate address family, and that it still needs IPv6 on the link to run at all.

for a middle

Explain how the Instance ID selects the address family, that each family has its own database and SPF, and that the existing LSAs carry the IPv4 prefixes.

for a senior

Explain the black-hole risk from routers that do not support address families and how the AF-bit check prevents it, plus IPv4 next hops in the Link-LSA.

for a principal

Weigh one OSPFv3 with address families against separate OSPFv2 and OSPFv3: shared failure domain, mixed implementation support, the IPv6-enabled requirement and migration order.

## The problem A dual-stack network running OSPF traditionally runs **two protocols**: OSPFv2 for IPv4 and OSPFv3 for IPv6, with two configurations, two sets of adjacencies and two databases. **RFC 5838** (Standards Track) lets OSPFv3 alone carry other **address families (AFs)**: IPv6 multicast, IPv4 unicast and IPv4 multicast besides the base IPv6 unicast. ## Why OSPFv3 could do it cheaply Two properties of RFC 5340 do most of the work: - **Multiple instances per link.** The OSPFv3 header carries an `Instance ID`; a packet whose Instance ID does not match the receiving interface's is discarded, so independent instances can share a link. - **Protocol-independent topology.** Router-LSAs and network-LSAs contain no addresses, and every prefix is carried as a prefix length plus prefix bits. An IPv4 `/24` is just a prefix with length 24. RFC 5838 says its approach introduces no new protocol mechanism; it maps each AF to an instance. ## Instance ID ranges | Instance ID | Address family | |---|---| | 0-31 | IPv6 unicast | | 32-63 | IPv6 multicast | | 64-95 | IPv4 unicast | | 96-127 | IPv4 multicast | | 128-255 | unassigned | The first value of each range is that family's default, so an IPv4 unicast instance uses `64` unless configured otherwise. Each Instance ID is a **separate OSPFv3 instance** with its own neighbour adjacencies, link-state database, data structures and SPF computation. Running IPv6 and IPv4 this way therefore still means two databases and two SPF runs, inside one protocol. ## What changes on the wire 1. **No new LSA types.** The existing LSAs carry the IPv4 prefixes. A prefix that does not belong to an instance's AF must not be used in that instance's route computation. 2. **The AF-bit.** A new `AF-bit` in the OSPFv3 Options field must be set in Hellos, Database Description packets and LSAs by a router supporting address families. A router participating in an AF must discard Hellos whose AF-bit is clear, except in the base IPv6 unicast AF, where the check is skipped for backward compatibility. 3. **IPv4 next hops.** OSPFv3's next hops are normally IPv6 link-local addresses. For the IPv4 families the link's **IPv4 address** is put in the first 32 bits of the Link-LSA's link-local address field, the remaining bits zero, and used for IPv4 next-hop calculation. RFC 5838 notes the two routers' IPv4 addresses need not be on the same subnet, and says ARP should still resolve them. 4. **IPv4 forwarding addresses.** In AS-External-LSAs and NSSA-LSAs, an IPv4 forwarding address likewise occupies the first 32 bits of the 128-bit field. 5. **MTU.** The Database Description packet carries the MTU for the instance's address family, and an `M6-bit` signals that the IPv6 MTU differs. 6. **The V6-bit** applies only to the IPv6 unicast AF and is ignored in the others. ## Why the AF-bit check matters Router-LSAs and network-LSAs are AF-independent. Suppose a router that does not implement RFC 5838 is configured with Instance ID 64. It can form adjacencies in that instance and appear in the shortest-path tree as a transit router, yet it will not forward IPv4. Traffic routed through it is **black-holed**. RFC 5838 names this risk, from a misconfiguration or a software downgrade, and the AF-bit check is its fix: routers in the IPv4 AF refuse adjacency with any router whose Hellos lack the bit. ## Why IPv6 must still be enabled OSPFv3 is an IPv6 protocol. Its packets are IPv6 packets with Next Header 89, sent from **IPv6 link-local addresses** and, on multicast-capable links, mostly addressed to `ff02::5` and `ff02::6`. That does not change in an IPv4 instance. RFC 5838 therefore requires IPv6 to be enabled on every OSPFv3 link, even one that participates in no IPv6 address family. An IPv4-only link cannot run the OSPFv3 IPv4 AF. ## What it does and does not save One protocol instead of two means one implementation to operate, one set of timers and one authentication scheme across both families. It does not halve the work: each family is still its own instance, with its own adjacencies on every link, its own flooding and its own SPF. And because the IPv4 instance runs on IPv6, a fault in a link's IPv6 configuration now takes down IPv4 routing on that link as well. ## Mistakes that show up in interviews - Saying OSPFv3 tunnels OSPFv2 packets to carry IPv4. - Saying IPv4 and IPv6 share one OSPFv3 database and one SPF run. - Expecting new LSA types for IPv4. - Assuming Instance ID 0 carries IPv4; it is the IPv6 unicast default.

  • What goes wrong if an OSPFv3 router that does not implement RFC 5838 is configured with Instance ID 64?
    Without the AF-bit check it could form adjacencies in the IPv4 unicast instance, appear in that instance's shortest-path tree because router- and network-LSAs are AF-independent, and then fail to forward IPv4, black-holing traffic. RFC 5838 prevents it: routers in an AF set the AF-bit and must discard Hellos with the bit clear, so the old router never becomes a neighbour.
  • Why does an OSPFv3 IPv4 instance advertise an IPv4 address in its Link-LSA instead of using the IPv6 link-local next hop?
    An IPv6 link-local address could serve as the next hop, but RFC 5838 prefers next hops in the same family as the prefix. In IPv4 multicast, the reverse-path check needs the neighbour and next-hop addresses to be IPv4, and troubleshooting is easier when they match. The IPv4 address occupies the first 32 bits of the Link-LSA's link-local address field, and the remaining bits are zero.

saying these in an interview costs you the question

  • OSPFv3 carries IPv4 by tunnelling OSPFv2 packets inside IPv6.
  • RFC 5838 adds new LSA types to hold IPv4 prefixes.
  • An IPv4-only link can run the OSPFv3 IPv4 address family.
  • IPv4 and IPv6 routes share one OSPFv3 database and one SPF run.
  • Instance ID 0 is the default for IPv4 unicast in OSPFv3.