Sunday, April 22, 2012

Great IPv6 article "Measuring Dual Stack Quality" by the web browser

Wow! An ex-colleague of mine (Max) sent me a great article/presentation "Analysing Dual Stack Behaviour and IPv6 Quality" written by Geoff Huston & George Michaelson of APNIC. The presentation is here: https://ripe64.ripe.net/presentations/78-2012-04-16-ripe64.pdf

The article is about dual-stack (both IPv4 and IPv6) situations, and how to handle them in the best way. As expected, the article concludes that a lot of IPv6 connections are not functioning at all. The problem can be on your local system or network, but also at the other end, or somewhere in between. If you would first use IPv6, wait for a time-out, and then use IPv4, your browsing experience would be horribly slow. That should be avoided.

The solution is this:
  • the web browser should both query for A (IPv4) and AAAA (IPv6) addresses. This should happen in parallel
  • then the web browser should measure both and in parallel the speed of the IPv4 and the IPv6 connection using a SYN packet
  • based on that measurement, the web browser should use the fastest connection
So this completely according to the old Dutch engineering's saying "meten is weten, gissen is missen" ;-)

What is unclear to me, is if/how the current browsers have already implemented the above. I used wireshark with Chromium 18.0.1025.151 (Developer Build 130497 Linux) on Ubuntu 11.10, and I did see the A and AAAA lookups, but then only a SYN over IPv6, not over IPv4 (for website http://www.appelboor.com/ which has both a IPv4 and IPv6 address + connectivity).

Some interesting conclusions from the article:

A lot of IPv6 connections are not working: about 40%!



The IPv6 failure depends on the IPv6 technology used: unicast/native is quite good, Teredo/Miredo is quite bad:



The articles also compares the speed of different IPv6 technologies to IPv4: Unicast and 6to4 are faster than IPv4 (!), Teredo/Miredo is slower:




All in all a great article! Kudo's to Geoff Huston & George Michaelson.

No comments: