draft-ietf-v6ops-ipv6-roaming-analysis-03.txt   draft-ietf-v6ops-ipv6-roaming-analysis-04.txt 
Network Working Group G. Chen Network Working Group G. Chen
Internet-Draft H. Deng Internet-Draft H. Deng
Intended status: Informational China Mobile Intended status: Informational China Mobile
Expires: February 10, 2015 D. Michaud Expires: February 22, 2015 D. Michaud
Rogers Communications Rogers Communications
J. Korhonen J. Korhonen
Renesas Mobile Broadcom
M. Boucadair M. Boucadair
France Telecom France Telecom
A. Vizdal A. Vizdal
Deutsche Telekom AG Deutsche Telekom AG
August 9, 2014 August 21, 2014
IPv6 Roaming Behavior Analysis IPv6 Roaming Behavior Analysis
draft-ietf-v6ops-ipv6-roaming-analysis-03 draft-ietf-v6ops-ipv6-roaming-analysis-04
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 investigations on those failed cases reveal the causes in order The analysis reveals that the failure causes include improper
to notice improper configurations, equipment's incomplete functions configurations, incomplete functionality support in equipment, and
or inconsistent IPv6 introduction strategy. inconsistent IPv6 deployment strategies between the home and the
visited networks.
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 February 10, 2015. This Internet-Draft will expire on February 22, 2015.
Copyright Notice Copyright Notice
Copyright (c) 2014 IETF Trust and the persons identified as the Copyright (c) 2014 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 . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Roaming Architecture Description . . . . . . . . . . . . . . 3 1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3
2.1. Home Routed Mode . . . . . . . . . . . . . . . . . . . . 3 2. Background . . . . . . . . . . . . . . . . . . . . . . . . . 3
2.2. Local Breakout Mode . . . . . . . . . . . . . . . . . . . 4 2.1. Roaming Architecture: An Overview . . . . . . . . . . . . 3
3. Roaming Scenario . . . . . . . . . . . . . . . . . . . . . . 5 2.1.1. Home Routed Mode . . . . . . . . . . . . . . . . . . 4
4. Failure Case in Attachment Stage . . . . . . . . . . . . . . 6 2.1.2. Local Breakout Mode . . . . . . . . . . . . . . . . . 5
5. Failure Cases in PDP/PDN Creation . . . . . . . . . . . . . . 7 2.2. Typical Roaming Scenarios . . . . . . . . . . . . . . . . 6
5.1. Case 1: Splitting Dual-stack Bearer . . . . . . . . . . . 7 3. Failure Case in the Network Attachment . . . . . . . . . . . 7
5.2. Case 2: Lack of IPv6 support in applications . . . . . . 8 4. Failure Cases in the PDP/PDN Creation . . . . . . . . . . . . 8
5.3. Case 3: Fallback Incapability . . . . . . . . . . . . . . 9 4.1. Case 1: Splitting Dual-stack Bearer . . . . . . . . . . . 9
5.4. Case 4: 464xlat Support . . . . . . . . . . . . . . . . . 9 4.2. Case 2: IPv6 PDP/PDN Unsupported . . . . . . . . . . . . 10
6. HLR/HSS User Profile Setting . . . . . . . . . . . . . . . . 9 4.3. Case 3: Inappropriate Roaming APN Set . . . . . . . . . . 11
7. Discussion . . . . . . . . . . . . . . . . . . . . . . . . . 11 4.4. Case 4: Fallback Failure . . . . . . . . . . . . . . . . 11
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12 5. Failure Cases in the Service Requests . . . . . . . . . . . . 11
9. Security Considerations . . . . . . . . . . . . . . . . . . . 12 5.1. Lack of IPv6 Support in Applications . . . . . . . . . . 11
10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 13 5.2. 464xlat Support . . . . . . . . . . . . . . . . . . . . . 12
11. References . . . . . . . . . . . . . . . . . . . . . . . . . 13 6. HLR/HSS User Profile Setting . . . . . . . . . . . . . . . . 12
11.1. Normative References . . . . . . . . . . . . . . . . . . 13 7. Discussion . . . . . . . . . . . . . . . . . . . . . . . . . 14
11.2. Informative References . . . . . . . . . . . . . . . . . 13 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 15 9. Security Considerations . . . . . . . . . . . . . . . . . . . 15
10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 15
11. Informative References . . . . . . . . . . . . . . . . . . . 16
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 18
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. A IPv6 connectivity if their User Equipment (UE) is IPv6-compliant.
detailed overview of IPv6 support in 3GPP architectures is provided Operators may adopt various approaches to deploy IPv6 in mobile
in [RFC6459]. Operators may adopt various approaches to deploy IPv6 networks such as the solutions described in [TR23.975]). Depending
in mobile networks, for example the solutions described in on network conditions, either dual-stack or IPv6-only deployment
[TR23.975]). Depending on network conditions either dual-stack or schemes can be enabled.
single-stack IPv6 is selected.
In production networks, it has been observed that a mobile subscriber A detailed overview of IPv6 support in 3GPP architectures is provided
roaming around a different operator's areas may experience service in [RFC6459].
degradation or interruptions due to inconsistent configurations and
incomplete functionality of equipment in the network.
2. Roaming Architecture Description It has been observed and reported that a mobile subscriber roaming
around a different operator's areas may experience service disruption
due to inconsistent configurations and incomplete functionality of
equipment in the network. This document focuses on these issues.
1.1. Terminology
This document makes use of these terms:
o Mobile networks refer to 3GPP mobile networks.
o Mobile UE denotes a 3GPP device which can be connected to 3GPP
mobile networks.
o The Public Land Mobile Network (PLMN) is a network that is
operated by a single administrative entity. 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 [RFC6459].
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)
that contains subscriber data and information related to call
routing. All subscribers of an operator, and the subscribers'
enabled services, are provisioned in the HLR [RFC6459].
o The Home Subscriber Server (HSS) is a database for a given
subscriber and was introduced in 3GPP Release-5. It is the entity
containing the subscription-related information to support the
network entities actually handling calls/sessions [RFC6459].
"HLR/HSS" is used collectively for the subscriber database unless
referring to the failure case related to General Packet Radio Service
(GPRS) Subscriber data from the HLR.
An overview of key 3GPP functional elements is documented in
[RFC6459].
"Mobile device" and "mobile UE" are used interchangeably.
2. Background
2.1. Roaming Architecture: An Overview
Roaming occurs in two scenarios: Roaming occurs in two scenarios:
o International roaming: a mobile UE may enter a visited network, o International roaming: a mobile UE enters a visited network
where a different Public Land Mobile Network (PLMN) identity is operated by a different operator, where a different Public Land
used. The UEs could, either in an automatic mode or a manual Mobile Network (PLMN) code is used. The UEs could, either in an
mode, attach to the visited PLMN. automatic mode or in a manual mode, attach to the visited PLMN.
o Intra-PLMN mobility: a mobile UE moves to a different area of the o Intra-PLMN mobility: an operator may have one or multiple PLMN
Home Public Land Mobile Network (HPLMN). However, the subscriber codes. A mobile UE could pre-configure the codes to identify the
profile may not be stored in the area. To allow network Home PLMN (HPLMN) or Equivalent HPLMN (EHPLMN). Intra-PLMN
attachment the subscribers profile needs to be downloaded from the mobility allows the UE moving to a different area of HPLMN and
home network area. EHPLMN. When the subscriber profile is not stored in the visited
area, HLR/HSS in the Home area will transmit the profile to
Serving GPRS Support Node (SGSN)/Mobility Management Entity (MME)
in the visited area so as to complete network attachment.
When a UE is turned on or is transferred via a handover to a visited When a UE is turned on or is transferred via a hand-over 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 Public Land Mobile Networks (PLMNs) to attach to. The available PLMNs to attach to. The SGSN or the MME in the visited
Serving GPRS Support Node (SGSN) or the Mobility Management Entity networks must contact the HLR or HSS to retrieve the subscriber
(MME) in the visited networks must contact the Home Location profile.
Register(HLR) or Home Subscriber Server(HSS) and obtain the
subscriber profile. After the authentication and registration
process is completed, the Packet Data Protocol (PDP) or Packet Data
Networks (PDN) activation and traffic flows may be operated
differently according to the subscriber profile stored in HLR or HSS.
There are two roaming modes illustrated below, i.e. "Home routed Steering of roaming may also be used by the HPLMN to further restrict
traffic" (Figure 1) and "Local breakout" (Figure 2). which of the available networks the UE may be attached to. Once the
authentication and registration stage is completed, the Packet Data
Protocol (PDP) or Packet Data Networks (PDN) activation and traffic
flows may be operated differently according to the subscriber profile
stored in the HLR or the HSS.
2.1. Home Routed Mode The following sub-sections describe two roaming modes: Home routed
traffic (Section 2.1.1) and Local breakout (Section 2.1.2).
In the home routed mode, the subscriber's UE activates the PDP/PDN 2.1.1. Home Routed Mode
context and get an address from the home network. All traffic is
routed back to the home network. This is likely to be the case In this mode, the subscriber's UE gets IP addresses from the home
international roaming of Internet data services to facilitate the network. All traffic belonging to that UE is therefore routed to the
charging process between the two operators concerned. home network (Figure 1).
GPRS roaming exchange (GRX) or Internetwork Packet Exchange (IPX)
networks [IR.34] is likely to be invoked as the transit network to
deliver the traffic. This is the main mode for international roaming
of Internet data services to facilitate the charging process between
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/MME|====================>|GGSN/PGW|============>
| +----+ +--------+ | Signaling | +--------+ | | +----+ +--------+ | Signaling | +--------+ |
| |------------------------>+--------+ | | |------------------------>+--------+ |
| | | |HLR/HSS | | | | | |HLR/HSS | |
| | | +--------+ | | | | +--------+ |
+-----------------------------+ +------------------------+ +-----------------------------+ +------------------------+
Figure 1: Home Routed Traffic Figure 1: Home Routed Traffic
2.2. Local Breakout Mode 2.1.2. Local Breakout Mode
In the local breakout mode, the subscriber address is assigned by the In the local breakout mode, IP addresses are assigned by the visited
visited network. The traffic flow is directly offloaded locally at a network to a roaming mobile UE. Unlike the home mode, the traffic
doesn't have to traverse GRX/IPX; it is offloaded locally at a
network node close to that device's point of attachment in the network node close to that device's point of attachment in the
visited network. Therefore,a more efficient route to the data visited network. This mode ensures a more optimized forwarding path
service is achieved. The international roaming of IP Multimedia for the delivery of packets belonging to a visiting UE (Figure 2).
Subsystem (IMS) based services, e.g. Voice over LTE (VoLTE)[IR.92] ,
is claimed to select the local breakout mode in [IR.65]. Data
service roaming across different areas within an operator network
might use local breakout mode in order to get more efficient traffic
routing. The local breakout mode could be also applied to an
operator's alliance for international roaming of data service. EU
Roaming Regulation III[EU-Roaming-III] involves local breakout mode
allowing European subscribers roaming in European 2G/3G networks can
choose to have their Internet data routed directly to the Internet
from their current VPLMN.
+----------------------------+ +----------------+ +----------------------------+ +----------------+
|Visited Network | |Home Network | |Visited Network | |Home Network |
| +----+ +--------+ | Signaling | +--------+ | | +----+ +--------+ | Signaling | +--------+ |
| | UE |=======>|SGSN/MME|------------------->|HLR/HSS | | | | UE |=======>|SGSN/MME|------------------->|HLR/HSS | |
| +----+ +--------+ | (GRX/IPX) | +--------+ | | +----+ +--------+ | (GRX/IPX) | +--------+ |
| || | | | | || | | |
| +--------+ | | | | +--------+ | | |
| |GGSN/PGW| | | | | |GGSN/PGW| | | |
| +--------+ | | | | +--------+ | | |
| Traffic Flow || | | | | Traffic Flow || | | |
+--------------------||------+ +----------------+ +--------------------||------+ +----------------+
\/ \/
Figure 2: Local Breakout Figure 2: Local Breakout
The following enumerates the more specific configuration The international roaming of IP Multimedia Subsystem (IMS) based
considerations. services, e.g. Voice over LTE (VoLTE)[IR.92], is claimed to select
the local breakout mode in [IR.65]. Data service roaming across
different areas within an operator network might use local breakout
mode in order to get more efficient traffic forwarding and also ease
emergency services. The local breakout mode could also be applied to
an operator's alliance for international roaming of data service.
EU Roaming Regulation III [EU-Roaming-III] involves local breakout
mode allowing European subscribers roaming in European 2G/3G networks
to have their Internet data routed directly to the Internet from
their current VPLMN.
Specific local breakout related configuration considerations are
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 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 profile to enable local breakout mode flag [TS29.272] in the user's profile to enable local breakout
in a Visited Public Land Mobile Networks (VPLMNs). mode in a Visited Public Land Mobile Networks (VPLMNs).
o 3GPP specified Selected IP Traffic Offload (SIPTO) o 3GPP specified Selected IP Traffic Offload (SIPTO) function
function[TS23.401] since Release 10 in order to get efficient [TS23.401] since Release 10 in order to get efficient route paths.
route paths. It enables an operator to offload certain types of It enables an operator to offload a portion of the traffic at a
traffic at a network node close to that device's point of network node close to the visiting UE's point of attachment to the
attachment to the access network. visited network.
o GSMA has defined RAVEL[IR.65] as the IMS international roaming o GSMA has 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.
3. Roaming Scenario 2.2. Typical Roaming Scenarios
Two 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 start data services. intends to invoke services:
o Network attachment: this occurs when the subscriber enters a o Network attachment: this occurs when the UE enters a visited
visited network. During an attachment, 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 HSS/
HLR in the home network of the subscriber. Accordingly, the 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 Access Point Names (APN), the allowed
PDP/PDN Types and rules regarding the routing of data sessions PDP/PDN Types and rules regarding the routing of data sessions
(i.e. home routed or local breakout mode) [TS29.272]. The SGSN/ (i.e., home routed or local breakout mode) [TS29.272]. The SGSN/
MME in the visited network can use this information to facilitate MME in the visited network can use this information to facilitate
the subsequent PDP/PDN session creation. the subsequent PDP/PDN session creation.
o PDP/PDN context creation: this occurs after the subscriber makes a o PDP/PDN context creation: this occurs after the subscriber UE has
successful attachment. This stage is integrated with the been successfully attached to the network. This stage is
attachment stage in the case of 4G, but is a seperate process in integrated with the attachment stage in the case of 4G, but is a
2/3G. 3GPP specifies three types of Packet Data Protocol separate process in 2/3G. 3GPP specifies three types of PDP/PDN to
(PDP)/Packet Data Networks (PDN) to describe connections, i.e. describe connections, i.e. PDP/PDN Type IPv4, PDP/PDN Type IPv6
PDP/PDN Type IPv4, PDP/PDN Type IPv6 and PDP/ PDN Type IPv4v6. and PDP/ PDN Type IPv4v6. When a subscriber creates a data
When a subscriber creates a data session, their device requests a session, their device requests a particular PDP/PDN Type. The
particular PDP/PDN Type. The allowed PDP/PDN types for that allowed PDP/PDN types for that subscriber are learned in the
subscriber are learned in the attachment stage. Hence, SGSN/MME attachment stage. Hence, SGSN/MME could initiate PDP/PDN request
could initiate PDP/PDN request to GGSN/PGW if the subscription to GGSN/PGW modulo subscription grants.
profile is allowed.
In both stages, the failure cases described are likely to occur due o Service requests: when the PDP/PDN context is created
to an incompliant implementation in the visited network or a mismatch successfully, UEs may launch applications and request services
between the subscriber requested and the capability of the visited based on the allocated IP addresses. The service traffic will be
network. The failures described in the attachment stage are transmitted via the visited network.
independent of home routed or the local breakout mode. Most failure
cases in the PDP/PDN context creation stage occur in the local
breakout mode. Section 4 and 5 describe each case.
4. Failure Case in Attachment Stage Failures that occur at the attachment stage (Section 3) are
independent of home routed and the local breakout mode. Most failure
cases in the PDP/PDN context creation (Section 4) and service
requests (Section 5) occur in the local breakout mode.
3. Failure Case in the Network Attachment
3GPP specified PDP/PDN type IPv4v6 in order to allow a UE get both an
IPv4 address and an IPv6 prefix within a single PDP/PDN bearer. This
option is stored as a part of subscription data for a subscriber in
the HLR/HSS. PDP/PDN type IPv4v6 has been introduced at the
inception of Evolved Packet System (EPS) in 4G networks.
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
networks depending on SGSN software version. In theory, S4-SGSN
(i.e., an SGSN with S4 interface) supports the PDP/PDN type IPv4v6
since Release 8 and a Gn-SGSN (i.e., the SGSN with Gn interface)
supports it since Release 9. In most cases, operators normally use
Gn-SGSN to connect either GGSN in 3G or Packet Data Network Gateway
(PGW) in 4G.
3GPP specified PDP/PDN type IPv4v6 in order to allow a UE get both
IPv4 and IPv6 address within a single PDP/PDN bearer. This option is
stored as a part of subscription data for a subscriber in the HLR/
HSS. PDP/PDN type IPv4v6 has been introduced at the inception of
Evolved Packet System (EPS) in 4G networks. The nodes in 4G networks
should present no issues with the handling of this PDN type.
However, support varies in 2/3G networks depending on Serving GPRS
Support Node (SGSN) software version. In theory, S4-SGSN (i.e. an
SGSN with S4 interface) supports the PDP/PDN type IPv4v6 since
Release8 and a Gn-SGSN (i.e. the SGSN with Gn interface) supports it
since Release 9. In most cases, operators normally use Gn-SGSN to
connect either GGSN in 3G or Packet 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 and
consequently it must silently discard that IE and continue processing consequently it must silently discard that IE and continue processing
of the rest of the ISD MAP message. The issue we observe is that of the rest of the ISD MAP message. An issue that has been observed
multiple SGSNs will be unable to correctly process a subscriber's is that multiple SGSNs are unable to correctly process a subscriber's
data received in the Insert Subscriber Data Procedure[TS23.060]. As data received in the Insert Subscriber Data Procedure [TS23.060]. As
a consequence, it will likely refuse the subscriber attach request. a consequence, it will likely discard the subscriber attach request.
This is erroneous behavior due to the equipment not being 3GPP This is erroneous behavior due to the equipment not being compliant
Release 9 compliant. with 3GPP Release 9.
Operators may have to remove the PDP/PDN type IPv4v6 from the HLR/HSS In order to avoid encountering this attach problem at a visited SGSN,
in the home network, that will restrict UEs to only initiate IPv4 PDP both operators should make a comprehensive roaming agreement to
or IPv6 PDP activation. In order to avoid this situation, operators support IPv6 and ensure that it aligns with the GSMA documents, e.g.,
should make a comprehensive roaming agreement to 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 visited operator to get
the necessary patch on all their SGSN nodes to support PDP/PDN type
IPv4v6.
As an alternative solution there are some specific implementations [IR.33], [IR.88] and [IR.21]. Such an agreement requires the visited
(not standardized by 3GPP) in the HLS/HSS of the home network. When operator to get the necessary patch on all its SGSN nodes to support
the HLR/HSS receives an Update Location message from a visited SGSN the "ext-pdp-Type" MAP IE sent by the HLR. To ensure data session
known to not support the PDP type IPv4v6, subscription data with only continuity in Radio Access Technology (RAT) handovers the PDN Type
PDP/PDN type IPv4 will be sent to that SGSN in the Insert Subscriber sent by the HSS to the MME could be consistent with the PDP Type sent
Data procedure. It guarantees the user profile is compatible with by the HLR to the Gn-SGSN. Where roaming agreements and visited SGSN
visited SGSN/MME capability. nodes have not been updated the HPLMN also has to make use of
specific implementations (not standardized by 3GPP, discussed further
in (Section 6) in the HLR/HSS of the home network. That is, when the
HLR/HSS receives an Update Location message from a visited SGSN not
known to support dual-stack in a single bearer, subscription data
allowing only PDP/PDN type IPv4 or IPv6 will be sent to that SGSN in
the Insert Subscriber Data procedure. This guarantees that the user
profile is compatible with the visited SGSN/MME capability. In
addition, HSS may not have to change, if the PGW is aware of
subscriber's roaming status and only restricts the accepted PDN type
consistent with PDP type sent by the HLR. For example, an AAA server
may coordinate with the PGW to decide the allowed PDN type.
5. Failure Cases in PDP/PDN Creation Alternatively, HPLMNs without the non-standardized capability to
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
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/
PDN activation. This alternative has problems:
When a subscriber succeeds in the attach stage, the IP allocation o The HPLMN cannot support dual-stack in a single bearer at home
process takes place to allocate IP addresses to the subscriber. In either where the APN profile in the HLR/HSS is also used for
general, a PDP/PDN type IPv4v6 request implicitly allows a network roaming.
side to make several IP assignment options, including IPv4-only,
IPv6-only, IPv4 and IPv6 in single PDP/PDN bearer, IPv4 and IPv6 in
separated PDP/PDN bearers. A PDP/PDN type IPv4 or IPv6 restricts the
network side only allocates requested IP family. This section
summarizes several failures in the Local Breakout mode.
+-------------+-------------------+--------------+ o The UE may set-up separate parallel bearers for IPv4 and IPv6
| UE request | PDN/PDP IP Type |Local breakout| where only single stack IPv4 or IPv6 service is preferred by the
| | permitted | | operator.
+-------------+-------------------+--------------+
| IPv4v6 | IPv4 or IPv6 |Failure case 1|
+-------------+-------------------+--------------+
| IPv4v6 | IPv6 |Failure case 2|
+-------------+-------------------+--------------+
| IPv6 | IPv4 |Failure case 3|
+-------------+-------------------+--------------+
| IPv6 | IPv6 |Failure case 4|
| with 464xlat| without NAT64 | |
+-------------+-------------------+--------------+
Table 1: Local Breakout Failure Cases 4. Failure Cases in the PDP/PDN Creation
5.1. Case 1: Splitting Dual-stack Bearer When a subscriber's UE succeeds in the attach stage, the IP
allocation process takes place to retrieve IP addresses. In general,
a PDP/PDN type IPv4v6 request implicitly allows the network side to
make several IP assignment options, including IPv4-only, IPv6-only,
IPv4 and IPv6 in single PDP/PDN bearer, IPv4 and IPv6 in separated
PDP/PDN bearers.
Dual-stack capability can be provided using separate PDP/PDN A PDP/PDN type IPv4 or IPv6 restricts the network side to only
activation. That means only separate parallel single-stack IPv4 and allocate requested IP address family.
IPv6 PDP/PDN connections are allowed to be initiated to separately
allocate IPv4 and IPv6 addresses.
The cases are listed below: This section summarizes several failures in the Home Routed (HR) and
Local Breakout (LBO) mode as shown in Table 1.
o The SGSN/MME returns Session Management (SM) Cause #52, "Single +-------+-------------+------------------------+---------+
address bearers only allowed", or SM Cause #28 "Unknown PDP | Case# | UE request | PDP/PDN IP Type | Mode |
address or PDP type" as per[TS24.008] and [TS24.301]. | | | permitted on GGSN/PGW | |
+-------+-------------+------------------------+---------+
| | IPv4v6 | IPv4v6 | HR |
| #1 |-------------+------------------------+---------+
| | IPv4v6 | IPv4 or IPv6 | LBO |
+-------+-------------+------------------------+---------+
| #2 | IPv6 | IPv6 | HR |
+-------+-------------+------------------------+---------+
| #3 | IPv4 | IPv6 | HR |
+-------+-------------+------------------------+---------+
| #4 | IPv6 | IPv4 | LBO |
+-------+-------------+------------------------+---------+
o The SGSN/MME does not set the Dual Address Bearer Flag (DAF) Table 1: Failure Cases in the PDP/PDN Creation
because the operator uses single addressing per bearer to support
interworking with nodes of earlier releases
A roaming subscriber's UE with IPv4v6 PDP/PDN type has to change the 4.1. Case 1: Splitting Dual-stack Bearer
request into two separated PDP/PDN requests with a single IP version
in order to achieve equivalent results. Some drawbacks of this case
are listed as below:
o The parallel PDP/PDN activation would likely double PDP/PDN Dual-stack capability is provided using separate PDP/PDN activation
resources consumption. It also impacts the capacity of GGSN/PGW, in the visited network that doesn't support PDP/PDN type IPv4v6.
since a certain amount of PDP/PDN activation is only allowed on That means only separate parallel single-stack IPv4 and IPv6 PDP/PDN
those nodes. connections are allowed to be initiated to separately allocate an
IPv4 address and an IPv6 prefix. The SGSN does not support the Dual
Address Bearer Flag (DAF) or does not set DAF because the operator
uses single addressing per bearer to support interworking with nodes
of earlier releases. Regardless of home routed or local breakout
mode, visited SGSN will change PDN/PDP type to a single address PDP/
PDN type and return the Session Management (SM) Cause #52 "Single
address bearers only allowed" or SM Cause #28 "Unknown PDP address or
PDP type" as per [TS24.008] and [TS24.301]. to the UE. In this case,
the UE may make another PDP/PDN request with a single address PDP
type (IPv4 or IPv6) other than the one already activated.
o Some networks may only allow one PDP/PDN is alive for each This approach suffers from the followings drawbacks:
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 RAN side. It also impacts the capacity of the
GGSN/PGW, since only a certain amount of PDP/PDN activation is
only allowed on those nodes.
o Some networks may only allow one PDP/PDN 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
will lose the IPv6 connection in the visited network. It is even will lose the IPv6 connection in the visited network. It is even
worse as they may have a risk of losing all data connectivity if worse as they may have a risk of losing all data connectivity if
the IPv6 PDP gets rejected with a permanent error at the APN-level the IPv6 PDP gets rejected with a permanent error at the APN-level
and not specific to the PDP-Type IPv6 requested. and not specific to the PDP-Type 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)/Policy and Charging o Policy and Charging Rules Function (PCRF) [TS29.212]/ Policy and
Enforcement Function (PCEF) treats the IPv4 and IPv6 session as Charging Enforcement Function (PCEF) treats the IPv4 and IPv6
independent and performs different Quality of Service (QoS) session as independent and performs different Quality of Service
policies. The subscriber may have unstable experiences due to (QoS) policies. The subscriber may have unstable experiences due
different behaviors on each IP version connection. 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 allowed simultaneous PDP/
PDN activation. Excessive PDP/PDN activation may result in other PDN contexts. Excessive PDP/PDN activation may result in service
unrelated services broken. disruption.
Operators may have to disable the local-break mode to avoid the In order to avoid the issue, the roaming agreement in the home routed
risks. Another approach is to set a dedicated Access Point Name mode should make sure the visited SGSN support and set the DAF.
(APN) profile to only request PDP/PDN type IPv4 in the roaming Since the PDP/PDN type IPv4v6 is supported in the GGSN/PGW of home
network. network, the visited SGSN/MME should create dual-stack bearer as UE
requested.
5.2. Case 2: Lack of IPv6 support in applications In the local breakout mode, the visited GGSN may only allow single IP
version addressing. In this case, DAF on visited SGSN/MME has to be
unset. One approach is to set a dedicated Access Point Name (APN)
[TS23.003] profile to only request PDP/PDN type IPv4 in the roaming
network. Some operators may also consider not adopting the local
breakout mode to avoid the risks.
Some operators may adopt an IPv6-only configuration for the IMS 4.2. Case 2: IPv6 PDP/PDN Unsupported
service, e.g. Voice over LTE (VoLTE)[IR.92] or Rich Communication
Suite (RCS)[RCC.07]. Since the IMS roaming architecture will offload
all traffic in the visited network, a dual-stack subscriber can only
be assigned with an IPv6 prefix and no IPv4 address returned. This
requires that all the IMS based applications should be IPv6 capable.
A translation-based method, for example Bump-in-the-host
(BIH)[RFC6535] or 464xlat [RFC6877] may help to address the issue if
there are IPv6 compatibility problems. Those functions could be
automatically enabled in an IPv6-only network and disabled in a dual-
stack or IPv4 network.
5.3. Case 3: Fallback Incapability PDP/PDN type IPv6 has good compatibility to visited networks during
the network attachment. In order to support the IPv6-only visitors,
SGSN/MME in the visited network is required to accept IPv6-only PDP/
PDN activation requests and enable IPv6 on user plane towards the
home network.
3GPP specified the PDP/PDN type IPv6 as early as PDP/PDN type IPv4. In some cases, IPv6-only visitors may still be subject to the SGSN
Therefore, the IPv6 single PDP/PDN type has been well supported and capability in visited networks. This becomes especially risky if the
interpretable in the 3GPP network nodes. Roaming to IPv4-only home operator performs roaming steering targeted to an operator that
networks and making an IPv6 PDP/PDN request could guarantee that the doesn't allow IPv6. The visited SGSN may just directly reject the
subscription data is compatible with the visited pre-Release 9 SGSN. PDP context activation. Therefore, it's expected that visited
When a subscriber requests PDP/PDN type IPv6, the network should only network is IPv6 roaming friendly to enable the functions on SGSN/MME
return the expected IPv6 prefix. The mobile device may fail to get by default. Otherwise, operators may consider steering the roaming
an IPv6 prefix if the visited network only allocates an IPv4 address traffic to the IPv6-enable visited network that has IPv6 roaming
to the subscriber. In that case, the request will be dropped and the agreement.
cause code should be sent to the user.
A proper fallback is desirable, however the behavior is 4.3. Case 3: Inappropriate Roaming APN Set
implementation specific. There are some mobile devices have the
ability to provide a different configuration for home network and
visited network respectively. For instance, the Android system
solves the issue by setting the roaming protocol to IPv4 for the
Access Point Name(APN). It guarantees that UE will always initiate
an PDP/PDN type IPv4 in the roaming area.
5.4. Case 4: 464xlat Support If IPv6 single stack with the home routed mode is deployed, the
requested PDP/PDN type should also be IPv6. Some implementations
that support roaming APN profile may set IPv4 as the default PDP/PDN
type, since the visited network is incapable to support PDP/PDN type
IPv4v6 (Section 4.1) and IPv6 (Section 4.2). The PDP/PDN request
will fail because the APN in the home network only allows IPv6.
Therefore, the roaming APN have to be compliant with the home network
configuration when home routed mode is adopted.
4.4. Case 4: Fallback Failure
In the local breakout mode, PDP/PDN type IPv6 should have no issues
to pass through network attachment process, since 3GPP specified 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
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 will reject the request and send the cause code to
the UE.
A proper fallback scheme for PDP/PDN type IPv6 is desirable, however
there is no the standard way to specify the behavior. Roaming APN
profile could help to address the issue by setting PDP/PDN type IPv4.
For instance, the Android system solves the issue by configuring the
roaming protocol to IPv4 for the Access Point Name (APN). It
guarantees that UE will always initiate an PDP/PDN type IPv4 in the
roaming area.
5. Failure Cases in the Service Requests
After the successful network attachment and IP address allocation,
applications could start to request service based on the activated
PDP/PDN context. The service request may depend on specific IP
family or network collaboration. If traffic is offloaded locally
(Section 2.1.2 ), the visited network may not be able to accommodate
UE's service requests. This section describes the failures.
5.1. Lack of IPv6 Support in Applications
Operators may only allow IPv6 in the IMS APN. VoLTE [IR.92] or Rich
Communication Suite (RCS) [RCC.07] use the APN to offer the voice
service for visitors. The IMS roaming in RAVEL architecture [IR.65]
offloads voice and video traffic in the visited network, therefore a
dual-stack visitor can only be assigned with an IPv6 prefix but no
IPv4 address. If the applications can't support IPv6, the service is
likely failed .
Translation-based methods, for example 464xlat [RFC6877] or Bump-in-
the-host (BIH) [RFC6535], may help to address the issue if there are
IPv6 compatibility problems. The translation function could be
enabled in an IPv6-only network and disabled in a dual-stack or IPv4
network, therefore the IPv4 applications only get the translation in
the IPv6 network and perform normally in an IPv4 or dual-stack
network.
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 single-stack environment. The function on a mobile device in an IPv6-only connectivity environment. The customer-side
is likely in conjunction with a PDP/PDN IPv6 type request and translator (CLAT) function on a mobile device is likely in
cooperates with a remote NAT64[RFC6146] gateway. 464xlat may use the conjunction with a PDP/PDN IPv6 type request and cooperates with a
mechanism defined in [RFC7050] to automatically detect the presence remote NAT64 [RFC6146] device.
of DNS64 and to learn the IPv6 prefix used for protocol translation.
In the local breakout approach when a mobile device with 464xlat
function roams to an IPv6 visited network without the presence of
NAT64 or DNS64, 464xlat will fail to function.
The issue has been found mostly in intra-PLMN mobility cases for the 464xlat may use the mechanism defined in [RFC7050] or [RFC7225] to
time being. Considering the various network's situations, operators detect the presence of NAT64 devices and to learn the IPv6 prefix
may turn off the local breakout and use the home routed mode to used for protocol translation[RFC6052].
perform 464xlat. Some devices may support the configuration to adopt
464xlat in the home networks and use IPv4-only in the visited In the local breakout approach, when a UE with the 464xlat function
networks with different roaming profile configurations. This could roaming to an IPv6 visited network may encounter various situations.
also be a solution to address this issue. For example, the visited network may not deploy DNS64 [RFC6147] but
only NAT64, CLAT may not be able to discover the provider-side
translator (PLAT) translation IPv6 prefix used as a destination of
the PLAT. If the visited network doesn't deploy NAT64 and DNS64,
464xlat can't perform successfully due to the lack of PLAT
collaboration. Even in the case of the presence of NAT64 and DNS64,
pre-configured PLAT-side IPv6 prefix in the CLAT may cause the
failure because it can't match the PLAT translation.
Considering the various network's situations, operators may turn off
the local breakout and use the home routed mode to perform 464xlat.
Alternatively, UE may support the different roaming profile
configurations to adopt 464xlat in the home networks and use
IPv4-only 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 and
IPv6-only connectivity requests may come from devices. The HLR/HSS IPv6-only connectivity requests may come from devices. The HLR/HSS
may have to apply extra logic to achieve this. It's also desirable may have to apply extra logic (not standardized by 3GPP) to achieve
that the network could set-up connectivity of any requested PDP/PDN this. It is also desirable that the network could set-up
context type. connectivity of any requested PDP/PDN context type.
The following are examples to demonstrate 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 decision criteria to apply when returning user profile
information to visited SGSN. information to the visited SGSN.
Scenario 1: Support IPv6-only, IPv4-only and dual-stack devices user profile #1:
user profile #1: PDP-Context ::= SEQUENCE {
pdp-ContextId ContextId,
pdp-Type PDP-Type-IPv4
....
ext-pdp-Type PDP-Type-IPv4v6
...
}
PDP-Context ::= SEQUENCE { user profile #2:
pdp-ContextId ContextId,
pdp-Type PDP-Type-IPv4
....
ext-pdp-Type PDP-Type-IPv4v6
...
}
user profile #2: PDP-Context ::= SEQUENCE {
pdp-ContextId ContextId,
pdp-Type PDP-Type-IPv6
....
}
PDP-Context ::= SEQUENCE { Scenario 1: Support of IPv6-only, IPv4-only and dual-stack devices.
pdp-ContextId ContextId,
pdp-Type PDP-Type-IPv6
....
}
The full PDP-context parameters is referred to Section 17.7.1 "Mobile The full PDP-context parameters is referred to Section 17.7.1 "Mobile
Sevice date types" of [TS29.002]. User profile 1 and 2 share the Service date types" of [TS29.002]. User profiles #1 and #2 share the
same contextId. The setting of user profile #1 enables IPv4-only and same "ContextId". The setting of user profile #1 enables IPv4-only
dual-stack devices to work. And, the user profile #2 fulfills the and dual-stack devices to work. And, the user profile #2 fulfills
request if the device asks for IPv6 only PDP context. the request if the device asks for IPv6 only PDP context.
Scenario 2: Support dual-stack devices with pre-R9 vSGSN access user profile #1:
user profile #1: PDP-Context ::= SEQUENCE {
pdp-ContextId ContextId,
pdp-Type PDP-Type-IPv4
....
ext-pdp-Type PDP-Type-IPv4v6
...
}
PDP-Context ::= SEQUENCE { user profile #2:
pdp-ContextId ContextId,
pdp-Type PDP-Type-IPv4
....
ext-pdp-Type PDP-Type-IPv4v6
...
}
user profile #2: PDP-Context ::= SEQUENCE {
pdp-ContextId ContextId,
pdp-Type PDP-Type-IPv4
....
}
PDP-Context ::= SEQUENCE { Scenario 2: Support of dual-stack devices with pre-R9 vSGSN access.
pdp-ContextId ContextId,
pdp-Type PDP-Type-IPv4
....
}
User profile 1 and 2 share the same contextId. If a visited SGSN is User profiles #1 and #2 share the same "ContextId". If a visited
identified as early as pre-Release 9, the HLR/HSS should only send SGSN is identified as early as pre-Release 9, the HLR/HSS should only
user profile#2 to 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 testified that the major issues happened at two stages, i.e., been testified that the major issues happened at three stages, i.e.,
the initial network attachment and the IP allocation process. the initial network attachment, the PDP/PDN creation and service
requests.
During the initial network attach, PDP/PDN type IPv4v6 is the major In the stage of the network attachment, PDP/PDN type IPv4v6 is the
concern to the visited pre-Release 9 SGSN. 3GPP didn't specify PDP/ major concern to the visited pre-Release 9 SGSN. 3GPP didn't specify
PDN type IPv4v6 in the early release. Such PDP/PDN type is supported PDP/PDN type IPv4v6 in the early release. Such PDP/PDN type is
in new-built EPS network, but didn't support well in the third supported in new-built EPS network, but didn't support well in the
generation network. The situations may cause the roaming issues third generation network. The situations may cause the roaming
dropping with the attach request from dual-stack subscribers. issues dropping with the attach request from dual-stack subscribers.
Operators may have to adopt temporary solution unless all the Operators may have to adopt temporary solutions unless all the
interworking nodes(i.e. the SSGN) in the visited network have been interworking nodes (i.e., the SSGN) in the visited network have been
upgraded to support the ext-PDP-Type feature. upgraded to support the ext-PDP-Type feature.
PDP/PDN type IPv6 has good compatibility to visited networks during In the stage of the PDP/PDN creation, PDP/PDN type IPv4v6 and IPv6
the network attachment. It has been observed that IPv6 single stack support on the visited SGSN is the major concern. It has been
with the home routed mode is a viable approach to deploy IPv6. In observed that IPv6 single stack with the home routed mode is a viable
order to support the IPv6-only visitors, SGSN/MME in the visited approach to deploy IPv6. It is desirable the visited SGSN could
network is required to accept IPv6-only PDP/PDN activation requests enable IPv6 on the user plane by default. For the PDP/PDN type
and enable IPv6 on user plane towards the home network. In some IPv4v6 supporting, the DAF is suggested to be set. As a
cases, IPv6-only visitors may still be subject to the SGSN capability complementary function, the implementation of roaming APN
in visited networks. This becomes especially apparent if the home configuration is useful to accommodate the visited network. However,
operator performs roaming steering targeted to an operator that it should consider roaming architecture and permitted PDP/PDN type to
doesn't allow IPv6. Therefore, it's expected that visited network is make proper setting on the UE. Roaming APN in the home routed mode
IPv6 roaming friendly to enable the functions on SGSN/MME by default. is recommended to align with home network profile setting. In the
local breakout case, PDP/PDN type IPv4 could be selected as a safe
In the local breakout mode, the IP address is allocated by the way to initiate PDP/PDN activation.
visited GGSN or PGW. The mismatch is found in the following aspects.
o The mismatch between the requested PDP/PDN type and the permitted
PDP/PDN type
o The mismatch between the application capability and allowed
network connections
o The mismatch between mobile device function (e.g., 464xlat) and
the support for that function in the visited network
There are some solutions to overcome the issue. Those solutions can
be made either in the network side or mobile device side.
o Change local breakout to the home routed mode In the stage of service requests, the failure cases are mostly
occurred in the local breakout case. The visited network may not be
able to satisfy the requested capability from applications or UEs.
Operators may consider to use home routed to avoid the risks.
Several solutions either in the network side or mobile device side
can also help to address the issue. For example,
o A dedicated roaming APN profile is implemented for the roamer. o 464xlat could help IPv4 applications access IPv6 visited networks.
When a subscriber roams to a visited network, PDP/PDN type IPv4 is
to be always selected for session activation.
o Networks could deploy an AAA server to coordinate the mobile o Networks can deploy an AAA server to coordinate the mobile device
device capability. Once the GGSN/PGW receives the session capability. Once the GGSN/PGW receives the session creation
creation request, it will initiate an Access-Request to an AAA request, it will initiate an Access-Request to an AAA server in
server in the home network via the Radius protocol. The Access- the home network via the Radius protocol. The Access-Request
Request contains subscriber and visited network information, e.g. contains subscriber and visited network information, e.g. PDP/PDN
PDP/PDN Type, International Mobile Equipment Id (IMEI), Software Type, International Mobile Equipment Id (IMEI), Software Version
Version(SV) and visited SGSN/MME location code, etc. The AAA (SV) and visited SGSN/MME location code, etc. The AAA server
server could take mobile device capability and combine it with the could take mobile device capability and combine it with the
visited network information to ultimately determine the type of visited network information to ultimately determine the type of
session to be created, i.e. IPv4, IPv6 or IPv4v6. session to be created, i.e., IPv4, IPv6 or IPv4v6.
8. IANA Considerations 8. IANA Considerations
This document makes no request of IANA. This document makes no request of IANA.
9. Security Considerations 9. 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, it is encouraged to refer to [RFC6459] for a generic protocol, it is encouraged to refer to [RFC6459] for a generic
discussion on IPv6-related security considerations. discussion on IPv6-related security considerations.
10. Acknowledgements 10. Acknowledgements
Many thanks to F. Baker and J. Brzozowski for their support. Many thanks to F. Baker and J. Brzozowski for their support.
This document is the result of the IETF v6ops IPv6-Roaming design This document is the result of the IETF v6ops IPv6-Roaming design
team effort. team effort.
The authors would like to thank Mikael Abrahamsson, Victor Kuarsingh, The authors would like to thank Mikael Abrahamsson, Victor Kuarsingh,
Heatley Nick, Alexandru Petrescu, Tore Anderson, Cameron Byrne and Heatley Nick, Alexandru Petrescu, Tore Anderson, Cameron Byrne,
Holger Metschulat for their helpful comments. Holger Metschulat and Geir Egeland for their helpful discussions and
comments.
The authors especially thank Fred Baker and Ross Chandler for his
efforts and contributions on editing which substantially improves the
legibility of the document.
11. References
11.1. Normative References
[RFC6146] Bagnulo, M., Matthews, P., and I. van Beijnum, "Stateful
NAT64: Network Address and Protocol Translation from IPv6
Clients to IPv4 Servers", RFC 6146, April 2011.
[RFC6535] Huang, B., Deng, H., and T. Savolainen, "Dual-Stack Hosts
Using "Bump-in-the-Host" (BIH)", RFC 6535, February 2012.
[RFC6877] Mawatari, M., Kawashima, M., and C. Byrne, "464XLAT:
Combination of Stateful and Stateless Translation", RFC
6877, April 2013.
[RFC7050] Savolainen, T., Korhonen, J., and D. Wing, "Discovery of The authors especially thank Fred Baker and Ross Chandler for their
the IPv6 Prefix Used for IPv6 Address Synthesis", RFC efforts and contributions which substantially improved the
7050, November 2013. readability of the document.
11.2. Informative References 11. Informative References
[EU-Roaming-III] [EU-Roaming-III]
"http://www.amdocs.com/Products/Revenue- "http://www.amdocs.com/Products/Revenue-
Management/Documents/ Management/Documents/
amdocs-eu-roaming-regulation-III-solution.pdf", July 2013. amdocs-eu-roaming-regulation-III-solution.pdf", July 2013.
[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", July 2012.
[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", July 2012.
[IR.34] Global System for Mobile Communications Association,
GSMA., "Guidelines for IPX Provider networks", 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 & Interworking Guidelines", May 2012.
[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", January 2012.
[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 Version 7.0",
March 2013. March 2013.
[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.1 Advanced
Communications Services and Client Specification Version Communications Services and Client Specification Version
4.0", November 2013. 4.0", November 2013.
[RFC6052] Bao, C., Huitema, C., Bagnulo, M., Boucadair, M., and X.
Li, "IPv6 Addressing of IPv4/IPv6 Translators", RFC 6052,
October 2010.
[RFC6146] Bagnulo, M., Matthews, P., and I. van Beijnum, "Stateful
NAT64: Network Address and Protocol Translation from IPv6
Clients to IPv4 Servers", RFC 6146, April 2011.
[RFC6147] Bagnulo, M., Sullivan, A., Matthews, P., and I. van
Beijnum, "DNS64: DNS Extensions for Network Address
Translation from IPv6 Clients to IPv4 Servers", RFC 6147,
April 2011.
[RFC6459] Korhonen, J., Soininen, J., Patil, B., Savolainen, T., [RFC6459] Korhonen, J., Soininen, J., Patil, B., Savolainen, T.,
Bajko, G., and K. Iisakkila, "IPv6 in 3rd Generation 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.
[RFC6535] Huang, B., Deng, H., and T. Savolainen, "Dual-Stack Hosts
Using "Bump-in-the-Host" (BIH)", RFC 6535, February 2012.
[RFC6877] Mawatari, M., Kawashima, M., and C. Byrne, "464XLAT:
Combination of Stateful and Stateless Translation", RFC
6877, April 2013.
[RFC7050] Savolainen, T., Korhonen, J., and D. Wing, "Discovery of
the IPv6 Prefix Used for IPv6 Address Synthesis", RFC
7050, November 2013.
[RFC7225] Boucadair, M., "Discovering NAT64 IPv6 Prefixes Using the
Port Control Protocol (PCP)", RFC 7225, May 2014.
[TR23.975] [TR23.975]
3rd Generation Partnership Project, 3GPP., "IPv6 migration 3rd Generation Partnership Project, 3GPP., "IPv6 migration
guidelines", June 2011. guidelines", June 2011.
[TS23.003]
3rd Generation Partnership Project, 3GPP., "Numbering,
addressing and identification v9.0.0", September 2009.
[TS23.060] [TS23.060]
3rd Generation Partnership Project, 3GPP., "General Packet 3rd Generation Partnership Project, 3GPP., "General Packet
Radio Service (GPRS); Service description; Stage 2 v9.00", Radio Service (GPRS); Service description; Stage 2 v9.00",
March 2009. March 2009.
[TS23.401] [TS23.401]
3rd Generation Partnership Project, 3GPP., "General Packet 3rd Generation Partnership Project, 3GPP., "General Packet
Radio Service (GPRS) enhancements for Evolved Universal Radio Service (GPRS) enhancements for Evolved Universal
Terrestrial Radio Access Network (E-UTRAN) access v9.00", Terrestrial Radio Access Network (E-UTRAN) access v9.00",
March 2009. March 2009.
skipping to change at page 15, line 10 skipping to change at page 18, line 15
[TS24.301] [TS24.301]
3rd Generation Partnership Project, 3GPP., "Non-Access- 3rd Generation Partnership Project, 3GPP., "Non-Access-
Stratum (NAS) protocol for Evolved Packet System (EPS) ; Stratum (NAS) protocol for Evolved Packet System (EPS) ;
Stage 3 v9.00", September 2009. Stage 3 v9.00", September 2009.
[TS29.002] [TS29.002]
3rd Generation Partnership Project, 3GPP., "Mobile 3rd Generation Partnership Project, 3GPP., "Mobile
Application Part (MAP) specification v9.12.0", December Application Part (MAP) specification v9.12.0", December
2009. 2009.
[TS29.212]
3rd Generation Partnership Project, 3GPP., "Policy and
Charging Control (PCC); Reference points v9.0.0",
September 2009.
[TS29.272] [TS29.272]
3rd Generation Partnership Project, 3GPP., "Mobility 3rd Generation Partnership Project, 3GPP., "Mobility
Management Entity (MME) and Serving GPRS Support Node Management Entity (MME) and Serving GPRS Support Node
(SGSN) related interfaces based on Diameter protocol (SGSN) related interfaces based on Diameter protocol
v9.00", September 2009. v9.00", September 2009.
Authors' Addresses Authors' Addresses
Gang Chen Gang Chen
China Mobile China Mobile
skipping to change at page 15, line 35 skipping to change at page 19, line 4
Email: phdgang@gmail.com Email: phdgang@gmail.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
Renesas Mobile Broadcom
Porkkalankatu 24 Porkkalankatu 24
FIN-00180 Helsinki, Finland FIN-00180 Helsinki, Finland
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 Vizdal Ales
Deutsche Telekom AG Deutsche Telekom AG
 End of changes. 94 change blocks. 
369 lines changed or deleted 524 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/