Test your connectivity for World IPv6 Day

Tim Chown tjc at ecs.soton.ac.uk
Thu Jun 2 11:18:20 CEST 2011

On 1 Jun 2011, at 19:11, Tassos Chatzithomaoglou wrote:

> Stefan Neufeind wrote on 01/06/2011 19:32:
>> On 06/01/2011 06:28 PM, Guillaume.Leclanche at swisscom.com wrote:
>>>> The reason Chromium was "working" fine is because it was using IPv4 in
>>>> order to connect to the dual-stack sites included in eyechart. As
>>>> someone else pointed before, it would be good to have IPv4/IPv6
>>>> differentiation shown.
>>>> For everyone interested, from http://codereview.chromium.org/7029049
>>>> When a hostname has both IPv6 and IPv4 addresses, and the IPv6 address
>>>> is listed first, we start a timer (300ms) (deliberately chosen to be
>>>> different from the backup connect job). If the timer fires, that means
>>>> the IPv6 connect() hasn't completed yet, and we start a second socket
>>>> connect() where we give it the same AddressList, except we move all
>>>> IPv6
>>>> addresses that are in front of the first IPv4 address to the end. That
>>>> way, we will use the first IPv4 address. We will race these two
>>>> connect()s and pass the first one to complete to
>>>> ConnectJob::set_socket().
>>> Doesn't this sound like an implementation of Happy Eyeballs (http://tools.ietf.org/html/draft-ietf-v6ops-happy-eyeballs-02) ?
>> Hi,
>> not fully according to the spec as this post says:
>> http://www.ietf.org/mail-archive/web/v6ops/current/msg09017.html
>> but close. I guess the basic idea is similar ...
>> Kind regards,
>>  Stefan Neufeind
> What is interesting is that it started as a temporary hack for IPv6 world day (like Microsoft did recently in http://support.microsoft.com/kb/2533454), probably it didn't work as expected, so the fallback mechanism (happy-eyeballs-like) was chosen instead..
> http://code.google.com/p/chromium/issues/detail?id=81686

The main difference is the Chrome code gives IPv6 a fixed 300ms headstart, while HE has a tuneable 'p' value that allows IPv6 or IPv4 (if p is negative) to have a variable headstart (recommended p=100ms at startup).  HE also allows p to react to observed behaviour, potentially on a per prefix basis.

So HE is more complex, but Chrome provides a fix for the (potential) long timeout when IPv6 connectivity is down before the browser falls back to IPv4.


More information about the ipv6-ops mailing list