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

Emile Aben — Mar 25, 2010 01:40 PM
Filed under: , , , , , ,
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.

 

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. 

Figure 1: Native IPv6 capabilities in Northern Europe

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.

Figure 2: Native IPv6 capabilities in Western Europe

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

Figure 3: Native IPv6 capabilities in Southern Europe

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. 


Figure 4: Native IPv6 capabilities in Eastern Europe (including former Yugoslavia)

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. 

Figure 5: Native IPv6 capabilities in the Middle East

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. 

Figure 6: Native IPv6 capabilities in former Soviet countries

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. 

Figure 7: Native IPv6 capabilities in low-population countries

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. 

Figure 8: Native IPv6 capabilities in selected non-RIPE region countries

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. 

City

measurement

count

overall client

IPv6 capability

native client

IPv6 capability

ASs providing

native IPv6

Ljubljana,SI 467 13.3% 12.6% 8
Paris,FR 1858 12.9% 11.5% 14
Espoo,FI 476 12.2% 9.6% 4
Lisbon,PT 415 11.8% 8.4% 2
Uppsala,SE 301 12.0% 7.3% 5
Brno,CZ 514 8.9% 5.4% 5
Utrecht,NL 373 7.8% 5.1% 4
Athens,GR 1013 6.1% 4.9% 5
Munich,DE 878 4.9% 4.7% 6
Rotterdam,NL 436 6.2% 4.6% 4
Praha,CZ 2997 5.5% 3.9% 16
Chisinau,MD 673 11.0% 3.4% 1
Zürich,CH 729 5.1% 3.2% 5
Oslo,NO 1244 6.4% 3.1% 11
Berlin,DE 1698 5.0% 3.1% 9
Den Haag,NL 503 8.0% 3.0% 7
Amsterdam,NL 2006 4.9% 2.8% 12
Tallinn,EE 466 4.5% 2.8% 5
Szczecin,PL 397 5.5% 2.8% 2
Vienna,AT 2254 5.0% 2.6% 9
Dublin,IE 853 4.8% 2.5% 9
Zagreb,HR 647 3.7% 2.3% 2
Köln,DE 359 5.3% 2.2% 3
Göteborg,SE 395 6.8% 2.0% 4
Frankfurt Am Main, DE 790 3.0% 2.0% 7

  Table 1: Cities with highest IPv6 client capabilities

 

IPv6 and mobile devices 

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. 

number of measurements 1155
mobile client IPv6 preference 0.17%
mobile client IPv6 capability 0.26%
resolver IPv6 capability 2.7%

Table 2: Measured IPv6 capabilities of mobile devices and the resolvers they use

 

IPv6 at the AS-level  

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. 

  Total IPv6

% IPv6

(of Total)

ASs in the routing system (2010-03-10) 33814 1984 5.9%
ASs seen in measurements 11131 588 5.3%
% of ASs seen in measurements 32.9% 29.6%  
ASs seen with web clients 10340 400 3.8%
% of ASs seen with web clients 30.6% 20.2%  
ASs seen with resolvers 9058 465 5.1%
% of total ASs seen with resolvers 26.8% 23.4%  

Table 3: Key statistics on the number of ASs seen in this measurement 

 

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?). 

  measurements same AS different AS mixed AS

IPv4 client

IPv4 resolver

260k 79% 19% 2.2%

IPv6 client

IPv4 resolver

10.8k 19% 77% 4.1%

native IPv6 client

IPv4 resolver

3.33k 63% 34% 3.1%

IPv4 client

IPv6 resolver

13.4k 62% 38% 0.5%

IPv4 client

native IPv6 resolver

12.6k 65% 34% 0.5%

Table 4: Comparison of AS that clients and resolvers in use by these clients are in

   

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.

 

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
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 ...

Visualising Bandwidth Capacity and Network Activity in RIPEstat Using M-Lab Data

As a result of the cooperation between the RIPE NCC and Measurement Lab (M-Lab), you can now ...

RIPEstat 2013 Year in Review

RIPEstat users saw a lot of changes throughout 2013, from support for new query types, such as ...

Internet Disruptions in Sudan

Significant Internet disruptions are happening in Sudan, possibly as a reaction to riots. We use ...

more ...