IPv6 Measurements - A Compilation

The increased deployment of IPv6 that has accompanied the exhaustion of the free IPv4 address pool has encouraged a wide range of organisations and individuals to conduct measurements related to IPv6 data and traffic. These studies range from analyses of IPv6 take-up per country and per organisation, to technical examinations of the performance of IPv6-enabled websites.

We list below the organisations and individuals that produced these studies, including links to their measurements, explanations of their methods and the results of their studies. There is a wide range of statistics and information related to all aspects of IPv6 deployment, so, where possible, we have tried to make connections between related studies. However, we draw no conclusions from the measurements, instead preferring to simply present the results for your own analysis.

What we would like to hear from you are suggestions for further IPv6 measurements or studies that can help you in your operations. How would you  chose to measure the growing deployment of IPv6? Have you set criteria for when you will deploy IPv6, e.g. when 25 percent of End Users are IPv6-capable? Let us know what information and analysis would be helpful to assist you in the deployment of IPv6. And would measurements influence your decision to deploy IPv6 or not?

As always, you can let us know what you think by [mailing us at RIPE Labs or leaving a comments in the forum].

Studies:

1.     APNIC
2.    Comcast
3.    Hurricane Electric
4.    IPDN
5.    Google
6.    TNO & GNKS
7.    Max.nl
8.    Eric Vyncke (Cisco)
9.    Tore Anderson (Redpill Linpro)
10.  Mark Prior (Juniper Networks)
11.  CAIDA

12.  RIPE NCC

1. APNIC

Source: 

www.potaroo.net/presentations/2008-10-13-ipv6-deployment.pdf

Description:

Geoff Huston and George Michaelson from APNIC have been measuring IPv6 deployment by looking at various datasets: BGP routing table, DNS server traffic and web server access.

From BGP data they found 15% of transit AS’s are playing with IPv6 in some fashion, while from web server access logs 0.4% of end-hosts was IPv6 capable. Due to widespread NAT in IPv4 and the fact that the websites that were measured where RIR websites, they estimate that the end-host IPv6 capability was closer to around 0.2% in October 2008.

Source:

bgp.potaroo.net/iso3166/v6cc.html 
 

Description:

On this webpage Geoff Huston compares IPv6 allocations and advertisements to country level indicators such as GDP, population and number of Internet users. It shows Australia and the Vatican City leading the way in terms of number of /48 equivalents per Internet user.

More Information:

Geoff Huston also published an article describing the findings:
www.potaroo.net/ispcol/2008-04/ipv6.html

2. Comcast

Source: 

ipv6monitor.comcast.net

mnlab-ipv6.seas.upenn.edu

Description:

Comcast together with the University of Pennsylvania measured the size of the IPv6 Internet by looking at the Alexa top one million websites (see www.alexa.com ). The tool is looking for A and AAAA records for all the sites listed on Alexa. All those websites were then probed to find out if there is IPv6 content and if the download times for IPv4 and IPv6 content differs. It was found that about 0.15% of these websites were reachable directly via IPv6.

RIPE Labs did an interview with Alain Durand of Comcast and found out more details about the measurements: labs.ripe.net/content/ipv6-monitor . 

3. Hurricane Electric

Source:

bgp.he.net/ipv6-progress-report.cgi

Description:

Mike Leber from Hurricane Electric did a number of IPv6 measurements looking at Top Level Domains (TLDs), DNS name servers, Usenet servers and web servers. He found that out of 280 TLDs 224 (80%) had IPv6 name servers. He also looked at the reverse DNS and found that 36% of IPv6 reverse DNS servers were reachable via IPv6. And the percentage of IPv6 reverse DNS name servers where IPv6 is as fast or faster than IPv4 (within 1ms) was 69.5%.

He also found that the percentage of AS's currently running IPv6 is 5.5%.
Just like Comcast (see above) Mike Leber also looked at the Alexa list of the most popular websites and checked if they had AAAA records registered in the DNS. Out of the top million domains on the Alexa list, he found 1,459 domains (or 0.15%) with a direct IPv6 address (he also searched for ‘www’ and ‘ipv6’ hosts within the domain). This is consistent with the Comcast results (see above).

More Details:

