IPv6 Transition

The Internet is running two incompatible protocols at once, and has been for over twenty years.

IPv4 and IPv6 don't just use different address formats—they're mutually unintelligible. An IPv4 packet arriving at an IPv6-only host is like a letter in a language nobody reads. The packet isn't malformed or corrupted. It's just... incomprehensible.

This incompatibility is why the IPv6 transition isn't a migration. It's a decades-long coexistence, managed through a collection of bridges, tunnels, and translators that let two separate Internets pretend they're one.

The Exhaustion That Started Everything

IPv4 address exhaustion isn't theoretical—it happened. The global pool ran out in 2011. Regional registries followed. Today, new networks can't get IPv4 addresses without buying them from someone else, and prices keep climbing.

IPv6 provides 340 undecillion addresses—340 trillion trillion trillion. That's enough to give every atom on Earth's surface its own address and still have room left over. Scarcity solved.

But you can't just switch. Every router, every host, every piece of software that speaks IPv4 needs to also speak IPv6—or something needs to translate. And "everything" is a lot of things.

Dual Stack: Speaking Both Languages

The simplest approach: teach everything both protocols.

A dual-stack host has an IPv4 address and an IPv6 address. When it needs to connect somewhere, it asks DNS for both A records (IPv4) and AAAA records (IPv6). If both exist, it prefers IPv6. If IPv6 fails, it falls back to IPv4.

This works beautifully. IPv6 traffic flows natively over IPv6. IPv4 traffic flows natively over IPv4. Nothing breaks.

The catch: you still need IPv4 addresses for everything. Dual stack doesn't solve scarcity—it just delays the problem while IPv6 adoption grows.

Happy Eyeballs: Fast Fallback

Dual stack creates a subtle problem: what if IPv6 is broken?

Maybe your ISP advertises IPv6 but doesn't route it properly. Maybe a firewall somewhere drops IPv6 packets. If your device tries IPv6 first and waits for timeout before trying IPv4, you'll stare at a loading spinner for thirty seconds before the page loads.

Happy Eyeballs (RFC 8305) fixes this. Your device starts connecting over IPv6, then after 250 milliseconds—before IPv6 has time to fail slowly—starts a parallel IPv4 attempt. Whichever succeeds first wins.

Users never notice. They just get fast connections, regardless of which protocol actually worked. The "happy eyeballs" are the user's, not staring at a spinner.

Tunneling: IPv6 Through IPv4 Pipes

Sometimes you have IPv6 islands separated by IPv4 oceans. Your office has IPv6. Your data center has IPv6. But the connection between them only speaks IPv4.

Tunneling wraps IPv6 packets inside IPv4 packets—like putting a letter inside another envelope. The outer envelope gets the packet across the IPv4 network. At the other end, the outer envelope is removed, revealing the IPv6 packet inside.

Various tunneling protocols emerged over the years: 6to4, 6in4, ISATAP, Teredo. Most are now deprecated. They were bridges built for a transition that was supposed to be faster. Twenty years later, native dual-stack and purpose-built translation have largely replaced them.

Translation: Protocol Interpreters

What if you want to run IPv6-only but still reach IPv4 servers?

NAT64 acts as an interpreter. Your IPv6-only device sends packets to a special IPv6 address. The NAT64 gateway receives them, translates to IPv4, and forwards to the IPv4 destination. Return traffic gets translated back.

But there's a problem: how does your IPv6-only device know the IPv6 address to use for an IPv4-only server? That server only has an A record (IPv4), not a AAAA record (IPv6).

DNS64 synthesizes the answer. When your device queries for a domain and only gets an A record back, DNS64 manufactures a AAAA record pointing through the NAT64 gateway. Your device thinks it's talking IPv6 end-to-end. The translation is invisible.

Together, NAT64 and DNS64 let IPv6-only networks access the entire IPv4 Internet. The IPv6-only device never knows it's crossing a protocol boundary.

464XLAT: When Apps Need Real IPv4

Some applications are stubborn. They don't use DNS—they connect to hardcoded IPv4 addresses. Or they do things with sockets that assume IPv4. NAT64 can't help them because they never ask DNS for an address to translate.

464XLAT adds client-side translation. Your device runs a local translator (CLAT) that gives apps a fake IPv4 interface. Apps think they're using IPv4. The CLAT translates to IPv6, sends across the IPv6 network, where NAT64 (the PLAT) translates back to IPv4 for the destination.

Two translations, one at each end, letting IPv4-only apps work on IPv6-only networks. It's elaborate, but it works.

Why Mobile Networks Love IPv6

Mobile carriers were among the first to embrace IPv6, and for practical reasons: Carrier-Grade NAT is painful.

When you don't have enough IPv4 addresses for all your customers, you share them. Thousands of phones behind a single public IPv4 address. This breaks apps that need incoming connections, complicates troubleshooting, and creates legal headaches when someone does something illegal from a shared address.

IPv6 lets carriers give every device a globally unique address. No NAT. No sharing. Every phone directly addressable. Peer-to-peer apps work. Troubleshooting works. The carrier's life gets simpler.

Most mobile networks now run IPv6-only internally, with NAT64 for IPv4 access. Your phone probably uses IPv6 more than you realize.

The Chicken and the Egg

IPv6 deployment faces a genuinely absurd coordination problem.

Content providers don't deploy IPv6 because most users don't have it—why spend money supporting a protocol only 40% of visitors can use?

Users don't deploy IPv6 because most content doesn't require it—everything works fine over IPv4, so why bother?

Everyone's waiting for everyone else. This is why the transition has taken over two decades and will take decades more.

The providers who did deploy IPv6—Google, Facebook, Netflix, major ISPs—did so because they could see the long-term necessity, or because IPv4 address costs forced their hand. But critical mass comes slowly when there's no immediate penalty for waiting.

What Slows Adoption

Beyond the coordination problem:

Legacy equipment. Routers and firewalls that can't do IPv6, or can but poorly. Replacement costs money.

Training gaps. Engineers who learned IPv4 twenty years ago and haven't needed IPv6 since. New skills cost time.

Application assumptions. Code that stores IP addresses in 32-bit integers. Regex that validates "IP addresses" by counting dots. Software that just... assumed IPv4 forever.

Security uncertainty. IPv6 is different enough that security teams worry about unknown unknowns. Better the devil you know.

Despite all this, adoption grows. Some measurements show over 40% of users reaching major services via IPv6. Many large networks handle majority IPv6 traffic. The transition is slow, but it's happening.

IPv6-Only Networks

The logical endpoint: stop running IPv4 entirely.

Some newer deployments—mobile networks, cloud data centers—are built IPv6-only from the start. NAT64/DNS64 provides IPv4 access. 464XLAT handles stubborn apps. Native IPv6 handles everything else.

This eliminates IPv4 address costs and simplifies network operations. One protocol stack instead of two. One set of firewall rules. One address plan.

The catch: you're betting that translation handles everything. Most traffic works fine. But edge cases exist, and when they break, debugging crosses protocol boundaries.

The Long Coexistence

IPv6 deployment began in the 1990s. We're still transitioning.

This isn't failure—it's the natural pace of changing something as fundamental as Internet addressing. Every device, every application, every network must eventually support IPv6. That's billions of things, upgraded on thousands of different timelines by millions of different organizations.

Dual-stack operation will likely persist for decades. Some networks may never fully eliminate IPv4 if legacy systems require it indefinitely. The practical reality is a hybrid Internet where both protocols coexist, connected by bridges that let them interoperate.

The transition isn't a project with an end date. It's an ongoing state of the Internet, managed rather than completed.