On the first day of its World Wide Developers Conference (WWDC), Apple presents its keynote, where it mostly unveils its consumer-facing plans. Later, when the pundits are taking their first jab at explaining what it all means, there's the Platforms State of the Union session. At 35 minutes in, Sebastien Marineau, Apple’s VP of Core OS, dropped the following bomb: "Because IPv6 support is so critical to ensuring your applications work across the world for every customer, we are making it an App Store submission requirement, starting with iOS 9."
However, on the last day of WWDC, there was a session that put the above statement in a somewhat different light. We'll get back to that because, in the mean time, I spent a larger part of the week than I'd like to admit testing whether various applications work over IPv6.
The current state of IPv6
My first reaction was "this means no more Skype under iOS 9." Which led to some back-and-forth about whether Skype works over an IPv6-only network. The easiest way to test this is to get rid of that old, rickety version 4 of the Internet Protocol—it only has four billion addresses!—simply by turning it off in the Network pane of the System Preferences on your Mac. If there's an IPv6 router present on your Ethernet or Wi-Fi network, your Mac will then configure an IPv6 address for itself—well, two, actually—and connect to the IPv6 Internet. If there's no IPv6 router present, at least your Mac will talk to other devices on the local network over IPv6, using "link local" addresses.
In this setup, many things will work just fine. You can reach the Apple, Microsoft, Google, Yahoo, Facebook, and Wikipedia websites using any current browser. If your mail server has IPv6, you can send and receive e-mail. Time Machine works, and you can sync your iPhone to iTunes over Wi-Fi. iTunes will stream audio (but not video) to an Apple TV.
However, there are many things that don't work. You can't reach any IPv4-only websites, such as support.apple.com or developer.apple.com. iCloud, Apple Maps, the iTunes/App Stores, iMessage, and iPhone call/SMS forwarding don't work. And Skype doesn't work: it runs, but it doesn't "see" any contacts and it complains about a lack of Internet connectivity when you try to make calls.
In the real world, of course, people don't go around turning off IPv4 on their Macs—and on iOS that's not even an option. A more realistic way to test IPv6-only is by connecting to a network that doesn't have IPv4 connectivity but does have IPv6 connectivity. This is surprisingly hard to achieve in practice, as every device that supports IPv6 also runs IPv4, and the old protocol usually can't be turned off. However, after getting an old Cisco router out of retirement, I was able to test this scenario.
The difference between this method and turning off IPv6 at the network interface level is that devices can still communicate using IPv4 over the local network. In this setup, I was able to use AirPlay streaming of video from iTunes on the Mac to the Apple TV, too. The Apple TV was also happy to connect to Netflix and YouTube, but most other channels and iTunes Store content weren't available. Interestingly, the weather app on the Apple Watch worked, but the weather (and sunrise/sunset) wouldn't show up on the watch face display. On my iPhone, the Overcast and Pocket Casts podcast players couldn't sync with their servers. SMS forwarding, the App Store, and notifications also didn't work.
But the situation where computing devices only have IPv6 connectivity, with no way to reach the IPv4 Internet, is pretty far-fetched. In a blog post earlier this week, Geoff Huston, chief scientist at APNIC, deducted points because Apple isn't implementing any technologies that bridge the gap between IPv4 and IPv6. He wrote:
IPv4 is not going away any time soon, and for some years to come it’s not the IPv6-only networks that will provide services to customers. It’s just not quite there yet. For years to come we need to operate the Internet in a mode that supports IPv6 and IPv4 together in Dual Stack mode. The operational premise for today’s devices and apps is simple: 'Do IPv6 if you can, and fall back to IPv4 if you must.' So how well is Apple doing in a dual stack world? Not as well as I would want.
Huston points out that Android supports a technology called 464XLAT. 464XLAT allows IPv4 apps to talk to IPv4 servers over IPv6 networks by having the phone translate the application's network requests from IPv4 to IPv6. Then, at the edge of the IPv6 network, a NAT64 device translates the IPv6 packets back to IPv4 and sends them on their way to the server.
What’s actually happening
So why wouldn't Apple go this route? During the "Your App and Next Generation Networks" session on Friday morning, Prabhakar Lakhera took the stage and clarified what's going on. He explained in a bit more detail what Apple's considerations with IPv6 on iOS 9 are. Lakhera referred to the fact that there are pretty much no IPv4 addresses left and that the big cellular carriers really don't want to continue running IPv4 and IPv6 side by side in dual stack configuration—apparently, IPv6-only cellular service is coming. Soon.
The way Apple is addressing that situation is to make sure that all iOS apps support IPv6. However, many servers are still IPv4-only. To reach those, the cellular networks are going to deploy NAT64 translators. NAT64 allows IPv6 applications to access IPv4 servers. Without these translators, IPv6 applications ask the DNS for IPv6 addresses to connect to, but obviously IPv4-only servers don't have IPv6 addresses, so a regular DNS server then returns an empty list of IPv6 addresses, leaving the application all dressed up with nowhere to go. A DNS64 server, on the other hand, creates a "synthetic" IPv6 address that the application can use. The packets sent to those addresses end up at the NAT64 translator, which recovers the IPv4 address of the intended destination using the IPv6 address created by the DNS64 and translates the packet from IPv6 to IPv4.
In the presence of DNS64+NAT64, most of the applications that wouldn't work in my IPv6-only test setup will work fine because it ensures that IPv6 software can reach IPv4 servers.
So 464XLAT and DNS64+NAT64 achieve the same result, but there is a fundamental difference: 464XLAT also works for applications that only support IPv4, while DNS64+NAT64 expects applications to talk IPv6 to the network. So applications that work over DNS64+NAT64 are ready for the IPv4 to be turned off at some point, while 464XLAT kicks that particular can down the road.
To allow iOS developers to test whether their applications work through NAT64, Apple has included a DNS64+NAT64 implementation in the seeds of OS X 10.11, which can be enabled by first option-clicking the Share pane in the System Preferences and then option-clicking the Internet Sharing service. After that, a "Create NAT64 Network" option appears.
The main reasons why applications only work over IPv4 are the use of the ancient Unix gethostbyname() family of system calls and "pre-flight checks" that try to determine whether the system has a connection to the Internet by looking for an IPv4 address or if address 0.0.0.0 can be reached. These issues are usually easy enough to fix—70 percent of current iOS apps already work over IPv6 today. Things only get complex for applications that need to interact with the network on a lower level, such as VoIP applications like Skype. Such apps need to figure out how to connect two client devices that are probably behind NATs and firewalls—more challenging than simply looking up a server address.
iOS developers should definitely check out the presentation, and it's highly recommended for non-developers with an interest in networking, too, with Stuart Cheshire explaining how to remove network performance bottlenecks that aren't caused by a lack of raw bandwidth. This includes why CoDel is the bee's knees and that Apple is enabling Explicit Congestion Notification (ECN) in iOS 9 and OS X 10.11.
reader comments
72