IPv6 Hit 50% of Google's Traffic for a Day. What Changes.
Google's IPv6 traffic hit 50% for a day in March 2026. Cloudflare and APNIC measured lower. What matters is a narrower question: dual-stack or IPv6-only.
On March 28, 2026, Google reported that IPv6, the newer of the two addressing systems every device needs to reach the internet, carried just over half the traffic to its own services for the first time. Fifty-point-one percent, to be precise, up from 46.33 percent a year earlier. Tech outlets called it a milestone. The same week, two other organizations measuring the same thing landed on numbers ten points lower. Which reading you trust changes almost nothing about the decision that actually matters to anyone running a server in 2026: whether you can drop the older protocol, IPv4, and run on IPv6 alone.
IPv6 hit 50% of Google’s traffic for a day, and nobody else agrees on the number
Google’s own explanation is precise about what it counted. The company tracks how many people reaching Google Search and YouTube do so over IPv6 rather than IPv4, using data from its own services rather than the internet as a whole. On March 28, that share touched 50.1 percent, and Google noted it had already crossed 49.5 percent on plenty of other days over the preceding year. One day above half is not the same as a settled majority.
The same week, two independent measurements told a less tidy story. Cloudflare recorded 40.1 percent of HTTP requests over IPv6, and APNIC Labs, the research arm of the registry that allocates IP addresses across the Asia-Pacific region, measured 43.13 percent of observable networks as IPv6-capable. Three organizations, three different methods, and a ten-point spread on what was supposedly the same question. The Register, the tech-industry outlet that covered all three numbers side by side, wrote that Google’s figure was “notable, and nice, but not solid proof that IPv6 has finally become dominant.”
The gap has a simple explanation. Each company only sees its own slice of the internet. Google sees whoever visits Google Search and YouTube, two of the most-visited sites anywhere, which skews its number toward whichever countries and devices happen to browse those particular services. Cloudflare sees the traffic passing through its own content delivery network. APNIC applies statistical weighting to correct for how unevenly IPv6 support is advertised across networks worldwide. None of the three is wrong. They are measuring different slices of the internet and reporting the difference as one shared milestone.
Why IPv4 keeps running anyway
IPv4 is not fading because it ran out of room to hand out. It ran out of new addresses to allocate years ago: the regional registries responsible for assigning them exhausted their reserves between 2011, in the Asia-Pacific region, and 2019, in Europe and the Middle East. The internet kept working regardless, because of a trick called network address translation, or NAT, which lets many devices share one public IPv4 address, the way an office building shares a single street address for dozens of tenants. Carrier-grade NAT does the same thing at the scale of an entire mobile network, letting millions of phones share a small pool of addresses. That trick is why the exhaustion of 2011 to 2019 never actually broke anything, and why IPv4 has kept a job fifteen years after the official supply ran dry.
One concrete example makes the point better than any traffic percentage. GitHub, one of the most-used developer platforms in the world, still runs its core services, the website, the API, and Git cloning, on IPv4 only in 2026. There is no public roadmap for adding IPv6 support, and developers have been asking in GitHub’s own community forums for years without an official answer. The one part of GitHub that does reach visitors over IPv6 is GitHub Pages, and only because it is served through Cloudflare’s network rather than GitHub’s own infrastructure. A traffic-share number describes an average across the whole internet. It says nothing about whether the one service your deploy pipeline depends on has made the switch.
The decision that actually matters: dual-stack or IPv6-only
For most people running a server today, supporting IPv6 at all is not the open question. Enabling it alongside IPv4, a setup called dual-stack, is close to free and has been standard practice for years: the server answers on both protocols, and each visitor’s device picks whichever one it prefers. The real question in 2026 is narrower and more specific: can you turn IPv4 off entirely and run IPv6-only.
That is already viable for a growing set of cases. Internal infrastructure that only talks to other systems you also control, a private API between two services you both run, a fresh deployment with no legacy client base to support: all of these can go IPv6-only without anyone noticing. A public-facing web server that anyone might reach, including from an old home router or a mobile network still relying on IPv4-only carrier-grade NAT, is a different case, and cutting IPv4 there risks locking out real visitors.
Dual-stack has its own quiet cost, which is why some teams skip it rather than embrace it. Every firewall rule, load balancer, and monitoring check now needs to cover two protocols instead of one, and a rule written for IPv4 only will silently fail to protect the IPv6 side of the same server. That gap, not a shortage of addresses, is the actual reason some outages get blamed on IPv6 when the real fault is a firewall rule nobody updated.
Cost has started to tilt that decision too. OVHcloud raised the price of an additional IPv4 address from 1.50 euros to 2 euros a month starting in April 2026, and named pressure on memory-chip supply, not IPv4 scarcity itself, as the reason. IPv6 remains free at every major provider. That does not justify cutting IPv4 on a service that genuinely needs it, but it is a real and growing nudge to stop defaulting to more IPv4 addresses than you actually use, the same instinct that pays off when right-sizing any other cloud bill.
How to check before you cut IPv4
A generic list of which industries still rely on IPv4 is less useful than auditing your own setup, because the right answer depends on what your own server actually talks to, not on an average. Two lists are worth building before switching anything to IPv6-only.
The first is outbound: every third-party API, package registry, or service that your application or your build pipeline calls. GitHub is the example worth testing first, since so much deployment tooling pulls from it, but it will rarely be the only one. If a dependency you rely on is IPv4-only, an IPv6-only server needs a translation layer, commonly one called NAT64, just to reach it, and that is one more moving part to maintain.
The second is inbound: who actually connects to you. A server used only by other systems under your own control has no legacy-client problem to worry about. A server open to the general public still has to assume some visitors sit behind IPv4-only home routers or mobile carriers, even in a country where IPv6 adoption looks strong on paper.
Both lists are quick to build. Running dig AAAA against a domain, a one-line command that asks for its IPv6 address record, shows in seconds whether it publishes one at all, and a few minutes reading your own DNS records and outbound API calls will tell you more about your actual exposure than any adoption statistic. The number worth trusting is the one you measured on your own infrastructure, not the one a headline reported about someone else’s.
The safest way to find the real answer is to test it on a non-critical environment first, a staging server or an internal tool, rather than flipping a production system straight to IPv6-only and finding out what breaks from the support queue.
FAQ
Is IPv6 now the majority of internet traffic? Not as a settled fact. Google’s own number touched 50.1 percent for a single day in March 2026, but Cloudflare and APNIC, measuring the same period with different methods, recorded 40.1 percent and 43.13 percent. Treat any single “IPv6 has crossed 50%” headline as one company’s read on its own traffic, not a verdict on the whole internet.
Can I just turn off IPv4 on my server today? Only after checking what it actually depends on. Audit the services you call outbound and the kind of visitors who reach you inbound first. A server with only internal dependents is a far easier case than a public-facing website.
Why does GitHub still not support IPv6? GitHub has not published an official explanation or a roadmap, despite years of requests in its own community forums. The one part of GitHub that does work over IPv6, GitHub Pages, does so because Cloudflare’s network serves it, not because GitHub’s own infrastructure changed.
What is carrier-grade NAT, and why does it matter here? It is the mechanism internet providers use to let a large number of customers, sometimes an entire mobile network, share a small pool of public IPv4 addresses. It is the main reason the 2011-2019 exhaustion of new IPv4 addresses never actually broke anything, and it is why some visitors to your server may still be effectively IPv4-only for years to come.
Is IPv4 going to keep getting more expensive? At least one major provider, OVHcloud, has already raised its IPv4 pricing in 2026, citing pressure on memory-chip supply. IPv6 remains free everywhere. Whether that trend spreads to every provider is not settled yet, but the direction argues for trimming the IPv4 addresses you no longer use, not for rushing to migrate a service that still needs them.
The traffic-share number that made headlines in March 2026 is worth remembering for what it actually is: one company’s read on its own visitors, contradicted by ten points depending on who else is counting. The decision worth making has nothing to do with that number. It is a plain audit of what your own server calls out to and who calls into it, run once, before any protocol gets switched off.
