IPv6 OSPFv3 and EIGRPv6 Dual Stack

Introduction

As enterprise networks adopt IPv6 alongside existing IPv4 infrastructure, network engineers must understand how routing protocols operate in a dual-stack environment. Running both protocol families simultaneously is the most common migration strategy, and it demands routing protocols capable of handling IPv4 and IPv6 address families -- sometimes within a single process.

This lesson focuses on how OSPFv3 supports both IPv4 and IPv6 address families, how IS-IS takes an integrated approach to multiprotocol routing, and the practical considerations that come with deploying these protocols in dual-stack networks. By the end of this lesson, you will understand OSPFv3 address family adjacency rules, the CLI differences between OSPFv2 and OSPFv3 for IPv4, OSPFv3 authentication options, and how IS-IS handles IPv6 through its TLV-based architecture.

Key Concepts

OSPFv3 Address Families

OSPFv3 was originally designed for IPv6 only, but it was later extended to support an IPv4 address family (AF) as well. This means a single OSPFv3 process can carry routing information for both IPv4 and IPv6. Understanding which configurations form adjacencies with each other is critical for troubleshooting.

OSPFv3 Adjacency Compatibility

Not every combination of OSPF configuration styles will form a neighbor relationship. The following table shows which pairings establish adjacencies and which do not:

Router A Configuration	Router B Configuration	Adjacency?
`router ospfv3` / IPv6 AF	`ipv6 router ospf`	Yes
`router ospfv3` / IPv6 AF	`router ospf`	No
`router ospfv3` / IPv6 AF	`router ospfv3` / IPv4 AF	No
`router ospfv3` / IPv4 AF	`ipv6 router ospf`	No
`router ospfv3` / IPv4 AF	`router ospf`	No
`ipv6 router ospf`	`router ospf`	No

Key takeaway: The only cross-compatible pairing is between the OSPFv3 IPv6 AF (router ospfv3 with IPv6 AF) and the legacy ipv6 router ospf syntax. OSPFv3 IPv4 AF does not form adjacencies with traditional OSPFv2 (router ospf), and IPv4 AF and IPv6 AF within OSPFv3 do not peer with each other.

OSPFv2 vs. OSPFv3 IPv4 AF

When choosing between classic OSPFv2 and the OSPFv3 IPv4 address family, there are compelling arguments in favor of OSPFv3:

Single protocol consistency -- if you are also running IPv6, using OSPFv3 for both address families means greater operational consistency
Partial SPF optimization -- OSPFv3 can potentially make better use of Partial SPF calculations as opposed to Full SPF
Prefix suppression -- works more efficiently under OSPFv3
Flexible addressing on inter-router links -- IPv4 addresses on transit links do not matter as much; they can come from discontiguous networks or even be unnumbered if permitted
Stub router via the R-bit -- OSPFv3 provides stub router functionality through the R-bit mechanism
IPsec integration -- OSPFv3 supports IPsec-based authentication and even encryption of routing protocol packets

IS-IS and IPv6

IS-IS is inherently a multiprotocol routing protocol. Because it runs directly over Layer 2 frames rather than over IP, it encodes all routing information as Type-Length-Value (TLV) records inside Link State PDUs. This design naturally lends itself to supporting multiple address families.

RFC 1195 introduced IPv4 support to IS-IS, creating what is known as Integrated IS-IS
RFC 5308 extends IS-IS with IPv6 support, continuing the integrated approach where a single IS-IS instance can handle OSI, IPv4, and IPv6 routing simultaneously

How It Works

OSPFv3 Encapsulation for IPv4

A critical fact to remember is that even when OSPFv3 carries IPv4 routing information, the OSPFv3 packets themselves are still encapsulated in IPv6. This has important implications for:

ACLs -- access control lists filtering OSPF traffic must account for IPv6 encapsulation, not IPv4
QoS -- quality of service policies matching on protocol headers need to look at IPv6 headers
Monitoring -- packet captures and monitoring tools must decode IPv6-encapsulated OSPFv3 packets

