OSPFv3 Explained: OSPF for IPv6 (and Address Families for IPv4)

OSPFv3 is not "OSPF with longer addresses". It is a redesign of the protocol machinery that happens to have shipped alongside IPv6, and with address families (RFC 5838) it can carry IPv4 routes too, which surprises almost everyone the first time they see ospfv3 1 ipv4 area 0 on an interface. This post explains what actually changed from OSPFv2 to OSPFv3, what stayed identical, how the address family model works, and what the protocol looks like on the wire and in the routing table of a live Cisco IOS XE lab. It belongs to both the OSPF and IPv6 clusters; the hands-on companion is OSPFv3 Configuration on Cisco IOS XE.

What Stayed the Same

The algorithmic heart is untouched. OSPFv3 is still link-state: routers flood LSAs, build an identical database, and run Dijkstra SPF to compute shortest paths. Areas work the same way, with area 0 as the backbone. Neighbor discovery still uses hellos, adjacencies still climb through Init, 2-Way, ExStart, Exchange, Loading, and Full, and multiaccess networks still elect a DR and BDR. Costs are still derived from bandwidth. If you can read an OSPFv2 neighbor table, the v3 one holds no surprises:

R1# show ospfv3 neighbor

          OSPFv3 1 address-family ipv6 (router-id 1.1.1.1)

Neighbor ID     Pri   State           Dead Time   Interface ID    Interface
2.2.2.2           1   FULL/DR         00:00:35    1               Ethernet0/1

Even the router ID is still a 32-bit dotted-quad value, which is why an IPv6-only router with no IPv4 addresses must have its router ID set manually.

What Actually Changed

The per-link design is the deepest change. In OSPFv2, the protocol is welded to IPv4 subnets: hellos source from the interface address, and mismatched subnets prevent adjacency. OSPFv3 sources everything from the link-local address, so the protocol converses happily on a link regardless of what global prefixes are configured, and the routing table shows the consequence directly:

R1# show ipv6 route ospf
O   2001:DB8::2/128 [110/10]
     via FE80::A8BB:CCFF:FE00:1C00, Ethernet0/1
OE2 2001:DB8:34::/64 [110/20]
     via FE80::A8BB:CCFF:FE00:1C00, Ethernet0/1

Every next hop is a link-local FE80:: address. Your first reaction ("where are the real addresses?") is the point: forwarding to an on-link neighbor never needed a global address in the first place. Note also the familiar route codes: O for intra-area, OI for inter-area, OE2 for externals with the same AD 110 and the same E1/E2 metric semantics as v2 (the OE2 routes above are EIGRP prefixes redistributed into OSPFv3 in our lab).

Address Families: One Protocol, Both Stacks

The original OSPFv3 specification carried only IPv6. RFC 5838 generalized it: each address family (IPv6 unicast, IPv4 unicast, and multicast variants) maps to a reserved range of Instance IDs, so an IPv4 AF adjacency is just an OSPFv3 instance whose packets carry Instance ID 64 and whose type 9 LSAs carry IPv4 prefixes. The transport is always IPv6 link-local, even when the payload prefixes are IPv4, which means every interface participating in the IPv4 AF still needs ipv6 enable.

On IOS XE this appears as one router ospfv3 process with address families inside it, and interfaces join a specific AF:

router ospfv3 1
 router-id 1.1.1.1
 address-family ipv6 unicast
 address-family ipv4 unicast
!
interface Ethernet0/1
 ospfv3 1 ipv6 area 0
!
interface Ethernet0/2
 ipv6 enable
 ospfv3 1 ipv4 area 0

The neighbor table then reports each family separately, and one process can hold different adjacencies per AF on different links, as in our lab where the IPv4 AF runs on one R1-R2 link and the IPv6 AF on another:

R1# show ospfv3 neighbor

          OSPFv3 1 address-family ipv4 (router-id 1.1.1.1)
Neighbor ID     Pri   State           Dead Time   Interface ID    Interface
2.2.2.2           1   FULL/DR         00:00:33    3               Ethernet0/2

          OSPFv3 1 address-family ipv6 (router-id 1.1.1.1)
Neighbor ID     Pri   State           Dead Time   Interface ID    Interface
2.2.2.2           1   FULL/DR         00:00:35    1               Ethernet0/1

R1# show ospfv3 interface brief
Interface    PID   Area            AF         Cost  State Nbrs F/C
Et0/2        1     0               ipv4       10    BDR   1/1
Lo0          1     0               ipv6       1     LOOP  0/0
Et0/1        1     0               ipv6       10    BDR   1/1

