The future is forever: the state of IPv6 in the Apple world

The new Internet is upon us. Apple has work to do but there's no reason to fear.

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.

Avoiding broken IPv6

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 Airport Extreme base stations, or 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.

I would be interested in another article (or two) like this focusing on how the Windows and GNU/Linux IPv6 implementations differ, where progress still needs to be made and such. This article seems to be focused on the Apple side of things, when in reality Apple devices (in the desktop space) are a very small segment.

This is all very nice, but until ISPs start handing out IPv6 prefixes to people, it's all moot. The only people affected will be network nerds that set up IPv6 tunnels.

While your statement is true for home users at the present time, corporate users will likely see some benefits and it's also important to make sure that when ISPs due implement IPv6 that older devices will still be able to network.

This is all very nice, but until ISPs start handing out IPv6 prefixes to people, it's all moot. The only people affected will be network nerds that set up IPv6 tunnels.

Well, that is kind of the point of World IPv6 launch, having some of the major ISP's finally handing them out to consumers. Note that most business ISP's (over here at least) has been handing out native IPv6 for years - if you ask for it - which nobody really does, oh well..

Oh, fwiw, I was involved in a (native) IPv6 rollout to about 70 office users a couple of weeks back. Mixed Windows 7, Linux, OS X 10.6/10.7 and IOS, and - gasp - nothing broke. No user have noticed they got it. Which is how it should be I guess - even though I'd like it if someone came to me and went like OMG my computer has IPv6 - you rock dude!! ;-)

This is all very nice, but until ISPs start handing out IPv6 prefixes to people, it's all moot. The only people affected will be network nerds that set up IPv6 tunnels.

Well, that is kind of the point of World IPv6 launch, having some of the major ISP's finally handing them out to consumers.

Before we talk about what the ISPs do, the problem is surely crappy routers?

AEBS and most of the routers I can buy at Best Buy may be IPv6 capable, but the box most people have to use to connect to the outside world is some piece of crap made by Scientific Atlanta, like the 2Wire boxes and their U-Verse successors. It is THOSE that need to made IPv6 capable before anything more can occur.Yes, Comcast's versions of these boxes may not suck, but how about everybody else's?

"In the IPv4 world this problem is largely solved by having a protocol that allows the operating system or applications to ask a NAT device to forward incoming sessions toward a specific TCP or UDP port number to the requesting device. So far, there is no protocol like this for IPv6."

PFSense supports UPNP to punch holes in the IPv6 stateful firewall. A protocol already exists, unless they want to extend it in a way that would break it.

Sorry, if my question is off-topic since it's about Linux (using Chakra, which is based off Arch Linux).

So, the OS looks for a IPv6 compatible router but if it doesn't find one, the connection times out? I know I have to disable ipv6 at the Grub2 level to have a stable internet connection but I never understood why! But then again, before I disabled ipv6, after refreshing a web page a few times my internet connection worked. Why does that happen, does the OS just give up on using ipv6. Also, does having this problem mean that my laptop can handle ipv6 but my router cannot?

IPv6 doesn't have much to offer the average non-technical home users. As such, it will be years before there will be a compelling reason for the average consumer to be concerned with it, and many years before they will HAVE to be concerned. No websites which cater to consumers will risk not being accessible via IPv4. Contrary to popular propaganda, we have not "run out" of IPv4 addresses; the ISP space may be all assigned, but it's not all "being used." A huge percentage of the assigned IP space is being held by organizations who have no current use for it. In many cases, huge blocks were purchased by companies, governments, and universities years ago with the expectation that they'd need one IP address for each device on their network (a pre-NAT concept), and now very little of the space is actually used.

The IPv6-maniacs have made a lot of noise, even recently very publicly taking Apple to task for making the Airport Utility easier for consumers to use, but they have no case. IPv4 is tried and true and, for the foreseeable future, easier for ISPs to troubleshoot with consumers. IPv6 has its place, but it's not in the typical web-surfing, Netflix-watching home.

