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
| Approach | What it does | When to use |
|---|---|---|
| Dual-stack | Run IPv4 and IPv6 simultaneously on the same device / link | The default. Use everywhere you can. |
| Tunneling | Encapsulate one protocol inside the other to cross a non-supporting transit | When the path between two endpoints doesn’t support the protocol you need |
| Translation | Rewrite 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:
- IPv6-only client asks DNS for
legacy-server.example.comAAAA record. - No AAAA exists. DNS64 server checks for an A record.
- A record found (
198.51.100.10). - DNS64 synthesizes a fake AAAA:
64:ff9b::c633:640aand returns it. - Client connects to the synthesized IPv6.
- 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
-
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. -
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 1400oripv6 tcp adjust-mss 1360to avoid black-holing. -
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. -
Dual-stack without dual-stack DNS. Server has AAAA but client gets only A → uses IPv4. Make sure recursive resolvers serve AAAA records correctly.
-
NAT64 without DNS64. Without DNS synthesis, IPv6 clients don’t know to send to the NAT64 prefix. Must deploy them together.
-
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.
-
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.
-
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
- Build two routers connected via a router-on-stick or simple link. Enable dual-stack on both.
- Configure IPv4 and IPv6 addresses on the interconnect. Run OSPFv2 for IPv4 and OSPFv3 for IPv6. Verify both reachabilities.
- Add a GRE tunnel between two hosts using only IPv4 transport. Configure IPv6 addresses on the tunnel. Run IPv6 routing across it.
- Add a third host that’s IPv6-only. Add a NAT64 gateway. Configure DNS64 (
dnsmasqon Linux has a--dns64-prefixoption). - From the IPv6-only host, browse to an IPv4-only website. Watch the gateway translate.
- Bonus: capture with Wireshark and verify the IPv4 ↔ IPv6 packet rewrite.
- Bonus: configure
tunnel mtucarefully to avoid fragmentation. Test withpingof varying sizes.
Cheat strip
| Mechanism | What it does |
|---|---|
| Dual-stack | Run IPv4 + IPv6 simultaneously. Default for new deployments. |
| Manual 6in4 tunnel | IPv6 inside IPv4 packet — fixed endpoints |
| GRE for IPv6 | Generic tunnel that can carry IPv6 + multicast + other |
| 6to4 | Auto-tunnel using 2002::/16 — deprecated |
| Teredo | UDP-encapsulated IPv6 through NAT — deprecated |
| ISATAP | Intra-site IPv6 over IPv4 — rare in 2026 |
| NAT64 | Stateful header translation IPv6 ↔ IPv4 |
| DNS64 | Synthesize fake AAAA from real A records so IPv6 client knows where to go |
64:ff9b::/96 | Well-known NAT64 prefix |
| MTU gotcha | Tunnels add overhead — adjust MTU/MSS |
| CCNA depth | Know names, recognize patterns, understand dual-stack as the default |