In the past three years, we have witnessed a substantial increase in IPv6 adoption on the Internet. More IPv6 prefixes have been routed, an increasing number of popular websites support IPv6, and popular service providers report increasing numbers of client connections over IPv6.
But what about traffic?
Reported IPv6 traffic shares vary widely. While some ISPs report IPv6 traffic shares of between 20% and 40% within their network [here and here], we see that IPv6 traffic accounts only for a small fraction of total traffic at several large Internet Exchange Points (IXPs) (for example, 2% at AMS-IX and 7% at SeattleIX). Hence, shifting actual traffic from IPv4 to IPv6 seems to be a different and more complicated matter than just providing IPv6 connectivity.
So what causes traffic to be carried over either IPv4 or IPv6?
In our most recent paper, we studied the interplay between IPv6 connectivity and traffic from the perspective of 13,000 ADSL subscribers of a major European dual-stack ISP, where customers have both IPv4 as well as IPv6 connectivity.
In this particular ISP, the IPv6 share is about 11%. Should we expect a higher share? If so, what are the reasons for traffic to be carried over IPv4?
What’s required for IPv6 traffic?
For end-user traffic to be carried over IPv6 in a dual-stack network, several conditions on the way from the user device to the content provider must be satisfied:
- The end-user devices in the home network support IPv6.
- The CPE router provides IPv6 connectivity to these devices.
- The ISP delegates an IPv6 prefix to the subscriber’s CPE.
- The ISP has IPv6 connectivity to other networks.
- The content provider makes its services available over IPv6.
- IPv6 network conditions are good (happy eyeballs: RFC6555).
Matching IPv6 connectivity and traffic
Given the requirements, we’re interested in understanding whether a particular traffic flow could be carried over either IPv4 or IPv6. For this, we have to annotate the traffic exchanged in this ISP with “connectivity options”.
For each traffic flow, we identify the preceding exchange of DNS requests and replies, where possible.
The DNS request tells us whether the subscriber’s devices want IPv6 (requesting an AAAA record), or whether devices only request IPv4 (an A record). The DNS reply tells us whether the requested service is available over IPv6 (providing an AAAA resource record).
We annotate our data flows with these observations (Figure 2). We also annotate whether the DSL received an IPv6 prefix or not. Read our paper for more details about the technique (for example, about how we deal with DNS TTL values).
This approach allows us to annotate each flow with the following information:
- DSL connectivity: did the ISP offer IPv6 connectivity to the subscriber?
- IPv6 intent: did the device request IPv6?
- IPv6 server availability: was the service available over IPv6?
With this information, we proceeded to study how users and servers interact with each other by inspecting network traffic.
Dual-stack broadband networks: IPv6 connectivity for everybody?
Let’s first have a look at the available IPv6 connectivity and the corresponding traffic on a per-subscriber basis. We group our subscribers in three categories:
| DSL type | IPv6 connectivity | IPv6 traffic | % of lines |
| IPv4-only | X | X | 17.3 |
| IPv6-inactive | ✔ | X | 29.9 |
| IPv6-active | ✔ | ✔ | 52.9 |
The first group of DSLs, IPv4-only, refers to lines without IPv6 connectivity (the CPE router did not receive an IPv6 prefix from the ISP). The reason here is that not all subscribers have IPv6 enabled in their contracts yet.
The second group of subscribers, IPv6-inactive, are lines with IPv6 connectivity (the CPE received an IPv6 prefix from the ISP), but no IPv6 traffic. Moreover, for most of them, we don’t see AAAA DNS requests. The absence of such requests suggests that either the CPE routers do not provide IPv6 connectivity to the devices in the home network, or — more unlikely — that none of the connected devices speaks IPv6.
The third group, IPv6-active, are DSL lines with IPv6 connectivity and traffic.
This meant only a half of the considered DSL lines generate IPv6 traffic. In about a third of the cases, the subscriber’s CPE devices receive an IPv6 prefix from the ISP, but we can’t see any IPv6 traffic. The most likely reason for this behaviour is a lack of support, or default settings, within the CPE routers that prevent user devices from exchanging traffic over IPv6.
IPv6 traffic barriers
Next, we want to understand what elements affect the overall share of IPv6 traffic at our ISP. We coined the term “IPv6 barriers” to explain those data exchanges over IPv4 with content providers, who in fact, support IPv6.
In the top bar of Figure 3, we present a classification of the overall traffic, grouped by IPv6 availability of the server side. The IPv6-ready category refers to traffic from content providers that have set A and AAAA DNS resource records.
In the middle bar, we show which protocol the traffic from IPv6-ready servers is carried over, finding that the majority is IPv4 (61%).
In the bottom bar, we further illustrate why this traffic is carried over IPv4 and not IPv6. The grey portion at the bottom left corresponds to two of the earlier introduced subscribers’ classes. These are those DSLs that did not receive an IPv6 prefix from the ISP (IPv4-only) and those that did receive an IPv6 prefix but don’t generate IPv6 traffic (IPv6-inactive).
The red and blue portion is traffic generated by subscribers in the IPv6-active group. If you recall, these subscribers can and do communicate over IPv6. There are two reasons some of their traffic is carried over IPv4:
- No AAAA: For these particular flows, no AAAA record was requested via the DNS. These flows are caused by some devices that apparently cannot speak IPv6 even though they are in IPv6-enabled home networks.
- Fallbacks: For these flows, both an A as well as an AAAA record were requested, yet the devices choose IPv4 over IPv6. These cases are related to the happy-eyeballs algorithm.
We find that the majority of traffic from IPv6-ready content providers is still carried over IPv4 in our dual-stack ISP (more than 60%). This is mostly due to IPv6-inactive — and to a lesser extent IPv4-only — subscribers.
Also, devices within IPv6-enabled home networks cannot speak IPv6, and some happy-eyeballs fallbacks contribute to it. Once these barriers within home networks are resolved, the amount of IPv6 traffic in this ISP could easily double!
IPv6 traffic intent
Next, we focus on the server-side and ask the question: How much traffic do subscribers want to receive over IPv6, but the server-side can only provide it via IPv4? We refer to this as “IPv6 traffic intent”.
We show again in the top bar of Figure 4 all exchanged traffic, but this time we focus on the traffic exchanged with IPv4-only services; that is, servers that do not have an AAAA record set.
We then dissect the traffic in the second bar according to our three groups of DSL subscribers. Close to half of traffic from IPv4-only services is exchanged with IPv6-active subscribers.
In the bottom bar, we show that these subscribers indeed want IPv6 (per AAAA requests) for a majority of this traffic. In fact, we find that 30% of the total traffic from IPv4-only services could be carried over IPv6 immediately, once IPv6 is enabled at the server-side.
This implies that once content providers adopt IPv6, both this ISP, as well as the content providers, may experience pronounced and rapid shifts of traffic from IPv4 to IPv6.
Barriers remain but intent are there
Our study shows that there are still several barriers present in our dual-stack ISP that prevent more traffic from being carried over IPv6, even when the server-side supports it.
Our analysis suggests that CPE devices that do not properly support IPv6 (or are not properly configured) are a major barrier for IPv6 traffic, along with some non-IPv6 capable devices. In fact, the share of IPv6 traffic in this ISP could double once these barriers within home networks disappear.
On the other hand, we see that the subscribers of this ISP show a strong intent for IPv6 traffic, requesting IPv6 for a significant share of content from IPv4-only servers (30%).
Improving IPv6 compatibility within home networks, in ISP networks, as well as within content providers can significantly increase the share of IPv6 traffic in the near future.
Co-authored by Philipp Richter
Enric Pujol is a network-data analyst at BENOCS Gmbh. Before that, he was a PhD candidate in the INET group at TU Berlin, where his co-author, Philipp Richter, is a PhD candidate. They have a common interest in Internet measurement-related topics, ranging from network performance to infrastructure and protocol deployment.
The views expressed by the authors of this blog are their own and do not necessarily reflect the views of APNIC. Please note a Code of Conduct applies to this blog.