Skip to content
Log in Sign up My account

1.6 IPv6 Migration Strategies

Blueprint 1.6: IPv6 migration strategies

  • 1.6.a Overlay: tunneling IPv6 across an IPv4 network (manual, GRE, 6to4, ISATAP, 6rd, 6PE and 6VPE)
  • 1.6.b Native: dual-stacking
  • 1.6.c Boundaries: IPv4/IPv6 translation (NAT64, DNS64, 464XLAT, and why NAT-PT is deprecated)

IPv6 migration is a sequencing problem: which parts of the network, applications and users move first, and which technique bridges the gap between old and new. There are three families of techniques, and the exam asks you to pick the one that matches the constraint. Prefix planning is in Addressing Plans. Tunnel mechanics are in ENCOR GRE and IPsec, and first hop protection for IPv6 is in ENARSI IPv6 first hop security.

The three strategies

Strategy Idea Network requirement Typical use
Dual stack (native) Every device runs IPv4 and IPv6 side by side Every hop supports IPv6 Preferred end state. Campus, data centre, edge.
Tunneling (overlay) IPv6 packets carried inside IPv4 across parts that cannot route IPv6 Only the tunnel endpoints need IPv6 Bridging IPv6 islands across an IPv4-only core or WAN
Translation (boundary) Convert between IPv4 and IPv6 headers at a gateway A translator and, usually, DNS64 IPv6-only clients reaching IPv4-only services, or the reverse 
graph LR
    A["IPv6 island A"] -- "overlay tunnel over IPv4 core" --- B["IPv6 island B"]
    C["IPv6-only clients"] -- "NAT64 + DNS64" --- D["IPv4-only servers"]
    E["Dual-stack campus"] --- F["Dual-stack edge"]

Rule of thumb: dual stack where you can, tunnels where you must bridge, translation only at a boundary. The order of preference is driven by operational cost: dual stack doubles the routing and security configuration but gives full native performance, tunnels add MTU and troubleshooting problems, and translation is stateful and breaks some applications.

1.6.b Native: dual stack

Every interface carries both an IPv4 and IPv6 address, and both routing protocols (or protocol address families) run. Hosts prefer IPv6 when an AAAA record exists (Happy Eyeballs, RFC 8305, falls back quickly when IPv6 is broken).

Design considerations:

  • Platform scale: each stack has its own forwarding, ACL and routing entries. On many switches the TCAM must be re-carved (an SDM template change that needs a reload on some platforms) to allocate space for IPv6.
  • Routing: run the IGP in dual-stack mode: OSPFv3 with address families, IS-IS with multi-topology, EIGRP named mode, or separate processes. BGP carries each family separately. See the IGP pages in this module.
  • Security policy: ACLs, firewall rules, CoPP and first hop security must exist for both stacks. A forgotten IPv6 policy is a classic hole, because IPv6 may be enabled by default on hosts (link-local) even when the network team has not deployed it.
  • Management and operations: DHCPv6 or SLAAC, DNS AAAA records, monitoring, logging and NetFlow all need IPv6 coverage.
  • Address assignment: SLAAC for simple hosts, stateless or stateful DHCPv6 for options and tracking. Use RA guard and DHCPv6 guard on access ports.

Dual stack's weakness is that it does not reduce IPv4 usage, so it does not solve IPv4 exhaustion by itself. It is the right answer when the requirement is "native performance with the least added complexity" and every hop can run IPv6.

Exam trap

Dual stack is not the answer when the stem says part of the path (a WAN carrier, an older core) cannot forward IPv6, or when IPv4 addresses are exhausted and the requirement is to remove IPv4 from new segments. The first points to tunneling, the second to IPv6-only with translation.

1.6.a Overlay: tunneling

A tunnel wraps IPv6 in IPv4 (or MPLS) so that only the endpoints need IPv6.

