On March 28, 2026, something happened that a lot of us in infrastructure had been watching for years: Google's continuous monitoring of its own traffic showed IPv6 carrying 50.10% of requests — the first time the protocol had ever crossed the majority threshold. The milestone did not hold day-over-day; Google's rolling average sits between 45% and 48%, and Cloudflare Radar puts the figure at 40.1% across its own network. But the crossover moment was real, and after 28 years it warrants more than a footnote.
I have been running hosting infrastructure since the mid-1990s. I remember reading about IPv6 when RFC 2460 dropped in December 1998 and thinking we would be migrated in five years. Then I thought the same thing in 2003. And 2008. And 2015. The protocol designed to save the internet from address exhaustion kept getting pushed back by the most powerful force in technology: good enough.
Why a 28-Year Migration Is Actually Logical
IPv6 uses 128-bit addressing — 340 undecillion unique addresses compared to IPv4's 4.3 billion. The problem was never the destination. It was the departure.
IPv4 ran out formally. IANA exhausted its central pool in February 2011. RIPE NCC, which manages European allocations, depleted its reserves in November 2019. Yet traffic kept flowing, because Network Address Translation let organizations put hundreds of devices behind a single public IP. When carriers needed more headroom they deployed Carrier-Grade NAT (CGNAT), stacking another translation layer on top. Problem kicked down the road, again.
The root causes of the delay were well understood but hard to fix simultaneously: NAT removed urgency, enterprise dual-stack deployments cost roughly $2.4 million with three-to-five-year ROI timelines, and early transition mechanisms like 6in4 and Teredo were fragile enough that cautious engineers quietly avoided them. The chicken-and-egg dynamic was real — content providers would not enable IPv6 without users, and users saw no reason to demand it without content. Network teams, perpetually overloaded with incident response, did not have bandwidth for a multi-year architectural shift that was not visibly broken.
What Finally Moved the Needle
Three forces converged to break the stalemate.
The first was mobile. LTE standards mandated IPv6 support in 2009, and it took years to propagate — but it did. T-Mobile now routes 93% of its traffic over IPv6. Verizon is at 90%. Every smartphone that hits a cell tower is almost certainly using IPv6 to reach your servers. If you have not published AAAA records for your services, you are adding latency for a majority of mobile users through fallback mechanisms every single time they connect.
The second was money. In February 2024, AWS began charging $0.005 per hour per public IPv4 address — $3.65 per address annually at minimum. Trivial for a small deployment, material if you are running hundreds of Elastic IPs. That billing change forced organizations to audit their IPv4 usage seriously for the first time. Many discovered they were carrying IPv4 allocations they had never meaningfully evaluated. IPv6, by contrast, is free and inexhaustible on every major cloud provider.
The third was the developing world moving directly to IPv6. Countries that received smaller IPv4 allocations due to historical imbalances in early internet resource governance — India, Vietnam, parts of Africa and Latin America — had less IPv4 infrastructure to protect and deployed IPv6 aggressively. India is now at 72% IPv6 adoption. That is more than a billion internet users where IPv6 is the primary path to your content.
The Numbers Require Context
The 50% headline carries important asterisks. APNIC's analysis notes that Google's measurement derives from ad-serving traffic, which skews toward wealthier markets with higher IPv6 penetration. APNIC applies statistical weighting by world internet population and arrives at 43% globally. The milestone did not hold past March 28 — Google's dashboard rolled back to the 45–48% range in subsequent weeks.
Geographic variation is stark and operationally significant. France is at 86% IPv6 adoption. Germany, 75%. The United States has crossed 52%. China, despite a massive internet population, sits under 5% — a consequence of large state-managed IPv4 allocations and centralized ISP infrastructure that creates entirely different migration dynamics.
If you run a CDN, a SaaS product, or global hosting infrastructure, the percentage of your users arriving over IPv6 varies enormously by market. Your European user base is almost certainly majority IPv6 today. Your North American users are split. Your Chinese users remain predominantly IPv4. A single infrastructure posture does not reflect that reality.
The Performance Case Is No Longer Soft
For years the performance argument for IPv6 was vague. The numbers have sharpened. Facebook documented 10–15% faster connection times for IPv6 users — primarily because eliminating CGNAT removes a translation hop and its associated latency. Akamai measured approximately 5% mobile improvement from the same cause. Those are not dramatic gains in isolation, but they are consistent, measurable, and they compound across a large user base.
More importantly, CGNAT creates correctness problems, not just performance problems. It breaks the internet's original end-to-end model by placing translation devices in the middle of connections. Applications that depend on direct peer connectivity — VoIP, WebRTC, certain gaming and VPN configurations — can fail or degrade under CGNAT in ways that are difficult to diagnose. If you have ever spent hours debugging a connectivity issue that turned out to be carrier CGNAT behavior, you understand how opaque these failures can be.
What Infrastructure Operators Need to Do Now
Reaching 50% does not mean IPv4 is retiring. The internet will run dual-stack for another decade or more. But the calculus has shifted in ways that infrastructure teams need to act on.
Dual-stack is the floor, not the ceiling. If your servers, load balancers, and CDN configurations do not serve AAAA records, you are already behind. Adding IPv6 to an existing deployment is not a rip-and-replace operation — major cloud providers have made dual-stack configuration straightforward. There is no good reason to defer it in 2026.
Audit your IPv4 holdings. The AWS pricing change was a warning shot, and other cloud providers have followed. Know how many public IPv4 addresses you carry, what they are attached to, and what a migration path would require. IPv4 is now a cost center that grows over time as scarcity increases.
Rethink rate limiting and blocking by IP. Rate limiting by source address breaks badly under CGNAT — you throttle an entire ISP's customer base when you mean to limit a single bad actor. If you block or rate-limit by source IP, you need to know whether those IPs represent single users or entire carrier networks serving thousands of subscribers. This is a security and customer-experience problem simultaneously.
Validate your monitoring tooling. Geolocation databases, IP reputation services, and fraud detection systems trained primarily on IPv4 traffic may behave unpredictably on IPv6 addresses. IPv6 allocations follow different ARIN, RIPE, and APNIC delegation patterns. Test your tooling against both address families — the edge cases are more common than vendors advertise.
28 Years Is Not a Failure
There is a narrative that IPv6 adoption was a coordination disaster, that it should have taken five years, that the industry failed. I do not buy it. The migration required every ISP, every OS vendor, every device manufacturer, every content provider, and every enterprise network team to make coordinated changes to infrastructure they could not afford to break. That it took 28 years to cross 50% is, in its own way, remarkable — the internet kept working throughout, which is the actual goal.
What I do believe is that infrastructure teams who treated IPv6 as perpetually optional made a deliberate bet that the transition would keep getting pushed back indefinitely. Mobile networks are now predominantly IPv6. The AWS pricing floor is a real budget line. India's 72% adoption means a substantial share of global internet users are connecting over a protocol many operators still do not serve natively.
The milestone Google recorded on March 28 is a useful forcing function. The question is no longer "when will we need to care about IPv6?" It is "why have we not done this yet?"