IPv6 Deployment Statistics and Analysis

Introduction IPv6 is a fundamental component of the continued evolution of the Internet. As service provider networks, enterprise networks, cloud platforms, Content Delivery Networks (CDNs), applications, and user devices increasingly support IPv6, the operational focus of IPv6 deployment is moving from basic enablement toward active utilization, service quality, and sustainable traffic growth. Existing work has described IPv6 deployment status and related observations at different levels of the Internet ecosystem . Such information is useful for understanding overall deployment progress. However, operators of production networks often need more detailed analysis to understand why IPv6 traffic does not grow as expected, why IPv6 quality differs from IPv4 quality, or why user devices and applications continue to select IPv4 even when IPv6 appears to be available. IPv6 deployment is not a single capability that can be evaluated by one observation. A user device may obtain an IPv6 address while the application still uses IPv4. A domain may publish a DNS AAAA record while some application dependencies remain IPv4-only. An IPv6 path may be reachable while its latency, packet loss, or connection success rate is worse than that of the corresponding IPv4 path. This document discusses these operational gaps and explains why correlated analysis across multiple operational domains is useful. It also describes examples of statistical evidence that can support such analysis.

Problem Statement

Limitations of Existing IPv6 Deployment Observations Existing IPv6 deployment observations commonly include country-level or region-level adoption rates, Autonomous System (AS) level traffic ratios, BGP IPv6 prefix visibility, DNS AAAA record statistics, web access logs, application access logs, active probing results, and network-device counters. These observations are useful for understanding general deployment trends. However, they are often insufficient for operational analysis in large production networks. First, many existing observations provide only a macro-level view. They can show that IPv6 usage is increasing or decreasing in a country, region, network, or service, but they often cannot identify where a deployment problem occurs. For example, a low IPv6 traffic ratio may be related to an access-network gap, an application-side gap, a CDN mapping issue, a DNS issue, user-device behavior, or an interconnection quality problem. Second, different data sources are often isolated. Network counters can indicate IPv6 packet or byte volume, but they may not explain whether application transactions succeeded. DNS statistics can indicate whether AAAA records were queried or returned, but they may not show whether the returned IPv6 address was successfully used. Application logs can indicate request success or failure, but they may not reveal whether the cause is located in the user device, network path, CDN, DNS, or origin service. Third, many observations focus on whether IPv6 is available rather than whether it is effectively used and whether the user experience is acceptable. Reachability alone is not sufficient. An IPv6 path may be reachable but still perform worse than the corresponding IPv4 path. In such cases, applications or user devices may prefer IPv4, limiting IPv6 traffic growth even though IPv6 appears to be deployed.

Gaps Between Capability, Utilization, and Experience IPv6 deployment capability, actual IPv6 utilization, and IPv6 service quality may not develop at the same pace. For example, a network may have a high IPv6 enablement rate while actual IPv6 traffic remains low. This may indicate that applications, DNS, CDNs, or user devices are not fully using IPv6. Conversely, IPv6 traffic may increase significantly while latency, packet loss, connection failure, or application response time becomes worse than IPv4. In this case, IPv6 is being used, but the service quality may discourage sustained IPv6 usage. Typical inconsistencies include:

network infrastructure supports IPv6, but IPv6 traffic share remains low;
user devices obtain IPv6 addresses or prefixes, but active IPv6 connections remain limited;
applications publish AAAA records, but IPv6 connection success rates are low;
IPv6 traffic share is high, but IPv6 service quality is worse than IPv4; and
IPv6 quality is acceptable in one region, application, or access type, but poor in another.

These cases show that high IPv6 capability does not necessarily imply high IPv6 utilization, and high utilization does not necessarily imply acceptable user experience.

Deployment Problems Hidden by Protocol Selection In dual-stack environments, user devices and applications can select either IPv4 or IPv6 for a given service. Mechanisms such as Happy Eyeballs are designed to improve user experience by reducing delays when one address family is unavailable or performs poorly. Such behavior can make IPv6 deployment problems less visible. A user device may attempt IPv6 and IPv4 connections in close succession, while the IPv4 connection is ultimately selected because the IPv6 connection is slower or fails. From a network-capability perspective, IPv6 may appear enabled and reachable. From the application perspective, however, the successful user session may use IPv4. As a result, statistics limited to address assignment, route visibility, or aggregate traffic volume may not show that IPv6 is being bypassed. Information about connection attempts, connection success, selected address family, and session behavior can provide useful evidence when available.