Tunnel type Mode Notes
Manual IPv6-in-IPv4 (tunnel mode ipv6ip) Point to point Simple and stable, IP protocol 41
GRE (tunnel mode gre ip) Point to point Carries IPv6 plus multicast and routing protocols. Preferred when a routing protocol must run over the tunnel.
6to4 Automatic, point to multipoint Uses 2002::/16 derived from a public IPv4 address. Needs a public address, relies on relays, and is deprecated (RFC 7526).
ISATAP Automatic, host to router Intra-site, embeds the IPv4 address in the interface identifier. Legacy and used for Windows hosts.
6rd Provider-controlled Like 6to4 but uses the provider's own prefix, so no dependency on anycast relays. Used by ISPs.
6PE MPLS IPv6 over an IPv4 MPLS core, with IPv6 labels carried by MP-BGP between PEs. The core runs no IPv6.
6VPE MPLS L3VPN The same idea for IPv6 VRFs (VPNv6 address family).
DMVPN / IPsec Overlay IPv6 can run over an IPv4 DMVPN (and the reverse) with the transport address family separate from the payload. 
interface Tunnel6
 ipv6 address 2001:db8:ff::1/127
 tunnel source Loopback0
 tunnel destination 192.0.2.2
 tunnel mode ipv6ip
 ipv6 mtu 1480

Design points for tunnels:

  • MTU: the IPv4 header adds 20 bytes (more for GRE or IPsec). Set the tunnel MTU and rely on Path MTU Discovery working; blocked ICMPv6 "packet too big" messages cause black holes.
  • Performance: software encapsulation on some platforms; check hardware support.
  • Troubleshooting and visibility: inner traffic is hidden from the core. Monitoring and QoS in the core cannot see it unless marked on the outer header.
  • Scalability: manual tunnels need a full mesh for any-to-any. Use automatic tunnel types or DMVPN to avoid n squared configuration, or use 6PE where the core is MPLS.
  • Temporary by design: a tunnel solution should have an exit plan, since it adds permanent debt otherwise.

1.6.c Boundaries: translation

Translation lets IPv6-only and IPv4-only systems communicate. It changes headers, so it is stateful and application-sensitive (applications that embed IP addresses in payloads need helpers, and end-to-end security such as IPsec AH breaks).

Technique Direction How it works
Stateful NAT64 (RFC 6146) with DNS64 (RFC 6147) IPv6 clients to IPv4 servers DNS64 synthesizes AAAA records from A records using a prefix (well-known 64:ff9b::/96). NAT64 translates the packets and keeps state, like PAT.
Stateless NAT64 / SIIT IPv6 to IPv4, 1:1 Algorithmic address mapping, no state, needs a 1:1 IPv4 address per host
464XLAT IPv4-only apps on IPv6-only access Client-side translation (CLAT) plus provider-side NAT64 (PLAT). Common in mobile networks.
NAT-PT Old protocol translation Deprecated (see RFC 4966). Not a valid modern answer.
IPv4-to-IPv6 (reverse) IPv4 clients reaching IPv6 servers Static NAT64 mappings or application proxies, often through a load balancer or reverse proxy
Application proxy / load balancer Either way Terminates one protocol and opens the other. Often the simplest for public web services. 
interface GigabitEthernet0/0/0
 description IPv6 inside
 nat64 enable
interface GigabitEthernet0/0/1
 description IPv4 outside
 nat64 enable
!
nat64 prefix stateful 64:ff9b::/96
nat64 v4 pool P1 198.51.100.10 198.51.100.20
nat64 v6v4 list NAT64-LIST pool P1 overload
ipv6 access-list NAT64-LIST
 permit ipv6 2001:db8:100::/48 64:ff9b::/96

Exam trap

NAT64 is stateful and needs DNS64 for name-based traffic. A client that connects by a literal IPv4 address cannot use it without extra help, which is why 464XLAT exists. Another trap: NAT-PT is a historic technology and is never the preferred design answer.

Choosing a strategy

