IPv6 Migration: Dual-Stack, Tunneling, and NAT64

Why Migrate Now#

IPv4 address exhaustion is real. All regional internet registries have depleted their pools. Organizations pay premium prices for small IPv4 blocks while IPv6 address space remains free. Beyond addressing, IPv6 eliminates NAT complexity, simplifies routing, and increasingly becomes a competitive requirement as major platforms prioritize IPv6 traffic.

The business case is straightforward: your users are already on IPv6 networks (mobile carriers, cloud providers, modern ISPs), but you might not be ready to serve them efficiently. Apple requires IPv6 support for iOS apps. Google ranks IPv6-enabled sites slightly higher. IPv6 traffic grows 25-30% annually.

Three Migration Approaches#

IPv6 migration isn't one-size-fits-all. You have three fundamental strategies:

Most production networks use dual-stack. Tunneling serves as a temporary bridge. Translation handles edge cases where protocols must interoperate.

Dual-Stack Deployment#

Dual-stack means every network device speaks both protocols. A server has an IPv4 address (192.0.2.10) and an IPv6 address (2001:db8::10). Applications choose which protocol to use based on destination and preference.

┌─────────────────────────────────┐
│      Application Layer          │
├─────────────────────────────────┤
│  TCP/UDP (Protocol Agnostic)    │
├──────────────┬──────────────────┤
│  IPv4 Stack  │   IPv6 Stack     │
│  192.0.2.10  │  2001:db8::10    │
└──────────────┴──────────────────┘
         │              │
    IPv4 Network   IPv6 Network

Advantages#

Dual-stack creates zero compatibility problems. IPv4-only clients continue working normally. IPv6 clients get native connectivity. You migrate at your own pace without service disruption or coordination with external parties.

Network architecture simplifies over time. As IPv6 adoption grows, you can deprecate IPv4 services gradually. No flag day. No migration weekend. Just steady progress.

Implementation Steps#

1. Verify Hardware Support

Check that routers, switches, and firewalls support IPv6. Most enterprise equipment from the last decade does, but verify firmware versions. Some older devices need updates.

2. Design Your Addressing Scheme

Request a /48 or larger prefix from your ISP (or RIR for large organizations). Plan your subnet structure. Unlike IPv4's rigid subnetting, use /64 for all LANs—the standard subnet size that enables SLAAC.

Example allocation for a /48:

2001:db8:0100::/48  - Received from ISP
2001:db8:0100:0001::/64  - Data center servers
2001:db8:0100:0002::/64  - Office LAN
2001:db8:0100:0003::/64  - Guest network
2001:db8:0100:0010::/64  - DMZ

This hierarchical structure makes routing aggregation simple and provides room for growth.

3. Configure Network Infrastructure

Enable IPv6 routing on border routers. Configure router advertisements (SLAAC) or DHCPv6 for address assignment. Update firewall rules—this is critical and often forgotten.

4. Deploy to Servers

Start with low-risk services. Add AAAA DNS records. Test thoroughly before moving to production services. Monitor both IPv4 and IPv6 traffic patterns.

5. Enable Client Connectivity

Modern operating systems handle dual-stack automatically. SLAAC configures addresses without DHCP. Clients receive both IPv4 (via DHCP) and IPv6 (via SLAAC) addresses and choose appropriately.

Happy Eyeballs: Protocol Selection#

RFC 8305 defines "Happy Eyeballs," the algorithm modern systems use to choose between IPv4 and IPv6. Understanding this helps debug connectivity issues.

The process:

1. DNS lookup returns both A (IPv4) and AAAA (IPv6) records
2. System attempts IPv6 connection first
3. After 50-250ms (implementation-specific), starts IPv4 attempt in parallel
4. First successful connection wins
5. Result cached for subsequent connections to same host

This ensures users get the best available connectivity without noticeable delay. IPv6 gets preference, but IPv4 remains a fallback.

You can test this behavior with our IPv6 ping tool. Compare response times for dual-stack destinations.

Tunneling Mechanisms#

Tunneling wraps IPv6 packets inside IPv4, allowing IPv6 connectivity across IPv4-only infrastructure. Think of it as a temporary workaround, not a permanent solution.

Original: [IPv6 Header | Data]
Tunneled: [IPv4 Header | IPv6 Header | Data]

6in4: Manual Tunnels#

The simplest tunneling method. Configure two endpoints manually, and IPv6 packets flow through IPv4 networks as protocol 41 (not UDP or TCP—raw IP protocol 41).

Linux configuration example:

# Create tunnel interface
ip tunnel add he-ipv6 mode sit remote 209.51.161.14 local 203.0.113.50 ttl 255

This creates a SIT (Simple Internet Transition) tunnel to a remote endpoint.

# Assign IPv6 address (from tunnel broker)
ip addr add 2001:470:1f0a:1ab::2/64 dev he-ipv6
 
# Set link up
ip link set he-ipv6 up

These commands configure the tunnel interface with an IPv6 address.

# Add default IPv6 route
ip route add ::/0 dev he-ipv6
 
# Verify
ping6 google.com

Key points:

• Protocol 41 must pass through firewalls/NAT (often blocked)
• Tunnel endpoints need static IPv4 addresses
• Hurricane Electric and other tunnel brokers provide free endpoints
• Adds ~10-30ms latency depending on tunnel broker location

6rd: ISP Rapid Deployment#

6rd lets ISPs provide IPv6 to customers over existing IPv4 infrastructure. The ISP runs relay servers, and customer routers automatically tunnel IPv6 traffic.

Unlike 6to4, 6rd uses ISP-specific prefixes and ISP-controlled relays, making it more reliable and secure. You won't configure this manually—it's provisioned automatically if your ISP supports it.

DS-Lite: IPv4 over IPv6#