More detailed results and measurements can be seen on the URL above. Mike Leber had the idea for this test while writing a paper called “Going Native” ( bgp.he.net/going-native.pdf ) about Hurricane's experience of adding extensive native IPv6 peering as a result of a core router and backbone upgrade.

4. IPDN

Source:

www.ipdn.tw/

Description:

Kuo-Wei Wu from Taiwan produced a number of statistics showing IPv4 and IPv6 address allocations and announcements per country. One can search by various criteria: RIR region, country, year, month, addresses allocated vs. advertised, and so on. This shows, for instance, that in November 2009 in France the total number of IPv6 addresses allocated is very close to the number of IPv6 addresses advertised. By comparison: in the Netherlands the number of advertised addresses is only a fraction of the number of allocated IPv6 addresses.

More Details:

There is a lot more information on this site: Upcoming events, news and articles related to address allocation policies, trends and services, information about ccTLDs and statistics on number of domains registered per TLD. One can also find an IPv4 Exhaustion Counter that shows the number of unallocated IPv4 addresses in the IANA database going down. This is based on data taken from the IANA IPv4 Address Space Registry and the IPv4 Address Report compiled by Geoff Huston of APNIC. 

5. Google

Source:

www.ripe.net/ripe/meetings/ripe-58/content/presentations/Colitti-IPv6atGoogle-RIPE58.pdf

Description:

Google was trying to find out how common IPv6 was among their users and how much IPv6 still breaks things on a network. The measurements were done by asking a number of Google users to participate in an IPv6 experiment where their browser was asked to perform a background request. The test recorded the user’s IPv4 and IPv6 addresses (if applicable), the request latency and some browser and operating system details. At the time of  the measurement, 0.238% of the users performing the test had useful IPv6 connectivity. And 0.09% users had broken IPv6 connectivity. Google concluded that there are at least 1 million distinct IPv6 users on the Internet.

Google also looked at the type of connectivity and found that almost 30% were running native IPv6 and that 6to4 was by far the most popular transition mechanism. It is interesting to note that France is almost 95% native IPv6 where as the US and Canada is running almost entirely on 6to4.

Google concluded that IPv6 deployment is still very low, but that it is growing every week. The type of connectivity is used depends heavily on the operating system used. 

6. TNO & GNKS

Source:

www.ipv6monitoring.eu/

Description:

This is a project that runs for two years, having started in January 2009. A consortium of TNO and GNKS is doing the IPv6 deployment research through metrics analyses, questionnaires and measurements in order to determine the number of IPv6-enabled users in Europe in the period 2009—2010. This project was commissioned by the European Commission.

The measurements are described in a White Paper entitled “IPv6 deployment monitoring in Europe”: www.ipv6monitoring.eu/project-files?func=fileinfo&id=4

The consortium is measuring the percentage of unique users that is able to connect to the IPv6 Internet and access the most important content and services without noticing any difference. Three set of measurements are being used to do this: 

• The number of IPv6-enabled users is measured using a method similar to max.nl and Google
• The number of IPv6-enabled websites is measured, examining both DNS and website access
• The performance of IPv6-enabled websites compared to IPv4-enabled websites is measured using a methodology based on an ITU-T standard

The results will be interesting to compare to the measurements Comcast and Hurricane Electrics are carrying out in this area.

More Details:

There is much more information on the website above. The statistics produced by IPDN (see above) can also be found on it.

A summary of the survey GNKS conducted can be found at:
labs.ripe.net/content/ipv6-panel-discussion-results 

7. Max.nl

Source:

ipv6test.max.nl

Description:

This is a website aimed at web server operators set up by Sander Steffann. The site is in Dutch, but the check is pretty straightforward and can be used by anybody.

The test was created because providers hosting websites were worried that making their website reachable over IPv6 would have a negative impact on their customers.

Through a javascript it offers a test where one can check what the impact would be on the visitors if a web server would be set up to offer services over IPv6. It tests native IPv4, native IPv6 and dual-stack IPv4/IPv6. At the moment, this IPv6 test has been used by 64 websites. Up to now more than 6.5 million tests have been performed in total. 0.13% of the tests showed that a visitor would have problems reaching the website once it is reachable over IPv6.

More Details:

There are detailed instructions on the web site about how to perform the tests. There is also a demo page where one can follow the progress of the test while it is going on. It also gives possible reasons that could cause the dual-stack test to fail. 

