Measuring Cellular IPv6 Networksfor Web Performance

Utkarsh Goel (Student)1, Moritz Steiner2, Erik Nygren2, Mike P. Wittie1,Ruomei Gao2, Martin Flack2, and Stephen Ludin2

1 Department of Computer Science, Montana State University, Bozeman MT 59717{utkarsh.goel, mwittie}@cs.montana.edu

2 Akamai Technologies, Inc., San Francisco, CA 94103{moritz, nygren, rgao, mflack, sludin}@akamai.com

Abstract. The growing numbers of mobile users challenge cellular net-work scalability. The IPv4 address space is not sufficiently large to uniquelyidentify all active network devices, while at the same time network ad-dress translation (NAT) middleboxes used to extend the IPv4 addressspace introduce performance overheads. Therefore, ISPs have started toadopt IPv6 addressing to provide Internet services to their growing userbase. However, the impact of adopting IPv6 on Web performance is notyet well understood. In this study, we perform the first large scale investi-gation of the deployment of IPv6 infrastructure across cellular networksin the US and compare Web performance over IPv6 and IPv4 networks.Results from our measurements indicate that providing Web content overIPv6 does not degrade Web performance, and in some cases, IPv6 speedsup user communication. We therefore argue that server and applicationsupport for IPv6 has the potential to improve the Web performance forend-users.

Keywords: IPv6, cellular, measurement, performance, middlebox

1 Introduction

The growing numbers of mobile (cellular) users have resulted in Internet ServiceProviders (ISPs) upgrading and scaling their network infrastructure. To accom-modate the growing user base, ISPs deploy Carrier Grade NATs (CGNs) andLarge Scale NATs (LSNs) that provide connectivity despite the lack of suffi-cient publicly routable IPv4 addresses for every mobile user. With the estimatedexhaustion of the American Registry for Internet Numbers (ARIN)’s IPv4 ad-dress space in September 2015, many ISPs strive to continue expanding Internetconnectivity with IPv6 addressing to their users. Although using a NAT-basednetwork infrastructure is a viable option to scale and reuse the available IPv4 ad-dress space in the short term, NAT middleboxes introduce complexity in networkoperations and add latency to end-to-end communication [3, 20, 22].

IPv6 addressing has become one of the potential solutions for many ISPsto solve the problem of IPv4 scarcity related to the growing user base and toeliminate performance overheads introduced by NAT-based middleboxes [12, 20].Although, ISPs tend to adopt IPv6 and upgrade their network infrastructure

from IPv4 to IPv6, the Web performance over IPv6 networks is not yet wellunderstood in the network operator, content provider, and developer communi-ties [3]. For example, previous studies have mostly investigated challenges to de-ploy IPv6 and adoption rate of IPv6 in different countries [12, 20, 23]. Therefore,content providers, server operators, and application developers remain unawareof whether providing support for IPv6 in their services would improve or degradethe end-user experience.

In this study, we explore the IPv6 deployment of four major cellular carriersin the US and compare the Web performance on each carrier’s IPv6 network,with respect to that carrier’s respective IPv4 network. Specifically, we performa large scale measurement study over five months in 2015 on a major CDNprovider to investigate the performance of three major metrics of Web perfor-mance; 1) Round trip latency between clients and servers, 2) DNS lookup time,and 3) Webpage load time for pages loaded over IPv6 and IPv4 networks. To thebest of our knowledge, this study is the first large scale investigation to compareperformance of IPv4 and IPv6 networks, which exposes the performance benefitsof adopting IPv6 for server operators. Our results indicate that support for IPv6does not degrade Web performance and infact in some cases, IPv6 speeds upuser communication.

The rest of the paper is organized as follows. In the next section, we providea high level overview of how IPv6 is deployed in different US-based cellular car-riers. In Section 3, we describe our data collection methodology. In Section 4, 5,and 6, we investigate the round trip latency between clients and CDN servers,the DNS lookup time, and the webpage load time for pages loaded over IPv6and IPv4 networks, respectively. Finally, we conclude in Section 8.

2 Overview of IPv6 Deployment across Cellular Carriers

A cellular carrier that supports IPv6 addressing must provide ways for its IPv6devices to connect with IPv4 and dual-stacked (both IPv4 and IPv6 addresses)servers on the Internet. Cellular network architectures are influenced by a varietyof factors such as capability of the existing infrastructure hardware to supportIPv6 addressing, urgency to upgrade networks to IPv6, number of users withIPv6-capable devices, number of available IPv4 addresses, etc., which results inISPs taking different approaches to IPv6 deployment [7]. In this section we pro-vide an overview of how different cellular carriers in the US have upgraded theirIPv4 networks to provide IPv6 addressing to their users, based on the publiclyavailable information from those carriers.

