Measuring IPv6 at Web Clients and Caching Resolvers (Part 1)

Emile Aben — Mar 25, 2010 01:35 PM
Filed under: , , ,
It is important to keep an eye on how the IPv6 Internet develops. We wrote a script to measure the IPv4 capability, IPv6 capability and IPv4/IPv6 preference of end-users visiting our site. What is unique about this script is that it allows us also to measure the caching DNS resolver that the end-user system is using.


Measuring IPv6 at Web Clients and Caching Resolvers:

Part 1: Overview

Part 2: Country Level and other Statistics

Part 3: Methodology

 


 

With the looming IPv4 free address space depletion ( soon or sooner ), it is important to keep an eye on how the IPv6 Internet develops. For a compilation of IPv6 measurement studies see http://labs.ripe.net/content/ipv6-measurement-compilation . These studies show that the core is more IPv6 capable then the edge (no surprise). Relatively little is known about things between the core and the edge, which is why we wanted to measure near the edge to give us a more complete view of the size and shape of IPv6 deployment. One piece of the Internet infrastructure that is typically close to end-users is the caching DNS resolver they use; it's usually located in the same organisation as the end-user. The expectation is that if an organisation is deploying IPv6, it is deployed on infrastructure first before rolling it out to end-users. If this is true, the IPv6 capabilities of the resolvers that the clients use can be a predictor for the IPv6 capabilities of the clients in the (near) future.

We wrote a piece of JavaScript that allows us to measure the IPv4 capability, IPv6 capability and IPv4/IPv6 preference of end-users visiting our site. What is unique about this script is that it allows us also to measure the caching DNS resolver that the end-user system is using. Details on the way we did this are described in Part 3 of this article .

An initial version of the measurement script was incorporated in an earlier article about IPv6 on labs.ripe.net . This allows us to measure the IPv6 capabilities of JavaScript-enabled webbrowsers of users visiting this specific article. This showed some interesting result and we decided to install the measurement script on www.ripe.net . Table 1 shows the initial results from a multiday period on labs.ripe.net and a single day on www.ripe.net .

  labs www
number of measurements 768 8176
web client IPv6 preference 7.2% 1.4%
web client IPv6 capability 9.2% 3.5%
resolver IPv6 capability 11.0% 5.0%

 

Table 1 : Initial measurement results on labs.ripe.net and www.ripe.net

Note that we did not include resolver IPv6 preference, because resolvers can and will query both on IPv4 and IPv6 when offered both an A and a AAAA record for an NS-referral. Table 1 shows the large influence the website that hosts the script has on the measurement results. Visitors to www.ripe.net   are likely more interested in IPv6 then the average Internet user, and visitors to an IPv6 article on labs.ripe.net even more so. For this measurement to be representative of the entire Internet it would need to be deployed on a representative sample of hosting websites. However, these initial results already show a difference of 2% between IPv6 capabilities of web clients and the resolvers they use. So we decided to track this data for a longer period.

Figure 1: IPv6 in web clients and caching resolvers they use

In Figure 1 we tracked IPv6 preference and capability over time. End-user IPv6 preference is relatively constant at around 1.5%. Web client and resolver IPv6 capability show a weekday-weekend pattern. Resolver IPv6 capability is around 5%, but can drop to 4% on weekends. Web client IPv6 capability is around 4% on weekdays, but increases to about 5% on the weekend. The increased use of home networks during the weekend is a possible explanation for this effect. Overall, Figure 1 shows that the caching resolvers in use by users on home networks are significantly less IPv6 capable then the overall population of caching resolvers we measured.

The difference between preference and capability is caused by local policy decisions on the end-user systems, the most common/sane/ RFC-compliant of which is to prefer native IPv6 over everything else, but prefer IPv4 over non-native IPv6 (like 6to4 and Teredo). This explains the difference between client IPv6 preference and capability. The spikes in end-user IPv6 capability, but not in IPv6 preference, seem to be caused by higher usage of non-native IPv6 at home.

Figure 2: Native IPv6 in web clients and caching resolvers they use

Figure 2 shows the same data as Figure 1, but now only counting native IPv6. We count all non-Teredo/non-6to4 traffic as native. This includes configured IPv6 tunnels as offered by Hurricane Electric and SIXXS . As expected the graphs showing client IPv6 capability and IPv6 preference are now almost the same. Both the resolver IPv6 capability and client IPv6 preference are slightly lower then the same numbers in Figure 1. For the resolvers this indicates some use of Teredo or 6to4. For the client this indicates some prefer non-native IPv6 over IPv4. Figure 2 most strikingly shows the gap between end-user IPv6 capability at 1.2% on average and resolver IPv6 capability at 4.9% on average. If the caching resolvers are part of the same network providing connectivity to the end-users (in Part 3 of this article we show that this is very often the case), this gap represents networks that have deployed IPv6 in their infrastructure but have not provided the end-user with native IPv6 (yet).

You can find more statistics on IPv6 deployment, including country- and city-level breakdowns of IPv6 capabilities, in Part 2 of this article . Part 3 contains details on how these measurements were done.

 

Conclusion

Our measurements show that 1.2% of end-users that visit www.ripe.net have native IPv6 connectivity, whereas 4.9% of the resolvers these end-users use have native IPv6 connectivity.  We see an interesting effect on weekends where IPv6 capability (native and non-native) goes up and IPv6 capability of resolvers goes down.

Time will tell if the native-IPv6 capabilities of resolvers can tell us something about native-IPv6 capabilities of clients in the future.

We think it would be interesting to leave this measurement running for a longer time, and also try to get more sites to participate in order to get better coverage of the average Internet user (and is there such thing as an average user?).

We are really interested in your opinion on these measurements. Are there other analysis you would you like to see? And of course: if you have a website that would be interesting to serve the measurement script from, please contact us!

 

Analysis: Emile Aben

 


 

Measuring IPv6 at Web Clients and Caching Resolvers:

Part 1: Overview

Part 2: Country Level and other Statistics

Part 3: Methodology

 

0 Comments

Add comment

You can add a comment by filling out the form below. Only plain text is possible. Web and email addresses will be transformed into clickable links. Comments are moderated so they won't appear immediately.

Navigation
Related Items
Increased Reach of RIPE Atlas Anchors

Increasing the reach of RIPE Atlas anchors is one of the highest priority goals of RIPE Atlas Team. ...

Proposing Making RIPE Atlas Data More Public

RIPE Atlas is now three years old, and is moving from a prototype to production service. Based on ...

Modifications to the IP Analyser to Reflect New Policy

We are in the process of implementing the policy regarding Post Depletion Adjustment of Procedures ...

Report on IPv6 Security Test Methodology

The Dutch Institute for Applied Scientific Research (TNO) and a number of Dutch security companies ...

RIPE Atlas: Improved Probe Pages

We've made it much easier to get an overview of the history and measurements for all the public ...

more ...