Skip to main content
Your first session is free. Claim mine
PacketMentor logo
Open menu
Home
Training
CCNA Library (74)
Browse all CCNA topics →
Network (13)
Device Operations (5)
Network Access (12)
Wireless (6)
IP Connectivity (10)
IP Services (11)
Security (10)
Automation (7)
CCNP Library (15)
LabsPricing
Contact 📞 +1 (860) 556-3010 Book a Call
← All topics
IP Connectivity Intermediate

IPv6 Transition Mechanisms

How networks bridge the IPv4 → IPv6 gap — dual-stack, tunneling (6to4, 6in4, GRE), NAT64 / DNS64, and the realistic 2026 migration patterns.

TL;DR
  • IPv4 isn't going away by itself. Real networks run **dual-stack** (IPv4 and IPv6 simultaneously) and use translation/tunneling where one side hasn't caught up.
  • Three mainstream techniques: dual-stack (run both protocols), tunneling (IPv6 inside IPv4 or vice versa), translation (NAT64 / DNS64).
  • Modern strategy: dual-stack everywhere you can, NAT64 to bridge IPv6-only clients to legacy IPv4 services.

Mental model

The textbook says “IPv6 will replace IPv4.” That’s been the textbook for 25 years. Reality:

  • Mobile carriers and large hyperscalers are heavily IPv6 (T-Mobile US, Comcast, AWS, Google).
  • Enterprise LAN is still mostly IPv4 (95%+) with creeping IPv6.
  • Legacy industrial / SCADA / financial systems may never go to IPv6.
  • The internet runs both — most public sites are dual-stack.

So the transition isn’t “throw the switch.” It’s a multi-decade overlap where every protocol must work during the migration. That’s what transition mechanisms are for.

The three approaches

ApproachWhat it doesWhen to use
Dual-stackRun IPv4 and IPv6 simultaneously on the same device / linkThe default. Use everywhere you can.
TunnelingEncapsulate one protocol inside the other to cross a non-supporting transitWhen the path between two endpoints doesn’t support the protocol you need
TranslationRewrite headers between IPv4 and IPv6 (NAT64)When an endpoint only speaks one and must reach the other

You’ll see all three in real networks. None replaces the others — they complement.

1. Dual-stack

Every device runs both IPv4 and IPv6 stacks. Each interface has both an IPv4 address and an IPv6 address. DNS returns AAAA (IPv6) and A (IPv4) records; the client picks (usually IPv6 first via “Happy Eyeballs”).

R1(config)# ipv6 unicast-routing               ! enable IPv6 globally
R1(config)# interface Gi0/1
R1(config-if)# ip address 10.0.0.1 255.255.255.0
R1(config-if)# ipv6 address 2001:db8:1::1/64
R1(config-if)# ipv6 enable

That’s literally it — every IPv4 routing protocol has an IPv6 cousin (OSPFv2 → OSPFv3, EIGRP for IPv6, etc.) and each runs independently.

Pros: Cleanest. Each protocol works natively. No encapsulation overhead. Cons: Both stacks consume resources. Double the policy work — every ACL written twice.

This is the default strategy for any new deployment in 2026. Tunnel/translate only when dual-stack isn’t possible.

2. Tunneling — IPv6 over IPv4 (or vice versa)

When your sites speak IPv6 but the transit between them only routes IPv4, you wrap IPv6 packets inside IPv4 packets for the journey.

Manual IPv6-in-IPv4 (6in4)

R1(config)# interface Tunnel0
R1(config-if)# tunnel mode ipv6ip               ! IPv6 over IPv4
R1(config-if)# tunnel source Gi0/1              ! local IPv4
R1(config-if)# tunnel destination 198.51.100.5  ! remote IPv4
R1(config-if)# ipv6 address 2001:db8:99::1/64

Predictable, simple. Manual configuration for each tunnel — doesn’t scale to thousands.

GRE for IPv6

GRE can carry IPv6 too — see GRE Tunnels. Use when you also want to carry multicast or other non-IP protocols.

R1(config)# interface Tunnel0
R1(config-if)# tunnel mode gre ip
R1(config-if)# ipv6 address 2001:db8:99::1/64

6to4 (deprecated)

A historical “auto” mechanism that mapped IPv4 to a special 2002::/16 block. Largely deprecated due to reliability issues with the public relay infrastructure. Recognize the name; don’t deploy.

Teredo (deprecated)

NAT-traversing UDP-encapsulated IPv6. Microsoft pushed it for home users a decade ago. Now disabled by default in modern Windows. Don’t use.

ISATAP

Intra-Site Automatic Tunnel Addressing Protocol. Used inside a single site to give IPv4-only hosts IPv6 connectivity via a router. Edge case; rarely seen.

DMVPN / FlexVPN

Modern alternative to manual tunnels — Dynamic Multipoint VPN can carry IPv6 over IPv4 underlay (and the reverse). The standard for scaled deployments.

3. Translation — NAT64 / DNS64

When you have IPv6-only clients that need to reach IPv4-only services (the case at every IPv6-only mobile carrier today), translation is the answer.

NAT64

A NAT64 gateway statefully translates between IPv6 and IPv4 packets — like classic NAT (see NAT) but across address families.

The well-known prefix for NAT64 is 64:ff9b::/96. IPv4 addresses are embedded in the last 32 bits:

IPv4: 198.51.100.10
IPv6: 64:ff9b::198.51.100.10  =  64:ff9b::c633:640a

The NAT64 gateway sees 64:ff9b::c633:640a come in, extracts the embedded IPv4 (198.51.100.10), opens an IPv4 socket, and forwards. Return traffic gets reassembled into IPv6 toward the client.

