An IPv6 adoption percentage is useful only when you know what was counted, where it was measured and when the observation was made. A share of users reaching one provider, a sample of capable browsers and a government asset target answer different questions. None is a direct measurement of whether your own website or device fleet is ready.
This guide shows how to read dated IPv6 measurements, compare regional results and distinguish policy targets from observed deployment. It then turns those distinctions into a measurement record for teams planning VPS, dedicated server or colocation capacity. The aim is to make a defensible planning decision without treating a global chart as a service test.
Start with the Measure, Date and Denominator
Before repeating a percentage, write down the source, metric label, population, geographic or network scope, observation date and averaging window. Record the sample size where supplied. Keep the original data or report alongside that record so someone else can reproduce the comparison. A chart retrieved today may contain older observations; the retrieval date does not replace the measurement date.
| Reported measure | What to record | What it cannot establish alone |
|---|---|---|
| Users reaching a named service over IPv6 | Provider, denominator, observation date and series definition | The share of all internet traffic or all people with IPv6 |
| IPv6 capability or preference in a measurement sample | Exact metric, selected country or network, date, window and sample size | The experience of every subscriber or destination |
| A target for organizational assets | Covered organization, asset definition, required state and deadline | How many assets actually met the target |
| Your edge’s IPv6 request share | Endpoint, request population, filters, time interval and collection point | Origin IPv6 readiness or requests that failed before reaching the edge |
Keep users, connections, requests, sessions, devices and bytes separate. A user can make many requests, a session can open several connections, and a device can use multiple addresses. Changing the unit changes the question. Do not relabel a published user measure as “internet traffic” merely to make a headline shorter.
Google: Two Dated Observations, One Defined Series
Google’s public series measures the percentage of users accessing Google over IPv6. Two observations in its published dataset are 31.53% on 6 December 2020 and 49.05% on 6 December 2025. These are historical examples from that series, not a statement of today’s worldwide traffic share.
| Observation date | Published total IPv6 value | Rounded value used here |
|---|---|---|
| 6 December 2020 | 31.532246% | 31.53% |
| 6 December 2025 | 49.046673% | 49.05% |
The values come from Google’s adoption dataset, whose date format uses zero-based months: month 11 is December. Preserve that detail when importing the data. These observations show an increase between two dates; two points do not establish that adoption accelerated throughout the interval or that it rose in every country.
Daily values fluctuate. For a trend comparison, choose consistent observation periods and describe whether you are comparing individual days or an average you calculated. If you calculate an average yourself, retain the included dates and method and label it as your calculation. Do not compare a daily maximum in one year with an annual average in another and describe the difference as a like-for-like change.
The denominator remains Google users reaching its services. It is not all internet requests, bytes, websites or people. Your own audience may differ by network, geography and usage pattern. The related article on interpreting an IPv6 adoption milestone for infrastructure planning provides further context; a milestone in one dataset is not a universal readiness threshold.
APNIC: Keep Capability, Preference and Sample Scope Distinct
APNIC’s measurement charts expose separate IPv6 Capable and IPv6 Preferred views, a measurement sample size, a selected date and an averaging window. Record the selected view instead of copying an unlabeled percentage. A result about capability and a result about the preferred connection are not interchangeable.
When comparing countries or networks, use the same source, measure and time window. Inspect the sample size and the coverage described by the source before treating a small difference as meaningful. A map color is a presentation choice; its legend and range matter, and it should not substitute for the underlying value and definition.
- For a regional comparison: Save the selected countries or networks, metric, date and window together. State any missing coverage rather than filling the gap with a neighboring country’s result.
- For a time comparison: Keep the geographic scope and metric consistent. Note changes in coverage or methodology that could affect interpretation.
- For an explanation: Treat proposed causes as hypotheses until supported by separate evidence. A country chart alone cannot establish that regulation, a particular ISP or legacy equipment caused its result.
Country averages can hide differences between mobile, residential and enterprise networks. Even an accurate national measurement does not show whether your specific customers have a usable path to your endpoint. Use public measurements to select relevant networks for investigation, then collect service-specific evidence.
Policy Targets Are Different from Adoption Results
The U.S. Office of Management and Budget’s memorandum M-21-07, issued on 19 November 2020, directed covered federal agencies to plan for at least 80% of IP-enabled assets on federal networks to operate in IPv6-only environments by the end of fiscal year 2025, with earlier milestones. The memorandum excludes national security systems from its application. The 80% figure is a policy target, not evidence that agencies achieved it.
That denominator is IP-enabled assets within the policy’s scope. It differs from users accessing Google and from a browser measurement sample. “IPv6-only” is also a different state from “IPv6-capable” or a dual-stack public endpoint. Do not put these percentages into a single ranking without explaining those differences.
To report achievement, obtain a dated implementation or assessment report that identifies the covered assets and the state actually observed. If you have only the memorandum, describe only its requirements and deadline. An elapsed deadline does not turn a target into an achieved result.
For procurement, record the actual jurisdiction, contract, service scope and acceptance evidence required of your organization. M-21-07 is not a universal requirement for every private website or ISP. A partner’s contractual requirement may still justify work, but it must be identified separately from a global adoption chart.
IPv4 Registry Milestones Need Their Own Context
Address supply helps explain why operators evaluate IPv6, but “IPv4 exhaustion” does not describe one identical event everywhere. ARIN exhausted its general free pool on 24 September 2015, and RIPE NCC announced exhaustion of its remaining available pool on 25 November 2019. LACNIC announced in August 2020 that its last available block had been reserved. APNIC has rationed its final /8 pool, while AFRINIC entered soft-landing Phase 2 on 13 January 2020.
These milestones do not mean every allocation route disappeared. Limited pools, recovered addresses, waiting lists and transfers have different regional rules. For example, current ARIN documentation describes special-policy options and a waiting list; RIPE policy provides conditional /24 waiting-list allocations without guaranteeing waiting time. Check the relevant registry’s current policy, eligibility and available supply when making an actual request.
Allocation limits and transfer prices are separate variables. Transfers can add acquisition costs, but prices vary over time; a depletion date does not prove a continuous price increase. The guide to IPv4 exhaustion and address-market costs examines that context. For your own budget, count retained IPv4 assignments, proxy or translation capacity and operational work rather than treating a rising IPv6 percentage as an automatic saving.
Connect Public Measurements to Your Own Observation Point
A native IPv6 connection needs a working client path and an IPv6-capable public service. Access-network deployment can make that path available; a CDN can accept IPv6 while reaching its origin over IPv4. Some IPv6-only access networks use translation to reach IPv4 destinations. None of these arrangements implies that every mobile connection uses translation or that IPv6 will always be faster.
DNS publishes available destinations; client address-selection and connection logic, such as Happy Eyeballs, determine connection attempts. The recursive resolver does not choose the web connection’s address family. A successful dual-stack browser visit may therefore conceal a broken IPv6 path through fallback. Public adoption data cannot identify that failure for you.
| Field | What the operator records |
|---|---|
| Question and scope | Named endpoint or user flow, required audience networks and the decision being considered |
| Observation point | Client-to-edge or edge-to-origin leg, collector and trusted forwarding configuration |
| Population and filters | Requests, connections or sessions; treatment of bots, retries, health checks and sampled records |
| Time and baseline | Start/end with timezone, normal and busy periods, and comparable IPv4/IPv6 tests |
| Outcome | Connection failures, TLS failures, application results and timing, with counts as well as rates |
| Decision | Acceptance criteria chosen before the change, observed result, owner and next review date |
For example, a request-share calculation would divide observed IPv6 requests by all observed IPv4 and IPv6 requests within the same filtered edge dataset and interval. Label it as a request share. It does not count people, and it misses connections that failed before an HTTP request reached that collector. Pair it with explicit external tests and client or connection telemetry where available.
Origin logs behind a proxy may record the proxy address, not the visitor’s connection family. Use documented edge telemetry and trust forwarded client information only from configured trusted proxies. Temporary IPv6 addresses can change, so unique address counts are not authenticated user counts. Check IP parsing, storage and analytics before using those fields in a decision.
What the Numbers Cannot Prove about Performance or Readiness
A larger IPv6 address space supports structured prefix planning; routing and access controls still enforce service and tenant boundaries. A native IPv6 path can avoid some IPv4 address-sharing translation, but IPv4 does not always use carrier-grade NAT and IPv6 can also traverse middleboxes. Compare equivalent application flows from representative networks, including cache state and workload, before attributing a timing difference to the address family.
Likewise, an adoption figure says nothing about your firewall or WAF coverage. Both families need the intended access policy, appropriate ICMPv6 handling including Packet Too Big, and tested logging and abuse controls. Large address space is not protection for a known service address. The VPS hardening guide provides operational detail; a percentage cannot replace those checks.
Keep web ingress, internal services, outbound dependencies and email as separate readiness states. An internal IPv6-only segment may use NAT64/DNS64 for suitable IPv4 destinations, but literal IPv4 addresses and DNSSEC validation arrangements require specific compatibility tests. The usual outbound setup does not automatically make an IPv6-only website reachable by IPv4 visitors. See the guide to IPv6-only VPS architecture with NAT64/DNS64 before choosing that design.
Email sending also needs separate evidence: forward and reverse DNS, SMTP identity, appropriate SPF authorization, DKIM/DMARC and recipient acceptance. PTR and authentication do not guarantee inbox placement, and web IPv6 adoption does not require moving SMTP from IPv4. The guide to IPv6 email deliverability, PTR, HELO, SPF and blocklists covers this separate decision.
Compare Deployment Models Before Choosing a Scope
The following patterns address different compatibility needs. They are alternatives you can combine, rather than mandatory stages every deployment must follow.
1. Dual-stack public endpoints
A dual-stack public endpoint can preserve IPv4 reachability while adding IPv6:
- The public web server, CDN or reverse proxy accepts both IPv4 and IPv6 connections.
- Its supported DNS setup publishes A and AAAA answers for the relevant hostnames.
- Firewall, TLS, monitoring and application checks cover both paths; backend connectivity can be planned separately.
Dual-stack preserves an IPv4 path, but a broken advertised IPv6 endpoint can still delay or fail connections. Test before publication and retain monitoring afterward. Our dual-stack guide to AAAA records and connectivity tests covers the rollout checks.
2. IPv6‑first with IPv4 as a compatibility layer
An internal IPv6-first design is an option when the platform, applications and dependencies support it:
- Internal service‑to‑service traffic runs over IPv6.
- Public entry points (load balancers, reverse proxies) expose both IPv4 and IPv6.
- Legacy IPv4‑only dependencies are isolated or fronted by translators.
This separates public client compatibility from internal addressing. Verify service discovery, outbound dependencies and failure handling before removing IPv4 from a segment.
3. IPv6‑only segments with NAT64/DNS64
IPv6-only segments can use NAT64/DNS64 to reach suitable IPv4 destinations. DNS64 synthesizes IPv6 answers from IPv4 DNS records, and NAT64 translates traffic. This can reduce IPv4 consumption, but applications using literal IPv4 addresses may need additional translation support; DNSSEC validation also requires a compatible design. The usual outbound arrangement does not automatically let IPv4-only visitors reach an IPv6-only website. Public access may need a dual-stack proxy or another explicitly designed ingress path.
For the architecture and compatibility considerations, see our guide to running a website on an IPv6-only VPS with NAT64/DNS64.
Choose a Rollout Scope for Each Type of Service
Set the pace from service dependencies, available maintenance time and measured client needs. Use the following examples to choose an initial scope, then expand after validating the result.
Small websites and blogs
For a small website or blog, start by evaluating one public endpoint:
- Confirm IPv6 availability and configure the address, routing, firewall and web service.
- Test the hostname and HTTPS against the IPv6 endpoint before publishing AAAA.
- Publish the record, then test from IPv6-capable mobile and fixed-line networks, monitor both paths and keep a rollback plan.
You can align this change with other maintenance, such as SSL certificate updates or a migration to a faster stack. Our article on launch‑time SEO and performance checks from the hosting side is a good companion if you are also refreshing your site.
E‑commerce, SaaS and high‑traffic applications
For online stores, SaaS platforms and APIs, validate the full user flow before expanding:
- Use staging or pre-production to check IPv6 clients, APIs, login, checkout, webhooks and logs.
- Prepare edge components, including listeners, TLS, WAF, DDoS controls and monitoring. Confirm origin access restrictions still work.
- Test each address family, then publish AAAA for validated hostnames in stages and track connection failures, response times and application errors.
- Expand after the results meet your requirements. During rollback, account for cached DNS answers and keep previously advertised endpoints available where possible.
A staged rollout makes failures easier to detect and limits the scope of each change. It does not replace testing critical dependencies or comparing performance on representative networks.
Agencies and multi‑tenant hosting
Agencies and resellers need to verify each client’s DNS, edge configuration and service behavior before describing a site as IPv6-ready. Check the following with the provider:
- IPv6 availability, address allocation and routing for the specific shared, reseller, VPS or dedicated plan.
- DNS templates that publish AAAA only after the corresponding endpoint is ready, including any CDN-specific requirements.
- Per-site testing, monitoring and rollback procedures so one template change does not advertise broken endpoints across an entire portfolio.
For a broader discussion of rollout pace, see our guide to deciding how quickly to adapt your infrastructure to IPv6. Use its planning considerations alongside measurements from your own sites.
Turn the Evidence into a Bounded Decision
Use public data to frame audience and capacity questions, then decide from service requirements and tested dependencies. Record what would justify proceeding, investigating further or retaining the current arrangement. There is no universal traffic percentage at which a website must remove IPv4 or an organization must move every backend component.
For a website change, use the website IPv6 pilot and acceptance guide and the dual-stack AAAA and connectivity playbook. Prepare routing, listeners, TLS, access controls and monitoring; test the intended hostname externally before advertising AAAA. Preserve required IPv4 paths and account for cached DNS answers in rollback.
Implementation details belong in the VPS IPv6 configuration guide and the DNS records reference. Website AAAA publication does not itself require a nameserver change; glue and DNSSEC concern separate DNS functions. Confirm support and management scope for the exact provider product and location.
Certificate checks remain independent of adoption figures. Each endpoint needs the correct hostname certificate and chain. OCSP stapling is certificate-authority dependent, not an IPv6 requirement; Let’s Encrypt ended its OCSP service on 6 August 2025. HSTS is an HTTPS policy, not a reachability test. If the work accompanies an SSL certificate change, keep those checks explicit alongside the hosting checks for a website launch.
For the wider organizational schedule, consult the guide to planning the pace of IPv6 infrastructure changes. Close each measurement review with its source, date, denominator, limitations and decision owner. That record is useful even when the result is to gather more evidence; a larger headline percentage alone is not a completed migration.