T-Mobile is an IPv6-only network for all phones with support for 464XLAT,which includes all phones with Android version 4.3 and above [10]. For older ver-sions of Android, as well as iPhone, Blackberry, and Windows devices, T-Mobileis an IPv4-only network. As a result, IPv6 devices in T-Mobile network al-ways transmit IPv6 packets, whereas, IPv4 devices always transmit IPv4 pack-ets into the network. The choice of addressing (IPv4/IPv6) for devices is basedon whether the device supports 464XLAT. In Figure 1, we depict a high levelinfrastructure of the IPv6 network deployed by T-Mobile. We show that, when

Fig. 1. IPv6 network of T-Mobile. Fig. 2. IPv6 network of Verizon.

an IPv6 device communicates with an IPv6 server, the packets are routed di-rectly to the server, through the IPv6 network without any NAT-based statefulmiddleboxes (Steps 1 and 2). However, when an IPv6 device communicates withan IPv4 server, the IPv6 packets generated by the device are routed to a state-ful NAT64 middlebox (Steps 3 and 4). The NAT64 middlebox translates IPv6packets to IPv4 address family and forwards the translated packets to the IPv4server (Step 5). The NAT64 middlebox also converts reply IPv4 packets (fromthe IPv4 server) to IPv6 packets (to be forwarded to the mobile device), as shownin steps 5, 4, and 3. In summary, there are two ways in which T-Mobile routespackets from IPv6 devices: 1) via IPv6 network with no stateful middleboxes,and 2) via NAT64 middlebox, where IPv6 network is used between clients andNAT64 and IPv4 network is used between NAT64 and IPv4 servers.

Verizon Wireless provides both IPv6 and IPv4 addressing to all of its de-vices connected to its LTE network [6]. For devices with no IPv6 support or notconnected to the LTE network, Verizon provides only IPv4 addressing – resultingin the devices to use Verizon’s IPv4 network. In Verizon network, the choice ofaddressing on the device is based on whether the device is connected to the LTEnetwork [21]. In Figure 2, we depict a high level infrastructure of Verizon’s IPv6network. Similarly to T-Mobile, when an IPv6 device communicates with an IPv6server, the packets are routed to the server through the IPv6 network withoutany stateful middleboxes (Steps 1 and 2). However, when an IPv6 device commu-nicates with an IPv4 server, the device uses the Gateway-Initiated Dual-StackLite (DS Lite), a software installed on the phone, to encapsulate IPv4 packets in-side IPv6 headers (Step 3) [9, 14]. The encapsulated packets are then forwardedto a stateless middlebox that decapsulates the packet contents and strips outthe IPv6 header (Steps 4 and 5). Finally, the IPv4 packets are forwarded tothe IPv4 server (Step 6). One of the benefits of using a gateway initiated DSLite is that encapsulating IPv4 packets in an IPv6 header allows Verizon to useIPv6 addressing for routing packets within the cellular network. In summary,there are two different ways in which Verizon routes packets from IPv6 devices:1) via IPv6 network with no stateful middleboxes, and 2) via stateless IPv4-in-IPv6 tunnels, where IPv6 network is used between clients and DS-Lite (in thenetwork) and IPv4 network is used between DS-Lite and IPv4 servers.

AT&T and Sprint provide both IPv6 and IPv4 addressing to only someof their IPv6-capable devices [2, 8]. For other IPv6-capable and IPv4-only de-vices, both these networks provide only IPv4 addressing. Therefore, the choiceof addressing for devices in these networks is neither dependent on 464XLAT

nor on the cellular technology and is rather likely to be decided by the car-rier’s respective network configurations. In Figure 3, we depict a high level

Fig. 3. IPv6 network of AT&T & Sprint.

infrastructure of the IPv6 network deployed by AT&T and Sprint. We showthat when an IPv6 device communicates with an IPv6 server, the packets arerouted directly to the server, through the IPv6 network without any statefulmiddleboxes (Steps 1 and 2) [2, 8]. However, when an IPv6 device communicateswith an IPv4 server, unlike in T-Mobile and Verizon networks, the packets arerouted through the IPv4 network which consists of several stateful NAT mid-dleboxes (Steps 3, 4, and 5). In summary, there are two different ways in whichboth AT&T and Sprint route packets from IPv6 devices: 1) via IPv6 networkwith no stateful middleboxes, and 2) via IPv4 network with several stateful NATmiddleboxes.