8. Eric Vyncke (Cisco)

Source:

www.vyncke.org/countv6/stats.php

Description:

This site provides statistics showing to what extent visitors to this particular website are IPv6-enabled. It uses http-redirect to link dual-stack and IPv6-only measurements. One can sort the data by various criteria: only IPv4 or only IPv6, only IPv6-preferred or only IPv4-preferred, dual-stack or only Freebox, 6to4 or Teredo. One can also see what operating system the visitor is using. There is also historical data.

The overall results are that between 10% and 13% of Internet hosts are IPv6-enabled. This seems high compared to other measurements, probably because this check is not widely published yet and therefore only used by IPv6 enthusiasts.

The results can be seen in graphical form or in table format. It is also explained how the tests are performed. 

9. Tore Anderson (Redpill Linpro)

Source:

[UPDATE: fud.no/ipv6/ now holds daily updated information , and hit Slashdot ]

lists.cluenet.de/pipermail/ipv6-ops/2009-November/002658.html
 
lists.cluenet.de/pipermail/ipv6-ops/2009-December/002707.html

Description:

The first URL above points to a mail Tore Anderson from Redpill Linpro wrote to a mailing list in Germany ( ipv6-ops _at_ lists.cluenet _dot_ de ) describing an experiment he conducted in Norway trying to find any eventual breakage that would be caused by dual-stack web sites. He recently published an updated version (see second URL).

In summary: On the dual-stack host, 0.217% of all hits are lost - IPv6 penetration (preference over IPv4) is at 0.403% over November 2009.

Tore found out that the Opera web browser (coupled with Windows Vista or newer, which automatically configure Teredo and 6to4) is causing most of the problems, because it unconditionally prefers IPv6 to IPv4. He believes that until Opera has released a fixed version, it will be difficult to convince customers to dual-stack their production websites. It is worth mentioning that this problem seems to be prominent in Norway, because the market penetration of Opera (a Norwegian company) is likely to be higher than in other countries. 

10. Mark Prior (Juniper Networks)

Source:

www.mrp.net/IPv6_Survey.html

Description:

Mark Prior has done some measurements to quantify how well major organisations are embracing IPv6. In order to get some real data, he identified a number of services and used them as an indicator of IPv6 usage: Web, email, DNS, NTP and Jabber.

Initially, he was looking at Internet2 members and other universities. He also added a number of ISPs and other organisations that asked to be included and who provided their domain names for the test. RIR sites are also listed.

The results currently show that out of 924 web servers 100 were accessible via IPv6. That is a percentage of 10.8%, which is high compared to other measurements. This is likely caused by the fact that he is looking at sites that are already more likely to be embracing IPv6, such as academic organisations, large ISPs and RIRs.

More Information:

The URL above contains more information about the method used for the test and the detailed results. Mark Prior would be happy to accept suggestions on other organisations or groups of organisation to include in the measurements. For suggestions, please contact Mark Prior: mrp at mrp dot net 

11. CAIDA

Source:

www.caida.org/research/topology/as_core_network/

Description: 

Using their Archipelago measurement infrastructure, CAIDA maps the macroscopic Internet topology both in IPv4 and IPv6. They use a vizualisation method that illustrates both the extensive geographical scope as well as the rich interconnectivity of nodes participating in the global Internet routing system. The IPv6 graph grew from 486 AS nodes in January 2008 to 515 nodes in January 2009.

12. RIPE NCC

is-portal.ripe.net

Description:

The RIPE NCC offers several measurement services supporting IPv6: 

• Test Traffic Measurement
• Routing Information Service
• DNSMON
• Hostcount++

www.ripe.net/ttm Test Traffic Measurement (TTM) is the RIPE NCC’s active measurement network. Currently, TTM has over 50 IPv6-enabled measurement nodes around the world and it continuously measures one-way delays, loss and jitter. The www.ris.ripe.net Routing Information Service (RIS) collects BGP routing information. The RIS currently supports IPv6 on 13 remote route collectors around the globe. Apart from raw data, the RIS features several query and visualisation tools such as BGPViz ( www.ris.ripe.net/bgpviz ) and the RIS Dashboard ( www.ris.ripe.net/dashboard/ ).

