IPv6 at 50%: the leapfrog economies got there first, China didn't

What happened

APNIC's measurement of Google's client-side traffic crossed the 50% IPv6 mark this week — meaning that for the first time, more than half of the requests reaching Google's edge arrive over IPv6. The methodology is the same one Geoff Huston's team has run for over a decade: a 1×1 pixel served from Google's ad network probes the client's stack and reports which protocol wins. It's the closest thing the industry has to a real-world adoption meter, because it's measured at users, not at routers.

The headline number — 50% — is the least interesting thing about the data. The per-country breakdown is what tells the actual story. India sits near 80%. France clears 75%. Germany and Saudi Arabia are in the low 70s. The United States is around 55%. The United Kingdom is in the mid-40s. Japan is roughly even with the US. China — depending on whose measurement you trust — sits anywhere from single digits (APNIC's external view) to the 30s (CNNIC's internal view). Russia is under 10%. Most of sub-Saharan Africa is under 5%.

This is the most geographically uneven infrastructure transition in the history of the internet, and it has been that way for years. The 50% milestone is just when the unevenness became impossible to round off.

Why it matters

The instinct is to assume the rich, early-internet countries lead and the rest follow. IPv6 is the opposite: the countries that got the internet last are the ones that got off IPv4 first. Reliance Jio launched in 2016 as an IPv6-first carrier because they could not get enough IPv4 to serve 400 million subscribers — APNIC had run out of /8s five years earlier, and the secondary market was already pricing addresses at $20-30 each. Building IPv6-only with NAT64 for legacy services was cheaper than buying their way into a depleted pool. France's Free Mobile made the same calculus. T-Mobile US did too — their 5G core has been IPv6-only since 2014, with 464XLAT translating IPv4 traffic at the edge.

The countries lagging are the ones that hoarded /8s in the 1980s. The US Department of Defense alone holds 13 /8s — about 218 million addresses, more than India was allocated for its entire population. When you have that much IPv4, the forcing function to migrate never arrives. Comcast's residential network is the rare US exception (IPv6 default since around 2014), and even then the enterprise side of the same companies sits on IPv4-only VPCs.

The community reaction on the APNIC blog and HN reflected this split: every comment from someone running infrastructure in Asia treated 50% as old news, while every comment from someone running US enterprise treated it as aspirational. One commenter noted that their Indian fintech employer had been IPv6-only internally since 2019 and was now starting to bill IPv4 access as a cost center. Another from a US healthcare network admitted they had never run an IPv6 test in production.

The other underappreciated detail: mobile carriers are now the dominant driver, not residential broadband. India's number is high because mobile is the internet there. France's Free is similar. The US number would be 20 points lower without T-Mobile and Verizon Wireless dragging it up. If your traffic is consumer-mobile-heavy, you are already serving the IPv6 majority and just haven't measured it.

What this means for your stack

Three concrete things changed at 50% that didn't matter at 40%.

First, happy-eyeballs latency is now your problem, not your ISP's. RFC 8305 says clients should race A and AAAA lookups and prefer whichever connects first, with a 50ms head start to IPv6. When IPv6 is the minority path, a slow AAAA record costs you a few users. When it's the majority path, a slow AAAA record is your p50. If your CDN's IPv6 PoP is one hop further than its IPv4 PoP — and several still are — that's now visible in your RUM data. Check it.

Second, IPv4 is becoming a billable resource. AWS started charging $0.005/hour per public IPv4 address in 2024 — about $43/year per address. EKS clusters that allocate dozens of public IPv4 endpoints per cluster are seeing five-figure annual line items that did not exist 24 months ago. Cloudflare, Fastly, and Vercel are all quietly building IPv6-only egress paths because the IPv4 transit cost is becoming a meaningful percentage of their gross margin. The IPv6 transition isn't being driven by RFC compliance anymore — it's being driven by the IPv4 line item on the AWS bill.

Third, your observability stack probably lies about IPv6. Most application logs truncate or normalize IPv6 addresses into something that breaks GeoIP joins, abuse detection, and rate limiting. Your WAF rules written against /24 CIDRs do nothing against a client that rotates through a /64. Your fraud team's IP-reputation feed has 10x less signal on an IPv6 address than an IPv4 one, because the address space is too sparse to reuse. The half of your traffic that's IPv6 is operationally invisible in tools designed around IPv4 assumptions.

Looking ahead

The path from 50% to 80% will look nothing like the path from 10% to 50%. The first half was won by mobile carriers and consumer ISPs running out of IPv4 and rebuilding their access networks. The second half has to be won by enterprise — and enterprise has no equivalent forcing function, because AWS will happily sell them another /22 of public IPv4 at $43/address/year forever. The likely accelerant isn't policy, it's cost: when an enterprise's annual IPv4 lease bill crosses the cost of one IPv6 migration engineer, the spreadsheet does the work that RFCs couldn't. Expect that line to be crossed at most large SaaS companies within 18 months. Expect China's APNIC number to keep being argued about. And expect the next milestone — APNIC's measurement of 60% — to arrive a lot faster than 31 years.