It’s Apple’s developer conference time again, and in amongst the various announcements this week, IPv6 was mentioned in the “Platforms State of the Union” presentation. Sebastien Marineau, Apple’s VP of Core OS, told the conference IPv4 address exhaustion “is finally here”, noting this started in 2011 in the Asia Pacific, and in North America IPv4 address exhaustion is imminent.
Sebastien noted that it’s really important to support IPv6 in devices and applications these days. He referenced Apple’s work in adding IPv6 to its network stack over a decade ago, and adding IPv6 into its mobile operating system iOS since version 4.
You would be led to believe that Apple “got it” years ago. And they appear to still get it.
For iOS9, part of the app submission process will be to test the app functions in an IPv6 infrastructure. Great! Developers can no longer ignore IPv6 if they want their app to live in Apple’s App store. They are ensuring that if the app uses Apple’s standard libraries for its networking connectivity then not only will the app work over an IPv6 network, but it will negotiate transport level security as well. Again, great! They get it. They also are adding an IPv6 network emulator to their Mac OSX platform, allowing a developer to create a personal IPv6 only WiFi hotspot to test an app to see that it works in an IPv6 only environment. Again, a great idea. Kudos to Apple!
But, I’m afraid I can’t mark these initiatives down as a 10/10 success for Apple and IPv6.
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 Dual Stack mode that supports both IPv6 and IPv4 together. 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.
T-Mobile in the US is a large carrier. It has taken the decision to operate part of its mobile network, that supports a total of some 45 million subscribers, in IPv6-only mode. The way they provide the IPv4 component of a Dual Stack environment is by a form of encapsulation that tunnels the IPv4 network stack on the mobile device across the IPv6 carrier network to the IPv4 gateway in the provider network. This encapsulation approach goes by the rather scary name of “464-XLAT“. So T-Mobile now operates a very large IPv6-only mobile data network that can be used by handsets that support 464-XLAT.
This leads to the question: which family of devices support 464-XLAT? Android. Not Apple’s iPhone or iPad. They just aren’t supporting 464-XLAT in iOS right now.
Mac OSX has had IPv6 support for many years. As has iOS. But it’s not quite all there. What if I want to use my Apple iPhone as a personal hotspot and relay a Dual Stack network to my Mac? Will I see both protocols on my Mac? Nope. It’s an IPv4-only personal hotspot.
What about the other way? What if I want to use my Mac as a personal hotspot and provide a WiFi service to my iPhone? Dual Stack support? Nope once more. It’s an IPv4-only hotspot.
What about the larger picture of Dual Stack support? Will Mac OSX and iOS platforms support both protocols at once, assuming that you can get them to your Apple device? Yes! So will these platforms “do IPv6 if you can, and fall back to IPv4 if you must”? Ooops. That’s a “nope” as well. Its Dual Stack protocol selection algorithm does not do it that way.
I’m just a little disappointed. You see it’s not yet time to throw out all traces of IPv4 and go boldly into an IPv6-only world. Today what we have is a Dual Stack Internet; for some time yet it’s going to remain a Dual Stack Internet. That means that we need to add support for both protocols across the entire networked platform. And bear in mind that the Dual Stack operational paradigm is: “Do IPv6 if you can, and fall back to IPv4 if you must.” So, with this in mind, do Apple really get it?
Hmmm. Not quite. It’s 7/10 for Apple I’m afraid. Could do better.
The views expressed by the authors of this blog are their own and do not necessarily reflect the views of APNIC. Please note a Code of Conduct applies to this blog.