Half the Internet Finally Speaks IPv6, and the Story Is Messier Than the Milestone
Source: hackernews
The Google IPv6 statistics page now shows something that seemed perpetually out of reach for most of the past two decades: more than half of all traffic reaching Google’s servers arrives over IPv6. The Hacker News thread hit nearly 600 comments, which tells you something about how long people have been waiting to see this number.
IPv6 was standardized in RFC 2460 in December 1998. The protocol that now carries the majority of Google’s traffic took 28 years to get there. That is not a bug in the process; it is a lesson in how infrastructure transitions actually work at internet scale.
Why IPv4 Lasted This Long
The standard explanation for IPv6’s slow adoption is the chicken-and-egg problem. Content providers would not prioritize IPv6 until users had it; ISPs would not deploy it until content required it. That is true, but it understates the role of NAT.
Network Address Translation was supposed to be a temporary measure. When the IANA exhausted its IPv4 free pool on February 3, 2011, the regional registries followed: APNIC in April 2011, RIPE NCC in September 2012, ARIN in September 2015. The addresses were gone, and yet the internet kept growing. The reason is that NAT made scarcity tolerable. One public IPv4 address can serve thousands of clients behind it. Carrier-Grade NAT (CGNAT) extended this to entire ISP subscriber bases, letting operators defer IPv6 deployment for years.
The cost of that deferral is not just address space. CGNAT breaks many protocols that assume end-to-end reachability: peer-to-peer applications, certain VoIP flows, some gaming protocols. Every TCP connection through a CGNAT box requires state tables on the carrier’s equipment. At scale, that is real hardware, real power, real operational complexity. Eventually, deploying IPv6 and routing around the CGNAT problem becomes cheaper than maintaining it.
What Actually Moved the Needle
The 50% figure did not arrive through a smooth linear climb. Google’s own statistics show uneven adoption, with certain periods of rapid growth corresponding to specific deployments.
The most significant single event was Reliance Jio’s launch in India in 2016. Jio built a greenfield LTE network and deployed IPv6 natively across it. India went from negligible IPv6 adoption to among the highest IPv6 penetration rates in the world, often measured above 60-70% of internet users. Because India has over a billion internet users, this one carrier’s architecture decision materially shifted global statistics.
T-Mobile in the United States made a similar architectural choice for its LTE network, carrying the majority of its traffic over IPv6 for years. Comcast’s residential broadband deployment, Deutsche Telekom in Germany, and Free in France all represent ISPs that went past the tipping point where deploying IPv6 was the path of least resistance rather than an extra project.
On the content and CDN side, the work was largely done earlier. Akamai, Cloudflare, Fastly, and the major cloud providers all added IPv6 support well before 2020. AWS enabled IPv6 for VPCs in 2016. Google Cloud and Azure followed. The CDN and cloud layer being dual-stack meant that any origin server behind them could serve IPv6 traffic without touching its own configuration.
The Technical Architecture That Made the Transition Tolerable
One reason 50% IPv6 traffic could coexist with 50% IPv4 for this long is that the dual-stack transition was designed to be invisible at the application layer. The mechanism that accomplishes this is Happy Eyeballs, now specified in RFC 8305.
The algorithm is straightforward. When a browser resolves a hostname with both A (IPv4) and AAAA (IPv6) records, it initiates a connection attempt over IPv6 first. After a short delay (typically 250ms), if the IPv6 connection has not completed, it begins a parallel IPv4 attempt. Whichever connection establishes first wins; the other is abandoned. The result is that broken IPv6 connectivity adds at most 250ms to page load time on the first connection, and most users never notice anything.
This was a pragmatic concession. Pure IPv6-first would have broken too many things; pure dual-stack with equal preference would have split traffic arbitrarily. Happy Eyeballs gave IPv6 a preference without making it a hard requirement, which allowed deployment to proceed without requiring perfect IPv6 infrastructure everywhere simultaneously.
On the addressing side, IPv6 eliminates the entire NAT layer that creates CGNAT complexity. Every device can have a globally routable address. Stateless Address Autoconfiguration (SLAAC, RFC 4862) lets devices self-configure addresses from a router advertisement prefix without running a DHCPv6 server. Privacy extensions (RFC 4941) generate temporary randomized interface identifiers to prevent tracking via stable MAC-derived addresses, which addressed an early concern about IPv6’s visibility.
The IPv6 header itself is simpler than IPv4 despite the larger address fields. At a fixed 40 bytes with no checksum and no fragmentation at intermediate routers (fragmentation is the sender’s responsibility), routers can forward packets without the variable-length option parsing that IPv4 required. Extension headers handle optional functionality. Whether this theoretical efficiency manifests in real-world router performance has been debated, but the design intention was clear.
What the Remaining 50% Looks Like
The second half of this transition will be harder than the first, for a structural reason: the remaining IPv4-only traffic is concentrated in places where changing is expensive or disruptive.
Enterprise networks are the clearest example. A corporate network that has been running on RFC 1918 private addressing behind a firewall for 20 years has no immediate pressure to change. The network works. The applications work. Adding IPv6 means training network teams, updating firewall rules, auditing applications for IPv6 compatibility, and in many cases replacing hardware. The cost-benefit calculation favors deferral as long as internet access continues to work through dual-stack edge equipment.
Legacy embedded systems present a related problem. Industrial control systems, older IoT devices, and long-lifecycle equipment often run firmware with no IPv6 stack. These devices will remain IPv4 until they are physically replaced, which in some industries is measured in decades.
Small business and home equipment is less of a blocker than it was, since most modern consumer routers support IPv6 and ISPs increasingly enable it by default. But small businesses often have older equipment managed by someone who has no reason to think about address protocols.
The third holdout category is hosting. A significant portion of web servers, databases, and internal services run on addresses that were never meant to be directly reachable, and their operators have not prioritized adding IPv6 listeners. CDNs mask this for publicly served content, but origin-to-origin traffic and internal service meshes often remain IPv4.
What the Milestone Actually Means
Fifty percent is not a finish line; it is the point where the protocol preference has inverted. For the past decade, IPv4 was the assumed default and IPv6 was the secondary path. The statistics now say that, at least for traffic reaching Google, more packets travel over IPv6 than IPv4. The operational assumption in new deployments should shift accordingly.
For anyone building networked software today, the practical implication is to verify that your application binds to IPv6 sockets and that your infrastructure exposes AAAA records. In most stacks this is now the default, but it is worth confirming rather than assuming. Linux’s socket() call with AF_INET6 and IPV6_V6ONLY set to zero will accept both IPv4 and IPv6 connections on a single socket through the IPv4-mapped address mechanism, which simplifies dual-stack server code considerably.
The longer view is that 28 years is about how long major internet infrastructure transitions take. The transition from circuit-switched voice to VoIP took a similar arc. The shift from FTP to HTTP for file distribution was faster but still measured in years. IPv6 reaching 50% is the confirmation that the transition is past the point of reversal, not the announcement that it is complete.