Fragmented Visibility Across Operational Domains IPv6 deployment problems often need to be analyzed across multiple parts of the service path. A complete IPv6 user transaction can depend on the combined behavior of user devices, Customer Premises Equipment (CPE), access networks, transport networks, DNS, CDNs, cloud platforms, application servers, and third-party dependencies. A network may be IPv6-ready while the application domain does not publish AAAA records. An application may publish AAAA records while embedded resources, APIs, images, scripts, video segments, authentication systems, payment services, or third-party components remain IPv4-only. A CDN may provide IPv6 service in one region but not in another. A user device may obtain an IPv6 address while the application stack selects IPv4 because IPv6 connection setup is less reliable or less performant. Routing and interconnection differences can also create deployment gaps. IPv4 and IPv6 traffic may follow different peering, transit, or traffic-engineering paths. IPv6 traffic may traverse a less optimized interconnection point or CDN path than IPv4 traffic. As a result, IPv6 may be reachable while its performance is worse than IPv4 for particular regions or services. No single domain necessarily provides sufficient information to explain such problems. Correlation across the available network, application, and user-device observations is therefore useful when narrowing the possible causes of IPv6 deployment gaps.

External and Contextual Factors Affecting IPv6 Traffic Growth IPv6 growth can also be affected by factors that do not appear as direct network faults. Cost is one such factor. IPv6 deployment may require upgrades to network devices, CPE, service platforms, applications, testing environments, logging systems, security systems, and operational processes. When the operational benefit or return on investment is unclear, some parts of a network or application environment may remain only partially upgraded. IPv6-related innovation can also influence deployment. Some IPv6-related capabilities, such as SRv6 or cloud-network integration, may change deployment priorities and traffic patterns. When such capabilities are introduced, operators may need more detailed path, service-quality, and application-behavior statistics. At the same time, these capabilities can increase the need to understand paths, service quality, and application behavior rather than relying only on aggregate traffic counts. User behavior and device diversity are also important. Different operating systems, browsers, applications, chipsets, and CPE implementations may behave differently in address assignment, DNS handling, Router Advertisement processing, DHCPv6 behavior, and protocol selection. The content and application ecosystem can significantly affect IPv6 traffic growth. A limited number of major content providers, cloud providers, application platforms, and CDNs may account for a substantial portion of traffic. Uneven IPv6 deployment across regions or services can limit IPv6 traffic growth even where access networks have been upgraded. Policy, regulation, market competition, and enterprise migration plans can also affect the pace of IPv6 deployment. These factors may accelerate initial IPv6 enablement while detailed operational visibility remains incomplete.

Need for Correlated IPv6 Deployment Analysis

Why Single-Domain Observations Are Insufficient Single-domain observations can identify symptoms, but they often cannot explain why those symptoms occur. For example, a low IPv6 traffic share does not identify whether the issue is related to IPv6 address assignment, application readiness, CDN mapping, DNS behavior, user-device selection, routing, interconnection, or service quality. Similarly, a high IPv6 connection failure rate does not by itself identify whether the problem is related to a server, a security policy, a DNS response, a path issue, or a device-specific behavior. Correlated analysis helps operators compare observations from multiple domains and narrow the possible problem space. It does not necessarily establish causality. Instead, it provides evidence that can guide further operational investigation.

Analysis Across the Service Path A service-path-oriented analysis can correlate available evidence from multiple parts of an IPv6 user transaction. Depending on the operator's visibility and operational responsibilities, this may include: - user-device address and connection behavior; - CPE address delegation and prefix assignment; - access-network IPv6 capability and traffic; - transport-network routing and traffic; - DNS AAAA availability and resolution results; - CDN and cloud-service IPv6 availability; - application transaction success and response quality; and - interconnection and path-quality observations. Not all operators control or observe all of these domains. The purpose of correlated analysis is not to require complete visibility across the Internet. Instead, it is to avoid drawing conclusions about IPv6 deployment from a single isolated observation when relevant information from other accessible domains can provide additional context.

