The APNIC blog post frames Google's measurement crossing 50% as a landmark moment for IPv6 adoption, three decades after RFC 1883. The piece highlights leaders like France (>75%) and India (>80%) driven by mobile carriers like Reliance Jio choosing IPv6-first deployment over expensive carrier-grade NAT44 infrastructure.
The editorial argues that Google's metric only captures users reaching Google's edge, not the protocol that production stacks actually speak internally. When an EKS pod calls an RDS instance, it's still almost certainly IPv4 — and that's the real measure of IPv6 adoption that's been stuck for years.
A substantial portion of the 400+ comment thread pointed out that consumer-eyeball metrics like Google's chart don't reflect the protocol used inside data centers, VPCs, or between microservices. They argue the celebration ignores that enterprise infrastructure adoption has barely moved in five years.
AWS shipped EC2 IPv6 support in 2016 but treated it as second-class for a decade — VPC endpoints, RDS, Lambda VPC networking, and IAM policies had gaps or silent gotchas. The cultural consequence is that every tutorial, Terraform module, and runbook defaults to IPv4, making IPv6 the path of most resistance for any new enterprise deployment.
The countries leading IPv6 adoption (India at 80%+, France at 75%+) got there because mobile carriers like Reliance Jio chose IPv6-first deployment for a simple cost reason: handing out a /64 to every handset was cheaper than building NAT44 carrier-grade gear that tracks billions of connection states. The pattern shows IPv6 wins where the v4 alternative is more expensive, not where it's technically superior.
APNIC's measurement lab, the canonical scoreboard for IPv6 adoption, reported that Google's global IPv6 user traffic crossed the 50% line. Three decades after RFC 1883 specified IPv6 in 1995, the majority of traffic reaching Google's edge is finally on the protocol that was supposed to replace IPv4 by the early 2000s.
The number itself is a weighted average. France sits above 75%. India clears 80% thanks to Reliance Jio launching IPv6-first in 2016. Germany, the US, and Japan are in the 50–65% range. China is the visible drag: still under 35% by Google's measurement despite Beijing's IPv6+ mandate. The shape of the curve is unsurprising — mobile carriers drove the gains, because handing out a /64 to every handset was cheaper than NAT44 carrier-grade equipment that needed to track billions of connection states.
The HN thread (267 points, 400+ comments) split predictably. One camp celebrated the milestone. The other pointed at the exact same chart and noted: Google's number measures *users reaching Google*. It doesn't measure the protocol your production stack actually speaks when an EKS pod calls an RDS instance.
The ceiling on IPv6 adoption stopped being a consumer-ISP problem around 2020. The remaining 50% — and the part that's barely moved in five years — is enterprise infrastructure: hyperscaler VPCs, Kubernetes control planes, legacy load balancers, and the config files of every appliance that was last touched in 2017.
Look at the hyperscalers. AWS shipped IPv6 support in EC2 in 2016 but kept it second-class for a decade. VPC endpoints, RDS, ElastiCache, Lambda VPC networking, and large swaths of the IAM policy surface either didn't support v6 or had silent gotchas (dual-stack subnets that broke specific instance types, NLB target group restrictions, missing PrivateLink support). The cultural consequence: every AWS tutorial, every Terraform module on the public registry, every internal runbook defaulted to v4. Greenfield projects in 2024 were still being built v4-only by engineers who'd never had a reason to think about it.
The forcing function finally arrived in early 2024, when AWS started charging $0.005/hour for every public IPv4 address — about $43/year per IP. For a mid-sized enterprise running a few thousand public-facing addresses across dev/stage/prod, that's six figures a year of newly-itemized cost, and it's the first time the IPv4 status quo had a price tag attached. Google Cloud followed with similar pricing. Azure had been charging since 2021. Within twelve months, the dual-stack engineering tickets that had been sitting in backlogs since 2018 suddenly had executive sponsors.
Kubernetes is the other piece of the bottleneck. Dual-stack went GA in 1.23 (December 2021), but most managed offerings — EKS, GKE, AKS — kept it behind feature flags or required cluster recreation. Service mesh sidecars, ingress controllers, CNI plugins, and Helm charts inherited the v4 assumption from the CNI spec's early days. As of mid-2026, the operational answer to "can my cluster talk v6 end-to-end?" is still "probably, but you'll be the first person at your company to find out." The HN comments are full of war stories: a Cilium upgrade that quietly broke v6 NodePorts, a kube-proxy iptables rule that NAT'd v6 to v4 because someone copy-pasted from a 2019 blog post.
The protocol design itself isn't the holdup anymore. NAT64, DNS64, 464XLAT, and SLAAC have been production-ready for years. The bottleneck is the long tail of software that hardcoded `struct sockaddr_in`, the Helm values.yaml that defaults `dualStack: false`, the security team that still writes firewall rules in dotted-quad, and the SRE who'll get paged at 3am if they flip the flag wrong. That's not a protocol problem. That's an inertia problem with a tooling tail measured in person-decades.
If you're greenfielding infrastructure in 2026, dual-stack-by-default has crossed the line from "nice future-proofing" to "line item on the cloud bill." Concretely: turn on IPv6 in your VPC, set your subnets to dual-stack, and make sure your Terraform modules surface the option rather than burying it. If you're on AWS, every public-facing ALB or NLB that doesn't need a v4 address shouldn't have one — `ipv6` scheme costs nothing extra, and you save the $43/IP/year.
For Kubernetes, the practical move is to set `ipFamilies: [IPv6, IPv4]` on new clusters and audit your ingress controllers (nginx-ingress, Traefik, Istio gateways) for dual-stack support before you commit. The single biggest landmine is service discovery: if your app code uses `getaddrinfo` correctly it'll Just Work, but anything calling `gethostbyname` or parsing addresses with regex will silently prefer v4 forever. Grep your code for `\d+\.\d+\.\d+\.\d+` and treat each hit as a migration ticket.
For the long tail — internal monitoring, log shippers, the appliance that exports Prometheus metrics over a hardcoded v4 endpoint — accept that this is a multi-year project and prioritize by blast radius. The honest sequencing is: turn on dual-stack at the network layer first, make v6 the preferred path for new services, and let the v4-only systems retire on their natural replacement cycle.
The IPv6 transition was always going to end not with a flag day but with a long, boring tail where v4 became the expensive legacy path. Google's 50% number says the consumer half of the internet has finished its part. The enterprise half now has a cost-per-IP dial that's going up, not down, and the next five years of IPv6 progress will be measured in cloud invoices, not APNIC charts. The interesting question isn't when we hit 75% — it's how long the last 10% of v4-only enterprise systems get to amortize their refusal to move.
Top 10 dev stories every morning at 8am UTC. AI-curated. Retro terminal HTML email.