draft-ietf-v6ops-3gpp-eps-08.txt   rfc6459.txt 
Individual Submission J. Korhonen, Ed. Internet Engineering Task Force (IETF) J. Korhonen, Ed.
Internet-Draft Nokia Siemens Networks Request for Comments: 6459 Nokia Siemens Networks
Intended status: Informational J. Soininen Category: Informational J. Soininen
Expires: April 2, 2012 Renesas Mobile ISSN: 2070-1721 Renesas Mobile
B. Patil B. Patil
T. Savolainen T. Savolainen
G. Bajko G. Bajko
Nokia Nokia
K. Iisakkila K. Iisakkila
Renesas Mobile Renesas Mobile
September 30, 2011 January 2012
IPv6 in 3GPP Evolved Packet System IPv6 in 3rd Generation Partnership Project (3GPP)
draft-ietf-v6ops-3gpp-eps-08 Evolved Packet System (EPS)
Abstract Abstract
Use of data services in smart phones and broadband services via HSPA The use of cellular broadband for accessing the Internet and other
and HSPA+, in particular Internet services, has increased rapidly and data services via smartphones, tablets, and notebook/netbook
operators that have deployed networks based on 3GPP network computers has increased rapidly as a result of high-speed packet data
architectures are facing IPv4 address shortages at the Internet networks such as HSPA, HSPA+, and now Long-Term Evolution (LTE) being
registries and are feeling a pressure to migrate to IPv6. This deployed. Operators that have deployed networks based on 3rd
document describes the support for IPv6 in 3GPP network Generation Partnership Project (3GPP) network architectures are
architectures. facing IPv4 address shortages at the Internet registries and are
feeling pressure to migrate to IPv6. This document describes the
Status of this Memo support for IPv6 in 3GPP network architectures.
This Internet-Draft is submitted in full conformance with the Status of This Memo
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering This document is not an Internet Standards Track specification; it is
Task Force (IETF). Note that other groups may also distribute published for informational purposes.
working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months This document is a product of the Internet Engineering Task Force
and may be updated, replaced, or obsoleted by other documents at any (IETF). It represents the consensus of the IETF community. It has
time. It is inappropriate to use Internet-Drafts as reference received public review and has been approved for publication by the
material or to cite them other than as "work in progress." Internet Engineering Steering Group (IESG). Not all documents
approved by the IESG are a candidate for any level of Internet
Standard; see Section 2 of RFC 5741.
This Internet-Draft will expire on April 2, 2012. Information about the current status of this document, any errata,
and how to provide feedback on it may be obtained at
http://www.rfc-editor.org/info/rfc6459.
Copyright Notice Copyright Notice
Copyright (c) 2011 IETF Trust and the persons identified as the Copyright (c) 2012 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
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
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 . . . . . . . . . . . . . . . . . . . . 10 2.2. The Concept of APN ........................................10
3. IP over 3GPP GPRS . . . . . . . . . . . . . . . . . . . . . . 10 3. IP over 3GPP GPRS ..............................................11
3.1. Introduction to 3GPP GPRS . . . . . . . . . . . . . . . . 10 3.1. Introduction to 3GPP GPRS .................................11
3.2. PDP Context . . . . . . . . . . . . . . . . . . . . . . . 12 3.2. PDP Context ...............................................12
4. IP over 3GPP EPS . . . . . . . . . . . . . . . . . . . . . . . 13 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 ..........................................15
5. Address Management . . . . . . . . . . . . . . . . . . . . . . 15 5. Address Management .............................................16
5.1. IPv4 Address Configuration . . . . . . . . . . . . . . . . 15 5.1. IPv4 Address Configuration ................................16
5.2. IPv6 Address Configuration . . . . . . . . . . . . . . . . 15 5.2. IPv6 Address Configuration ................................16
5.3. Prefix Delegation . . . . . . . . . . . . . . . . . . . . 16 5.3. Prefix Delegation .........................................17
5.4. IPv6 Neighbor Discovery Considerations . . . . . . . . . . 17 5.4. IPv6 Neighbor Discovery Considerations ....................18
6. 3GPP Dual-Stack Approach to IPv6 . . . . . . . . . . . . . . . 18 6. 3GPP Dual-Stack Approach to IPv6 ...............................18
6.1. 3GPP Networks Prior to Release-8 . . . . . . . . . . . . . 18 6.1. 3GPP Networks Prior to Release-8 ..........................18
6.2. 3GPP Release-8 and -9 Networks . . . . . . . . . . . . . . 19 6.2. 3GPP Release-8 and -9 Networks ............................20
6.3. PDN Connection Establishment Process . . . . . . . . . . . 20 6.3. PDN Connection Establishment Process ......................21
6.4. Mobility of 3GPP IPv4v6 Type of Bearers . . . . . . . . . 22 6.4. Mobility of 3GPP IPv4v6 Bearers ...........................23
7. Dual-Stack Approach to IPv6 Transition in 3GPP Networks . . . 23 7. Dual-Stack Approach to IPv6 Transition in 3GPP Networks ........24
8. Deployment issues . . . . . . . . . . . . . . . . . . . . . . 23 8. Deployment Issues ..............................................25
8.1. Overlapping IPv4 Addresses . . . . . . . . . . . . . . . . 23 8.1. Overlapping IPv4 Addresses ................................25
8.2. IPv6 for transport . . . . . . . . . . . . . . . . . . . . 24 8.2. IPv6 for Transport ........................................26
8.3. Operational Aspects of Running Dual-Stack Networks . . . . 25 8.3. Operational Aspects of Running Dual-Stack Networks ........26
8.4. Operational Aspects of Running a Network with 8.4. Operational Aspects of Running a Network with
IPv6-only Bearers . . . . . . . . . . . . . . . . . . . . 26 IPv6-Only Bearers .........................................27
8.5. Restricting Outbound IPv6 Roaming . . . . . . . . . . . . 27 8.5. Restricting Outbound IPv6 Roaming .........................28
8.6. Inter-RAT Handovers and IP Versions . . . . . . . . . . . 27 8.6. Inter-RAT Handovers and IP Versions .......................29
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 ............29
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 30 9. Security Considerations ........................................31
10. Security Considerations . . . . . . . . . . . . . . . . . . . 30 10. Summary and Conclusions .......................................32
11. Summary and Conclusion . . . . . . . . . . . . . . . . . . . . 31 11. Acknowledgements ..............................................32
12. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 31 12. Informative References ........................................33
13. Informative References . . . . . . . . . . . . . . . . . . . . 31
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 34
1. Introduction 1. Introduction
IPv6 has been specified in the 3rd Generation Partnership Project IPv6 support has been part of the 3rd Generation Partnership Project
(3GPP) standards since the early architectures developed for R99 (3GPP) standards since the first release of the specifications
General Packet Radio Service (GPRS). However, the support for IPv6 (Release 99). This support extends to all radio access and packet-
in commercially deployed networks remains low. There are many based system variants of the 3GPP architecture family. In addition,
factors that can be attributed to the lack of IPv6 deployment in 3GPP a lot of work has been invested by the industry to investigate
networks. The most relevant one is essentially the same as the different transition and deployment scenarios over the years.
reason for IPv6 not being deployed by other networks as well, i.e. However, IPv6 deployment in commercial networks remains low. There
the lack of business and commercial incentives for deployment. 3GPP are many factors that can be attributed to this lack of deployment.
network architectures have also evolved since 1999 (since R99). The The most relevant factor is essentially the same as the reason for
most recent version of the 3GPP architecture, the Evolved Packet IPv6 not being deployed in other networks either, i.e., the lack of
System (EPS), which is commonly referred to as SAE, LTE or Release-8, business and commercial incentives for deployment.
is a packet centric architecture. The number of subscribers and
devices that are using the 3GPP networks for Internet connectivity 3GPP network architectures have continued to evolve in the time since
and data services has also increased significantly. With the Release 99, which was finalized in early 2000. The most recent
subscriber growth numbers projected to increase even further and the version of the 3GPP architecture, the Evolved Packet System (EPS) --
IPv4 addresses depletion problem looming in the near term, 3GPP commonly referred to as System Architecture Evolution (SAE), Long-
operators and vendors have started the process of identifying the Term Evolution (LTE), or Release-8 -- is a packet-centric
scenarios and solutions needed to transition to IPv6. architecture. In addition, the number of subscribers and devices
using the 3GPP networks for Internet connectivity and data services
has also increased phenomenally -- the number of mobile broadband
subscribers has increased exponentially over the last couple of
years.
With subscriber growth projected to increase even further, and with
recent depletion of available IPv4 address space by IANA, 3GPP
operators and vendors are now in the process of identifying the
scenarios and solutions needed to deploy IPv6.
This document describes the establishment of IP connectivity in 3GPP This document describes the establishment of IP connectivity in 3GPP
network architectures, specifically in the context of IP bearers for network architectures, specifically in the context of IP bearers for
3GPP GPRS and for 3GPP EPS. It provides an overview of how IPv6 is 3G General Packet Radio Service (GPRS) and for EPS. It provides an
supported as per the current set of 3GPP specifications. Some of the overview of how IPv6 is supported as per the current set of 3GPP
issues and concerns with respect to deployment and shortage of specifications. Some of the issues and concerns with respect to
private IPv4 addresses within a single network domain are also deployment and shortage of private IPv4 addresses within a single
discussed. network domain are also discussed.
The IETF has specified a set of tools and mechanisms that can be The IETF has specified a set of tools and mechanisms that can be
utilized for transitioning to IPv6. In addition to operating dual- utilized for transitioning to IPv6. In addition to operating dual-
stack networks during the transition from IPv4 to IPv6 phase, the two stack networks during the transition from IPv4 to IPv6, the two
alternative categories for the transition are encapsulation and alternative categories for the transition are encapsulation and
translation. The IETF continues to specify additional solutions for translation. The IETF continues to specify additional solutions for
enabling the transition based on the deployment scenarios and enabling the transition based on the deployment scenarios and
operator/ISP requirements. There is no single approach for operator/ISP requirements. There is no single approach for
transition to IPv6 that can meet the needs for all deployments and transition to IPv6 that can meet the needs for all deployments and
models. The 3GPP scenarios for transition, described in [TR.23975], models. The 3GPP scenarios for transition, described in [TR.23975],
can be addressed using transition mechanisms that are already can be addressed using transition mechanisms that are already
available in the toolbox. The objective of transition to IPv6 in available in the toolbox. The objective of transition to IPv6 in
3GPP networks is to ensure that: 3GPP networks is to ensure that:
1. Legacy devices and hosts which have an IPv4-only stack will 1. Legacy devices and hosts that have an IPv4-only stack will
continue to be provided with IP connectivity to the Internet and continue to be provided with IP connectivity to the Internet and
services, services.
2. Devices which are dual-stack can access the Internet either via 2. Devices that are dual-stack can access the Internet either via
IPv6 or IPv4. The choice of using IPv6 or IPv4 depends on the IPv6 or IPv4. The choice of using IPv6 or IPv4 depends on the
capability of: capability of:
A. the application on the host, A. the application on the host,
B. the support for IPv4 and IPv6 bearers by the network and/or, B. the support for IPv4 and IPv6 bearers by the network, and/or
C. the capability of the server(s) and other end points. C. the server(s) and other end points.
3GPP networks are capable of providing a host with IPv4 and IPv6 3GPP networks are capable of providing a host with IPv4 and IPv6
connectivity today, albeit in many cases with upgrades to network connectivity today, albeit in many cases with upgrades to network
elements such as the SGSN and GGSN. elements such as the Serving GPRS Support Node (SGSN) and the Gateway
GPRS Support Node (GGSN).
2. 3GPP Terminology and Concepts 2. 3GPP Terminology and Concepts
2.1. Terminology 2.1. Terminology
Access Point Name Access Point Name
Access Point Name (APN) is a fully qualified domain name and The Access Point Name (APN) is a Fully Qualified Domain Name
resolves to a specific gateway in an operators network. The APNs (FQDN) and resolves to a set of gateways in an operator's network.
are piggybacked on the administration of the DNS namespace. The APNs are piggybacked on the administration of the DNS
namespace.
Dual Address PDN/PDP Type Dual Address PDN/PDP Type
The Dual Address PDN/PDP Type (IPv4v6) is used in 3GPP context in The dual address Packet Data Network/Packet Data Protocol (PDN/
many cases as a synonym for dual-stack i.e. a connection type PDP) Type (IPv4v6) is used in 3GPP context in many cases as a
capable of serving both IPv4 and IPv6 simultaneously. synonym for dual-stack, i.e., a connection type capable of serving
both IPv4 and IPv6 simultaneously.
Evolved Packet Core Evolved Packet Core
Evolved Packet Core (EPC) is an evolution of the 3GPP GPRS system The Evolved Packet Core (EPC) is an evolution of the 3GPP GPRS
characterized by higher-data-rate, lower-latency, packet-optimized system characterized by a higher-data-rate, lower-latency, packet-
system. EPC comprises of subcomponents such as Mobility optimized system. The EPC comprises subcomponents such as the
Management Entity (MME), Serving Gateway (SGW), Packet Data Mobility Management Entity (MME), Serving Gateway (SGW), Packet
Network Gateway (PDN-GW) and Home Subscriber Server (HSS). Data Network Gateway (PDN-GW), and Home Subscriber Server (HSS).
Evolved Packet System Evolved Packet System
Evolved Packet System (EPS) is an evolution of the 3GPP GPRS The Evolved Packet System (EPS) is an evolution of the 3GPP GPRS
system characterized by higher-data-rate, lower-latency, packet- system characterized by a 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 (RATs). The EPS comprises the EPC together with the Evolved
with the evolved radio access network (E-UTRA and E-UTRAN). Universal Terrestrial Radio Access (E-UTRA) and the Evolved
Universal Terrestrial Radio Access Network (E-UTRAN).
Evolved UTRAN Evolved UTRAN
Evolved UTRAN (E-UTRAN) is communications network, sometimes The Evolved UTRAN (E-UTRAN) is a 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 stations),
make up the E-UTRAN radio access network. The E-UTRAN allows which make up the E-UTRAN. The E-UTRAN allows connectivity
connectivity between the User Equipment and the core network. between the User Equipment and the core network.
GPRS tunnelling protocol GPRS Tunnelling Protocol
GPRS Tunnelling Protocol (GTP) [TS.29060] [TS.29274] is a The GPRS Tunnelling Protocol (GTP) [TS.29060] [TS.29274]
tunnelling protocol defined by 3GPP. It is a network based [TS.29281] is a tunnelling protocol defined by 3GPP. It is a
mobility protocol and similar to Proxy Mobile IPv6 (PMIPv6) network-based mobility protocol and is similar to Proxy Mobile
[RFC5213]. However, GTP also provides functionality beyond IPv6 (PMIPv6) [RFC5213]. However, GTP also provides functionality
mobility such as inband signaling related to Quality of Service beyond mobility, such as in-band signaling related to Quality of
(QoS) and charging among others. Service (QoS) and charging, among others.
GSM EDGE Radio Access Network GSM EDGE Radio Access Network
GSM EDGE Radio Access Network (GERAN) is communications network, The Global System for Mobile Communications (GSM) EDGE Radio
commonly referred to as 2G or 2.5G, and consists of base stations Access Network (GERAN) is a communications network, commonly
and Base Station Controllers (BSC) which make up the GSM EDGE referred to as 2G or 2.5G, and consists of base stations and Base
radio access network. The GERAN allows connectivity between the Station Controllers (BSCs), which make up the GSM EDGE radio
User Equipment and the core network. access network. The GERAN allows connectivity between the 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, The Gateway GPRS Support Node (GGSN) is a gateway function in the
which provides connectivity to Internet or other PDNs. The host GPRS that provides connectivity to the Internet or other PDNs.
attaches to a GGSN identified by an APN assigned to it by an The host attaches to a GGSN identified by an APN assigned to it by
operator. The GGSN also serves as the topological anchor for an operator. The GGSN also serves as the topological anchor for
addresses/prefixes assigned to the User Equipment. 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 The General Packet Radio Service (GPRS) is a packet-oriented
data service available to users of the 2G and 3G cellular mobile data service available to users of the 2G and 3G cellular
communication systems Global System for Mobile communications communication systems -- the GSM -- specified by 3GPP.
(GSM), and specified by 3GPP.
High Speed Packet Access High-Speed Packet Access
The High Speed Packet Access (HSPA) and the Evolved High Speed The High-Speed Packet Access (HSPA) and HSPA+ are enhanced
Packet Access (HSPA+) are enhanced versions of the WCDMA and versions of the Wideband Code Division Multiple Access (WCDMA) and
UTRAN, thus providing more data throughput and lower latencies. UTRAN, thus providing more data throughput and lower latencies.
Home Location Register Home Location Register
The Home Location Register (HLR) is a pre-Release-5 database (but The Home Location Register (HLR) is a pre-Release-5 database (but
is also used in Release-5 and later networks in real deployments) is also used in Release-5 and later networks in real deployments)
that contains subscriber data and call routing related that contains subscriber data and information related to call
information. Every subscriber of an operator including routing. All subscribers of an operator, and the subscribers'
subscribers' enabled services are provisioned in the HLR. enabled services, are provisioned in the HLR.
Home Subscriber Server Home Subscriber Server
The Home Subscriber Server (HSS) is a database for a given The Home Subscriber Server (HSS) is a database for a given
subscriber and got introduced in 3GPP Release-5. It is the entity subscriber and was introduced in 3GPP Release-5. It is the entity
containing the subscription-related information to support the containing the subscription-related information to support the
network entities actually handling calls/sessions. network entities actually handling calls/sessions.
Mobility Management Entity Mobility Management Entity
Mobility Management Entity (MME) is a network element that is The Mobility Management Entity (MME) is a network element that is
responsible for control plane functionalities, including responsible for control-plane functionalities, including
authentication, authorization, bearer management, layer-2 authentication, authorization, bearer management, layer-2
mobility, etc. The MME is essentially the control plane part of mobility, etc. The MME is essentially the control-plane part of
the SGSN in GPRS. The user plane traffic bypasses the MME. the SGSN in the GPRS. The user-plane traffic bypasses the MME.
Mobile Terminal Mobile Terminal
The Mobile Terminal (MT) is the modem and the radio part of the The Mobile Terminal (MT) is the modem and the radio part of the
Mobile Station (MS). Mobile Station (MS).
Public Land Mobile Network Public Land Mobile Network
The Public Land Mobile Network (PLMN) is a network that is The Public Land Mobile Network (PLMN) is a network that is
operated by a single administration. A PLMN (and therefore also operated by a single administration. A PLMN (and therefore also
an operator) is identified by the Mobile Country Code (MCC) and an operator) is identified by the Mobile Country Code (MCC) and
the Mobile Network Code (MNC). Each (telecommunications) operator the Mobile Network Code (MNC). Each (telecommunications) operator
providing mobile services has its own PLMN. providing mobile services has its own PLMN.
Policy and Charging Control Policy and Charging Control
The Policy and Charging Control (PCC) framework is used for QoS The Policy and Charging Control (PCC) framework is used for QoS
policy and charging control. It has two main functions: flow policy and charging control. It has two main functions: flow-
based charging including online credit control, and policy control based charging, including online credit control; and policy
(e.g. gating control, QoS control and QoS signaling). It is control (e.g., gating control, QoS control, and QoS signaling).
optional to 3GPP EPS but needed if dynamic policy and charging It is optional to 3GPP EPS but needed if dynamic policy and
control by means of PCC rules based on user and services are charging control by means of PCC rules based on user and services
desired. are desired.
Packet Data Network Packet Data Network
Packet Data Network (PDN) is a packet based network that either The Packet Data Network (PDN) is a packet-based network that
belongs to the operator or is an external network such as Internet either belongs to the operator or is an external network such as
and corporate intranet. The user eventually accesses services in the Internet or a corporate intranet. The user eventually
one or more PDNs. The operator's packet core network are accesses services in one or more PDNs. The operator's packet core
separated from packet data networks either by GGSNs or PDN networks are separated from packet data networks either by GGSNs
Gateways (PDN-GW). or PDN Gateways (PDN-GWs).
Packet Data Network Gateway Packet Data Network Gateway
Packet Data Network Gateway (PDN-GW) is a gateway function in The Packet Data Network Gateway (PDN-GW) is a gateway function in
Evolved Packet System (EPS), which provides connectivity to the Evolved Packet System (EPS), which provides connectivity to
Internet or other PDNs. The host attaches to a PDN-GW identified the Internet or other PDNs. The host attaches to a PDN-GW
by an APN assigned to it by an operator. The PDN-GW also serves identified by an APN assigned to it by an operator. The PDN-GW
as the topological anchor for addresses/prefixes assigned to the also serves as the topological anchor for addresses/prefixes
User Equipment. assigned to the 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 User Equipment (UE) and a PDN using
a specific gateway.
Packet Data Protocol Type Packet Data Protocol Type
A Packet Data Protocol Type (PDP Type) identifies the used/allowed A Packet Data Protocol Type (PDP Type) identifies the used/allowed
protocols within the PDP Context. Examples are IPv4, IPv6 and protocols within the PDP context. Examples are IPv4, IPv6, and
IPv4v6 (dual stack). IPv4v6 (dual-stack).
S4 Serving Gateway Support Node S4 Serving GPRS Support Node
S4 Serving Gateway Support Node (S4-SGSN) is a Release-8 (and The S4 Serving GPRS Support Node (S4-SGSN) is compliant with a
onwards) compliant SGSN that connects 2G/3G radio access network Release-8 (and onwards) SGSN that connects 2G/3G radio access
to EPC via new Release-8 interfaces like S3, S4, and S6d. networks to the 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 The Serving Gateway (SGW) is a gateway function in the EPS, which
terminates the interface towards E-UTRAN. The SGW is the Mobility terminates the interface towards the E-UTRAN. The SGW is the
Anchor point for layer-2 mobility (inter-eNodeB handovers). For Mobility Anchor point for layer-2 mobility (inter-eNodeB
each User Equipment connected with the EPS, at any given point of handovers). For each UE connected with the EPS, at any given
time, there is only one SGW. The SGW is essentially the user point in time, there is only one SGW. The SGW is essentially the
plane part of the GPRS' SGSN forwarding packets between a PDN-GW. user-plane part of the GPRS's SGSN.
Serving Gateway Support Node Serving GPRS Support Node
Serving Gateway Support Node (SGSN) is a network element that is The Serving GPRS 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 User Equipment point to point (p2p) tunnel between (GGSN). A per-UE point-to-point (p2p) tunnel between the GGSN and
the GGSN and SGSN transports the packets between the User SGSN transports the packets between the UE and 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 user. 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 an MT, for example, over the Point to Point
(PPP). Protocol (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 that are hosts with the
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). is comprised of the Terminal Equipment (TE) and a Mobile Terminal
The terms UE, MS, MN and devices are used interchangeably within (MT). The terms UE, MS, MN, and mobile are used interchangeably
this document. within this document.
UMTS Terrestrial Radio Access Network UMTS Terrestrial Radio Access Network
UMTS Terrestrial Radio Access Network (UTRAN) is communications The Universal Mobile Telecommunications System (UMTS) Terrestrial
network, commonly referred to as 3G, and consists of NodeBs (3G Radio Access Network (UTRAN) is a communications network, commonly
base station) and Radio Network Controllers (RNC) which make up referred to as 3G, and consists of NodeBs (3G base stations) and
the UMTS radio access network. The UTRAN allows connectivity Radio Network Controllers (RNCs), which make up the UMTS radio
between the User Equipment and the core network. UTRAN comprises access network. The UTRAN allows connectivity between the UE and
of WCDMA, HSPA and HSPA+ radio technologies. the core network. The UTRAN is comprised of WCDMA, HSPA, and
HSPA+ radio technologies.
User Plane User Plane
Data traffic and the required bearers for the data traffic. In The user plane refers to data traffic and the required bearers for
practice IP is the only data traffic protocol used in user plane. the data traffic. In practice, IP is the only data traffic
protocol used in the 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. User Equipment (UE) can choose discovery of gateways using the DNS. The UE can choose to attach to
to attach to a specific gateway in the packet core. The gateway a specific gateway in the packet core. The gateway provides
provides connectivity to the Packet Data Network (PDN) such as the connectivity to the Packet Data Network (PDN), such as the Internet.
Internet. An operator may also include gateways which do not provide An operator may also include gateways that do not provide Internet
Internet connectivity, rather a connectivity to closed network connectivity but rather provide connectivity to a closed network
providing a set of operator's own services. A UE can be attached to providing a set of the operator's own services. A UE can be attached
one or more gateways simultaneously. The gateway in a 3GPP network to one or more gateways simultaneously. The gateway in a 3GPP
is the GGSN or PDN-GW. Figure 1 below illustrates the APN-based network is the GGSN or PDN-GW. Figure 1 illustrates the APN-based
network connectivity concept. network connectivity concept.
.--. .--.
_(. `) _(. `)
.--. +------------+ _( PDN `)_ .--. +------------+ _( PDN `)_
_(Core`. |GW1 |====( Internet `) _(Core`. |GW1 |====( Internet `)
+---+ ( NW )------|APN=internet| ( ` . ) ) +---+ ( NW )------|APN=internet| ( ` . ) )
[UE]~~~~|RAN|----( ` . ) )--+ +------------+ `--(_______)---' [UE]~~~~|RAN|----( ` . ) )--+ +------------+ `--(_______)---'
^ +---+ `--(___.-' | ^ +---+ `--(___.-' |
| | .--. | | .--.
| | +----------+ _(.PDN`) | | +----------+ _(.PDN`)
| +--|GW2 | _(Operator`)_ | +--|GW2 | _(Operator`)_
| |APN=OpServ|====( Services `) | |APN=OpServ|====( Services `)
UE is attached +----------+ ( ` . ) ) UE is attached +----------+ ( ` . ) )
to GW1 and GW2 `--(_______)---' to GW1 and GW2 `--(_______)---'
simultaneously simultaneously
Figure 1: User Equipment 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 from 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 to as 2.5G), WCDMA (3G), and HSPA(+) (3G, often
as 3.5G). The architecture shares obvious similarities with the referred to as 3.5G). The architecture shares obvious similarities
Evolved Packet System (EPS) as will be seen in Section 4. Based on with the Evolved Packet System (EPS), as will be seen in Section 4.
Gn/Gp interfaces, the GPRS core network functionality is logically Based on Gn/Gp interfaces, the GPRS core network functionality is
implemented on two network nodes, the SGSN and the GGSN. logically implemented on two network nodes -- the SGSN and the GGSN.
3G 3G
.--. .--. .--. .--.
Uu _( `. Iu +----+ +----+ _( `. Uu _( `. Iu +----+ +----+ _( `.
[UE]~~|~~~( UTRAN )--|---|SGSN|--|---|GGSN|--|----( PDN ) [UE]~~|~~~( UTRAN )--|---|SGSN|--|---|GGSN|--|----( PDN )
( ` . ) ) +----+ Gn +----+ Gi ( ` . ) ) ( ` . ) ) +----+ Gn +----+ Gi ( ` . ) )
`--(___.-' / | `--(___.-' `--(___.-' / | `--(___.-'
/ | / |
2G Gb-- | 2G Gb-- |
.--. / | .--. / |
_( `. / --Gp _( `. / --Gp
[UE]~~|~~~( PDN )__/ | [UE]~~|~~~( PDN )__/ |
Um ( ` . ) ) .--. 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: Interfaces that provide a network-based mobility service for
a UE and are used between a SGSN and a GGSN. The Gn a UE and are used between an SGSN and a GGSN. The Gn
interface is used when GGSN and SGSN are located inside one interface is used when the GGSN and SGSN are located inside
operator (i.e. PLMN). The Gp-interface is used if the GGSN one operator (i.e., a PLMN). The Gp-interface is used if the
and the SGSN are located in different operator domains (i.e. GGSN and the SGSN are located in different operator domains
'other' PLMN). GTP protocol is defined for the Gn/Gp (i.e., a different PLMN). GTP 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: 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
on either on Frame Relay or IP. on either Frame Relay or IP.
Iu: Is the Radio Network System (RNS) to SGSN interface, which is Iu: The Radio Network System (RNS)-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 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 the 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: The interface between the GGSN and a PDN. The PDN may be an
be an operator external public or private packet data network operator's external public or private packet data network, or
or an intra-operator packet data network. an intra-operator packet data network.
Uu/Um: Are either 2G or 3G radio interfaces between a UE and a Uu/Um: 2G or 3G radio interfaces between a UE and a respective radio
respective radio access network. 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 UE within its geographical service area when a direct tunnel the UE within its geographical service area when a direct tunnel
option is not used. If the direct tunnel is used, then the user option is not used. If the direct tunnel is used, then the user
plane goes directly between the RNC (in the RNS) and the GGSN. The plane goes directly between the RNC (in the RNS) and the GGSN. The
control plane traffic always goes through the SGSN. For each UE 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 in time, there is only
one SGSN. one SGSN.
3.2. PDP Context 3.2. PDP Context
A PDP (Packet Data Protocol) context is an association between a UE A PDP (Packet Data Protocol) context is an association between a UE
represented by one IPv4 address and/or one /64 IPv6 prefix and a PDN represented by one IPv4 address and/or one /64 IPv6 prefix, and a PDN
represented by an APN. Each PDN can be accessed via a gateway represented by an APN. Each PDN can be accessed via a gateway
(typically a GGSN or PDN-GW). On the UE a PDP context is equivalent (typically a GGSN or PDN-GW). On the UE, a PDP context is equivalent
to a network interface. A UE 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. 3GPP GPRS gateways via separate connections, i.e., PDP contexts. 3GPP GPRS
supports PDP Types IPv4, IPv6 and since Release-9 also PDP Type supports PDP Types IPv4, IPv6, and since Release-9, PDP Type IPv4v6
IPv4v6 (dual-stack). (dual-stack) as well.
Each primary PDP context has its own IPv4 address and/or one /64 IPv6 Each primary PDP context has its own IPv4 address and/or one /64 IPv6
prefix assigned to it by the PDN and anchored in the corresponding prefix assigned to it by the PDN and anchored in the corresponding
gateway. The GGSN or PDN-GW is the first hop router for the UE. gateway. The GGSN or PDN-GW is the first-hop router for the UE.
Applications on the UE 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)
| | | 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: the
Equipment in 3GPP parlance). The 'PDPc1' PDP context that is 'PDPc1' PDP context, which is connected to APNx, provides Internet
connected to APNx provided Internet connectivity and the 'PDPc2' PDP connectivity, and the 'PDPc2' PDP context provides connectivity to a
context provides connectivity to a private IP network via APNy (as an private IP network via APNy (as an example, this network may include
example this network may include operator specific services such as operator-specific services, such as the MMS (Multimedia Messaging
MMS (Multi media service). An application on the host such as a web Service)). An application on the host, such as a web browser, would
browser would use the PDP context that provides Internet connectivity use the PDP context that provides Internet connectivity for accessing
for accessing services on the Internet. An application such as MMS services on the Internet. An application such as a MMS would use
would use APNy in the figure above because the service is provided APNy in the figure above, because the service is provided through the
through the private network. 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
functional split of gateways allows for operators to choose optimized functional split of gateways allows operators to choose optimized
topological locations of nodes within the network and enables various topological locations of nodes within the network and enables various
deployment models including the sharing of radio networks between deployment models, including the sharing of radio networks between
different operators. This also allows independent scaling and growth different operators. This also allows independent scaling, growth of
of traffic throughput and control signal processing. traffic throughput, and control-signal processing.
+--------+ +--------+
S1-MME +-------+ S11 | IP | | IP |
+----|----| MME |---|----+ |Services| S1-MME +-------+ S11 |Services|
| | | | +--------+ +----|----| MME |----|----+ +--------+
| +-------+ | S5/ |SGi | | | | |SGi
+----+ LTE-Uu +-------+ S1-U +-------+ S8 +-------+ | +-------+ | S5/ |
|UE |----|---|eNodeB |---|----------------| SGW |--|---|PDN-GW | +----+ LTE-Uu +-------+ S1-U +-------+ S8 +-------+
| |========|=======|====================|=======|======| | |UE |----|---|eNodeB |---|-----------------| SGW |--|---|PDN-GW |
+----+ +-------+DualStack EPS Bearer+-------+ +-------+ | |========|=======|=====================|=======|======| |
+----+ +-------+Dual-Stack EPS Bearer+-------+ +-------+
Figure 4: EPS Architecture for 3GPP Access Figure 4: EPS Architecture for 3GPP Access
S5/S8: It provides user plane tunnelling and tunnel management S5/S8: Provides user-plane tunnelling and tunnel management between
between SGW and PDN-GW, using GTP (both GTP-U and GTP-C) or the SGW and PDN-GW, using GTP (both GTP-U and GTP-C) or
PMIPv6 [RFC5213][TS.23402] as the network based mobility PMIPv6 [RFC5213] [TS.23402] as the network-based mobility
management protocol. The S5 interface is used when PDN-GW management protocol. The S5 interface is used when the
and SGW are located inside one operator (i.e. PLMN). The PDN-GW and SGW are located inside one operator (i.e., a
S8-interface is used if the PDN-GW and the SGW are located PLMN). The S8-interface is used if the PDN-GW and the SGW
in different operator domains (i.e. 'other' PLMN). are located in different operator domains (i.e., a different
PLMN).
S1-U: Provides user plane tunnelling and inter eNodeB path S11: Reference point for the control-plane protocol between the
switching during handover between eNodeB and SGW, using the MME and SGW, based on GTP-C (GTP control plane) and used,
GTP-U protocol (GTP user plane). for example, during the establishment or modification of the
default bearer.
S1-MME: Reference point for the control plane protocol between S1-U: Provides user-plane tunnelling and inter-eNodeB path
switching during handover between the eNodeB and SGW, using
GTP-U (GTP user plane).
S1-MME: Reference point for the control-plane protocol between the
eNodeB and MME. eNodeB and MME.
SGi: It is the interface between the PDN-GW and the packet data SGi: The interface between the PDN-GW and the PDN. The PDN may
network. Packet data network may be an operator external be an operator-external public or private packet data
public or private packet data network or an intra operator network or an intra-operator packet data network.
packet data network.
4.2. PDN Connection 4.2. PDN Connection
A PDN connection is an association between a UE represented by one A PDN connection is an association between a UE represented by one
IPv4 address and/or one /64 IPv6 prefix, and a PDN represented by an IPv4 address and/or one /64 IPv6 prefix, and a PDN represented 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). The PDN
responsible for the IP address/prefix allocation to the UE. On the is responsible for the IP address/prefix allocation to the UE. On
UE a PDN connection is equivalent to a network interface. A UE may the UE, a PDN connection is equivalent to a network interface. A UE
hence be attached to one or more gateways via separate connections, may hence be attached to one or more gateways via separate
i.e. PDN connections. 3GPP EPS supports PDN Types IPv4, IPv6 and connections, i.e., PDN connections. 3GPP EPS supports PDN Types IPv4,
IPv4v6 (dual-stack) since the beginning of EPS i.e. Release-8. IPv6, and IPv4v6 (dual-stack) since the beginning of EPS, i.e., since
Release-8.
Each PDN connection has its own IP address/prefix assigned to it by Each PDN connection has its own IP address/prefix assigned to it by
the PDN and anchored in the corresponding gateway. In case of GTP- the PDN and anchored in the corresponding gateway. In the case of
based S5/S8 interface, the PDN-GW is the first hop router for the UE the GTP-based S5/S8 interface, the PDN-GW is the first-hop router for
and in case of PMIPv6-based S5/S8 the SGW is the first hop router. the UE, and in the case of PMIPv6-based S5/S8, the SGW is the first-
Applications on the UE use the appropriate network interface (PDN hop router. Applications on the UE use the appropriate network
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 UE and the PDN-GW and is used to provide bearer exists between the UE and the PDN-GW and is used to provide
the same level of packet forwarding treatment to the aggregated IP the same level of packet-forwarding treatment to the aggregated IP
flows constituting the bearer. Services with IP flows requiring a flows constituting the bearer. Services with IP flows requiring
different packet forwarding treatment would therefore require more different packet-forwarding treatment would therefore require more
than one EPS bearer. The UE performs the binding of the uplink IP than one EPS bearer. The UE performs the binding of the uplink IP
flows to the bearer while the PDN-GW performs this function for the flows to the bearer, 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 always provide low latency 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 UE (this is different from and/or IPv6 prefix gets assigned to the UE (this is different from
GPRS, where UEs are not automatically assigned with an IP address or GPRS, where UEs are not automatically connected to a PDN and
prefix). This default bearer will be allowed to carry all traffic therefore do not get an IPv4 address and/or IPv6 prefix assigned
which is not associated with a dedicated bearer. Dedicated bearers until they activate their first PDP context). This default bearer
are used to carry traffic for IP flows that have been identified to will be allowed to carry all traffic that is not associated with a
require a specific packet forwarding treatment. They may be dedicated bearer. Dedicated bearers are used to carry traffic for IP
established at the time of startup; for example, in the case of flows that have been identified to require specific packet-forwarding
services that require always-on connectivity and better QoS than that treatment. They may be established at the time of startup -- for
provided by the default bearer. The default bearer and the dedicated example, in the case of services that require always-on connectivity
bearer(s) associated to it share the same IP address(es)/prefix. and better QoS than that provided by the default bearer. The default
bearer and the dedicated bearer(s) associated to it share the same IP
address(es)/prefix.
An EPS bearer is referred to as a GBR bearer if dedicated network An EPS bearer is referred to as a Guaranteed Bit Rate (GBR) bearer if
resources related to a Guaranteed Bit Rate (GBR) value that is dedicated network resources related to a GBR value that is associated
associated with the EPS bearer are permanently allocated (e.g. by an with the EPS bearer are permanently allocated (e.g., by an admission
admission control function in the eNodeB) at bearer establishment/ control function in the eNodeB) at bearer establishment/modification.
modification. Otherwise, an EPS bearer is referred to as a non-GBR Otherwise, an EPS bearer is referred to as a non-GBR bearer. The
bearer. The default bearer is always non-GBR, with the resources for default bearer is always non-GBR, with the resources for the IP flows
the IP flows not guaranteed at eNodeB, and with no admission control. not guaranteed at the 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 GBR and Maximum Bit Rate (MBR), while more than one
while more than one non-GBR bearer belonging to the same UE shares an non-GBR bearer belonging to the same UE shares an Aggregate MBR
Aggregate Maximum Bit Rate (AMBR). Non-GBR bearers can suffer packet (AMBR). Non-GBR bearers can suffer packet loss under congestion,
loss under congestion while GBR bearers are immune to such losses. while GBR bearers are immune to such losses as long as they honor the
contracted bit rates.
5. Address Management 5. Address Management
5.1. IPv4 Address Configuration 5.1. IPv4 Address Configuration
UE's IPv4 address configuration is always performed during PDP The UE's IPv4 address configuration is always performed during 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 UE must always specifications, but is not used on a wide scale. The UE must always
support address configuration as part of the bearer setup signaling, support address configuration as part of the bearer setup signaling,
since DHCPv4 is optional for both UEs and networks. since DHCPv4 is optional for both UEs and networks.
The 3GPP standards also specify a 'deferred IPv4 address allocation' The 3GPP standards also specify a 'deferred IPv4 address allocation'
on a PMIPv6-based dual-stack IPv4v6 PDN connection at the time of on a PMIPv6-based dual-stack IPv4v6 PDN connection at the time of
connection establishment as described in Section 4.7.1 of [TS.23402]. connection establishment, as described in Section 4.7.1 of
This has the advantage of a single PDN Connection for IPv6 and IPv4 [TS.23402]. This has the advantage of a single PDN connection for
along with deferring IPv4 address allocation until an application IPv6 and IPv4, along with deferring IPv4 address allocation until an
needs it. The deferred address allocation is based on the use of application needs it. The deferred address allocation is based on
DHCPv4 as well as appropriate UE side implementation dependant the use of DHCPv4 as well as appropriate UE-side implementation-
triggers to invoke the protocol. dependent triggers to invoke the protocol.
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
[RFC4861][RFC4862] is the only supported address configuration [RFC4861] and [RFC4862], is the only supported address configuration
mechanism. Stateful DHCPv6-based address configuration [RFC3315] is mechanism. Stateful DHCPv6-based address configuration [RFC3315] is
not supported by 3GPP specifications. On the other hand, Stateless not supported by 3GPP specifications. On the other hand, stateless
DHCPv6-service to obtain other configuration information is supported DHCPv6 service to obtain other configuration information is supported
[RFC3736]. This implies that the M-bit is always zero and the O-bit [RFC3736]. This implies that the M-bit is always zero and that the
may be set to one in the Router Advertisement (RA) sent to the UE. O-bit may be set to one in the Router Advertisement (RA) sent to
the UE.
3GPP network allocates each default bearer a unique /64 prefix, and The 3GPP network allocates each default bearer a unique /64 prefix,
uses layer-2 signaling to suggest user equipment an Interface and uses layer-2 signaling to suggest to the UE an Interface
Identifier that is guaranteed not to conflict with gateway's Identifier that is guaranteed not to conflict with the 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, on using privacy extensions for
SLAAC [RFC4941] or other similar types of mechanisms. However, there SLAAC [RFC4941] or other similar types of mechanisms. However, there
are network drivers that fail to pass the Interface Identifier to the are network drivers that fail to pass the Interface Identifier to the
stack and instead synthesize their own Interface Identifier (usually stack and instead synthesize their own Interface Identifier (usually
a MAC address equivalent). If the UE skips the Duplicate Address a Media Access Control (MAC) address equivalent). If the UE skips
Detection (DAD) and also has other issues with the Neighbor Discovery the Duplicate Address Detection (DAD) and also has other issues with
Protocol (see Section 5.4), then there is a small theoretical chance the Neighbor Discovery protocol (see Section 5.4), then there is a
that the UE configures exactly the same link-local address as the small theoretical chance that the UE will configure exactly the same
GGSN/PDN-GW. The address collision may then cause issues in the IP link-local address as the GGSN/PDN-GW. The address collision may
connectivity, for instance, the UE not being able to forward any then cause issues in IP connectivity -- for instance, the UE not
packets to uplink. being able to forward any packets to the uplink.
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. Details of the 3GPP link-model and address
configuration is described in Section 11.2.1.3.2a of [TS.29061]. configuration are provided 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 UE. Therefore, there is no need to perform any unique for the UE. Therefore, there is no need to perform any DAD on
Duplicate Address Detection (DAD) on addresses the UE creates (i.e., addresses the UE creates (i.e., the 'DupAddrDetectTransmits' variable
the 'DupAddrDetectTransmits' variable in the UE could be zero). The in the UE could be zero). The GGSN/PDN-GW is not allowed to generate
GGSN/PDN-GW is not allowed to generate any globally unique IPv6 any 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 UE in the RA.
RA.
The current 3GPP architecture limits number of prefixes in each The current 3GPP architecture limits the number of prefixes in each
bearer to a single /64 prefix. If the UE finds more than one prefix bearer to a single /64 prefix. If the UE finds more than one prefix
in the RA, it only considers the first one and silently discards the in the RA, it only considers the first one and silently discards the
others [TS.29061]. Therefore, multi-homing within a single bearer is others [TS.29061]. Therefore, multi-homing within a single bearer is
not possible. Renumbering without closing layer-2 connection is also not possible. Renumbering without closing the layer-2 connection is
not possible. The lifetime of /64 prefix is bound to lifetime of also not possible. The lifetime of the /64 prefix is bound to the
layer-2 connection even if the advertised prefix lifetime is longer lifetime of the layer-2 connection even if the advertised prefix
than the layer-2 connection lifetime. lifetime is longer 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 releases. However, the /64 prefix allocated for each
default bearer (and to the user equipment) may be shared to local default bearer (and to the UE) may be shared to the local area
area network by user equipment implementing Neighbor Discovery proxy network by the UE implementing Neighbor Discovery proxy (ND proxy)
(ND proxy) [RFC4389] functionality. [RFC4389] functionality.
Release-10 prefix delegation uses the DHCPv6-based prefix delegation The Release-10 prefix delegation uses the DHCPv6-based prefix
[RFC3633]. The model defined for Release-10 requires aggregatable delegation [RFC3633]. The model defined for Release-10 requires
prefixes, which means the /64 prefix allocated for the default bearer aggregatable prefixes, which means the /64 prefix allocated for the
(and to the user equipment) must be part of the shorter delegated default bearer (and to the UE) 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 that the shorter 'delegated
cannot be given to the requesting router (i.e. the user equipment) as prefix' cannot be given to the requesting router (i.e., the UE) 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 that the /64 prefix allocated to the default
is not part of the 'delegated prefix'. An option to exclude a prefix bearer is not part of the 'delegated prefix'. An option to exclude a
from delegation [I-D.ietf-dhc-pd-exclude] prevents this problem. prefix from delegation [PD-EXCLUDE] prevents this problem.
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) The 3GPP link between the UE and the next-hop router (e.g., the GGSN)
resemble a point to point (p2p) link, which has no link-layer resembles 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 the 2G/3G GPRS to
The UE IP stack has to take this into consideration. When the 3GPP the EPS. The UE IP stack has to take this into consideration. When
PDP Context appears as a PPP interface/link to the UE, the IP stack the 3GPP PDP context appears as a PPP interface/link to the UE, the
is usually prepared to handle Neighbor Discovery protocol and the IP stack is usually prepared to handle the Neighbor Discovery
related Neighbor Cache state machine transitions in an appropriate protocol and the related Neighbor Cache state machine transitions in
way, even though Neighbor Discovery protocol messages contain no link an appropriate way, even though Neighbor Discovery protocol messages
layer address information. However, some operating systems discard contain no link-layer address information. However, some operating
Router Advertisements on their PPP interface/link as a default systems discard Router Advertisements on their PPP interface/link as
setting. This causes the SLAAC to fail when the 3GPP PDP Context a default setting. This causes SLAAC to fail when the 3GPP PDP
gets established, thus stalling all IPv6 traffic. context gets established, thus stalling all IPv6 traffic.
Currently several operating systems and their network drivers can Currently, several operating systems and their network drivers can
make the 3GPP PDP Context to appear as an IEEE802 interface/link to make the 3GPP PDP context appear as an IEEE 802 interface/link to the
the IP stack. This has few known issues, especially when the IP IP stack. This has a few known issues, especially when the IP stack
stack is made to believe the underlying link has link-layer is made to believe that the underlying link has link-layer addresses.
addresses. First, the Neighbor Advertisement sent by a GGSN as a First, the Neighbor Advertisement sent by a GGSN as a response to a
response to an address resolution triggered Neighbor Solicitation may Neighbor Solicitation triggered by address resolution might not
not contain a Target Link-Layer address option (as suggested in contain a Target Link-Layer Address option (see Section 4.4 of
[RFC4861] Section 4.4). Then it is possible that the address [RFC4861]). It is then possible that the address resolution never
resolution never completes when the UE tries to resolve the link- completes when the UE tries to resolve the link-layer address of the
layer address of the GGSN, thus stalling all IPv6 traffic. GGSN, thus stalling all IPv6 traffic.
Second, the GGSN may simply discard all address resolution triggered Second, the GGSN may simply discard all Neighbor Solicitation
Neighbor Solicitation messages (as sometimes misinterpreted from messages triggered by address resolution (as Section 2.4.1 of
[RFC3316] Section 2.4.1 that responding to address resolution and [RFC3316] is sometimes misinterpreted as saying that responding to
next-hop determination are not needed). As a result the address address resolution and next-hop determination is not needed). As a
resolution never completes when the UE tries to resolve the link- result, the address resolution never completes when the UE tries to
layer address of the GGSN, thus stalling all IPv6 traffic. There is resolve the link-layer address of the GGSN, thus stalling all IPv6
little that can be done about this in the GGSN, assuming the Neighbor traffic. There is little that can be done about this in the GGSN,
Discovery implementation already does the right thing. But the UE assuming the neighbor-discovery implementation already does the right
stacks must be able to handle address resolution in the manner that thing. But the UE stacks must be able to handle address resolution
they have chosen to represent the interface. In other words, if they in the manner that they have chosen to represent the interface. In
emulate IEEE802 type interfaces, they also need to process Neighbor other words, if they emulate IEEE 802 interfaces, they also need to
Discovery messages correctly. process Neighbor Discovery messages correctly.
6. 3GPP Dual-Stack Approach to IPv6 6. 3GPP Dual-Stack Approach to IPv6
6.1. 3GPP Networks Prior to Release-8 6.1. 3GPP Networks Prior to Release-8
3GPP standards prior to Release-8 provide IPv6 access for cellular 3GPP standards prior to Release-8 provide IPv6 access for cellular
devices with PDP contexts of type IPv6 [TS.23060]. For dual-stack devices with PDP contexts of type IPv6 [TS.23060]. For dual-stack
access, a PDP context of type IPv6 is established in parallel to the access, a PDP context of type IPv6 is established in parallel to the
PDP context of type IPv4, as shown in Figure 5 and Figure 6. For PDP context of type IPv4, as shown in Figures 5 and 6. For IPv4-only
IPv4-only service, connections are created over the PDP context of service, connections are created over the PDP context of type IPv4,
type IPv4 and for IPv6-only service connections are created over the and for IPv6-only service, connections are created over the PDP
PDP context of type IPv6. The two PDP contexts of different type may context of type IPv6. The two PDP contexts of different type may use
use the same APN (and the gateway), however, this aspect is not the same APN (and the gateway); however, this aspect is not
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 | .--.
| U | | S | | S | _(IPv6`. | U | | S | | S | _(IPv6`.
| E | IPv6 context | N | | N | ( PDN ) | E | IPv6 context | N | | N | ( PDN )
|///|~~~~~~~//-----| |====|(s)|====( ` . ) ) |///|~~~~~~~//-----| |====|(s)|====( ` . ) )
+---+ +---+ +---+ `--(___.-' +---+ +---+ +---+ `--(___.-'
Figure 5: A dual-stack User Equipment connecting to both IPv4 and Figure 5: Dual-Stack (DS) User Equipment Connecting to Both IPv4 and
IPv6 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 )
| U | | S | | S |====( ` . ) ) | U | | S | | S |====( ` . ) )
| E | IPv6 context | N | | N | `--(___.-' | E | IPv6 context | N | | N | `--(___.-'
|///|~~~~~~~//-----| |====| | |///|~~~~~~~//-----| |====| |
+---+ +---+ +---+ +---+ +---+ +---+
Figure 6: A dual-stack User Equipment connecting to dual-stack Figure 6: Dual-Stack User Equipment Connecting to Dual-Stack Internet
Internet using parallel IPv4-only and IPv6-only PDP contexts 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 types 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 Figure 6, the IPv4 and IPv6 PDP contexts are attached to
attached to the same GGSN. While this is possible, the dual-stack the same GGSN. While this is possible, the dual-stack MS may be
(DS) MS may be attached to different GGSNs in the scenario where one attached to different GGSNs in the scenario where one GGSN supports
GGSN supports IPv4 PDN connectivity while another GGSN provides IPv6 IPv4 PDN connectivity while another GGSN provides IPv6 PDN
PDN connectivity. connectivity.
6.2. 3GPP Release-8 and -9 Networks 6.2. 3GPP Release-8 and -9 Networks
Since 3GPP Release-8, the powerful concept of a dual-stack type of Since 3GPP Release-8, the powerful concept of a dual-stack type of
PDN connection and EPS bearer have been introduced [TS.23401]. This PDN connection and EPS bearer has been introduced [TS.23401]. This
enables parallel use of both IPv4 and IPv6 on a single bearer enables parallel use of both IPv4 and IPv6 on a single bearer
(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 (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 )
| U |~~~~~~~//-----| G |====| - |====( ` . ) ) | U |~~~~~~~//-----| G |====| - |====( ` . ) )
| E | bearer | W | | G | `--(___.-' | E | bearer | W | | G | `--(___.-'
|///| | | | W | |///| | | | W |
+---+ +---+ +---+ +---+ +---+ +---+
Figure 7: A dual-stack User Equipment connecting to dual-stack Figure 7: Dual-Stack User Equipment Connecting to Dual-Stack Internet
Internet using a single IPv4v6 type PDN connection Using a Single IPv4v6 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 the GPRS core (SGSN/GGSN) pre-Release-9,
two IP PDP Types, IPv4 and IPv6. Two PDP contexts are needed to there are two IP PDP Types: IPv4 and IPv6. Two PDP contexts are
get dual stack connectivity. needed to get dual-stack connectivity.
2. For 2G/3G access to GPRS core (SGSN/GGSN) from Release-9 there 2. For 2G/3G access to the GPRS core (SGSN/GGSN), starting with
are three IP PDP Types, IPv4, IPv6 and IPv4v6. Minimum one PDP Release-9, there are three IP PDP Types: IPv4, IPv6, and IPv4v6.
context is needed to get dual stack connectivity. A minimum of one PDP context is needed to get dual-stack
connectivity.
3. For 2G/3G access to EPC core (PDN-GW via S4-SGSN) from Release-8 3. For 2G/3G access to the EPC (PDN-GW via S4-SGSN), starting with
there are three IP PDP Types, IPv4, IPv6 and IPv4v6 which gets Release-8, there are three IP PDP Types: IPv4, IPv6, and IPv4v6
mapped to PDN Connection type. Minimum one PDP Context is needed (which gets mapped to the PDN connection type). A minimum of one
to get dual stack connectivity. PDP context is needed to get dual-stack connectivity.
4. For LTE (E-UTRAN) access to EPC core from Release-8 there are 4. For LTE (E-UTRAN) access to the EPC, starting with Release-8,
three IP PDN Types, IPv4, IPv6 and IPv4v6. Minimum one PDN there are three IP PDN Types: IPv4, IPv6, and IPv4v6. A minimum
Connection is needed to get dual stack connectivity. of one PDN connection is needed to get dual-stack connectivity.
6.3. PDN Connection Establishment Process 6.3. PDN Connection Establishment Process
The PDN connection establishment process is specified in detail in The PDN connection establishment process is specified in detail in
3GPP specifications. Figure 8 illustrates the high level process and 3GPP specifications. Figure 8 illustrates the high-level process and
signaling involved in the establishment of a PDN connection. signaling involved in the establishment of a PDN connection.
UE eNb/ MME SGW PDN-GW HSS/ UE eNodeB/ MME SGW PDN-GW HSS/
| BS | | | AAA | BS | | | AAA
| | | | | | | | | | | |
|---------->|(1) | | | | |---------->|(1) | | | |
| |---------->|(1) | | | | |---------->|(1) | | |
| | | | | | | | | | | |
|/---------------------------------------------------------\| |/---------------------------------------------------------\|
| Authentication and Authorization |(2) | Authentication and Authorization |(2)
|\---------------------------------------------------------/| |\---------------------------------------------------------/|
| | | | | | | | | | | |
| | |---------->|(3) | | | | |---------->|(3) | |
| | | |---------->|(3) | | | | |---------->|(3) |
| | | | | | | | | | | |
| | | |<----------|(4) | | | | |<----------|(4) |
| | |<----------|(4) | | | | |<----------|(4) | |
| |<----------|(5) | | | | |<----------|(5) | | |
|/---------\| | | | | |/---------\| | | | |
| RB setup |(6) | | | | | RB setup |(6) | | | |
|\---------/| | | | | |\---------/| | | | |
| |---------->|(7) | | | | |---------->|(7) | | |
|---------->|(8) | | | | |---------->|(8) | | | |
| |---------->|(9) | | | | |---------->|(9) | | |
| | | | | | | | | | | |
|============= Uplink Data =========>==========>|(10) | |============= Uplink Data =========>==========>|(10) |
| | | | | | | | | | | |
| | |---------->|(11) | | | | |---------->|(11) | |
| | | | | | | | | | | |
| | |<----------|(12) | | | | |<----------|(12) | |
| | | | | | | | | | | |
|<============ Downlink Data =======<===========|(13) | |<============ Downlink Data =======<===========|(13) |
| | | | | | | | | | | |
Figure 8: Simplified PDN connection setup procedure in Release-8 Figure 8: Simplified PDN Connection Setup Procedure in Release-8
1. The UE (i.e the MS) requires a data connection and hence decides 1. The UE (i.e., the MS) requires a data connection and hence
to establish a PDN connection with a PDN-GW. The UE sends an decides to establish a PDN connection with a PDN-GW. The UE
"Attach Request" (layer-2) to the BS. The BS forwards this sends an "Attach" request (layer-2) to the base station (BS).
attach request to the MME. The BS forwards this Attach request to the MME.
2. Authentication of the UE with the AAA server/HSS follows. If 2. Authentication of the UE with the Authentication, Authorization,
the UE is authorized for establishing a data connection, the and Accounting (AAA) server/HSS follows. If the UE is
following steps continue authorized to establish a data connection, the process continues
with the following steps:
3. The MME sends a "Create Session Request" message to the 3. The MME sends a "Create Session" request message to the SGW.
Serving-GW. The SGW forwards the create session request to the The SGW forwards the Create Session request to the PDN-GW. The
PDN-GW. The SGW knows the address of the PDN-GW to forward the SGW knows the address of the PDN-GW to which it forwards the
create session request to as a result of this information having Create Session request as a result of this information having
been obtained by the MME during the authentication/authorization been obtained by the MME during the authentication/authorization
phase. phase.
The UE IPv4 address and/or IPv6 prefix get assigned during this The UE IPv4 address and/or IPv6 prefix gets assigned during this
step. If a subscribed IPv4 address and/or IPv6 prefix is step. If a subscribed IPv4 address and/or IPv6 prefix is
statically allocated for the UE for this APN, then the MME statically allocated for the UE for this APN, then the MME
already passes the address information to the SGW and eventually passes this previously allocated address information to the SGW
to the PDN-GW in the "Create Session Request" message. and eventually to the PDN-GW in the Create Session request
Otherwise, the PDN-GW manages the address assignment to the UE message. Otherwise, the PDN-GW manages the address assignment
(there is another variation to this where IPv4 address to the UE (there is another variation to this step where IPv4
allocation is delayed until the UE initiates a DHCPv4 exchange address allocation is delayed until the UE initiates a DHCPv4
but this is not discussed here). exchange, but this is not discussed here).
4. The PDN-GW creates a PDN connection for the UE and sends "Create 4. The PDN-GW creates a PDN connection for the UE and sends a
Session Response" message to the SGW from which the session Create Session response message to the SGW from which the
request message was received from. The SGW forwards the session request message was received. The SGW forwards the
response to the corresponding MME which originated the request. response to the corresponding MME that originated the request.
5. The MME sends the "Attach Accept/Initial Context Setup request" 5. The MME sends the "Attach Accept/Initial Context Setup" request
message to the eNodeB/BS. message to the eNodeB/BS.
6. The radio bearer between the UE and the eNb is reconfigured 6. The radio bearer (RB) between the UE and the eNodeB is
based on the parameters received from the MME. (See note 1 reconfigured based on the parameters received from the MME.
below) (See Note 1 below.)
7. The eNb sends "Initial Context Response" message to the MME. 7. The eNodeB sends an "Initial Context" response message to
the MME.
8. The UE sends a "Direct Transfer" message to the eNodeB which 8. The UE sends a "Direct Transfer" message, which includes the
includes the Attach complete signal. "Attach Complete" signal, to the eNodeB.
9. The eNodeB forwards the Attach complete message to the MME. 9. The eNodeB forwards the Attach Complete message to the MME.
10. The UE can now start sending uplink packets to the PDN GW. 10. The UE can now start sending uplink packets to the PDN GW.
11. The MME sends a "Modify Bearer Request" message to the SGW. 11. The MME sends a "Modify Bearer" request message to the SGW.
12. The SGW responds with a "Modify Bearer Response" message. At 12. The SGW responds with a Modify Bearer response message. At this
this time the downlink connection is also ready. time, the downlink connection is also ready.
13. The UE can now start receiving downlink packets, including 13. The UE can now start receiving downlink packets, including
possible SLAAC related IPv6 packets. possible SLAAC-related IPv6 packets.
The type of PDN connection established between the UE and the PDN-GW The type of PDN connection established between the UE and the PDN-GW
can be any of the types described in the previous section. The dual- can be any of the types described in the previous section. The dual-
stack (DS) PDN connection, i.e the one which supports both IPv4 and stack PDN connection, i.e., the one that supports both IPv4 and IPv6
IPv6 packets is the default one that will be established if no packets, is the default connection that will be established if no
specific PDN connection type is specified by the UE in Release-8 specific PDN connection type is specified by the UE in Release-8
networks. networks.
Note 1: The UE receives the PDN Address Information Element Note 1: The UE receives the PDN Address Information Element
[TS.24301] at the end of radio bearer setup messaging. This [TS.24301] at the end of radio bearer setup messaging. This
Information Element contains only the Interface Identifier of the information element contains only the Interface Identifier of the
IPv6 address. In a case of GPRS the PDP Address Information IPv6 address. In the case of the GPRS, the PDP Address
Element [TS.24008] would contain a complete IPv6 address. Information Element [TS.24008] would contain a complete IPv6
However, the UE must ignore the IPv6 prefix if it receives one in address. However, the UE must ignore the IPv6 prefix if it
the message (see Section 11.2.1.3.2a of [TS.29061]). receives one in 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 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 an S4-SGSN for the new dual-stack bearers. The chosen
approach for mobility is as follows, in short: if a UE is allowed for approach for mobility is as follows, in short: if a UE is allowed to
doing handovers between a Release-8 LTE network and a pre-Release-9 do handovers between a Release-8 LTE network and a pre-Release-9
2G/3G network without a S4-SGSN while having open PDN connections, 2G/3G network without an S4-SGSN while having open PDN connections,
only single stack bearers are used. Essentially this means following only single-stack bearers are used. Essentially, this indicates the
deployment options: following deployment options:
1. If a network knows a UE may do handovers between a Release-8 LTE 1. If a network knows a UE may do handovers between a Release-8 LTE
network and a pre-Release-9 2G/3G network without a S4-SGSN, then network and a pre-Release-9 2G/3G network without an S4-SGSN,
the network is configured to provide only single stack bearers, then the network is configured to provide only single-stack
even if the UE requests dual-stack bearers. bearers, even if the UE requests dual-stack bearers.
2. If the network knows the UE 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
Release-9 network with a S4-SGSN, then the network is configured pre-Release-9 network with an S4-SGSN, then the network is
to provide the UE with dual-stack bearers on request. The same configured to provide the UE with dual-stack bearers on request.
also applies for LTE-only deployments. The same 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 UE always requests for a dual-stack bearers. A Release-8 UE always requests a dual-stack
dual-stack bearer, but accepts what is assigned by the network. bearer, but accepts what is assigned by the 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 UE and the gateway (GGSN or PDN-GW) as a result of establishing the UE and the gateway (GGSN or PDN-GW) as a result of establishing
either a dual-stack PDP context or parallel IPv4 and IPv6 PDP either a dual-stack PDP context or parallel IPv4 and 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 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 fall back to IPv4. A device that 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, the dual-
approach as such does not lower the number of used IPv4 addresses. stack approach as such does not lower the number of used IPv4
Every dual-stack bearer still needs to be given an IPv4 address, addresses. Every dual-stack bearer still needs to be given an IPv4
private or public. This is a major concern with dual-stack bearers address, private or public. This is a major concern with dual-stack
concerning IPv6 transition. However, if the majority of active IP bearers concerning IPv6 transition. However, if the majority of
communication has moved over to IPv6, then in case of Network Address active IP communication has moved over to IPv6, then in the case of
Translation from IPv4 to IPv4 (NAT44) [RFC1918] IPv4 connections the Network Address Translation from IPv4 to IPv4 (NAT44), the number of
number of active IPv4 connections can still be expected to gradually active NAT44-translated IPv4 connections can still be expected to
decrease and thus giving some level of relief regarding NAT44 gradually decrease and thus give some level of relief regarding NAT44
function scalability. 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 that supports both IPv4 and IPv6.
IPv6. Since IPv4 and IPv6 packets are carried as payload within GTP Since IPv4 and IPv6 packets are carried as payload within GTP between
between the MS and the gateway (GGSN/PDN-GW) the transport network 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 between the SGW and PDN-GW
immaterial. is 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 UEs when operators tend to assign private IPv4 addresses [RFC1918] to UEs when
they establish an IPv4-only PDP context or an IPv4v6 type PDN they establish an IPv4-only PDP context or an IPv4v6 PDN context.
context. About 16 million UEs can be assigned a private IPv4 address About 16 million UEs can be assigned a private IPv4 address that is
that is unique within a domain. However, in case of many operators unique within a domain. However, for many operators, the number of
the number of subscribers is greater than 16 million. The issue can subscribers is greater than 16 million. The issue can be dealt with
be dealt with by assigning overlapping RFC 1918 IPv4 addresses to by assigning overlapping RFC 1918 IPv4 addresses to UEs. As a
UEs. As a result the IPv4 address assigned to a UE within the result, the IPv4 address assigned to a UE within the context of a
context of a single operator realm would no longer be unique. This single operator realm would no longer be unique. This has the
has the obvious and known issues of NATed IP connection in the obvious and known issues of NATed IP connections in the Internet.
Internet. Direct UE to UE connectivity becomes complicated, unless Direct UE-to-UE connectivity becomes complicated; unless the UEs are
the UEs are within the same private address range pool and/or within the same private address range pool and/or anchored to the
anchored to the same gateway, referrals using IP addresses will have same gateway, referrals using IP addresses will have issues, and so
issues and so forth. These are generic issues and not only a concern forth. These are generic issues and not only a concern of the EPS.
of the EPS. However, 3GPP as such does not have any mandatory However, 3GPP as such does not have any mandatory language concerning
language concerning NAT44 functionality in EPC. Obvious deployment NAT44 functionality in the EPC. Obvious deployment choices apply
choices apply also to EPC: also to the 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 geographical areas. This partitioning allows
overlapping IPv4 addresses ranges to be assigned to UEs that are overlapping IPv4 address ranges to be assigned to UEs that are in
in different areas. Each area has its own pool of gateways that different areas. Each area has its own pool of gateways that are
are dedicated for a certain overlapping IPv4 address range dedicated to a certain overlapping IPv4 address range (also
(referred here later as a zone). Standard NAT44 functionality referred to as a zone). Standard NAT44 functionality allows for
allows for communication from the [RFC1918] private zone to the communication from the [RFC1918] private zone to the Internet.
Internet. Communication between zones require special Communication between zones requires special arrangement, such as
arrangement, such as using intermediate gateways (e.g. Back to using intermediate gateways (e.g., a Back-to-Back User Agent
Back User Agent (B2BUA) in case of SIP). (B2BUA) in the case of SIP).
2. A UE attaches to a gateway as part of the attach process. The 2. A UE attaches to a gateway as part of the Attach process. The
number of UEs that a gateway supports is in the order of 1 to 10 number of UEs that a gateway supports is on the order of 1 to 10
million. Hence all the UEs assigned to a single gateway can be million. Hence, all of the UEs assigned to a single gateway can
assigned private IPv4 addresses. Operators with large subscriber be assigned private IPv4 addresses. Operators with large
bases have multiple gateways and hence the same [RFC1918] IPv4 subscriber bases have multiple gateways, and hence the same
address space can be reused across gateways. The IPv4 address [RFC1918] IPv4 address space can be reused across gateways. The
assigned to a UE is unique within the scope of a single gateway. IPv4 address assigned to a UE is unique within the scope of a
single gateway.
3. New services requiring direct connectivity between UEs should be 3. New services requiring direct connectivity between UEs should be
built 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 since its introduction in
Release-8. The user plane traffic between the UE and the gateway can Release-8. The user-plane traffic between the UE and the gateway can
use either IPv4 or IPv6. These packets are essentially treated as use either IPv4 or IPv6. These packets are essentially treated as
payload by GTP/PMIPv6 and transported accordingly with no real payload by GTP/PMIPv6 and transported accordingly, with no real
attention paid to the information (at least from a routing attention paid (at least from a routing perspective) to the
perspective) contained in the IPv4 or IPv6 headers. The transport information 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
the architecture. to 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
plane traffic in the core network and as described earlier the user-plane traffic in the core network, and as described earlier, the
transport network IP version is not in any way tied to user plane IP transport-network IP version is not in any way tied to the user-plane
version. Furthermore, the design of the inter-operator roaming IP version. Furthermore, the design of the inter-operator roaming
networks is such that the user plane and transport network IP networks is such that the user-plane and transport-network IP
addressing is completely separated from each other. The inter- addressing schemes are completely separated from each other. The
operator roaming network itself is also completely separated from the inter-operator roaming network itself is also completely separated
Internet. Only those core network nodes that must be connected to from the Internet. Only those core network nodes that must be
the inter-operator roaming networks are actually visible there, and connected to the inter-operator roaming networks are actually visible
be able to send and receive (tunneled) traffic within the inter- there, and are able to send and receive (tunneled) traffic within the
operator roaming networks. Obviously, in order the roaming to work inter-operator roaming networks. Obviously, in order for the roaming
properly, the operators have to agree on supported protocol versions to work properly, the operators have to agree on supported protocol
so that the visited network does not, for example, unnecessarily drop versions so that the visited network does not, for example,
user plane IPv6 traffic. unnecessarily drop user-plane IPv6 traffic.
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
that legacy devices and services are unaffected and there is always a assurance that legacy devices and services are unaffected, and there
fallback to IPv4 in case of issues with the IPv6 deployment or is always a fallback to IPv4 in case of issues with the IPv6
network elements. The model also enables operators to develop deployment or network elements. The model also enables operators to
operational experience and expertise in an incremental manner. develop 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 UEs needs to be expanded since it can be address spaces. Tracking of UEs needs to be expanded, since it can
identified by either an IPv4 address or IPv6 prefix. Network be identified by either an IPv4 address or an 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 (see Section 6.1) for providing dual-
dual-stack like capability may mean doubled resource usage in stack capability may mean doubled resource usage in an operator's
operator's network. This is a major concern against providing dual- network. This is a major concern against providing dual-stack
stack like connectivity using techniques discussed in Section 6.1. connectivity using techniques discussed in Section 6.1. Also,
Also handovers between networks with different capabilities in terms handovers between networks with different capabilities in terms of
of networks being dual-stack like service capable or not, may turn whether or not networks are capable of dual-stack service may prove
out hard to comprehend for users and for application/services to cope difficult for users to comprehend and for applications/services to
with. These facts may add other than just technical concerns for cope with. These facts may add other than just technical concerns
operators when planning to roll out dual-stack service offerings. for 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 UEs in 3GPP It is possible to allocate IPv6-only bearers to UEs in 3GPP networks.
networks. IPv6-only bearer type has been part of the 3GPP The IPv6-only bearer has been part of the 3GPP specification since
specification since the beginning. In 3GPP Release-8 (and later) it the beginning. In 3GPP Release-8 (and later), it was defined that a
was defined that a dual-stack UE (or when the radio equipment has no dual-stack UE (or when the radio equipment has no knowledge of the UE
knowledge of the UE IP stack capabilities) must first attempt to IP stack's capabilities) must first attempt to establish a dual-stack
establish a dual-stack bearer and then possibly fall back to single bearer and then possibly fall back to a single-stack bearer. A
IP version bearer. A Release-8 (or later) UE with IPv6-only stack Release-8 (or later) UE with an IPv6-only stack can directly attempt
can directly attempt to establish an IPv6-only bearer. The IPv6-only to establish an IPv6-only bearer. The IPv6-only behavior is up to
behaviour is up to a subscription provisioning or a PDN-GW subscription provisioning or PDN-GW configuration, and the fallback
configuration, and the fallback scenarios do not necessarily cause scenarios do not 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. The following are
aspects to consider for running a network with IPv6-only bearers: some operational aspects to consider for running a network with
IPv6-only bearers:
o The UE must have an IPv6 capable stack and a radio interface o The UE must have an IPv6-capable stack and a radio interface
capable of establishing an IPv6 PDP context or PDN connection. capable of establishing an IPv6 PDP context or PDN 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 a
Type or PDN Type of IPv6. PDP 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 that 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 does not support
support PDP/PDN Type IPv6, then there needs to be a fallback PDP/PDN Type IPv6, then there needs to be a fallback option. The
option. The fallback option in this specific case is mostly up to fallback option in this specific case is mostly up to the UE to
the UE to implement. Several cases are discussed in the following implement. Several cases are discussed in the following sections.
sections.
o If and when a UE using IPv6-only bearer needs to access to IPv4 o If and when a UE using an IPv6-only bearer needs access to the
Internet/network, a translation of some type from IPv6 to IPv4 has IPv4 Internet/network, some type of translation from IPv6 to IPv4
to be deployed in the network. NAT64 (and DNS64) is one solution has to be deployed in the network. NAT64 (or DNS64) is one
that can be used for this purpose and works for a certain set of solution that can be used for this purpose and works for a certain
protocols (read TCP, UDP and ICMP, and when applications actually set of protocols (read TCP, UDP, and ICMP, and when applications
use DNS for resolving name to IP addresses). actually use DNS for resolving names 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 UEs there is interest in offering roaming service for IPv6-enabled UEs
and subscriptions, not all visited networks are prepared for IPv6 and subscriptions, not all visited networks are prepared for IPv6
outbound roamers: outbound roamers:
o The visited network SGSN does not support the IPv6 PDP Context or o The visited-network SGSN does not support the IPv6 PDP context or
IPv4v6 PDP Context types. These should mostly concern pre- IPv4v6 PDP context types. These should mostly concern
Release-9 2G/3G networks without S4-SGSN but there is no pre-Release-9 2G/3G networks without an S4-SGSN, but there is no
definitive rule as the deployed feature sets vary depending on definitive rule, as the deployed feature sets vary depending on
implementations and licenses. implementations and licenses.
o The visited network might not be commercially ready for IPv6 o The visited network might not be commercially ready for IPv6
outbound roamers, while everything might work technically at the outbound roamers, while everything might work technically at the
user plane level. This would lead to "revenue leakage" especially user-plane level. This would lead to "revenue leakage",
from the visited operator point of view (note that the use of especially from the visited operator's point of view (note that
visited network GGSN/PDN-GW does not really exist in commercial the use of a visited-network GGSN/PDN-GW does not really exist
deployments today for data roaming). today in commercial deployments for data roaming).
It might be in the interest of operators to prohibit roaming It might be in the interest of operators to prohibit roaming
selectively within specific visited networks until IPv6 roaming is in selectively within specific visited networks until IPv6 roaming is in
place. 3GPP does not specify a mechanism whereby IPv6 roaming is place. 3GPP does not specify a mechanism whereby IPv6 roaming is
prohibited without also disabling IPv4 access and other packet prohibited without also disabling IPv4 access and other packet
services. The following options for disabling IPv6 access for services. The following options for disabling IPv6 access for
roaming subscribers could be available in some network deployments: roaming subscribers could be available in some network deployments:
o Using Policy and Charging Control (PCC) [TS.23203] functionality o Policy and Charging Control (PCC) [TS.23203] functionality and its
and its rules to fail, for example, the bearer authorization when rules, for example, could be used to cause bearer authorization to
a desired criteria is met. In this case that would be PDN/PDP fail when a desired criteria is met. In this case, that would be
Type IPv6/IPv4v6 and a specific visited network. The rules can be PDN/PDP Type IPv6/IPv4v6 and a specific visited network. The
provisioned either in the home network or locally in the visited rules can be provisioned either in the home network or locally in
network. the visited 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 a well-specified
fall back mechanism from the UE point of view. fallback mechanism from the UE's 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 as operators start to incrementally deploy the EPS
with the existing UTRAN/GERAN, handovers between different radio along with the existing UTRAN/GERAN, handovers between different
technologies (inter-RAT handovers) become inevitable. In case of radio technologies (inter-RAT handovers) become inevitable. In the
inter-RAT handovers 3GPP supports the following IP addressing case of inter-RAT handovers, 3GPP supports the following IP
scenarios: addressing scenarios:
o E-UTRAN IPv4v6 bearer has to map one to one to UTRAN/GERAN IPv4v6 o The E-UTRAN IPv4v6 bearer has to map one to one to the UTRAN/GERAN
bearer. IPv4v6 bearer.
o E-UTRAN IPv6 bearer has to map one to one to UTRAN/GERAN IPv6 o The E-UTRAN IPv6 bearer has to map one to one to the UTRAN/GERAN
bearer. IPv6 bearer.
o E-UTRAN IPv4 bearer has to map one to one to UTRAN/GERAN IPv4 o The E-UTRAN IPv4 bearer has to map one to one to the UTRAN/GERAN
bearer. IPv4 bearer.
Other types of configurations are not standardized. What the above Other types of configurations are not standardized. The above rules
rules essentially imply is that the network migration has to be essentially imply that the network migration has to be planned and
planned and subscriptions provisioned based on the lowest common subscriptions provisioned based on the lowest common denominator, if
nominator, if inter-RAT handovers are desired. For example, if some inter-RAT handovers are desired. For example, if some part of the
part of the UTRAN network cannot serve anything but IPv4 bearers, UTRAN cannot serve anything but IPv4 bearers, then the E-UTRAN is
then the E-UTRAN is also forced to provide only IPv4 bearers. also forced to provide only IPv4 bearers. Various combinations of
Various combinations of subscriber provisioning regarding IP versions subscriber provisioning regarding IP versions are discussed further
are discussed further in Section 8.7. 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 the IPv4v6 PDP Type does not exist in
and Mobile Application Part (MAP) [TS.29002] signaling prior an HLR and Mobile Application Part (MAP) [TS.29002] signaling
Release-9). prior to 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 the IPv4_or_IPv6 PDP Type does
exist in a HLR or MAP signaling. However, a HLR may have multiple not exist in an HLR or MAP signaling. However, an HLR may have
APN configurations of different PDN Types, which effectively multiple APN configurations of different PDN Types; these
achieves the same functionality). configurations would effectively achieve the same functionality).
A Release-8 dual-stack UE must always attempt to establish a PDP/PDN A Release-8 dual-stack UE must always attempt to establish a PDP/PDN
Type IPv4v6 bearer. The same also applies when the modem part of the Type IPv4v6 bearer. The same also applies when the modem part of the
UE does not have exact knowledge whether the UE operating system IP UE does not have exact knowledge of whether the UE operating system
stack is a dual-stack capable or not. A UE that is IPv6-only capable IP stack is dual-stack capable or not. A UE that is IPv6-only
must attempt to establish a PDP/PDN Type IPv6 bearer. Last, a UE capable must attempt to establish a PDP/PDN Type IPv6 bearer. Last,
that is IPv4-only capable must attempt to establish a PDN/PDP Type a UE that is IPv4-only capable must attempt to establish a PDN/PDP
IPv4 bearer. Type IPv4 bearer.
In a case the PDP/PDN Type requested by a UE does not match what has In a case where the PDP/PDN Type requested by a UE does not match
been provisioned for the subscriber in the HSS (or HLR), the UE what has been provisioned for the subscriber in the HSS (or HLR), the
possibly falls back to a different PDP/PDN Type. The network (i.e. UE possibly falls back to a different PDP/PDN Type. The network
the MME or the S4-SGSN) is able to inform the UE during the network (i.e., the MME or the S4-SGSN) is able to inform the UE during
attachment signaling why it did not get the requested PDP/PDN Type. network attachment signaling as to why it did not get the requested
These response/cause codes are documented in [TS.24008] for requested PDP/PDN Type. These response/cause codes are documented in
PDP Types and [TS.24301] for requested PDN Types: [TS.24008] for requested PDP Types and [TS.24301] for requested PDN
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, the response/cause codes that are used vary,
the vendor, unfortunately. depending on the vendor, unfortunately.
Possible fall back cases when the network deploys MMEs and/or S4- Possible fallback cases when the network deploys MMEs and/or S4-SGSNs
SGSNs include (as documented in [TS.23401]): 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 UE receives o Requested IPv4v6 and provisioned IPv6 => IPv6, and a UE receives
indication that IPv6-only bearer is allowed. an indication that an IPv6-only bearer is allowed.
o Requested IPv4v6 and provisioned IPv4 => IPv4 and the UE receives o Requested IPv4v6 and provisioned IPv4 => IPv4, and the UE receives
indication that IPv4-only bearer is allowed. an indication that an 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
UE may then attempt to establish, based on the UE implementation, UE may then attempt to establish, based on the UE implementation,
a parallel bearer of a different PDP/PDN Type. a parallel bearer of a different PDP/PDN 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 an 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 UE Bearer" flag in the bearer establishment signaling, then the UE
receives an indication that IPv6-only or IPv4-only bearer is would have received an indication that an IPv6-only or IPv4-only
allowed. bearer is 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 UE Bearer" flag in the bearer establishment signaling, then the UE
may attempt to establish, based on the UE implementation, a may have attempted to establish, based on the UE implementation, a
parallel bearer of different PDP/PDN Type. parallel bearer of a different PDP/PDN Type.
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
not understand the requested PDN Type, then the PDN Type is handled
as IPv6.
9. IANA Considerations
This document has no requests to IANA. An SGSN that does not understand the requested PDP Type is supposed
to handle the requested PDP Type as IPv4. If for some reason an MME
does not understand the requested PDN Type, then the PDN Type is
handled as IPv6.
10. Security Considerations 9. Security Considerations
This document does not introduce any security related concerns. This document does not introduce any security-related concerns.
Section 5 of [RFC3316] already contains in depth discussion of IPv6 Section 5 of [RFC3316] already contains an in-depth discussion of
related security considerations in 3GPP networks prior Release-8. IPv6-related security considerations in 3GPP networks prior to
This section discusses few additional security concerns to take into Release-8. This section discusses a few additional security concerns
consideration. to take into consideration.
In 3GPP access the UE and the network always perform a mutual In 3GPP access, the UE and the network always perform a mutual
authentication during the network attachment [TS.33102][TS.33401]. authentication during the network attachment [TS.33102] [TS.33401].
Furthermore, each time a PDP Context/PDN Connection gets created, a Furthermore, each time a PDP context/PDN connection gets created, a
new connection, a modification of an existing connection and an new connection, a modification of an existing connection, and an
assignment of an IPv6 prefix or an IP address can be authorized assignment of an IPv6 prefix or an IP address can be authorized
against the PCC infrastructure [TS.23203] and/or PDN's AAA server. against the PCC infrastructure [TS.23203] and/or PDN's AAA server.
The wireless part of the 3GPP link between the UE and the (e)NodeB as The wireless part of the 3GPP link between the UE and the (e)NodeB as
well as the signaling messages between the UE and the MME/SGSN can be well as the signaling messages between the UE and the MME/SGSN can be
protected depending on the regional regulation and operators' protected, depending on the regional regulation and the operator's
deployment policy. User plane traffic can be confidentiality deployment policy. User-plane traffic can be confidentiality
protected. The control plane is always at least integrity and replay protected. The control plane is always at least integrity and replay
protected, and may also be confidentiality protected. The protection protected, and may also be confidentiality protected. The protection
within the transmission part of the network depends on operators' within the transmission part of the network depends on the operator's
deployment policy. [TS.33401] deployment policy [TS.33401].
Several of the on-link and neighbor discovery related attacks can be Several of the on-link and neighbor-discovery-related attacks can be
mitigated due the nature of 3GPP point to point link model, and the mitigated due to the nature of the 3GPP point-to-point link model,
fact the UE and the first hop router (PGW/GGSN or SGW) being the only and the fact that the UE and the first-hop router (PDN-GW/GGSN or
nodes on the link. For off-link IPv6 attacks the 3GPP EPS is as SGW) are the only nodes on the link. For off-link IPv6 attacks, the
vulnerable as any IPv6 system. 3GPP EPS is as vulnerable as any IPv6 system.
There have also been concerns that the UE IP stack might use There have also been concerns that the UE IP stack might use
permanent subscriber identities, such as IMSI, as the source for IPv6 permanent subscriber identities, such as an International Mobile
address Interface Identifier. This would be a privacy threat and Subscriber Identity (IMSI), as the source for the IPv6 address
allow tracking of subscribers, and therefore use of IMSI (or any Interface Identifier. This would be a privacy threat and would allow
[TS.23003] defined identity) as the Interface Identifier is tracking of subscribers. Therefore, the use of an IMSI (or any
identity defined by [TS.23003]) as the Interface Identifier is
prohibited [TS.23401]. However, there is no standardized method to prohibited [TS.23401]. However, there is no standardized method to
block such misbehaving UEs. block such misbehaving UEs.
11. Summary and Conclusion 10. Summary and Conclusions
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 that capability.
Release-8, 3GPP has specified a more optimal PDP context type which With Release-8, 3GPP has specified a more optimal PDP context type
enables the transport of IPv4 and IPv6 packets within a single PDP that enables the transport of IPv4 and IPv6 packets within a single
context between the UE and the gateway. PDP 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 ability to fall back to IPv4. 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 current widely used applications and solutions for their
are widely used, for their ability to operate over IPv6 PDN ability to operate over IPv6 PDN connections, an IPv6-only access
connections, an IPv6-only access would cause disruptions. would cause disruptions.
12. Acknowledgements 11. Acknowledgements
The authors thank Shabnam Sultana, Sri Gundavelli, Hui Deng, The authors thank Shabnam Sultana, Sri Gundavelli, Hui Deng,
Zhenqiang Li, Mikael Abrahamsson, James Woodyatt, Wes George, Martin Zhenqiang Li, Mikael Abrahamsson, James Woodyatt, Wes George, Martin
Thomson, Russ Mundy, Cameron Byrne, Ales Vizdal, Frank Brockners, Thomson, Russ Mundy, Cameron Byrne, Ales Vizdal, Frank Brockners,
Adrian Farrel, Stephen Farrell, and Jari Arkko for their reviews and Adrian Farrel, Stephen Farrell, Paco Cortes, and Jari Arkko for their
comments on this document. reviews and comments on this document.
13. Informative References 12. 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] [PD-EXCLUDE] Korhonen, J., Ed., Savolainen, T., Krishnan, S., and O.
Korhonen, J., Savolainen, T., Krishnan, S., and O. Troan, Troan, "Prefix Exclude Option for DHCPv6-based Prefix
"Prefix Exclude Option for DHCPv6-based Prefix Delegation", Work in Progress, December 2011.
Delegation", draft-ietf-dhc-pd-exclude-03 (work in
progress), August 2011.
[RFC1918] Rekhter, Y., Moskowitz, R., Karrenberg, D., Groot, G., and [RFC1918] Rekhter, Y., Moskowitz, B., Karrenberg, D., de Groot,
E. Lear, "Address Allocation for Private Internets", G., and E. Lear, "Address Allocation for Private
BCP 5, RFC 1918, February 1996. Internets", 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., Ed., Bound, J., Volz, B., Lemon, T.,
and M. Carney, "Dynamic Host Configuration Protocol for Perkins, C., and M. Carney, "Dynamic Host Configuration
IPv6 (DHCPv6)", RFC 3315, July 2003. Protocol for IPv6 (DHCPv6)", RFC 3315, July 2003.
[RFC3316] Arkko, J., Kuijpers, G., Soliman, H., Loughney, J., and J. [RFC3316] Arkko, J., Kuijpers, G., Soliman, H., Loughney, J., and
Wiljakka, "Internet Protocol Version 6 (IPv6) for Some J. Wiljakka, "Internet Protocol Version 6 (IPv6) for
Second and Third Generation Cellular Hosts", RFC 3316, Some Second and Third Generation Cellular Hosts",
April 2003. RFC 3316, April 2003.
[RFC3633] Troan, O. and R. Droms, "IPv6 Prefix Options for Dynamic [RFC3633] Troan, O. and R. Droms, "IPv6 Prefix Options for
Host Configuration Protocol (DHCP) version 6", RFC 3633, Dynamic Host Configuration Protocol (DHCP) version 6",
December 2003. RFC 3633, December 2003.
[RFC3736] Droms, R., "Stateless Dynamic Host Configuration Protocol [RFC3736] Droms, R., "Stateless Dynamic Host Configuration
(DHCP) Service for IPv6", RFC 3736, April 2004. Protocol (DHCP) Service for IPv6", RFC 3736,
April 2004.
[RFC4389] Thaler, D., Talwar, M., and C. Patel, "Neighbor Discovery [RFC4389] Thaler, D., Talwar, M., and C. Patel, "Neighbor
Proxies (ND Proxy)", RFC 4389, April 2006. Discovery Proxies (ND Proxy)", RFC 4389, April 2006.
[RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman, [RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman,
"Neighbor Discovery for IP version 6 (IPv6)", RFC 4861, "Neighbor Discovery for IP version 6 (IPv6)", RFC 4861,
September 2007. September 2007.
[RFC4862] Thomson, S., Narten, T., and T. Jinmei, "IPv6 Stateless [RFC4862] Thomson, S., Narten, T., and T. Jinmei, "IPv6 Stateless
Address Autoconfiguration", RFC 4862, September 2007. Address Autoconfiguration", RFC 4862, September 2007.
[RFC4941] Narten, T., Draves, R., and S. Krishnan, "Privacy [RFC4941] Narten, T., Draves, R., and S. Krishnan, "Privacy
Extensions for Stateless Address Autoconfiguration in Extensions for Stateless Address Autoconfiguration in
IPv6", RFC 4941, September 2007. IPv6", RFC 4941, September 2007.
[RFC5213] Gundavelli, S., Leung, K., Devarapalli, V., Chowdhury, K., [RFC5213] Gundavelli, S., Ed., Leung, K., Devarapalli, V.,
and B. Patil, "Proxy Mobile IPv6", RFC 5213, August 2008. Chowdhury, K., and B. Patil, "Proxy Mobile IPv6",
RFC 5213, August 2008.
[RFC6144] Baker, F., Li, X., Bao, C., and K. Yin, "Framework for [RFC6144] Baker, F., Li, X., Bao, C., and K. Yin, "Framework for
IPv4/IPv6 Translation", RFC 6144, April 2011. IPv4/IPv6 Translation", RFC 6144, April 2011.
[TR.23975] [TR.23975] 3GPP, "IPv6 Migration Guidelines", 3GPP
3GPP, "IPv6 Migration Guidelines", 3GPP TR 23.975 1.1.1, TR 23.975 11.0.0, June 2011.
June 2010.
[TS.23003] [TS.23003] 3GPP, "Numbering, addressing and identification", 3GPP
3GPP, "Numbering, addressing and identification", 3GPP TS 23.003 10.3.0, September 2011.
TS 23.003 10.2.0, June 2011.
[TS.23060] [TS.23060] 3GPP, "General Packet Radio Service (GPRS); Service
3GPP, "General Packet Radio Service (GPRS); Service description; Stage 2", 3GPP TS 23.060 8.14.0,
description; Stage 2", 3GPP TS 23.060 8.8.0, March 2010. September 2011.
[TS.23203] [TS.23203] 3GPP, "Policy and charging control architecture", 3GPP
3GPP, "Policy and charging control architecture (PCC)", TS 23.203 8.12.0, June 2011.
3GPP TS 23.203 8.11.0, September 2010.
[TS.23401] [TS.23401] 3GPP, "General Packet Radio Service (GPRS) enhancements
3GPP, "General Packet Radio Service (GPRS) enhancements for Evolved Universal Terrestrial Radio Access Network
for Evolved Universal Terrestrial Radio Access Network (E-UTRAN) access", 3GPP TS 23.401 10.5.0,
(E-UTRAN) access", 3GPP TS 23.401 10.4.0, June 2011. September 2011.
[TS.23402] [TS.23402] 3GPP, "Architecture enhancements for non-3GPP
3GPP, "Architecture enhancements for non-3GPP accesses", accesses", 3GPP TS 23.402 10.5.0, September 2011.
3GPP TS 23.402 10.5.0, September 2011.
[TS.24008] [TS.24008] 3GPP, "Mobile radio interface Layer 3 specification;
3GPP, "Mobile radio interface Layer 3 specification", 3GPP Core network protocols; Stage 3", 3GPP
TS 24.008 8.12.0, December 2010. TS 24.008 8.14.0, June 2011.
[TS.24301] [TS.24301] 3GPP, "Non-Access-Stratum (NAS) protocol for Evolved
3GPP, "Non-Access-Stratum (NAS) protocol for Evolved Packet System (EPS); Stage 3", 3GPP TS 24.301 8.10.0,
Packet System (EPS)", 3GPP TS 24.301 8.8.0, December 2010. June 2011.
[TS.29002] [TS.29002] 3GPP, "Mobile Application Part (MAP) specification",
3GPP, "Mobile Application Part (MAP) specification", 3GPP 3GPP TS 29.002 9.6.0, September 2011.
TS 29.002 9.5.0, June 2011.
[TS.29060] [TS.29060] 3GPP, "General Packet Radio Service (GPRS); GPRS
3GPP, "General Packet Radio Service (GPRS); GPRS Tunnelling Protocol (GTP) across the Gn and Gp
Tunnelling Protocol (GTP) across the Gn and Gp interface", interface", 3GPP TS 29.060 8.15.0, September 2011.
3GPP TS 29.274 8.8.0, April 2010.
[TS.29061] [TS.29061] 3GPP, "Interworking between the Public Land Mobile
3GPP, "Interworking between the Public Land Mobile Network Network (PLMN) supporting packet based services and
(PLMN) supporting packet based services and Packet Data Packet Data Networks (PDN)", 3GPP TS 29.061 8.8.0,
Networks (PDN)", 3GPP TS 29.061 8.5.0, April 2010. September 2011.
[TS.29274] [TS.29274] 3GPP, "3GPP Evolved Packet System (EPS); Evolved
3GPP, "3GPP Evolved Packet System (EPS); Evolved General General Packet Radio Service (GPRS) Tunnelling
Packet Radio Service (GPRS) Tunnelling Protocol for Protocol for Control plane (GTPv2-C); Stage 3", 3GPP
Control plane (GTPv2-C)", 3GPP TS 29.060 8.11.0, TS 29.274 8.10.0, June 2011.
December 2010.
[TS.33102] [TS.29281] 3GPP, "General Packet Radio System (GPRS) Tunnelling
3GPP, "3G Security; Security architecture", 3GPP Protocol User Plane (GTPv1-U)", 3GPP TS 29.281 10.3.0,
TS 33.102 10.0.0, December 2010. September 2011.
[TS.33401] [TS.33102] 3GPP, "3G security; Security architecture", 3GPP
3GPP, "3GPP System Architecture Evolution (SAE); Security TS 33.102 10.0.0, December 2010.
architecture", 3GPP TS 33.401 10.1.1, June 2011.
[TS.33401] 3GPP, "3GPP System Architecture Evolution (SAE);
Security architecture", 3GPP TS 33.401 10.2.0,
September 2011.
Authors' Addresses Authors' Addresses
Jouni Korhonen (editor) Jouni Korhonen (editor)
Nokia Siemens Networks Nokia Siemens Networks
Linnoitustie 6 Linnoitustie 6
FI-02600 Espoo FI-02600 Espoo
FINLAND FINLAND
Email: jouni.nospam@gmail.com EMail: jouni.nospam@gmail.com
Jonne Soininen Jonne Soininen
Renesas Mobile Renesas Mobile
Porkkalankatu 24 Porkkalankatu 24
FI-00180 Helsinki FI-00180 Helsinki
FINLAND FINLAND
Email: jonne.soininen@renesasmobile.com EMail: jonne.soininen@renesasmobile.com
Basavaraj Patil Basavaraj Patil
Nokia Nokia
6021 Connection drive 6021 Connection Drive
Irving, TX 75039 Irving, TX 75039
USA USA
Email: basavaraj.patil@nokia.com EMail: basavaraj.patil@nokia.com
Teemu Savolainen Teemu Savolainen
Nokia Nokia
Hermiankatu 12 D Hermiankatu 12 D
FI-33720 Tampere FI-33720 Tampere
FINLAND FINLAND
Email: teemu.savolainen@nokia.com EMail: teemu.savolainen@nokia.com
Gabor Bajko Gabor Bajko
Nokia Nokia
323 Fairchild drive 6 323 Fairchild Drive 6
Mountain view, CA 94043 Mountain View, CA 94043
USA USA
Email: gabor.bajko@nokia.com EMail: gabor.bajko@nokia.com
Kaisu Iisakkila Kaisu Iisakkila
Renesas Mobile Renesas Mobile
Porkkalankatu 24 Porkkalankatu 24
FI-00180 Helsinki FI-00180 Helsinki
FINLAND FINLAND
Email: kaisu.iisakkila@renesasmobile.com EMail: kaisu.iisakkila@renesasmobile.com
 End of changes. 258 change blocks. 
931 lines changed or deleted 954 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/