Measuring IPv6 at Web Clients and Caching Resolvers (Part 2: Country Level and other Statistics)

In Part 1 of this article we showed some statistics on IPv6 at end-users and at caching DNS resolvers. In this part will dig deeper into the data we collected and show details on mobile device use of IPv6, country- and city-level IPv6 deployment numbers, and AS-level statistics.

IPv6 per country 

The figures below show client and resolver capability for native IPv6, for various part of the RIPE region and for selected countries outside of the RIPE region. These measurements cover 1 February - 13 March 2010. Each figure also shows the overall average of all measurements: 1.2% of clients and 4.9% of resolvers (see Part 1 ). Geolocation was done by looking up the country for the IPv4 address of the client in the MaxMind GeoLite database, so accuracy is as good as this database is. The DNS resolver IPv6 capabilities in these graphs are the capabilities of resolvers in use by clients in that country, which doesn't necessarily mean that the resolvers themselves are in the same country, but they usually are (see footnote [1]).  In these geolocation graphs the numbers in parentheses next to the country name are the number of measurements received from that country, which tells you something about the confidence levels of the numbers reported. In Figure 1 (Northern Europe) we see high IPv6 capability percentages for resolvers in use by clients from Norway, Sweden, Finland and Ireland. 

In Figure 2 (Western Europe), we see a native IPv6 client capability in France of over 4%. This is mainly caused by free.fr that accounts for 70% of the native IPv6 clients measured. Note that technically free.fr uses 6rd-tunneling, but externally that looks, feels and smells like native IPv6 . In Luxembourg, the client and resolver IPv6 capabilities are even higher, but due to the low number of measurements (264), there may be a relatively large measurement error in that.

In Figure 3 (Southern Europe), we see Greece and Portugal standing out on client IPv6 capabilities.

In Figure 4 (Eastern Europe, including former Yugoslavia), we see above average IPv6 resolver capabilities in Hungary and the Czech Republic. But the overall highest native client and resolver IPv6 capability rates for any country where we have a significant number of measurements are seen in Slovenia at 9.5% (clients) and 23% (resolvers). This is probably due to initiatives like the go6 Institute . We see 10 different ASs (9 if you exclude US-based tunnel-brokering Hurricane Electric) providing native IPv6 to the web clients in Slovenia that we measure, which is an indication of the diversity of IPv6-originating ASs in this country. 

In Figure 5, we don't see much client IPv6 capabilities in the Middle East, with Turkey and Saudi Arabia as notable exceptions. We do see some web clients in these countries using resolvers with IPv6 capabilities, which suggests IPv6 deployment is happening in the Middle East, even though it is not visible from web clients. The very high IPv6 capability reported for resolvers in use by clients from Bahrain is due to two resolvers that are located in address space announced by AS6453 (GLOBEINTERNET/TATA communications). For the countries on the right-hand side of the graph we have relatively few measurements, so the numbers reported for these countries are likely not very accurate. 

In Figure 6 (former Soviet Union countries) two of the Baltic states stand out on resolver IPv6 capabilities: Estonia at 38% and Latvia at 25%. We also see that Moldova and Uzbekistan have an above average number of web clients with IPv6 capabilities. In Uzbekistan this is caused by two local ASs and one US-based tunnel-broker AS. For Moldova we predominantly see IPv6 capable web clients from a single local AS. 

In Figure 7, we see client and resolver IPv6 capabilities for countries with small populations. We removed the single measurement for the Vatican that indicated 0% client and 100% resolver IPv6 capability. There are few measurements from these countries, so these numbers are likely quite inaccurate, but this still shows IPv6 activity from Malta and Liechtenstein. 

In Figure 8, we see IPv6 capabilities from selected countries outside of the RIPE region. Client native IPv6 capabilities in the USA are close to the global measured average, while Japan, Brazil, Australia and China are definately above average. For the resolvers these clients are using, the USA, Japan and Australia stand out. In India we see higher IPv6 capabilities in the web clients than in the resolvers they are using: this is caused by a single AS ( AS109 ) that provides IPv6 capabilities to clients, but the resolvers (that were in the same AS) showed only IPv4 capabilities. 