Why would you carry IPv4 in OSPFv3 at all? Operational consolidation: one protocol, one process, one set of timers and policies for both stacks, instead of running OSPFv2 and OSPFv3 side by side forever. In practice most dual-stack enterprises still run both protocols during transition (our lab does exactly that), and the AF model is the destination rather than the starting point. Each AF is a separate SPF domain with separate LSAs; enabling the IPv4 AF does not merge anything with an existing OSPFv2 process, and both will offer routes at AD 110, so migrate deliberately rather than running both sources for the same prefixes indefinitely.

The LSA Model, Briefly

For LSDB readers, the v3 lineup: Router (1) and Network (2) LSAs describe pure topology; Inter-Area Prefix (3) and Inter-Area Router (4) replace v2's summary LSAs; AS External (5) and NSSA (7) work as before; Link LSAs (8) carry a router's link-local address and on-link prefixes to neighbors on that link only; and Intra-Area Prefix LSAs (9) carry the actual prefixes that v2 used to stuff into types 1 and 2. The practical payoff of the split is stability: adding or renumbering a prefix updates a type 9 LSA without touching the topology LSAs, so the SPF tree itself does not recompute for addressing changes.

End to End

Dual-stack proof from the lab: the IPv6 path crosses the OSPFv3 domain into an EIGRPv6 domain via redistribution at the border, and pings clean:

R1# ping 2001:db8::4
Sending 5, 100-byte ICMP Echos to 2001:DB8::4, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 3/4/9 ms

OSPFv2 and OSPFv3 Side by Side

Migration Strategies for Dual-Stack Networks

Three patterns cover almost every real deployment. Ships in the night (the overwhelming majority, and this lab): OSPFv2 owns IPv4, OSPFv3 owns IPv6, the processes share links and fates but exchange nothing; simple, debuggable, and the two-protocol overhead is mostly cognitive. AF consolidation: one OSPFv3 process carries both families, retiring OSPFv2 entirely; cleanest end state, but the cutover needs care because OSPFv2 and the OSPFv3 IPv4 AF both offer routes at AD 110, so migrate area by area with one protocol authoritative per prefix at every step. And v6-only islands: new segments deploy IPv6-only with OSPFv3 from day one, which sidesteps migration but demands the router-id discipline (no IPv4 address to borrow) and NAT64/translation at the edges, which belongs to the IPv6 pillar's transition coverage.

Whichever path you take, monitoring has to split too: show ip ospf neighbor says nothing about OSPFv3, and a dashboard that only polls v2 state will happily show green while the IPv6 half of your dual-stack network is down. Poll both, alert on both, and test failover on both stacks (they can and do diverge).

FAQ

Is OSPFv3 backward compatible with OSPFv2?

No. Different packet formats, different transport, no interoperation. A dual-stack network runs both protocols (or moves IPv4 into OSPFv3's IPv4 AF, which is still OSPFv3, not v2 compatibility).

Why does my IPv6-only router refuse to start OSPFv3?

No 32-bit router ID could be derived from an IPv4 address, because there are none. Set router-id manually; it is a name, not an address, and never needs to be routable.

Do I still need DR/BDR in OSPFv3?

Yes, the multiaccess machinery is unchanged, elections included (and the same ~40 second election patience applies on fresh Ethernet segments). Point-to-point network type still skips it where appropriate.

Can OSPFv3 and EIGRPv6 redistribute into each other?

Exactly like their IPv4 counterparts, seed metrics, tags, loops and all. The OE2 routes in this post's captures are EIGRPv6 prefixes redistributed into OSPFv3 at our lab's border router; the full mechanics are in the redistribution guide.

Key Takeaways

OSPFv3 keeps the SPF engine, areas, neighbor states, and cost model of OSPFv2, and changes the plumbing: per-link operation over link-local addresses, prefixes relocated into type 8 and 9 LSAs, native multi-instance support, and IPsec-based authentication. Next hops are always link-local, and the router ID is still 32 bits (set it manually on v6-only boxes). Address families let one OSPFv3 process route both IPv6 and IPv4, with the IPv4 AF still transported over IPv6 link-local, at the cost of one ipv6 enable per interface. For the command-by-command build, verification workflow, and the gotchas that eat lab time, continue to the OSPFv3 configuration guide, or zoom out to the OSPF pillar, the IPv6 pillar, and the IP Routing cluster.