Will I lose customers if I enable IPv6 on my web site?

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/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/browser falls back to IPv4.

Let’s first check the current OS reality, the factual data and how to work around?

The conclusions:
– there are indeed some badly configured users who will experiment issues
by wanting to use IPv6, statistics is about 0.1% of users;
– an recent (Novembre 2010) Mac OS release 10.6.5 vastly improves the situation;
– there are work-around technique 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 [[This means that a dual-stack host with native IPv4 and a 6to4 IPv6 address (2002::/16) prefers to use its IPv6 6to4 address to contact a dual-stack server.]] by Windows and Mac OS which lead 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
– Mac OS 10.6.5 (November 2010) also prefers IPv4 rather than 6to4, see this external test report

Factual data mentions 0.12% of problems with IPv6, but this is from 93 websites only.

Another (from Scandinavia) reports 0.033% of problems in October 2010. Another source of data is (and specifically for this web site).

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 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 Y. 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 arounds

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 can have:
– a A for (nothing is changing for casual users);
– a AAAA for or 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,, for a couple of months before moving to with a A and a AAAA. See their feedback.

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).