draft-ietf-v6ops-3gpp-eps-01.txt   draft-ietf-v6ops-3gpp-eps-02.txt 
Individual Submission J. Korhonen, Ed. Individual Submission J. Korhonen, Ed.
Internet-Draft Nokia Siemens Networks Internet-Draft Nokia Siemens Networks
Intended status: Informational J. Soininen Intended status: Informational J. Soininen
Expires: November 3, 2011 Renesas Mobile Expires: January 7, 2012 Renesas Mobile
B. Patil B. Patil
T. Savolainen T. Savolainen
G. Bajko G. Bajko
Nokia Nokia
K. Iisakkila K. Iisakkila
Renesas Mobile Renesas Mobile
May 2, 2011 July 6, 2011
IPv6 in 3GPP Evolved Packet System IPv6 in 3GPP Evolved Packet System
draft-ietf-v6ops-3gpp-eps-01 draft-ietf-v6ops-3gpp-eps-02
Abstract Abstract
Internet connectivity and use of data services in 3GPP based mobile Use of data services in smart phones and broadband services via HSPA
networks has increased rapidly as a result of smart phones, broadband and HSPA+, in particular Internet services, has increased rapidly and
service via HSPA and HSPA+ networks, competitive service offerings by operators that have deployed networks based on 3GPP network
operators and a large number of applications. Operators who have architectures are facing IPv4 address shortages at the Internet
deployed networks based on 3GPP architectures are facing IPv4 address registries and are feeling a pressure to migrate to IPv6. This
shortages. With the impending exhaustion of available IPv4 addresses document describes the support for IPv6 in 3GPP network
from the registries there is an increased emphasis for operators to architectures.
migrate to IPv6. This document describes the support for IPv6 in
3GPP network architectures.
Status of this Memo Status of this Memo
This Internet-Draft is submitted in full conformance with the This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on November 3, 2011. This Internet-Draft will expire on January 7, 2012.
Copyright Notice Copyright Notice
Copyright (c) 2011 IETF Trust and the persons identified as the Copyright (c) 2011 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
skipping to change at page 3, line 10 skipping to change at page 2, line 20
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
2. 3GPP Terminology and Concepts . . . . . . . . . . . . . . . . 5 2. 3GPP Terminology and Concepts . . . . . . . . . . . . . . . . 5
2.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 5 2.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 5
2.2. The concept of APN . . . . . . . . . . . . . . . . . . . . 8 2.2. The concept of APN . . . . . . . . . . . . . . . . . . . . 9
3. IP over 3GPP GPRS . . . . . . . . . . . . . . . . . . . . . . 9 3. IP over 3GPP GPRS . . . . . . . . . . . . . . . . . . . . . . 10
3.1. Introduction to 3GPP GPRS . . . . . . . . . . . . . . . . 9 3.1. Introduction to 3GPP GPRS . . . . . . . . . . . . . . . . 10
3.2. PDP Context . . . . . . . . . . . . . . . . . . . . . . . 10 3.2. PDP Context . . . . . . . . . . . . . . . . . . . . . . . 12
4. IP over 3GPP EPS . . . . . . . . . . . . . . . . . . . . . . . 11 4. IP over 3GPP EPS . . . . . . . . . . . . . . . . . . . . . . . 12
4.1. Introduction to 3GPP EPS . . . . . . . . . . . . . . . . . 11 4.1. Introduction to 3GPP EPS . . . . . . . . . . . . . . . . . 13
4.2. PDN Connection . . . . . . . . . . . . . . . . . . . . . . 12 4.2. PDN Connection . . . . . . . . . . . . . . . . . . . . . . 14
4.3. EPS bearer model . . . . . . . . . . . . . . . . . . . . . 13 4.3. EPS bearer model . . . . . . . . . . . . . . . . . . . . . 14
5. Address Management . . . . . . . . . . . . . . . . . . . . . . 13 5. Address Management . . . . . . . . . . . . . . . . . . . . . . 15
5.1. IPv4 Address Configuration . . . . . . . . . . . . . . . . 14 5.1. IPv4 Address Configuration . . . . . . . . . . . . . . . . 15
5.2. IPv6 Address Configuration . . . . . . . . . . . . . . . . 14 5.2. IPv6 Address Configuration . . . . . . . . . . . . . . . . 15
5.3. Prefix Delegation . . . . . . . . . . . . . . . . . . . . 15 5.3. Prefix Delegation . . . . . . . . . . . . . . . . . . . . 16
5.4. IPv6 Neighbor Discovery Considerations . . . . . . . . . . 15 5.4. IPv6 Neighbor Discovery Considerations . . . . . . . . . . 16
6. 3GPP Dual-Stack Approach to IPv6 . . . . . . . . . . . . . . . 16 6. 3GPP Dual-Stack Approach to IPv6 . . . . . . . . . . . . . . . 17
6.1. 3GPP Networks Prior to Release-8 . . . . . . . . . . . . . 16 6.1. 3GPP Networks Prior to Release-8 . . . . . . . . . . . . . 17
6.2. 3GPP Release-8 and -9 Networks . . . . . . . . . . . . . . 17 6.2. 3GPP Release-8 and -9 Networks . . . . . . . . . . . . . . 18
6.3. PDN Connection Establishment Process . . . . . . . . . . . 18 6.3. PDN Connection Establishment Process . . . . . . . . . . . 19
6.4. Mobility of 3GPP IPv4v6 Type of Bearers . . . . . . . . . 21 6.4. Mobility of 3GPP IPv4v6 Type of Bearers . . . . . . . . . 22
7. Dual-Stack Approach to IPv6 Transition in 3GPP Networks . . . 21 7. Dual-Stack Approach to IPv6 Transition in 3GPP Networks . . . 22
8. Deployment issues . . . . . . . . . . . . . . . . . . . . . . 22 8. Deployment issues . . . . . . . . . . . . . . . . . . . . . . 23
8.1. Overlapping IPv4 Addresses . . . . . . . . . . . . . . . . 22 8.1. Overlapping IPv4 Addresses . . . . . . . . . . . . . . . . 23
8.2. IPv6 for transport . . . . . . . . . . . . . . . . . . . . 23 8.2. IPv6 for transport . . . . . . . . . . . . . . . . . . . . 24
8.3. Operational Aspects of Running Dual-Stack Networks . . . . 24 8.3. Operational Aspects of Running Dual-Stack Networks . . . . 25
8.4. Operational Aspects of Running a Network with IPv6 8.4. Operational Aspects of Running a Network with
Only Bearers . . . . . . . . . . . . . . . . . . . . . . . 24 IPv6-only Bearers . . . . . . . . . . . . . . . . . . . . 25
8.5. Restricting Outbound IPv6 Roaming . . . . . . . . . . . . 25 8.5. Restricting Outbound IPv6 Roaming . . . . . . . . . . . . 26
8.6. Inter-rat Handovers and IP Versions . . . . . . . . . . . 26 8.6. Inter-RAT Handovers and IP Versions . . . . . . . . . . . 27
8.7. Provisioning of IPv6 Subscribers and Various 8.7. Provisioning of IPv6 Subscribers and Various
Combinations During Initial Network Attachment . . . . . . 27 Combinations During Initial Network Attachment . . . . . . 28
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 28 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 30
10. Security Considerations . . . . . . . . . . . . . . . . . . . 28 10. Security Considerations . . . . . . . . . . . . . . . . . . . 30
11. Summary and Conclusion . . . . . . . . . . . . . . . . . . . . 28 11. Summary and Conclusion . . . . . . . . . . . . . . . . . . . . 30
12. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 29 12. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 30
13. Informative References . . . . . . . . . . . . . . . . . . . . 29 13. Informative References . . . . . . . . . . . . . . . . . . . . 30
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 31 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 32
1. Introduction 1. Introduction
IPv6 has been specified in the 3rd Generation Partnership Project IPv6 has been specified in the 3rd Generation Partnership Project
(3GPP) standards since the early architectures developed for R99 (3GPP) standards since the early architectures developed for R99
General Packet Radio Service (GPRS). However, the support for IPv6 General Packet Radio Service (GPRS). However, the support for IPv6
in commercially deployed networks by the end of 2010 is nearly non- in commercially deployed networks remains low. There are many
existent. There are many factors that can be attributed to the lack factors that can be attributed to the lack of IPv6 deployment in 3GPP
of IPv6 deployment in 3GPP networks. The most relevant one is networks. The most relevant one is essentially the same as the
essentially the same as the reason for IPv6 not being deployed by reason for IPv6 not being deployed by other networks as well, i.e.
other networks as well, i.e. the lack of business and commercial the lack of business and commercial incentives for deployment. 3GPP
incentives for deployment. 3GPP network architectures have also network architectures have also evolved since 1999 (since R99). The
evolved since 1999 (since R99). The most recent version of the 3GPP most recent version of the 3GPP architecture, the Evolved Packet
architecture, the Evolved Packet System (EPS), which is commonly System (EPS), which is commonly referred to as SAE, LTE or Release-8,
referred to as SAE, LTE or Release-8, is a packet centric is a packet centric architecture. The number of subscribers and
architecture. The number of subscribers and devices that are using devices that are using the 3GPP networks for Internet connectivity
the 3GPP networks for Internet connectivity and data services has and data services has also increased significantly. With the
also increased significantly. With the subscriber growth numbers subscriber growth numbers projected to increase even further and the
projected to increase even further and the IPv4 addresses depletion IPv4 addresses depletion problem looming in the near term, 3GPP
problem looming in the near term, 3GPP operators and vendors have operators and vendors have started the process of identifying the
started the process of identifying the scenarios and solutions needed scenarios and solutions needed to transition to IPv6.
to transition to 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 3GPP GPRS and for 3GPP EPS. It provides an overview of how IPv6 is
supported as per the current set of 3GPP specifications. Some of the supported as per the current set of 3GPP specifications. Some of the
issues and concerns with respect to deployment and shortage of issues and concerns with respect to deployment and shortage of
private IPv4 addresses within a single network domain are also private IPv4 addresses within a single network domain are also
discussed. 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 phase, the two
alternative categories for the transition are encapsulation and alternative categories for the transition are encapsulation and
translation. Most of the mechanisms available in the toolbox can be translation. The IETF continues to specify additional solutions for
categorized into either translation or encapsulation approaches. The enabling the transition based on the deployment scenarios and
IETF continues to specify additional solutions for enabling the operator/ISP requirements. There is no single approach for
transition based on the deployment scenarios and operator/ISP transition to IPv6 that can meet the needs for all deployments and
requirements. There is no single approach for transition to IPv6 models. The 3GPP scenarios for transition, described in [TR.23975],
that can meet the needs for all deployments and models. The 3GPP can be addressed using transition mechanisms that are already
scenarios for transition, described in [3GPP.23.975], can be available in the toolbox. The objective of transition to IPv6 in
addressed using transition mechanisms that are already available in 3GPP networks is to ensure that:
the toolbox. The objective of transition to IPv6 in 3GPP networks is
to ensure that:
1. Legacy devices and hosts which have an IPv4 only stack will 1. Legacy devices and hosts which 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 which 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,
skipping to change at page 5, line 29 skipping to change at page 5, line 26
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 Access Point Name (APN) is a fully qualified domain name and
resolves to a specific gateway in an operators network. The APNs resolves to a specific gateway in an operators network. The APNs
are piggybacked on the administration of the DNS namespace. are piggybacked on the administration of the DNS namespace.
Packet Data Protocol Context Dual Address PDN/PDP Type
A Packet Data Protocol (PDP) Context is the equivalent of a The Dual Address PDN/PDP Type (IPv4v6) is used in 3GPP context in
virtual connection between the host and a gateway. many cases as a synonym for dual-stack i.e. a connection type
capable of serving both IPv4 and IPv6 simultaneously.
Evolved Packet Core
Evolved Packet Core (EPC) is an evolution of the 3GPP GPRS system
characterized by higher-data-rate, lower-latency, packet-optimized
system. EPC comprises of subcomponents such as Mobility
Management Entity (MME), Serving Gateway (SGW), Packet Data
Network Gateway (PDN-GW) and Home Subscriber Server (HSS).
Evolved Packet System
Evolved Packet System (EPS) is an evolution of the 3GPP GPRS
system characterized by higher-data-rate, lower-latency, packet-
optimized system that supports multiple Radio Access Technologies
(RAT). The EPS comprises the Evolved Packet Core (EPC) together
with the evolved radio access network (E-UTRA and E-UTRAN).
Evolved UTRAN
Evolved UTRAN (E-UTRAN) is communications network, sometimes
referred to as 4G, and consists of eNodeBs (4G base station) which
make up the E-UTRAN radio access network. The E-UTRAN allows
connectivity between the mobile host/device and the core network.
GPRS tunnelling protocol
GPRS Tunnelling Protocol (GTP) [TS.29060] [TS.29274] is a
tunnelling protocol defined by 3GPP. It is a network based
mobility protocol and similar to Proxy Mobile IPv6 (PMIPv6)
[RFC5213]. However, GTP also provides functionality beyond
mobility such as inband signaling related to Quality of Service
(QoS) and charging among others.
GSM EDGE Radio Access Network
GSM EDGE Radio Access Network (GERAN) is communications network,
commonly referred to as 2G or 2.5G, and consists of base stations
and Base Station Controllers (BSC) which make up the GSM EDGE
radio access network. The GERAN allows connectivity between the
mobile host/device and the core network.
Gateway GPRS Support Node
Gateway GPRS Support Node (GGSN) is a gateway function in GPRS,
which provides connectivity to Internet or other PDNs. The host
attaches to a GGSN identified by an APN assigned to it by an
operator. The GGSN also serves as the topological anchor for
addresses/prefixes assigned to the mobile host.
General Packet Radio Service General Packet Radio Service
General Packet Radio Service (GPRS) is a packet oriented mobile General Packet Radio Service (GPRS) is a packet oriented mobile
data service available to users of the 2G and 3G cellular data service available to users of the 2G and 3G cellular
communication systems Global System for Mobile communications communication systems Global System for Mobile communications
(GSM), and specified by 3GPP. (GSM), and specified by 3GPP.
High Speed Packet Access
The High Speed Packet Access (HSPA) and the Evolved High Speed
Packet Access (HSPA+) are enhanced versions of the WCDMA and
UTRAN, thus providing more data throughput and lower latencies.
Home Location Register
The Home Location Register (HLR) is a pre-Release-5 database (but
is also used in Release-5 and later networks in real deployments)
that contains subscriber data and call routing related
information. Every subscriber of an operator including
subscribers' enabled services are provisioned in the HLR.
Home Subscriber Server
The Home Subscriber Server (HSS) is a database for a given
subscriber and got introduced in 3GPP Release-5. It is the entity
containing the subscription-related information to support the
network entities actually handling calls/sessions.
Mobility Management Entity
Mobility Management Entity (MME) is a network element that is
responsible for control plane functionalities, including
authentication, authorization, bearer management, layer-2
mobility, etc. The MME is essentially the control plane part of
the SGSN in GPRS. The user plane traffic bypasses the MME.
Mobile Terminal
The Mobile Terminal (MT) is the modem and the radio part of the
Mobile Station (MS).
Public Land Mobile Network
The Public Land Mobile Network (PLMN) is a network that is
operated by a single administration. A PLMN (and therefore also
an operator) is identified by the Mobile Country Code (MCC) and
the Mobile Network Code (MNC). Each (telecommunications) operator
providing mobile services has its own PLMN.
Policy and Charging Control
The Policy and Charging Control (PCC) framework is used for QoS
policy and charging control. It has two main functions: flow
based charging including online credit control, and policy control
(e.g. gating control, QoS control and QoS signaling). It is
optional to 3GPP EPS but needed if dynamic policy and charging
control by means of PCC rules based on user and services are
desired.
Packet Data Network Packet Data Network
Packet Data Network (PDN) is a packet based network that either Packet Data Network (PDN) is a packet based network that either
belongs to the operator or is an external network such as Internet belongs to the operator or is an external network such as Internet
and corporate intranet. The user eventually accesses services in and corporate intranet. The user eventually accesses services in
one or more PDNs. The operator's packet domain network are one or more PDNs. The operator's packet core network are
separated from packet data networks either by GGSNs or PDN separated from packet data networks either by GGSNs or PDN
Gateways (PDN-GW). Gateways (PDN-GW).
Gateway GPRS Support Node
Gateway GPRS Support Node (GGSN) is a gateway function in GPRS,
which provides connectivity to Internet or other PDNs. The host
attaches to a GGSN identified by an APN assigned to it by an
operator. The GGSN also serves as the topological anchor for
addresses/prefixes assigned to the mobile host.
Packet Data Network Gateway Packet Data Network Gateway
Packet Data Network Gateway (PDN-GW) is a gateway function in Packet Data Network Gateway (PDN-GW) is a gateway function in
Evolved Packet System (EPS), which provides connectivity to Evolved Packet System (EPS), which provides connectivity to
Internet or other PDNs. The host attaches to a PDN-GW identified Internet or other PDNs. The host attaches to a PDN-GW identified
by an APN assigned to it by an operator. The PDN-GW also serves by an APN assigned to it by an operator. The PDN-GW also serves
as the topological anchor for addresses/prefixes assigned to the as the topological anchor for addresses/prefixes assigned to the
mobile host. mobile host.
Packet Data Protocol Context
A Packet Data Protocol (PDP) Context is the equivalent of a
virtual connection between the host and a gateway.
S4 Serving Gateway Support Node
S4 Serving Gateway Support Node (S4-SGSN) is a Release-8 (and
onwards) compliant SGSN that connects 2G/3G radio access network
to EPC via new Release-8 interfaces like S3, S4, and S6d.
Serving Gateway Serving Gateway
Serving Gateway (SGW) is a gateway function in EPS, which Serving Gateway (SGW) is a gateway function in EPS, which
terminates the interface towards E-UTRAN. The SGW is the Mobility terminates the interface towards E-UTRAN. The SGW is the Mobility
Anchor point for layer-2 mobility (inter-eNodeB handovers). For Anchor point for layer-2 mobility (inter-eNodeB handovers). For
each User Equipment connected with the EPS, at any given point of each User Equipment connected with the EPS, at any given point of
time, there is only one SGW. The SGW is essentially the user time, there is only one SGW. The SGW is essentially the user
plane part of the GPRS' SGSN forwarding packets between a PDN-GW. plane part of the GPRS' SGSN forwarding packets between a PDN-GW.
Serving Gateway Support Node Serving Gateway Support Node
Serving Gateway Support Node (SGSN) is a network element that is Serving Gateway Support Node (SGSN) is a network element that is
located between the radio access network (RAN) and the gateway located between the radio access network (RAN) and the gateway
(GGSN). A per mobile host point to point (p2p) tunnel between the (GGSN). A per mobile host point to point (p2p) tunnel between the
GGSN and SGSN transports the packets between the mobile host and GGSN and SGSN transports the packets between the mobile host and
the gateway. the gateway.
GPRS tunnelling protocol Terminal Equipment
GPRS Tunnelling Protocol (GTP) [3GPP.29.060] [3GPP.29.274] is a
tunnelling protocol defined by 3GPP. It is a network based
mobility protocol and similar to Proxy Mobile IPv6 (PMIPv6)
[RFC5213]. However, GTP also provides functionality beyond
mobility such as inband signaling related to Quality of Service
(QoS) and charging among others.
Evolved Packet System
Evolved Packet System (EPS) is an evolution of the 3GPP GPRS The Terminal Equipment (TE) is any device/host connected to the
system characterized by higher-data-rate, lower-latency, packet- Mobile Terminal (MT) offering services to the use. A TE may
optimized system that supports multiple Radio Access Technologies communicate to a MT, for example, over Point to Point Protocol
(RAT). The EPS comprises the Evolved Packet Core (EPC) together (PPP).
with the evolved radio access network (E-UTRA and E-UTRAN).
Mobility Management Entity UE, MS, MN and Mobile
Mobility Management Entity (MME) is a network element that is The terms UE (User Equipment), MS (Mobile Station), MN (Mobile
responsible for control plane functionalities, including Node) and, mobile refer to the devices which are hosts with
authentication, authorization, bearer management, layer-2 ability to obtain Internet connectivity via a 3GPP network. A MS
mobility, etc. The MME is essentially the control plane part of comprises of a Terminal Equipment (TE) and a Mobile Terminal (MT).
the GPRS' SGSN and not located on the user plane data path, i.e. The terms UE, MS, MN and devices are used interchangeably within
user plane traffic bypasses the MME. this document.
UMTS Terrestrial Radio Access Network UMTS Terrestrial Radio Access Network
UMTS Terrestrial Radio Access Network (UTRAN) is communications UMTS Terrestrial Radio Access Network (UTRAN) is communications
network, commonly referred to as 3G, and consists of NodeBs (3G network, commonly referred to as 3G, and consists of NodeBs (3G
base station) and Radio Network Controllers (RNC) which make up base station) and Radio Network Controllers (RNC) which make up
the UMTS radio access network. The UTRAN allows connectivity the UMTS radio access network. The UTRAN allows connectivity
between the mobile host/device and the core network. UTRAN between the mobile host/device and the core network. UTRAN
comprises of WCDMA, HSPA and HSPA+ radio technologies. comprises of WCDMA, HSPA and HSPA+ radio technologies.
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.
High Speed Packet Access
The High Speed Packet Access (HSPA) and the Evolved High Speed
Packet Access (HSPA+) are enhanced versions of the WCDMA and
UTRAN, thus providing more data throughput and lower latencies.
Evolved UTRAN
Evolved UTRAN (E-UTRAN) is communications network, sometimes
referred to as 4G, and consists of eNodeBs (4G base station) which
make up the E-UTRAN radio access network. The E-UTRAN allows
connectivity between the mobile host/device and the core network.
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.
GSM EDGE Radio Access Network
GSM EDGE Radio Access Network (GERAN) is communications network,
commonly referred to as 2G or 2.5G, and consists of base stations
and Base Station Controllers (BSC) which make up the GSM EDGE
radio access network. The GERAN allows connectivity between the
mobile host/device and the core network.
UE, MS, MN and Mobile
The terms UE (User Equipment), MS (Mobile Station), MN (Mobile
Node) and, mobile refer to the devices which are hosts with
ability to obtain Internet connectivity via a 3GPP network. The
terms UE, MS, MN and devices are used interchangeably within this
document.
PCC
The Policy and Charging Control (PCC) framework is used for QoS
policy and charging control. It is optional for 3GPP EPS but
needed if dynamic policy and charging control by means of PCC
rules based on user and services are desired.
HLR
The Home Location Register (HLR) is a pre-Release-5 database (the
reality regarding releases is different, though) for a given
subscriber. It is the entity containing the subscription-related
information to support the network entities actually handling
calls/sessions.
HSS
The Home Subscriber Server (HSS) is a database for a given
subscriber and got introduced in 3GPP Release-5. It is the entity
containing the subscription-related information to support the
network entities actually handling calls/sessions.
2.2. The concept of APN 2.2. The concept of APN
The Access Point Name (APN) essentially refers to a gateway in the The Access Point Name (APN) essentially refers to a gateway in the
3GPP network. The 'complete' APN is expressed in a form of a Fully 3GPP network. The 'complete' APN is expressed in a form of a Fully
Qualified Domain Name (FQDN) and also piggybacked on the Qualified Domain Name (FQDN) and also piggybacked on the
administration of the DNS namespace, thus effectively allowing the administration of the DNS namespace, thus effectively allowing the
discovery of gateways using the DNS. Mobile hosts/devices can choose discovery of gateways using the DNS. Mobile hosts/devices can choose
to attach to a specific gateway in the packet core. The gateway to attach to a specific gateway in the packet core. The gateway
provides connectivity to the Packet Data Network (PDN) such as the provides connectivity to the Packet Data Network (PDN) such as the
Internet. An operator may also include gateways which do not provide Internet. An operator may also include gateways which do not provide
skipping to change at page 9, line 30 skipping to change at page 10, line 31
Figure 1: Mobile host/device attached to multiple APNs simultaneously Figure 1: Mobile host/device attached to multiple APNs simultaneously
3. IP over 3GPP GPRS 3. IP over 3GPP GPRS
3.1. Introduction to 3GPP GPRS 3.1. Introduction to 3GPP GPRS
A simplified 2G/3G GPRS architecture is illustrated in Figure 2. A simplified 2G/3G GPRS architecture is illustrated in Figure 2.
This architecture basically covers the GPRS core network since R99 to This architecture basically covers the GPRS core network since R99 to
Release-7, and radio access technologies such as GSM (2G), EDGE (2G, Release-7, and radio access technologies such as GSM (2G), EDGE (2G,
ofter referred as 2.5G), WCDMA (3G) and HSPA(+) (3G, often referred often referred as 2.5G), WCDMA (3G) and HSPA(+) (3G, often referred
as 3.5G). The architecture shares obvious similarities with the as 3.5G). The architecture shares obvious similarities with the
Evolved Packet System (EPS) as will be seen in Section 4. Based on Evolved Packet System (EPS) as will be seen in Section 4. Based on
Gn/Gp interfaces, the GPRS core network functionality is logically Gn/Gp interfaces, the GPRS core network functionality is logically
implemented on two network nodes, the SGSN and the GGSN. implemented on two network nodes, the SGSN and the GGSN.
3G .--. 3G .--.
Uu +-----+ Iu +----+ +----+ _( `. Uu +-----+ Iu +----+ +----+ _( `.
[TE]+[MT]~~|~~~|UTRAN|--|---|SGSN|--|---|GGSN|--|----( PDN ) [TE]+[MT]~~|~~~|UTRAN|--|---|SGSN|--|---|GGSN|--|----( PDN )
+-----+ +----+ Gn +----+ Gi ( ` . ) ) +-----+ +----+ Gn +----+ Gi ( ` . ) )
/ | `--(___.-' / | `--(___.-'
skipping to change at page 14, line 38 skipping to change at page 16, line 6
using this Interface Identifier. The UE is allowed to use any using this Interface Identifier. The UE is allowed to use any
Interface Identifier it wishes for the other addresses it configures. Interface Identifier it wishes for the other addresses it configures.
There is no restriction, for example, of using Privacy Extension for There is no restriction, for example, of using Privacy Extension for
SLAAC [RFC4941] or other similar types of mechanisms. SLAAC [RFC4941] or other similar types of mechanisms.
In the 3GPP link model the /64 prefix assigned to the UE is always In the 3GPP link model the /64 prefix assigned to the UE is always
off-link (i.e. the L-bit in the Prefix Information Option (PIO) in off-link (i.e. the L-bit in the Prefix Information Option (PIO) in
the RA must be set to zero). If the advertised prefix is used for the RA must be set to zero). If the advertised prefix is used for
SLAAC then the A-bit in the PIO must be set to one. The details of SLAAC then the A-bit in the PIO must be set to one. The details of
the 3GPP link-model and address configuration is described in Section the 3GPP link-model and address configuration is described in Section
11.2.1.3.2a of [3GPP.29.061]. More specifically, the GGSN/PDN-GW 11.2.1.3.2a of [TS.29061]. More specifically, the GGSN/PDN-GW
guarantees that the /64 prefix is unique for the mobile host. guarantees that the /64 prefix is unique for the mobile host.
Therefore, there is no need to perform any Duplicate Address Therefore, there is no need to perform any Duplicate Address
Detection (DAD) on addresses the mobile host creates (i.e., the Detection (DAD) on addresses the mobile host creates (i.e., the
'DupAddrDetectTransmits' variable in the mobile host should be zero). 'DupAddrDetectTransmits' variable in the mobile host should be zero).
The GGSN/PDN-GW is not allowed to generate any globally unique IPv6 The GGSN/PDN-GW is not allowed to generate any globally unique IPv6
addresses for itself using the /64 prefix assigned to the mobile host addresses for itself using the /64 prefix assigned to the mobile host
in the RA. in the RA.
The current 3GPP architecture limits number of prefixes in each The current 3GPP architecture limits number of prefixes in each
bearer to a single /64 prefix. If the mobile host finds more than bearer to a single /64 prefix. If the mobile host finds more than
one prefix in the RA, it only considers the first one and silently one prefix in the RA, it only considers the first one and silently
discard the others [3GPP.29.061]. Therefore, multi-homing within a discards the others [TS.29061]. Therefore, multi-homing within a
single bearer is not possible. Renumbering without closing layer-2 single bearer is not possible. Renumbering without closing layer-2
connection is also not possible. The lifetime of /64 prefix is bound connection is also not possible. The lifetime of /64 prefix is bound
to lifetime of layer-2 connection even if the advertised prefix to lifetime of layer-2 connection even if the advertised prefix
lifetime would be longer than the layer-2 connection lifetime. lifetime would be 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 release. However, the /64 prefix allocated for each
default bearer (and to the user equipment) may be shared to local default bearer (and to the user equipment) may be shared to local
skipping to change at page 15, line 36 skipping to change at page 17, line 4
PDN-GW) in such a way the /64 prefix allocated to the default bearer PDN-GW) in such a way the /64 prefix allocated to the default bearer
is not part of the 'delegated prefix'. IETF is working on a solution is not part of the 'delegated prefix'. IETF is working on a solution
for DHCPv6-based prefix delegation to exclude a specific prefix from for DHCPv6-based prefix delegation to exclude a specific prefix from
the 'delegated prefix' [I-D.ietf-dhc-pd-exclude]. the 'delegated prefix' [I-D.ietf-dhc-pd-exclude].
5.4. IPv6 Neighbor Discovery Considerations 5.4. IPv6 Neighbor Discovery Considerations
3GPP link between the UE and the next hop router (e.g. GGSN) 3GPP link between the UE and the next hop router (e.g. GGSN)
resemble a point to point (p2p) link, which has no link-layer resemble a point to point (p2p) link, which has no link-layer
addresses [RFC3316] and this has not changed from 2G/3G GPRS to EPS. addresses [RFC3316] and this has not changed from 2G/3G GPRS to EPS.
The UE IP stack has to take this into consideration. When the 3GPP The UE IP stack has to take this into consideration. When the 3GPP
PDP Context appears as a PPP interface/link to the UE, the IP stack PDP Context appears as a PPP interface/link to the UE, the IP stack
is usually prepared to handle Neighbor Discovery protocol and the is usually prepared to handle Neighbor Discovery protocol and the
related Neighbor Cache state machine transitions in an appropriate related Neighbor Cache state machine transitions in an appropriate
way, even thought Neighbor Discovery protocol messages contain no way, even though Neighbor Discovery protocol messages contain no link
link layer address information. However, some operating systems layer address information. However, some operating systems discard
discard Router Advertisements on their PPP interface/link as a Router Advertisements on their PPP interface/link as a default
default setting. This causes the SLAAC to fail when the 3GPP PDP setting. This causes the SLAAC to fail when the 3GPP PDP Context
Context gets established, thus stalling all IPv6 traffic. 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 to appear as an IEEE802 interface/link to
the IP stack. This has few known issues, especially when the IP the IP stack. This has few known issues, especially when the IP
stack is made to believe the underlying link has link-layer stack is made to believe the underlying link has link-layer
addresses. First, the Neighbor Advertisement sent by a GGSN as a addresses. First, the Neighbor Advertisement sent by a GGSN as a
response to an address resolution triggered Neighbor Solicitation may response to an address resolution triggered Neighbor Solicitation may
not contain a Target Link-Layer address option (as suggested in not contain a Target Link-Layer address option (as suggested in
[RFC4861] Section 4.4). Then it is possible that the address [RFC4861] Section 4.4). Then it is possible that the address
resolution never completes when the UE tries to resolve the link- resolution never completes when the UE tries to resolve the link-
skipping to change at page 16, line 21 skipping to change at page 17, line 38
that address resolution and next-hop determination are not needed). that address resolution and next-hop determination are not needed).
As a result the address resolution never completes when the UE tries As a result the address resolution never completes when the UE tries
to resolve the link-layer address of the GGSN, thus stalling all IPv6 to resolve the link-layer address of the GGSN, thus stalling all IPv6
traffic. traffic.
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 [3GPP.23.060]. 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 Figure 5 and Figure 6. For
IPv4-only service, connections are created over the PDP context of IPv4-only service, connections are created over the PDP context of
type IPv4 and for IPv6-only service connections are created over the type IPv4 and for IPv6-only service connections are created over the
PDP context of type IPv6. The two PDP contexts of different type may PDP context of type IPv6. The two PDP contexts of different type may
use the same APN (and the gateway), however, this aspect is not use 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.
skipping to change at page 17, line 23 skipping to change at page 18, line 37
|///|~~~~~~~//-----| |====| | |///|~~~~~~~//-----| |====| |
+---+ +---+ +---+ +---+ +---+ +---+
Figure 6: A dual-stack mobile host connecting to dual-stack Internet Figure 6: A dual-stack mobile host connecting to dual-stack 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 type of PDP contexts
open is not optimal, because two PDP contexts require double the open is not optimal, because two PDP contexts require double the
signaling and consume more network resources than a single PDP signaling and consume more network resources than a single PDP
context. In the figure above the IPv4 and IPv6 PDP contexts are context. In the figure above the IPv4 and IPv6 PDP contexts are
attached to the same GGSN. While this is possible, the DS MS may be attached to the same GGSN. While this is possible, the dual-stack
attached to different GGSNs in the scenario where one GGSN supports (DS) MS may be attached to different GGSNs in the scenario where one
IPv4 PDN connectivity while another GGSN provides IPv6 PDN GGSN supports IPv4 PDN connectivity while another GGSN provides IPv6
connectivity. PDN 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 [3GPP.23.401]. PDN connection and EPS bearer have been introduced [TS.23401]. This
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 type (IPv4v6) PDP contexts.
Y Y
| |
|---+ +---+ +---+ |---+ +---+ +---+
| D | | | | P | .--. | D | | | | P | .--.
| S | | | | D | _( DS `. | S | | | | D | _( DS `.
| | IPv4v6 (DS) | S | | N | ( PDN ) | | IPv4v6 (DS) | S | | N | ( PDN )
skipping to change at page 18, line 13 skipping to change at page 19, line 30
types that are specified by 3GPP: types that are specified by 3GPP:
1. For 2G/3G access to GPRS core (SGSN/GGSN) pre-Release-9 there are 1. For 2G/3G access to GPRS core (SGSN/GGSN) pre-Release-9 there are
two IP PDP Types, IPv4 and IPv6. Two PDP contexts are needed to two IP PDP Types, IPv4 and IPv6. Two PDP contexts are needed to
get dual stack connectivity. get dual stack connectivity.
2. For 2G/3G access to GPRS core (SGSN/GGSN) from Release-9 there 2. For 2G/3G access to GPRS core (SGSN/GGSN) from Release-9 there
are three IP PDP Types, IPv4, IPv6 and IPv4v6. Minimum one PDP are three IP PDP Types, IPv4, IPv6 and IPv4v6. Minimum one PDP
context is needed to get dual stack connectivity. context is needed to get dual stack connectivity.
3. For 2G/3G access to EPC core (PDN-GW via S4 Release-8 SGSN) from 3. For 2G/3G access to EPC core (PDN-GW via S4-SGSN) from Release-8
Release-8 there are three IP PDP Types, IPv4, IPv6 and IPv4v6 there are three IP PDP Types, IPv4, IPv6 and IPv4v6 which gets
which gets mapped to PDN Connection type. Minimum one PDP mapped to PDN Connection type. Minimum one PDP Context is needed
Context is needed to get dual stack connectivity. 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 EPC core from Release-8 there are
three IP PDN Types, IPv4, IPv6 and IPv4v6. Minimum one PDN three IP PDN Types, IPv4, IPv6 and IPv4v6. Minimum one PDN
Connection is needed to get dual stack connectivity. 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.
skipping to change at page 19, line 28 skipping to change at page 20, line 28
| | | |<----------|(4) | | | | |<----------|(4) |
| | |<----------|(4) | | | | |<----------|(4) | |
| |<----------|(5) | | | | |<----------|(5) | | |
|/---------\| | | | | |/---------\| | | | |
| RB setup |(6) | | | | | RB setup |(6) | | | |
|\---------/| | | | | |\---------/| | | | |
| |---------->|(7) | | | | |---------->|(7) | | |
|---------->|(8) | | | | |---------->|(8) | | | |
| |---------->|(9) | | | | |---------->|(9) | | |
| | | | | | | | | | | |
|============= UL Data =============>==========>|(10) | |============= Uplink Data =========>==========>|(10) |
| | | | | | | | | | | |
| | |---------->|(11) | | | | |---------->|(11) | |
| | | | | | | | | | | |
| | |<----------|(12) | | | | |<----------|(12) | |
| | | | | | | | | | | |
|<============ DL 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 decides
to establish a PDN connection with a PDN-GW. The UE sends an to establish a PDN connection with a PDN-GW. The UE sends an
"Attach Request" (layer-2) to the BS. The BS forwards this "Attach Request" (layer-2) to the BS. The BS forwards this
attach request to the MME. attach request to the MME.
2. Authentication of the UE with the AAA server/HSS follows. If 2. Authentication of the UE with the AAA server/HSS follows. If
skipping to change at page 20, line 25 skipping to change at page 21, line 25
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 "Create
Session Response" message to the SGW from which the session Session Response" message to the SGW from which the session
request message was received from. The SGW forwards the request message was received from. The SGW forwards the
response to the corresponding MME which originated the request. response to the corresponding MME which 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 between the UE and the eNb is reconfigured
based on the parameters received from the MME based on the parameters received from the MME. (See note 1
below)
7. The eNb sends "Initial Context Response" message to the MME. 7. The eNb sends "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 to the eNodeB which
includes the Attach complete signal. includes the Attach complete signal.
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 time the downlink connection is also ready this time the downlink connection is also ready.
13. The UE can now start receiving downlink packets 13. The UE can now start receiving downlink packets, including
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 DS can be any of the types described in the previous section. The dual-
PDN connection, i.e the one which supports both IPv4 and IPv6 packets stack (DS) PDN connection, i.e the one which supports both IPv4 and
is the default one that will be established if no specific PDN IPv6 packets is the default one that will be established if no
connection type is specified by the UE in Release-8 networks. specific PDN connection type is specified by the UE in Release-8
networks.
Note 1: The UE receives the PDN Address Information Element
[TS.24301] at the end of radio bearer setup messaging. This
Information Element contains only the Interface Identifier of the
IPv6 address. In a case of GPRS the PDP Address Information
Element [TS.24008] would contain a complete IPv6 address.
However, the UE must ignore the IPv6 prefix if it receives one in
the message (see Section 11.2.1.3.2a of [TS.29061]).
6.4. Mobility of 3GPP IPv4v6 Type of Bearers 6.4. Mobility of 3GPP IPv4v6 Type of Bearers
3GPP discussed at length various approaches to support mobility 3GPP discussed at length various approaches to support mobility
between Release-8 and pre-Release-8 networks for the new dual-stack between a Release-8 LTE network and a pre-Release-9 2G/3G network
type of bearers. without a S4-SGSN for the new dual-stack type of bearers. The chosen
approach for mobility is as follows, in short: if a mobile is allowed
The chosen approach for mobility is as follows, in short: if a mobile for doing handovers between a Release-8 LTE network and a pre-
is known to be at risk for doing handovers between Release-8 and pre- Release-9 2G/3G network without a S4-SGSN while having open PDN
Release-8 networks, only single stack bearers are used. Essentially connections, only single stack bearers are used. Essentially this
meaning: means following deployment options:
1. If a network knows a mobile may do handovers between Release-8 1. If a network knows a mobile may do handovers between a Release-8
and pre-Release-8 networks (segment), network will only provide LTE network and a pre-Release-9 2G/3G network without a S4-SGSN,
single stack bearers, even if the mobile host requests dual-stack then the network is configured to provide only single stack
bearers. This can happen e.g. if an operator is using pre- bearers, even if the mobile host requests dual-stack bearers.
Release-8 SGSNs in some parts of the network. The single stack
bearers of Release-8 are easy to map one-to-one to pre-Release-8
bearers.
2. If a network knows a mobile will not be able to do handover to 2. If the network knows the mobile does handovers only between a
pre-Release-8 network (segment), it will provide mobile with Release-8 LTE network and a Release-9 2G/3G network or a pre-
dual-stack bearers on request. This can happen e.g. if an Release-9 network with a S4-SGSN, then the network is configured
operator has upgraded their SGSNs to support dual-stack bearers, to provide the mobile with dual-stack bearers on request. The
or if an operator is running LTE-only network. 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 mobile device always dual-stack type of bearers. A Release-8 mobile device always
requests for a dual-stack bearer, but accepts what is assigned by the requests for a dual-stack bearer, but accepts what is assigned by the
network. network.
7. Dual-Stack Approach to IPv6 Transition in 3GPP Networks 7. Dual-Stack Approach to IPv6 Transition in 3GPP Networks
3GPP networks can natively transport IPv4 and IPv6 packets between 3GPP networks can natively transport IPv4 and IPv6 packets between
the mobile station/UE and the gateway (GGSN or PDN-GW) as a result of the mobile station/UE and the gateway (GGSN or PDN-GW) as a result of
establishing either a dual-stack PDP context or parallel IPv4 and establishing either a dual-stack PDP context or parallel IPv4 and
IPv6 PDP contexts. IPv6 PDP contexts.
Current deployments of 3GPP networks primarily support IPv4 only. Current deployments of 3GPP networks primarily support IPv4-only.
These networks can be upgraded to also support IPv6 PDP contexts. By These networks can be upgraded to also support IPv6 PDP contexts. By
doing so devices and applications that are IPv6 capable can start doing so devices and applications that are IPv6 capable can start
utilizing the IPv6 connectivity. This will also ensure that legacy utilizing the IPv6 connectivity. This will also ensure that legacy
devices and applications continue to work with no impact. As newer devices and applications continue to work with no impact. As newer
devices start using IPv6 connectivity, the demand for actively used devices start using IPv6 connectivity, the demand for actively used
IPv4 connections is expected to slowly decrease, helping operators IPv4 connections is expected to slowly decrease, helping operators
with a transition to IPv6. With a dual-stack approach, there is with a transition to IPv6. With a dual-stack approach, there is
always the potential to fallback to IPv4. A device which may be always the potential to fallback to IPv4. A device which may be
roaming in a network wherein IPv6 is not supported by the visited roaming in a network wherein IPv6 is not supported by the visited
network could fall back to using IPv4 PDP contexts and hence the end network could fall back to using IPv4 PDP contexts and hence the end
user would at least get some connectivity. Unfortunately, dual-stack user would at least get some connectivity. Unfortunately, dual-stack
approach as such does not lower the number of used IPv4 addresses. approach as such does not lower the number of used IPv4 addresses.
Every dual-stack bearer still needs to given an IPv4 address, private Every dual-stack bearer still needs to be given an IPv4 address,
or public. This is a major concern with dual-stack bearers private or public. This is a major concern with dual-stack bearers
concerning IPv6 transition. However, if the majority of active IP concerning IPv6 transition. However, if the majority of active IP
communication has moved over to IPv6, then in case of NAT44 [RFC1918] communication has moved over to IPv6, then in case of NAT44 [RFC1918]
IPv4 connections the number of active IPv4 connections can still be IPv4 connections the number of active IPv4 connections can still be
expected to gradually decrease and thus giving some level of relief expected to gradually decrease and thus giving some level of relief
regarding NAT44 function scalability. regarding NAT44 function scalability.
As the networks evolve to support Release-8 EPS architecture and the As the networks evolve to support Release-8 EPS architecture and the
dual-stack PDP contexts, newer devices will be able to leverage such dual-stack PDP contexts, newer devices will be able to leverage such
capability and have a single bearer which supports both IPv4 and capability and have a single bearer which supports both IPv4 and
IPv6. Since IPv4 and IPv6 packets are carried as payload within GTP IPv6. Since IPv4 and IPv6 packets are carried as payload within GTP
skipping to change at page 22, line 31 skipping to change at page 23, line 36
capability in terms of whether it supports IPv4 or IPv6 on the capability in terms of whether it supports IPv4 or IPv6 on the
interfaces between the eNodeB and SGW or, SGW and PDN-GW is interfaces between the eNodeB and SGW or, SGW and PDN-GW is
immaterial. immaterial.
8. Deployment issues 8. Deployment issues
8.1. Overlapping IPv4 Addresses 8.1. Overlapping IPv4 Addresses
Given the shortage of globally routable public IPv4 addresses, Given the shortage of globally routable public IPv4 addresses,
operators tend to assign private IPv4 addresses [RFC1918] to hosts operators tend to assign private IPv4 addresses [RFC1918] to hosts
when they establish an IPv4 only PDP context or an IPv4v6 type PDN when they establish an IPv4-only PDP context or an IPv4v6 type PDN
context. About 16 million hosts can be assigned a private IPv4 context. About 16 million hosts can be assigned a private IPv4
address that is unique within a domain. However, in case of many address that is unique within a domain. However, in case of many
operators the number of subscribers is greater than 16 million. The operators the number of subscribers is greater than 16 million. The
issue can be dealt with by assigning overlapping RFC 1918 IPv4 issue can be dealt with by assigning overlapping RFC 1918 IPv4
addresses to hosts. As a result the IPv4 address assigned to a host addresses to hosts. As a result the IPv4 address assigned to a host
within the context of a single operator realm would no longer be within the context of a single operator realm would no longer be
unique. This has the obvious and know issues of NATed IP connection unique. This has the obvious and known issues of NATed IP connection
in the Internet. Direct host to host connectivity becomes in the Internet. Direct host to host connectivity becomes
complicated, unless the hosts are within the same private address complicated, unless the hosts are within the same private address
range pool and/or anchored to the same gateway, referrals using IP range pool and/or anchored to the same gateway, referrals using IP
addresses will have issues and so forth. These are generic issues addresses will have issues and so forth. These are generic issues
and not only a concern of the EPS. However, 3GPP as such does not and not only a concern of the EPS. However, 3GPP as such does not
have any mandatory language concerning NAT44 functionality in EPC. have any mandatory language concerning NAT44 functionality in EPC.
Obvious deployment choices apply also to EPC: Obvious deployment choices apply also to EPC:
1. Very large network deployments are partitioned, for example, 1. Very large network deployments are partitioned, for example,
based on a geographical areas. This partitioning allows based on a geographical areas. This partitioning allows for
overlapping IPv4 addresses ranges to be assigned to hosts that overlapping IPv4 addresses ranges to be assigned to hosts that
are in different areas. Each area has its own pool of gateways are in different areas. Each area has its own pool of gateways
that are dedicated for a certain overlapping IPv4 address range that are dedicated for a certain overlapping IPv4 address range
(referred here later as a zone). Standard NAT44 functionality (referred here later as a zone). Standard NAT44 functionality
enables the communication between hosts that are assigned the allows for communication from the [RFC1918] private zone to the
same IPv4 address but belong to different zones, yet are part of Internet. Communication between zones require special
the same operator domain. arrangement, such as using intermediate gateways (e.g. Back to
Back User Agent (B2BUA) in case of SIP).
2. A mobile host/device attaches to a gateway as part of the attach 2. A mobile host/device attaches to a gateway as part of the attach
process. The number of hosts that a gateway supports is in the process. The number of hosts that a gateway supports is in the
order of 1 to 10 million. Hence all the hosts assigned to a order of 1 to 10 million. Hence all the hosts assigned to a
single gateway can be assigned private IPv4 addresses. Operators single gateway can be assigned private IPv4 addresses. Operators
with large subscriber bases have multiple gateways and hence the with large subscriber bases have multiple gateways and hence the
same [RFC1918] IPv4 address space can be reused across gateways. same [RFC1918] IPv4 address space can be reused across gateways.
The IPv4 address assigned to a host is unique within the scope of The IPv4 address assigned to a host is unique within the scope of
a single gateway. a single gateway.
skipping to change at page 23, line 40 skipping to change at page 24, line 46
Release-8. The user plane traffic between the mobile host and the Release-8. The user plane traffic between the mobile host and the
gateway can use either IPv4 or IPv6. These packets are essentially gateway can use either IPv4 or IPv6. These packets are essentially
treated as payload by GTP/PMIPv6 and transported accordingly with no treated as payload by GTP/PMIPv6 and transported accordingly with no
real attention paid to the information (at least from a routing real attention paid to the information (at least from a routing
perspective) contained in the IPv4 or IPv6 headers. The transport perspective) contained in the IPv4 or IPv6 headers. The transport
links between the eNodeB and the SGW, and the link between the SGW links between the eNodeB and the SGW, and the link between the SGW
and PDN-GW can be migrated to IPv6 without any direct implications to and PDN-GW can be migrated to IPv6 without any direct implications to
the architecture. the architecture.
Currently, the inter-operator (for 3GPP technology) roaming networks Currently, the inter-operator (for 3GPP technology) roaming networks
are all IPv4 only (see Inter-PLMN Backbone Guidelines [GSMA.IR.34]). are all IPv4-only (see Inter-PLMN Backbone Guidelines [GSMA.IR.34]).
Eventually these roaming networks will also get migrated to IPv6, if Eventually these roaming networks will also get migrated to IPv6, if
there is a business reason for that. The migration period can be there is a business reason for that. The migration period can be
prolonged considerably because the 3GPP protocols always tunnel user prolonged considerably because the 3GPP protocols always tunnel user
plane traffic in the core network and as described earlier the 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 user plane IP
version. Furthermore, the design of the inter-operator roaming 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 is completely separated from each other. The inter-
operator roaming network itself is also completely separated from the operator roaming network itself is also completely separated from the
Internet. Only those core network nodes that must be connected to Internet. Only those core network nodes that must be connected to
skipping to change at page 24, line 35 skipping to change at page 25, line 40
Deployment and migration cases described in Section 6.1 for providing Deployment and migration cases described in Section 6.1 for providing
dual-stack like capability may mean doubled resource usage in dual-stack like capability may mean doubled resource usage in
operator's network. This is a major concern against providing dual- operator's network. This is a major concern against providing dual-
stack like connectivity using techniques discussed in Section 6.1. stack like connectivity using techniques discussed in Section 6.1.
Also handovers between networks with different capabilities in terms Also handovers between networks with different capabilities in terms
of networks being dual-stack like service capable or not, may turn of networks being dual-stack like service capable or not, may turn
out hard to comprehend for users and for application/services to cope out hard to comprehend for users and for application/services to cope
with. These facts may add other than just technical concerns for with. These facts may add other than just technical concerns for
operators when planning to roll out dual-stack service offerings. operators when planning to roll out dual-stack service offerings.
8.4. Operational Aspects of Running a Network with IPv6 Only Bearers 8.4. Operational Aspects of Running a Network with IPv6-only Bearers
It is possible to allocate IPv6 only type bearers to mobile hosts in It is possible to allocate IPv6-only type bearers to mobile hosts in
3GPP networks. IPv6 only bearer type has been part of the 3GPP 3GPP networks. IPv6-only bearer type has been part of the 3GPP
specification since the beginning. In 3GPP Release-8 (and later) it specification since the beginning. In 3GPP Release-8 (and later) it
was defined that a dual-stack mobile host (or when the radio was defined that a dual-stack mobile host (or when the radio
equipment has no knowledge of the host IP stack capabilities) must equipment has no knowledge of the host IP stack capabilities) must
first attempt to establish a dual-stack bearer and then possibly fall first attempt to establish a dual-stack bearer and then possibly fall
back to single IP version bearer. A Release-8 (or later) mobile host back to single IP version bearer. A Release-8 (or later) mobile host
with IPv6 only stack can directly attempt to establish an IPv6 only with IPv6-only stack can directly attempt to establish an IPv6-only
bearer. The IPv6 only behavior is up to a subscription provisioning bearer. The IPv6-only behaviour is up to a subscription provisioning
or a PDN-GW configuration, and the fallback scenarios do not or a PDN-GW configuration, and the fallback scenarios do not
necessarily cause additional signaling. necessarily cause additional signaling.
Although the bullets below introduce IPv6 to IPv4 address translation Although the bullets below introduce IPv6 to IPv4 address translation
and specifically discuss NAT64 technology [RFC6144], the current 3GPP and specifically discuss NAT64 technology [RFC6144], the current 3GPP
Release-8 architecture does not describe the use of address Release-8 architecture does not describe the use of address
translation or NAT64. It is up to a specific deployment whether translation or NAT64. It is up to a specific deployment whether
address translation is part of the network or not. Some operational address translation is part of the network or not. Some operational
aspects to consider for running a network with IPv6 only bearers: aspects to consider for running a network with IPv6-only bearers:
o The mobile hosts must have an IPv6 capable stack and a radio o The mobile hosts must have an IPv6 capable stack and a radio
interface capable of establishing an IPv6 PDP context or PDN interface capable of establishing an IPv6 PDP context or PDN
connection. connection.
o The GGSN/PDN-GW must be IPv6 capable in order to support IPv6 o The GGSN/PDN-GW must be IPv6 capable in order to support IPv6
bearers. Furthermore, the SGSN/MME must allow the creation of PDP bearers. Furthermore, the SGSN/MME must allow the creation of PDP
Type or PDN Type of IPv6. Type or PDN Type of IPv6.
o Many of the common applications are IP version agnostic and hence o Many of the common applications are IP version agnostic and hence
skipping to change at page 25, line 28 skipping to change at page 26, line 33
IPv4 specific would not work. IPv4 specific would not work.
o Inter-operator roaming is another aspect which causes issues, at o Inter-operator roaming is another aspect which causes issues, at
least during the ramp up phase of the IPv6 deployment. If the least during the ramp up phase of the IPv6 deployment. If the
visited network to which outbound roamers attach to does not visited network to which outbound roamers attach to does not
support PDP/PDN Type IPv6, then there needs to be a fallback support PDP/PDN Type IPv6, then there needs to be a fallback
option. The fallback option in this specific case is mostly up to option. The fallback option in this specific case is mostly up to
the mobile host to implement. Several cases are discussed in the the mobile host to implement. Several cases are discussed in the
following sections. following sections.
o If and when a mobile host using IPv6 only bearer needs to access o If and when a mobile host using IPv6-only bearer needs to access
to IPv4 Internet/network, a translation of some type from IPv6 to to IPv4 Internet/network, a translation of some type from IPv6 to
IPv4 has to be deployed in the network. NAT64 (and DNS64) is one IPv4 has to be deployed in the network. NAT64 (and DNS64) is one
solution that can be used for this purpose and works for a certain solution that can be used for this purpose and works for a certain
set of protocols (read TCP and UDP, 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 name to IP addresses).
8.5. Restricting Outbound IPv6 Roaming 8.5. Restricting Outbound IPv6 Roaming
Roaming was briefly touched upon in Sections 8.2 and 8.4. While Roaming was briefly touched upon in Sections 8.2 and 8.4. While
there is interest in offering roaming service for IPv6 enabled mobile there is interest in offering roaming service for IPv6 enabled mobile
hosts and subscriptions, not all visited networks are prepared for hosts and subscriptions, not all visited networks are prepared for
IPv6 outbound roamers. There are basically two issues. First, the IPv6 outbound roamers. There are basically two issues. First, the
visited network (S4-)SGSN does not support the IPv6 PDP Context or visited network SGSN does not support the IPv6 PDP Context or IPv4v6
IPv4v6 PDP Context types. These should mostly concern pre-Release-8 PDP Context types. These should mostly concern pre-Release-9 2G/3G
networks but there is no definitive rule as the deployed feature sets networks without S4-SGSN but there is no definitive rule as the
vary depending on implementations and licenses. Second, the visited deployed feature sets vary depending on implementations and licenses.
network might not be commercially ready for IPv6 outbound roamers, Second, the visited network might not be commercially ready for IPv6
while everything might work technically at the user plane level. outbound roamers, while everything might work technically at the user
This would lead to "revenue leakage" especially from the visited plane level. This would lead to "revenue leakage" especially from
operator point of view (note that the use of visited network GGSN/ the visited operator point of view (note that the use of visited
PDN-GW does not really exist in real deployments today). Therefore, network GGSN/PDN-GW does not really exist in real deployments today).
it might be in the interest of operators to prohibit roaming Therefore, it might be in the interest of operators to prohibit
selectively within specific visited networks. roaming selectively within specific visited networks.
Unfortunately, it is not mandatory to implement/deploy 3GPP standards Unfortunately, it is not mandatory to implement/deploy 3GPP standards
based solution to selectively prohibit IPv6 roaming without also based solution to selectively prohibit IPv6 roaming without also
prohibiting other packet services (such as IPv4 roaming). However, prohibiting other packet services (such as IPv4 roaming). However,
there are few possibilities how this can be done in real deployments. there are few possibilities how this can be done in real deployments.
The examples given below are either optional and/or vendor specific The examples given below are either optional and/or vendor specific
features to the 3GPP EPC: features to the 3GPP EPC:
o Using Policy and Charging Control (PCC) [3GPP.23.203] o Using Policy and Charging Control (PCC) [TS.23203] functionality
functionality and its rules to fail, for example, the bearer and its rules to fail, for example, the bearer authorization when
authorization when a desired criteria is met. In this case that a desired criteria is met. In this case that would be PDN/PDP
would be PDN/PDP Type IPv6/IPv4v6 and a specific visited network. Type IPv6/IPv4v6 and a specific visited network. The rules can be
The rules can be provisioned either in the home network or locally provisioned either in the home network or locally in the visited
in the visited network. network.
o Some Home Location Register (HLR) and Home Subscriber Server (HSS) o Some Home Location Register (HLR) and Home Subscriber Server (HSS)
subscriber databases allow prohibiting roaming in a specific subscriber databases allow prohibiting roaming in a specific
(visited) network for a specified PDN/PDP Type. (visited) network for a specified PDN/PDP Type.
The obvious problems are that these solutions are not mandatory, are The obvious problems are that these solutions are not mandatory, are
not unified across networks, and therefore also lack well-specified not unified across networks, and therefore also lack well-specified
fall back mechanism from the mobile host point of view. fall back mechanism from the mobile host point of view.
8.6. Inter-rat Handovers and IP Versions 8.6. Inter-RAT Handovers and IP Versions
It is obvious that when operators start to incrementally deploy EPS It is obvious that operators start incrementally deploy EPS along
(and E-UTRAN) along with the existing UTRAN/GERAN, handovers between with the existing UTRAN/GERAN, handovers between different radio
different radio technologies (inter-rat handovers) become inevitable. technologies (inter-RAT handovers) become inevitable. In case of
In case of inter-rat handovers 3GPP supports the following IP inter-RAT handovers 3GPP supports the following IP addressing
addressing scenarios: scenarios:
o E-UTRAN IPv4v6 bearer has to map one to one to UTRAN/GERAN IPv4v6 o E-UTRAN IPv4v6 bearer has to map one to one to UTRAN/GERAN IPv4v6
bearer. bearer.
o E-UTRAN IPv6 bearer has to map one to one to UTRAN/GERAN IPv6 o E-UTRAN IPv6 bearer has to map one to one to UTRAN/GERAN IPv6
bearer. bearer.
o E-UTRAN IPv4 bearer has to map one to one to UTRAN/GERAN IPv4 o E-UTRAN IPv4 bearer has to map one to one to UTRAN/GERAN IPv4
bearer. bearer.
Other types of configurations are considered network planning Other types of configurations are considered network planning
mistakes. What the above rules essentially imply is that the network mistakes. What the above rules essentially imply is that the network
migration has to be planned and subscriptions provisioned based on migration has to be planned and subscriptions provisioned based on
the lowest common nominator, if inter-rat handovers are desired. For the lowest common nominator, if inter-RAT handovers are desired. For
example, if some part of the UTRAN network cannot serve anything but example, if some part of the UTRAN network cannot serve anything but
IPv4 bearers, then the E-UTRAN is also forced to provide only IPv4 IPv4 bearers, then the E-UTRAN is also forced to provide only IPv4
bearers. Various combinations of subscriber provisioning regarding bearers. Various combinations of subscriber provisioning regarding
IP versions are discussed further in Section 8.7. IP versions are discussed further in Section 8.7.
8.7. Provisioning of IPv6 Subscribers and Various Combinations During 8.7. Provisioning of IPv6 Subscribers and Various Combinations During
Initial Network Attachment Initial Network Attachment
Subscribers' provisioned PDP/PDN Types have multiple configurations. Subscribers' provisioned PDP/PDN Types have multiple configurations.
The supported PDP/PDN Type is provisioned per each APN for every The supported PDP/PDN Type is provisioned per each APN for every
subscriber. The following PDN Types are possible in the HSS for a subscriber. The following PDN Types are possible in the HSS for a
Release-8 subscription [3GPP.23.401]: Release-8 subscription [TS.23401]:
o IPv4v6 PDN Type (note that IPv4v6 PDP Type does not exist in HLR). o IPv4v6 PDN Type (note that IPv4v6 PDP Type does not exist in a HLR
and Mobile Applicatio Part (MAP) [TS.29002] signaling prior
Release-9).
o IPv6 only PDN Type o IPv6-only PDN Type
o IPv4 only PDN Type. o IPv4-only PDN Type.
o IPv4_or_IPv6 PDN Type (note that IPv4_or_IPv6 PDP Type does not o IPv4_or_IPv6 PDN Type (note that IPv4_or_IPv6 PDP Type does not
exist in HLR). exist in a HLR or MAP signaling. However, a HLR may have multiple
APN configurations of different PDN Types, which effectively
achieves the same functionality).
A Release-8 dual-stack mobile host must always attempt to establish a A Release-8 dual-stack mobile host must always attempt to establish a
PDP/PDN Type IPv4v6 bearer. The same also applies when the modem PDP/PDN Type IPv4v6 bearer. The same also applies when the modem
part of the mobile host does not have exact knowledge whether the part of the mobile host does not have exact knowledge whether the
host operating system IP stack is a dual-stack capable or not. A host operating system IP stack is a dual-stack capable or not. A
mobile host that is IPv6 only capable must attempt to establish a mobile host that is IPv6-only capable must attempt to establish a
PDP/PDN Type IPv6 bearer. Last, a mobile host that is IPv4 only PDP/PDN Type IPv6 bearer. Last, a mobile host that is IPv4-only
capable must attempt to establish a PDN/PDP Type IPv4 bearer. capable must attempt to establish a PDN/PDP Type IPv4 bearer.
In a case the PDP/PDN Type requested by a mobile host does not match In a case the PDP/PDN Type requested by a mobile host does not match
what has been provisioned for the subscriber in the HSS (or HLR), the what has been provisioned for the subscriber in the HSS (or HLR), the
mobile host possibly falls back to a different PDP/PDN Type. The mobile host possibly falls back to a different PDP/PDN Type. The
network (i.e. the MME or the SGSN) is able to inform the mobile host network (i.e. the MME or the S4-SGSN) is able to inform the mobile
during the network attachment signaling why it did not get the host during the network attachment signaling why it did not get the
requested PDP/PDN Type. These response/cause codes are documented in requested PDP/PDN Type. These response/cause codes are documented in
[3GPP.24.008][3GPP.24.301]: [TS.24008] for requested PDP Types and [TS.24301] for requested PDN
Types:
o ESM cause #50 "PDN type IPv4 only allowed". o (E)SM cause #50 "PDN/PDP type IPv4-only allowed".
o ESM cause #51 "PDN type IPv6 only allowed". o (E)SM cause #51 "PDN/PDP type IPv6-only allowed".
o ESM cause #52 "single address bearers only allowed". o (E)SM cause #52 "single address bearers only allowed".
The above respone/cause codes apply to Release-8 and onwards. In The above response/cause codes apply to Release-8 and onwards. In
pre-Release-8 networks used response/cause codes vary depending on pre-Release-8 networks used response/cause codes vary depending on
the vendor, unfortunately. the vendor, unfortunately.
Possible fall back cases include (as documented in [3GPP.23.401]): Possible fall back cases when the network deploys MMEs and/or S4-
SGSNs include (as documented in [TS.23401]):
o Requested & provisioned PDP/PDN Types match -> requested. o Requested and provisioned PDP/PDN Types match => requested.
o Requested IPv4v6 & provisioned IPv6 -> IPv6 and a mobile host o Requested IPv4v6 and provisioned IPv6 => IPv6 and a mobile host
receives indication that IPv6-only bearer is allowed. receives indication that IPv6-only bearer is allowed.
o Requested IPv4v6 & provisioned IPv4 -> IPv4 and the mobile host o Requested IPv4v6 and provisioned IPv4 => IPv4 and the mobile host
receives indication that IPv4-only bearer is allowed. receives indication that IPv4-only bearer is allowed.
o Requested IPv4v6 & provisioned IPv4_or_IPv6 -> IPv4 or IPv6 is o Requested IPv4v6 and provisioned IPv4_or_IPv6 => IPv4 or IPv6 is
selected by the MME based on an unspecified criteria. The mobile selected by the MME/S4-SGSN based on an unspecified criteria. The
host may then attempt to establish, based on the mobile host mobile host may then attempt to establish, based on the mobile
implementation, a parallel bearer of a different PDP/PDN Type. host implementation, 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) to affect the final selected PDP/ possible for a PDN-GW (and a MME/S4-SGSN) to affect the final
PDN Type: selected PDP/PDN Type:
o Requested IPv4v6 & configured IPv4 or IPv6 in the PDN-GW -> IPv4 o Requested IPv4v6 and configured IPv4 or IPv6 in the PDN-GW => IPv4
or IPv6. If the MME operator had included the "Dual Address or IPv6. If the MME operator had included the "Dual Address
Bearer Flag" into the bearer establishment signaling, then the Bearer Flag" into the bearer establishment signaling, then the
mobile host receives an indication that IPv6-only or IPv4-only mobile host receives an indication that IPv6-only or IPv4-only
bearer is allowed. bearer is allowed.
o Requested IPv4v6 & configured IPv4 or IPv6 in the PDN-GW -> IPv4 o Requested IPv4v6 and configured IPv4 or IPv6 in the PDN-GW => IPv4
or IPv6. If the MME operator had not included the "Dual Address or IPv6. If the MME operator had not included the "Dual Address
Bearer Flag" into the bearer establishment signaling, then the Bearer Flag" into the bearer establishment signaling, then the
mobile host may attempt to establish, based on the mobile host mobile host may attempt to establish, based on the mobile host
implementation, a parallel bearer of different PDP/PDN Type. implementation, a parallel bearer of different PDP/PDN Type.
If for some reason a SGSN does not understand the requested PDP Type, A SGSN that does not understand the requested PDP Type is supposed to
then the PDP Type is handled as IPv4. If for some reason a MME does handle the requested PDP Type as IPv4. If for some reason a MME does
not understand the requested PDN Type, then the PDN Type is handled not understand the requested PDN Type, then the PDN Type is handled
as IPv6. as IPv6.
9. IANA Considerations 9. IANA Considerations
This document has no requests to IANA. This document has no requests to IANA.
10. Security Considerations 10. Security Considerations
This document does not introduce any security related concerns. This document does not introduce any security related concerns.
skipping to change at page 29, line 20 skipping to change at page 30, line 32
context between the mobile station and the gateway. context between the mobile station and the gateway.
As devices and applications are upgraded to support IPv6 they can As devices and applications are upgraded to support IPv6 they can
start leveraging the IPv6 connectivity provided by the networks while start leveraging the IPv6 connectivity provided by the networks while
maintaining the fall back to IPv4 capability. Enabling IPv6 maintaining the fall back to IPv4 capability. Enabling IPv6
connectivity in the 3GPP networks by itself will provide some degree connectivity in the 3GPP networks by itself will provide some degree
of relief to the IPv4 address space as many of the applications and of relief to the IPv4 address space as many of the applications and
services can start to work over IPv6. However without comprehensive services can start to work over IPv6. However without comprehensive
testing of different applications and solutions that exist today and testing of different applications and solutions that exist today and
are widely used, for their ability to operate over IPv6 PDN are widely used, for their ability to operate over IPv6 PDN
connections, an IPv6 only access would cause disruptions. connections, an IPv6-only access would cause disruptions.
12. Acknowledgements 12. Acknowledgements
The authors thank Shabnam Sultana, Sri Gundavelli, Hui Deng, and The authors thank Shabnam Sultana, Sri Gundavelli, Hui Deng, and
Zhenqiang Li, Mikael Abrahamsson, James Woodyatt and Cameron Byrne Zhenqiang Li, Mikael Abrahamsson, James Woodyatt, Cameron Byrne, Ales
for their reviews and comments on this document. Vizdal and Frank Brockners for their reviews and comments on this
document.
13. Informative References 13. Informative References
[3GPP.23.060]
3GPP, "General Packet Radio Service (GPRS); Service
description; Stage 2", 3GPP TS 23.060 8.8.0, March 2010.
[3GPP.23.203]
3GPP, "Policy and charging control architecture (PCC)",
3GPP TS 23.203 8.11.0, September 2010.
[3GPP.23.401]
3GPP, "General Packet Radio Service (GPRS) enhancements
for Evolved Universal Terrestrial Radio Access Network
(E-UTRAN) access", 3GPP TS 23.401 10.3.0, March 2011.
[3GPP.23.975]
3GPP, "IPv6 Migration Guidelines", 3GPP TR 23.975 1.1.1,
June 2010.
[3GPP.24.008]
3GPP, "Mobile radio interface Layer 3 specification", 3GPP
TS 24.008 8.12.0, December 2010.
[3GPP.24.301]
3GPP, "Non-Access-Stratum (NAS) protocol for Evolved
Packet System (EPS)", 3GPP TS 24.301 8.8.0, December 2010.
[3GPP.29.060]
3GPP, "General Packet Radio Service (GPRS); GPRS
Tunnelling Protocol (GTP) across the Gn and Gp interface",
3GPP TS 29.274 8.8.0, April 2010.
[3GPP.29.061]
3GPP, "Interworking between the Public Land Mobile Network
(PLMN) supporting packet based services and Packet Data
Networks (PDN)", 3GPP TS 29.061 8.5.0, April 2010.
[3GPP.29.274]
3GPP, "3GPP Evolved Packet System (EPS); Evolved General
Packet Radio Service (GPRS) Tunnelling Protocol for
Control plane (GTPv2-C)", 3GPP TS 29.060 8.11.0,
December 2010.
[GSMA.IR.34] [GSMA.IR.34]
GSMA, "Inter-PLMN Backbone Guidelines", GSMA GSMA, "Inter-PLMN Backbone Guidelines", GSMA
PRD IR.34.4.9, March 2010. PRD IR.34.4.9, March 2010.
[I-D.ietf-dhc-pd-exclude] [I-D.ietf-dhc-pd-exclude]
Korhonen, J., Savolainen, T., Krishnan, S., and O. Troan, Korhonen, J., Savolainen, T., Krishnan, S., and O. Troan,
"Prefix Exclude Option for DHCPv6-based Prefix "Prefix Exclude Option for DHCPv6-based Prefix
Delegation", draft-ietf-dhc-pd-exclude-01 (work in Delegation", draft-ietf-dhc-pd-exclude-02 (work in
progress), January 2011. progress), June 2011.
[RFC1918] Rekhter, Y., Moskowitz, R., Karrenberg, D., Groot, G., and [RFC1918] Rekhter, Y., Moskowitz, R., Karrenberg, D., Groot, G., and
E. Lear, "Address Allocation for Private Internets", E. Lear, "Address Allocation for Private Internets",
BCP 5, RFC 1918, February 1996. BCP 5, RFC 1918, February 1996.
[RFC2131] Droms, R., "Dynamic Host Configuration Protocol", [RFC2131] Droms, R., "Dynamic Host Configuration Protocol",
RFC 2131, March 1997. RFC 2131, March 1997.
[RFC3315] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C., [RFC3315] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C.,
and M. Carney, "Dynamic Host Configuration Protocol for and M. Carney, "Dynamic Host Configuration Protocol for
skipping to change at page 31, line 29 skipping to change at page 31, line 51
[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., Leung, K., Devarapalli, V., Chowdhury, K.,
and B. Patil, "Proxy Mobile IPv6", RFC 5213, August 2008. 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]
3GPP, "IPv6 Migration Guidelines", 3GPP TR 23.975 1.1.1,
June 2010.
[TS.23060]
3GPP, "General Packet Radio Service (GPRS); Service
description; Stage 2", 3GPP TS 23.060 8.8.0, March 2010.
[TS.23203]
3GPP, "Policy and charging control architecture (PCC)",
3GPP TS 23.203 8.11.0, September 2010.
[TS.23401]
3GPP, "General Packet Radio Service (GPRS) enhancements
for Evolved Universal Terrestrial Radio Access Network
(E-UTRAN) access", 3GPP TS 23.401 10.4.0, June 2011.
[TS.24008]
3GPP, "Mobile radio interface Layer 3 specification", 3GPP
TS 24.008 8.12.0, December 2010.
[TS.24301]
3GPP, "Non-Access-Stratum (NAS) protocol for Evolved
Packet System (EPS)", 3GPP TS 24.301 8.8.0, December 2010.
[TS.29002]
3GPP, "Mobile Application Part (MAP) specification", 3GPP
TS 29.002 9.5.0, June 2011.
[TS.29060]
3GPP, "General Packet Radio Service (GPRS); GPRS
Tunnelling Protocol (GTP) across the Gn and Gp interface",
3GPP TS 29.274 8.8.0, April 2010.
[TS.29061]
3GPP, "Interworking between the Public Land Mobile Network
(PLMN) supporting packet based services and Packet Data
Networks (PDN)", 3GPP TS 29.061 8.5.0, April 2010.
[TS.29274]
3GPP, "3GPP Evolved Packet System (EPS); Evolved General
Packet Radio Service (GPRS) Tunnelling Protocol for
Control plane (GTPv2-C)", 3GPP TS 29.060 8.11.0,
December 2010.
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
 End of changes. 84 change blocks. 
323 lines changed or deleted 383 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/