In wake of World IPv6 Day, browsers resist IPv6 brokenness—but should they?

[nsane.forums]

At a plenary session during the Internet Engineering Task Force (IETF) meeting in Quebec City, Canada two weeks ago, World IPv6 Day was rehashed at some length. It took place on June 8 this year, and Google, Facebook, Yahoo and others turned on IPv6 for 24 hours in an effort to flush out broken IPv6 setups. Immediately after IPv6 day, and again six weeks later, we noted that there didn't appear to be much breakage to speak of. But at the IETF meeting, several of the Web companies had a little more information to share (PDF).

The most interesting presentation came from Cisco's Mark Townsley. Unlike companies such as Google, Yahoo, Limelight, and Akamai, Cisco isn't a Web company. It does make most of its money through cisco.com, though; as such, it was hard to convince management to participate in IPv6 day, since nobody really wants to put any part of $30 billion in revenue at risk. But apart from the argument that Cisco should be "eating our own dogfood," the management found one argument compelling: many others would be doing the same thing, so this was the one and only chance to try it without much risk of a customer backlash. 1.11 percent of all traffic to www.cisco.com was IPv6 on June 8 and zero IPv6-related support tickets opened that day.

Google's Lorenzo Colitti showed a graph indicating slowly declining levels of "issues" with IPv6, but this number excluded users of Google's Chrome browser. For Chrome, Colitti reported a reduction in problems by as much as 80 to 90. However, this figure only applies to the user experience; Chrome now has a "fast fallback" option which makes the browser switch to IPv4 if an initial IPv6 connection attempt doesn't progress in 300 milliseconds. (According to Colitti, Firefox implements a similar workaround.)

Of course, such fixes only apply to browser use—other applications still experience much longer timeouts when using a machine that thinks it has IPv6 connectivity when IPv6 doesn't actually work.

As of Mac OS 10.7 Lion, Apple implements something similar in its lower layer networking frameworks. This means that all applications that use these frameworks automatically gain this user-friendly behavior. As explained by Apple's Josh Graessley on the company's IPv6 dev mailing list, the address (IPv4 or IPv6) that has the lowest minimum round trip time is initially selected for connections. Round trip times are continuously measured during TCP connections and stored for some time in the system's routing table. If this information isn't available, the system uses a set of rules to determine which addresses are "better" than others. However, unlike Windows, FreeBSD, and Linux, Mac OS doesn't allow the user or system administrator to change these "RFC 3484" rules.

There's also some DNS timeout magic going on in Apple's implementation of decisions based on previous RTT measurements (which was also present in Mac OS 10.6, but remained buggy until version 10.6.8). In Chrome's approach, it tries IPv6 first and the browser only falls back to IPv4 if there is no answer over IPv6 within 300 milliseconds. Apple's approach layers several mechanisms on top of each other, each dependent on ever changing timing information, so it becomes pretty much impossible to predict whether the system is going to connect over IPv6 or IPv4.

For users, this doesn't matter. If IPv6 doesn't work, their Mac will connect over IPv4 automatically and the broken IPv6 connectivity is never an issue. However, for system and network administrators, this behavior can be extremely problematic. Applications, operating systems, and various network devices change on a regular basis, and it's quite common for these changes to break connectivity. Broken IPv4 connectivity immediately leads to complaints and is thus fixed very quickly. But if broken IPv6 connectivity is now hidden by numerous "happy eyeballs" algorithms, this means that any broken connectivity is never even detected, let alone fixed. This makes it easier to enable IPv6 on large Web properties without any problems, but makes it harder to learn much from the experience.

All of this seamless fallback to IPv4 is also going to make it harder to eventually turn off IPv4, because lots of people who think they have IPv6 will in fact have broken IPv6 without realizing it. The worst part about this is that Apple refuses to allow power users to disable this automatic behavior or change the RFC 3484 policies used by their system, frustrating efforts to find and fix IPv6 brokenness.

However, not all software uses Apple's networking frameworks, which leads to some interesting results. At home, I use a tunnel so IPv6 packets are carried in IPv4 packets, which makes IPv6 slower than IPv4. This ensures I get two different results when I test my IPv6 connectivity. Using Safari, Apple's browser, my system only connects over IPv4 when it has the choice between IPv4 and IPv6, since that's the faster option. ipv6test.google.com even tells me I don't have IPv6. But Firefox uses lower-layer Unix network code and thus connects over IPv6 where possible. So, with that browser, Google's IPv6 test tells me I do have working IPv6.

I'm afraid that the efforts by Google (Chrome), Mozilla (Firefox), and Apple to hide broken IPv6 will produce a short-term victory, but at a cost of delaying the long-term solution.

View: Original Article