3 Data Collection Methodology

To compare the Web performance for end-users on IPv6 and IPv4 netorks, weused a Akamai’s Real User Monitoring (RUM) system that injects JavaScriptinto the requested HTML pages [5]. The JavaScript uses the browser exposedNavigation Timing API to collect the time to resolve domains, establish TCPconnections, and load webpages [4]. The JavaScript then sends the timing data(which we refer as RUM beacon) to a dual-stacked server after the page loadcompletes, where the server stores the data into a database. The server thencomplements the data with the TCP latency estimated by the CDN server thatserved the webpage, the IP addresses of the CDN server and the client, an indi-cator of whether the webpage was requested over IPv4 or IPv6, an indicator ofwhether the RUM beacon was submitted over IPv4 or IPv6, and the cellular ISPname to which the client’s IP address belongs (by using Akamai’s EdgeScape [1]).

We filtered our dataset to collect performance numbers pertaining to web-pages loaded on Google Chrome browser on Android devices. To get the roundtrip latency over IPv6 and IPv4 networks, we filtered our dataset to collect la-tency numbers pertaining to HTTPS sessions only (instead of HTTP sessions),as our previous work on detecting connection terminating TCP proxies has re-vealed that none of the US-based cellular networks terminate TCP connectionsfor HTTPS sessions [15]. Thus, considering latency numbers for HTTPS ses-sions enables accurate estimate of the latency between CDN servers and theclient devices, and ensures that the estimated latency is not between serversand middleboxes in a cellular network. To get the latency over an IPv6 connec-tion, we used latency estimated by CDN servers for webpages requested overIPv6 network. To get the latency over connections via NAT64 (in T-Mobile) orIPv4-in-IPv6 tunnels (in Verizon), or by IPv6 clients using IPv4 network (inAT&T and Sprint), we used latency estimated by CDN servers for connections,where webpages were requested over IPv4 network and the RUM beacon was sub-mitted over IPv6 – indicating that the webpage loaded on an IPv6 client. To get

0.0 0.2 0.4 0.6 0.8 1.0

0.0

0.2

0.4

0.6

0.8

1.0

Normalized Latency

CD

F of

Ses

sion

s

E2E IPv6 SessionIPv6-to-NAT64-to-IPv4E2E IPv4 Session

Fig. 4. RTT for T-Mobile clients.

0.0 0.2 0.4 0.6 0.8 1.0

0.0

0.2

0.4

0.6

0.8

1.0

Normalized Latency

CD

F of

Ses

sion

s

E2E IPv6 SessionIPv4-in-IPv6 TunnelE2E IPv4 Session

Fig. 5. RTT for Verizon clients.

the latency over IPv4 connections, we used latency estimated by CDN serversfor webpages requested over IPv4 and where RUM beacon was also submittedover IPv4 – indicating that the webpage is loaded on an IPv4 client. We applythese techniques to extract DNS lookup and webpage load time from our dataset.Additionally, for comparing webpage load time, we only used data for webpageswhere the DNS lookup was performed and the pages were loaded over newlyestablished TCP connections. Our current filtered dataset consists of round triplatency and DNS lookup time measurements from several million sessions andwebpage load times from several hundred sessions.

4 Round Trip Latency over IPv6 and IPv4 Networks

The Round trip latency (RTT) between clients and servers plays an importantrole in influencing Web performance [16]. In this section, we investigate whetheror not serving mobile content over IPv6 results in lower latency. Specifically, wecompare RTT between clients and CDN servers over IPv6 and IPv4 networksacross different cellular networks.

In Figures 4-7, we show the distribution of RTT between clients and CDNservers over IPv6 and IPv4 networks of different cellular carriers. In order toconcentrate on the relative performance between IPv4 and IPv6, we normalizethe RTT independently for each network in these figures. The solid CDF linesshow the RTT when IPv6 clients connect to IPv6 servers, over the IPv6 network.The dashed CDF lines show the RTT when IPv6 clients connect to IPv4 serversvia NAT64 middleboxes (in T-Mobile), via IPv4-in-IPv6 tunnel (in Verizon), orvia the IPv4 network (in AT&T and Sprint). The dotted CDF lines show theRTT when IPv4 clients connect to IPv4 servers, over the IPv4 network.

