Posted on Friday, November 14th, 2008 | Bookmark on del.icio.us

Google Report on IPv6 Capable Clients

by Danny McPherson

Given that I’ve seen a number of references to a report Google provided at a RIPE meeting in Dubai a couple weeks ago titled “Global IPv6 Statisics: Measuring the current state of IPv6 for ordinary users“, and several folks comparing it to a report titled Tracking the IPv6 Migration we at Arbor released several months back, I feel obligated to share an observation or two here about this data.

First and foremost, there’s a big difference between measuring end systems or clients capable of usable IPv6 connectivity (what Google measured) and how much actual traffic on [a defined subset of] the Internet is IPv6 (what we measured).  That is, just because some percentage of end systems on the Internet support IPv6, that doesn’t necessarily mean the percentage of IPv6 traffic on the Internet parallels it - i.e., the data points provided are indeed complementary, not at odds.

Basically, as our friend  Iljitsch van Beijnum points out at ars technica from the Google presentation, Google observed that .238% of all users worldwide have working IPv6 connectivity.  Another .09% of users have IPv6 connectivity, but it’s apparently broken in some manner.  What we observed is that .0026% of traffic measured was IPv6 traffic (with noted methodology caveats such as some limitations in supported flow types, Teredo data channels not being measured, etc, and being captive to what the production ISP networks we were measuring were capable of reporting).  There are several other IPv6-related measurements out there, to include Geoff Huston’s IPv6 routing system report, DNS IPv6 enabled queries, and IPv6 address space delegation from RIRs (pdf).

I want to state explicitly that the point of the Arbor IPv6 traffic report certainly wasn’t to discredit IPv6 in any way, quite the contrary, as the goal was to foster discussion on the topic of the Internet community’s prepardness for the exhausiton of IPv4 addresses.  What’s key here is that folks are measuring these datapoints, and solong as we continue to measure and ensure the methodology is well understood, growth rates [of what's being measured] can be observed, and progress can be gauged.

Finally, I suspect that had Google simply put up a traffic graph of Google inter-domain IPv4 v. IPv6 percentages the numbers would be more akin to what we observed - although I might be otherwise pleasantly surprised.

One Response | Add your own



Comment Post by: Steinar H. Gunderson — November 15th, 2008 @ 3:43 pm EST  Reply

Hi,

First of all, I completely agree that the two data points are complementary, and that the observations certainly are not at odds with each other. The scenario outlined in the presentation is more a “what if” scenario — what happens if you add an AAAA record to a typical web site? Or more drastically, if you make an AAAA-only web site, how many will actually be able to see it? I’ll leave further interpretation of the results and differences to others.

There is one minor inaccuracy in your article I feel should be corrected, though; you are saying that “Another .09% of users have IPv6 connectivity, but it’s apparently broken in some manner.” First, as mentioned in the presentation, there’s a lot of uncertainty in this number (if you want to sit down one day and discuss the finer points of the statistics involved, send me an e-mail :-) ). Second, we don’t actually know why these people’s connectivity is broken by an AAAA record — some of it is certainly broken IPv6 (ie., someone forgot a tunnel that no longer works, and the OS doesn’t understand that the packets are being blackholed), but probably not all of it. In particular, there are home routers with built-in DNS servers that convert AAAA responses into garbage on the way — so the users wouldn’t need to have IPv6 _connectivity_ to be broken, the OS would just have to try in the first place.

I would be very interested if someone could investigate this 0.09% (plus or minus quite some!) and break it down somehow (is it really broken tunnels, client software/OSes that is really broken, DNS issues, or something else?). Exactly how to measure this is left as an exercise for the reader. It’s probably a difficult one. :-)

/* Steinar */

Leave a Comment