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.
I disagree with you a bit about the need for 464XLAT.
As I understand it, an iOS9 device on an IPv6-only network would use their ISP’s DNS64/NAT64 service to access IPv4-only Internet sites by hostname.
Android devices need 464XLAT so that IPv4-only apps can access IPv4-only sites across IPv6-only transport.
Apple has solved the IPv4-only App problem by banning iOS9 IPv4-only apps from their App Store!
There still remains the problem of Web content that contains embedded IPv4 literals. These sites won’t work for iOS9 devices using IPv6-only transport.
I suspect that Apple customers will pressure websites to fix their content rather than pressure Apple add 464XLAT to their devices. Alternatively, ISPs may be caught in the middle and be forced to continue to provide dual-stack or IPv4-only to Apple devices.
===
Apple’s goal isn’t to follow the IPv6 mantra:
“do IPv6 if you can, and fall back to IPv4 if you must”?
Their goal is more “provide Apple users with the best possible experience”, or “we don’t make compromises” – sometimes the best will be via IPv6, sometimes not.
Hi John,
It’s a tough call to launch a large scale production service and base it on the rock solid reliability of a NAT64 service. 464XLAT represents a more conservative approach that attempts to allow native mode V4 apps on the handset talk to public IPv4 services without attempting rather delicate on-the-fly packet header surgery to perform the protocol translation function. It is effectively saying that the operator is more confident to support tunnelling than NAT64 within the network.
The IPv6 mantra I referred to is a serious issue. The end point of all of this work is not to run a dual stack network forever, but to reach the point where IPv4 can be removed without any consequence. If end systems follow the mantra of preferring IPv6 when they can then as the volume of IPv6 deployment rises then the volume of IPv6 connections also rises and the volume of connections in IPv4 falls. Ultimately IPv4 fades away as IPv6 is further deployed.
But if the end system persists in making IPv4 connections even when IPv6 is an option then its not a given outcome that the greater the level of IPv6 deployment the greater the volume of IPv6 connections. As we deploy more IPv6 in the network it is not necessarily the case that the volume of IPv4 connections will fall in this environment. So how would you know when IPv4 is no longer required?
Apple may well think that its interpretation of the dual stack operating world advantages its users, but it does so in a manner that sends out all the wrong signals to the network. In such an environment IPv4 use will not decline as IPv6 deployment picks up. I’d offer the view that Apple is counting on everyone else to follow the IPv6 mantra while, somewhat selfishly, re-interpreting the rules to suit itself and its users.
I’m still at 7/10. Could do better.
I think 464XLAT starts with an IPv4 packet,
the clat in the phone translates the packet, replacing the IPv4 header with an IPv6 header using IPv4-embedded IPv6 addresses,
then the ISP’s NAT64 plat translates the packet again, replacing the IPv6 header with a IPv4 header, …
464XLAT does “rather delicate on-the-fly packet header surgery” twice. It is not tunnelling.
James Woodyatt (previously at Apple) has argued that 464XLAT delays the transition to all-IPv6 by prolonging the viability of IPv4-only software.
ref1,
ref2
I see Apple iOS9 phones working on IPv6-only transport as a good (catchup) move, and with no 464XLAT as another good (leading) move.
Some cellular networks are leaping from IPv4-only transport to IPv6-only transport, and skipping dual-stack access all together.
It will be interesting if a iOS9 phone with IPv6 transport creates a useful IPv6-only hot-spot, with the ISP providing the DNS64/NAT64. You then need IPv6-clean laptop apps, or a clat on your laptop.
===
I agree that Apple not preferring IPv6 on dual-stack networks is feet-dragging rather than leading.
I’m at 8/10.