OSPF Deep Dive Part 5: OSPFv3 and Running OSPF Over IPv6

Every post in this series so far has run on IPv4, and IPv4-only OSPF coverage is common enough on vendor documentation and training material that it’s easy to assume OSPFv3 is just OSPFv2 with 128-bit addresses swapped in. It isn’t. The LSA structure changed, the authentication model changed, and the addressing model changed in a way that isn’t obvious until an interface is configured for OSPFv3 and it forms an adjacency using an address that was never explicitly assigned.

What actually changed

OSPFv2’s Router and Network LSAs mix topology information (who’s connected to whom) with addressing information (what prefixes exist on those connections) in the same LSA. OSPFv3 splits these apart. Router and Network LSAs in OSPFv3 describe topology only, and a separate LSA type, the Intra-Area-Prefix LSA, carries the addressing. The old Summary LSA (Type 3) is renamed Inter-Area-Prefix LSA, and the ASBR Summary LSA (Type 4) is renamed Inter-Area-Router LSA. None of this changes the area hierarchy from Part 2, stub, totally stubby, NSSA, and totally NSSA all still work the same way and filter the same categories of information. It changes which LSA type carries which piece of that information.

This split exists because RFC 5838 later extended OSPFv3 to carry address families beyond IPv6, including IPv4, by reusing the same topology LSAs and just adding a different prefix LSA per address family. That’s a detail that rarely comes up in a straightforward IPv6 deployment, but it explains why the LSA redesign happened at all rather than OSPFv3 simply being OSPFv2 with wider address fields.

Authentication is the other major change, and it’s a removal, not an addition. OSPFv2 carries authentication (null, plaintext, or MD5) directly in its own packet header. OSPFv3 has no equivalent field. Authentication and encryption, if either is wanted, come entirely from IPv6’s own IPsec (AH or ESP), applied at the interface level rather than inside the OSPF packet itself. This is a meaningful operational change from Part 6’s IPv4 authentication material: there’s no OSPFv3-specific authentication command to configure on any of the three platforms in this series, because OSPFv3 doesn’t have an authentication concept of its own to configure.

Link-local addressing changes what “neighbor” means

OSPFv3 hello and LSA traffic runs over IPv6 link-local addresses, not global unicast addresses, even when the interface also has a global address assigned. This is worth sitting with for a moment: the neighbor relationship itself, at the packet level, uses an address that was never explicitly configured by an administrator and isn’t the address that shows up in a show ipv6 route or get router info6 routing-table output. The router ID is still a 32-bit value in the same dotted format OSPFv2 uses, and still has to be manually configured or auto-selected the same way, because IPv6 addresses don’t map cleanly onto a 32-bit router ID and OSPFv3 didn’t try to make them.

The practical consequence: a router with IPv6 unicast routing enabled and a global address assigned but no explicit router ID configured, and no IPv4 address anywhere on the box to fall back to for auto-selection, will fail to bring up OSPFv3 at all, with an error that’s easy to misread as an addressing problem when it’s actually a missing router ID. All three vendors in this series require a router ID to be resolvable somehow before OSPFv3 comes up, IPv6-only network or not.

Bringing it up on all three vendors

Cisco IOS-XE moved OSPFv3 to an address-family model rather than reusing the OSPFv2-style global process command wholesale:

ipv6 unicast-routing
router ospfv3 1
 router-id 10.0.0.1
 address-family ipv6 unicast
 exit-address-family
!
interface GigabitEthernet0/1
 ipv6 address 2001:db8:0:1::1/64
 ospfv3 1 ipv6 area 0

The per-interface ospfv3 1 ipv6 area 0 line is the part most often missed, since it’s a separate step from defining the process and address-family under the router configuration. Without it, the process exists but no interface actually participates.

Junos uses a distinct protocol name, ospf3, rather than reusing ospf with an address-family qualifier:

set routing-options router-id 10.0.0.3
set interfaces ge-0/0/1 unit 0 family inet6 address 2001:db8:0:1::3/64
set protocols ospf3 area 0.0.0.0 interface ge-0/0/1.0

Junos’s separation of ospf and ospf3 as entirely distinct protocol stanzas, rather than one protocol with an address-family knob, mirrors Cisco’s classic (pre-XE) ipv6 router ospf model more than IOS-XE’s current address-family approach, which is a useful thing to know precisely because it means Junos and modern Cisco now structure this differently from each other despite both having done IPv6 OSPF for a long time.

FortiOS follows the same “6” suffix pattern it uses elsewhere for IPv6 equivalents of IPv4 features:

config router ospf6
    set router-id 10.0.0.2
    config area
        edit 0.0.0.0
            config interface
                edit "port2"
                    set interface "port2"
                    set area 0.0.0.0
                next
            end
        next
    end
end

What doesn’t change

The neighbor state machine from Part 1 is identical. DR/BDR election works the same way over the same network types. The SPF algorithm and route-type preference order from Part 3 are unchanged. Area filtering rules from Part 2 apply the same way to the renamed LSA types. This is by design: OSPFv3’s changes are entirely about how topology and addressing information get packaged and secured, not about the fundamental algorithm or area model that makes OSPF what it is. A router running both OSPFv2 and OSPFv3 in the same area runs two entirely separate, non-interacting instances of the same logic, one per address family, which is also why RFC 5838’s later address-family extension to OSPFv3 itself was possible without touching the core protocol at all.

Part 6 goes back to OSPFv2 territory for the last piece of the fundamentals arc before the series turns vendor-specific: authentication, and what actually gets exposed to an attacker on an unauthenticated segment.