Virtual Link Limitations

Virtual links are not supported in OSPFv3 IPv4 AFI. The reason is that OSPFv3 uses IPv6 for transport, but there is no guarantee that the virtual link endpoints have global IPv6 addresses, and such addresses cannot be advertised within an IPv4 AFI. This is an important design constraint when planning your OSPF area topology in dual-stack environments.

Router ID Requirement

In a pure IPv6 environment with no IPv4 addresses configured on any interface, manual Router ID configuration is required for OSPFv3. The router cannot automatically derive a 32-bit Router ID without an IPv4 address, so you must explicitly set one.

IS-IS IPv6 TLV Extensions (RFC 5308)

RFC 5308 defines three key extensions for IPv6 support in IS-IS:

TLV	Type Code	Purpose
IPv6 Reachability TLV	236 (0xEC)	Carries a single IPv6 prefix with its metric and attributes
IPv6 Interface Address TLV	232 (0xE8)	Carries an interface's IPv6 address
IPv6 NLPID	142 (0x8E)	Indicates support of IPv6

IS-IS Integrated Address Family Behavior

Because IS-IS handles all enabled routed protocols in a single instance, several consequences follow:

On the wire, there is only a single exchange of PDUs for all address families
If an adjacency is torn down or cannot be established, all address families are impacted
Churn in one address family causes flooding of new LSPs containing information about all address families
By default on IOS, IOS XE, and NX-OS, all address families are forced to share the same topology, the same link costs, and the same best paths

Configuration Example

IS-IS for IPv6 -- Basic Adjacency

The following configuration establishes a basic IS-IS adjacency with IPv6 support between two routers:

R1:

interface Gi1
 ip address 10.0.0.1 255.255.255.0
 ipv6 address fe80::1 link-local
 ipv6 router isis
!
router isis
 net 49.0001.1111.1111.1111.00

R2:

interface Gi1
 ip address 10.0.0.2 255.255.255.0
 ipv6 address fe80::2 link-local
 ipv6 router isis
!
router isis
 net 49.0001.2222.2222.2222.00

This configuration successfully forms an adjacency because both routers have ipv6 router isis enabled on the interface and both advertise the IPv6 Interface Address TLV in their IIH (IS-IS Hello) packets.

Warning: If one router has both ip router isis and ipv6 router isis on the interface but the other router only has ip router isis, the adjacency will not form. The router running both address families expects the IPv6 Interface Address TLV from its neighbor, and when that TLV is missing, the adjacency fails. Both sides must enable ipv6 router isis on the interface for IPv6 IS-IS to work.

OSPFv3 Authentication Trailer

OSPFv3 originally lacked its own authentication mechanism and relied on IPsec for packet authentication. However, IPsec saw little adoption for this purpose because it is complex, not universally supported, and tedious to configure manually. RFC 7166 reintroduced an authentication trailer to OSPFv3, which is much easier to configure using key chains.

key chain keys
 key 1
  key-string Lab@123
  cryptographic-algorithm hmac-sha-512
!
interface Gi1
 ospfv3 1 ipv6 authentication key-chain keys

This configuration creates a key chain named keys with a single key using the hmac-sha-512 algorithm, then applies it to the OSPFv3 process on the interface. Both neighbors must have matching key chain configurations for the adjacency to form.

OSPFv3 CLI Gotcha -- Verifying IPv4 Routes

When running OSPFv3 with the IPv4 address family, there is an important CLI distinction. The traditional show ip route ospf command returns no output, even though OSPF-learned routes appear in the routing table:

r2# show ip route ospf
r2#

This is because the routes were learned through OSPFv3, not OSPFv2. You must use the ospfv3 keyword instead:

