IPv6 Deployment Statistics and Analysis

2.1. 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.¶

2.2. 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.¶

2.3. 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 [RFC8305] 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.¶

2.4. 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.¶

2.5. 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.¶

3.1. 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.¶

3.2. 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.¶

3.3. 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.¶

3.4. 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?¶

4.1. 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.¶

4.2. 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.¶

4.3. 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.¶

4.4. Utilization Indicators

Utilization indicators describe how much production traffic or how many application transactions are actually carried over IPv6. They help determine whether IPv6 capability is being converted into real use. Examples include:¶

• IPv6 ingress and egress byte counts;¶

• IPv6 ingress and egress packet counts;¶

• IPv4 ingress and egress byte and packet counts for comparison;¶

• IPv6 and IPv4 flow counts;¶

• IPv6 and IPv4 traffic by region, access type, network segment, or application category;¶

• IPv6 and IPv4 application-request counts;¶

• IPv6 and IPv4 transaction counts;¶

• DNS AAAA and A query counts;¶

• changes in IPv6 traffic volume over time.¶

Derived statistical indicators may include:¶

• IPv6 traffic share;¶

• IPv6 packet share;¶

• IPv6 flow share;¶

• IPv6 application-request share;¶

• IPv6 transaction share;¶

• DNS AAAA query share;¶

• IPv6 traffic growth rate;¶

• peak-period IPv6 traffic share.¶

Utilization indicators are most useful when interpreted together with readiness indicators. For example, high network readiness with low IPv6 traffic share may indicate that the limiting factor is related to application readiness, CDN mapping, DNS behavior, user-device protocol selection, or user traffic composition rather than basic network capability.¶

4.5. Quality Indicators

Quality indicators describe whether IPv6 service quality is acceptable and whether it is comparable to IPv4 service quality under similar conditions. These indicators help identify whether IPv6 is available but performing poorly. Examples include:¶

• IPv6 connection-attempt counts;¶

• IPv6 connection-success and connection-failure counts;¶

• IPv6 connection setup time;¶

• IPv6 Round-Trip Time (RTT);¶

• IPv6 packet loss rate;¶

• IPv6 jitter;¶

• IPv6 throughput;¶

• IPv6 retransmission rate;¶

• abnormal IPv6 session-termination events;¶

• DNS resolution success, failure, and latency;¶

• Transport Layer Security (TLS) handshake success and failure;¶

• application-request success and error counts;¶

• application response time;¶

• Path MTU Discovery failure events;¶

• comparable IPv4 quality statistics for the same application, region, access type, and time period.¶

Derived statistical indicators may include:¶

• IPv6 connection-success rate;¶

• IPv6 connection-failure rate;¶

• IPv6 DNS-resolution success rate;¶

• IPv6 application-request success rate;¶

• IPv6 average response time;¶

• IPv6-to-IPv4 latency difference;¶

• IPv6-to-IPv4 packet-loss difference;¶

• IPv6 retransmission-rate difference;¶

• IPv6 quality-degradation ratio.¶

Quality indicators should be interpreted in context. A quality difference between IPv6 and IPv4 may result from routing, interconnection, CDN mapping, server placement, access-network conditions, or application behavior. Therefore, quality indicators should generally be correlated with topology, application, and time-based statistics before drawing conclusions.¶

4.6. Connection-Behavior Indicators

Some connection-behavior indicators may only be available from application logs, client-side measurements, CPE state, or controlled measurement environments. Operators can use these indicators where such data is available and permitted.¶

Connection-behavior indicators describe how user devices and applications select and maintain IPv6 connections in dual-stack or transition environments. These indicators help reveal protocol-selection behavior that may not be visible from traffic volume alone. Examples include:¶

• number of active IPv6 and IPv4 connections;¶

• number of newly established IPv6 and IPv4 connections;¶

• number of failed IPv6 connection attempts;¶

• number of IPv6 connection timeouts;¶

• number of IPv6 connection resets;¶

• average IPv6 session duration;¶

• peak concurrent IPv6 connections;¶

• address-family selection outcomes in dual-stack connection attempts;¶

• observed IPv6-to-IPv4 fallback or retry behavior, where available;¶

• IPv6 and IPv4 connection counts by application, user-device category, access type, or region;¶

• connection success and failure statistics in NAT64/DNS64 or other transition environments, where such mechanisms are used.¶

Derived statistical indicators may include:¶

• active IPv6 connection share;¶

• new IPv6 connection share;¶

• IPv6 connection-failure rate;¶

• IPv6 connection-timeout rate;¶

• IPv6-to-IPv4 fallback rate;¶

• dual-stack IPv6 selection rate;¶

• IPv6 session-duration ratio;¶

• peak concurrent IPv6 connection ratio.¶

Connection-behavior indicators can expose deployment problems that traffic indicators alone may hide. For example, a small number of high-volume services may produce a high IPv6 traffic share, while many ordinary user sessions still select IPv4. Conversely, a large number of short-lived IPv6 connections may indicate that IPv6 is used for lightweight transactions but not for major traffic-bearing services.¶

4.7. Environment and Contextual Statistics

Some IPv6 deployment problems are influenced by operational context outside the direct IPv6 forwarding path. Environment and contextual statistics can help explain changes in readiness, utilization, quality, or connection behavior. Examples include:¶

• BGP path changes;¶

• routing-policy changes;¶

• interconnection utilization and congestion statistics;¶

• CDN mapping or service-location results;¶

• server-capacity or resource-exhaustion events;¶

• IPv6 security-policy events;¶

• application-release and configuration-change records;¶

• DNS configuration changes;¶

• user-device software-version distributions;¶

• CPE firmware-version distributions;¶

• major service incidents occurring during the same period as IPv6 traffic or quality changes;¶

• changes in user behavior, application popularity, or traffic composition.¶

These statistics are not necessarily IPv6-specific, but they can be useful for interpreting IPv6 deployment indicators. For example, a sudden change in IPv6 traffic share may be related not only to network readiness, but also to CDN mapping, application release changes, content distribution, or routing-policy changes.¶

5.1. Example Analysis Patterns

No single statistical indicator is sufficient to determine the cause of an IPv6 deployment problem. Operators can correlate indicators across readiness, utilization, quality, connection behavior, and operational context to narrow the possible problem domain.¶

The following table provides illustrative examples.¶

The purpose of such correlation is not to produce a single universal diagnosis. Instead, it helps operators narrow the problem space and decide whether further investigation should focus on network readiness, application readiness, traffic engineering, interconnection, CDN behavior, user-device behavior, or external ecosystem factors.¶