Skip to end of metadata
Go to start of metadata


The main concern for a web site operator that wants to deploy dual-stack service on his site, is the existence of broken users, i.e., users that could access his site fine while it was available over IPv4 only, but for some reason have problems accessing it when it is made available over IPv6 as well. A list of the most common causes for this is found in Customer problems that could occur

At the time of writing, measurements done by several organisations indicate that at least 1 in 2000 users currently have this problem, see:

Google's presentation at RIPE 61

Redpill Linpro's presentation at RIPE 61

Yahoo's presentation at IETF 77

One thing a web site operator can do about this problem, is to automatically identify these users whenever they visit his web site (which presumably is IPv4-only at that point), and display a warning of some kind that informs the users that they have a problem, and preferably how to fix it, too. That way, when the site is finally dual-stacked, the users will have had ample warning.

It is also useful to warn broken users in this way even after the site has been dual-stacked, as they will in most cases be able to load a dual-stacked page if they are patient enough to endure an initial connection timeout over IPv6.

A much more comprehensive (and probably better) solution for testing the user's IPv6 connectivity is available from falling-sky, the open-source variant of Jason Fesler's

JavaScript code

Add this code near the bottom of your HTML pages. It should work as-is, but see below for some more discussion about how to adapt it better to your site.

Improving the warning

The code above will just throw a JavaScript alert() pop-up, which is likely not what you want. You probably want to replace this with a nicer-looking error box/banner that gives a warning in the same language as the rest of the site, and giving pointers to further information so that the user will be able to solve the problem himself, or alternatively contact you for help.

Hosting of the test elements

You should make sure to use different hostnames for each URL, preferably pointing to different IP addresses. This prevents browsers from doing clever optimisations which could trick the test.

Changing the timeout and number of test elements

The timeout setting should be higher than the time required by a normal client to load the test images, but lower than the systemic connect() timeout of the common operating systems. The lowest such timeout is, to the best of my knowledge, 21 seconds (Microsoft Windows).

You can also modify the number of test elements loaded if you feel that six of them makes the test too heavy-weight. I would not go below one ipv4-only PNG though, because otherwise you might be testing whether or not the machine that hosts the test elements is up or not; or below two dual-stacked PNGs, because a single load failure could be caused by a number of unrelated things, such as the user having a congested Internet connection.

Author and copyright information

The code was written by me, Tore Anderson, and is released into the public domain. Do with it what you wish.

Sites who have this or something similar in production

Please add your site here if you add such a test, so that others can have a look at it for inspiration!

  • No labels