The state of IPv6 in the Apple world

With the demise of Apple's own networking protocol AppleTalk, Apple's products are suffering from the same issue as anyone else's: the Internet is running out of addresses. Google, Facebook, Yahoo, Netflix, and others will permanently turn on IPv6 in less than a month with the World IPv6 Launch, so here's everything you need to know about IPv6. The short version? IPv6 has 79,228,162,514,264,337,593,543,950,336 times more addresses than the current IPv4.

Unlike Windows XP, which supports IPv6 if the user turns it on first, the protocol was turned on by default for Mac users as part of the OS X 10.2 Jaguar release in May 2002. This means that Macs running Jaguar (or later) will detect IPv6 routers on the local network and use those to talk IPv6 to the rest of the world. But even if there is no IPv6 router present, your Mac will have special IPv6 addresses for local use ("link local" addresses in IPv6 lingo), so those so inclined can do things like this in the Terminal:

What I did above was use the IPv6 version of the ping command toward my other computer using its local name (hence the .local.).

Once the basic IPv6 foundations were there in Mac OS, Apple started adding IPv6 support to its applications. This was made easy by having the Cocoa network frameworks use IPv6 where available, so applications that interact with the network through these will automatically use IPv6 when appropriate. I believe that all of Apple's built-in applications now support IPv6. However, there is a slight caveat: several of these applications use logic that determines whether you're connected to the Internet or not. Safari seems to handle this well, and works without issue even when the system only has IPv6 connectivity but no IPv4. (At some point in the future this will be routine. Really!)

iChat Messages, on the other hand, will declare that the system isn't connected to the Internet when you manually turn off IPv4. It won't bother to even try to connect to (for instance) Google Talk, while it will do so over IPv6 when the system still has an IPv4 address. Or even when the system doesn't have an actual IPv4 address, but the IPv4 protocol is enabled as usual.

Because all the routers along the path between two IPv6 systems must be upgraded to provide "native" IPv6, most IPv6 connectivity was based on tunnels until recently. With a tunnel, an IPv6 packet is put inside an IPv4 packet so it can be forwarded by existing IPv4 routers until it reaches an IPv6-capable router again. Windows Vista and Windows 7 have IPv6 turned on out of the box, and will try to use the 6to4 or Teredo tunneling mechanisms to talk to the IPv6 Internet if they can't find a local IPv6 router. However, these tunneled packets are sometimes filtered and then the systems think they have IPv6... but it doesn't actually work.

To add insult to injury, Windows makes it exceedingly easy to share such broken IPv6 connectivity over Ethernet or WiFi, creating problems for all users of IPv6-enabled systems. In OS X 10.2 to 10.5, as with pretty much any other IPv6-capable system, IPv6 connectivity is preferred when the local machine has a "real" IPv6 address (not just a local one) and the destination has an IPv6 address in the DNS. So advertising broken IPv6 connectivity means the systems that pick up on that connectivity will try to use it preferentially over IPv4, to their detriment.

In late 2008, Google measurements showed that Apple users were ten times as likely to be IPv6-capable than Windows and Linux users. It's a result helped by 6to4 tunneling in AEBSes (discussed below). Another outcome of this test was that about one in a thousand systems had broken IPv6. Many large websites, such as Google, were reluctant to make themselves reachable over IPv6, because that way, systems would try to connect over IPv6 and not get anywhere. This would leave the user waiting for a timeout, after which the system retries over IPv4.

In response, operating systems started preferring IPv4 connectivity over tunneled IPv6 connectivity. In OS X, this change was made in the 10.6.5 update. But users waiting for applications to realize that IPv6 connections aren't going anywhere isn't exactly up to Apple's user experience standards. So with 10.6 Snow Leopard, Apple further introduced a mechanism that tried to determine whether IPv4 or IPv6 is faster, and then prefer to use that protocol.

During most of the reign of Snow Leopard, this "happy eyeballs" approach had an unexpected side effect. Sometimes sites wouldn't load at all when running IPv6-only, because the IPv6 connectivity was deemed insufficient. However, this issue seems to have been fixed in the 10.6.8 update. In 10.7 Lion, the eyeballs were made even happier because now the system will try to talk to a remote destination that has IPv6 and IPv4 over both protocols and then settle on the one that is fastest. What I see a lot is that a first connection uses IPv6, and then subsequent ones use IPv4, as my (tunneled) IPv6 at home is somewhat slower than my IPv4.

For most users, this is an improvement. If one protocol is slow or fails, the system will use the other, thus minimizing the amount of time you're staring at a non-responsive application. But the downside is that it's really hard to debug IPv6 (or IPv4) for connectivity issues. You have no idea which protocol version is being used for any particular connection. It would be great if Apple could add the mechanism that lets system administrators change the rules that govern IPv4 vs IPv6 preference (the RFC 3484 policy table), something already possible in other operating systems.

View the original article here