The trials and tribulations of a few network engineers

Author: Nick Chettle

Apple have recently made waves in the networking world by announcing IPv6 support will be mandatory for apps in iOS9. Now, this is not actually as scary as it originally sounds for app developers; all it really means is that they must avoid the use of IPv4 literals and make use of iOS’s high-level network API’s. In this way, the network is abstracted from the developer and they don’t really need to care about the underlying transport. iOS will decide what to use. If only IPv4 is available, it will use that. If only IPv6, it will use that, although perhaps with the help of DNS64/NAT64 in the providers network if the content itself is IPv4-only. Things get more interesting when both IPv4 and IPv6 are available, the decision is then more complicated.

In dual-stack networks, you could be forgiven for thinking that iOS will make the ”right” decision when presented with a dual-stack connection, unfortunately, real world experience is not proving this to be the case. Of course, the “right decision” means different things to different people. For example, Facebook have recently shown that they see a significant performance increase (Up to 40% decrease in page load-time) when using IPv6 on a major US mobile network. The interesting thing here though, is that they also report that iOS will only choose the IPv6 path ~20% of the time. This seems to be because Apple are basing their decision on RTT even though HTTP throughput is faster via IPv6. This has actually led Facebook to develop mobile proxygen so they have control over the protocol selection process.

So what are developers meant to do? How will they even know if their apps are IPv6 compliant? Fortunately, Apple have thought of this and are providing OS X with the ability to create an IPv6-only hotspot. As far as I know, the details of exactly how this works are not yet public but the best guess seems to be that they will present an IPv6-only connection and then use NAT64/DNS64 to provide connectivity to any content that may be IPv4-only.

This is all great news but there is an elephant in the room: 464XLAT. This is a technique that combines existing translation mechanisms (RFC6146, and RFC6145) to provide IPv4 connectivity to devices connected to an IPv6-only network. This is achieved by providing a client-side IPv4 CLAT, traffic is allowed to enter as IPv4 and is then mapped to IPv6 for transport across an IPv6-only network. This is great for the mobile world; it means UEs (User Equipment) that support 464XLAT can be connected to operators IPv6-only networks without fear of poorly coded apps breaking. The UE itself “fakes” IPv4 connectivity towards any applications that can’t live without it. So why have Apple stubbornly refused to support 464XLAT and show no sign of changing this stance?

It is important to remember that 464XLAT solves a very specific problem; IPv6-only networks, even with DNS64/NAT64 cannot achieve parity with IPv4-only networks when some apps break on an IPv6-only network. This typically happens because the app is using IPv4 literals or making use of legacy IPv4-only APIs. 464XLAT gets around this by presenting IPv4 connectivity so these apps can continue to work. Because of this, major mobile networks (T-Mobile US being a prime example) have been able to provide IPv6-only to their Android users. But Apple are in a unique position, they exercise great control over their store and apps must meet certain requirements to gain entry. One of these requirements will now be that the app *must* work on an IPv6-only network. If developers have coded apps in such a way that they break without IPv4, they will be required to fix this for iOS9. This is an excellent move, just like so many things before, Apple are consigning “IPv4-only” to the history books.

There is still plenty more for Apple (And the rest of the industry) to do regarding IPv6 but I can’t help but be optimistic after hearing this announcement. I hope this move really does help weed out legacy code in apps and Apple listen to experiences gained by Facebook, and others, around improvements to protocol selection. I guess we will find out over the coming months.