In the case of T-Mobile in Figure 4, we observe that the RTT for sessions overIPv6 network is lower than the RTT over the IPv4 network. For example, formedian and 80% of sessions, the RTT over IPv6 network is about 49% and 64%faster than RTT over IPv4 network, respectively. Even for sessions via NAT64middlebox, the RTT is lower than RTT over IPv4 network. For example, forconnections that go through NAT64 middleboxes, the latencies for median and80% of sessions are about 18% and 27% faster than RTT over the IPv4 network,respectively. We argue that such difference in round trip latency in T-Mobile net-work arises from the elimination of overhead of NAT middleboxes deployed inthe IPv4 network to perform NATing of client sessions. With no middleboxes in

0.0 0.2 0.4 0.6 0.8 1.0

0.0

0.2

0.4

0.6

0.8

1.0

Normalized Latency

CD

F of

Ses

sion

s

E2E IPv6 SessionE2E IPv4 Session on IPv6 deviceE2E IPv4 Session on IPv4 device

Fig. 6. RTT for AT&T clients.

0.0 0.2 0.4 0.6 0.8 1.0

0.0

0.2

0.4

0.6

0.8

1.0

Normalized Latency

CD

F of

Ses

sion

s

E2E IPv6 SessionE2E IPv4 Session on IPv6 deviceE2E IPv4 Session on IPv4 device

Fig. 7. RTT for Sprint clients.

case of end-to-end IPv6 connectivity or one NAT64 middlebox, users experiencelower latency.

In the case of Verizon in Figure 5, we observe that RTT for IPv6 sessionsis similar to RTT for connections via IPv4-in-IPv6 tunnels. We expect the twoRTTs to be similar since in case of IPv4-in-IPv6 tunneling, all packets are sentfrom the device over the IPv6 network, resulting in similar RTT as end-to-endIPv6 sessions. The RTT over IPv4 network however is influenced by CGNs andLSNs and thus experience significantly higher latency than end-to-end IPv6 orIPv4-in-IPv6 tunneled sessions. For example, for median and 80% of sessions onVerizon, the RTT over IPv6 network is about 29% and 44% faster than RTTover its IPv4 network, respectively. We argue that the reduced RTT over IPv6networks is likely due to two factors: 1) no stateful middleboxes in IPv6 net-work, and 2) use of IPv6 connectivity over LTE network, as opposed to usingIPv4 connectivity over 3G networks.

In case of AT&T and Sprint in Figures 6 and 7 respectively, we observe thatRTT over IPv6 network is slightly lower than RTT over their respective IPv4networks, especially in the long tail. For example, for median and 80% of sessionson AT&T network in Figure 6, the RTT over IPv6 is 17% and 24% faster thanRTT over its IPv4 network, respectively. Further, RTT for sessions establishedby IPv6 clients with IPv4 servers is similar to RTT for sessions established byIPv4 clients with IPv4 servers. We expect the two RTTs to be similar becauseboth AT&T and Sprint are dual-stacked networks and therefore both IPv6 andIPv4 clients must connect to IPv4 servers over their respective IPv4 networks –resulting in similar latency. Similarly to T-Mobile, we argue that RTT over IPv6networks of AT&T and Sprint is lower than RTT over IPv4 because there areno stateful middleboxes in their IPv6 networks.

Discussion: Although, we observe that providing mobile content over IPv6offers reduced latency for end-users, we identified a cellular network outside theUS where, during our study, RTT over IPv6 network was higher than RTT overits IPv4 network, by almost 200 ms. To investigate, we ran traceroutes from CDNservers to several IPv6 client IP addresses in that network and identified thatIPv6 packets were being routed through another country – resulting in higherRTT over its IPv6 network. While it is possible that IPv6 could be slower thanIPv4 in some networks, it could be related to how IPv6 packets are forwardedon the Internet.

0.0 0.2 0.4 0.6 0.8 1.0

0.0

0.2

0.4

0.6

0.8

1.0

Normalized DNS Lookup Time

CD

F of

Req

uest

s

IPv4 ClientIPv6 Client

Fig. 8. DNS Lookup time forT-Mobile clients.

0.0 0.2 0.4 0.6 0.8 1.0

0.2

0.4

0.6

0.8

1.0

Normalized DNS Lookup Time

CD

F of

Req

uest

s

IPv4 ClientIPv6 Client

Fig. 9. DNS Lookup time forVerizon clients.

5 DNS Lookup Time for IPv6 and IPv4 Clients

DNS lookup time is also an important factor influencing the Web performance [25].In this section, we are interested in measuring the DNS lookup time for both IPv6and IPv4 clients resolving dual-stacked domain names. In Figures 8–11, we showthe distribution of DNS lookup times when IPv6 and IPv4 clients resolve dual-stacked domain names. For the same reason as RTT comparison, we normalizethe lookup times independently for each network. The dotted CDF lines repre-sent the lookup time when domains are resolved for IPv6 clients, whereas, thesolid CDF lines represent lookup time when domains are resolved for IPv4 clients.

