Google's IPv6 share just crossed 50% — the 27-year transition has a midpoint

What happened

On April 28, APNIC's Geoff Huston posted the chart everyone in the routing world has been waiting on for roughly a decade: Google's IPv6 user-measurement counter crossed 50%, meaning half of all clients reaching google.com now do so over IPv6 rather than IPv4. The data comes from Google's own long-running [adoption page](https://www.google.com/intl/en/ipv6/statistics.html), which embeds a tiny dual-stack probe in a fraction of search responses and counts which transport wins the race.

The 50% milestone is global average. The regional breakdown is where the story actually lives. India is sitting at roughly 79% — a number driven almost entirely by Reliance Jio launching as an IPv6-first mobile network in 2016. France is at 76%, propelled by Free and Orange. Germany and Vietnam are both north of 70%. The United States is around 55%, dragged up by T-Mobile and Comcast and dragged down by enterprise. China, despite a five-year state directive, is still under 5%. The United Kingdom is under 15%. Most of Africa is in single digits.

The shape of the curve is the giveaway. RFC 2460 — the original IPv6 spec — was published in December 1998. The first World IPv6 Day was 2011. Google's counter passed 1% in 2012, 10% in 2016, 25% in 2018, and then crawled sideways for years. The acceleration since 2023 is sharp, and it correlates almost perfectly with one specific event: AWS announcing in July 2023 that it would begin charging $0.005 per hour for every public IPv4 address starting February 1, 2024.

Why it matters

IPv6 has been technically ready for shipping production traffic for over a decade. What was missing was a business reason to do the migration. The thing that finally moved the curve wasn't a standards body, a security advisory, or a hyperscaler tutorial — it was a line item on an AWS invoice. A medium-sized fleet of 5,000 public IPv4s is now a $219,000-per-year recurring charge that didn't exist 24 months ago. Finance noticed. Finance told platform. Platform finally allocated a sprint.

The HN thread on Huston's post (371 points, 400+ comments) splits along predictable lines. The operators who run dual-stack networks are matter-of-fact: it works, the tooling has been there for a decade, the hard part was always organizational. The skeptics point out — correctly — that 50% of *Google traffic* is not 50% of *the internet*. Google's measurement is weighted heavily toward consumer mobile, where carrier-grade IPv6 has been the default rollout pattern. The enterprise long tail — internal VPNs, B2B SaaS, government extranets, every appliance with a hardcoded 10.0.0.0/8 — is barely moving.

The other thing the comments surface is that a huge fraction of "IPv6 traffic" is actually IPv4 hidden inside an IPv6 tunnel or vice versa. NAT64, 464XLAT, CGNAT, MAP-T, DS-Lite — the translation layer is the actual production reality, not pure dual-stack. T-Mobile's network is famously IPv6-only on the radio, with 464XLAT translating IPv4 literals at the edge. That's how Google sees a v6 connection; the app on the phone may still think it's talking v4. The clean dual-stack story most architecture diagrams assume is, in practice, a much messier translation mesh.

There's also a quietly important security angle. The first time most enterprises will discover they have IPv6 turned on is when their EDR vendor flags a beacon leaving over an interface their firewall ruleset never covered. Windows enables IPv6 by default. macOS prefers it. Most Linux distros ship it on. If your perimeter ACLs are v4-only, your IPv6 stack is an unmonitored second front door. Several commenters mentioned auditing this after the post — and finding things.

What this means for your stack

The practical implications break into three buckets.

If you're on AWS or GCP, the IPv4 charge is now real and growing — GCP matched AWS's pricing in 2024. The cheapest wins are usually: move egress to NAT Gateway v6, switch internal service-to-service traffic to v6-only inside VPCs, and audit which of your public IPv4s are actually needed versus ones that exist because somebody attached an EIP to an EC2 instance in 2019 and never removed it. The AWS Cost Explorer line `PublicIPv4:InUseAddress` is the number to put in a dashboard.

If you ship a client SDK or CLI, test it under NAT64. The classic failure mode is hardcoded IPv4 literals — STUN servers, fallback DNS, hardcoded `127.0.0.1` checks that fail on `::1`. Happy Eyeballs (RFC 8305) handles the dual-stack race, but only if your code uses `getaddrinfo()` with both families instead of `gethostbyname()` or its language equivalents. Go's `net` package gets this right by default. Python's `socket.create_connection` does. Plenty of older C and Java code does not.

If you operate a perimeter, the homework is: confirm your WAF, DDoS provider, rate limiter, and bot-detection vendor all evaluate v6 rules at parity with v4. Cloudflare and Fastly do. Some of the older on-prem appliances quietly don't, and a /64 of IPv6 source addresses can blow through a per-IP rate limit faster than you can update the regex. Geo-IP databases for v6 are also still measurably worse than v4 — fraud teams have been complaining about this for two years.

Looking ahead

The interesting question is no longer *whether* IPv6 wins — it's *how long the tail is*. The remaining 50% is concentrated in places that are structurally hard to move: legacy enterprise, large parts of Asia ex-India, most of Africa, and the long tail of consumer ISPs that monetized their IPv4 blocks rather than deploy v6. The realistic forecast is that the curve flattens around 70-75% global by 2030, with the last 25% being a translation-layer problem rather than a migration problem. The IPv4 address market — currently around $35-40 per address on the resale market — is the leading indicator to watch. If that number starts falling, it means demand is finally giving up. Right now it's still climbing.