Introduction
The initial and ubiquitously deployed version 4 of the Internet Protocol has a fundamental resource scarcity problem: it reached the limit of available, globally unique, IP address space. As of today, IPv4 address scarcity has become a global issue, forcing some ISPs to NAT large chunks of their customers [], i.e., the one ISP offering free IPv6 tunnels has the largest customer cone in the IPv6 Internet, whereas Tier-1 ISPs with worldwide backbones are less prominent in this hierarchy.
Fig. 1.
IPv6 traffic in dual-stack networks. Barriers are present at home networks (operating systems, applications and CPEs), ISPs (offered DSL connectivity), and at service providers.
We argue that increasing IPv6 traffic shares will eventually provide the incentives for ISPs to provision proper IPv6 infrastructure, establish genuine interconnectivity, and finally make IPv6 the first-class citizen on the Internet. However, to exchange data over IPv6, all components on the path from a source to a destination need to fully support IPv6 (see Fig. ].
Determined to investigate the reasons that refrain the increase of IPv6 traffic on the Internet, we study this problem from the perspective of 12.9 K subscribers of a dual-stack ISP. This vantage point gives us a unique opportunity to analyze the interactions between applications, devices, equipment and services, and how they eventually influence the share of IPv6 traffic. Our main findings can be summarized as follows:
- (i)
Even though this ISP supports IPv6 connectivity, a large number of subscribers can not use IPv6. While in some few cases the ISP does not provide IPv6 connectivity to its subscribers, more often the CPE limits IPv6 connectivity.
- (ii)
Consequently, IPv6-ready services exchange a significant amount of traffic over IPv4. IPv4-only speaking devices and fallback mechanisms further increase the share of IPv4 traffic for these services. We observe, on the other hand, a strong intent for IPv6 traffic that IPv4-only services are not yet ready to correspond to.
- (iii)
Due to dual-stack applications preference for IPv6, dual-stack networks could face a rapid and substantial increase of the IPv6 traffic share if only a few major service providers enable IPv6 for high-traffic domains.
The rest of this manuscript is organized as follows: Section .
Methodology
The focus of our study is the traffic at a residential broadband network of a dual-stack ISP. As shown in Fig.. Hence, a dual-stack ISP presents a unique opportunity to study the interactions of this ecosystem and its influence on the share of IPv6 traffic. To this end, we first need to discover the connectivity options of the two engaged parties, i.e., the subscribers (the client side) and the service providers (the server side). With this information in hand we can proceed to study which traffic is exchanged over which protocol, and why.
3.1 Measuring IPv6 Connectivity
Connectivity of subscribers (client side). Broadband network providers typically rely on Remote Authentication Dial-In User Service (RADIUS []. If the CPE receives an IPv6 prefix assignment, we say that the subscriber obtains IPv6 connectivity from the ISP. Traffic statistics later tell us whether the subscribers devices make actual use of this assigned IPv6 prefix.
Since not all devices within home networks support IPv6, the raw traffic statistics are necessary but not sufficient to infer if a device within a subscribers premise can use IPv6. We use AAAA DNS requests as an indicator for the presence of IPv6-speaking devices. Most dual-stack applications follow the happy-eyeballs proposed standard (see [], some dual-stack devices do not always attempt a connection over both IPv4 and IPv6 although they issue requests for both RR s.
One important fact regarding IPv6-speaking devices is that many resolver libraries avoid suppressing AAAA requests if there is no global IPv6 connectivity, but just link-local, i.e., within the home network. The rationale is that doing so can lead to undesired situations []. Thus, we can use this information to further identify CPEs that offer link-local IPv6 connectivity even if the ISP does not provide IPv6 connectivity to them.
Connectivity of services (server side). In this paper we use the term service to refer to content and functionality that is available on the Internet via a Fully-Qualified Domain Name (FQDN). For example, at
3.2 From IPv6 Connectivity to IPv6 Usage
Now that we are aware of the connectivity options of subscribers and services (IPv4 and/or IPv6), we proceed to study the exchanged traffic. To accomplish this, we first need to annotate each flow in our trace with the respective subscriber and service.
Matching flows to names. One of the building blocks for our methodology is the ability to associate the DNS requests issued by an IP address to the network flows it generates, i.e., reproduce the mapping between FQDNs and server IPs for each subscriber. This problem has been already explored (see, e.g., []. The immediate consequence is that at times we will not observe a AAAA request for services without AAAA RR and may mis-attribute it to a device that does not support IPv6.
Annotating flows. We next annotate each flow with the following information: (i) whether the ISP has delegated an IPv6 prefix to the subscribers CPE, (ii) the FQDN associated with the flow, where possible, and (iii) if the subscriber issued an A and/or a AAAA DNS request. After collecting the trace we extend this annotation with the following information: (iv) if the subscriber makes use of its assigned IPv6 prefix at all, and with (v) the connectivity options for the FQDN i.e., whether the service is available over IPv4 and/or IPv6.