What happens when a web site enables IPv6 access in addition to IPv4 access? Not talking here about the technical steps (configuring IPv6 in the kernel, adding a AAAA to DNS, checking whether logs include IPv6) but rather on the consequences...

There are indeed a couple of OS or browsers which could prefer IPv6 rather than IPv4 even when IPv6 connectivity is broken. This could lead to some users/customers experimenting a slow web server before the OS falls back to IPv4.

Let's first check the current OS reality, the factual data and then how to work around? The conclusions:

there are indeed some badly configured users/browsers who will experiment issues by wanting to use IPv6, statistics is about 0.1% of users;

an upcoming Mac OS release 10.6.5 should vastly improve the situation;

there are work-around techniques (and IETF proposals such as draft-wing-http-new-tech) to fix the above issues.

Current OS IP-version selection Modern operating systems usually prefer IPv6 rather than IPv4. RFC 3484 is about policies to decide whether to use IPv4 or IPv6 and in the case of multiple IPv6 addresses (native, Teredo or 6to4 tunnels), which address to use.

For instance, on all Windows machines, Teredo (2001::/32) addresses are used only when the destination is not reachable over IPv4. The assumption is that Teredo tunnels are quite unreliable.

Until recently, 6to4 was preferred to IPv4 by Windows and Mac OS. This means that a dual-stack host with native IPv4 and a 6to4 IPv6 address (2002::/16) preferred to use its IPv6 6to4 address to contact a dual-stack server. This preference leads to several issues as 6to4 is not the most reliable tunneling technique. Some recent improvements:

Hurricane Electric (and others) added several 6to4 relays which improved the overall latency and resilience of 6to4;

recent Windows now prefer IPv4 rather than 6to4, see this external blog article;

upcoming Mac OS 10.6.5 will also prefer IPv4 rather than 6to4, see this external test report.

Factual data http://ipv6test.max.nl/index.php mentions 0.12% of problems with IPv6, but this is from 93 websites only.

Another http://www.fud.no/ipv6/ (from Scandinavia) reports 0.033% of problems in October 2010.

Google also presented another study where 0.09% of the connections were problematic, again, Mac OS is pointed to as the bad implementation preferring broken IPv6 to working IPv4. Removing Mac OS from the sample gives an error rate of 0.014% only.

Of course, problem is annoying but not catastrophic: the user's experience is about a very slow web site as the browser tries to use the user's broken IPv6 connectivity before falling back to IPv4?

Andrew Yourtchenko, a colleague of mine, also runs its own test which is available freely for any webmaster to measure the impact of going IPv6 only. Thinking after 2012... We can of course also wonder what will be the drawbacks of NOT HAVING a AAAA for a web site after 2012 when some newcomers (tablets, phones, Y-generation) will access a web site only through some NAT (NAT44 or NAT64) where the web site server has no control at all ;-0 Work around techniques If a web site still has fear to lose customers/users, then the easiest way to circumvent the issue is to use another name for the IPv6 users. Rather than having a A (for IPv4) and a AAAA (for IPv6) in DNS, the web site www.example.org can have:

a A for www.example.org (nothing is changing for casual users);

a AAAA for www6.example.org or www.ipv6.example.org allowing testing or friendly users to check their connectivity. Of course, this AAAA points usually to the very same machine of the A.

The latter has been selected in September 2010 by a large German ICT press group, www.six.heise.de , for a couple of weeks before moving to www.heise.de with a A and a AAAA. See their feedback about this experiment.

Other work-around techniques to improve the IPv6 connectivity of web sites include:

running a local 6to4 gateway to ensure that the server -> client path is better for browsers which still select the 6to4 connectivity;

set the IPv6 MTU to 1280 to ensure that no fragmentation happens on the path (this could also be done in some OS by setting the TCP MSS to 1220).