dnsmon.ripe.net DNSMON measures reachability and availability of DNS root and TLD servers. DNSMON currently monitors more than 35 IPv6 enabled TLDs as well as the whole DNS root zone.

www.ripe.net/is/hostcount Hostcount++ is also IPv6-enabled and is able to count IPv6 hosts for TLDs that allow AXFR transfers towards the Hostcount++ service.

netsense.ripe.net In an effort to unify the data presentation of the RIPE NCC’s measurement services, NetSense has been created and fully supports IPv6.

Thanks to Emile Aben for all his help with this article.

Well, first of all a big THANK YOU! to everyone doing measurements and providing us with the summaries and references!

Somehow related to the comparisons, percent-wise, of the IPv6-based population on the 'net versus the IPv4-world, I am struggling with a similar(?) issue: how do I get a representative comparison of IPv6-based performance to sites which my users traditionally access by way of IPv4?

Of course, my first hope was the TTM-cloud. 

I do have some ideas, but I'd like to see a discussion started - somewhere - to find out what is easy to implement and what is useful for a bigger community at the same time.

Hi,
 
Brian Carpenter has been posting about this survey on several IPv6 operations related mailing lists. It is aimed to the ISPs, and the goal is to provide facts for the IETF document: ".
 
Here is the link to the survey: www.cs.auckland.ac.nz/~brian/ISP-v6-QQ.html
 
Regards,
Vesna
 

On request I created a breakdown for Africa, similar to the breakdowns in labs.ripe.net/content/measuring-ipv6-web-clients-and-caching-reso... . We have few measurements here, so take this with a grain of salt. I excluded all countries with less then 15 measurements; all of them didn't have any IPv6 capabilities that we detected.

It is good to see South Africa and Kenya with client IPv6 capabilities, but surprising to see no IPv6 connections from Egypt. The IPv6 resolvers that we see for clients in Nigeria and Algeria are in big global ASs (AS701 and AS174 respectively), wheras resolvers for clients in Tunisia are in AS2609 (TN-BB-AS/Tunisia BackBone AS).

 Hi,

a few suggestions on why you're seeing higher hb.db client loss than I do:

• How large are the HTTP requests/responses?  If you're exceeding 1280 octets in either direction, you could be observing PMTUD issues.  I've not attempted to measure that at all - in my setup, the requests are all small.  My plan is to use an IPv6 MTU of 1280 and advertise a TCP MSS of 1220 when I dualstack a "real" web site, just to avoid this potential problem.  Maybe later I will attempt to measure how much of a problem it really is, if at all.
• How is your 6to4 connectivity?  Do you run a local 6to4 return relay to which 2002::/16 is routed, and do you announce a public relay (192.88.99.0/24) to peers?  (I do both.)  From what I've been able to determine, unnecessary use of 6to4 is the cause of almost all brokenness.  Anycasted 6to4 is way less reliable than IPv4, so all you can do is to try to make it as good as possible in order to improve the client loss percentage.

When it comes to determining causes for lost clients, pay very close attention to users of Opera in versions earlier than 10.50 on Windows Vista or newer ( more info ), and all users of Mac OS X ( more info ).  Both of these setups will prefer 6to4 much more than they should, which in turn causes most of the problems.  If I simply filter away all log lines with Opera and OS X in the User-Agent field before running my scripts, the measured client loss is _very_ close to 0% (even negative, on individual days).

I have one final suggestion as to why you're seeing such a high client loss:  You write that «[a]ll measurements where the h4.d4 test doesn't succeed are discarded».  I really think you should not do that, because you then assume that _all_ of the hb.db failures are due to the dualstacking.  In reality, all types of requests, both the h4.d4 ones and the hb.db ones, fail from time to time, for reasons that have nothing to do with IPv6 or dualstacking (in the h4.d4 case, it must be all of them).  It stands to reason that there's a percentage of the hb.db failures that are caused by the same reasons.  For instance, my numbers from VG for yesterday are:

 [N]    linkgen.php hits (num of UUIDs generated):            2087303
[N_OK] UUIDs that was seen on both dualstack and ipv4-only:  2061803 (98.778% of N)
[Nd]   UUIDs that was seen on dualstack only:                   1362 (0.065% of N)
[Ns]   UUIDs that was seen on singlestack only:                 2683 (0.129% of N)