Gateway(config)# nat64 prefix stateful 64:ff9b::/96
Gateway(config)# interface Gi0/0
Gateway(config-if)# nat64 enable
Gateway(config)# nat64 v4 pool MY-POOL 198.51.100.100 198.51.100.110
Gateway(config)# nat64 v6v4 list NAT64-ACL pool MY-POOL

DNS64

NAT64 alone doesn’t help if the client doesn’t know the synthesized IPv6 address. DNS64 is the trick:

  1. IPv6-only client asks DNS for legacy-server.example.com AAAA record.
  2. No AAAA exists. DNS64 server checks for an A record.
  3. A record found (198.51.100.10).
  4. DNS64 synthesizes a fake AAAA: 64:ff9b::c633:640a and returns it.
  5. Client connects to the synthesized IPv6.
  6. Path leads to NAT64 gateway. Gateway extracts the embedded IPv4 and forwards.

The client thinks the world is IPv6. The legacy service thinks it’s getting IPv4. Both are right.

This is how T-Mobile US works for the millions of phones it gives only IPv6 — they reach the IPv4 internet via carrier-grade NAT64+DNS64.

Which to pick — 2026 reality

Scenario                                  Best choice
─────────────────────────────────────────────────────
New green-field LAN                       Dual-stack
Mature IPv4 LAN, gradual IPv6 rollout     Dual-stack (start internal)
IPv6 islands over IPv4 transit            Tunnel (GRE or DMVPN)
IPv6-only carrier serving mixed internet  NAT64 + DNS64
Legacy app that only speaks IPv4          Stay dual-stack until app is upgraded

The non-decision: Don’t pick a transition mechanism in isolation. They layer:

  • LAN is dual-stack.
  • WAN may tunnel IPv6 inside MPLS underlay.
  • Mobile users come in as IPv6-only, NAT64 handles their IPv4 needs.

All three can coexist in one network.

Verification

R1# show ipv6 interface brief
R1# show ipv6 route
R1# show ipv6 neighbors
R1# show interface Tunnel0
R1# show nat64 statistics
R1# show nat64 translations

DNS64 testing from the client: query an A-record-only domain via the DNS64 server, expect a synthesized AAAA back.

Common mistakes

  1. IPv6 enabled but no ipv6 unicast-routing. Interfaces are configured, neighbors form, but the router won’t actually forward IPv6 between them. Easy to miss.

  2. MTU surprise with tunnels. IPv6 in IPv4 has 40 bytes of overhead vs 20 for plain IPv4 — combined with GRE/IPsec you can blow past 1500 MTU. Configure tunnel mtu 1400 or ipv6 tcp adjust-mss 1360 to avoid black-holing.

  3. Treating link-local as a routable address. Link-locals (fe80::/10) only work within a single link. Use globals or ULAs for end-to-end.

  4. Dual-stack without dual-stack DNS. Server has AAAA but client gets only A → uses IPv4. Make sure recursive resolvers serve AAAA records correctly.

  5. NAT64 without DNS64. Without DNS synthesis, IPv6 clients don’t know to send to the NAT64 prefix. Must deploy them together.

  6. Forgetting policy for both protocols. New ACL? Write the IPv6 version too. New QoS classification? Both. New firewall rule? Both. Every “I forgot the IPv6 side” is a future incident.

  7. Deprecated mechanisms still around. 6to4 and Teredo are unreliable. If you find them in old configs, plan to retire — they’re more trouble than they’re worth.

  8. Privacy extensions surprises. IPv6 hosts often generate randomized addresses (RFC 4941). ACLs that pin policy to a specific IPv6 address break on rotation. Use DHCPv6 with reserved addresses or rely on link-local + MAC.

Lab to try tonight

  1. Build two routers connected via a router-on-stick or simple link. Enable dual-stack on both.
  2. Configure IPv4 and IPv6 addresses on the interconnect. Run OSPFv2 for IPv4 and OSPFv3 for IPv6. Verify both reachabilities.
  3. Add a GRE tunnel between two hosts using only IPv4 transport. Configure IPv6 addresses on the tunnel. Run IPv6 routing across it.
  4. Add a third host that’s IPv6-only. Add a NAT64 gateway. Configure DNS64 (dnsmasq on Linux has a --dns64-prefix option).
  5. From the IPv6-only host, browse to an IPv4-only website. Watch the gateway translate.
  6. Bonus: capture with Wireshark and verify the IPv4 ↔ IPv6 packet rewrite.
  7. Bonus: configure tunnel mtu carefully to avoid fragmentation. Test with ping of varying sizes.

Cheat strip

MechanismWhat it does
Dual-stackRun IPv4 + IPv6 simultaneously. Default for new deployments.
Manual 6in4 tunnelIPv6 inside IPv4 packet — fixed endpoints
GRE for IPv6Generic tunnel that can carry IPv6 + multicast + other
6to4Auto-tunnel using 2002::/16deprecated
TeredoUDP-encapsulated IPv6 through NAT — deprecated
ISATAPIntra-site IPv6 over IPv4 — rare in 2026
NAT64Stateful header translation IPv6 ↔ IPv4
DNS64Synthesize fake AAAA from real A records so IPv6 client knows where to go
64:ff9b::/96Well-known NAT64 prefix
MTU gotchaTunnels add overhead — adjust MTU/MSS
CCNA depthKnow names, recognize patterns, understand dual-stack as the default
Master this on a real network

Want this drilled into reflex?

1:1 weekly sessions, live feedback on your labs, and US interview prep — built around the CCNA® exam blueprint. Free first session. No card on file until you decide.

Claim my free session →

One topic per email, every fortnight

VLANs, OSPF, ACLs, subnetting, automation — written like this. Unsubscribe in one click.

We respect your inbox. One email per week, max. Unsubscribe any time.

Start typing — or browse popular topics below.

↑↓ navigate open Searches topics · labs · programs · pages