Company Confidential

Advances in IPv6 Mobile Access

John Loughney, Nokia

john.loughney@nokia.com (with help from Teemu Savolainen, Nokia)

Company Confidential

Overview

Motivations for IPv6 in mobile networks

Main IPv6 Deployment options in mobile networks

Handset support for IPv6

Network support for IPv6

Key challenges

Practical advice

Company Confidential

Motivations

• 5.3 billion mobile subscribers, ITU-T figures for 2010.

• Large percentage are IP capable −Trend toward Always-On applications (details next slide)

• LTE is happening now, will be soon doing voice over IP only.

• Operators run both a circuit switched and IP networks, causing higher CAPEX and OPEX.

• In the future, services will migrate to IP.

• Carrier grade NATs are a misnomer.

• So the choice is between −IPv4 with NAT frequent keep-alives & additional investments

−IPv6 and long lived connections

Company Confidential

NATs with keep alive messages

• IPv4 Mobile Devices are usually behind IPv4 NATs

−Always on application are becoming more prevalent −Applications that want to be reachable need to send

periodic keep-alives to keep NAT state active − Current NATs require keep-alives from 40 seconds to 5 minutes − Need to implement for minimum (~30 seconds)

• Sending of NAT periodic keep-alive messages decreases mobile device standby time by several days

• Not a problem for devices with power cords, but for mobile devices it is a big problem

Client, Private IPv4 address 1

Server, Public IPv4 address 3 Client, Private IPv4 address 2 UDP port = 6538

The UDP inactivity timer in NATs causes the public UDP port 6538 to be assigned to a different mobile, if the mobile does not send any data within a certain amount of time, about every 40 seconds …

There should be NO NATs between the terminal and the

server!

Company Confidential

IPv6 Trial Checklist

5 © Nokia 2011 Filename.pptx v. 0.1 YYYY-MM-DD Author Document ID [Edit via Insert > Header & Footer]

• IPv6 enabled routers and switches

• IPv6 transit provider and peering

• IPv6 enabled hosts

• IPv6 enabled apps

• Address planning, address config, DNS

• Transition mechanism(s) selection

• Fallback planning

• Middlebox support (firewalls, proxies, etc.)

Company Confidential 6

Deployment approaches

Dual-stack approach is the most customer-friendly solution for transitioning to IPv6

Dual-stack is also the standard approach (3GPP) and appears to be the most favored approach

IPv6-only transition solution based on protocol translation can cause service discontinuity, and is only an option for specific cases due to discrete reasons

Company Confidential 7

Details of dual-stack

3GPP release-8 introduced a new bearer type: IPv4v6

IPv4 and IPv6 bearers can be used in parallel when IPv4v6 is not supported (since 3GPP release-99)

Various fallback scenarios are involved that are not present with IPv4-only devices, e.g. IPv4v6 -> IPv4 & IPv6

References: 3GPP release-8 23.060, 23.401 draft-ietf-v6ops-3gpp-eps

Company Confidential 8

Details of IPv6-only

Everything, including applications, MUST BE IPv6 enabled – otherwise solutions such as NAT46 on a host (aka BIH) may be needed

IPv6 is not always available: no support on visited network, blocked on purpose due lack of roaming agreements.. Fallback support to IPv4-only mode is mandatory

This is pretty much the end-scenario world is transitioning towards

Company Confidential

Services & Content

IPv6 impacts at all levels

Applications Browsers, E-mail, IM, VoIP, Games, Utilities, Middleware entities like HTTP, ...

Modem Renesas, Qualcomm, ST-E, GCT, Broadcom, Icera (Nvidia), Marvell, Infineon, MediaTek, ...

TCP/IP Stack Symbian, iOS, Android, Windows Phone, various flavors of Linux, Series 40, RIM,

API Qt, Java, Posix, Symbian & other OS APIs, ...

Google, YouTube, Akamai, Facebook, Bing, ...

Company Confidential 10

IPv6 on handsets

IPv6 support on the modem

IPv6 support on the TCP/IP stack

IPv6 support on the connection manager

IPv6 support on the applications

IPv6 support on APIs

IPv6 support required at different levels

Company Confidential

IPv6 support required by the business

11

Status of terminals

IPv6 support on the modem

IPv6 support on the TCP/IP stack

IPv6 support on the connection manager

IPv6 support on the applications

IPv6 support on APIs

Company Confidential

Phone support for IPv6

Android Motorola Droid Bionic handset for Verizon Reportedly has have IPv6 for cellular. Samsung Nexus S Has IPv6 for WLAN only.

iPhone 4S IPv6 for WLAN only

Windows Phone 7 Mango IPv4 only as no IPv6 yet on WP OS; coming in Apollo

LG VL600 CDMA/LTE dongle

Symbian Has supported IPv6 since 2004, and used in trials. Apps can use IPv4 or IPv6 cellular access but not both simultaneously. This works normally when using WiFi access.

Nokia N9 IPv6 add-on enables dual-stack in 3G and WiFi accesses.

Nokia 21M-02 2G/3G /3.5G USB dongle Supports IPv6 and IPv4v6 PDP types

Company Confidential

• Dual-stack with single PDP (IPv6v4) is the most common solution

• Some network operators are considering dual-stack with parallel PDPs (IPv6 & IPv4).

− It is required for a 3GPP fallback scenario.

• IPv6-only solution is also required by a few

• Other solutions are also queried and investigated, but not required yet − PNAT, DS-Lite, DSMIP6, A+P & DS-Lite, 6rd.

• Configurability to single PDP (IPv4v6), parallel PDPs (IPv6 & IPv4), or only

