On March 28, 2026, Google's traffic monitoring recorded IPv6 carrying 50.10% of requests, its first reading above half. The share fell back afterward. In the following weeks, Google's readings were between 45% and 48%, while Cloudflare Radar reported 40.1% across its own network.

That makes the result a milestone for Google's measurements, rather than evidence that most internet traffic everywhere now uses IPv6. It came roughly 28 years after RFC 2460 was published in December 1998. For infrastructure operators, the useful questions concern where IPv6 is already common, what keeping IPv4 costs, and whether services work properly over both protocols.

Why IPv4 lasted so long

IPv6 uses 128-bit addresses, providing about 340 undecillion unique addresses compared with IPv4's 4.3 billion. Address capacity was a clear reason to migrate, but running out of new IPv4 allocations didn't mean existing networks stopped working.

IANA exhausted its central IPv4 pool in February 2011. RIPE NCC, which manages European allocations, depleted its reserves in November 2019. Network Address Translation, or NAT, helped organizations keep operating by placing hundreds of devices behind a single public address. Carriers extended that approach with Carrier-Grade NAT, or CGNAT, adding translation within their own networks.

Those measures reduced the immediate pressure to replace IPv4. An account of the migration's delays puts enterprise dual-stack deployment costs at roughly $2.4 million, with returns taking three to five years. Dual-stack means running IPv4 and IPv6 together. Those estimates aren't a budget for every organization, but they illustrate why a migration could be difficult to justify while existing systems still worked.

Early transition mechanisms, including 6in4 and Teredo, also had a reputation for fragility. Content providers had little incentive to enable IPv6 without users, while users had little reason to demand it without accessible content. Network teams handling daily incidents had to find time for a migration that could take years and introduce new operational problems.

Mobile networks and address costs changed the incentives

Mobile networks became a major source of IPv6 adoption. LTE standards mandated IPv6 support in 2009, although deployment took years. Reported IPv6 traffic shares now reach 93% at T-Mobile and 90% at Verizon. For services with substantial mobile traffic, IPv6 support is no longer an obscure compatibility feature.

A service without an AAAA record, the DNS record that publishes an IPv6 address, cannot offer those clients a native IPv6 connection through that name. Depending on the carrier and client network, reaching the service may require translation or an IPv4 fallback, with possible latency costs.

Public IPv4 addresses have also become an explicit cloud expense. In February 2024, AWS began charging $0.005 per hour per public IPv4 address. The reported annual minimum of $3.65 per address is inconsistent with that hourly rate, so that annual figure shouldn't be used for budgeting. The hourly charge can become material for deployments carrying hundreds of Elastic IPs.

The billing change gave organizations a reason to review addresses that had remained allocated without much scrutiny. IPv6 addresses, by comparison, are described as free and effectively inexhaustible across major cloud providers. That address advantage doesn't remove the engineering cost of deployment, but it changes the ongoing cost comparison.

Adoption also grew in countries that had received smaller IPv4 allocations under the internet's early resource governance. India, Vietnam, and parts of Africa and Latin America had less established IPv4 infrastructure to preserve and deployed IPv6 aggressively. India's reported adoption rate is 72%, making native IPv6 access relevant to a substantial share of traffic serving that market.

The percentages depend on the measurement

APNIC's analysis describes Google's measurement as deriving from ad-serving traffic, with a bias toward wealthier markets where IPv6 penetration is higher. APNIC's weighting by world internet population produces a global estimate of 43%. Google's own return to the 45% to 48% range after March 28 is another reason not to treat the single reading as a settled global majority.

Reported national adoption figures vary considerably:

  • France: 86%.
  • Germany: 75%.
  • India: 72%.
  • United States: above 52%.
  • China: below 5%.

The explanation offered for China's lower figure points to large state-managed IPv4 allocations and centralized ISP infrastructure. That is an explanation of the reported difference, rather than proof that those factors alone caused it.

For a CDN, SaaS provider, or hosting operator, geography changes the deployment priorities. Audiences in France and Germany may already be predominantly reachable over IPv6, while an audience in China may remain largely dependent on IPv4. National adoption figures are useful context, but service traffic measurements are needed to establish the mix for a particular customer base.

Performance and connection failures

Facebook documented 10% to 15% faster connection times for IPv6 users, while Akamai measured an improvement of approximately 5% on mobile. Those results were attributed primarily to avoiding CGNAT and its translation overhead. They support a performance case for IPv6, although they don't establish a fixed improvement for every service or network.

CGNAT can also cause connection problems. By inserting translation devices between endpoints, it complicates applications that depend on direct peer connectivity. VoIP, WebRTC, and some gaming and VPN configurations can fail or degrade in ways that are difficult to diagnose. A connection problem may originate in a carrier's translation behavior rather than in either endpoint.

Shared addresses create another operational issue. An address used by many subscribers is a poor stand-in for one person or device. Security controls built around that assumption can affect legitimate users alongside the intended target.

Practical checks for infrastructure teams

IPv4 isn't close to retirement. Dual-stack operation is likely to remain necessary for another decade or more. The immediate task is to make IPv6 a supported production path while maintaining IPv4 access.

  • Review dual-stack coverage. Check servers, load balancers, CDN configuration, and DNS. Publishing AAAA records needs to be backed by working IPv6 connectivity through the service. Major cloud providers offer established dual-stack configuration options, so adoption generally doesn't require replacing the entire deployment. The case for continued deferral should be specific to the system.
  • Audit public IPv4 addresses. Record how many are allocated, what each serves, and which could be released. AWS's charging model, followed by charges from other providers, makes unused addresses a recurring expense. Include migration work in the comparison rather than looking only at address prices.
  • Review address-based rate limits and blocks. A public IPv4 address behind CGNAT may represent thousands of subscribers. Blocking it can affect many unrelated customers. Controls should account for whether a source address represents one endpoint or a shared carrier connection.
  • Test monitoring and security tools on IPv6. Geolocation databases, IP reputation services, and fraud detection systems developed mainly around IPv4 may produce unexpected results. IPv6 delegation patterns across ARIN, RIPE, and APNIC differ from IPv4 patterns. Validate behavior with both address families rather than assuming equivalent coverage.

The long migration is understandable. ISPs, operating system vendors, device manufacturers, content providers, and enterprise teams had to change infrastructure without interrupting existing service. Keeping the internet working throughout that process was a legitimate constraint.

Continued deferral still carries costs. Mobile networks already send substantial traffic over IPv6, public IPv4 addresses incur recurring charges, and regional adoption changes which connection paths customers depend on. Infrastructure teams can assess those costs now, without waiting for a global percentage to remain above 50%.