Utkarsh Goel, Moritz Steiner, Mike P. Wittie, Martin Flack, Stephen Ludin

Published at ACM MobiCom 2016New York

A Case for Faster Mobile Web in Cellular IPv6 Networks

The Rise of IPv6● A version of the Internet Protocol proposed in 1994, in deployment since

last decade.

○ IPv4 exhausted already in September 2015.

○ Need more IP address for increasing numbers of mobile users,

Internet of Things, VANETs, etc.

○ IPv6 provides 3.4 x 1038 addresses - will (almost) never run out of

address.

● Deployment is need-based

○ ISPs may still have enough IPv4 addresses

○ Existing hardware does not support IPv6

○ Small footprint of user devices with IPv6 capabilities2

Why is IPv6 Adoption Slow for Content Providers?

● Is IPv6 the right choice yet for mobile content delivery?

● Content delivery networks (CDNs) act as surrogate

infrastructure for content providers (CPs).

○ CDNs do not alter content delivery configurations

without consent of CP.

○ CPs may be unaware of IPv6 performance.

○ Is IPv6 at least as fast as IPv4?

3

Deploying IPv6

● IETF recommends dual-stacking devices

○ Just allocate both IPv4 and IPv6 addresses to client devices

■ AT&T, Sprint, and Verizon: Sounds good

○ Some ISPs do not have IPv4 addresses in the first place

■ Dual stacking will not work

■ Deploy IPv6-only network

4

Dual-Stacking the devices● AT&T and Sprint Wireless

○ Each device gets both IPv4 and IPv6

addresses.

○ Offers native IPv6 connectivity

■ IPv6 clients -> IPv6 servers

■ Steps 1 and 2

○ Offer legacy IPv4 connectivity

■ IPv6-capable clients use IPv4

networks to talk to IPv4 servers

■ IPv4 clients -> IPv4 servers

■ Steps 3, 4, and 55

Verizon Wireless

● Support for IPv6 clients connecting to IPv4

servers

○ Uses Dual Stack-Lite (DS-Lite) on the

device to encapsulate IPv4 packets

inside IPv6 headers

○ Decapsulate IPv6 headers before

sending to the IPv4 server

● Uses native IPv6 + 4g LTE network

● No IPv6 on 3G or 2G

6

T-Mobile USA

● An IPv6-only network

○ Clients always send IPv6 packets

■ No IPv4 at all

■ Even when talking to IPv4 servers

■ Utilizes DNS 64 and NAT 64

● Also supports legacy IPv4 connectivity

○ For IPv4-only capable clients

7

Summary of IPv6 Deployment

8

Network IPv6 → IPv6 IPv6 → IPv4 IPv4 → IPv4

T-Mobile Via native IPv6 Via NAT64/DNS64(over IPv6 with a NAT)

Legacy IPv4With LSNs/CGNs

Verizon Wireless

Via native IPv6 Via DS-Lite(over IPv6)

Legacy IPv4With LSNs/CGNs

AT&T Via native IPv6 Legacy IPv4With LSNs/CGNs

Legacy IPv4With LSNs/CGNs

Sprint Via native IPv6 Legacy IPv4With LSNs/CGNs

Legacy IPv4With LSNs/CGNs

Measuring Web Performance

● Make extensive use of Navigation Timing API exposed by Web browser

● Use Akamai’s Real User Monitoring (RUM) System to collect data for

millions of client sessions

9

Data Collection

10

Measuring RTT : AT&T/Sprint

11

● Both, IPv6 and IPv4 devices use IPv4 network to talk to IPv4 servers○ RTTs are similar

End-to-end IPv6 is faster than IPv4.

Measuring RTT : Verizon Wireless

12

● DS-Lite is also as fast○ DS-Lite sends packets over IPv6

without NAT middleboxes

End-to-end IPv6 is faster than IPv4.

Measuring RTT : T-Mobile

13

● End-to-end IPv6 is the fastest across all connectivities.

○ No stateful NAT middleboxes

● NAT64 offers faster RTTs than end-to-end IPv4, but slower than E2E IPv6.○ NAT64 is a stateful middlebox -

adds latency

Measuring DNS Time

14

● DNS lookups on IPv6 clients are slower than IPv4 client

● Because,○ IPv6 clients perform serial

lookup■ Clients perform AAAA

lookup, followed by A.■ TCP handshake does not

happen until both lookups are complete

Measuring DNS Time : Verizon W.

15

● DNS lookup times for IPv6 clients are similar to IPv4○ Even when AAAA and A lookups

happen in serial

● Because, Verizon’s IPv6 network works on 4G LTE.○ Benefits from both upgraded

cellular technology and no-need for middleboxes.

Fixing the DNS Latency Problem

16

● Made four recommendations to the Android team at Google

○ Send both AAAA and A DNS queries in parallel, as opposed to in serial

○ Browsers indicate OS to not wait for A lookup, when AAAA is available

○ In the case of IPv6-only clients■ Only issue AAAA lookups - No need to do A lookup

○ Cache the existence of AAAA answers■ Not necessarily caching of the actual answer.

Webpage Load Time (PLT)

● Faster page load times over IPv6.

● Slower DNS lookup does not hurt PLT

○ DNS is only one round trip, but

actual data gets downloaded

over multiple faster RTTs.

● Observed similar performance for

other networks17

The T-Mobile DNS Problem

18

Fixing the Problem with OneTrip

19

● Allow DNS Authorities to send synthesize IPv6 addresses, instead of sending a NO ANSWER.○ Similar to how DNS64 synthesizes IPv6 addresses

● Using Akamai’s infrastructure and Netalyzr crowd-sourced data, ○ Collect Client IP to DNS IP mappings

■ Which client IP resolves domains from which DNS IP○ Collect DNS IP to NAT64 mappings

■ Which DNS 64 is associated to which NAT 64■ Perform IPv6 address synthesis based on DNS IP

○ If EDNS0 is supported■ Generate mappings between client IP and NAT64■ Perform IPv6 address synthesis based on NAT64 prefix that the client

is connected to.

Fixing the DNS Problem with OneTrip

20

Fixing the DNS Problem with OneTrip

21

Conclusions

22

● IPv6 offers scalability benefits○ Offers 340 trillion trillion trillion IP addresses

● Through extensive measurements we discover that IPv6 comes with performance benefits in today’s cellular deployments○ Faster RTT over IPv6 paths○ Slower DNS lookup (addressed by our recommendations to Google

and by OneTrip)○ Lower PLT overall

● Strong case for CPs and CDNs to embrace IPv6 in mobile and complete the transition to IPv6

Thank you

Questions?

Utkarsh Goel

utkarsh.goel@cs.montana.edu