Apple's upcoming App Store submission requirement around supporting IPv6-only environments (announced last year at WWDC and being enforced starting June 1) has been getting plenty of recent coverage. iOS application developers already need to make sure their applications work in IPv6-only environments with NAT64+DNS64; however, this by itself does not mean that those applications (or web-based applications) obtain content over native IPv6.
If mobile performance is important for your business, now is the time to go beyond just making sure apps work in IPv6-only and to also dual-stack content, sites, and applications (ie, make it available over both IPv6 as well as IPv4) if you haven't done so already. Not only is there already significant and growing IPv6 deployment in mobile (so your effort won't be wasted), but we are also observing faster performance for IPv6 than IPv4 in some US mobile networks that have broadly deployed IPv6.
IPv6 in mobile is already widespread and growing
Given that the IPv6 roll-out is a multi-decade activity (we're now almost four years since World IPv6 Launch), many people have an out-of-date perception that there is very little IPv6 deployment. In much of the world this is becoming increasingly false. For example, if you have a recent Android phone on one of the top-4 US mobile networks (AT&T Wireless, Sprint, T-Mobile US, and Verizon Wireless) then there's a good chance you are already using IPv6 rather than IPv4 when connecting to many sites on the Internet without even realizing it. The same is true if you have an iPhone on Verizon Wireless. Of those in the US, all but T-Mobile are deploying dual-stack IPv4+IPv6. However, T-Mobile US has taken a lead by deploying an IPv6-only network for Android, and other providers are likely to follow suit once iOS also supports IPv6-only.
As of May 4th, requests to dual-stacked sites on Akamai from the top-4 US mobile networks used IPv6 around 60% of the time for Android and over 20% of the time for iPhones, with almost all of those IPv6-enabled US mobile iPhones being on dual-stacked Verizon Wireless. The graph above shows the total percentage of requests to dual-stacked sites using IPv6 from each of these networks across all devices.
Why IPv6-only in mobile is likely to grow soon
Apple's new App Store IPv6-only support requirement is highly likely to enable acceleration of IPv6-only deployments in both the other US networks (such as T-Mobile), and may also unblock IPv6-only deployments in many mobile networks around the world. Recent Android and Windows Phone versions already include a piece of software called a "464xlat CLAT" which encapsulates traffic destined for IPv4 addresses in IPv6 and tunnels it through to a NAT64 gateway. While iOS 9 lacks this specific functionality, it provides similar support via a "bump in the API" for applications using many of Apple's network programming interfaces.
One hesitation that mobile networks have had on taking an IPv6-only path is that it only worked well for Android. As of June 1 Apple will start enforcing that iOS applications work in these IPv6-only environments (with DNS64+NAT64 available). At some point following this, enough applications will work in this environment that mobile networks deploying IPv6-only for Android can start enabling IPv6 for their iOS handsets as well. Once the bulk of new Android, iOS, and Windows Phones support IPv6-only, this may encourage even more mobile networks around the world to switch to this IPv6-only deployment model, using DNS64+NAT64 for access to legacy IPv4-only content.
Deploying IPv6-only (with DNS64+NAT64) makes complete sense for mobile networks. Most networks around the world have exhausted their supply of public IPv4 addresses, and the larger ones also have more devices than are supported by private "rfc1918" addresses. This adds significant complexity in-terms of reusing private IPv4 addresses as well as deploying expensive stateful IPv4 to IPv4 Network Address Translation (NAT44) infrastructure. With an IPv6-only deployment model, only requests to IPv4-only content need to go through NAT64 (IPv6 to IPv4 Network Address Translation) servers while access to dual-stacked content can proceed directly to the Internet without any need for address translation. As more and more content becomes dual-stacked, networks will be able to deploy fewer and fewer NAT64 infrastructure. Another motivating factor for IPv6-only in Mobile is that the IPv6 PDN (Packet Data Network) type was specified well before the IPv4v6 PDN type and reportedly has more robust support in networking equipment.
IPv6 can perform better than IPv4 in mobile
The simpler network architecture for native IPv6 traffic in mobile networks (with fewer middle-boxes between the handset and the Internet) translates into better performance. In IPv6-only mobile networks (and in some types of dual-stacked mobile networks that transport IPv4 traffic in an IPv6 tunnel to a NAT44), IPv6 traffic has direct access to the Internet while IPv4 traffic has its access mediated through a NAT. These NATs add latency and can be bottlenecks as they can be expensive for ISPs to deploy enough capacity to keep up with demand.
Akamai, Facebook, and LinkedIn have all conducted RUM (Real User Measurement) studies comparing relative performance between IPv6 and IPv4 for dual-stacked mobile devices. These studies have shown significant performance improvements for IPv6 over IPv4 in the top-4 US mobile networks, with page load times improving by well over 10%. This translates to enabling IPv6 for content resulting in a better user experience and better user engagement for significant numbers of mobile users in the US and elsewhere in the world.
At Akamai, we used our RUM system to compare performance differences between IPv4 and IPv6 in the top-four US mobile networks. When comparing web performance between (legacy) IPv4 and (dual-stacked) IPv6 some relevant metrics are the DNS lookup time, the latency between client and server, and finally the page load time. End-users primarily observe the page load time, but it is directly influenced by the other two.
Android and iOS have implemented the DNS lookup for dual-stacked sites differently: Android performs the lookups for IPv6 (AAAA record) and IPv4 (A record) sequentially and waits for both to return, whereas iOS runs them in parallel and will initiate TCP connections as soon as results come back. The different implementations are reflected in the DNS lookup times we observe. While Android devices need between 11% and 47% (depending on the carrier) longer to obtain an IPv6 address compared to an IPv4 address, for iOS a reduction in lookup time of 58% can be observed. For Android, since the AAAA record is looked up even if content is IPv4-only, much of the performance hit here happens simply from the Android device having IPv6 connectivity. For iOS, sites that are dual-stacked and thus have AAAA responses yield significant performance benefits over IPv4-only sites.
Both Android and iOS see more consistent client to server TCP connection latencies (as measured by a Navigation Timing API) across the four carriers. When comparing IPv4 to IPv6 the median latency (the normal user experience) is not affected, but the 95th percentile of the distribution is much improved. This translates to fewer bad user experiences over IPv6. For Android devices, the latency at the 95th percentile is reduced by 20% on Sprint, 11% on AT&T, and 5% on T-Mobile. One likely reason for this difference is that IPv6 connections access the network directly while IPv4 goes through stateful NAT servers. Verizon uses transparent proxy servers on IPv4 but not on IPv6; therefore, on IPv6 the browser measures the latency to the Akamai server but on IPv4 it only measures the latency to the proxy within the Verizon network. Due to this, we did measure an increase in IPv6 TCP connection latency on Verizon of 5% on Android and 9% for iPhones, but the presence of a proxy makes this metric less directly comparable.
Unlike DNS lookup times and client-to-server latency, it is not possible to compare page load times across sites or across devices without performing carefully controlled experiments (as was done in Facebook's study showing 10-15% improvements in page load time). We performed such an experiment looking at one specific site (URL) on one specific device (iPhone) on one network (Verizon), and we saw that the selected sites load 5% faster in median and 15% faster for the 95% percentile on IPv6 compared to IPv4. This shows that at least in this case the presence of the proxy on IPv4 (and hence the longer relative TCP connection latency for IPv6) didn't impact the improved overall page load time. The page load time is affected by both the DNS lookup time and the client-to-server latency.
It's also interesting to note that around 80% of connections from IPv6 enabled iPhones on Verizon to dual stacked domains on Akamai are using IPv6. For Android phones that fraction is even higher for recent versions of Android, with up to 96-98% depending on the phone model and carrier.
If you develop and publish applications to Apple's App Store, you are hopefully already testing your application's ability to function in an IPv6-only environment with DNS64+NAT64. Note that meeting Apple's IPv6 support requirement does not by itself require that all content accessed by the application is dual-stacked and available over IPv6. Rather, it just means that applications need to not try to directly access IPv4 literals without using particular Apple networking APIs that perform translation. However, as explained above, there will likely be significant performance benefits for dual-stacking content and using IPv6 end-to-end, as while references to IPv6 resources will be accessed natively, IPv4 resources will have their connections translated on NAT64 gateways that may become additional bottlenecks.
For content providers, dual-stacking sites and content on Akamai to make it available over IPv6 is typically quite straight-forward for most products and is simply a matter of selecting "IPv4+IPv6 dual-stack" during provisioning. There is no need to have IPv6 connectivity at your origin as Akamai will terminate both IPv4 and IPv6 connections at the edge and is then able to connect to your origin over IPv4. IP addresses delivered by Akamai in log lines, request headers, and download receipts may then contain the IPv6 address of clients connecting over IPv6. Akamai account teams and AkaTec support staff can switch existing sites to dual-stack, and we hope to have self-service for this as well later this year.
Akamai has a global footprint of IPv6 deployment with IPv6 configured and live on servers in 106 countries and over 1900 locations and around 700 network providers. We continue to encourage our network partners looking to turn-up IPv6 to their end-users to work with us to ensure IPv6 is properly configured and routed to our servers. Also, for mobile network operators looking to deploy IPv6-only environments, Akamai's AnswerX DNS resolver can be configured with a policy to implement DNS64, as well as other features that can help improve experience for mobile users.
The Internet has a long ways to go with the IPv6 transition, but Akamai continues to see significant uptake in both networks, content providers, and devices supporting IPv6. The improved performance from a flatter Internet with less NAT will likely accelerate uptake, especially as companies look for new ways to get improved mobile performance.
Thank you to Moritz Steiner and others for providing some of the details for this blog post. Stay tuned for another upcoming blog post around the fourth World IPv6 Launch anniversary (and see last year's post for some more details)