DS-Lite reverses the typical scenario: it provides IPv4 connectivity over an IPv6-only network. Used by ISPs transitioning to IPv6-only infrastructure while maintaining IPv4 service.

Customer ----[IPv4-in-IPv6]----> ISP AFTR ----[IPv4]----> Internet

Customer equipment (B4 element) tunnels IPv4 inside IPv6 to the ISP's AFTR (Address Family Transition Router), which performs NAT44 before forwarding to the IPv4 Internet.

End users typically don't configure DS-Lite—it's managed by the ISP.

Translation Technologies#

Translation converts packets between IPv6 and IPv4 at the network layer. This enables communication when one side is IPv6-only and the other is IPv4-only.

NAT64 with DNS64#

NAT64 translates IPv6 packets to IPv4 and vice versa. Combined with DNS64, it provides transparent access to IPv4-only services from IPv6-only networks.

How it works:

1. IPv6-only client queries DNS for ipv4only.example.com
2. DNS64 server sees only A record (IPv4), no AAAA record (IPv6)
3. DNS64 synthesizes AAAA record using NAT64 prefix: 64:ff9b::198.51.100.5
4. Client sends packet to synthesized IPv6 address
5. NAT64 gateway translates to IPv4 and forwards
6. Return traffic translated back to IPv6

┌─────────────┐         ┌─────────────┐         ┌─────────────┐
│ IPv6 Client │         │   NAT64     │         │ IPv4 Server │
│             │─────────│   Gateway   │─────────│             │
│2001:db8::1  │  IPv6   │  + DNS64    │  IPv4   │198.51.100.5 │
└─────────────┘         └─────────────┘         └─────────────┘

Well-known NAT64 prefix: 64:ff9b::/96 (RFC 6052)

NAT64 requires stateful translation—the gateway maintains session state like traditional NAT44. This introduces the same scaling concerns as IPv4 NAT.

464XLAT: Enabling IPv4 Apps#

464XLAT extends NAT64 by adding client-side translation (CLAT), allowing IPv4-only applications to work on IPv6-only networks.

┌──────────────┐      ┌──────────────┐      ┌──────────────┐
│ IPv4 App     │      │              │      │ IPv4 Server  │
│              │      │ IPv6-only    │      │              │
│ 192.0.0.1    │      │ Network      │      │ 198.51.100.5 │
└──────┬───────┘      └──────────────┘      └──────────────┘
       │                                             │
    CLAT (device)                              PLAT (ISP)
    NAT46                                       NAT64

Mobile networks extensively use 464XLAT. Your phone runs an IPv6-only stack, but legacy IPv4-only apps still work transparently. Android and iOS both support CLAT natively.

Choosing Your Strategy#

Decision framework based on network characteristics:

Have native IPv6 from ISP?
   │
   ├─ YES ──> Deploy dual-stack (recommended)
   │          1. Enable IPv6 on border router
   │          2. Configure SLAAC/DHCPv6
   │          3. Update firewall rules
   │          4. Add AAAA records to DNS
   │
   └─ NO ──> Need IPv6 immediately?
              │
              ├─ YES ──> Use tunnel broker
              │          (Hurricane Electric, etc.)
              │
              └─ NO ──> Request IPv6 from ISP
                        or plan migration timeline

Strategy Selection Matrix#

Common Pitfalls#

1. Incomplete Firewall Configuration#

IPv6 traffic often bypasses IPv4 firewall rules. Security teams configure extensive IPv4 policies but forget IPv6 entirely. Result: unfiltered IPv6 connectivity.

Solution: Apply equivalent security policies to both protocols. If you block port 23 (telnet) on IPv4, block it on IPv6. Use stateful inspection for both.

2. DNS Misconfigurations#

Publishing AAAA records without working IPv6 connectivity breaks access for IPv6-enabled clients. Happy Eyeballs helps, but causes delays and fallback to IPv4.

Solution: Only publish AAAA records after verifying IPv6 connectivity works. Monitor both A and AAAA query patterns. Configure reverse DNS (PTR records) for IPv6 addresses.

3. Application Compatibility Issues#

Applications that hardcode IPv4 assumptions fail with IPv6:

• Storing IP addresses in 32-bit integers
• Regex patterns matching only IPv4 format
• Not bracketing IPv6 addresses in URLs: http://[2001:db8::1]:8080/
• Binding to 0.0.0.0 instead of :: (IPv6 wildcard)

Solution: Test applications thoroughly with IPv6-only connectivity. Use dual-stack test environments. Review code for IPv4 assumptions.

4. Monitoring Blind Spots#

Network monitoring often tracks IPv4 metrics but ignores IPv6. You won't notice if IPv6 connectivity degrades or fails entirely.

Solution:

• Monitor IPv6 and IPv4 traffic separately
• Set up IPv6-specific health checks
• Track protocol preference distribution (what percentage of traffic uses IPv6)
• Alert on IPv6 availability issues

Start Simple#

Begin with dual-stack on non-critical systems. A test server, development environment, or internal tool. Verify IPv6 connectivity works. Add AAAA records. Monitor traffic.

Once comfortable, expand to production services. Most modern infrastructure supports IPv6 with minimal configuration. The technical migration is straightforward—organizational change and thorough testing take longer.

Tunneling serves as a temporary bridge if you can't get native IPv6 immediately. But push your ISP for native support. Translation handles edge cases but shouldn't be your primary strategy.

IPv6 adoption continues accelerating. Starting now, even incrementally, positions your network for the future while your competitors scramble to catch up later.

Related Articles#

• How to Enable IPv6 - Practical steps for enabling IPv6 on your systems
• Dual-Stack Guide - Running IPv4 and IPv6 together
• Enterprise Migration - Planning large-scale IPv6 deployment

Frequently Asked Questions#