In general, we see that, in our testing, DNS lookup takes longer for IPv6clients than IPv4 clients in T-Mobile, AT&T, and Sprint networks, however,for Verizon’s IPv6 and IPv4 clients, the DNS lookup times are similar. DNSlookup times for IPv6 clients are influenced by their technique to perform DNSresolutions. Client devices are unaware of whether content from a domain isavailable over IPv4 network or over IPv6 network. Therefore, clients must sendboth AAAA (IPv6) and A (IPv4) DNS queries to their local resolvers to resolvedomain names. If an IPv6 address for the requested domain is available, Androidclients prefer to connect with the IPv6 address, instead of the IPv4 address of theserver [26]. Although, the two DNS requests could be sent in parallel to reducethe time to perform the DNS lookups, we observe that regardless of the type ofdomain (IPv4-only or dual-stack), IPv6 Android clients always issue both AAAA

and A DNS queries in serial. Further, before returning the DNS response to theapplication, the IPv6 clients wait until responses for both queries arrive or theresolutions times out. Therefore, the DNS resolution on IPv6 Android clientsrequire two round trips between clients and DNS server, whereas, IPv4 Androidclients wait for only one round trip for resolving the domain via type A query.

In the case of T-Mobile in Figure 8, we observe that the median DNS lookuptime for IPv6 clients is 25.7% slower than IPv4 clients, because IPv6 clients waitfor both type AAAA and A queries, whereas IPv4 clients wait for only type A query.However, for about 20% of DNS requests, IPv6 clients experience faster resolu-tion time than IPv4 clients. We argue that since T-Mobile’s IPv6 clients canonly transmit IPv6 packets into the network, IPv6 devices send DNS queriesto an IPv6 address of the local resolver, which indicates that the lookups for

0.0 0.2 0.4 0.6 0.8 1.0

0.0

0.2

0.4

0.6

0.8

1.0

Normalized DNS Lookup Time

CD

F of

Req

uest

s

IPv4 ClientIPv6 Client

Fig. 10. DNS Lookup time forAT&T clients.

0.0 0.2 0.4 0.6 0.8 1.0

0.0

0.2

0.4

0.6

0.8

1.0

Normalized DNS Lookup Time

CD

F of

Req

uest

s

IPv4 ClientIPv6 Client

Fig. 11. DNS Lookup time forSprint clients.

IPv6 clients within T-Mobile network take place over the IPv6 network. Ourearlier observation from Figure 4 shows that RTT over IPv6 network is lowerthan IPv4 network, therefore, the DNS lookups for IPv6 clients are offset by thisadvantage, and some IPv6 lookups outperform the lookup time of IPv4 clients,even though DNS lookup process for IPv6 clients waits for an extra round tripbetween the clients and the local resolver.

In the case of Verizon in Figure 9, we observe that about 60% of the DNSqueries by IPv6 clients take same time as queries by IPv4 clients. Similarly toT-Mobile, IPv6 clients in Verizon network transmit IPv6 packets into the net-work, which results in DNS lookups over the IPv6 network. From Figure 5, weknow that RTT over Verizon’s IPv6 network is significantly lower than its IPv4network (due to no NAT middleboxes over IPv6 and the use of LTE network byIPv6 clients), therefore the DNS lookup time for IPv6 clients is similar to lookuptime for IPv4 clients.

In the case of AT&T and Sprint in Figures 10 and 11 respectively, we observethat the median DNS lookup times for IPv6 clients are about 37.9%, and 37.8%slower than lookup times for IPv4 client. We expect this to happen since bothIPv4 and IPv6 clients in these networks use their respective IPv4 networks tosend DNS queries to local resolvers, RTT for IPv4 packets sent by IPv6 and IPv4clients is similar (from Figures 6 and 7), and IPv6 clients wait for responses fortwo DNS queries in serial.

Discussion: Although, we observe DNS lookups are slower for IPv6 clients inT-Mobile, AT&T, and Sprint networks, we expect their impact on the webpageload time over these networks to be minimal, since the RTT over IPv6 networkis lower than RTT over IPv4 networks, which accounts for most of the roundtrips when loading a webpage. For IPv6 clients in Verizon, we do not expect anegative impact of lookup time on webpage load time. We also argue that if An-droid devices send DNS queries in parallel, lookup times could be significantlyreduced for IPv6 clients.

