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:
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 timeoout over IPv6.
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
Hosting the test elements yourself
The .ipv6test.redpill-linpro.com URLs are hosted on a virtual server in one of Redpill Linpro's data centres in Oslo, Norway. While it should have no problems serving a couple of hundreds of thousands of hits per day, if you're hosting a *really big site you might want to host the test elements yourself instead, to make sure the elements will be as available as the main site from where they're included.
If so, you should make sure to use different hostnames for each URL, all pointing to different IP addresses. This prevents browsers from doing clever optimisations which could trick the test.
Please note: The test elements on *.ipv6test.redpill-linpro.com are hosted as a community service on a best-effort basis with absolutely no guarantees for availability and uptime.
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.
That said, I would appreciate it if you would let me know if you implement something like this on your page, especially if you will be using the *.ipv6test.redpill-linpro.com URLs for hosting of the test elements. This would allow me to notify you if I for some reason need to take them down or make some changes.
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!
- VG Nett (Norway's largest web site)