|
It’s Apple’s Developers Conference time again, and in amongst the various announcements was week, in the “Platforms Status of the Union” presentation was the mention of Apples support of IPv6. Sebastien Marineau, Apple’s VP of Core OS told the conference that as far as IPv4 addresses are concerned, exhaustion “is finally here”, noting that this already started in 2011 in the Asia Pacific while in North America IPv4 address exhaustion is imminent. Sebastien noted that it’s really important to support IPv6 in devices and applications these days, and 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’d be led to believe that Apple “got it” years ago. And you’re probably not wrong if that’s what you thought.
And they still appear to get it.
For iOS 9, part of the Apple’s app submission process will be to test that the app will function in an IPv6 network infrastructure. If your app does not work over IPv6 then its not going to be in the App Store. 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 that I can’t mark these initiatives down as a 10/10 success for Apple and the cause of 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 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.
T-Mobile in the US is a large carrier. It has taken the decision to operate part of it’s 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 in an IPv6-only network 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 cryptic 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. Which 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. What happens when other carriers want to build an IPv6-only mobile network and use an IPv4 overlay in the same way as T-Mobile? Their iPhone customers are going to be left behind.
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 hot spot and relay a dual stack network to my Mac? Will I see both protocols on my Mac? Nope. It’s a 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”? That’s a “nope” as well. It’s dual stack protocol selection algorithm does not do it that way. It tries to guess which protocol it thinks will be faster and use that. While that approach tries to optimise the user’s position it can persist in generating IPv4 connections which does not assist in the larger picture of transition. There is a good reason for this transition mantra of preferring IPv6 where feasible, and its difficult to understand how Apple’s slightly anomalous position is helping the overall transition process.
So I’m just a little disappointed. You see, its 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, does Apple really get it?
Hmmm. Not Quite.
Right now it’s 7/10 for Apple and IPv6, I’m afraid.
Could do better!
Sponsored byCSC
Sponsored byVerisign
Sponsored byVerisign
Sponsored byWhoisXML API
Sponsored byIPv4.Global
Sponsored byDNIB.com
Sponsored byRadix
At least Apple have now acknowledged that there are operators moving to IPv6-only.
If they acknowledged it those operators are using IPv6-only/464xlat and not just IPv6-only they’d get 8/10.
Putting the CLAT into iOS required by 464xlat and would make it a 9/10.
If they also provide a means of selecting IPv4 or IPv6-only/464xlat when roaming for 10/10.
The iPhone is reported to support Dual-stack tethering on Verizon Wireless with the /64 coming from the 3GPP link (RFC7278).
While the Internet is going to remain dual-stack for some time, there are parts of it with stronger selection pressures to move to single-stack. The 3GPP mobile device to the Packet Core is one of these.
Meanwhile Android refuses to support DHCPv6 out of some bizarre concern about people trying to tether devices to WiFi networks using the USB port on their Android device. Despite facing universal opposition to this stance, they won’t budge, so Android won’t do v6 on enterprise/campus networks that insist on DHCPv6 rather than SLAAC.