Requirement Best fit
All devices support IPv6 and there is no IPv4 shortage Dual stack
IPv6 islands separated by an IPv4-only network Tunnels (GRE, IPv6-in-IPv4) or DMVPN
Service provider MPLS core with no IPv6 in the core 6PE or 6VPE
IPv6-only access network (mobile, new site) must reach IPv4 internet NAT64 + DNS64, or 464XLAT
Legacy IPv4-only app server must serve IPv6 users Reverse proxy or load balancer at the edge
Must support IPv6 immediately for a new service, with minimum change Dual stack at the edge only, plus proxy

A typical enterprise phased approach: start at the internet edge and DMZ (dual stack public services), then data centre front ends, then campus access, then WAN, using tunnels only where an unsupported segment lies between ready segments, and leave translation for IPv6-only islands.

Design exercise

Scenario. A hospital group has three campuses connected by a carrier MPLS L3VPN service that does not offer IPv6. A new clinical application has IPv6-only requirements from a regulator, and campus A and campus C are ready to run IPv6 now. Campus B uses switches that cannot route IPv6 for another 18 months. The firm also plans an IPv6-only guest network that must reach IPv4 internet sites. Budget for a second WAN service is not available.

Requirements and constraints.

  • IPv6 between campus A and campus C now.
  • The WAN service carries only IPv4.
  • Campus B stays IPv4 only until the upgrade.
  • IPv6-only guests must reach IPv4 internet sites.
  • No new WAN circuit.
Model answer

Between A and C: build IPv6 over GRE or DMVPN tunnels (or IPv6-in-IPv4) across the carrier's IPv4 service, secured with IPsec where policy requires. The routing protocol (OSPFv3 or BGP IPv6) runs inside the tunnel. A GRE tunnel is preferred over a bare 6-in-4 tunnel because the IGP and multicast work across it. Adjust tunnel MTU and permit ICMPv6 packet-too-big.

Within A and C: dual stack, so existing IPv4 services are unaffected.

Campus B: stays IPv4-only. When its switches are upgraded, convert it to dual stack and retire any tunnels or replace them with native service if the carrier later offers IPv6.

Guest network: deploy NAT64 with DNS64 at the internet edge for the IPv6-only guest VLAN.

Rejected alternatives:

  • Ask the carrier for 6VPE: the service does not offer it, and no new service is budgeted.
  • Dual stack end to end: impossible across the IPv4-only carrier and campus B.
  • NAT-PT or translation between campuses: breaks end-to-end addressing and is deprecated.
  • 6to4 or ISATAP: deprecated or host-oriented, and not controllable for a managed WAN.
  • Delay IPv6 until campus B is ready: violates the regulator's requirement.

Quick check

A provider wants to offer IPv6 over an MPLS core that has no IPv6 on the P routers. Which technology?

6PE for the global table (or 6VPE for VRFs). PE routers are dual stack, carry IPv6 labels in MP-BGP, and the P routers just switch labels.

Why does NAT64 usually need DNS64?

IPv6-only clients look up names and get no AAAA record for an IPv4-only server. DNS64 synthesizes an AAAA from the A record using the NAT64 prefix, so the client sends traffic to an address the NAT64 gateway can translate.

Name one risk of a dual-stack rollout that is not about routing.

IPv6 security policy gaps. Hosts may already use IPv6 link-local or SLAAC, and ACLs, firewall rules and first hop security must be written for IPv6 as well as IPv4.

References

  • IPv6 Configuration Guide and Implementing IPv6 Transition, Cisco IOS XE (search "IPv6 Configuration Guide IOS XE" and "NAT64" on cisco.com)
  • RFC 4213 (basic transition mechanisms), RFC 6146 (stateful NAT64), RFC 6147 (DNS64), RFC 6052 (IPv6 addressing of IPv4/IPv6 translators), RFC 4798 (6PE), RFC 8305 (Happy Eyeballs), RFC 7526 (6to4 deprecation) at rfc-editor.org
  • Cisco Live On-Demand Library: search "IPv6 transition" and "NAT64"