What percentage of the internet uses IPv6 today?

Google's IPv6 statistics page (the most-cited public measurement) shows IPv6 reaching Google services from over 45% of users globally in 2026. Penetration is heavily uneven by country: India, France, Germany, and the US are above 60%; many Latin American and African countries are below 10%. By traffic volume the share is higher than by user count, because mobile-heavy regions tend to be IPv6-first.

Should I still configure IPv4 if I'm building something new?

Yes, for the foreseeable future. Dual-stack — listening on both IPv4 and IPv6 — is the safe default. A meaningful fraction of users (and many enterprise networks, including most US government and military) are still IPv4-only. IPv6-only services need a NAT64 translation layer to be reachable from those networks, which is workable but adds operational complexity. Dual-stack is the path of least resistance.

Will my software work correctly on IPv6?

Most modern software handles dual-stack transparently — modern HTTP libraries, language runtimes, and operating systems implement RFC 8305 'Happy Eyeballs v2' to race IPv4 and IPv6 connections and use whichever succeeds first. The frequent failure points are: hard-coded IPv4 assumptions in older code, logging systems that parse IPs as 4-byte fields, geo-IP systems with sparse v6 coverage, and rate-limiters that key by exact IP rather than by /64 prefix. If you have a legacy system, IPv6 will expose all of these.

Why isn't IPv6 deployed everywhere already?

Three structural reasons. First, CGNAT lets IPv4 last 'just one more year' for ISPs, removing the urgency. Second, IPv6 deployment is a cost with diffuse benefits — your customers gain little until their counterparties are also on v6, which depends on everyone else's deployment timeline. Third, legacy software, hardware, and operational habits accumulated over 30 years are non-trivial to update. The transition is real but it is going to take a long time still.

IPv6 in 2026 — the state of deployment, the remaining gaps, and what to do

The 30-year transition

IPv6 was designed in the 1990s in response to the slow-motion exhaustion of IPv4 addresses. The first major spec, RFC 1883, dates from 1995; the modern version, RFC 8200, was finalized in 2017. World IPv6 Launch Day was in June 2012, with the major ISPs and content providers turning v6 on permanently. The transition was supposed to take a decade. We are 14 years past that and still in the middle of it.

The numbers tell the story. Google's IPv6 measurement page — the most-cited public dataset — shows traffic reaching Google over v6 climbing past 45% globally in 2026. That is up from under 1% in 2012 and 25% in 2018. The trajectory is real and steadily upward; the finish line is not visible.

Who has IPv6 in 2026

Mobile carriers — essentially universal. All major US mobile networks have been IPv6-first since 2016; T-Mobile is IPv6-only with NAT64 for v4 destinations. European, Indian, and Brazilian mobile networks are similar. Mobile internet is where IPv6 deployment is most complete.
Major content providers and CDNs — essentially universal. Google, Meta, Cloudflare, Akamai, Fastly, AWS CloudFront, Microsoft, Apple — all dual-stack. If you use any of these as your infrastructure, your v6 story is mostly handled.
US residential ISPs — partial, varying. Comcast, Spectrum, Verizon FiOS, and AT&T residential are largely dual-stack. Many smaller providers are v4-only or v4-with-CGNAT.
European ISPs — strong. Germany, France, the Netherlands, and Belgium have residential v6 deployments above 60%.
Indian ISPs — leading. Reliance Jio's IPv6-first deployment pushed India to one of the highest v6-adoption rates worldwide.
Enterprise networks — lagging significantly. Many corporate LANs remain IPv4-only because the operational benefit is small and the legacy of tooling, hardware, and policy that assumes IPv4 is large.
US government and military — uneven. Despite explicit policy mandates from OMB requiring IPv6, deployment progress has been slow and inconsistent across agencies.

What dual-stack actually looks like

A dual-stack connection has both an IPv4 and an IPv6 address. When you query a dual-stack hostname, DNS returns both an A and an AAAA record. The client uses Happy Eyeballs v2 (RFC 8305) to race connections on both families and use whichever responds first.

From the user's perspective, this is invisible — sites just work, and which family the connection actually used is a detail. The IP shown by the home page on IPFerret tells you which family your browser actually used for this connection; v6 addresses look like 2606:4700:4700::1111, v4 like 203.0.113.42.

To verify your own setup has working v6 end-to-end, use the IPv6 reachability test.

Why we're not done yet

CGNAT removes the urgency

