draft-ietf-v6ops-3gpp-eps-03.txt   draft-ietf-v6ops-3gpp-eps-04.txt 
Individual Submission J. Korhonen, Ed. Individual Submission J. Korhonen, Ed.
Internet-Draft Nokia Siemens Networks Internet-Draft Nokia Siemens Networks
Intended status: Informational J. Soininen Intended status: Informational J. Soininen
Expires: January 12, 2012 Renesas Mobile Expires: February 21, 2012 Renesas Mobile
B. Patil B. Patil
T. Savolainen T. Savolainen
G. Bajko G. Bajko
Nokia Nokia
K. Iisakkila K. Iisakkila
Renesas Mobile Renesas Mobile
July 11, 2011 August 20, 2011
IPv6 in 3GPP Evolved Packet System IPv6 in 3GPP Evolved Packet System
draft-ietf-v6ops-3gpp-eps-03 draft-ietf-v6ops-3gpp-eps-04
Abstract Abstract
Use of data services in smart phones and broadband services via HSPA Use of data services in smart phones and broadband services via HSPA
and HSPA+, in particular Internet services, has increased rapidly and and HSPA+, in particular Internet services, has increased rapidly and
operators that have deployed networks based on 3GPP network operators that have deployed networks based on 3GPP network
architectures are facing IPv4 address shortages at the Internet architectures are facing IPv4 address shortages at the Internet
registries and are feeling a pressure to migrate to IPv6. This registries and are feeling a pressure to migrate to IPv6. This
document describes the support for IPv6 in 3GPP network document describes the support for IPv6 in 3GPP network
architectures. architectures.
skipping to change at page 1, line 43 skipping to change at page 1, line 43
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on January 12, 2012. This Internet-Draft will expire on February 21, 2012.
Copyright Notice Copyright Notice
Copyright (c) 2011 IETF Trust and the persons identified as the Copyright (c) 2011 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
skipping to change at page 2, line 20 skipping to change at page 2, line 20
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
2. 3GPP Terminology and Concepts . . . . . . . . . . . . . . . . 5 2. 3GPP Terminology and Concepts . . . . . . . . . . . . . . . . 5
2.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 5 2.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 5
2.2. The concept of APN . . . . . . . . . . . . . . . . . . . . 9 2.2. The concept of APN . . . . . . . . . . . . . . . . . . . . 10
3. IP over 3GPP GPRS . . . . . . . . . . . . . . . . . . . . . . 10 3. IP over 3GPP GPRS . . . . . . . . . . . . . . . . . . . . . . 10
3.1. Introduction to 3GPP GPRS . . . . . . . . . . . . . . . . 10 3.1. Introduction to 3GPP GPRS . . . . . . . . . . . . . . . . 10
3.2. PDP Context . . . . . . . . . . . . . . . . . . . . . . . 12 3.2. PDP Context . . . . . . . . . . . . . . . . . . . . . . . 12
4. IP over 3GPP EPS . . . . . . . . . . . . . . . . . . . . . . . 12 4. IP over 3GPP EPS . . . . . . . . . . . . . . . . . . . . . . . 13
4.1. Introduction to 3GPP EPS . . . . . . . . . . . . . . . . . 13 4.1. Introduction to 3GPP EPS . . . . . . . . . . . . . . . . . 13
4.2. PDN Connection . . . . . . . . . . . . . . . . . . . . . . 14 4.2. PDN Connection . . . . . . . . . . . . . . . . . . . . . . 14
4.3. EPS bearer model . . . . . . . . . . . . . . . . . . . . . 14 4.3. EPS bearer model . . . . . . . . . . . . . . . . . . . . . 14
5. Address Management . . . . . . . . . . . . . . . . . . . . . . 15 5. Address Management . . . . . . . . . . . . . . . . . . . . . . 15
5.1. IPv4 Address Configuration . . . . . . . . . . . . . . . . 15 5.1. IPv4 Address Configuration . . . . . . . . . . . . . . . . 15
5.2. IPv6 Address Configuration . . . . . . . . . . . . . . . . 15 5.2. IPv6 Address Configuration . . . . . . . . . . . . . . . . 15
5.3. Prefix Delegation . . . . . . . . . . . . . . . . . . . . 16 5.3. Prefix Delegation . . . . . . . . . . . . . . . . . . . . 16
5.4. IPv6 Neighbor Discovery Considerations . . . . . . . . . . 16 5.4. IPv6 Neighbor Discovery Considerations . . . . . . . . . . 16
6. 3GPP Dual-Stack Approach to IPv6 . . . . . . . . . . . . . . . 17 6. 3GPP Dual-Stack Approach to IPv6 . . . . . . . . . . . . . . . 17
6.1. 3GPP Networks Prior to Release-8 . . . . . . . . . . . . . 17 6.1. 3GPP Networks Prior to Release-8 . . . . . . . . . . . . . 17
skipping to change at page 2, line 49 skipping to change at page 2, line 49
8. Deployment issues . . . . . . . . . . . . . . . . . . . . . . 23 8. Deployment issues . . . . . . . . . . . . . . . . . . . . . . 23
8.1. Overlapping IPv4 Addresses . . . . . . . . . . . . . . . . 23 8.1. Overlapping IPv4 Addresses . . . . . . . . . . . . . . . . 23
8.2. IPv6 for transport . . . . . . . . . . . . . . . . . . . . 24 8.2. IPv6 for transport . . . . . . . . . . . . . . . . . . . . 24
8.3. Operational Aspects of Running Dual-Stack Networks . . . . 25 8.3. Operational Aspects of Running Dual-Stack Networks . . . . 25
8.4. Operational Aspects of Running a Network with 8.4. Operational Aspects of Running a Network with
IPv6-only Bearers . . . . . . . . . . . . . . . . . . . . 25 IPv6-only Bearers . . . . . . . . . . . . . . . . . . . . 25
8.5. Restricting Outbound IPv6 Roaming . . . . . . . . . . . . 26 8.5. Restricting Outbound IPv6 Roaming . . . . . . . . . . . . 26
8.6. Inter-RAT Handovers and IP Versions . . . . . . . . . . . 27 8.6. Inter-RAT Handovers and IP Versions . . . . . . . . . . . 27
8.7. Provisioning of IPv6 Subscribers and Various 8.7. Provisioning of IPv6 Subscribers and Various
Combinations During Initial Network Attachment . . . . . . 28 Combinations During Initial Network Attachment . . . . . . 28
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 30 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 29
10. Security Considerations . . . . . . . . . . . . . . . . . . . 30 10. Security Considerations . . . . . . . . . . . . . . . . . . . 30
11. Summary and Conclusion . . . . . . . . . . . . . . . . . . . . 30 11. Summary and Conclusion . . . . . . . . . . . . . . . . . . . . 30
12. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 30 12. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 30
13. Informative References . . . . . . . . . . . . . . . . . . . . 30 13. Informative References . . . . . . . . . . . . . . . . . . . . 30
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 32 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 32
1. Introduction 1. Introduction
IPv6 has been specified in the 3rd Generation Partnership Project IPv6 has been specified in the 3rd Generation Partnership Project
(3GPP) standards since the early architectures developed for R99 (3GPP) standards since the early architectures developed for R99
skipping to change at page 6, line 10 skipping to change at page 6, line 10
system characterized by higher-data-rate, lower-latency, packet- system characterized by higher-data-rate, lower-latency, packet-
optimized system that supports multiple Radio Access Technologies optimized system that supports multiple Radio Access Technologies
(RAT). The EPS comprises the Evolved Packet Core (EPC) together (RAT). The EPS comprises the Evolved Packet Core (EPC) together
with the evolved radio access network (E-UTRA and E-UTRAN). with the evolved radio access network (E-UTRA and E-UTRAN).
Evolved UTRAN Evolved UTRAN
Evolved UTRAN (E-UTRAN) is communications network, sometimes Evolved UTRAN (E-UTRAN) is communications network, sometimes
referred to as 4G, and consists of eNodeBs (4G base station) which referred to as 4G, and consists of eNodeBs (4G base station) which
make up the E-UTRAN radio access network. The E-UTRAN allows make up the E-UTRAN radio access network. The E-UTRAN allows
connectivity between the mobile host/device and the core network. connectivity between the User Equipment and the core network.
GPRS tunnelling protocol GPRS tunnelling protocol
GPRS Tunnelling Protocol (GTP) [TS.29060] [TS.29274] is a GPRS Tunnelling Protocol (GTP) [TS.29060] [TS.29274] is a
tunnelling protocol defined by 3GPP. It is a network based tunnelling protocol defined by 3GPP. It is a network based
mobility protocol and similar to Proxy Mobile IPv6 (PMIPv6) mobility protocol and similar to Proxy Mobile IPv6 (PMIPv6)
[RFC5213]. However, GTP also provides functionality beyond [RFC5213]. However, GTP also provides functionality beyond
mobility such as inband signaling related to Quality of Service mobility such as inband signaling related to Quality of Service
(QoS) and charging among others. (QoS) and charging among others.
GSM EDGE Radio Access Network GSM EDGE Radio Access Network
GSM EDGE Radio Access Network (GERAN) is communications network, GSM EDGE Radio Access Network (GERAN) is communications network,
commonly referred to as 2G or 2.5G, and consists of base stations commonly referred to as 2G or 2.5G, and consists of base stations
and Base Station Controllers (BSC) which make up the GSM EDGE and Base Station Controllers (BSC) which make up the GSM EDGE
radio access network. The GERAN allows connectivity between the radio access network. The GERAN allows connectivity between the
mobile host/device and the core network. User Equipment and the core network.
Gateway GPRS Support Node Gateway GPRS Support Node
Gateway GPRS Support Node (GGSN) is a gateway function in GPRS, Gateway GPRS Support Node (GGSN) is a gateway function in GPRS,
which provides connectivity to Internet or other PDNs. The host which provides connectivity to Internet or other PDNs. The host
attaches to a GGSN identified by an APN assigned to it by an attaches to a GGSN identified by an APN assigned to it by an
operator. The GGSN also serves as the topological anchor for operator. The GGSN also serves as the topological anchor for
addresses/prefixes assigned to the mobile host. addresses/prefixes assigned to the User Equipment.
General Packet Radio Service General Packet Radio Service
General Packet Radio Service (GPRS) is a packet oriented mobile General Packet Radio Service (GPRS) is a packet oriented mobile
data service available to users of the 2G and 3G cellular data service available to users of the 2G and 3G cellular
communication systems Global System for Mobile communications communication systems Global System for Mobile communications
(GSM), and specified by 3GPP. (GSM), and specified by 3GPP.
High Speed Packet Access High Speed Packet Access
skipping to change at page 8, line 21 skipping to change at page 8, line 21
separated from packet data networks either by GGSNs or PDN separated from packet data networks either by GGSNs or PDN
Gateways (PDN-GW). Gateways (PDN-GW).
Packet Data Network Gateway Packet Data Network Gateway
Packet Data Network Gateway (PDN-GW) is a gateway function in Packet Data Network Gateway (PDN-GW) is a gateway function in
Evolved Packet System (EPS), which provides connectivity to Evolved Packet System (EPS), which provides connectivity to
Internet or other PDNs. The host attaches to a PDN-GW identified Internet or other PDNs. The host attaches to a PDN-GW identified
by an APN assigned to it by an operator. The PDN-GW also serves by an APN assigned to it by an operator. The PDN-GW also serves
as the topological anchor for addresses/prefixes assigned to the as the topological anchor for addresses/prefixes assigned to the
mobile host. User Equipment.
Packet Data Protocol Context Packet Data Protocol Context
A Packet Data Protocol (PDP) Context is the equivalent of a A Packet Data Protocol (PDP) Context is the equivalent of a
virtual connection between the host and a gateway. virtual connection between the host and a gateway.
Packet Data Protocol Type
A Packet Data Protocol Type (PDP Type) identifies the used/allowed
protocols within the PDP Context. Examples are IPv4, IPv6 and
IPv4v6 (dual stack).
S4 Serving Gateway Support Node S4 Serving Gateway Support Node
S4 Serving Gateway Support Node (S4-SGSN) is a Release-8 (and S4 Serving Gateway Support Node (S4-SGSN) is a Release-8 (and
onwards) compliant SGSN that connects 2G/3G radio access network onwards) compliant SGSN that connects 2G/3G radio access network
to EPC via new Release-8 interfaces like S3, S4, and S6d. to EPC via new Release-8 interfaces like S3, S4, and S6d.
Serving Gateway Serving Gateway
Serving Gateway (SGW) is a gateway function in EPS, which Serving Gateway (SGW) is a gateway function in EPS, which
terminates the interface towards E-UTRAN. The SGW is the Mobility terminates the interface towards E-UTRAN. The SGW is the Mobility
Anchor point for layer-2 mobility (inter-eNodeB handovers). For Anchor point for layer-2 mobility (inter-eNodeB handovers). For
each User Equipment connected with the EPS, at any given point of each User Equipment connected with the EPS, at any given point of
time, there is only one SGW. The SGW is essentially the user time, there is only one SGW. The SGW is essentially the user
plane part of the GPRS' SGSN forwarding packets between a PDN-GW. plane part of the GPRS' SGSN forwarding packets between a PDN-GW.
Serving Gateway Support Node Serving Gateway Support Node
Serving Gateway Support Node (SGSN) is a network element that is Serving Gateway Support Node (SGSN) is a network element that is
located between the radio access network (RAN) and the gateway located between the radio access network (RAN) and the gateway
(GGSN). A per mobile host point to point (p2p) tunnel between the (GGSN). A per User Equipment point to point (p2p) tunnel between
GGSN and SGSN transports the packets between the mobile host and the GGSN and SGSN transports the packets between the User
the gateway. Equipment and the gateway.
Terminal Equipment Terminal Equipment
The Terminal Equipment (TE) is any device/host connected to the The Terminal Equipment (TE) is any device/host connected to the
Mobile Terminal (MT) offering services to the use. A TE may Mobile Terminal (MT) offering services to the user. A TE may
communicate to a MT, for example, over Point to Point Protocol communicate to a MT, for example, over Point to Point Protocol
(PPP). (PPP).
UE, MS, MN and Mobile UE, MS, MN and Mobile
The terms UE (User Equipment), MS (Mobile Station), MN (Mobile The terms UE (User Equipment), MS (Mobile Station), MN (Mobile
Node) and, mobile refer to the devices which are hosts with Node) and, mobile refer to the devices which are hosts with
ability to obtain Internet connectivity via a 3GPP network. A MS ability to obtain Internet connectivity via a 3GPP network. A MS
comprises of a Terminal Equipment (TE) and a Mobile Terminal (MT). comprises of a Terminal Equipment (TE) and a Mobile Terminal (MT).
The terms UE, MS, MN and devices are used interchangeably within The terms UE, MS, MN and devices are used interchangeably within
this document. this document.
UMTS Terrestrial Radio Access Network UMTS Terrestrial Radio Access Network
UMTS Terrestrial Radio Access Network (UTRAN) is communications UMTS Terrestrial Radio Access Network (UTRAN) is communications
network, commonly referred to as 3G, and consists of NodeBs (3G network, commonly referred to as 3G, and consists of NodeBs (3G
base station) and Radio Network Controllers (RNC) which make up base station) and Radio Network Controllers (RNC) which make up
the UMTS radio access network. The UTRAN allows connectivity the UMTS radio access network. The UTRAN allows connectivity
between the mobile host/device and the core network. UTRAN between the User Equipment and the core network. UTRAN comprises
comprises of WCDMA, HSPA and HSPA+ radio technologies. of WCDMA, HSPA and HSPA+ radio technologies.
User Plane
Data traffic and the required bearers for the data traffic. In
practice IP is the only data traffic protocol used in user plane.
Wideband Code Division Multiple Access Wideband Code Division Multiple Access
The Wideband Code Division Multiple Access (WCDMA) is the radio The Wideband Code Division Multiple Access (WCDMA) is the radio
interface used in UMTS networks. interface used in UMTS networks.
eNodeB eNodeB
The eNodeB is a base station entity that supports the Long Term The eNodeB is a base station entity that supports the Long Term
Evolution (LTE) air interface. Evolution (LTE) air interface.
2.2. The concept of APN 2.2. The concept of APN
The Access Point Name (APN) essentially refers to a gateway in the The Access Point Name (APN) essentially refers to a gateway in the
3GPP network. The 'complete' APN is expressed in a form of a Fully 3GPP network. The 'complete' APN is expressed in a form of a Fully
Qualified Domain Name (FQDN) and also piggybacked on the Qualified Domain Name (FQDN) and also piggybacked on the
administration of the DNS namespace, thus effectively allowing the administration of the DNS namespace, thus effectively allowing the
discovery of gateways using the DNS. Mobile hosts/devices can choose discovery of gateways using the DNS. User Equipment (UE) can choose
to attach to a specific gateway in the packet core. The gateway to attach to a specific gateway in the packet core. The gateway
provides connectivity to the Packet Data Network (PDN) such as the provides connectivity to the Packet Data Network (PDN) such as the
Internet. An operator may also include gateways which do not provide Internet. An operator may also include gateways which do not provide
Internet connectivity, rather a connectivity to closed network Internet connectivity, rather a connectivity to closed network
providing a set of operator's own services. A mobile host/device can providing a set of operator's own services. A UE can be attached to
be attached to one or more gateways simultaneously. The gateway in a one or more gateways simultaneously. The gateway in a 3GPP network
3GPP network is the GGSN or PDN-GW. Figure 1 below illustrates the is the GGSN or PDN-GW. Figure 1 below illustrates the APN-based
APN-based network connectivity concept. network connectivity concept.
.--. .--.
_(. `) _(. `)
.--. +------------+ _( PDN `)_ .--. +------------+ _( PDN `)_
_(Core`. |GW1 |====( Internet `) _(Core`. |GW1 |====( Internet `)
+---+ ( NW )------|APN=internet| ( ` . ) ) +---+ ( NW )------|APN=internet| ( ` . ) )
[MN]~~~~|RAN|----( ` . ) )--+ +------------+ `--(_______)---' [UE]~~~~|RAN|----( ` . ) )--+ +------------+ `--(_______)---'
^ +---+ `--(___.-' | ^ +---+ `--(___.-' |
| | .--. | | .--.
| | +----------+ _(.PDN`) | | +----------+ _(.PDN`)
| +--|GW2 | _(Operator`)_ | +--|GW2 | _(Operator`)_
| |APN=OpServ|====( Services `) | |APN=OpServ|====( Services `)
MN is attached +----------+ ( ` . ) ) UE is attached +----------+ ( ` . ) )
to GW1 and GW2 `--(_______)---' to GW1 and GW2 `--(_______)---'
simultaneously simultaneously
Figure 1: Mobile host/device attached to multiple APNs simultaneously Figure 1: User Equipment attached to multiple APNs simultaneously
3. IP over 3GPP GPRS 3. IP over 3GPP GPRS
3.1. Introduction to 3GPP GPRS 3.1. Introduction to 3GPP GPRS
A simplified 2G/3G GPRS architecture is illustrated in Figure 2. A simplified 2G/3G GPRS architecture is illustrated in Figure 2.
This architecture basically covers the GPRS core network since R99 to This architecture basically covers the GPRS core network since R99 to
Release-7, and radio access technologies such as GSM (2G), EDGE (2G, Release-7, and radio access technologies such as GSM (2G), EDGE (2G,
often referred as 2.5G), WCDMA (3G) and HSPA(+) (3G, often referred often referred as 2.5G), WCDMA (3G) and HSPA(+) (3G, often referred
as 3.5G). The architecture shares obvious similarities with the as 3.5G). The architecture shares obvious similarities with the
Evolved Packet System (EPS) as will be seen in Section 4. Based on Evolved Packet System (EPS) as will be seen in Section 4. Based on
Gn/Gp interfaces, the GPRS core network functionality is logically Gn/Gp interfaces, the GPRS core network functionality is logically
implemented on two network nodes, the SGSN and the GGSN. implemented on two network nodes, the SGSN and the GGSN.
3G .--. 3G
Uu +-----+ Iu +----+ +----+ _( `. .--. .--.
[TE]+[MT]~~|~~~|UTRAN|--|---|SGSN|--|---|GGSN|--|----( PDN ) Uu _( `. Iu +----+ +----+ _( `.
+-----+ +----+ Gn +----+ Gi ( ` . ) ) [UE]~~|~~~( UTRAN )--|---|SGSN|--|---|GGSN|--|----( PDN )
/ | `--(___.-' ( ` . ) ) +----+ Gn +----+ Gi ( ` . ) )
2G Gb-- | `--(___.-' / | `--(___.-'
+---+ / --Gp / |
[TE]+[MT]~~|~~~|BSS|___/ | 2G Gb-- |
Um +---+ .--. .--. / |
_(. `) _( `. / --Gp
[UE]~~|~~( PDN )__/ |
Um ( ` . ) ) .--.
`--(___.-' _(. `)
_( [GGSN] `)_ _( [GGSN] `)_
( other `) ( other `)
( ` . PLMN ) ) ( ` . PLMN ) )
`--(_______)---' `--(_______)---'
Figure 2: Overview of the 2G/3G GPRS Logical Architecture Figure 2: Overview of the 2G/3G GPRS Logical Architecture
Gn/Gp: These interfaces provide a network based mobility service for Gn/Gp: These interfaces provide a network based mobility service for
a mobile host and are used between a SGSN and a GGSN. The Gn a UE and are used between a SGSN and a GGSN. The Gn
interface is used when GGSN and SGSN are located inside one interface is used when GGSN and SGSN are located inside one
operator (i.e. PLMN). The Gp-interface is used if the GGSN operator (i.e. PLMN). The Gp-interface is used if the GGSN
and the SGSN are located in different operator domains (i.e. and the SGSN are located in different operator domains (i.e.
'other' PLMN). GTP protocol is defined for the Gn/Gp 'other' PLMN). GTP protocol is defined for the Gn/Gp
interfaces (both GTP-C for the control plane and GTP-U for interfaces (both GTP-C for the control plane and GTP-U for
the user plane). the user plane).
Gb: Is the Base Station System (BSS) to SGSN interface, which is Gb: Is the Base Station System (BSS) to SGSN interface, which is
used to carry information concerning packet data transmission used to carry information concerning packet data transmission
and layer-2 mobility management. The Gb-interface is based and layer-2 mobility management. The Gb-interface is based
skipping to change at page 11, line 47 skipping to change at page 12, line 5
used to carry information concerning packet data transmission used to carry information concerning packet data transmission
and layer-2 mobility management. The user plane part of the and layer-2 mobility management. The user plane part of the
Iu-interface (actually the Iu-PS) is based on GTP-U. The Iu-interface (actually the Iu-PS) is based on GTP-U. The
control plane part of the Iu-interface is based on Radio control plane part of the Iu-interface is based on Radio
Access Network Application Protocol (RANAP). Access Network Application Protocol (RANAP).
Gi: It is the interface between the GGSN and a PDN. The PDN may Gi: It is the interface between the GGSN and a PDN. The PDN may
be an operator external public or private packet data network be an operator external public or private packet data network
or an intra-operator packet data network. or an intra-operator packet data network.
Uu/Um: Are either 2G or 3G radio interfaces between a mobile Uu/Um: Are either 2G or 3G radio interfaces between a UE and a
terminal and a respective radio access network. respective radio access network.
The SGSN is responsible for the delivery of data packets from and to The SGSN is responsible for the delivery of data packets from and to
the mobile hosts within its geographical service area when a direct the UE within its geographical service area when a direct tunnel
tunnel option is not used. If the direct tunnel is used, then the option is not used. If the direct tunnel is used, then the user
user plane goes directly between the RNS and the GGSN. The control plane goes directly between the RNC (in the RNS) and the GGSN. The
plane traffic always goes through the SGSN. For each mobile host control plane traffic always goes through the SGSN. For each UE
connected with the GPRS, at any given point of time, there is only connected with the GPRS, at any given point of time, there is only
one SGSN. one SGSN.
3.2. PDP Context 3.2. PDP Context
A PDP context is an association between a mobile host represented by A PDP (Packet Data Protocol) context is an association between a UE
one IPv4 address and/or one /64 IPv6 prefix and a PDN represented by represented by one IPv4 address and/or one /64 IPv6 prefix and a PDN
an APN. Each PDN can be accessed via a gateway (typically a GGSN or represented by an APN. Each PDN can be accessed via a gateway
PDN-GW). On the device/mobile host a PDP context is equivalent to a (typically a GGSN or PDN-GW). On the UE a PDP context is equivalent
network interface. A host may hence be attached to one or more to a network interface. A UE may hence be attached to one or more
gateways via separate connections, i.e. PDP contexts. Each primary gateways via separate connections, i.e. PDP contexts. Each primary
PDP context has its own IPv4 address and/or one /64 IPv6 prefix PDP context has its own IPv4 address and/or one /64 IPv6 prefix
assigned to it by the PDN and anchored in the corresponding gateway. assigned to it by the PDN and anchored in the corresponding gateway.
Applications on the host use the appropriate network interface (PDP Applications on the UE use the appropriate network interface (PDP
context) for connectivity to a specific PDN. Figure 3 represents a context) for connectivity to a specific PDN. Figure 3 represents a
high level view of what a PDP context implies in 3GPP networks. high level view of what a PDP context implies in 3GPP networks.
Y Y
| +---------+ .--. | +---------+ .--.
|--+ __________________________ | APNx in | _( `. |--+ __________________________ | APNx in | _( `.
| |O______PDPc1_______________)| GGSN / |----(Internet) | |O______PDPc1_______________)| GGSN / |----(Internet)
|MS| | PDN-GW | ( ` . ) ) | | | PDN-GW | ( ` . ) )
|/ | +---------+ `--(___.-' |UE| +---------+ `--(___.-'
|UE| _______________________ +---------+ .--. | | _______________________ +---------+ .--.
| |O______PDPc2____________)| APNy in | _(Priv`. | |O______PDPc2____________)| APNy in | _(Priv`.
+--+ | GGSN / |-------(Network ) +--+ | GGSN / |-------(Network )
| PDN-GW | ( ` . ) ) | PDN-GW | ( ` . ) )
+---------+ `--(___.-' +---------+ `--(___.-'
Figure 3: PDP contexts between the MS/UE and gateway Figure 3: PDP contexts between the MS/UE and gateway
In the above figure there are two PDP contexts at the MS/UE (UE=User In the above figure there are two PDP contexts at the MS/UE (UE=User
Equipment in 3GPP parlance). The 'PDPc1' PDP context that is Equipment in 3GPP parlance). The 'PDPc1' PDP context that is
connected to APNx provided Internet connectivity and the 'PDPc2' PDP connected to APNx provided Internet connectivity and the 'PDPc2' PDP
skipping to change at page 13, line 4 skipping to change at page 13, line 7
connected to APNx provided Internet connectivity and the 'PDPc2' PDP connected to APNx provided Internet connectivity and the 'PDPc2' PDP
context provides connectivity to a private IP network via APNy (as an context provides connectivity to a private IP network via APNy (as an
example this network may include operator specific services such as example this network may include operator specific services such as
MMS (Multi media service). An application on the host such as a web MMS (Multi media service). An application on the host such as a web
browser would use the PDP context that provides Internet connectivity browser would use the PDP context that provides Internet connectivity
for accessing services on the Internet. An application such as MMS for accessing services on the Internet. An application such as MMS
would use APNy in the figure above because the service is provided would use APNy in the figure above because the service is provided
through the private network. through the private network.
4. IP over 3GPP EPS 4. IP over 3GPP EPS
4.1. Introduction to 3GPP EPS 4.1. Introduction to 3GPP EPS
In its most basic form, the EPS architecture consists of only two In its most basic form, the EPS architecture consists of only two
nodes on the user plane, a base station and a core network Gateway nodes on the user plane, a base station and a core network Gateway
(GW). The basic EPS architecture is illustrated in Figure 4. The (GW). The basic EPS architecture is illustrated in Figure 4. The
Mobility Management Entity (MME) node performs control-plane functional split of gateways allows for operators to choose optimized
functionality and is separated from the node(s) that performs bearer- topological locations of nodes within the network and enables various
plane functionality (GW), with a well-defined open interface between deployment models including the sharing of radio networks between
them (S11). The optional interface S5 can be used to split the different operators. This also allows independent scaling and growth
Gateway (GW) into two separate nodes, the Serving Gateway (SGW) and of traffic throughput and control signal processing.
the PDN-GW. This allows independent scaling and growth of traffic
throughput and control signal processing. The functional split of
gateways also allows for operators to choose optimized topological
locations of nodes within the network and enables various deployment
models including the sharing of radio networks between different
operators.
+--------+ +--------+
S1-MME +-------+ S11 | IP | S1-MME +-------+ S11 | IP |
+----|----| MME |---|----+ |Services| +----|----| MME |---|----+ |Services|
| | | | +--------+ | | | | +--------+
| +-------+ | |SGi | +-------+ | |SGi
+----+ LTE-Uu +-------+ S1-U +-------+ S5 +-------+ +----+ LTE-Uu +-------+ S1-U +-------+ S5 +-------+
|MN |----|---|eNodeB |---|----------------| SGW |--|---|PDN-GW | |UE |----|---|eNodeB |---|----------------| SGW |--|---|PDN-GW |
| |========|=======|====================|=======|======| | | |========|=======|====================|=======|======| |
+----+ +-------+DualStack EPS Bearer+-------+ +-------+ +----+ +-------+DualStack EPS Bearer+-------+ +-------+
Figure 4: EPS Architecture for 3GPP Access Figure 4: EPS Architecture for 3GPP Access
S5: It provides user plane tunnelling and tunnel management S5: It provides user plane tunnelling and tunnel management
between SGW and PDN-GW, using GTP or PMIPv6 as the network between SGW and PDN-GW, using GTP or PMIPv6 as the network
based mobility management protocol. based mobility management protocol.
S1-U: Provides user plane tunnelling and inter eNodeB path S1-U: Provides user plane tunnelling and inter eNodeB path
skipping to change at page 13, line 49 skipping to change at page 14, line 5
GTP-U protocol (GTP user plane). GTP-U protocol (GTP user plane).
S1-MME: Reference point for the control plane protocol between S1-MME: Reference point for the control plane protocol between
eNodeB and MME. eNodeB and MME.
SGi: It is the interface between the PDN-GW and the packet data SGi: It is the interface between the PDN-GW and the packet data
network. Packet data network may be an operator external network. Packet data network may be an operator external
public or private packet data network or an intra operator public or private packet data network or an intra operator
packet data network. packet data network.
The eNodeB is a base station entity that supports the Long Term
Evolution (LTE) air interface and includes functions for radio
resource control, user plane ciphering, and other lower layer
functions. MME is responsible for control plane functionalities,
including authentication, authorization, bearer management, layer-2
mobility, etc.
The SGW is the Mobility Anchor point for layer-2 mobility. For each
MN connected with the EPS, at any given point of time, there is only
one SGW.
4.2. PDN Connection 4.2. PDN Connection
A PDN connection is an association between a mobile host represented A PDN connection is an association between a UE represented by one
by one IPv4 address and/or one /64 IPv6 prefix, and a PDN represented IPv4 address and/or one /64 IPv6 prefix, and a PDN represented by an
by an APN. The PDN connection is the EPC equivalent of the GPRS PDP APN. The PDN connection is the EPC equivalent of the GPRS PDP
context. Each PDN can be accessed via a gateway (a PDN-GW). PDN is context. Each PDN can be accessed via a gateway (a PDN-GW). PDN is
responsible for the IP address/prefix allocation to the mobile host. responsible for the IP address/prefix allocation to the UE. On the
On the device/mobile host a PDN connection is equivalent to a network UE a PDN connection is equivalent to a network interface. A UE may
interface. A host may hence be attached to one or more gateways via hence be attached to one or more gateways via separate connections,
separate connections, i.e. PDN connections. Each PDN connection has i.e. PDN connections. Each PDN connection has its own IP address/
its own IP address/prefix assigned to it by the PDN and anchored in prefix assigned to it by the PDN and anchored in the corresponding
the corresponding gateway. Applications on the host use the gateway. Applications on the UE use the appropriate network
appropriate network interface (PDN connection) for connectivity. interface (PDN connection) for connectivity.
4.3. EPS bearer model 4.3. EPS bearer model
The logical concept of a bearer has been defined to be an aggregate The logical concept of a bearer has been defined to be an aggregate
of one or more IP flows related to one or more services. An EPS of one or more IP flows related to one or more services. An EPS
bearer exists between the Mobile Node (MN i.e. a mobile host) and the bearer exists between the UE and the PDN-GW and is used to provide
PDN-GW and is used to provide the same level of packet forwarding the same level of packet forwarding treatment to the aggregated IP
treatment to the aggregated IP flows constituting the bearer. flows constituting the bearer. Services with IP flows requiring a
Services with IP flows requiring a different packet forwarding different packet forwarding treatment would therefore require more
treatment would therefore require more than one EPS bearer. The than one EPS bearer. The UE performs the binding of the uplink IP
mobile host performs the binding of the uplink IP flows to the bearer flows to the bearer while the PDN-GW performs this function for the
while the PDN-GW performs this function for the downlink packets. downlink packets.
In order to provide low latency for always on connectivity, a default In order to provide low latency for always on connectivity, a default
bearer will be provided at the time of startup and an IPv4 address bearer will be provided at the time of startup and an IPv4 address
and/or IPv6 prefix gets assigned to the mobile host (this is and/or IPv6 prefix gets assigned to the UE (this is different from
different from GPRS, where mobile hosts are not automatically GPRS, where UEs are not automatically assigned with an IP address or
assigned with an IP address or prefix). This default bearer will be prefix). This default bearer will be allowed to carry all traffic
allowed to carry all traffic which is not associated with a dedicated which is not associated with a dedicated bearer. Dedicated bearers
bearer. Dedicated bearers are used to carry traffic for IP flows are used to carry traffic for IP flows that have been identified to
that have been identified to require a specific packet forwarding require a specific packet forwarding treatment. They may be
treatment. They may be established at the time of startup; for established at the time of startup; for example, in the case of
example, in the case of services that require always-on connectivity services that require always-on connectivity and better QoS than that
and better QoS than that provided by the default bearer. The default provided by the default bearer. The default bearer and the dedicated
bearer and the dedicated bearer(s) associated to it share the same IP bearer(s) associated to it share the same IP address(es)/prefix.
address(es)/prefix.
An EPS bearer is referred to as a GBR bearer if dedicated network An EPS bearer is referred to as a GBR bearer if dedicated network
resources related to a Guaranteed Bit Rate (GBR) value that is resources related to a Guaranteed Bit Rate (GBR) value that is
associated with the EPS bearer are permanently allocated (e.g. by an associated with the EPS bearer are permanently allocated (e.g. by an
admission control function in the eNodeB) at bearer establishment/ admission control function in the eNodeB) at bearer establishment/
modification. Otherwise, an EPS bearer is referred to as a non-GBR modification. Otherwise, an EPS bearer is referred to as a non-GBR
bearer. The default bearer is always non-GBR, with the resources for bearer. The default bearer is always non-GBR, with the resources for
the IP flows not guaranteed at eNodeB, and with no admission control. the IP flows not guaranteed at eNodeB, and with no admission control.
However, the dedicated bearer can be either GBR or non-GBR. A GBR However, the dedicated bearer can be either GBR or non-GBR. A GBR
bearer has a Guaranteed Bit Rate (GBR) and Maximum Bit Rate (MBR) bearer has a Guaranteed Bit Rate (GBR) and Maximum Bit Rate (MBR)
while more than one non-GBR bearer belonging to the same UE shares an while more than one non-GBR bearer belonging to the same UE shares an
Aggregate Maximum Bit Rate (AMBR). Non-GBR bearers can suffer packet Aggregate Maximum Bit Rate (AMBR). Non-GBR bearers can suffer packet
loss under congestion while GBR bearers are immune to such losses. loss under congestion while GBR bearers are immune to such losses.
5. Address Management 5. Address Management
5.1. IPv4 Address Configuration 5.1. IPv4 Address Configuration
Mobile host's IPv4 address configuration is always performed during UE's IPv4 address configuration is always performed during PDP
PDP context/EPS bearer setup procedures (on layer-2). DHCPv4-based context/EPS bearer setup procedures (on layer-2). DHCPv4-based
[RFC2131] address configuration is supported by the 3GPP [RFC2131] address configuration is supported by the 3GPP
specifications, but is not used in wide scale. The mobile host must specifications, but is not used in wide scale. The UE must always
always support layer-2 based address configuration, since DHCPv4 is support address configuration as part of the bearer setup signaling,
optional for both mobile hosts and networks. since DHCPv4 is optional for both UEs and networks.
5.2. IPv6 Address Configuration 5.2. IPv6 Address Configuration
IPv6 Stateless Address Autoconfiguration (SLAAC) as specified in IPv6 Stateless Address Autoconfiguration (SLAAC) as specified in
[RFC4862] is the only supported address configuration mechanism. [RFC4861][RFC4862] is the only supported address configuration
Stateful DHCPv6-based address configuration is not supported by 3GPP mechanism. Stateful DHCPv6-based address configuration [RFC3315] is
specifications [RFC3315]. On the other hand, Stateless DHCPv6- not supported by 3GPP specifications. On the other hand, Stateless
service to obtain other configuration information is supported DHCPv6-service to obtain other configuration information is supported
[RFC3736]. This implies that the M-bit must always be set to zero [RFC3736]. This implies that the M-bit is always zero and the O-bit
and the O-bit may be set to one in the Router Advertisement (RA) sent may be set to one in the Router Advertisement (RA) sent to the UE.
to the UE.
3GPP network allocates each default bearer a unique /64 prefix, and 3GPP network allocates each default bearer a unique /64 prefix, and
uses layer-2 signaling to suggest user equipment an Interface uses layer-2 signaling to suggest user equipment an Interface
Identifier that is guaranteed not to conflict with gateway's Identifier that is guaranteed not to conflict with gateway's
Interface Identifier. The UE must configure its link-local address Interface Identifier. The UE must configure its link-local address
using this Interface Identifier. The UE is allowed to use any using this Interface Identifier. The UE is allowed to use any
Interface Identifier it wishes for the other addresses it configures. Interface Identifier it wishes for the other addresses it configures.
There is no restriction, for example, of using Privacy Extension for There is no restriction, for example, of using Privacy Extension for
SLAAC [RFC4941] or other similar types of mechanisms. SLAAC [RFC4941] or other similar types of mechanisms. However, there
are network drivers that fail to pass the Interface Identifier to the
stack and instead synthesize their own Interface Identifier (usually
a MAC address equivalent). If the UE skips the Duplicate Address
Detection (DAD) or has other issues with the Neighbor Discovery
Protocol (see Section 5.4), then there is a small theoretical chance
that the UE configures exactly the same link-local address as the
GGSN/PDN-GW. The address collision may then cause issues in the IP
connectivity.
In the 3GPP link model the /64 prefix assigned to the UE cannot be In the 3GPP link model the /64 prefix assigned to the UE cannot be
used for on-link determination (because the L-bit in the Prefix used for on-link determination (because the L-bit in the Prefix
Information Option (PIO) in the RA must always be set to zero). If Information Option (PIO) in the RA must always be set to zero). If
the advertised prefix is used for SLAAC then the A-bit in the PIO the advertised prefix is used for SLAAC then the A-bit in the PIO
must be set to one. The details of the 3GPP link-model and address must be set to one. The details of the 3GPP link-model and address
configuration is described in Section 11.2.1.3.2a of [TS.29061]. configuration is described in Section 11.2.1.3.2a of [TS.29061].
More specifically, the GGSN/PDN-GW guarantees that the /64 prefix is More specifically, the GGSN/PDN-GW guarantees that the /64 prefix is
unique for the mobile host. Therefore, there is no need to perform unique for the UE. Therefore, there is no need to perform any
any Duplicate Address Detection (DAD) on addresses the mobile host Duplicate Address Detection (DAD) on addresses the UE creates (i.e.,
creates (i.e., the 'DupAddrDetectTransmits' variable in the mobile the 'DupAddrDetectTransmits' variable in the UE could be zero). The
host could be zero). The GGSN/PDN-GW is not allowed to generate any GGSN/PDN-GW is not allowed to generate any globally unique IPv6
globally unique IPv6 addresses for itself using the /64 prefix addresses for itself using the /64 prefix assigned to the UE in the
assigned to the mobile host in the RA. RA.
The current 3GPP architecture limits number of prefixes in each The current 3GPP architecture limits number of prefixes in each
bearer to a single /64 prefix. If the mobile host finds more than bearer to a single /64 prefix. If the UE finds more than one prefix
one prefix in the RA, it only considers the first one and silently in the RA, it only considers the first one and silently discards the
discards the others [TS.29061]. Therefore, multi-homing within a others [TS.29061]. Therefore, multi-homing within a single bearer is
single bearer is not possible. Renumbering without closing layer-2 not possible. Renumbering without closing layer-2 connection is also
connection is also not possible. The lifetime of /64 prefix is bound not possible. The lifetime of /64 prefix is bound to lifetime of
to lifetime of layer-2 connection even if the advertised prefix layer-2 connection even if the advertised prefix lifetime is longer
lifetime is longer than the layer-2 connection lifetime. than the layer-2 connection lifetime.
5.3. Prefix Delegation 5.3. Prefix Delegation
IPv6 prefix delegation is a part of Release-10 and is not covered by IPv6 prefix delegation is a part of Release-10 and is not covered by
any earlier release. However, the /64 prefix allocated for each any earlier release. However, the /64 prefix allocated for each
default bearer (and to the user equipment) may be shared to local default bearer (and to the user equipment) may be shared to local
area network by user equipment implementing Neighbor Discovery proxy area network by user equipment implementing Neighbor Discovery proxy
(ND proxy) [RFC4389] functionality. (ND proxy) [RFC4389] functionality.
Release-10 prefix delegation uses the DHCPv6-based prefix delegation Release-10 prefix delegation uses the DHCPv6-based prefix delegation
[RFC3633]. The model defined for Release-10 requires aggregatable [RFC3633]. The model defined for Release-10 requires aggregatable
prefixes, which means the /64 prefix allocated for the default bearer prefixes, which means the /64 prefix allocated for the default bearer
(and to the user equipment) must be part of the shorter delegated (and to the user equipment) must be part of the shorter delegated
prefix. DHCPv6 prefix delegation has an explicit limitation prefix. DHCPv6 prefix delegation has an explicit limitation
described in Section 12.1 of [RFC3633] that a prefix delegated to a described in Section 12.1 of [RFC3633] that a prefix delegated to a
requesting router cannot be used by the delegating router (i.e., the requesting router cannot be used by the delegating router (i.e., the
PDN-GW in this case). This implies the shorter 'delegated prefix' PDN-GW in this case). This implies the shorter 'delegated prefix'
cannot be given to the requesting router (i.e. the user equipment) as cannot be given to the requesting router (i.e. the user equipment) as
such but has to be delivered by the delegating router (i.e. the such but has to be delivered by the delegating router (i.e. the
PDN-GW) in such a way the /64 prefix allocated to the default bearer PDN-GW) in such a way the /64 prefix allocated to the default bearer
is not part of the 'delegated prefix'. IETF is working on a solution is not part of the 'delegated prefix'. An option to exclude a prefix
for DHCPv6-based prefix delegation to exclude a specific prefix from from delegation [I-D.ietf-dhc-pd-exclude] prevents this problem.
the 'delegated prefix' [I-D.ietf-dhc-pd-exclude].
5.4. IPv6 Neighbor Discovery Considerations 5.4. IPv6 Neighbor Discovery Considerations
3GPP link between the UE and the next hop router (e.g. GGSN) 3GPP link between the UE and the next hop router (e.g. GGSN)
resemble a point to point (p2p) link, which has no link-layer resemble a point to point (p2p) link, which has no link-layer
addresses [RFC3316] and this has not changed from 2G/3G GPRS to EPS. addresses [RFC3316] and this has not changed from 2G/3G GPRS to EPS.
The UE IP stack has to take this into consideration. When the 3GPP The UE IP stack has to take this into consideration. When the 3GPP
PDP Context appears as a PPP interface/link to the UE, the IP stack PDP Context appears as a PPP interface/link to the UE, the IP stack
is usually prepared to handle Neighbor Discovery protocol and the is usually prepared to handle Neighbor Discovery protocol and the
related Neighbor Cache state machine transitions in an appropriate related Neighbor Cache state machine transitions in an appropriate
way, even though Neighbor Discovery protocol messages contain no link way, even though Neighbor Discovery protocol messages contain no link
layer address information. However, some operating systems discard layer address information. However, some operating systems discard
Router Advertisements on their PPP interface/link as a default Router Advertisements on their PPP interface/link as a default
setting. This causes the SLAAC to fail when the 3GPP PDP Context setting. This causes the SLAAC to fail when the 3GPP PDP Context
gets established, thus stalling all IPv6 traffic. gets established, thus stalling all IPv6 traffic.
skipping to change at page 18, line 11 skipping to change at page 18, line 11
explicitly defined in standards. Therefore, cellular device and explicitly defined in standards. Therefore, cellular device and
gateway implementations from different vendors may have varying gateway implementations from different vendors may have varying
support for this functionality. support for this functionality.
Y .--. Y .--.
| _(IPv4`. | _(IPv4`.
|---+ +---+ +---+ ( PDN ) |---+ +---+ +---+ ( PDN )
| D |~~~~~~~//-----| |====| |====( ` . ) ) | D |~~~~~~~//-----| |====| |====( ` . ) )
| S | IPv4 context | S | | G | `--(___.-' | S | IPv4 context | S | | G | `--(___.-'
| | | G | | G | .--. | | | G | | G | .--.
| M | | S | | S | _(IPv6`. | U | | S | | S | _(IPv6`.
| N | IPv6 context | N | | N | ( PDN ) | E | IPv6 context | N | | N | ( PDN )
|///|~~~~~~~//-----| |====|(s)|====( ` . ) ) |///|~~~~~~~//-----| |====|(s)|====( ` . ) )
+---+ +---+ +---+ `--(___.-' +---+ +---+ +---+ `--(___.-'
Figure 5: A dual-stack mobile host connecting to both IPv4 and IPv6 Figure 5: A dual-stack User Equipment connecting to both IPv4 and
Internet using parallel IPv4-only and IPv6-only PDP contexts IPv6 Internet using parallel IPv4-only and IPv6-only PDP contexts
Y Y
| |
|---+ +---+ +---+ |---+ +---+ +---+
| D |~~~~~~~//-----| |====| | .--. | D |~~~~~~~//-----| |====| | .--.
| S | IPv4 context | S | | G | _( DS `. | S | IPv4 context | S | | G | _( DS `.
| | | G | | G | ( PDN ) | | | G | | G | ( PDN )
| M | | S | | S |====( ` . ) ) | U | | S | | S |====( ` . ) )
| N | IPv6 context | N | | N | `--(___.-' | E | IPv6 context | N | | N | `--(___.-'
|///|~~~~~~~//-----| |====| | |///|~~~~~~~//-----| |====| |
+---+ +---+ +---+ +---+ +---+ +---+
Figure 6: A dual-stack mobile host connecting to dual-stack Internet Figure 6: A dual-stack User Equipment connecting to dual-stack
using parallel IPv4-only and IPv6-only PDP contexts Internet using parallel IPv4-only and IPv6-only PDP contexts
The approach of having parallel IPv4 and IPv6 type of PDP contexts The approach of having parallel IPv4 and IPv6 type of PDP contexts
open is not optimal, because two PDP contexts require double the open is not optimal, because two PDP contexts require double the
signaling and consume more network resources than a single PDP signaling and consume more network resources than a single PDP
context. In the figure above the IPv4 and IPv6 PDP contexts are context. In the figure above the IPv4 and IPv6 PDP contexts are
attached to the same GGSN. While this is possible, the dual-stack attached to the same GGSN. While this is possible, the dual-stack
(DS) MS may be attached to different GGSNs in the scenario where one (DS) MS may be attached to different GGSNs in the scenario where one
GGSN supports IPv4 PDN connectivity while another GGSN provides IPv6 GGSN supports IPv4 PDN connectivity while another GGSN provides IPv6
PDN connectivity. PDN connectivity.
skipping to change at page 19, line 11 skipping to change at page 19, line 11
(IPv4v6), as illustrated in Figure 7, and makes dual stack simpler (IPv4v6), as illustrated in Figure 7, and makes dual stack simpler
than in earlier 3GPP releases. As of Release-9, GPRS network nodes than in earlier 3GPP releases. As of Release-9, GPRS network nodes
also support dual-stack type (IPv4v6) PDP contexts. also support dual-stack type (IPv4v6) PDP contexts.
Y Y
| |
|---+ +---+ +---+ |---+ +---+ +---+
| D | | | | P | .--. | D | | | | P | .--.
| S | | | | D | _( DS `. | S | | | | D | _( DS `.
| | IPv4v6 (DS) | S | | N | ( PDN ) | | IPv4v6 (DS) | S | | N | ( PDN )
| M |~~~~~~~//-----| G |====| - |====( ` . ) ) | U |~~~~~~~//-----| G |====| - |====( ` . ) )
| N | bearer | W | | G | `--(___.-' | E | bearer | W | | G | `--(___.-'
|///| | | | W | |///| | | | W |
+---+ +---+ +---+ +---+ +---+ +---+
Figure 7: A dual-stack mobile host connecting to dual-stack Internet Figure 7: A dual-stack User Equipment connecting to dual-stack
using a single IPv4v6 type PDN connection Internet using a single IPv4v6 type PDN connection
The following is a description of the various PDP contexts/PDN bearer The following is a description of the various PDP contexts/PDN bearer
types that are specified by 3GPP: types that are specified by 3GPP:
1. For 2G/3G access to GPRS core (SGSN/GGSN) pre-Release-9 there are 1. For 2G/3G access to GPRS core (SGSN/GGSN) pre-Release-9 there are
two IP PDP Types, IPv4 and IPv6. Two PDP contexts are needed to two IP PDP Types, IPv4 and IPv6. Two PDP contexts are needed to
get dual stack connectivity. get dual stack connectivity.
2. For 2G/3G access to GPRS core (SGSN/GGSN) from Release-9 there 2. For 2G/3G access to GPRS core (SGSN/GGSN) from Release-9 there
are three IP PDP Types, IPv4, IPv6 and IPv4v6. Minimum one PDP are three IP PDP Types, IPv4, IPv6 and IPv4v6. Minimum one PDP
skipping to change at page 22, line 18 skipping to change at page 22, line 18
IPv6 address. In a case of GPRS the PDP Address Information IPv6 address. In a case of GPRS the PDP Address Information
Element [TS.24008] would contain a complete IPv6 address. Element [TS.24008] would contain a complete IPv6 address.
However, the UE must ignore the IPv6 prefix if it receives one in However, the UE must ignore the IPv6 prefix if it receives one in
the message (see Section 11.2.1.3.2a of [TS.29061]). the message (see Section 11.2.1.3.2a of [TS.29061]).
6.4. Mobility of 3GPP IPv4v6 Type of Bearers 6.4. Mobility of 3GPP IPv4v6 Type of Bearers
3GPP discussed at length various approaches to support mobility 3GPP discussed at length various approaches to support mobility
between a Release-8 LTE network and a pre-Release-9 2G/3G network between a Release-8 LTE network and a pre-Release-9 2G/3G network
without a S4-SGSN for the new dual-stack type of bearers. The chosen without a S4-SGSN for the new dual-stack type of bearers. The chosen
approach for mobility is as follows, in short: if a mobile is allowed approach for mobility is as follows, in short: if a UE is allowed for
for doing handovers between a Release-8 LTE network and a pre- doing handovers between a Release-8 LTE network and a pre-Release-9
Release-9 2G/3G network without a S4-SGSN while having open PDN 2G/3G network without a S4-SGSN while having open PDN connections,
connections, only single stack bearers are used. Essentially this only single stack bearers are used. Essentially this means following
means following deployment options: deployment options:
1. If a network knows a mobile may do handovers between a Release-8 1. If a network knows a UE may do handovers between a Release-8 LTE
LTE network and a pre-Release-9 2G/3G network without a S4-SGSN, network and a pre-Release-9 2G/3G network without a S4-SGSN, then
then the network is configured to provide only single stack the network is configured to provide only single stack bearers,
bearers, even if the mobile host requests dual-stack bearers. even if the UE requests dual-stack bearers.
2. If the network knows the mobile does handovers only between a 2. If the network knows the UE does handovers only between a
Release-8 LTE network and a Release-9 2G/3G network or a pre- Release-8 LTE network and a Release-9 2G/3G network or a pre-
Release-9 network with a S4-SGSN, then the network is configured Release-9 network with a S4-SGSN, then the network is configured
to provide the mobile with dual-stack bearers on request. The to provide the UE with dual-stack bearers on request. The same
same also applies for LTE-only deployments. also applies for LTE-only deployments.
When a network operator and their roaming partners have upgraded When a network operator and their roaming partners have upgraded
their networks to Release-8, it is possible to use the new IPv4v6 their networks to Release-8, it is possible to use the new IPv4v6
dual-stack type of bearers. A Release-8 mobile device always dual-stack type of bearers. A Release-8 UE always requests for a
requests for a dual-stack bearer, but accepts what is assigned by the dual-stack bearer, but accepts what is assigned by the network.
network.
7. Dual-Stack Approach to IPv6 Transition in 3GPP Networks 7. Dual-Stack Approach to IPv6 Transition in 3GPP Networks
3GPP networks can natively transport IPv4 and IPv6 packets between 3GPP networks can natively transport IPv4 and IPv6 packets between
the mobile station/UE and the gateway (GGSN or PDN-GW) as a result of the UE and the gateway (GGSN or PDN-GW) as a result of establishing
establishing either a dual-stack PDP context or parallel IPv4 and either a dual-stack PDP context or parallel IPv4 and IPv6 PDP
IPv6 PDP contexts. contexts.
Current deployments of 3GPP networks primarily support IPv4-only. Current deployments of 3GPP networks primarily support IPv4-only.
These networks can be upgraded to also support IPv6 PDP contexts. By These networks can be upgraded to also support IPv6 PDP contexts. By
doing so devices and applications that are IPv6 capable can start doing so devices and applications that are IPv6 capable can start
utilizing the IPv6 connectivity. This will also ensure that legacy utilizing the IPv6 connectivity. This will also ensure that legacy
devices and applications continue to work with no impact. As newer devices and applications continue to work with no impact. As newer
devices start using IPv6 connectivity, the demand for actively used devices start using IPv6 connectivity, the demand for actively used
IPv4 connections is expected to slowly decrease, helping operators IPv4 connections is expected to slowly decrease, helping operators
with a transition to IPv6. With a dual-stack approach, there is with a transition to IPv6. With a dual-stack approach, there is
always the potential to fallback to IPv4. A device which may be always the potential to fallback to IPv4. A device which may be
roaming in a network wherein IPv6 is not supported by the visited roaming in a network wherein IPv6 is not supported by the visited
network could fall back to using IPv4 PDP contexts and hence the end network could fall back to using IPv4 PDP contexts and hence the end
user would at least get some connectivity. Unfortunately, dual-stack user would at least get some connectivity. Unfortunately, dual-stack
approach as such does not lower the number of used IPv4 addresses. approach as such does not lower the number of used IPv4 addresses.
Every dual-stack bearer still needs to be given an IPv4 address, Every dual-stack bearer still needs to be given an IPv4 address,
private or public. This is a major concern with dual-stack bearers private or public. This is a major concern with dual-stack bearers
concerning IPv6 transition. However, if the majority of active IP concerning IPv6 transition. However, if the majority of active IP
communication has moved over to IPv6, then in case of NAT44 [RFC1918] communication has moved over to IPv6, then in case of Network Address
IPv4 connections the number of active IPv4 connections can still be Translation from IPv4 to IPv4 (NAT44) [RFC1918] IPv4 connections the
expected to gradually decrease and thus giving some level of relief number of active IPv4 connections can still be expected to gradually
regarding NAT44 function scalability. decrease and thus giving some level of relief regarding NAT44
function scalability.
As the networks evolve to support Release-8 EPS architecture and the As the networks evolve to support Release-8 EPS architecture and the
dual-stack PDP contexts, newer devices will be able to leverage such dual-stack PDP contexts, newer devices will be able to leverage such
capability and have a single bearer which supports both IPv4 and capability and have a single bearer which supports both IPv4 and
IPv6. Since IPv4 and IPv6 packets are carried as payload within GTP IPv6. Since IPv4 and IPv6 packets are carried as payload within GTP
between the MS and the gateway (GGSN/PDN-GW) the transport network between the MS and the gateway (GGSN/PDN-GW) the transport network
capability in terms of whether it supports IPv4 or IPv6 on the capability in terms of whether it supports IPv4 or IPv6 on the
interfaces between the eNodeB and SGW or, SGW and PDN-GW is interfaces between the eNodeB and SGW or, SGW and PDN-GW is
immaterial. immaterial.
8. Deployment issues 8. Deployment issues
8.1. Overlapping IPv4 Addresses 8.1. Overlapping IPv4 Addresses
Given the shortage of globally routable public IPv4 addresses, Given the shortage of globally routable public IPv4 addresses,
operators tend to assign private IPv4 addresses [RFC1918] to hosts operators tend to assign private IPv4 addresses [RFC1918] to UEs when
when they establish an IPv4-only PDP context or an IPv4v6 type PDN they establish an IPv4-only PDP context or an IPv4v6 type PDN
context. About 16 million hosts can be assigned a private IPv4 context. About 16 million UEs can be assigned a private IPv4 address
address that is unique within a domain. However, in case of many that is unique within a domain. However, in case of many operators
operators the number of subscribers is greater than 16 million. The the number of subscribers is greater than 16 million. The issue can
issue can be dealt with by assigning overlapping RFC 1918 IPv4 be dealt with by assigning overlapping RFC 1918 IPv4 addresses to
addresses to hosts. As a result the IPv4 address assigned to a host UEs. As a result the IPv4 address assigned to a UE within the
within the context of a single operator realm would no longer be context of a single operator realm would no longer be unique. This
unique. This has the obvious and known issues of NATed IP connection has the obvious and known issues of NATed IP connection in the
in the Internet. Direct host to host connectivity becomes Internet. Direct UE to UE connectivity becomes complicated, unless
complicated, unless the hosts are within the same private address the UEs are within the same private address range pool and/or
range pool and/or anchored to the same gateway, referrals using IP anchored to the same gateway, referrals using IP addresses will have
addresses will have issues and so forth. These are generic issues issues and so forth. These are generic issues and not only a concern
and not only a concern of the EPS. However, 3GPP as such does not of the EPS. However, 3GPP as such does not have any mandatory
have any mandatory language concerning NAT44 functionality in EPC. language concerning NAT44 functionality in EPC. Obvious deployment
Obvious deployment choices apply also to EPC: choices apply also to EPC:
1. Very large network deployments are partitioned, for example, 1. Very large network deployments are partitioned, for example,
based on a geographical areas. This partitioning allows for based on a geographical areas. This partitioning allows for
overlapping IPv4 addresses ranges to be assigned to hosts that overlapping IPv4 addresses ranges to be assigned to UEs that are
are in different areas. Each area has its own pool of gateways in different areas. Each area has its own pool of gateways that
that are dedicated for a certain overlapping IPv4 address range are dedicated for a certain overlapping IPv4 address range
(referred here later as a zone). Standard NAT44 functionality (referred here later as a zone). Standard NAT44 functionality
allows for communication from the [RFC1918] private zone to the allows for communication from the [RFC1918] private zone to the
Internet. Communication between zones require special Internet. Communication between zones require special
arrangement, such as using intermediate gateways (e.g. Back to arrangement, such as using intermediate gateways (e.g. Back to
Back User Agent (B2BUA) in case of SIP). Back User Agent (B2BUA) in case of SIP).
2. A mobile host/device attaches to a gateway as part of the attach 2. A UE attaches to a gateway as part of the attach process. The
process. The number of hosts that a gateway supports is in the number of UEs that a gateway supports is in the order of 1 to 10
order of 1 to 10 million. Hence all the hosts assigned to a million. Hence all the UEs assigned to a single gateway can be
single gateway can be assigned private IPv4 addresses. Operators assigned private IPv4 addresses. Operators with large subscriber
with large subscriber bases have multiple gateways and hence the bases have multiple gateways and hence the same [RFC1918] IPv4
same [RFC1918] IPv4 address space can be reused across gateways. address space can be reused across gateways. The IPv4 address
The IPv4 address assigned to a host is unique within the scope of assigned to a UE is unique within the scope of a single gateway.
a single gateway.
3. New services requiring direct connectivity between hosts should 3. New services requiring direct connectivity between UEs should be
be build on IPv6. Possible existing IPv4-only services and built on IPv6. Possible existing IPv4-only services and
applications requiring direct connectivity can be ported to IPv6. applications requiring direct connectivity can be ported to IPv6.
8.2. IPv6 for transport 8.2. IPv6 for transport
The various reference points of the 3GPP architecture such as S1-U, The various reference points of the 3GPP architecture such as S1-U,
S5 and S8 are based on either GTP or PMIPv6. The underlying S5 and S8 are based on either GTP or PMIPv6. The underlying
transport for these reference points can be IPv4 or IPv6. GTP has transport for these reference points can be IPv4 or IPv6. GTP has
been able to operate over IPv6 transport (optionally) since R99 and been able to operate over IPv6 transport (optionally) since R99 and
PMIPv6 has supported IPv6 transport starting from its introduction in PMIPv6 has supported IPv6 transport starting from its introduction in
Release-8. The user plane traffic between the mobile host and the Release-8. The user plane traffic between the UE and the gateway can
gateway can use either IPv4 or IPv6. These packets are essentially use either IPv4 or IPv6. These packets are essentially treated as
treated as payload by GTP/PMIPv6 and transported accordingly with no payload by GTP/PMIPv6 and transported accordingly with no real
real attention paid to the information (at least from a routing attention paid to the information (at least from a routing
perspective) contained in the IPv4 or IPv6 headers. The transport perspective) contained in the IPv4 or IPv6 headers. The transport
links between the eNodeB and the SGW, and the link between the SGW links between the eNodeB and the SGW, and the link between the SGW
and PDN-GW can be migrated to IPv6 without any direct implications to and PDN-GW can be migrated to IPv6 without any direct implications to
the architecture. the architecture.
Currently, the inter-operator (for 3GPP technology) roaming networks Currently, the inter-operator (for 3GPP technology) roaming networks
are all IPv4-only (see Inter-PLMN Backbone Guidelines [GSMA.IR.34]). are all IPv4-only (see Inter-PLMN Backbone Guidelines [GSMA.IR.34]).
Eventually these roaming networks will also get migrated to IPv6, if Eventually these roaming networks will also get migrated to IPv6, if
there is a business reason for that. The migration period can be there is a business reason for that. The migration period can be
prolonged considerably because the 3GPP protocols always tunnel user prolonged considerably because the 3GPP protocols always tunnel user
skipping to change at page 25, line 25 skipping to change at page 25, line 24
8.3. Operational Aspects of Running Dual-Stack Networks 8.3. Operational Aspects of Running Dual-Stack Networks
Operating dual-stack networks does imply cost and complexity to a Operating dual-stack networks does imply cost and complexity to a
certain extent. However these factors are mitigated by the assurance certain extent. However these factors are mitigated by the assurance
that legacy devices and services are unaffected and there is always a that legacy devices and services are unaffected and there is always a
fallback to IPv4 in case of issues with the IPv6 deployment or fallback to IPv4 in case of issues with the IPv6 deployment or
network elements. The model also enables operators to develop network elements. The model also enables operators to develop
operational experience and expertise in an incremental manner. operational experience and expertise in an incremental manner.
Running dual-stack networks requires the management of multiple IP Running dual-stack networks requires the management of multiple IP
address spaces. Tracking of hosts needs to be expanded since it can address spaces. Tracking of UEs needs to be expanded since it can be
be identified by either an IPv4 address or IPv6 prefix. Network identified by either an IPv4 address or IPv6 prefix. Network
elements will also need to be dual-stack capable in order to support elements will also need to be dual-stack capable in order to support
the dual-stack deployment model. the dual-stack deployment model.
Deployment and migration cases described in Section 6.1 for providing Deployment and migration cases described in Section 6.1 for providing
dual-stack like capability may mean doubled resource usage in dual-stack like capability may mean doubled resource usage in
operator's network. This is a major concern against providing dual- operator's network. This is a major concern against providing dual-
stack like connectivity using techniques discussed in Section 6.1. stack like connectivity using techniques discussed in Section 6.1.
Also handovers between networks with different capabilities in terms Also handovers between networks with different capabilities in terms
of networks being dual-stack like service capable or not, may turn of networks being dual-stack like service capable or not, may turn
out hard to comprehend for users and for application/services to cope out hard to comprehend for users and for application/services to cope
with. These facts may add other than just technical concerns for with. These facts may add other than just technical concerns for
operators when planning to roll out dual-stack service offerings. operators when planning to roll out dual-stack service offerings.
8.4. Operational Aspects of Running a Network with IPv6-only Bearers 8.4. Operational Aspects of Running a Network with IPv6-only Bearers
It is possible to allocate IPv6-only type bearers to mobile hosts in It is possible to allocate IPv6-only type bearers to UEs in 3GPP
3GPP networks. IPv6-only bearer type has been part of the 3GPP networks. IPv6-only bearer type has been part of the 3GPP
specification since the beginning. In 3GPP Release-8 (and later) it specification since the beginning. In 3GPP Release-8 (and later) it
was defined that a dual-stack mobile host (or when the radio was defined that a dual-stack UE (or when the radio equipment has no
equipment has no knowledge of the host IP stack capabilities) must knowledge of the UE IP stack capabilities) must first attempt to
first attempt to establish a dual-stack bearer and then possibly fall establish a dual-stack bearer and then possibly fall back to single
back to single IP version bearer. A Release-8 (or later) mobile host IP version bearer. A Release-8 (or later) UE with IPv6-only stack
with IPv6-only stack can directly attempt to establish an IPv6-only can directly attempt to establish an IPv6-only bearer. The IPv6-only
bearer. The IPv6-only behaviour is up to a subscription provisioning behaviour is up to a subscription provisioning or a PDN-GW
or a PDN-GW configuration, and the fallback scenarios do not configuration, and the fallback scenarios do not necessarily cause
necessarily cause additional signaling. additional signaling.
Although the bullets below introduce IPv6 to IPv4 address translation Although the bullets below introduce IPv6 to IPv4 address translation
and specifically discuss NAT64 technology [RFC6144], the current 3GPP and specifically discuss NAT64 technology [RFC6144], the current 3GPP
Release-8 architecture does not describe the use of address Release-8 architecture does not describe the use of address
translation or NAT64. It is up to a specific deployment whether translation or NAT64. It is up to a specific deployment whether
address translation is part of the network or not. Some operational address translation is part of the network or not. Some operational
aspects to consider for running a network with IPv6-only bearers: aspects to consider for running a network with IPv6-only bearers:
o The mobile hosts must have an IPv6 capable stack and a radio o The UE must have an IPv6 capable stack and a radio interface
interface capable of establishing an IPv6 PDP context or PDN capable of establishing an IPv6 PDP context or PDN connection.
connection.
o The GGSN/PDN-GW must be IPv6 capable in order to support IPv6 o The GGSN/PDN-GW must be IPv6 capable in order to support IPv6
bearers. Furthermore, the SGSN/MME must allow the creation of PDP bearers. Furthermore, the SGSN/MME must allow the creation of PDP
Type or PDN Type of IPv6. Type or PDN Type of IPv6.
o Many of the common applications are IP version agnostic and hence o Many of the common applications are IP version agnostic and hence
would work using an IPv6 bearer. However, applications that are would work using an IPv6 bearer. However, applications that are
IPv4 specific would not work. IPv4 specific would not work.
o Inter-operator roaming is another aspect which causes issues, at o Inter-operator roaming is another aspect which causes issues, at
least during the ramp up phase of the IPv6 deployment. If the least during the ramp up phase of the IPv6 deployment. If the
visited network to which outbound roamers attach to does not visited network to which outbound roamers attach to does not
support PDP/PDN Type IPv6, then there needs to be a fallback support PDP/PDN Type IPv6, then there needs to be a fallback
option. The fallback option in this specific case is mostly up to option. The fallback option in this specific case is mostly up to
the mobile host to implement. Several cases are discussed in the the UE to implement. Several cases are discussed in the following
following sections. sections.
o If and when a mobile host using IPv6-only bearer needs to access o If and when a UE using IPv6-only bearer needs to access to IPv4
to IPv4 Internet/network, a translation of some type from IPv6 to Internet/network, a translation of some type from IPv6 to IPv4 has
IPv4 has to be deployed in the network. NAT64 (and DNS64) is one to be deployed in the network. NAT64 (and DNS64) is one solution
solution that can be used for this purpose and works for a certain that can be used for this purpose and works for a certain set of
set of protocols (read TCP, UDP and ICMP, and when applications protocols (read TCP, UDP and ICMP, and when applications actually
actually use DNS for resolving name to IP addresses). use DNS for resolving name to IP addresses).
8.5. Restricting Outbound IPv6 Roaming 8.5. Restricting Outbound IPv6 Roaming
Roaming was briefly touched upon in Sections 8.2 and 8.4. While Roaming was briefly touched upon in Sections 8.2 and 8.4. While
there is interest in offering roaming service for IPv6 enabled mobile there is interest in offering roaming service for IPv6 enabled UEs
hosts and subscriptions, not all visited networks are prepared for and subscriptions, not all visited networks are prepared for IPv6
IPv6 outbound roamers. There are basically two issues. First, the outbound roamers:
visited network SGSN does not support the IPv6 PDP Context or IPv4v6
PDP Context types. These should mostly concern pre-Release-9 2G/3G
networks without S4-SGSN but there is no definitive rule as the
deployed feature sets vary depending on implementations and licenses.
Second, the visited network might not be commercially ready for IPv6
outbound roamers, while everything might work technically at the user
plane level. This would lead to "revenue leakage" especially from
the visited operator point of view (note that the use of visited
network GGSN/PDN-GW does not really exist in real deployments today).
Therefore, it might be in the interest of operators to prohibit
roaming selectively within specific visited networks.
Unfortunately, it is not mandatory to implement/deploy 3GPP standards o The visited network SGSN does not support the IPv6 PDP Context or
based solution to selectively prohibit IPv6 roaming without also IPv4v6 PDP Context types. These should mostly concern pre-
prohibiting other packet services (such as IPv4 roaming). However, Release-9 2G/3G networks without S4-SGSN but there is no
there are few possibilities how this can be done in real deployments. definitive rule as the deployed feature sets vary depending on
The examples given below are either optional and/or vendor specific implementations and licenses.
features to the 3GPP EPC:
o The visited network might not be commercially ready for IPv6
outbound roamers, while everything might work technically at the
user plane level. This would lead to "revenue leakage" especially
from the visited operator point of view (note that the use of
visited network GGSN/PDN-GW does not really exist in commercial
deployments today for data roaming).
It might be in the interest of operators to prohibit roaming
selectively within specific visited networks until IPv6 roaming is in
place. 3GPP does not specify a mechanism whereby IPv6 roaming is
prohibited without also disabling IPv4 access and other packet
services. The following options for disabling IPv6 access for
roaming subscribers could be available in some network deployments:
o Using Policy and Charging Control (PCC) [TS.23203] functionality o Using Policy and Charging Control (PCC) [TS.23203] functionality
and its rules to fail, for example, the bearer authorization when and its rules to fail, for example, the bearer authorization when
a desired criteria is met. In this case that would be PDN/PDP a desired criteria is met. In this case that would be PDN/PDP
Type IPv6/IPv4v6 and a specific visited network. The rules can be Type IPv6/IPv4v6 and a specific visited network. The rules can be
provisioned either in the home network or locally in the visited provisioned either in the home network or locally in the visited
network. network.
o Some Home Location Register (HLR) and Home Subscriber Server (HSS) o Some Home Location Register (HLR) and Home Subscriber Server (HSS)
subscriber databases allow prohibiting roaming in a specific subscriber databases allow prohibiting roaming in a specific
(visited) network for a specified PDN/PDP Type. (visited) network for a specified PDN/PDP Type.
The obvious problems are that these solutions are not mandatory, are The obvious problems are that these solutions are not mandatory, are
not unified across networks, and therefore also lack well-specified not unified across networks, and therefore also lack well-specified
fall back mechanism from the mobile host point of view. fall back mechanism from the UE point of view.
8.6. Inter-RAT Handovers and IP Versions 8.6. Inter-RAT Handovers and IP Versions
It is obvious that operators start incrementally deploy EPS along It is obvious that operators start incrementally deploy EPS along
with the existing UTRAN/GERAN, handovers between different radio with the existing UTRAN/GERAN, handovers between different radio
technologies (inter-RAT handovers) become inevitable. In case of technologies (inter-RAT handovers) become inevitable. In case of
inter-RAT handovers 3GPP supports the following IP addressing inter-RAT handovers 3GPP supports the following IP addressing
scenarios: scenarios:
o E-UTRAN IPv4v6 bearer has to map one to one to UTRAN/GERAN IPv4v6 o E-UTRAN IPv4v6 bearer has to map one to one to UTRAN/GERAN IPv4v6
bearer. bearer.
o E-UTRAN IPv6 bearer has to map one to one to UTRAN/GERAN IPv6 o E-UTRAN IPv6 bearer has to map one to one to UTRAN/GERAN IPv6
bearer. bearer.
o E-UTRAN IPv4 bearer has to map one to one to UTRAN/GERAN IPv4 o E-UTRAN IPv4 bearer has to map one to one to UTRAN/GERAN IPv4
bearer. bearer.
Other types of configurations are considered network planning Other types of configurations are not standardized. What the above
mistakes. What the above rules essentially imply is that the network rules essentially imply is that the network migration has to be
migration has to be planned and subscriptions provisioned based on planned and subscriptions provisioned based on the lowest common
the lowest common nominator, if inter-RAT handovers are desired. For nominator, if inter-RAT handovers are desired. For example, if some
example, if some part of the UTRAN network cannot serve anything but part of the UTRAN network cannot serve anything but IPv4 bearers,
IPv4 bearers, then the E-UTRAN is also forced to provide only IPv4 then the E-UTRAN is also forced to provide only IPv4 bearers.
bearers. Various combinations of subscriber provisioning regarding Various combinations of subscriber provisioning regarding IP versions
IP versions are discussed further in Section 8.7. are discussed further in Section 8.7.
8.7. Provisioning of IPv6 Subscribers and Various Combinations During 8.7. Provisioning of IPv6 Subscribers and Various Combinations During
Initial Network Attachment Initial Network Attachment
Subscribers' provisioned PDP/PDN Types have multiple configurations. Subscribers' provisioned PDP/PDN Types have multiple configurations.
The supported PDP/PDN Type is provisioned per each APN for every The supported PDP/PDN Type is provisioned per each APN for every
subscriber. The following PDN Types are possible in the HSS for a subscriber. The following PDN Types are possible in the HSS for a
Release-8 subscription [TS.23401]: Release-8 subscription [TS.23401]:
o IPv4v6 PDN Type (note that IPv4v6 PDP Type does not exist in a HLR o IPv4v6 PDN Type (note that IPv4v6 PDP Type does not exist in a HLR
and Mobile Applicatio Part (MAP) [TS.29002] signaling prior and Mobile Application Part (MAP) [TS.29002] signaling prior
Release-9). Release-9).
o IPv6-only PDN Type o IPv6-only PDN Type
o IPv4-only PDN Type. o IPv4-only PDN Type.
o IPv4_or_IPv6 PDN Type (note that IPv4_or_IPv6 PDP Type does not o IPv4_or_IPv6 PDN Type (note that IPv4_or_IPv6 PDP Type does not
exist in a HLR or MAP signaling. However, a HLR may have multiple exist in a HLR or MAP signaling. However, a HLR may have multiple
APN configurations of different PDN Types, which effectively APN configurations of different PDN Types, which effectively
achieves the same functionality). achieves the same functionality).
A Release-8 dual-stack mobile host must always attempt to establish a A Release-8 dual-stack UE must always attempt to establish a PDP/PDN
PDP/PDN Type IPv4v6 bearer. The same also applies when the modem Type IPv4v6 bearer. The same also applies when the modem part of the
part of the mobile host does not have exact knowledge whether the UE does not have exact knowledge whether the UE operating system IP
host operating system IP stack is a dual-stack capable or not. A stack is a dual-stack capable or not. A UE that is IPv6-only capable
mobile host that is IPv6-only capable must attempt to establish a must attempt to establish a PDP/PDN Type IPv6 bearer. Last, a UE
PDP/PDN Type IPv6 bearer. Last, a mobile host that is IPv4-only that is IPv4-only capable must attempt to establish a PDN/PDP Type
capable must attempt to establish a PDN/PDP Type IPv4 bearer. IPv4 bearer.
In a case the PDP/PDN Type requested by a mobile host does not match In a case the PDP/PDN Type requested by a UE does not match what has
what has been provisioned for the subscriber in the HSS (or HLR), the been provisioned for the subscriber in the HSS (or HLR), the UE
mobile host possibly falls back to a different PDP/PDN Type. The possibly falls back to a different PDP/PDN Type. The network (i.e.
network (i.e. the MME or the S4-SGSN) is able to inform the mobile the MME or the S4-SGSN) is able to inform the UE during the network
host during the network attachment signaling why it did not get the attachment signaling why it did not get the requested PDP/PDN Type.
requested PDP/PDN Type. These response/cause codes are documented in These response/cause codes are documented in [TS.24008] for requested
[TS.24008] for requested PDP Types and [TS.24301] for requested PDN PDP Types and [TS.24301] for requested PDN Types:
Types:
o (E)SM cause #50 "PDN/PDP type IPv4-only allowed". o (E)SM cause #50 "PDN/PDP type IPv4-only allowed".
o (E)SM cause #51 "PDN/PDP type IPv6-only allowed". o (E)SM cause #51 "PDN/PDP type IPv6-only allowed".
o (E)SM cause #52 "single address bearers only allowed". o (E)SM cause #52 "single address bearers only allowed".
The above response/cause codes apply to Release-8 and onwards. In The above response/cause codes apply to Release-8 and onwards. In
pre-Release-8 networks used response/cause codes vary depending on pre-Release-8 networks used response/cause codes vary depending on
the vendor, unfortunately. the vendor, unfortunately.
Possible fall back cases when the network deploys MMEs and/or S4- Possible fall back cases when the network deploys MMEs and/or S4-
SGSNs include (as documented in [TS.23401]): SGSNs include (as documented in [TS.23401]):
o Requested and provisioned PDP/PDN Types match => requested. o Requested and provisioned PDP/PDN Types match => requested.
o Requested IPv4v6 and provisioned IPv6 => IPv6 and a mobile host o Requested IPv4v6 and provisioned IPv6 => IPv6 and a UE receives
receives indication that IPv6-only bearer is allowed. indication that IPv6-only bearer is allowed.
o Requested IPv4v6 and provisioned IPv4 => IPv4 and the mobile host o Requested IPv4v6 and provisioned IPv4 => IPv4 and the UE receives
receives indication that IPv4-only bearer is allowed. indication that IPv4-only bearer is allowed.
o Requested IPv4v6 and provisioned IPv4_or_IPv6 => IPv4 or IPv6 is o Requested IPv4v6 and provisioned IPv4_or_IPv6 => IPv4 or IPv6 is
selected by the MME/S4-SGSN based on an unspecified criteria. The selected by the MME/S4-SGSN based on an unspecified criteria. The
mobile host may then attempt to establish, based on the mobile UE may then attempt to establish, based on the UE implementation,
host implementation, a parallel bearer of a different PDP/PDN a parallel bearer of a different PDP/PDN Type.
Type.
o Other combinations cause the bearer establishment to fail. o Other combinations cause the bearer establishment to fail.
In addition to PDP/PDN Types provisioned in the HSS, it is also In addition to PDP/PDN Types provisioned in the HSS, it is also
possible for a PDN-GW (and a MME/S4-SGSN) to affect the final possible for a PDN-GW (and a MME/S4-SGSN) to affect the final
selected PDP/PDN Type: selected PDP/PDN Type:
o Requested IPv4v6 and configured IPv4 or IPv6 in the PDN-GW => IPv4 o Requested IPv4v6 and configured IPv4 or IPv6 in the PDN-GW => IPv4
or IPv6. If the MME operator had included the "Dual Address or IPv6. If the MME operator had included the "Dual Address
Bearer Flag" into the bearer establishment signaling, then the Bearer Flag" into the bearer establishment signaling, then the UE
mobile host receives an indication that IPv6-only or IPv4-only receives an indication that IPv6-only or IPv4-only bearer is
bearer is allowed. allowed.
o Requested IPv4v6 and configured IPv4 or IPv6 in the PDN-GW => IPv4 o Requested IPv4v6 and configured IPv4 or IPv6 in the PDN-GW => IPv4
or IPv6. If the MME operator had not included the "Dual Address or IPv6. If the MME operator had not included the "Dual Address
Bearer Flag" into the bearer establishment signaling, then the Bearer Flag" into the bearer establishment signaling, then the UE
mobile host may attempt to establish, based on the mobile host may attempt to establish, based on the UE implementation, a
implementation, a parallel bearer of different PDP/PDN Type. parallel bearer of different PDP/PDN Type.
A SGSN that does not understand the requested PDP Type is supposed to A SGSN that does not understand the requested PDP Type is supposed to
handle the requested PDP Type as IPv4. If for some reason a MME does handle the requested PDP Type as IPv4. If for some reason a MME does
not understand the requested PDN Type, then the PDN Type is handled not understand the requested PDN Type, then the PDN Type is handled
as IPv6. as IPv6.
9. IANA Considerations 9. IANA Considerations
This document has no requests to IANA. This document has no requests to IANA.
skipping to change at page 30, line 22 skipping to change at page 30, line 18
11. Summary and Conclusion 11. Summary and Conclusion
The 3GPP network architecture and specifications enable the The 3GPP network architecture and specifications enable the
establishment of IPv4 and IPv6 connections through the use of establishment of IPv4 and IPv6 connections through the use of
appropriate PDP context types. The current generation of deployed appropriate PDP context types. The current generation of deployed
networks can support dual-stack connectivity if the packet core networks can support dual-stack connectivity if the packet core
network elements such as the SGSN and GGSN have the capability. With network elements such as the SGSN and GGSN have the capability. With
Release-8, 3GPP has specified a more optimal PDP context type which Release-8, 3GPP has specified a more optimal PDP context type which
enables the transport of IPv4 and IPv6 packets within a single PDP enables the transport of IPv4 and IPv6 packets within a single PDP
context between the mobile station and the gateway. context between the UE and the gateway.
As devices and applications are upgraded to support IPv6 they can As devices and applications are upgraded to support IPv6 they can
start leveraging the IPv6 connectivity provided by the networks while start leveraging the IPv6 connectivity provided by the networks while
maintaining the fall back to IPv4 capability. Enabling IPv6 maintaining the fall back to IPv4 capability. Enabling IPv6
connectivity in the 3GPP networks by itself will provide some degree connectivity in the 3GPP networks by itself will provide some degree
of relief to the IPv4 address space as many of the applications and of relief to the IPv4 address space as many of the applications and
services can start to work over IPv6. However without comprehensive services can start to work over IPv6. However without comprehensive
testing of different applications and solutions that exist today and testing of different applications and solutions that exist today and
are widely used, for their ability to operate over IPv6 PDN are widely used, for their ability to operate over IPv6 PDN
connections, an IPv6-only access would cause disruptions. connections, an IPv6-only access would cause disruptions.
12. Acknowledgements 12. Acknowledgements
The authors thank Shabnam Sultana, Sri Gundavelli, Hui Deng, and The authors thank Shabnam Sultana, Sri Gundavelli, Hui Deng, and
Zhenqiang Li, Mikael Abrahamsson, James Woodyatt, Cameron Byrne, Ales Zhenqiang Li, Mikael Abrahamsson, James Woodyatt, Martin Thomson,
Vizdal and Frank Brockners for their reviews and comments on this Cameron Byrne, Ales Vizdal and Frank Brockners for their reviews and
document. comments on this document.
13. Informative References 13. Informative References
[GSMA.IR.34] [GSMA.IR.34]
GSMA, "Inter-PLMN Backbone Guidelines", GSMA GSMA, "Inter-PLMN Backbone Guidelines", GSMA
PRD IR.34.4.9, March 2010. PRD IR.34.4.9, March 2010.
[I-D.ietf-dhc-pd-exclude] [I-D.ietf-dhc-pd-exclude]
Korhonen, J., Savolainen, T., Krishnan, S., and O. Troan, Korhonen, J., Savolainen, T., Krishnan, S., and O. Troan,
"Prefix Exclude Option for DHCPv6-based Prefix "Prefix Exclude Option for DHCPv6-based Prefix
Delegation", draft-ietf-dhc-pd-exclude-02 (work in Delegation", draft-ietf-dhc-pd-exclude-03 (work in
progress), June 2011. progress), August 2011.
[RFC1918] Rekhter, Y., Moskowitz, R., Karrenberg, D., Groot, G., and [RFC1918] Rekhter, Y., Moskowitz, R., Karrenberg, D., Groot, G., and
E. Lear, "Address Allocation for Private Internets", E. Lear, "Address Allocation for Private Internets",
BCP 5, RFC 1918, February 1996. BCP 5, RFC 1918, February 1996.
[RFC2131] Droms, R., "Dynamic Host Configuration Protocol", [RFC2131] Droms, R., "Dynamic Host Configuration Protocol",
RFC 2131, March 1997. RFC 2131, March 1997.
[RFC3315] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C., [RFC3315] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C.,
and M. Carney, "Dynamic Host Configuration Protocol for and M. Carney, "Dynamic Host Configuration Protocol for
 End of changes. 82 change blocks. 
286 lines changed or deleted 286 lines changed or added

This html diff was produced by rfcdiff 1.41. The latest version is available from http://tools.ietf.org/tools/rfcdiff/