6 Webpage Load Time over IPv6 and IPv4 Networks

Interactive webpages consist of potentially multiple DNS lookups and requiremultiple round trips between clients and servers to download static Web ob-jects. Therefore, to investigate the overall impact of lower RTT and higher DNS

0.0 0.2 0.4 0.6 0.8 1.0

0.0

0.2

0.4

0.6

0.8

1.0

Normalized Page Load Time

CD

F of

Req

uest

s

via IPv6 Networkvia IPv4 Network

Fig. 12. Dual-Stack web-page PLT for T-Mobile.

0.0 0.2 0.4 0.6 0.8 1.0

0.0

0.2

0.4

0.6

0.8

1.0

Normalized Page Load Time

CD

F of

Req

uest

s

via IPv6 Networkvia IPv4 Network

Fig. 13. Dual-Stack web-page PLT for Verizon.

0.0 0.2 0.4 0.6 0.8 1.0

0.0

0.2

0.4

0.6

0.8

1.0

Normalized Page Load Time

CD

F of

Req

uest

s

via IPv6 Networkvia IPv4 Network

Fig. 14. Dual-Stack web-page PLT for AT&T.

0.0 0.2 0.4 0.6 0.8 1.0

0.0

0.2

0.4

0.6

0.8

1.0

Normalized Page Load Time

CD

F of

Req

uest

s

via IPv6 Networkvia IPv4 Network

Fig. 15. Dual-Stack web-page PLT for Sprint.

0.0 0.2 0.4 0.6 0.8 1.0

0.0

0.2

0.4

0.6

0.8

1.0

Normalized Page Load Time

CD

F of

Req

uest

s

via NAT64via IPv4 Network

Fig. 16. IPv4 webpage PLTfor T-Mobile.

0.0 0.2 0.4 0.6 0.8 1.0

0.0

0.2

0.4

0.6

0.8

1.0

Normalized Page Load Time

CD

F of

Req

uest

s

via IPv4-in-IPv6 Tunnelvia IPv4 Network

Fig. 17. IPv4 webpage PLTfor Verizon.

lookup times on Web performance, we compare the webpage load time (PLT)over IPv6 and IPv4 networks. For this part of the study, we analyzed measure-ment data for two types of webpages; 1) those available over both IPv6 and IPv4networks, and 2) those available over only IPv4 network. To mitigate influenceof mobile hardware on PLTs [24], we consider PLTs from only one specific de-vice model for each cellular carrier. Further, to reliably identify performance ofwebpage loads over IPv6 and IPv4 networks, we consider PLTs for only one WebURL loaded on one specific device model for each network.

IPv6 webpage PLT: In Figures 12–15, we show the distribution of pageload time of one dual-stacked webpage loaded by IPv6 clients over networks andloaded by IPv4 clients over IPv4 network. We normalize the PLTs indepen-dently for each network. The solid CDF lines show PLTs when the page wasloaded over IPv6 network. The doted CDF lines show PLTs when the page wasloaded over IPv4 network. In general, we observe that for all four US carriers,the PLTs of pages loaded by IPv6 clients over IPv6 networks are lower thanPLTs of the same pages loaded by IPv4 clients over the respective carrier’s IPv4networks. Further, despite DNS lookup times being higher for IPv6 clients, weobserve that PLTs are lower for IPv6 clients loading pages over IPv6 network.We argue that DNS lookup times for IPv6 clients influence the overall page loadtime by just one extra round trip, and that the actual benefits of faster IPv6 net-work are observed when multiple Web objects are loaded over the IPv6 networkin several round trips.

In case of T-Mobile in Figure 12, we observe that for median and 80% of pageloads by IPv6 clients, the PLTs over IPv6 network are 8.8% and 13.6% fasterthan PLTs over T-Mobile’s IPv4 network. In Figure 13, we observe similar re-ductions in PLTs for pages loaded by Verizon’s IPv6 clients over Verizon’s IPv6

0.0 0.2 0.4 0.6 0.8 1.0

0.0

0.2

0.4

0.6

0.8

1.0

Normalized Page Load Time

CD

F of

Req

uest

s

V6 Client via IPv4 NetworkV4 Client via IPv4 Network

Fig. 18. IPv4 webpage PLT forAT&T.

0.0 0.2 0.4 0.6 0.8 1.0

0.0

0.2

0.4

0.6

0.8

1.0

Normalized Page Load Time

CD

F of

Req

uest

s

V6 Client via IPv4 NetworkV4 Client via IPv4 Network

Fig. 19. IPv4 webpage PLT forSprint.