In Figure 9, we see the IPv6 capabilities in the RIPE region compared to what we measure for the rest of the world. The RIPE region accounts for 90% of the measurements; this is because the measurement script is hosted on www.ripe.net . 

  Figure 9: Native IPv6 capabilities of RIPE region compared to the rest of the world

IPv6 per city 

Table 1 shows the cities that had over 2% native client IPv6 capability and where we received over 300 measurements from. Geolocation was again done with IPv4 address lookup in MaxMind GeoLite, which is known to be less accurate on the city level then on the country level. Even with this measurement being biased because it only measures visitors to www.ripe.net . This provides some insight in the "pockets of IPv6" that exist in the current Internet. In Ljubljana, Slovenia and Paris, France over 10% of the clients that we measured had native IPv6 capability. For Ljubljana that is only slightly over the national average that we measured, but for Paris that is more then twice the national average. As for diversity, Prague tops the list with 16 different AS numbers providing native IPv6. 

Table 2 shows the IPv6 characteristics of mobile devices as determined by the user-agent strings in our measurements from 1 February - 13 March 2010. Of the 1155 measurements taken we only saw three IPv6 capable devices (0.26%), all devices from Nokia. We didn't attempt to classify into WiFi or other types of networks that mobile devices use. These numbers suggest that mobile networks are lagging behind in IPv6 uptake, although the 2.7% IPv6 capability at resolvers used by mobile devices is an encouraging sign. 

In Table 3, we summarize some characteristics of the number of ASs we saw in our measurements to give you an idea of the scope of this measurement. As you can see from Table 3 the measurements cover 30% of all ASs in the routing system. The last column of this table also shows that, if these 30% are a representative sample of all ASs, of the 5.9% of ASs that announce an IPv6 prefix, a vast majority also has a working IPv6 infrastructure. This is captured by the 5.3% of ASs seen in our measurements that have either web clients or resolvers that connect over IPv6. Extrapolating from our measurements, 90% ( 5.3 / 5.9 ) of ASs that announce an IPv6 prefix also has working infrastructure behind it that can make native IPv6 connections to the Internet. 

To get a feeling for the proximity of client to resolver, we looked at how often they are in the same AS. If both are in the same AS, their connectivity is likely arranged by the same entity/ISP. If they are not in the same AS, they could still be under the same ISP (i.e. multi-ASs ISPs), so this provides a lower bound. In Table 4 we compare combinations of IPv4 and IPv6 at clients and resolvers with regard to the AS they are using. The counts in the mixed AS case are caused by clients using multiple resolvers in multiple ASs. Table 4 shows that 79% of clients and resolvers in the IPv4 client-IPv4 resolver-measurement are in the same AS. However, when we look at measurements of IPv6 clients and IPv4 resolvers, we see only 19% of clients and resolvers in the same AS; caused largely by non-native IPv6. If we filter out Teredo and 6to4 we see 63% of clients and resolvers in the same AS. The drop from 79% for IPv4-IPv4 to 62-65% for IPv4-IPv6 combinations suggests that there is a significant fraction of IPv6 users that use native-but-tunneled IPv6, for instance via tunnel brokers, or that some networks announce their IPv6 address space from a different AS then their IPv4 address space (do people do this?). 

Conclusion 

In this article, we show the differences between IPv6 capabilities in countries and cities. In our measurements we see large differences between countries. At the city-level we see "pockets of IPv6" where over 10% of clients in some cities use native IPv6. At the AS-level we see that 5.3% of the ASs we measure have web clients and/or resolvers that can connect to the Internet over IPv6. 

In Part 3 of this article we show how these measurements were actually done.

Footnote:

[1] Cursory inspection of geolocation of clients and the resolvers they use shows that the resolvers usually are in the same country as the clients, based on the geolocation information provided by MaxMind GeoLite, even though it is known that this geolocation database is less accurate for IPv4 infrastructure than for end-user addresses. We also had to deal with the fact that we often see multiple resolver source addresses per client, with an unknown relationship to the number of resolver instances these represent. These are the reasons why we prefer using client IPv4 address geolocation for the resolvers, instead of trying to do IPv4 geolocation on the DNS resolvers. This way we measure the infrastructure that clients in a particular country are using, instead of less accurate geolocation of an unknown number of resolver instances.