Google IPv6 crossed 50%, your IPv4 controls didn't follow

Google’s continuous measurement of IPv6 connectivity among its own users crossed 50% for the first time. That number is the share of users who reach Google services over IPv6. APNIC Labs, measuring the same thing a different way, puts worldwide IPv6 capability at 42%.

Both numbers are real, and the gap between them is instructive.

Google measures the availability of IPv6 among the people already connecting to it. APNIC Labs runs its measurement through online advertising placed via Google Ads, which appears in browsers, games and apps across every economy, around the clock. Each impression triggers a set of tests that cover IP, BGP routing and DNS, with APNIC’s own logic layered onto ordinary ad tracking. No end-user PII is retained, and raw measurements are never shared, only collations at ISP, economy and region level.

The 50% versus 42% difference comes from weighting. APNIC can’t simply add up its daily samples, because Google optimizes ad delivery for reach and revenue. On any given day one set of economies, say Egypt or Tunisia, may generate far more impressions than South America or Asia. APNIC weights each economy’s measured capability by its estimated Internet user population, drawn from World Bank data, so India, China and Indonesia count in proportion to their size rather than to that day’s ad distribution. At the level of individual economies APNIC’s figures line up with Google’s, and with Cloudflare, Akamai and Cisco. The divergence shows up at the global aggregate, and it is the weighting model. APNIC tends to read lower than Google, so the two bracket the likely range.

Adoption is uneven underneath the aggregate. India, Viet Nam and Saudi Arabia follow curves that look nothing like the global line. Newer entrants, especially in mobile, tend to run IPv6 as the primary protocol because it lowers total cost of ownership; Reliance Jio in India is the clearest example. Carriers that sank capital into IPv4 earlier have kept running it, layered with NAT in the home and CGNAT in the core.

The result is an internet that runs three ways at once: direct IPv4, IPv4 behind NAT and CGNAT, and IPv6. Interoperability lives above the IP layer. TCP, UDP and QUIC don’t care which IP version carries them, which is how a provider like Cloudflare serves dual-stack to users whether or not the backend speaks both protocols. Services that still answer only on IPv4, some Git platforms and some national broadcasters among them, are usually held there by operational cost or by legal and geolocation requirements around data access.

For anyone running these systems, the figure that matters is that half of Google’s users already arrive over IPv6, and your dual-stacked hosts present the same parallel path to whoever is scanning them.

A dual-stack host carries an IPv6 address that is independent of its IPv4 address. Firewall rules, security-group entries, rate limits, WAF policies and allow/deny lists written against IPv4 addresses or CIDR blocks do not apply to the v6 side unless you wrote them there as well. iptables and ip6tables are separate tables. A rule that permits SSH from a known v4 range says nothing about v6, and a host you meant to expose only on v4 may be answering on a v6 address you never firewalled. Log pipelines and detection rules that parse or correlate on IPv4 addresses will drop or misattribute v6 traffic, and geo-IP and threat-intelligence feeds are usually far thinner for v6 space.

The work that follows from the 50% figure is an audit of both families. Confirm that the firewall, WAF, rate limiter and access lists have explicit v6 equivalents and not just v4. Check that logging captures v6 addresses and normalizes them, and that alerting correlates across both. Where a host is dual-stacked but you only intended to serve v4, close the v6 listener or control it on purpose. On the measurement itself, treat Google’s 50% and APNIC’s 42% as the two ends of a range rather than competing answers; the real figure sits between them, and it is climbing.