IPv6 and the trouble with being happy

A few days ago we unveiled our IPv6 Health Check tool, and it very quickly proved its worth.

There are plenty of other IPv6 website checkers already out there that do a cursory check to make sure that you have some IPv6 addresses for your website, nameservers, and mail servers. Our checker attempts to dig a little deeper. Do your webservers actually respond over IPv6? On all addresses? Do all your MXs have working IPv6 reverse DNS? Are your DNS entries dependent on other zones that don’t have IPv6 nameservers?

One user pointed us towards the results for one of the Regional Internet Registries, initially because it broke the checker. A few bug-fixes (both in our code, and in CPAN modules) later, and we’d determined that there was a real problem behind it: www had two AAAA records, both servers were up, but only one was accepting connections on its IPv6 address. Connections to the other server eventually timed out.

Although this issue would cause real problems to an IPv6-only user, this is exactly the kind of problem that the Happy Eyeballs (aka Fast Fallback) algorithm does a perfect job of masking. If you pick the duff IPv6 server out of the DNS, it’ll almost immediately and silently fall back on an IPv4 server. Even if you use a tool like SixOrNot to show you what connection got used, it may not be obvious that something is amiss, as falling back to IPv4 becomes part of normal operation.

Even in a dual-stack world, such a problem isn’t without side effects, as it would likely lead to an imbalance in the load spread between the two web servers.

We’re continuing to broaden the range of tests performed by the tool in order to help catch the less obvious problems that can occur when IPv6-enabling your site.