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

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.

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
.

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!

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.

The RIPE NCC uses cookies. Some of these cookies may have been set already. More information about our cookies can be found in our privacypolicy. You can accept our cookies either by clicking here or by continuing to use the site.