Scope of Service-Path-Oriented Analysis In this document, service-path-oriented analysis refers to the correlation of available information across different parts of the service path that contribute to an IPv6 user transaction. This does not imply that a single operator controls or observes every part of that path. It also does not imply that all data is collected by one entity or stored in one system. Different operators may have visibility into different portions of the path and may use different sources of statistical evidence. The purpose is to analyze IPv6 deployment from the perspective of the complete service experience, rather than from the perspective of one network device, one protocol layer, or one administrative domain.

Questions the Analysis Is Intended to Answer Correlated IPv6 deployment analysis can help operators investigate questions such as: - Are networks, applications, and user devices sufficiently prepared for IPv6? - Is IPv6 actually used when it is available? - Is IPv6 service quality comparable to IPv4 service quality for similar services and conditions? - Do user devices and applications select IPv6 or regularly use IPv4 instead? - Are deployment gaps concentrated in particular regions, access types, applications, devices, or service platforms? - Is an observed IPv6 issue more likely related to readiness, routing, interconnection, DNS, CDN behavior, application dependencies, user-device behavior, or another factor? - Which gaps or bottlenecks may be limiting further IPv6 utilization and service quality?

Statistical Indicators for Deployment Analysis

Role of Statistical Indicators This section describes examples of statistical indicators that operators can aggregate and analyze to identify gaps, bottlenecks, and blocking points in IPv6 deployment. The purpose of these indicators is not to define a fixed evidence model or a mandatory data set. Different operators may have different visibility depending on their network architecture, service model, operational boundaries, and privacy requirements. Therefore, the indicators in this section are illustrative. Operators may select, adapt, or extend them according to their own deployment environments and analysis objectives. The statistical indicators are organized around four operational questions:

whether networks, applications, and user devices are sufficiently prepared for IPv6;
whether IPv6 is actually used when it is available;
whether IPv6 service quality is acceptable and comparable to IPv4;
whether user devices and applications select and maintain IPv6 connections in practice.

These indicators can be aggregated from existing operational statistics, such as network-device counters, flow records, DNS statistics, application logs, CDN statistics, CPE state, and user-device connection-state information, where such data is available and permitted. The statistical indicators described in this section can be derived from a combination of passive observation and active measurement. Passive observation refers to statistics obtained from normal operational traffic and system state, such as network-device counters, flow records, DNS query logs, and application server logs. Active measurement refers to statistics obtained from controlled synthetic transactions or probes, such as path-quality tests, connection-attempt probes, and DNS resolution tests. The choice of data sources is deployment-specific, and this document does not require any particular collection mechanism.

Common Aggregation Dimensions IPv6 deployment indicators are most useful when they can be aggregated along dimensions that reflect operational reality. Depending on available data sources, useful aggregation dimensions may include:

time: minute, hour, day, week, month, peak period, and off-peak period;
geography: country, region, province, city, campus, or service area;
network topology: AS, core network, metro network, access network, BNG, mobile core, data center, CDN node, and interconnection link;
access type: fixed broadband, mobile network, enterprise leased line, public Wi-Fi, and data-center access;
application space: domain, service, application category, API gateway, CDN resource, and content category;
protocol: IPv4, IPv6, dual-stack, NAT64/DNS64, and other transition-related environments;
user-device category: device class, operating system family, browser family, application type, CPE type, or terminal category;
failure category: DNS failure, connection timeout, connection reset, TLS failure, HTTP error, path unreachable, Path MTU Discovery failure, and protocol fallback.

The same statistical indicator may lead to different operational interpretations when viewed across different dimensions. For example, an overall IPv6 traffic share may appear normal, while the same indicator broken down by region or application category may reveal a localized deployment gap.

Readiness Indicators Readiness indicators describe whether networks, applications, and user devices have the capability to support IPv6. These indicators help identify whether IPv6 deployment gaps originate from missing or incomplete IPv6 enablement.

Network Readiness Indicators Network readiness indicators describe the IPv6 capability of network infrastructure. Examples include:

total number of network elements;
number of network elements supporting IPv6;
number of network elements with IPv6 enabled in production;
number of operational interfaces configured with IPv6 addresses;
number of advertised and received IPv6 prefixes;
number of IPv6 routing adjacencies;
number of successful and failed DHCPv6 address-assignment events;
number of successful and failed Prefix Delegation events;
observed Stateless Address Autoconfiguration behavior and related failure indications, where such information is available;
IPv6-related security-policy, ACL, or firewall coverage;
number of CPEs or user devices receiving IPv6 addresses or prefixes.