Google's IPv6 hits 50%. The transition that wouldn't die just won.

What happened

APNIC's blog flagged what the protocol nerds have been refreshing Google's stats page for: the IPv6 adoption counter at google.com/intl/en/ipv6/statistics.html tipped past 50%. For the first time in the public internet's history, a majority of users reaching one of the world's most-trafficked properties are doing so over IPv6, not IPv4.

Google's measurement is the de facto industry yardstick because it samples actual end-user connections to Google services rather than route announcements or allocations. The methodology is unglamorous — a small JavaScript probe served to a fraction of visitors that attempts both IPv4 and IPv6 fetches, with the per-country breakdown rolled up daily. The number has been climbing roughly linearly at 4-5 percentage points per year since 2018. France crossed 75% years ago. India is over 80%. Germany sits around 72%. The United States hovers in the high 50s, dragged up by mobile carriers (T-Mobile US has been IPv6-only on its cellular core since 2015) and down by enterprise networks that still treat IPv6 as a 2027 problem.

The RFC for IPv6 — RFC 1883, later obsoleted by RFC 2460 and then RFC 8200 — was published in December 1995. World IPv6 Launch was June 6, 2012. So the headline is: it took 31 years from spec to majority deployment, and 14 years from the coordinated marketing push.

Why it matters

For most of the last decade, the standard developer take on IPv6 was some variant of "we'll get to it." That position is now actively expensive. The growth isn't coming from enterprise IT finally reading the memo — it's coming from mobile carriers who ran out of RFC 1918 space inside their own networks and went IPv6-only with NAT64/464XLAT translation at the edge. If your service is IPv4-only, those users reach you through a carrier-grade NAT that mangles source ports, breaks connection reuse, and adds 10-40ms of latency on the translation hop. They show up in your logs as a handful of IPs hammering your rate limiter.

The other quiet driver is hyperscaler economics. AWS started charging $0.005/hour per public IPv4 address in February 2024 — about $43/year per IP. Multiply that by a fleet of NAT gateways, load balancers, and EC2 instances and the IPv4 bill becomes a line item leadership notices. Azure and GCP have followed with their own IPv4 surcharges. Meanwhile IPv6 addresses on all three clouds remain free. The economic gradient that used to favor "just stay on v4" reversed two years ago; the org charts are catching up.

Community reaction on Hacker News (125 points) split along predictable lines. The protocol veterans treated it as vindication — Geoff Huston has been writing "IPv6 is happening, slowly" essays at APNIC for fifteen years and is finally allowed a victory lap. The skeptics pointed out, correctly, that "50% of Google users" is not the same as "50% of the internet," because Google's user base skews mobile and skews toward countries with aggressive carrier deployments. Cloudflare's radar puts the global figure closer to 40%. APNIC's own ASN-level measurement is in the same range. Whichever number you trust, the slope is the same and the trend line crosses every reasonable threshold within the next 36 months.

The more interesting argument in the thread was about what the transition actually looks like in 2026. Nobody is turning off IPv4 — the long tail of embedded devices, ATM networks, point-of-sale terminals, and "we shipped it in 2009 and the customer signed off" infrastructure will be dual-stacked for another decade. The question is which protocol is the default code path and which is the compatibility shim. For a growing share of the internet, IPv4 is now the shim.

What this means for your stack

Three concrete implications worth acting on this quarter.

First, audit whether your service is actually reachable on IPv6. Not "we have AAAA records" — actually reachable. The common failure modes: your load balancer terminates IPv6 but your origin is IPv4-only and the health check passes anyway; your CDN serves AAAA but your WAF rules are written against IPv4 CIDR blocks and silently drop v6 traffic; your rate limiter buckets by /32 and a single mobile user behind a /64 allocation looks like 18 quintillion attackers. If you don't have an IPv6 column in your observability stack, you don't actually know what your IPv6 users are experiencing.

Second, revisit your IP-based logic. Geo-IP databases for IPv6 are sparser than for IPv4 — MaxMind's GeoLite2 has full coverage but accuracy degrades for /48 and /56 allocations. Fraud-detection systems that key on "this IP has been seen before" need rethinking because a single subscriber on a residential ISP might rotate through a /64 daily. Allowlists, denylists, and "trusted IP" patterns written for IPv4 don't transfer cleanly. The cleanest mental model is: treat the /64 as the unit of identity, not the /128.

Third, if you're on AWS and still running NAT gateways purely to give private subnets outbound IPv4 to talk to v4-only third-party APIs, you're now in the awkward middle. Egress-only Internet Gateways for IPv6 are free; NAT gateways are not. The migration isn't free either — but the cost-benefit calculation that said "leave it" in 2022 says "plan it" in 2026.

Looking ahead

The interesting question for the next 36 months isn't whether IPv6 wins — that's decided — but how the IPv4 long tail gets managed. Expect to see more cloud providers offering IPv4-as-a-service: a pool of shared addresses you rent by the hour for the specific case of reaching a legacy endpoint. The protocol that was supposed to replace IPv4 is now the default, and IPv4 is becoming the paid premium feature. Somewhere, the people who paid $40,000 for a /22 block in 2019 are recalculating their ROI.