r2# show ip route ospfv3
10.0.0.0/8 is variably subnetted, 7 subnets, 2 masks
O   10.255.255.1/32 [110/10] via 10.0.12.1, 00:08:15, Ethernet0/1
O   10.255.255.3/32 [110/10] via 10.0.23.3, 00:08:15, Ethernet0/0
O   192.0.2.0/24 [110/11] via 10.0.12.1, 00:08:15, Ethernet0/1
O   203.0.113.0/24 [110/11] via 10.0.23.3, 00:08:15, Ethernet0/0

Best practice: Always remember that OSPFv3-learned IPv4 routes require show ip route ospfv3 for verification. This is one of the most common troubleshooting pitfalls when migrating from OSPFv2 to OSPFv3 IPv4 AF.

The full routing table still displays all routes regardless of the protocol source:

r2# show ip route
10.0.0.0/8 is variably subnetted, 7 subnets, 2 masks
C   10.0.12.0/24 is directly connected, Ethernet0/1
L   10.0.12.2/32 is directly connected, Ethernet0/1
C   10.0.23.0/24 is directly connected, Ethernet0/0
L   10.0.23.2/32 is directly connected, Ethernet0/0
O   10.255.255.1/32 [110/10] via 10.0.12.1, 00:03:12, Ethernet0/1
C   10.255.255.2/32 is directly connected, Loopback0
O   10.255.255.3/32 [110/10] via 10.0.23.3, 00:03:12, Ethernet0/0
O   192.0.2.0/24 [110/11] via 10.0.12.1, 00:03:12, Ethernet0/1
O   203.0.113.0/24 [110/11] via 10.0.23.3, 00:03:12, Ethernet0/0

Real-World Application

Dual-Stack Migration Strategy

Most enterprise networks adopt a dual-stack approach during IPv6 migration rather than performing a hard cutover. In this scenario, choosing OSPFv3 for both IPv4 and IPv6 address families provides operational consistency -- a single routing protocol to configure, monitor, and troubleshoot.

Design Considerations

Authentication -- use the RFC 7166 authentication trailer with key chains for OSPFv3 rather than relying on IPsec. It is simpler to deploy and maintain across a large number of routers.
Area design -- because virtual links are not available in OSPFv3 IPv4 AFI, ensure your area topology does not rely on virtual links for backbone connectivity when running dual-stack OSPFv3.
Router ID planning -- in pure IPv6 deployments, always configure an explicit Router ID on every router to prevent OSPFv3 process failures.
IS-IS trade-offs -- the integrated nature of IS-IS means that a failure in one address family cascades to all others. Consider this carefully when deciding between OSPF and IS-IS for dual-stack environments.
Monitoring and ACLs -- remember that OSPFv3 IPv4 AF traffic is encapsulated in IPv6. Update your firewall rules, ACLs, and monitoring tools accordingly.

When to Use IS-IS

IS-IS is commonly deployed in service provider networks and large-scale data centers where its multiprotocol TLV architecture provides a natural fit for carrying IPv4 and IPv6 prefixes. However, the shared-fate nature of a single IS-IS instance means that instability in either address family affects the entire routing domain.

Summary

OSPFv3 supports both IPv4 and IPv6 address families, but the OSPFv3 IPv4 AF does not form adjacencies with traditional OSPFv2 -- they are separate protocols despite sharing the same administrative distance of 110.
Use show ip route ospfv3 instead of show ip route ospf to verify IPv4 routes learned through OSPFv3. This CLI distinction is a frequent troubleshooting trap.
OSPFv3 authentication has evolved from relying on IPsec to supporting an authentication trailer (RFC 7166) configured through key chains, which is far simpler to deploy.
IS-IS handles IPv6 natively through RFC 5308 TLV extensions, but its integrated single-instance design means all address families share fate -- adjacency loss or churn in one AF impacts all others.
Virtual links are not supported in OSPFv3 IPv4 AFI, and pure IPv6 environments require manual Router ID configuration.

Continue your dual-stack studies by exploring redistribution between OSPFv3 and EIGRPv6, route filtering with IPv6 prefix lists, and advanced IS-IS multi-topology configurations that allow independent path selection per address family.