In Mac OS X 10.2 Jaguar, Apple introduced IPv6 support. Like other IPv6-capable operating systems, Mac OS will prefer IPv6 over IPv4 if it has a choice. That is, until yesterday's 10.6.5 Snow Leopard update. With regular IPv6 connectivity, the newly updated Snow Leopard will still try to connect over IPv6 first, but for IPv6 destinations that are reachable over 6to4, the snowy cat prefers IPv4 instead. It will only connect over 6to4 to IPv6 destinations if there's no IPv4.

The apparent rationale for this move is that 6to4 is responsible for a disproportionate share of non-working IPv6 setups. Measurements by Google show that simply giving www.google.com an IPv6 address means that, subsequently, about 0.1 percent of all Google's users would be unable to connect to the search giant. That is unacceptable to them, not just from a commercial perspective, but also... how are you going to debug this problem if you're unable to search the Web? ISPs are unlikely to hold user's hands if this eventuality comes to pass. Earlier results show that Mac 6to4 users are a huge proportion of the (currently) 0.3 percent of IPv6-capable users. But 6to4 has exactly the properties that make it fail in ways that tend to go unfixed.

6to4 is an automatic tunneling mechanism where IPv6 packets are put inside IPv4 packets so users of ISPs that don't support IPv6 yet can still connect to the IPv6 Internet. The automatic part means that 6to4 generates IPv6 addresses and manages to exchange packets with remote gateways that connect to the "native" (untunneled) IPv6 Internet without the need for any configuration. An IPv6 address range is created by putting "2002:" in front of the hexadecimal representation of the local IPv4 address. Obviously that doesn't work with an address in the 10.x.x.x range that is shared by half the world at home behind a broadband router—only holders of "real" public IPv4 addresses need apply. The remote gateway lives at the address 192.88.99.1—but this same address is "anycasted": multiple operators of 6to4 gateways all use this address and the routing system sends packets to the nearest gateway.

The disadvantage of all this automatic behavior is that if something doesn't work, it's really hard to get around the breakage. 6to4 gateways can be flakey—they are operated for free for the good of the Internet after all. Some ISPs don't carry the 6to4 route in their network, while many universities filter 6to4 packets.

To add insult to injury, Windows Vista and 7 systems always enable 6to4 automatically if they have a public IPv4 address. If they're configured with Internet connection sharing, those Windows systems will advertise their 6to4 IPv6 connectivity on the local network. Of course this connectivity rarely works because Windows also loves to firewall for the previously mentioned reasons. Note that Windows systems will try to use 6to4 to other 6to4 users but IPv4 if the choice is between IPv4 and 6to4. However, as far as I can tell, this is an implementation peculiarity and not a conscious decision by the Windows networking team.

So good riddance to 6to4? Some people certainly think so. And if this helps everyone get over their reluctance to add IPv6 addresses to their Web properties, that's certainly a good thing. I'm not holding my breath, though. "Once we have X% IPv6 deployment will really take off!" stories litter the 15-year-long road that got us to the current 0.3 percent IPv6 deployment number.

And this change has a big downside: it's no longer possible to just turn on 6to4 and start experimenting. Sure, technically you still have IPv6 connectivity if you add the 6to4 virtual interface to your Mac's network configuration or by setting IPv6 mode to "tunnel" on your Airport Extreme base station—as long as you have that public IPv4 address—but if you then go to www.kame.net you won't see the KAME dance. Only when a site has just IPv6 (such as ipv6.google.com or v6.facebook.com) or if you can instruct your application to specifically ask for IPv6 will you be using the new protocol. So basically, the infamous 6to4 functionality in the Airport Extreme base stations is now rendered useless. As very few ISPs offer IPv6 connectivity to consumers, the only alternatives are non-automatic tunnels, which aren't always trivial to set up.

It would of course be much better if users could choose which type of 6to4 behavior they prefer—even if the vast majority of users stick to the default setting. All other current systems allow this through a policy table that instructs the system how preferred (ranges of) IPv6 and IPv4 addresses are, as per RFC 3484. I entered a feature request for RFC 3484 support in Apple's bug reporter in April 2007, but so far the request is still listed as "open." At least it's not "functions as intended." In the meantime, the bug that makes Snow Leopard ignore certain IPv6 addresses in the DNS mentioned earlier (which I've been assured has nothing to do with CNAMEs) is still there. There's always hope for 10.6.6.

Oh, and as I was writing this, IANA gave out another block of 16.78 million addresses. That's the 15th this year, with 11 left.