IPv6 deployment scenarios in mobile networks - netnod.se deployment... · Netnod Spring Meeting, 2011 4 © Nokia Siemens Networks GGSN Packet Core & LTE Gb Iu Gn S1-MME S1-U S11 Gi

Netnod Spring Meeting, 2011 1 © Nokia Siemens Networks

IPv6 deployment scenarios in mobile networks

Jouni Korhonen Netnod Spring Meeting 9-11 March, 2011 Stockholm, Sweden


Foreword

• This presentation concentrates in most parts to 3GPP packet core; both GPRS (2G/+3G radio) & Evolved Packet System (LTE radio).

• 3GPP system architecture release numbers are explicitly stated when different releases make difference.

• 3GPP architecture has supported IPv6 since Rel-99.. and the fundamental peculiarities & flaws originate from that time(*).

• This presentation takes a peek into some current IPv6 deployments plans and trends I have faced when discussing with operators.

• The emphasis is on getting IPv6 to the end user – not whole operator transmission/core/interconnection/roaming migration. 3GPP “IPv6 migration guideline” is in 3GPP TR29.975.

(*) see draft-korhonen-v6ops-3gpp-eps for a lot of details


In the year 2005 this was proposed for the system architecture evolution...

• Had no concept of PDP Context.. Bearerless radio concept.. • Had no mandatory IP Mobility as part of the architecture.. • Had no mandatory tunneling..

All IP Access Network

BS

BS

Serving Node - C

Serving Node - U

Service Gateway

Subscription

Operator service network

AAA Registers

Internet

Inter-connection

HA


GGSN

Packet Core & LTE

Gb

Iu Gn

S1-MME

S1-U S11

Gi

BSC

RNC

Combi SGSN

S10

RAN

NodeB

eNodeB

MME

S5 PGW SGW

LTE

3G

2G

SGi

(Gn)

Gateway

In the year 2011 this is what we got for the system architecture evolution...

PCRF

Gx

• Although not visible here, there are multiple IP Mobility & tunneling protocols: GTPv[12], MIPv4, DSMIPv6, PMIPv6, IPsec/MOBIKE, GRE..

• APNs, default and dedicated bearers, Policy Control, PDN Connections, .. • And a lot of options.. also in case of IPv6!


Some jargon and fundamentals

• Access Point Name (APN) is a fully qualified domain name and resolves to a specific gateway in an operator network. APN identifies the network to connect via the selected gateway.

• PDN (Connection) Types: IPv4, IPv6 and IPv4v6 (dual-stack). A device may have multiple PDN Connections of the same or different types open in parallel.

• Subscription profiles understand: IPv4, IPv6, IPv4v6 and IPv4_or_IPv6.

• Each IP[v4]v6 PDN Connection has exactly one unique /64.

• SLAAC is the only supported IPv6 configuration method for the mobile device.

• 3GPP separates User Plane (UP) & Control Plane (CP).

• Extensive tunneling for User Plane: transmission and payload IP versioning are independent of each other. GTP (UDP encapsulation) is the dominant tunneling protocol.

• The first real User Plane “IP aware” node is PGW/GGSN (hmm.. PMIPv6 is an exception).

• IPv6 migration solutions involving mobile host terminated tunneling strictly ruled out in 3GPP.. in standards space.. reality might prove different, though.


Mobile operators’ positions towards IPv6

• j

Mode: aggressive.. or panic • Addresses out and NATs are melting • Deploy now even if the world around you is not up to speed • IPv6-only is ok, NAT64 is ok. • Do not bother waiting for dual-stack capable handsets and core

Driver: market demand • Address shortage not an issue in the foreseen future or NATing ok • React when lack of IPv6 start causing loss of subscribers • May offer something to selected • groups (even using tunneling)

Mode: it happens eventually • ...Wait until Dual-Stack capability becomes available/justified • Accept NATing IPv4 ‘forever’ • Deploy selectively (i.e. end users don’t really care about IP version)

Driver: IPv4 address shortage • Always on apps, M2M, LTE-devices, .. need a lot of addresses • Growth of mobile broadband discourages NAT44 deployments • Simply.. out of addresses any day soon

IPv6 deployment

and migration


Introducing IPv6 in phases

• IPv6 rollout can be and is recommended to be phased:

• 1st IPv6 at the application and end-user layer: • End-user visible User Plane has technically been “switch on” for some time. • Operators have done quite a bit of testing behind the curtains. However, • Commercial offering usually involves a lot more: security(!), subscriber management/

processes, customer support, roaming, DPI, provisioning, billing, DNS, AAA, address planning, ..., and a whole lot more in-house systems & databases.

• 2nd IPv6 at the transport layer: • Since User Plane is always tunneled there seems be no hurry to upgrade transmission to

IPv6.. and sometimes transmission is owned/operator by some one else who’s IPv6 rollout schedule is different.

• Upgrading RAN and transmission to IPv6 typically not business critical. • Typically IPv6 is not the driver to touch existing IPv4 MPLS core & aggregation network. • Roaming and interconnection not even defined for IPv6 yet.. it tends to work though.

• 3rd IPv6 at all other interfaces: • 3GPP signaling protocol information elements are IPv6 aware, even when run over IPv4. • Core nodes run just fine in all IPv4 environment.. • Management systems running in IPv6 typically not business critical.


Primary colours: Supporting colours:

Typical IPv6 network introduction plan

Mobile Broadband

Internet

Core

IMS Site