IPv4 exhaustion was supposed to force everyone onto v6 by 2015. Instead, ISPs deployed CGNAT, sharing one IPv4 between many customers, and the urgency evaporated. CGNAT is a worse experience than real v4 (which is worse than v6) but for the average user who doesn't host services, it works. ISPs can keep customers on CGNAT'd v4 indefinitely; the v6 deployment they would otherwise be making is deferred.

The benefits are diffuse

An ISP that deploys v6 doesn't see immediate benefits — their customers don't have a noticeably better experience until the destinations they reach are also v6. A content provider that adds v6 carries the cost of the deployment but only saves a small amount on IPv4 transit. Nobody captures enough of the value individually to fund the transition, even though the collective value is enormous.

Legacy software, hardware, and habits

Thirty years of IPv4-only assumptions live in code, in router configurations, in firewall rules, in monitoring systems, in compliance documentation. Each one is a small task; collectively they're a generational engineering project. Most teams do the v6 work only when forced, and they're rarely forced.

The dual-stack tax

Running both protocols means maintaining two sets of routing, firewall rules, monitoring, and operational runbooks. For organizations that aren't pushed onto IPv6 by traffic pressure, the simplicity of "just v4" is attractive even when v6 is technically supported.

The rough edges in 2026

Geo-IP coverage for v6 is worse than v4

Commercial geo-IP databases have less data on v6 ranges. Coverage is improving, but expect a meaningful percentage of v6 lookups to return country-only or unknown-location results. See Geo-IP gotchas for developers for the broader context.

Rate-limiting by exact IP doesn't work the same

A v6 customer typically has a /64 allocation — meaning every device on their LAN has a different /128 address. Rate-limiting by exact /128 is trivially evaded by rotating addresses within the allocation. The convention is to rate-limit v6 by /64 prefix; see rate limiting by IP for details.

IPv6 leaks past v4 VPNs

Many consumer VPN clients only handle IPv4. On a dual-stack connection, v6 traffic bypasses the tunnel and goes direct to the destination, exposing your real ISP and location. The fix is either a VPN that handles v6 correctly or disabling v6 on the host while the VPN is up. Verify with the DNS leak test and IPv6 reachability test.

Firewall rules diverge between v4 and v6

A common configuration mistake is to write strict IPv4 firewall rules and assume they apply to v6 as well. They don't — iptables (v4) and ip6tables (v6) are separate. nftables tries to unify them but most production firewalls still require explicit parallel rules. The result is sometimes "we blocked port 22 on v4 but it's wide open on v6 and we never noticed."

Logging and analytics often break on v6

Older logging systems store IPs as 4-byte integers; v6 addresses don't fit. Some analytics platforms truncate v6 addresses or store them as strings without normalization, so the same address can appear in three different forms and confuse counts. If your business depends on IP-aware analytics, audit it for v6 handling before the v6 share grows past your noise threshold.

IPv6 PTR records often missing

Reverse DNS for v6 (PTR records in ip6.arpa) is dramatically less deployed than for v4. Mail servers that require valid PTR records on connecting IPs are increasingly tripping over v6 senders that have correct v4 PTR but missing v6 PTR. The fix is to set up v6 PTR for any outbound mail source. Bulk reverse DNS lookup works on both families if you want to spot-check.

What to do as a developer

Listen on both v4 and v6 in your servers. Most languages and frameworks default to dual-stack today; verify yours actually is.
Store IPs in your database in a format that handles both — INET in PostgreSQL, VARCHAR(45) in MySQL/SQLite. Don't store as a 32-bit int.
Rate-limit by /64 prefix for IPv6 traffic, not by exact /128.
Normalize v6 addresses before comparisons or storage — the same address has multiple textual representations (2001:db8::1 vs. 2001:0db8:0000:0000:0000:0000:0000:0001). Use a library to render the canonical form (RFC 5952).
Test with v6-only clients. The simplest way is to use a v6-only DNS resolver (like NAT64-style DNS) on a dual-stack machine; the harder but more thorough test is a v6-only network namespace or VM.
Log connection family in your access logs. You want to be able to say "what percent of connections in the last day were v6" without estimating.

What to do as a user

Verify your ISP gives you working v6. Run the IPv6 reachability test. If it shows v4 only, check your router configuration — v6 may be off by default.
If you self-host services, prefer v6 where possible. Your home network probably has a globally-routable v6 prefix already; every device can have a public address with no NAT.
Update your VPN client. The mature ones handle v6; the bargain ones often don't. Test for v6 leaks the same way you test for DNS leaks.
Use a dual-stack router. Most consumer routers ship dual-stack now, but older equipment may not support v6 at all.

IPv6 in 2026 — where it stands, where it's stuck