network. Specifically, we show that for median and 80% of the webpage loadsby IPv6 clients over Verizon’s IPv6 network are 48% and 64% faster than PLTsover its IPv4 network. For AT&T and Sprint as well, we observe that PLTs arelower when loaded over IPv6 network.

IPv4 webpage PLT: In Figures 16–19, we show distribution of PLTs ofan IPv4 webpage, loaded by IPv6 and IPv4 clients. We normalize the PLTsindependently for each network. The dashed CDF lines show PLTs when IPv6clients load an IPv4 webpage via NAT64 (in T-Mobile), via IPv4-in-IPv6 tun-nel (in Verizon), or via IPv4 network (in AT&T and Sprint). The dotted CDFlines show PLTs when IPv4 clients load an IPv4 webpage over the IPv4 net-work. In general, we observe that T-Mobile and Verizon IPv6 clients experiencereduced PLTs for IPv4 webpages, likely due to reduced RTT when using NAT64in T-Mobile and use of LTE and IPv6 network in Verizon. For example, in Fig-ure 17, we show that the median and 80% of the IPv4 page loads in Verizon,are about 49% and 67% faster than page loads over IPv4 network. In the case ofIPv6 clients in AT&T and Sprint network, we observe that IPv4 webpage PLTsare similar (in AT&T) or occasionally slower (in Sprint) than PLTs experiencedby IPv4 clients. We expect the two PLTs to be similar since both IPv6 andIPv4 clients use the IPv4 network to load IPv4 websites. However, in some caseswe expect the PLTs by IPv6 clients to be slower, since such clients wait for anadditional DNS query for each domain in the webpage.

Discussion: Based on our findings on page load times, we show that for IPv6clients in T-Mobile and Verizon networks, both IPv4-only and dual-stacked web-sites will load faster than IPv4 clients loading the same websites over the carrier’srespective IPv4 network. For dual-stacked networks, such as AT&T and Sprint,IPv6 clients in such networks experience faster page loads for only dual-stackedwebsites. Further, websites available over IPv4 only may occasionally experiencepoor performance on IPv6 clients, likely due to slower DNS lookups that lowerIPv6 latency cannot offset. Finally, we argue that since users are likely to visitwebsites from different network, providing mobile content over IPv6 will not hurtthe Web performance and in fact in some cases, the Web performance will beimproved if pages are served over IPv6.

7 Related Work

Previous studies have evaluated the adoption rate of IPv6 across different carri-ers worldwide, indicating a significant growth in the IPv6 traffic over years [12,17, 20, 23]. While understanding the adoption of IPv6 is important, a panel atthe recent @Scale conference brought the IPv6 community together to discussvarious challenges that network operators face specific to upgrading network in-frastructure from IPv4 to IPv6 addressing [3]. Specifically, mobile operators sug-gest browser providers to not fallback on IPv4 when IPv6 connectivity is slow,as the fallback to IPv4 may mask critical performance issues related to IPv6connectivity [3]. Mobile operators also suggest application developers to designtheir applications to support IPv6 connectivity – a complement to Apple’s re-cent announcement of IPv6 support in all iOS9 applications [19]. With respectto measuring Web performance over IPv6 networks, a study by Dhamdhere et al.investigates the impact of changes in BGP routing on the performance of IPv6networks [13]. Other studies suggest methods to improve Web performance byselectively handing out answers to AAAA queries based on how good is the cur-rent IPv6 connectivity behind the client’s resolver network [11, 18]. In contrast tothese studies, our work focuses on understanding whether providing static con-tent over IPv6 in cellular networks improve the Web performance for end-users.

8 Conclusions

The growing numbers of mobile users have motivated cellular carriers to adoptand provide Internet connectivity over IPv6, as IPv4 addressing can not uniquelyidentify active device sessions. However, the impact of providing mobile contentover IPv6 is not yet well understood in the server providers, content providersand developer communities. In this paper, we present a comprehensive mea-surement study to characterize the performance of different IPv6 deploymenttechniques employed by four major US cellular carriers. Our study reveals thatproviding mobile Web content over IPv6 does not degrade the Web performancefor end-users and in fact in some networks the Web performance is improved ifthe content is served over IPv6. Based on our findings, we argue that server andapplication support for IPv6 has the potential to improve the Web performancefor end users.

Acknowledgments

We thank Ajay Miyyapuram and Kanika Shah for their invaluable insights onrefining our research directions. We thank National Science Foundation for par-tially supporting this work through the grant NSF CNS-1555591.

References

1. Akamai EdgeScape. http://uk.akamai.com/dl/brochures/edgescape_service_

