draft-ietf-v6ops-ipv6-roaming-analysis-07.txt   rfc7445.txt 
Network Working Group G. Chen Internet Engineering Task Force (IETF) G. Chen
Internet-Draft H. Deng Request for Comments: 7445 H. Deng
Intended status: Informational China Mobile Category: Informational China Mobile
Expires: April 22, 2015 D. Michaud ISSN: 2070-1721 D. Michaud
Rogers Communications Rogers Communications
J. Korhonen J. Korhonen
Broadcom Broadcom Corporation
M. Boucadair M. Boucadair
France Telecom France Telecom
A. Vizdal March 2015
Deutsche Telekom AG
October 19, 2014
Analysis of Failure Cases in IPv6 Roaming Scenarios Analysis of Failure Cases in IPv6 Roaming Scenarios
draft-ietf-v6ops-ipv6-roaming-analysis-07
Abstract Abstract
This document identifies a set of failure cases that may be This document identifies a set of failure cases that may be
encountered by IPv6-enabled mobile customers in roaming scenarios. encountered by IPv6-enabled mobile customers in roaming scenarios.
The analysis reveals that the failure causes include improper The analysis reveals that the failure causes include improper
configurations, incomplete functionality support in equipment, and configurations, incomplete functionality support in equipment, and
inconsistent IPv6 deployment strategies between the home and the inconsistent IPv6 deployment strategies between the home and the
visited networks. visited networks.
Status of This Memo Status of This Memo
This Internet-Draft is submitted in full conformance with the This document is not an Internet Standards Track specification; it is
provisions of BCP 78 and BCP 79. published for informational purposes.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
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 22, 2015. 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/rfc7445.
Copyright Notice Copyright Notice
Copyright (c) 2014 IETF Trust and the persons identified as the Copyright (c) 2015 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 . . . . . . . . . . . . . . . . . . . . . . . . 2 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3 1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3
2. Background . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Background . . . . . . . . . . . . . . . . . . . . . . . . . 4
2.1. Roaming Architecture: An Overview . . . . . . . . . . . . 4 2.1. Roaming Architecture: An Overview . . . . . . . . . . . . 4
2.1.1. Home Routed Mode . . . . . . . . . . . . . . . . . . 4 2.1.1. Home Routed Mode . . . . . . . . . . . . . . . . . . 4
2.1.2. Local Breakout Mode . . . . . . . . . . . . . . . . . 5 2.1.2. Local Breakout Mode . . . . . . . . . . . . . . . . . 5
2.2. Typical Roaming Scenarios . . . . . . . . . . . . . . . . 6 2.2. Typical Roaming Scenarios . . . . . . . . . . . . . . . . 6
3. Failure Case in the Network Attachment . . . . . . . . . . . 7 3. Failure Case in the Network Attachment . . . . . . . . . . . 7
4. Failure Cases in the PDP/PDN Creation . . . . . . . . . . . . 8 4. Failure Cases in the PDP/PDN Creation . . . . . . . . . . . . 9
4.1. Case 1: Splitting Dual-stack Bearer . . . . . . . . . . . 9 4.1. Case 1: Splitting Dual-Stack Bearer . . . . . . . . . . . 9
4.2. Case 2: IPv6 PDP/PDN Unsupported . . . . . . . . . . . . 10 4.2. Case 2: IPv6 PDP/PDN Unsupported . . . . . . . . . . . . 11
4.3. Case 3: Inappropriate Roaming APN Set . . . . . . . . . . 11 4.3. Case 3: Inappropriate Roaming APN Set . . . . . . . . . . 11
4.4. Case 4: Fallback Failure . . . . . . . . . . . . . . . . 11 4.4. Case 4: Fallback Failure . . . . . . . . . . . . . . . . 11
5. Failure Cases in the Service Requests . . . . . . . . . . . . 11 5. Failure Cases in the Service Requests . . . . . . . . . . . . 12
5.1. Lack of IPv6 Support in Applications . . . . . . . . . . 11 5.1. Lack of IPv6 Support in Applications . . . . . . . . . . 12
5.2. 464xlat Support . . . . . . . . . . . . . . . . . . . . . 12 5.2. 464XLAT Support . . . . . . . . . . . . . . . . . . . . . 12
6. HLR/HSS User Profile Setting . . . . . . . . . . . . . . . . 12 6. HLR/HSS User Profile Setting . . . . . . . . . . . . . . . . 13
7. Discussion . . . . . . . . . . . . . . . . . . . . . . . . . 14 7. Discussion . . . . . . . . . . . . . . . . . . . . . . . . . 14
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15 8. Security Considerations . . . . . . . . . . . . . . . . . . . 15
9. Security Considerations . . . . . . . . . . . . . . . . . . . 15 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 16
10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 15 9.1. Normative References . . . . . . . . . . . . . . . . . . 16
11. References . . . . . . . . . . . . . . . . . . . . . . . . . 16 9.2. Informative References . . . . . . . . . . . . . . . . . 16
11.1. Normative References . . . . . . . . . . . . . . . . . . 16 Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 18
11.2. Informative References . . . . . . . . . . . . . . . . . 17 Contributors . . . . . . . . . . . . . . . . . . . . . . . . . . 18
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 18 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 19
1. Introduction 1. Introduction
Many Mobile Operators have deployed IPv6, or are about to, in their Many mobile operators have deployed IPv6, or are about to, in their
operational networks. A customer in such a network can be provided operational networks. A customer in such a network can be provided
IPv6 connectivity if their User Equipment (UE) is IPv6-compliant. IPv6 connectivity if their User Equipment (UE) is IPv6 compliant.
Operators may adopt various approaches to deploy IPv6 in mobile Operators may adopt various approaches to deploy IPv6 in mobile
networks such as the solutions described in [TR23.975]). Depending networks, such as the solutions described in [TR23.975]. Depending
on network conditions, either dual-stack or IPv6-only deployment on network conditions, either dual-stack or IPv6-only deployment
schemes can be enabled. schemes can be enabled.
A detailed overview of IPv6 support in 3GPP architectures is provided A detailed overview of IPv6 support in 3GPP architectures is provided
in [RFC6459]. in [RFC6459].
It has been observed and reported that a mobile subscriber roaming It has been observed and reported that a mobile subscriber roaming
around a different operator's areas may experience service disruption around a different operator's areas may experience service disruption
due to inconsistent configurations and incomplete functionality of due to inconsistent configurations and incomplete functionality of
equipment in the network. This document focuses on these issues. equipment in the network. This document focuses on these issues.
1.1. Terminology 1.1. Terminology
This document makes use of these terms: This document makes use of these terms:
o Mobile networks refer to 3GPP mobile networks. o Mobile networks refer to 3GPP mobile networks.
o Mobile UE denotes a 3GPP device which can be connected to 3GPP o Mobile UE denotes a 3GPP device that can be connected to 3GPP
mobile networks. mobile networks.
o The Public Land Mobile Network (PLMN) is a network that is o The Public Land Mobile Network (PLMN) is a network that is
operated by a single administrative entity. A PLMN (and therefore operated by a single administrative entity. A PLMN (and therefore
also an operator) is identified by the Mobile Country Code (MCC) also an operator) is identified by the Mobile Country Code (MCC)
and the Mobile Network Code (MNC). Each (telecommunications) and the Mobile Network Code (MNC). Each (telecommunications)
operator providing mobile services has its own PLMN [RFC6459]. operator providing mobile services has its own PLMN [RFC6459].
o The Home Location Register (HLR) is a pre-Release-5 database (but o 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 real deployments of Release 5 and later) that
that contains subscriber data and information related to call contains subscriber data and information related to call routing.
routing. All subscribers of an operator and the subscribers' All subscribers of an operator and the subscribers' enabled
enabled services are provisioned in the HLR [RFC6459]. services are provisioned in the HLR [RFC6459].
o The Home Subscriber Server (HSS) is a database for a given o The Home Subscriber Server (HSS) is a database for a given
subscriber and was 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 [RFC6459]. network entities actually handling calls/sessions [RFC6459].
"HLR/HSS" is used collectively for the subscriber database unless o "HLR/HSS" is used collectively for the subscriber database unless
referring to the failure case related to General Packet Radio Service referring to the failure case related to General Packet Radio
(GPRS) Subscriber data from the HLR. Service (GPRS) Subscriber data from the HLR.
An overview of key 3GPP functional elements is documented in An overview of key 3GPP functional elements is documented in
[RFC6459]. [RFC6459].
"Mobile device" and "mobile UE" are used interchangeably. "Mobile device" and "mobile UE" are used interchangeably.
2. Background 2. Background
2.1. Roaming Architecture: An Overview 2.1. Roaming Architecture: An Overview
Roaming occurs in two scenarios: Roaming occurs in two scenarios:
o International roaming: a mobile UE enters a visited network o International roaming: a mobile UE enters a visited network
operated by a different operator, where a different Public Land operated by a different operator, where a different PLMN code is
Mobile Network (PLMN) code is used. The UEs could, either in an used. The UEs could, either in an automatic mode or in a manual
automatic mode or in a manual mode, attach to the visited PLMN. mode, attach to the visited PLMN.
o Intra-PLMN mobility: an operator may have one or multiple PLMN o Intra-PLMN mobility: an operator may have one or multiple PLMN
codes. A mobile UE could pre-configure the codes to identify the codes. A mobile UE could pre-configure the codes to identify the
Home PLMN (HPLMN) or Equivalent HPLMN (EHPLMN). Intra-PLMN Home PLMN (HPLMN) or Equivalent HPLMN (EHPLMN). Intra-PLMN
mobility allows the UE moving to a different area of HPLMN and mobility allows the UE to move to a different area of HPLMN and
EHPLMN. When the subscriber profile is not stored in the visited EHPLMN. When the subscriber profile is not stored in the visited
area, HLR/HSS in the Home area will transmit the profile to area, HLR/HSS in the Home area will transmit the profile to the
Serving GPRS Support Node (SGSN)/Mobility Management Entity (MME) Serving GPRS Support Node (SGSN) / Mobility Management Entity
in the visited area so as to complete network attachment. (MME) in the visited area so as to complete network attachment.
When a UE is turned on or is transferred via a hand-over to a visited When a UE is turned on or is transferred via a handover to a visited
network, the mobile device will scan all radio channels and find network, the mobile device will scan all radio channels and find
available PLMNs to attach to. The SGSN or the MME in the visited available PLMNs to attach to. The SGSN or the MME in the visited
networks must contact the HLR or HSS to retrieve the subscriber networks must contact the HLR or HSS to retrieve the subscriber
profile. profile.
Steering of roaming may also be used by the HPLMN to further restrict Steering of roaming may also be used by the HPLMN to further restrict
which of the available networks the UE may be attached to. Once the which of the available networks the UE may be attached to. Once the
authentication and registration stage is completed, the Packet Data authentication and registration stage is completed, the Packet Data
Protocol (PDP) or Packet Data Networks (PDN) activation and traffic Protocol (PDP) or Packet Data Networks (PDN) activation and traffic
flows may be operated differently according to the subscriber profile flows may be operated differently according to the subscriber profile
stored in the HLR or the HSS. stored in the HLR or the HSS.
The following sub-sections describe two roaming modes: Home routed The following subsections describe two roaming modes: Home-routed
traffic (Section 2.1.1) and Local breakout (Section 2.1.2). traffic (Section 2.1.1) and Local breakout (Section 2.1.2).
2.1.1. Home Routed Mode 2.1.1. Home Routed Mode
In this mode, the subscriber's UE gets IP addresses from the home In this mode, the subscriber's UE gets IP addresses from the home
network. All traffic belonging to that UE is therefore routed to the network. All traffic belonging to that UE is therefore routed to the
home network (Figure 1). home network (Figure 1).
GPRS roaming exchange (GRX) or Internetwork Packet Exchange (IPX) GPRS roaming exchange (GRX) or Internetwork Packet Exchange (IPX)
networks [IR.34] are likely to be invoked as the transit network to networks [IR.34] are likely to be invoked as the transit network to
deliver the traffic. This is the main mode for international roaming deliver the traffic. This is the main mode for international roaming
of Internet data services to facilitate the charging process between of Internet data services to facilitate the charging process between
the two involved operators. the two involved operators.
+-----------------------------+ +------------------------+ +-----------------------------+ +------------------------+
|Visited Network | |Home Network | |Visited Network | |Home Network |
| +----+ +--------+ | (GRX/IPX) | +--------+ Traffic Flow | +----+ +----+---+ | (GRX/IPX) | +--------+ Traffic Flow
| | UE |=======>|SGSN/MME|====================>|GGSN/PGW|============> | | UE |=======>|SGSN/SGW|====================>|GGSN/PGW|============>
| +----+ +--------+ | Signaling | +--------+ | | +----+ +----+---+ | | +--------+ |
| |------------------------>+--------+ | | |MME | | | |
| | | |HLR/HSS | | | +----+ | Signaling | +--------+ |
| |-------------------------->|HLR/HSS | |
| | | +--------+ | | | | +--------+ |
+-----------------------------+ +------------------------+ +-----------------------------+ +------------------------+
Figure 1: Home Routed Traffic Figure 1: Home Routed Traffic
2.1.2. Local Breakout Mode 2.1.2. Local Breakout Mode
In the local breakout mode, IP addresses are assigned by the visited In the local breakout mode, IP addresses are assigned by the visited
network to a roaming mobile UE. Unlike the home mode, the traffic network to a roaming mobile UE. Unlike the home routed mode, the
doesn't have to traverse GRX/IPX; it is offloaded locally at a traffic doesn't have to traverse GRX/IPX; it is offloaded locally at
network node close to that device's point of attachment in the a network node close to that device's point of attachment in the
visited network. This mode ensures a more optimized forwarding path visited network. This mode ensures a more optimized forwarding path
for the delivery of packets belonging to a visiting UE (Figure 2). for the delivery of packets belonging to a visiting UE (Figure 2).
+----------------------------+ +----------------+ +----------------------------+ +----------------+
|Visited Network | |Home Network | |Visited Network | |Home Network |
| +----+ +--------+ | Signaling | +--------+ | | +----+ +--------+ | Signaling | +--------+ |
| | UE |=======>|SGSN/MME|------------------->|HLR/HSS | | | | UE |=======>|SGSN/MME|------------------->|HLR/HSS | |
| +----+ +--------+ | (GRX/IPX) | +--------+ | | +----+ +---+----+ | (GRX/IPX) | +--------+ |
| || | | | | |SGW| | | |
| +--------+ | | | | +---+ | | |
| |GGSN/PGW| | | | | || | | |
| +--------+ | | | | +--------+ | | |
| Traffic Flow || | | | | |GGSN/PGW| | | |
+--------------------||------+ +----------------+ | +--------+ | | |
| Traffic Flow || | | |
+------------------||--------+ +----------------+
\/ \/
Figure 2: Local Breakout Figure 2: Local Breakout
The international roaming of IP Multimedia Subsystem (IMS) based The international roaming of services based on the IP Multimedia
services, e.g., Voice over LTE (VoLTE)[IR.92], is claimed to select Subsystem (IMS), e.g., Voice over LTE (VoLTE)[IR.92], is claimed to
the local breakout mode in [IR.65]. Data service roaming across select the local breakout mode in [IR.65]. Data service roaming
different areas within an operator network might use local breakout across different areas within an operator network might use local
mode in order to get more efficient traffic forwarding and also ease breakout mode in order to get more efficient traffic forwarding and
emergency services. The local breakout mode could also be applied to also ease emergency services. The local breakout mode could also be
an operator's alliance for international roaming of data service. applied to an operator's alliance for international roaming of data
service.
EU Roaming Regulation III [EU-Roaming-III] involves local breakout EU Roaming Regulation III [EU-Roaming-III] involves local breakout
mode allowing European subscribers roaming in European 2G/3G networks mode allowing European subscribers roaming in European 2G/3G networks
to have their Internet data routed directly to the Internet from to have their Internet data routed directly to the Internet from
their current VPLMN. their current Visited Public Land Mobile Network (VPLMN).
Specific local breakout-related configuration considerations are Specific local breakout-related configuration considerations are
listed below: listed below:
o Operators may add the APN-OI-Replacement flag defined in 3GPP o Operators may add the APN-OI-Replacement flag defined in 3GPP
[TS29.272] into the user's subscription-data. The visited network [TS29.272] into the user's subscription data. The visited network
indicates a local domain name to replace the user requested Access indicates a local domain name to replace the user requested Access
Point Name (APN). Consequently, the traffic would be steered to Point Name (APN). Consequently, the traffic would be steered to
the visited network. Those functions are normally deployed for the visited network. Those functions are normally deployed for
the intra-PLMN mobility cases. the intra-PLMN mobility cases.
o Operators may also configure the VPLMN-Dynamic-Address-Allowed o Operators may also configure the VPLMN-Dynamic-Address-Allowed
flag [TS29.272] in the user's profile to enable local breakout flag [TS29.272] in the user's profile to enable local breakout
mode in Visited Public Land Mobile Networks (VPLMNs). mode in VPLMNs.
o 3GPP specified Selected IP Traffic Offload (SIPTO) function o 3GPP specified the Selected IP Traffic Offload (SIPTO) function
[TS23.401] since Release 10 in order to get efficient route paths. [TS23.401] since Release 10 in order to get efficient route paths.
It enables an operator to offload a portion of the traffic at a It enables an operator to offload a portion of the traffic at a
network node close to the visiting UE's point of attachment to the network node close to the UE's point of attachment to the network.
visited network.
o GSMA has defined Roaming Architecture for Voice over LTE with o The Global System for Mobile Communications Association (GSMA) has
Local Breakout (RAVEL) [IR.65] as the IMS international roaming defined Roaming Architecture for Voice over LTE with Local
Breakout (RAVEL) [IR.65] as the IMS international roaming
architecture. Local breakout mode has been adopted for the IMS architecture. Local breakout mode has been adopted for the IMS
roaming architecture. roaming architecture.
2.2. Typical Roaming Scenarios 2.2. Typical Roaming Scenarios
Three stages occur when a subscriber roams to a visited network and Three stages occur when a subscriber roams to a visited network and
intends to invoke services: intends to invoke services:
o Network attachment: this occurs when the UE enters a visited o Network attachment: this occurs when the UE enters a visited
network. During the attachment phase, the visited network should network. During the attachment phase, the visited network should
authenticate the subscriber and make a location update to the HSS/ authenticate the subscriber and make a location update to the
HLR in the home network of the subscriber. Accordingly, the HSS/HLR in the home network of the subscriber. Accordingly, the
subscriber profile is offered from the HSS/HLR. The subscriber subscriber profile is offered from the HSS/HLR. The subscriber
profile contains the allowed Access Point Names (APN), the allowed profile contains the allowed APNs, the allowed PDP/PDN Types, and
PDP/PDN Types and rules regarding the routing of data sessions rules regarding the routing of data sessions (i.e., home routed or
(i.e., home routed or local breakout mode) [TS29.272]. The SGSN/ local breakout mode) [TS29.272]. The SGSN/MME in the visited
MME in the visited network can use this information to facilitate network can use this information to facilitate the subsequent
the subsequent PDP/PDN session creation. PDP/PDN session creation.
o PDP/PDN context creation: this occurs after the subscriber UE has o PDP/PDN context creation: this occurs after the subscriber's UE
been successfully attached to the network. This stage is has been successfully attached to the network. This stage is
integrated with the attachment stage in the case of 4G, but is a integrated with the attachment stage in the case of 4G, but is a
separate process in 2/3G. 3GPP specifies three types of PDP/PDN to separate process in 2G/3G. 3GPP specifies three types of PDP/PDN
describe connections, i.e., PDP/PDN Type IPv4, PDP/PDN Type IPv6 to describe connections: PDP/PDN Type IPv4, PDP/PDN Type IPv6, and
and PDP/ PDN Type IPv4v6. When a subscriber creates a data PDP/PDN Type IPv4v6. When a subscriber creates a data session,
session, their device requests a particular PDP/PDN Type. The their device requests a particular PDP/PDN Type. The allowed
allowed PDP/PDN types for that subscriber are learned in the PDP/PDN Types for that subscriber are learned in the attachment
attachment stage. Hence, SGSN/MME could initiate PDP/PDN request stage. Hence, the SGSN and MME via the Serving Gateway (SGW)
to GGSN/PGW modulo subscription grants. could initiate a PDP/PDN request to Gateway GSN (GGSN) / Packet
Data Network Gateway (PGW) modulo subscription grants.
o Service requests: when the PDP/PDN context is created o Service requests: when the PDP/PDN context is created
successfully, UEs may launch applications and request services successfully, UEs may launch applications and request services
based on the allocated IP addresses. The service traffic will be based on the allocated IP addresses. The service traffic will be
transmitted via the visited network. transmitted via the visited network.
Failures that occur at the attachment stage (Section 3) are Failures that occur at the attachment stage (Section 3) are
independent of home routed and the local breakout mode. Most failure independent of home routed and the local breakout modes. Most
cases in the PDP/PDN context creation (Section 4) and service failure cases in the PDP/PDN context creation (Section 4) and in
requests (Section 5) occur in the local breakout mode. service requests (Section 5) occur in the local breakout mode.
3. Failure Case in the Network Attachment 3. Failure Case in the Network Attachment
3GPP specified PDP/PDN type IPv4v6 in order to allow a UE get both an 3GPP specified PDP/PDN Type IPv4v6 in order to allow a UE to get both
IPv4 address and an IPv6 prefix within a single PDP/PDN bearer. This an IPv4 address and an IPv6 prefix within a single PDP/PDN bearer.
option is stored as a part of subscription data for a subscriber in This option is stored as a part of subscription data for a subscriber
the HLR/HSS. PDP/PDN type IPv4v6 has been introduced at the in the HLR/HSS. PDP/PDN Type IPv4v6 has been introduced at the
inception of Evolved Packet System (EPS) in 4G networks. inception of the Evolved Packet System (EPS) in 4G networks.
The nodes in 4G networks should present no issues with the handling The nodes in 4G networks should present no issues with the handling
of this PDN type. However, the level of support varies in 2/3G of this PDN Type. However, the level of support varies in 2G/3G
networks depending on SGSN software version. In theory, S4-SGSN networks depending on the SGSN software version. In theory, S4-SGSN
(i.e., an SGSN with S4 interface) supports the PDP/PDN type IPv4v6 (i.e., an SGSN with S4 interface) has supported the PDP/PDN Type
since Release 8 and a Gn-SGSN (i.e., the SGSN with Gn interface) IPv4v6 since Release 8, and Gn-SGSN (i.e., the SGSN with Gn
supports it since Release 9. In most cases, operators normally use interface) has supported it since Release 9. In most cases,
Gn-SGSN to connect either GGSN in 3G or Packet Data Network Gateway operators normally use Gn-SGSN to connect either GGSN in 3G or Packet
(PGW) in 4G. Data Network Gateway (PGW) in 4G.
The MAP (Mobile Application Part) protocol, as defined in 3GPP The MAP (Mobile Application Part) protocol, as defined in 3GPP
[TS29.002], is used over the Gr interface between SGSN and HLR. The [TS29.002], is used over the Gr interface between SGSN and HLR. The
MAP Information Element (IE) "ext-pdp-Type" contains the IPv4v6 PDP MAP Information Element (IE) "ext-pdp-Type" contains the IPv4v6 PDP
Type that is conveyed to SGSN from the HLR within the Insert Type that is conveyed to SGSN from the HLR within the Insert
Subscriber Data (ISD) MAP operation. If the SGSN does not support Subscriber Data (ISD) MAP operation. If the SGSN does not support
the IPv4v6 PDP Type, it will not support the "ext-pdp-Type" IE and the IPv4v6 PDP Type, it will not support the "ext-pdp-Type" IE;
consequently it must silently discard that IE and continue processing consequently, it must silently discard that IE and continue
of the rest of the ISD MAP message. An issue that has been observed processing the rest of the ISD MAP message. An issue that has been
is that multiple SGSNs are unable to correctly process a subscriber's observed is that multiple SGSNs are unable to correctly process a
data received in the Insert Subscriber Data Procedure [TS23.060]. As subscriber's data received in the Insert Subscriber Data Procedure
a consequence, it will likely discard the subscriber attach request. [TS23.060]. As a consequence, it will likely discard the subscriber
This is erroneous behavior due to the equipment not being compliant attach request. This is erroneous behavior due to the equipment not
with 3GPP Release 9. being compliant with 3GPP Release 9.
In order to avoid encountering this attach problem at a visited SGSN, In order to avoid encountering this attach problem at a visited SGSN,
both operators should make a comprehensive roaming agreement to both operators should make a comprehensive roaming agreement to
support IPv6 and ensure that it aligns with the GSMA documents, e.g., support IPv6 and ensure that it aligns with the GSMA documents, e.g.,
[IR.33], [IR.88], and [IR.21]. Such an agreement requires the
[IR.33], [IR.88] and [IR.21]. Such an agreement requires the visited visited operator to get the necessary patch on all its SGSN nodes to
operator to get the necessary patch on all its SGSN nodes to support support the "ext-pdp-Type" MAP IE sent by the HLR. To ensure data-
the "ext-pdp-Type" MAP IE sent by the HLR. To ensure data session session continuity in Radio Access Technology (RAT) handovers, the
continuity in Radio Access Technology (RAT) handovers the PDN Type PDN Type sent by the HSS to the MME should be consistent with the PDP
sent by the HSS to the MME could be consistent with the PDP Type sent Type sent by the HLR to the Gn-SGSN. Where roaming agreements and
by the HLR to the Gn-SGSN. Where roaming agreements and visited SGSN visited SGSN nodes have not been updated, the HPLMN also has to make
nodes have not been updated, the HPLMN also has to make use of use of specific implementations (not standardized by 3GPP, discussed
specific implementations (not standardized by 3GPP, discussed further further in Section 6) in the HLR/HSS of the home network. That is,
in Section 6) in the HLR/HSS of the home network. That is, when the when the HLR/HSS receives an Update Location message from a visited
HLR/HSS receives an Update Location message from a visited SGSN not SGSN not known to support dual-stack in a single bearer, subscription
known to support dual-stack in a single bearer, subscription data data allowing only PDP/PDN Type IPv4 or IPv6 will be sent to that
allowing only PDP/PDN type IPv4 or IPv6 will be sent to that SGSN in SGSN in the Insert Subscriber Data procedure. This guarantees that
the Insert Subscriber Data procedure. This guarantees that the user the user profile is compatible with the visited SGSN/MME capability.
profile is compatible with the visited SGSN/MME capability. In In addition, HSS may not have to change if the PGW is aware of the
addition, HSS may not have to change, if the PGW is aware of subscriber's roaming status and only restricts the accepted PDN Type
subscriber's roaming status and only restricts the accepted PDN type consistent with PDP Type sent by the HLR. For example, a AAA server
consistent with PDP type sent by the HLR. For example, an AAA server may coordinate with the PGW to decide the allowed PDN Type.
may coordinate with the PGW to decide the allowed PDN type.
Alternatively, HPLMNs without the non-standardized capability to Alternatively, HPLMNs without the non-standardized capability to
suppress the sending of "ext-pdp-Type" by the HLR may have to remove suppress the sending of "ext-pdp-Type" by the HLR may have to remove
this attribute from APNs with roaming service. PDN Type IPv4v6 must this attribute from APNs with roaming service. PDN Type IPv4v6 must
also be removed from the corresponding profile for the APN in the also be removed from the corresponding profile for the APN in the
HSS. This will restrict their roaming UEs to only IPv4 or IPv6 PDP/ HSS. This will restrict their roaming UEs to only IPv4 or IPv6
PDN activation. This alternative has problems: PDP/PDN activation. This alternative has problems:
o The HPLMN cannot support dual-stack in a single bearer at home o The HPLMN cannot support dual-stack in a single bearer at home
either where the APN profile in the HLR/HSS is also used for where the APN profile in the HLR/HSS is also used for roaming.
roaming.
o The UE may set-up separate parallel bearers for IPv4 and IPv6 o The UE may set up separate parallel bearers for IPv4 and IPv6,
where only single stack IPv4 or IPv6 service is preferred by the where only single-stack IPv4 or IPv6 service is preferred by the
operator. operator.
4. Failure Cases in the PDP/PDN Creation 4. Failure Cases in the PDP/PDN Creation
When a subscriber's UE succeeds in the attach stage, the IP When a subscriber's UE succeeds in the attach stage, the IP
allocation process takes place to retrieve IP addresses. In general, allocation process takes place to retrieve IP addresses. In general,
a PDP/PDN type IPv4v6 request implicitly allows the network side to a PDP/PDN Type IPv4v6 request implicitly allows the network side to
make several IP assignment options, including IPv4-only, IPv6-only, make several IP assignment options, including IPv4-only, IPv6-only,
IPv4 and IPv6 in single PDP/PDN bearer, IPv4 and IPv6 in separated IPv4 and IPv6 in single PDP/PDN bearer, and IPv4 and IPv6 in
PDP/PDN bearers. separated PDP/PDN bearers.
A PDP/PDN type IPv4 or IPv6 restricts the network side to only A PDP/PDN Type IPv4 or IPv6 restricts the network side to only
allocate requested IP address family. allocate the requested IP address family.
This section summarizes several failures in the Home Routed (HR) and This section summarizes several failures in the Home Routed (HR) and
Local Breakout (LBO) mode as shown in Table 1. Local Breakout (LBO) mode as shown in Table 1.
+-------+-------------+------------------------+---------+ +-------+-------------+------------------------+---------+
| Case# | UE request | PDP/PDN IP Type | Mode | | Case# | UE request | PDP/PDN IP Type | Mode |
| | | permitted on GGSN/PGW | | | | | permitted on GGSN/PGW | |
+-------+-------------+------------------------+---------+ +-------+-------------+------------------------+---------+
| | IPv4v6 | IPv4v6 | HR | | | IPv4v6 | IPv4v6 | HR |
| #1 |-------------+------------------------+---------+ | #1 |-------------+------------------------+---------+
skipping to change at page 9, line 22 skipping to change at page 9, line 37
+-------+-------------+------------------------+---------+ +-------+-------------+------------------------+---------+
| #2 | IPv6 | IPv6 | HR | | #2 | IPv6 | IPv6 | HR |
+-------+-------------+------------------------+---------+ +-------+-------------+------------------------+---------+
| #3 | IPv4 | IPv6 | HR | | #3 | IPv4 | IPv6 | HR |
+-------+-------------+------------------------+---------+ +-------+-------------+------------------------+---------+
| #4 | IPv6 | IPv4 | LBO | | #4 | IPv6 | IPv4 | LBO |
+-------+-------------+------------------------+---------+ +-------+-------------+------------------------+---------+
Table 1: Failure Cases in the PDP/PDN Creation Table 1: Failure Cases in the PDP/PDN Creation
4.1. Case 1: Splitting Dual-stack Bearer 4.1. Case 1: Splitting Dual-Stack Bearer
Dual-stack capability is provided using separate PDP/PDN activation Dual-stack capability is provided using separate PDP/PDN activation
in the visited network that doesn't support PDP/PDN type IPv4v6. in the visited network that doesn't support PDP/PDN Type IPv4v6.
That means only separate parallel single-stack IPv4 and IPv6 PDP/PDN That means only separate, parallel, single-stack IPv4 and IPv6
connections are allowed to be initiated to separately allocate an PDP/PDN connections are allowed to be initiated to separately
IPv4 address and an IPv6 prefix. The SGSN does not support the Dual allocate an IPv4 address and an IPv6 prefix. The SGSN does not
Address Bearer Flag (DAF) or does not set DAF because the operator support the Dual Address Bearer Flag (DAF) or does not set the DAF
uses single addressing per bearer to support interworking with nodes because the operator uses single addressing per bearer to support
of earlier releases. Regardless of home routed or local breakout interworking with nodes of earlier releases. Regardless of home
mode, GGSN/PGW will change PDN/PDP type to a single address PDP/PDN routed or local breakout mode, GGSN/PGW will change PDN/PDP Type to a
type and return the Session Management (SM) Cause #52 "Single address single address PDP/PDN Type and return the Session Management (SM)
bearers only allowed" or SM Cause #28 "Unknown PDP address or PDP Cause #52 "single address bearers only allowed" or SM Cause #28
type" as per [TS24.008] and [TS24.301] to the UE. In this case, the "unknown PDP address or PDP type" as per [TS24.008] and [TS24.301] to
UE may make another PDP/PDN request with a single address PDP type the UE. In this case, the UE may make another PDP/PDN request with a
(IPv4 or IPv6) other than the one already activated. single address PDP Type (IPv4 or IPv6) other than the one already
activated.
This approach suffers from the followings drawbacks: This approach suffers from the following drawbacks:
o The parallel PDP/PDN activation would likely double PDP/PDN bearer o The parallel PDP/PDN activation would likely double PDP/PDN bearer
resource on the network side and Radio Access Bearer (RAB) resource on the network side and Radio Access Bearer (RAB)
resource on the RAN side. It also impacts the capacity of the resource on the Radio Access Network (RAN) side. It also impacts
GGSN/PGW, since only a certain amount of PDP/PDN activation is the capacity of the GGSN/PGW, since only a certain amount of
allowed on those nodes. PDP/PDN activation is allowed on those nodes.
o Some networks may only allow one PDP/PDN be alive for each o Some networks may allow only one PDP/PDN to be alive for each
subscriber. For example, an IPv6 PDP/PDN will be rejected if the subscriber. For example, an IPv6 PDP/PDN will be rejected if the
subscriber has an active IPv4 PDP/PDN. Therefore, the subscriber subscriber has an active IPv4 PDP/PDN. Therefore, the subscriber
would not be able to obtain the IPv6 connection in the visited would not be able to obtain the IPv6 connection in the visited
network. It is even worse as they may have a risk of losing all network. It is even worse, as they may have a risk of losing all
data connectivity if the IPv6 PDP gets rejected with a permanent data connectivity if the IPv6 PDP gets rejected with a permanent
error at the APN-level and not an error specific to the PDP-Type error at the APN level and not an error specific to the PDP-Type
IPv6 requested. IPv6 requested.
o Additional correlations between those two PDP/PDN contexts are o Additional correlations between those two PDP/PDN contexts are
required on the charging system. required on the charging system.
o Policy and Charging Rules Function (PCRF) [TS29.212]/ Policy and o Policy and Charging Rules Function (PCRF) [TS29.212] / Policy and
Charging Enforcement Function (PCEF) treats the IPv4 and IPv6 Charging Enforcement Function (PCEF) treats the IPv4 and IPv6
session as independent and performs different Quality of Service sessions as independent and performs different quality-of-service
(QoS) policies. The subscriber may have unstable experiences due (QoS) policies. The subscriber may have an unstable experience
to different behaviors on each IP version connection. due to different behaviors on each IP version connection.
o Mobile devices may have a limitation on allowed simultaneous PDP/ o Mobile devices may have a limitation on the number of allowed
PDN contexts. Excessive PDP/PDN activation may result in service simultaneous PDP/PDN contexts. Excessive PDP/PDN activations may
disruption. result in service disruption.
In order to avoid the issue, the roaming agreement in the home routed In order to avoid the issue, the roaming agreement in the home routed
mode should make sure the visited SGSN supports and set the DAF. mode should make sure the visited SGSN supports and sets the DAF.
Since the PDP/PDN type IPv4v6 is supported in the GGSN/PGW of home Since the PDP/PDN Type IPv4v6 is supported in the GGSN/PGW of the
network, it's expected that the visited SGSN/MME could create dual- home network, it's expected that the visited SGSN/MME could create a
stack bearer as UE requested. dual-stack bearer as the UE requested.
In the local breakout mode, the visited SGSN may only allow single IP In the local breakout mode, the visited SGSN may only allow single IP
version addressing. In this case, DAF on visited SGSN/MME has to be version addressing. In this case, the DAF on the visited SGSN/MME
unset. One approach is to set a dedicated Access Point Name (APN) has to be unset. One approach is to set a dedicated APN [TS23.003]
[TS23.003] profile to only request PDP/PDN type IPv4 in the roaming profile to only request PDP/PDN Type IPv4 in the roaming network.
network. Some operators may also consider not adopting the local Some operators may also consider not adopting the local breakout mode
breakout mode to avoid the risks. to avoid the risks.
4.2. Case 2: IPv6 PDP/PDN Unsupported 4.2. Case 2: IPv6 PDP/PDN Unsupported
PDP/PDN type IPv6 has good compatibility to visited networks during PDP/PDN Type IPv6 has good compatibility to visited networks during
the network attachment. In order to support the IPv6-only visitors, the network attachment. In order to support the IPv6-only visitors,
SGSN/MME in the visited network is required to accept IPv6-only PDP/ SGSN/MME in the visited network is required to accept IPv6-only
PDN activation requests and enable IPv6 on user plane towards the PDP/PDN activation requests and enable IPv6 on the user plane in the
home network. direction of the home network.
In some cases, IPv6-only visitors may still be subject to the SGSN In some cases, IPv6-only visitors may still be subject to the SGSN
capability in visited networks. This becomes especially risky if the capability in visited networks. This becomes especially risky if the
home operator performs roaming steering targeted to an operator that home operator performs roaming steering targeted to an operator that
doesn't allow IPv6. The visited SGSN may just directly reject the doesn't allow IPv6. The visited SGSN may just directly reject the
PDP context activation. Therefore, it's expected that visited PDP context activation. Therefore, it's expected that the visited
network is IPv6 roaming-friendly to enable the functions on SGSN/MME network is IPv6 roaming-friendly to enable the functions on SGSN/MME
by default. Otherwise, operators may consider steering the roaming by default. Otherwise, operators may consider steering the roaming
traffic to the IPv6-enable visited network that has IPv6 roaming traffic to the IPv6-enabled visited network that has an IPv6 roaming
agreement. agreement.
4.3. Case 3: Inappropriate Roaming APN Set 4.3. Case 3: Inappropriate Roaming APN Set
If IPv6 single stack with the home routed mode is deployed, the If IPv6 single stack with the home routed mode is deployed, the
requested PDP/PDN type should also be IPv6. Some implementations requested PDP/PDN Type should also be IPv6. Some implementations
that support roaming APN profile may set IPv4 as the default PDP/PDN that support the roaming APN profile may set IPv4 as the default
type, since the visited network is incapable of supporting PDP/PDN PDP/PDN Type, since the visited network is incapable of supporting
types IPv4v6 (Section 4.1) and IPv6 (Section 4.2). The PDP/PDN PDP/PDN Types IPv4v6 (Section 4.1) and IPv6 (Section 4.2). The
request will fail because the APN in the home network only allows PDP/PDN request will fail because the APN in the home network only
IPv6. Therefore, the roaming APN have to be compliant with the home allows IPv6. Therefore, the roaming APNs have to be compliant with
network configuration when home routed mode is adopted. the home network configuration when home routed mode is adopted.
4.4. Case 4: Fallback Failure 4.4. Case 4: Fallback Failure
In the local breakout mode, PDP/PDN type IPv6 should have no issues In the local breakout mode, PDP/PDN Type IPv6 should have no issues
to pass through network attachment process, since 3GPP specified the to pass through the network attachment process, since 3GPP specified
PDP/PDN type IPv6 as early as PDP/PDN type IPv4. When a visitor the PDP/PDN Type IPv6 as early as PDP/PDN Type IPv4. When a visitor
requests PDP/PDN type IPv6, the network should only return the requests PDP/PDN Type IPv6, the network should only return the
expected IPv6 prefix. The UE may fail to get an IPv6 prefix if the expected IPv6 prefix. The UE may fail to get an IPv6 prefix if the
visited network only allocates an IPv4 address. In this case, the visited network only allocates an IPv4 address. In this case, the
visited network will reject the request and send the cause code to visited network will reject the request and send the cause code to
the UE. the UE.
A proper fallback scheme for PDP/PDN type IPv6 is desirable, however A proper fallback scheme for PDP/PDN Type IPv6 is desirable; however,
there is no standard way to specify this behavior. Roaming APN there is no standard way to specify this behavior. The roaming APN
profile could help to address the issue by setting PDP/PDN type IPv4. profile could help to address the issue by setting the PDP/PDN Type
For instance, the Android system solves the issue by configuring the to IPv4. For instance, the Android system solves the issue by
roaming protocol to IPv4 for the Access Point Name (APN). It configuring the roaming protocol to IPv4 for the APN. It guarantees
guarantees that UE will always initiate a PDP/PDN type IPv4 in the that UE will always initiate a PDP/PDN Type IPv4 in the roaming area.
roaming area.
5. Failure Cases in the Service Requests 5. Failure Cases in the Service Requests
After the successful network attachment and IP address allocation, After the successful network attachment and IP address allocation,
applications could start to request service based on the activated applications could start to request service based on the activated
PDP/PDN context. The service request may depend on specific IP PDP/PDN context. The service request may depend on specific IP
family or network collaboration. If traffic is offloaded locally family or network collaboration. If traffic is offloaded locally
(Section 2.1.2 ), the visited network may not be able to accommodate (Section 2.1.2), the visited network may not be able to accommodate
UE's service requests. This section describes the failures. the UE's service requests. This section describes the failures.
5.1. Lack of IPv6 Support in Applications 5.1. Lack of IPv6 Support in Applications
Operators may only allow IPv6 in the IMS APN. VoLTE [IR.92] or Rich Operators may only allow IPv6 in the IMS APN. VoLTE [IR.92] and Rich
Communication Suite (RCS) [RCC.07] use the APN to offer the voice Communication Suite (RCS) [RCC.07] use the APN to offer voice service
service for visitors. The IMS roaming in RAVEL architecture [IR.65] for visitors. The IMS roaming in RAVEL architecture [IR.65] offloads
offloads voice and video traffic in the visited network, therefore a voice and video traffic in the visited network; therefore, a dual-
dual-stack visitor can only be assigned with an IPv6 prefix but no stack visitor can only be assigned with an IPv6 prefix but no IPv4
IPv4 address. If the applications can't support IPv6, the service is address. If the applications can't support IPv6, the service is
likely to fail. likely to fail.
Translation-based methods, for example 464xlat [RFC6877] or Bump-in- Translation-based methods, for example, 464XLAT [RFC6877] or Bump-in-
the-host (BIH) [RFC6535], may help to address the issue if there are the-Host (BIH) [RFC6535], may help to address the issue if there are
IPv6 compatibility problems. The translation function could be IPv6 compatibility problems. The translation function could be
enabled in an IPv6-only network and disabled in a dual-stack or IPv4 enabled in an IPv6-only network and disabled in a dual-stack or IPv4
network, therefore the IPv4 applications only get the translation in network; therefore, the IPv4 applications only get the translation in
the IPv6 network and perform normally in an IPv4 or dual-stack the IPv6 network and they perform normally in an IPv4 or dual-stack
network. network.
5.2. 464xlat Support 5.2. 464XLAT Support
464xlat[RFC6877] is proposed to address the IPv4 compatibility issue 464XLAT [RFC6877] is proposed to address the IPv4 compatibility issue
in an IPv6-only connectivity environment. The customer-side in an IPv6-only connectivity environment. The customer-side
translator (CLAT) function on a mobile device is likely used in translator (CLAT) function on a mobile device is likely used in
conjunction with a PDP/PDN IPv6 type request and cooperates with a conjunction with a PDP/PDN IPv6 Type request and cooperates with a
remote NAT64 [RFC6146] device. remote NAT64 [RFC6146] device.
464xlat may use the mechanism defined in [RFC7050] or [RFC7225] to 464XLAT may use the mechanism defined in [RFC7050] or [RFC7225] to
detect the presence of NAT64 devices and to learn the IPv6 prefix detect the presence of NAT64 devices and to learn the IPv6 prefix
used for protocol translation[RFC6052]. used for protocol translation [RFC6052].
In the local breakout approach, when a UE with the 464xlat function In the local breakout approach, a UE with the 464XLAT function
roaming on an IPv6 visited network may encounter various situations. roaming on an IPv6 visited network may encounter various situations.
For example, the visited network may not deploy DNS64 [RFC6147] but For example, the visited network may not have deployed DNS64
only NAT64, CLAT may not be able to discover the provider-side [RFC6147] but only NAT64, or CLAT may not be able to discover the
translator (PLAT) translation IPv6 prefix used as a destination of provider-side translator (PLAT) translation IPv6 prefix used as a
the PLAT. If the visited network doesn't deploy NAT64 and DNS64, destination of the PLAT. If the visited network doesn't have a NAT64
464xlat can't perform successfully due to the lack of PLAT and DNS64 deployed, 464XLAT can't perform successfully due to the
collaboration. Even in the case of the presence of NAT64 and DNS64, lack of PLAT collaboration. Even in the case of the presence of
pre-configured PLAT-side IPv6 prefix in the CLAT may cause the NAT64 and DNS64, a pre-configured PLAT IPv6 prefix in the CLAT may
failure because it can't match the PLAT translation. cause failure because it can't match the PLAT translation.
Considering the various network's situations, operators may turn off Considering the various network configurations, operators may turn
local breakout and use the home routed mode to perform 464xlat. off local breakout and use the home routed mode to perform 464XLAT.
Alternatively, UE may support the different roaming profile Alternatively, UE may support the different roaming profile
configurations to adopt 464xlat in the home networks and use configuration to adopt 464XLAT in the home network and use IPv4-only
IPv4-only in the visited networks. in the visited networks.
6. HLR/HSS User Profile Setting 6. HLR/HSS User Profile Setting
A proper user profile configuration would provide a deterministic A proper user profile configuration would provide a deterministic
outcome to the PDP/PDN creation stage where dual-stack, IPv4-only and outcome to the PDP/PDN creation stage where dual-stack, IPv4-only,
IPv6-only connectivity requests may come from devices. The HLR/HSS and IPv6-only connectivity requests may come from devices. The
may have to apply extra logic (not standardized by 3GPP) to achieve HLR/HSS may have to apply extra logic (not standardized by 3GPP) to
this. It is also desirable that the network could set-up achieve this. It is also desirable that the network be able to set
connectivity of any requested PDP/PDN context type. up connectivity of any requested PDP/PDN context type.
The following are examples to illustrate the settings for the The following are examples to illustrate the settings for the
scenarios and decision criteria to apply when returning user profile scenarios and the decision criteria to be applied when returning user
information to the visited SGSN. profile information from the HLR to the visited SGSN.
user profile #1: user profile #1:
PDP-Context ::= SEQUENCE { PDP-Context ::= SEQUENCE {
pdp-ContextId ContextId, pdp-ContextId ContextId,
pdp-Type PDP-Type-IPv4 pdp-Type PDP-Type-IPv4
.... ....
ext-pdp-Type PDP-Type-IPv4v6 ext-pdp-Type PDP-Type-IPv4v6
... ...
} }
user profile #2: user profile #2:
PDP-Context ::= SEQUENCE { PDP-Context ::= SEQUENCE {
pdp-ContextId ContextId, pdp-ContextId ContextId,
pdp-Type PDP-Type-IPv6 pdp-Type PDP-Type-IPv6
.... ....
} }
Scenario 1: Support of IPv6-only, IPv4-only and dual-stack devices. Scenario 1: Support of IPv6-Only, IPv4-Only, and Dual-Stack Devices
The full PDP-context parameters are referred to Section 17.7.1 The full PDP-context parameters are referred to Section 17.7.1
"Mobile Service date types" of [TS29.002]. User profiles #1 and #2 ("Mobile Service data types") of [TS29.002]. User profiles #1 and #2
share the same "ContextId". The setting of user profile #1 enables share the same "ContextId". The setting of user profile #1 enables
IPv4-only and dual-stack devices to work. And, the user profile #2 IPv4-only and dual-stack devices to work. User profile #2 fulfills
fulfills the request if the device asks for IPv6 only PDP context. the request if the device asks for IPv6-only PDP context.
user profile #1: user profile #1:
PDP-Context ::= SEQUENCE { PDP-Context ::= SEQUENCE {
pdp-ContextId ContextId, pdp-ContextId ContextId,
pdp-Type PDP-Type-IPv4 pdp-Type PDP-Type-IPv4
.... ....
ext-pdp-Type PDP-Type-IPv4v6 ext-pdp-Type PDP-Type-IPv4v6
... ...
} }
user profile #2: user profile #2:
PDP-Context ::= SEQUENCE { PDP-Context ::= SEQUENCE {
pdp-ContextId ContextId, pdp-ContextId ContextId,
pdp-Type PDP-Type-IPv4 pdp-Type PDP-Type-IPv4
.... ....
} }
Scenario 2: Support of dual-stack devices with pre-R9 vSGSN access. Scenario 2: Support of Dual-Stack Devices with Pre-Release 9 Visited
SGSN (vSGSN) Access
User profiles #1 and #2 share the same "ContextId". If a visited User profiles #1 and #2 share the same "ContextId". If a visited
SGSN is identified as early as pre-Release 9, the HLR/HSS should only SGSN is identified as early as pre-Release 9, the HLR/HSS should only
send user profile#2 to the visited SGSN. send user profile #2 to the visited SGSN.
7. Discussion 7. Discussion
Several failure cases have been discussed in this document. It has Several failure cases have been discussed in this document. It has
been illustrated that the major problems happen at three stages, been illustrated that the major problems happen at three stages: the
i.e., the initial network attachment, the PDP/PDN creation and initial network attachment, the PDP/PDN creation, and service
service requests. requests.
In the network attachment stage, PDP/PDN type IPv4v6 is the major In the network attachment stage, PDP/PDN Type IPv4v6 is the major
concern to the visited pre-Release 9 SGSN. 3GPP didn't specify PDP/ concern to the visited pre-Release 9 SGSN. 3GPP didn't specify
PDN type IPv4v6 in the earlier releases. That PDP/PDN type is PDP/PDN Type IPv4v6 in the earlier releases. That PDP/PDN Type is
supported in new-built EPS network, but isn't supported well in the supported in the newly built EPS network, but it isn't supported well
third generation network. Visited SGSNs may discard the subscriber's in the third-generation network. Visited SGSNs may discard the
attach requests because the SGSN is unable to correctly process PDP/ subscriber's attach requests because the SGSN is unable to correctly
PDN type IPv4v6. Operators may have to adopt temporary solutions process PDP/PDN Type IPv4v6. Operators may have to adopt temporary
unless all the interworking nodes (i.e., the SGSN) in the visited solutions unless all the interworking nodes (i.e., the SGSN) in the
network have been upgraded to support the ext-PDP-Type feature. visited network have been upgraded to support the ext-PDP-Type
feature.
In the PDP/PDN creation stage, PDP/PDN types IPv4v6 and IPv6 support In the PDP/PDN creation stage, support of PDP/PDN Types IPv4v6 and
on the visited SGSN is the major concern. It has been observed that IPv6 on the visited SGSN is the major concern. It has been observed
IPv6 single stack with the home routed mode is a viable approach to that single-stack IPv6 in the home routed mode is a viable approach
deploy IPv6. It is desirable that the visited SGSN could enable IPv6 to deploy IPv6. It is desirable that the visited SGSN have the
on the user plane by default. For support of the PDP/PDN type ability to enable IPv6 on the user plane by default. For support of
IPv4v6, it is suggested to set the DAF. As a complementary function, the PDP/PDN Type IPv4v6, it is suggested to set the DAF. As a
the implementation of roaming APN configuration is useful to complementary function, the implementation of a roaming APN
accommodate the visited network. However, it should consider roaming configuration is useful to accommodate the visited network. However,
architecture and permitted PDP/PDN type to make proper setting on the it should consider roaming architecture and the permitted PDP/PDN
UE. Roaming APN in the home routed mode is recommended to align with Type to properly set the UE. Roaming APN in the home routed mode is
home network profile setting. In the local breakout case, PDP/PDN recommended to align with home network profile setting. In the local
type IPv4 could be selected as a safe way to initiate PDP/PDN breakout case, PDP/PDN Type IPv4 could be selected as a safe way to
activation. initiate PDP/PDN activation.
In the service requests stage, the failure cases mostly occur in the In the service requests stage, the failure cases mostly occur in the
local breakout case. The visited network may not be able to satisfy local breakout case. The visited network may not be able to satisfy
the requested capability from applications or UEs. Operators may the requested capability from applications or UEs. Operators may
consider using home routed mode to avoid these problems. Several consider using home routed mode to avoid these problems. Several
solutions either in the network side or mobile device side can also solutions, in either the network side or mobile device side, can also
help to address the issue. For example, help to address the issue. For example,
o 464xlat could help IPv4 applications access IPv6 visited networks. o 464XLAT could help IPv4 applications access IPv6 visited networks.
o Networks can deploy an AAA server to coordinate the mobile device o Networks can deploy a AAA server to coordinate the mobile device
capability. Once the GGSN/PGW receives the session creation capability. Once the GGSN/PGW receives the session creation
request, it will initiate an Access-Request to an AAA server in request, it will initiate a request to a AAA server in the home
the home network via the RADIUS protocol. The Access-Request network via the RADIUS or Diameter protocol [TS29.061]. The
contains subscriber and visited network information, e.g., PDP/PDN request contains subscriber and visited network information, e.g.,
Type, International Mobile Equipment Id (IMEI), Software Version PDP/PDN Type, International Mobile Equipment Identity (IMEI),
(SV) and visited SGSN/MME location code, etc. The AAA server Software Version (SV) and visited SGSN/MME location code, etc.
could take mobile device capability and combine it with the The AAA server could take mobile device capability and combine it
visited network information to ultimately determine the type of with the visited network information to ultimately determine the
session to be created, i.e., IPv4, IPv6 or IPv4v6. type of session to be created, i.e., IPv4, IPv6, or IPv4v6.
8. IANA Considerations
This document makes no request of IANA.
9. Security Considerations 8. Security Considerations
Although this document defines neither a new architecture nor a new Although this document defines neither a new architecture nor a new
protocol, the reader is encouraged to refer to [RFC6459] for a protocol, the reader is encouraged to refer to [RFC6459] for a
generic discussion on IPv6-related security considerations. generic discussion on IPv6-related security considerations.
10. Acknowledgements 9. References
Many thanks to F. Baker and J. Brzozowski for their support.
This document is the result of the IETF v6ops IPv6-Roaming design
team effort.
The authors would like to thank Mikael Abrahamsson, Victor Kuarsingh,
Heatley Nick, Alexandru Petrescu, Tore Anderson, Cameron Byrne,
Holger Metschulat and Geir Egeland for their helpful discussions and
comments.
The authors especially thank Fred Baker and Ross Chandler for their
efforts and contributions which substantially improved the
readability of the document.
11. References
11.1. Normative References 9.1. Normative References
[IR.21] Global System for Mobile Communications Association, [IR.21] Global System for Mobile Communications Association
GSMA., "Roaming Database, Structure and Updating (GSMA), "Roaming Database, Structure and Updating
Procedures", July 2012. Procedures", IR.21, Version 7.4, November 2013.
[IR.65] Global System for Mobile Communications Association, [IR.65] Global System for Mobile Communications Association
GSMA., "IMS Roaming & Interworking Guidelines", May 2012. (GSMA), "IMS Roaming and Interworking Guidelines", IR.65,
Version 15.0, January 2015.
[RFC6146] Bagnulo, M., Matthews, P., and I. van Beijnum, "Stateful [RFC6146] Bagnulo, M., Matthews, P., and I. van Beijnum, "Stateful
NAT64: Network Address and Protocol Translation from IPv6 NAT64: Network Address and Protocol Translation from IPv6
Clients to IPv4 Servers", RFC 6146, April 2011. Clients to IPv4 Servers", RFC 6146, April 2011,
<http://www.rfc-editor.org/info/rfc6146>.
[RFC6147] Bagnulo, M., Sullivan, A., Matthews, P., and I. van [RFC6147] Bagnulo, M., Sullivan, A., Matthews, P., and I. van
Beijnum, "DNS64: DNS Extensions for Network Address Beijnum, "DNS64: DNS Extensions for Network Address
Translation from IPv6 Clients to IPv4 Servers", RFC 6147, Translation from IPv6 Clients to IPv4 Servers", RFC 6147,
April 2011. April 2011, <http://www.rfc-editor.org/info/rfc6147>.
[RFC6877] Mawatari, M., Kawashima, M., and C. Byrne, "464XLAT: [RFC6877] Mawatari, M., Kawashima, M., and C. Byrne, "464XLAT:
Combination of Stateful and Stateless Translation", RFC Combination of Stateful and Stateless Translation", RFC
6877, April 2013. 6877, April 2013,
<http://www.rfc-editor.org/info/rfc6877>.
[TS23.060] [TS23.060] 3GPP, "General Packet Radio Service (GPRS); Service
3rd Generation Partnership Project, 3GPP., "General Packet description; Stage 2 v9.00", TS 23.060, March 2009.
Radio Service (GPRS); Service description; Stage 2 v9.00",
March 2009.
[TS23.401] [TS23.401] 3GPP, "General Packet Radio Service (GPRS) enhancements
3rd Generation Partnership Project, 3GPP., "General Packet for Evolved Universal Terrestrial Radio Access Network
Radio Service (GPRS) enhancements for Evolved Universal (E-UTRAN) access v9.00", TS 23.401, March 2009.
Terrestrial Radio Access Network (E-UTRAN) access v9.00",
March 2009.
[TS29.002] [TS29.002] 3GPP, "Mobile Application Part (MAP) specification
3rd Generation Partnership Project, 3GPP., "Mobile v9.12.0", TS 29.002, December 2009.
Application Part (MAP) specification v9.12.0", December
2009.
[TS29.272] [TS29.272] 3GPP, "Mobility Management Entity (MME) and Serving GPRS
3rd Generation Partnership Project, 3GPP., "Mobility Support Node (SGSN) related interfaces based on Diameter protocol
Management Entity (MME) and Serving GPRS Support Node v9.00", TS 29.272, September 2009.
(SGSN) related interfaces based on Diameter protocol
v9.00", September 2009.
11.2. Informative References 9.2. Informative References
[EU-Roaming-III] [EU-Roaming-III]
"http://www.amdocs.com/Products/Revenue- Amdocs Inc., "Amdocs 2014 EU Roaming Regulation III
Management/Documents/ Solution", July 2013, <http://www.amdocs.com/Products/
amdocs-eu-roaming-regulation-III-solution.pdf", July 2013. Revenue-Management/Documents/
amdocs-eu-roaming-regulation-III-solution.pdf>.
[IR.33] Global System for Mobile Communications Association, [IR.33] Global System for Mobile Communications Association
GSMA., "GPRS Roaming Guidelines", July 2012. (GSMA), "GPRS Roaming Guidelines", IR.33, Version 7.0,
June 2014.
[IR.34] Global System for Mobile Communications Association, [IR.34] Global System for Mobile Communications Association
GSMA., "Guidelines for IPX Provider networks", November (GSMA), "Guidelines for IPX Provider networks", IR.34
2013. Version 11.0, January 2015.
[IR.88] Global System for Mobile Communications Association, [IR.88] Global System for Mobile Communications Association
GSMA., "LTE Roaming Guidelines", January 2012. (GSMA), "LTE Roaming Guidelines", IR.88, Version 12.0,
January 2015.
[IR.92] Global System for Mobile Communications Association [IR.92] Global System for Mobile Communications Association
(GSMA), , "IMS Profile for Voice and SMS Version 7.0", (GSMA), "IMS Profile for Voice and SMS", IR.92, Version
March 2013. 7.1, January 2015.
[RCC.07] Global System for Mobile Communications Association [RCC.07] Global System for Mobile Communications Association
(GSMA), , "Rich Communication Suite 5.1 Advanced (GSMA), "Rich Communication Suite 5.2 Advanced
Communications Services and Client Specification Version Communications Services and Client Specification", RCC.07,
4.0", November 2013. Version 5.0, May 2014.
[RFC6052] Bao, C., Huitema, C., Bagnulo, M., Boucadair, M., and X. [RFC6052] Bao, C., Huitema, C., Bagnulo, M., Boucadair, M., and X.
Li, "IPv6 Addressing of IPv4/IPv6 Translators", RFC 6052, Li, "IPv6 Addressing of IPv4/IPv6 Translators", RFC 6052,
October 2010. October 2010, <http://www.rfc-editor.org/info/rfc6052>.
[RFC6459] Korhonen, J., Soininen, J., Patil, B., Savolainen, T., [RFC6459] Korhonen, J., Ed., Soininen, J., Patil, B., Savolainen,
Bajko, G., and K. Iisakkila, "IPv6 in 3rd Generation T., Bajko, G., and K. Iisakkila, "IPv6 in 3rd Generation
Partnership Project (3GPP) Evolved Packet System (EPS)", Partnership Project (3GPP) Evolved Packet System (EPS)",
RFC 6459, January 2012. RFC 6459, January 2012,
<http://www.rfc-editor.org/info/rfc6459>.
[RFC6535] Huang, B., Deng, H., and T. Savolainen, "Dual-Stack Hosts [RFC6535] Huang, B., Deng, H., and T. Savolainen, "Dual-Stack Hosts
Using "Bump-in-the-Host" (BIH)", RFC 6535, February 2012. Using "Bump-in-the-Host" (BIH)", RFC 6535, February 2012,
<http://www.rfc-editor.org/info/rfc6535>.
[RFC7050] Savolainen, T., Korhonen, J., and D. Wing, "Discovery of [RFC7050] Savolainen, T., Korhonen, J., and D. Wing, "Discovery of
the IPv6 Prefix Used for IPv6 Address Synthesis", RFC the IPv6 Prefix Used for IPv6 Address Synthesis", RFC
7050, November 2013. 7050, November 2013,
<http://www.rfc-editor.org/info/rfc7050>.
[RFC7225] Boucadair, M., "Discovering NAT64 IPv6 Prefixes Using the [RFC7225] Boucadair, M., "Discovering NAT64 IPv6 Prefixes Using the
Port Control Protocol (PCP)", RFC 7225, May 2014. Port Control Protocol (PCP)", RFC 7225, May 2014,
<http://www.rfc-editor.org/info/rfc7225>.
[TR23.975] [TR23.975] 3GPP, "IPv6 migration guidelines", TR 23.975, June 2011.
3rd Generation Partnership Project, 3GPP., "IPv6 migration
guidelines", June 2011.
[TS23.003] [TS23.003] 3GPP, "Numbering, addressing and identification v9.0.0",
3rd Generation Partnership Project, 3GPP., "Numbering, TS 23.003, September 2009.
addressing and identification v9.0.0", September 2009.
[TS24.008] [TS24.008] 3GPP, "Mobile radio interface Layer 3 specification; Core
3rd Generation Partnership Project, 3GPP., "Mobile radio network protocols; Stage 3 v9.00", TS 24.008, September
interface Layer 3 specification; Core network protocols; 2009.
Stage 3 v9.00", September 2009.
[TS24.301] [TS24.301] 3GPP, "Non-Access-Stratum (NAS) protocol for Evolved
3rd Generation Partnership Project, 3GPP., "Non-Access- Packet System (EPS) ; Stage 3 v9.00", TS 24.301, September
Stratum (NAS) protocol for Evolved Packet System (EPS) ; 2009.
Stage 3 v9.00", September 2009.
[TS29.212] [TS29.061] 3GPP, "Interworking between the Public Land Mobile Network
3rd Generation Partnership Project, 3GPP., "Policy and (PLMN) supporting packet based services and Packet Data
Charging Control (PCC); Reference points v9.0.0", Networks (PDN) v9.14.0", TS 29.061, January 2015.
September 2009.
[TS29.212] 3GPP, "Policy and Charging Control (PCC); Reference points
v9.0.0", TS 29.212, September 2009.
Acknowledgements
Many thanks to F. Baker and J. Brzozowski for their support.
This document is the result of the IETF v6ops IPv6-Roaming design
team effort.
The authors would like to thank Mikael Abrahamsson, Victor Kuarsingh,
Nick Heatley, Alexandru Petrescu, Tore Anderson, Cameron Byrne,
Holger Metschulat, and Geir Egeland for their helpful discussions and
comments.
The authors especially thank Fred Baker and Ross Chandler for their
efforts and contributions that substantially improved the readability
of the document.
Contributors
The following individual contributed to this document.
Vizdal Ales
Deutsche Telekom AG
Tomickova 2144/1
Prague 4, 149 00
Czech Republic
EMail: ales.vizdal@t-mobile.cz
Authors' Addresses Authors' Addresses
Gang Chen Gang Chen
China Mobile China Mobile
53A,Xibianmennei Ave., 53A,Xibianmennei Ave.,
Xuanwu District, Xicheng District,
Beijing 100053 Beijing 100053
China China
Email: phdgang@gmail.com EMail: phdgang@gmail.com, chengang@chinamobile.com
Hui Deng Hui Deng
China Mobile China Mobile
53A,Xibianmennei Ave., 53A,Xibianmennei Ave.,
Xuanwu District, Xuanwu District,
Beijing 100053 Beijing 100053
China China
Email: denghui@chinamobile.com EMail: denghui@chinamobile.com
Dave Michaud Dave Michaud
Rogers Communications Rogers Communications
8200 Dixie Rd. 8200 Dixie Rd.
Brampton, ON L6T 0C1 Brampton, ON L6T 0C1
Canada Canada
Email: dave.michaud@rci.rogers.com EMail: dave.michaud@rci.rogers.com
Jouni Korhonen Jouni Korhonen
Broadcom Broadcom Corporation
Porkkalankatu 24 3151 Zanker Rd.
FIN-00180 Helsinki, Finland San Jose, CA 95134
United States
Email: jouni.nospam@gmail.com EMail: jouni.nospam@gmail.com
Mohamed Boucadair Mohamed Boucadair
France Telecom France Telecom
Rennes, Rennes,
35000 35000
France France
Email: mohamed.boucadair@orange.com EMail: mohamed.boucadair@orange.com
Vizdal Ales
Deutsche Telekom AG
Tomickova 2144/1
Prague 4, 149 00
Czech Republic
Email: ales.vizdal@t-mobile.cz
 End of changes. 134 change blocks. 
401 lines changed or deleted 412 lines changed or added

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