IPv6 − OMA DM (operator configuration) for APN setting

• Gradual fallback in roaming and error cases for improved user experience

− IPv4v6 ► IPv4 & IPv6 ► IPv4 or IPv6 − IPv6 ► IPv4

High level cellular requirements

Company Confidential

• Closed IPv6 trials at least since 2003 • First commercial IPv6 deployments at 2010

− While many operators are conducting internal (lab) trials

• Public trials and some commercial deployments occurring

during 2011 − Even more operators are trialing − Number of cellular IPv6 capable devices also increasing

• And things are getting even better for 2012 ! • But there are some gotchas

14

IPv6 status on mobile networks

Company Confidential

15

Gotchas

Company Confidential

• This has been a difficult topic in IETF...

• 3GPP cellular access 1. MUST take the address from PDP activation 2. Stateless DHCPv6 can be optionally supported 3. RA based approach can be supported but as not included in

3GPP specs, it is not something that can be depended upon.

• WiFi access 1. Stateless DHCPv6 is currently most widely available 2. RA based solution will probably be increasingly available as

standard RFC6106 exists (and e.g. RADVD supports this hence Linux based routers can easily have this)

• In the dual-stack case, it is just fine to talk to the DNS server

over IPv4, but IPv6 should be preferred (as general principle)

DNS server address discovery

Company Confidential

• Four possibilities for querying IPv4 and IPv6 addresses:

1) AAAA and A sequentially (Android, Maemo, Ubuntu)

2) A and AAAA sequentially (Windows 7, Symbian)

3) AAAA and A parallel

4) A and AAAA parallel (iOS, OS/X)

• Use of 3 or 4 avoids extra RTT in dual-stack networks

• The approach of sending A first is due to some legacy DNS servers screwing up if they get AAAA followed by A.. So A first may be slightly safer.

• Important to prefer IPv6 when both can be used

DNS query sending procedures

Company Confidential

”Happy Eyeballs”

Dual-Stack Internet

host

Dual-Stack WLAN FW

DNS

WWW

Silent drop

ICMPv6 no route

ICMPv6 address unreachable

1)

2)

3)

IPv6

IPv6

IPv6

Apps can improve the user experience by more aggressively making connections on IPv6 and IPv4 by using a variety of algorithms. In this approach, the application makes its connection attempts more aggressively over both IPv6 and IPv4. Initially, the connection attempts are made in order to provide a fast user experience

Endpoints issue DNS queries for AAAA and A resource records and then attempts connections to IPv6 and IPv4 addresses sequentially. If the IPv6 path is broken (or slow), it can take a long time before it falls back to IPv4 resulting in delays from 20 seconds to several minutes if the IPv6 path is broken.

Company Confidential 19

IPv6 changes tethering significantly

Traditional dial-up style IPv4 tethering uses dedicated PDP context for the dial-up IPv4 tethering solutions, often use

NAT and DHCP to allow sharing of the same mobile connection with internal applications

Traditional dial-up is possible also with IPv6

IPv6 does not use NATting, but instead Neighbor Discovery Proxy ”bridging function” that does not require explicit network support, or explicit and more proper DHCPv6 Prefix Delegation as is defined in 3GPP Release-10

Company Confidential 20

Bridging and DHCPv6 illustrated

WLAN

PDP

2001:0db8:0:1::/64

2001:0db8:0:1::/64

f(”proxy”)

PDN GW & DHCPv6 server

Handset (possibly with DHCPv6 server) Delegated e.g. 2001:0db8::/56

f(”router”)

WLAN

PDN GW

PDP

2001:0db8:0:1::/64

WLAN

2001:0db8:0:81::/64

f(”router”)

2001:0db8:0:C1::/64

Same prefix on both links

”Bridging” with Neighbor Discovery Proxy – no explicit network support is required!

DHCPv6 Prefix Delegation – support included in 3GPP since Release-10

Company Confidential

Cellular operator’s services

Internet

WiFi access

Illustration of basic WiFi offloading technologies under study

Cellular access

DHCPv6 server

Access Network Discovery and Selection Function (ANDSF)

PDN GW

Rules via DHCPv6

Provisioning rules with OMA-DM

Rules via IPv6 Router Advertisements RFC4191 draft-ietf-mif-dhcpv6-route-option draft-ietf-mif-dns-server-selection draft-korhonen-mif-ra-offload 3GPP 24.312 ANDSF

21

Routing rule DB

Company Confidential

Key specifications and standards are complete and matured for product creation and deployment

Additional features and improvements are actively researched, developed, and standardized. Nokia participates, for example, to: IPv6 protocol maintenance, Multi-Interface improvements, IP mobility solutions, protocol translation topics, and Happy Eyeballs

22

IPv6 standards are ready

Company Confidential

• Networks are getting deployed – use them

• Get a handset that supports IPv6 on both cellular and wifi

• Make sure you have apps that can speak both IPv4 and IPv6 −Don’t make address assumptions

−Address assignments are handled differently depending what interface is used

• Make sure your apps implement a ‘happy eyeballs’ algorithm

Recommendations

Company Confidential

• Internet Protocol Version 6 (IPv6) for Some Second and Third Generation Cellular Hosts

−http://tools.ietf.org/html/rfc3316

• IPv6 Node Requirements −http://tools.ietf.org/html/rfc4294

• Happy Eyeballs: Success with Dual-Stack Hosts −http://tools.ietf.org/html/draft-ietf-v6ops-happy-eyeballs-05

• Dual Stack Hosts Using "Bump-in-the-Host" (BIH) −http://tools.ietf.org/html/draft-ietf-behave-v4v6-bih-06

24

Additional reading