description.pdf, Mar. 2002.2. Sprint to Participate in World IPv6 Day. http://newsroom.sprint.com/news-

releases/sprint-to-participate-in-world-ipv6-day.htm, Apr. 2011.

3. Facebook: IPv6 is here and You’re Hurting your Users. https://www.youtube.

com/watch?v=_7rcAIbvzVY, Sept. 2015.4. Navigation Timing. http://w3c.github.io/navigation-timing/, Aug. 2015.5. Real User Monitoring. https://www.akamai.com/us/en/resources/real-user-

monitoring.jsp, Aug. 2015.6. APNIC 34. IPv6 at Verizon Wireless. https://www.hpc.mil/images/hpcdocs/

ipv6/vzw_apnic_13462152832-2.pdf, Aug. 2012.7. J. Arkko and F. Baker. Guidelines for Using IPv6 Transition Mechanisms during

IPv6 Deployment. https://tools.ietf.org/html/rfc6180, May 2011.8. AT&T Public Policy Blog. It’s World IPv6 Day. http://www.attpublicpolicy.

com/administration/it’s-world-ipv6-day/, Jun. 2011.9. Ben Parker. IPv6 Transition for VzW. https://sites.google.com/site/

ipv6implementors/2010/agenda/14_Parker_VerizonWireless.pdf, Jun. 2010.10. C. Byrne. 464XLAT: Breaking Free of IPv4. https://conference.apnic.net/

data/37/464xlat-apricot-2014_1393236641.pdf, Feb. 2014.11. L. Colitti. Broken IPv6 Clients. https://sites.google.com/site/

ipv6implementors/2010/agenda/BrokenIPv6clients.pdf, Jun. 2010.12. L. Colitti, S. H. Gunderson, E. Kline, and T. Refice. Evaluating IPv6 Adoption in

the Internet. In Passive and Active Measurement, Apr. 2010.13. A. Dhamdhere, M. Luckie, B. Huffaker, k. claffy, A. Elmokashfi, and E. Aben.

Measuring the Deployment of IPv6: Topology, Routing and Performance. In ACMIMC, Nov 2012.

14. F. Brockners, S. Gundavelli, S. Speicher and D. Ward. Gateway-Initiated Dual-Stack Lite Deployment. https://tools.ietf.org/html/rfc6674, Jul. 2012.

15. U. Goel, M. Steiner, M. P. Wittie, M. Flack, and S. Ludin. Detecting CellularMiddle-boxes using Passive Measurement Techniques. In Submission, 2015.

16. U. Goel, M. P. Wittie, and M. Steiner. Faster Web through Client-assisted CDNServer Selection. In IEEE International Conference on Computer Communicationsand Networks, Aug. 2015.

17. R. Kisteleki. Measuring IPv6 usage at web clients and DNS re-solvers. https://sites.google.com/site/ipv6implementors/2010/agenda/07_

robert-kisteleki-measure-v6.pdf, Jun. 2010.18. E. Kline. IPv6 Whitelist Operations. https://sites.google.com/site/

ipv6implementors/2010/agenda/IPv6_Whitelist_Operations.pdf, Jun. 2010.19. P. Lakhera. Your App and Next Generation Networks. https://developer.apple.

com/videos/wwdc/2015/?id=719, June. 2015.20. E. Nygren. Three years since World IPv6 Launch: strong IPv6 growth con-

tinues. https://blogs.akamai.com/2015/06/three-years-since-world-ipv6-

launch-strong-ipv6-growth-continues.html, Jun. 2015.21. B. Reed. LTE devices must support IPv6, says Verizon. http:

//www.networkworld.com/article/2257267/lan-wan/lte-devices-must-

support-ipv6--says-verizon.html, Jun. 2009.22. P. Richter, M. Allman, R. Bush, and V. Paxson. A Primer on IPv4 Scarcity. In

Sigcomm CCR, Apr. 2015.23. P. Saab. Facebook V6 World Congress 2015. https://www.youtube.com/watch?

v=An7s25FSK0U, Mar. 2015.24. M. Steiner and R. Gao. Should I Upgrade my Smartphone? In Submission, 2015.25. A. Vulimiri, P. B. Godfrey, R. Mittal, J. Sherry, S. Ratnasamy, and S. Shenker.

Low Latency via Redundancy. In ACM CoNEXT, Dec 2013.26. D. Wing and A. Yourtchenko. Happy Eyeballs: Success with Dual-Stack Hosts.

https://tools.ietf.org/html/rfc6555, Apr. 2012.