The editorial argues the 'finally moving to IPv6' framing misreads the data — mobile carriers and residential ISPs have been majority-v6 for half a decade, and the global average was only being suppressed by corporate networks and hyperscaler egress. Per-AS numbers make the split obvious: T-Mobile US at 94% and Jio at 89% versus AWS us-east-1 at 4% and Azure at 11%.
APNIC's chief scientist frames the 50% crossover as the predictable endpoint of a 17-year curve that started at 0.25% in 2008 — 'unremarkable in the way that water boiling is unremarkable.' The only real question was timing, not outcome, and the measurement infrastructure has been tracking the slope toward this point all along.
Submitted the APNIC post to HN with the straightforward framing 'Google Hits 50% IPv6,' treating the crossover as a clean, headline-worthy datapoint rather than a surprise. The 332-point score suggests the community accepts this as a milestone worth marking even if the underlying trend was long predicted.
India leads at 79% while China sits at 3% and Russia at 8% — the pattern doesn't track GDP or infrastructure maturity, it tracks whether local carrier economics ever made IPv4 painful enough to force migration. Where address scarcity bit (India, France, Germany), v6 won; where carriers had cheap v4 or aggressive CGNAT, the upgrade never happened.
The editorial pins the enterprise shift on AWS's February 2024 introduction of a ~$44/year-per-address charge on public IPv4, arguing the holdout segment is finally moving for cost reasons rather than any technical conversion. GCP at 38% sits well above AWS at 4% and Azure at 11%, but all three trail consumer carriers — the lever is billing, not engineering preference.
APNIC's measurement infrastructure clocked Google's IPv6 user share at 50.06% on April 28, 2026 — the first time the world's busiest endpoint has seen more v6 than v4 traffic to its eyeballs. Google has been publishing this counter publicly since 2008, when it sat at 0.25%. The crossover point arrived almost exactly 17 years later.
The per-country breakdown is the interesting part. India is at 79%. France is 78%. Germany 73%. The United States sits at 56%. The countries dragging the global average down are not the ones you'd expect from a digital-divide narrative — they're places like China (3%), Russia (8%), and large stretches of Eastern Europe where the carrier economics never penalized v4 enough to force the upgrade.
Geoff Huston, APNIC's chief scientist and the person who has been writing the annual "IPv6 is finally happening" post since approximately the Bronze Age, called the milestone "unremarkable in the way that water boiling is unremarkable — it was always going to happen, the question was when."
The story everyone is telling about this number is wrong. The popular framing — "the internet is finally moving to IPv6" — implies a transition that's still mostly ahead of us. It isn't. The consumer internet has been mostly v6 for years; mobile carriers in the US, India, and most of Europe deliver IPv6 by default and have for half a decade. What hit 50% this month is the *average*, and the average was being held back by a very specific category of traffic: corporate networks and cloud workloads.
Look at the per-AS data and the pattern is stark. T-Mobile US: 94% v6. Reliance Jio: 89%. Comcast residential: 76%. AWS us-east-1 egress to Google: 4%. Azure: 11%. GCP, ironically, is the highest of the three at 38%, but still well below any consumer carrier.
The reason is unsexy and entirely about money. AWS introduced a $0.005/hour charge per public IPv4 address in February 2024 — roughly $44/year per address. The expectation was that this would push customers to dual-stack or v6-only architectures. Eighteen months later, AWS's own usage data shows the IPv4 inventory shrunk by about 4% while the company collected an estimated $400M+ in new IPv4 fees. Customers preferred to pay rather than touch their networking config.
The reasons developers gave when surveyed: their CI pipelines hardcode v4 addresses for security group allowlists; their Terraform modules date from 2019 and assume `aws_eip`; their service meshes (Istio, Linkerd) had v6 support marked "experimental" until 2024; their observability stacks assume 32-bit address columns; and the one engineer who knew how IPv6 SLAAC worked left in the 2023 layoffs.
Kubernetes is its own special hell here. Dual-stack went GA in v1.23 (December 2021), but the default cluster networking in most managed offerings — EKS, GKE Autopilot, AKS — still provisions v4-only unless you explicitly opt in. The number of Helm charts in the wild that hardcode `0.0.0.0/0` in NetworkPolicy CIDR blocks is, conservatively, all of them.
If you're building greenfield in 2026, the calculus has flipped. Dual-stack is the lazy default — every major cloud supports it, every modern language runtime handles it transparently, and the v4 address you don't allocate is $44/year you don't spend per service. The diagnostic question is no longer "should we support IPv6?" but "why are we still paying for IPv4 addresses on internal services that never leave the VPC?"
For existing stacks, the honest answer is that this is a Helm chart and Terraform audit, not a network project. The actual work breaks down into roughly four buckets:
First, allowlists. Anything that pins `0.0.0.0/0` or specific /32s needs a v6 equivalent. This is grep-able and mostly mechanical, but it touches every team that owns a security group.
Second, observability. If your logs schema stores IPs as `VARCHAR(15)` or `INET` with v4 assumptions, you'll get silent truncation. Postgres `INET` handles v6 natively; most ELK schemas do not without remapping.
Third, service discovery. Consul, etcd, and most service meshes handle v6 fine in current versions but need explicit dual-stack configuration. The defaults are still v4-only because that's what the docs were written against in 2017.
Fourth, third-party integrations. The webhook endpoint your billing provider hits, the SAML callback URL, the OAuth redirect — these often live in someone else's allowlist, and that someone else may not have moved.
None of this is hard. All of it is tedious. The reason AWS could charge half a billion dollars in IPv4 fees and barely move the needle is that "tedious" is the most expensive word in the engineering vocabulary.
The 50% milestone is real but the meaningful number is the one nobody is publishing: the percentage of *enterprise* traffic that's v6. By that measure, we're probably still under 20%, and the curve looks more like an asymptote than a transition. The forcing function won't be technical — IPv6 has been technically ready for a decade. It'll be either regulatory (the EU's NIS2 directive has IPv6 readiness language that nobody has tested in court yet) or financial (AWS's $0.005/hr will keep climbing). The over/under on Google's counter hitting 75%: probably 2030. The over/under on your company's internal services being v6-native: whenever the person who owns the Terraform repo finally has a quiet sprint.
When I set up a "pure" (not really) IPv6 server, was surprised that Github does not support it. Without the voluntary operations listed at https://nat64.xyz/ , they'd be unreachable from IPv6.
Thread from two months ago (626 comments): https://news.ycombinator.com/item?id=47777894
Noooo, my /22 IPv4 subnet allocation is my personal 401k, I need this money to retire.
Meanwhile T-Mobile/Odido in the Netherlands is still not supporting IPv6 despite promising to have been working on it for years.Ubiquity gateways also seem to not support it sadly. It would be awesome if they supported something like Hurricane Electric’s tunneling.
Top 10 dev stories every morning at 8am UTC. AI-curated. Retro terminal HTML email.
Just to add to the 'but the ISPs do not' anecdotes, it has been six months since someone last commented so it is probably time to mention this again on Hacker News:* https://havevirginmediaenabledipv6yet.co.uk/A major ISP in the U.K., that said in a public statement on World