My home router isn't ipV6 aware. I'm waiting for the National Broadband Network (Australia's NBN project) to rollout (within 3 years, apparently), then I'll have something orders of magnitude faster, and ipV6 should have silently taken over the world.

Great article. I now have a slightly better idea on how IPv6 works in general as well as clearing up a few questions I've had on IPv6 NAT / DHCP.The SLAAC implemetation is a great feature regarding DNS search lists, it should make for some fast management and troubleshooting. I just hope it's just as good in practice, as it is in theory.

Sorry, if my question is off-topic since it's about Linux (using Chakra, which is based off Arch Linux).

So, the OS looks for a IPv6 compatible router but if it doesn't find one, the connection times out? I know I have to disable ipv6 at the Grub2 level to have a stable internet connection but I never understood why! But then again, before I disabled ipv6, after refreshing a web page a few times my internet connection worked. Why does that happen, does the OS just give up on using ipv6. Also, does having this problem mean that my laptop can handle ipv6 but my router cannot?

I don't know much about Arch, but if you have NetworkManager, you can disable IPv6 without messing with grub:

In many cases, huge blocks were purchased by companies, governments, and universities years ago with the expectation that they'd need one IP address for each device on their network (a pre-NAT concept), and now very little of the space is actually used.

AFAIK, ICANN never allowed any organization to "purchase" IPv4 blocks. One submitted an application with justification and was either granted or denied the request. Annual re-justification was also required (if I remember correctly).

I have native IPv6 through my Australian ISP (Internode), who have been running it for years now. The issue with the Airports is that while they support some IPv6 deployment mechanisms, they do NOT support IPV6 Prefix Delegation (PD). This is how Internode delivers IPv6 & how many ISPs in future will (provided they aren't cheating and tunnelling it like some do).

Bryn: the 4th generation AEBS that Apple started selling in late 2009 (and I assume the current 5th gen too) does support DHCPv6 prefix delegation, I've seen the AEBS ask for a prefix from a DHCPv6 server. So if it doesn't work for you, one of three things is going on:

- you have an older AEBS- the way in which the AEBS and your ISP do DHCPv6 PD isn't compatible- you are using PPPoE, which the AEBS reportedly won't do DHCPv6 PD over

I'm currently doing about 4% of my home network traffic over IPV6. My home has access using tunnelling which is pretty reliable, and my hosted virtual server has dual stack with native IPV6. Asia/Pacific has already depleted their allocatable pools, new ISPs or organisations asking are getting small allocations now. Europe will be in the same position in a couple of months at current rates.

I'm expecting IPV6 traffic to double every 12 months or so for the next several years, and IPV4 to cease being routable over the global net within 10 - 12 years or so. In the meantime the transition will probably create many complexities and security issues. IPV6 tunnelling certainly gets through existing firewalls efficiently, and those using it experimentally don't always have full knowledge of their organisation's security needs as their first priority.

IPv6 doesn't have much to offer the average non-technical home users. As such, it will be years before there will be a compelling reason for the average consumer to be concerned with it, and many years before they will HAVE to be concerned. No websites which cater to consumers will risk not being accessible via IPv4. Contrary to popular propaganda, we have not "run out" of IPv4 addresses; the ISP space may be all assigned, but it's not all "being used." A huge percentage of the assigned IP space is being held by organizations who have no current use for it. In many cases, huge blocks were purchased by companies, governments, and universities years ago with the expectation that they'd need one IP address for each device on their network (a pre-NAT concept), and now very little of the space is actually used.

The IPv6-maniacs have made a lot of noise, even recently very publicly taking Apple to task for making the Airport Utility easier for consumers to use, but they have no case. IPv4 is tried and true and, for the foreseeable future, easier for ISPs to troubleshoot with consumers. IPv6 has its place, but it's not in the typical web-surfing, Netflix-watching home.

"IPv6 doesn't have much to offer the average non-technical home users."

Just wait for IPv6 Multi-cast. A single person with a 5Mb upload pipe could stream HD video to everyone on the internet. Yes, IPv4 supports multi-cast, but it's optional and doesn't really work on the internet. IPv6 requires it and it will work for everyone.

"A huge percentage of the assigned IP space is being held by organizations who have no current use for it."

About 3-4 weeks worth of IP addresses are our current rate. By the time we finally run out, it will be more like 1-2 weeks.

"The IPv6-maniacs have made a lot of noise"

Ever see a harddrive get low on space? Works quite well. Keep ignoring it and you run out of room, bad things start to happen. You typically want to expand BEFORE you run out.

In many cases, huge blocks were purchased by companies, governments, and universities years ago with the expectation that they'd need one IP address for each device on their network (a pre-NAT concept), and now very little of the space is actually used.

AFAIK, ICANN never allowed any organization to "purchase" IPv4 blocks. One submitted an application with justification and was either granted or denied the request. Annual re-justification was also required (if I remember correctly).

The blocks he's referring to are old grandfathered blocks that don't need "Annual re-justification", as they were given before those rules were made.

But like you said, IP address may not be "purchased". This means those large blocks cannot be sold, only released. There is no incentive for those blocks to be given up and there really doesn't need to be.

A huge percentage of the assigned IP space is being held by organizations who have no current use for it. In many cases, huge blocks were purchased by companies, governments, and universities years ago with the expectation that they'd need one IP address for each device on their network (a pre-NAT concept), and now very little of the space is actually used.

Yeah and those companies certainly will waste quite a bit of money restructuring their aging infrastructure so that they can give back those unneeded addresses (one could assume that most organizations that wanted and could easily return back address blocks would've done so by now). Also, they will start giving out free beer every friday, because they suddenly realized how valuable good karma is compared to hard cash.

I'm surprised you haven't mentioned those class E IP blocks that could be distributed - sure, millions of routers would need fw upgrades (ha, good luck with that), but reality doesn't seem such a huge setback anyhow.

However, personally, I believe IPv4 addresses will run out about the same time as the world's oil reserves for exactly the same reason, economics. As scarcity causes prices to rise it becomes worthwhile to extract resources (oil/IPv4 addresses) that were previously too hard to bother with.

However, personally, I believe IPv4 addresses will run out about the same time as the world's oil reserves for exactly the same reason, economics. As scarcity causes prices to rise it becomes worthwhile to extract resources (oil/IPv4 addresses) that were previously too hard to bother with.

You're saying that IPv4 address will become worthless before they actually run out?

But so far, it seems that iOS devices will only run IPv6 over their WiFi connection—not 3G or LTE. This is despite the fact that, apparently, Verizon requires IPv6 support in devices before they're allowed on its LTE network.

iOS devices do not use IPv6 over LTE because there are currently no iOS devices available on Verizon's LTE network.

Iljitsch van Beijnum / Iljitsch is a contributing writer at Ars Technica, where he contributes articles about network protocols as well as Apple topics. He is currently finishing his Ph.D work at the telematics department at Universidad Carlos III de Madrid (UC3M) in Spain.