Mobile Broadband Access as #2 • Packet Core IPv4 • User IPv6, (S)Gi Dual-Stack

• IPv6 either native or tunneled to Internet • Current /64 link model makes prefix delegation for home gateways problematic (prior Rel-10)

Management Network

IP Multimedia Subsystem • Can be IPv6 only • Backend interfaces can be IPV4

Network Management as last • No need to upgrade at this point *if* it understands IPv6 information elements..

Internet connectivity • Dual-Stack • Either native or tunneled

Fixed Broadband

Fixed Broadband as #1 (if available) • IPv6 provided to end-user • Either native or tunneled

• 6rd (getting popular..), etc. • After transition to IPv6 IPv4 can be provided with DS-Lite, some A+P

Core Network Dual-Stack • Native, or • MPLS - 6PE/6VPE Network Services obviously..

• DNS has to be upgraded to support IPv6 access • Reverse DNS has to be set up


Operators and IPv6 migration; common approaches for the mobile side of operator • Native Dual-Stack everywhere (3G/EPS) + NAT44:

• Slow paced introduction to network. Start with easy to control devices – like USB dongles (and having a laptop does help migration.. dialers).

• Some in a mode of waiting till LTE.. but this attitude is changing. • No desire to introduce NAT64 (no improvement over NAT44). • No desire to introduce parallel IPv4 and IPv6 bearers.. doubles ‘costs’.

• Handovers between 3G and LTE are important. If pre-Rel-8 SGSNs are still in use, it means IPv4 or IPv6 only bearers.

• IP[v4]v6 for specific use/service.. easily doable e.g. a using dedicated “IPv6 APN” subscription bundled with a subsidized IPv6 capable handset/dongle.


Operators and IPv6 migration; common approaches for the mobile side of operator • IPv6 only + NAT64:

• Not overly popular but still to be reckoned with. • Good for always on (LTE) handsets that are unlikely be used for active

internet usage and produce huge traffic volumes.. • No desire to introduce parallel IPv4 and IPv6 bearers.. doubles ‘costs’.

• Active push to get important applications to IPv6 native.

• Handovers between 3G and LTE are important. If pre-Rel-8 SGSNs are used, it means IPv4 or IPv6 only bearers. Not issue with IPv6-only+NAT64 approach.

• IP[v4]v6 for specific use/service.. easily doable e.g. a using dedicated “IPv6 APN” subscription bundled with a subsidized IPv6 capable handset/dongle.


NAT44 and NAT64 considerations..

• NAT44 has become an important topic; something needed now and most likely forever after dual-stack deployment. Operators have accepted this..

• Common to bypass NATs/FWs for heavy users and smart phones.

• NAT64 seen as bad as NAT44 but not equally important.

• 16million RFC1918 address limit has caused headache: • Huge APNs where e.g. subscriber identification based on source IP

address (usually some “Gi box” or content platform issue). • Network segmentation/overlapping private networks would help but...

• Authorities require tracking of users behind a NAT -> real time tracing and NAT logging is becoming a real issue.


NAT[46]4 deployments.. may all exist in one network and differentiated by subscriptions

IPv6-only for e.g. M2M and “simple” handset

Dual-stack.. “normal” users

dual-stack

(S)Gi Domain

PGW

NAT44 Internet IPv6

IPv4

dual-stack

(S)Gi Domain

PGW/NAT44

Internet IPv6

IPv4

• The decision of NAT placement depends on e.g. • Gateway capacity, overlapping addressing needs, • Need of “Gi boxes”, PCC integration, ..

IPv6-only

(S)Gi Domain

PGW

NAT64 Internet IPv6

IPv4

IPv6-only

(S)Gi Domain

PGW/NAT64

Internet IPv6

IPv4

UE

UE


Dual-stack deployments.. may co-exists with NAT[46]4 and differentiated by subscriptions

Dual-stack.. “power” users and always on smart phones

dual-stack

(S)Gi Domain

PGW

Internet IPv6

IPv4

• The “UE” can also be a CPE with a cellular uplink • Rel-10 introduces DHCPv6-PD.. or did someone say NAT66 or ND-

Proxy? ;) • CPE can do NAT44 for its internal network (remember, one IPv4

address per PDN Connection). • Small business or widespot area internet solution.

UE


Fallback scenarios and roaming cause confusion

• If inter-RAT handovers are desired (e.g. 3G-LTE) then network migration has to be planned and subscriptions provisioned based on the lowest common nominator: • Example: 3G has IPv4 only, then LTE can only support IPv4. • A reason for many to wait until 3G (Rel-9 feature) and EPS (Rel-8 feature)

both are IPv4v6 capable..

• A dual-stack capable handset (since Rel-8) is always supposed to first try establishing IPv4v6 connection, then fall back to something different based on 1) subscription and 2) MME/PGW/GGSN configuration: • See draft-korhonen-v6ops-3gpp-eps Section 8.7 for a full list of choices.

• There is no roaming defined yet for IP[v4]v6: • GSMA has recently started working on IPv6 roaming but in general

operators have not invested that much effort on it yet. • It just happens to work ~75% of cases for IPv6. • Real issues with inter-operator billing, thus IPv6 roaming barring is in radar.


Thank you!

Questions?

Documents

IPv6 deployment scenarios in mobile networks - netnod.se deployment... · Netnod Spring Meeting, 2011 4 © Nokia Siemens Networks GGSN Packet Core & LTE Gb Iu Gn S1-MME S1-U S11 Gi