draft-ietf-v6ops-ipv6-roaming-analysis-00.txt   draft-ietf-v6ops-ipv6-roaming-analysis-01.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: July 17, 2014 D. Michaud Expires: January 5, 2015 D. Michaud
Rogers Communications Rogers Communications
J. Korhonen J. Korhonen
Renesas Mobile Renesas Mobile
M. Boucadair M. Boucadair
France Telecom France Telecom
A. Vizdal A. Vizdal
Deutsche Telekom AG Deutsche Telekom AG
C. Byrne July 4, 2014
T-Mobile USA
January 13, 2014
IPv6 Roaming Behavior Analysis IPv6 Roaming Behavior Analysis
draft-ietf-v6ops-ipv6-roaming-analysis-00 draft-ietf-v6ops-ipv6-roaming-analysis-01
Abstract Abstract
This document identifies as set of failure cases encountered by an This document identifies a set of failure cases encountered by an
IPv6-enabled IPv6 customers in roaming scenarios. The investigations IPv6-enabled IPv6 customers in roaming scenarios. The investigations
on those failed cases reveal the causes in order to notice improper on those failed cases reveal the causes in order to notice improper
configurations, equipment's incomplete functions or inconsistent IPv6 configurations, equipment's incomplete functions or inconsistent IPv6
introduction strategy. introduction strategy.
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 July 17, 2014. This Internet-Draft will expire on January 5, 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 2. Roaming Architecture Description . . . . . . . . . . . . . . 3
3. Roaming Scenario: Overview . . . . . . . . . . . . . . . . . 5 3. Roaming Scenario . . . . . . . . . . . . . . . . . . . . . . 5
4. Failure Cases in the Attach Stage . . . . . . . . . . . . . . 6 4. Failure Case in Attachment Stage . . . . . . . . . . . . . . 6
5. Failure Cases in the IP Allocation Stage . . . . . . . . . . 7 5. Failure Cases in PDP/PDN Creation . . . . . . . . . . . . . . 7
5.1. Case 1: Splitting Dual-stack Bearer . . . . . . . . . . . 7 5.1. Case 1: Splitting Dual-stack Bearer . . . . . . . . . . . 7
5.2. Case 2: Lack of IPv6 support in applications . . . . . . 8 5.2. Case 2: Lack of IPv6 support in applications . . . . . . 8
5.3. Case 3: Fallback Incapability . . . . . . . . . . . . . . 8 5.3. Case 3: Fallback Incapability . . . . . . . . . . . . . . 8
5.4. Case 4: 464xlat Support . . . . . . . . . . . . . . . . . 9 5.4. Case 4: 464xlat Support . . . . . . . . . . . . . . . . . 9
6. Discussions . . . . . . . . . . . . . . . . . . . . . . . . . 9 6. Discussions . . . . . . . . . . . . . . . . . . . . . . . . . 9
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10
8. Security Considerations . . . . . . . . . . . . . . . . . . . 10 8. Security Considerations . . . . . . . . . . . . . . . . . . . 10
9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 10 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 10
10. References . . . . . . . . . . . . . . . . . . . . . . . . . 11 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 11
10.1. Normative References . . . . . . . . . . . . . . . . . . 11 10.1. Normative References . . . . . . . . . . . . . . . . . . 11
10.2. Informative References . . . . . . . . . . . . . . . . . 11 10.2. Informative References . . . . . . . . . . . . . . . . . 11
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 13 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 13
1. Introduction 1. Introduction
Many Mobile Operators deployed or are in a per-deployment stage of Many Mobile Operators deployed or are in a per-deployment stage of
IPv6 in their operational networks. Customers will be delivered with IPv6 in their operational networks. Customers will be delivered with
IPv6 connectivity if their UE (User Equipment) are IPv6-compliant. IPv6 connectivity if their User Equipment (UE) are IPv6-compliant. A
Many strategies can be adopted for IPv6 introduction in mobile detailed overview of IPv6 support in 3GPP architectures is provided
networks (see for example [TR23.975]). A detailed overview of IPv6 in [RFC6459]. Operators may adopt various approaches to deploy IPv6
support in 3GPP architectures is provided in [RFC6459]. in mobile networks, for example the solutions described in
[TR23.975]). Dual-stack or IPv6 single-stack has been selected
Mobile Operators may deploy dual-stack or IPv6 single-stack depending depending on network's conditions. It has been observed that a
on network's conditions. It has been observed that those deployments mobile subscriber roaming around different operator's areas may
are rolled out in multiple provisioning domains. In the early IPv6
stage, a mobile subscriber roaming around the different areas may
experience service degradations or interruptions due to the experience service degradations or interruptions due to the
inconsistent configurations and incomplete functions in the networks inconsistent configurations and incomplete functions on the networks
nodes. nodes.
This memo intends to document the observed failed cases and analyze This memo intends to document the observed failed cases and analyze
the causes. the causes.
2. Roaming Architecture Description 2. Roaming Architecture Description
The roaming process could be triggered in the following scenarios: The roaming process has been occurred in the following scenarios:
o International roaming: a mobile UE may entry a visited network, o International roaming: a mobile UE may entry a visited network,
where different PLMN (Public Land Mobile Network) identity is where different Public Land Mobile Network (PLMN) identity is
used. UEs could, either in an automatic mode or a manual mode, used. UEs could, either in an automatic mode or a manual mode,
attach to the visited PLMN. attach to the visited PLMN.
o Intra-PLMN mobility: a UE moves to a visited network as that of o Intra-PLMN mobility: a UE moves to a visited network as that of
the Home Public Land Mobile Network (HPLMN). However, the the Home Public Land Mobile Network (HPLMN). However, the
subscriber profiles may not be stored in the area. Once the subscriber profiles may not be stored in the area. Once the
subscriber attached to the network, the subscriber profile should subscriber attached to the network, the subscriber profile should
be extracted from the home network for the network registration. be extracted from the home network for the 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 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 Public Land Mobile Networks (PLMNs) to attach. Serving available Public Land Mobile Networks (PLMNs) to attach. Serving
GPRS Support Node (SGSN) or Mobility Management Entity (MME) in the GPRS Support Node (SGSN) or Mobility Management Entity (MME) in the
visited networks must contact the Home Location Register(HLR) or Home visited networks must contact the Home Location Register(HLR) or Home
Subscriber Server(HSS) and obtain the subscriber profile. Once the Subscriber Server(HSS) and obtain the subscriber profile. Once the
authentication and registration process is completed, the PDP authentication and registration process is completed, the Packet Data
activation and traffic flows may be operated differently according to Protocol (PDP) or Packet Data Networks (PDN) activation and traffic
the subscriber data configuration. Two modes have been shown at the flows may be operated differently according to the subscriber profile
figure to illustrate, that are "Home routed traffic" (Figure 1) and stored in HLR or HSS. Two modes have been shown at the figure to
"Local breakout" (Figure 2). illustrate, that are "Home routed traffic" (Figure 1) and "Local
breakout" (Figure 2).
+---------------------------------+ +------------------------+ +---------------------------------+ +------------------------+
|Visited Network | |Home Network | |Visited Network | |Home Network |
| +----+ +--------+ | | +--------+ Traffic Flow | +----+ +--------+ | | +--------+ Traffic Flow
| | UE |==========>|SGSN/MME|======================>|GGSN/PGW|============> | | UE |==========>|SGSN/MME|======================>|GGSN/PGW|============>
| +----+ +--------+ | Signaling | +--------+ | | +----+ +--------+ | Signaling | +--------+ |
| |-------------------------->+--------+ | | |-------------------------->+--------+ |
| | | |HLR/HSS | | | | | |HLR/HSS | |
| | | +--------+ | | | | +--------+ |
+---------------------------------+ +------------------------+ +---------------------------------+ +------------------------+
skipping to change at page 4, line 22 skipping to change at page 4, line 22
| |GGSN/PGW| | | | | |GGSN/PGW| | | |
| +--------+ | | | | +--------+ | | |
| Traffic Flow || | | | | Traffic Flow || | | |
+-----------------------||--------+ +------------------------+ +-----------------------||--------+ +------------------------+
\/ \/
Figure 2: Local Breadkout Figure 2: Local Breadkout
In the home routed mode, subscribers will activate the PDP/PDN In the home routed mode, subscribers will activate the PDP/PDN
context and get address from the home network. All traffic would be context and get address from the home network. All traffic would be
routed back to the home networks. That is the default case for an routed back to the home networks. It's likely most cases for
international roaming except for the IP Multimedia Subsystem (IMS) international roaming of Internet data services to facilitate the
scenario. charging process between two operators.
In the local breakout mode, the subscriber address will be assigned In the local breakout mode, the subscriber address will be assigned
from the visited network. The traffic flow would directly offloaded from the visited network. The traffic flow is directly offloaded
locally at a network node close to that device's point of attachment locally at a network node close to that device's point of attachment
in the visited networks. Therefore, more efficient route would be in the visited networks. Therefore, more efficient route is
achieved. The following will describe the cases where there is local achieved. The international roaming of IP Multimedia Subsystem (IMS)
breakout mode adopted. 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 a operator network could use local
breakout mode in order to get efficient traffic route. The local
breakout mode could be also applied to an operators 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. The following enumerates the more specific
configuration considerations.
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 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). As the consequence, the traffic would be Point Name (APN). As the consequence, the traffic would be
steered to the visited network. Those functions are normally steered to the visited network. Those functions are normally
deployed for the Intra-PLMN mobility cases. deployed for the Intra-PLMN mobility cases.
o Operators could also configure VPLMN-Dynamic-Address-Allowed o Operators could also configure VPLMN-Dynamic-Address-Allowed
flag[TS29.272] in the user profile to enable local breakout mode flag[TS29.272] in the user profile to enable local breakout mode
skipping to change at page 5, line 5 skipping to change at page 5, line 15
o 3GPP specified Selected IP Traffic Offload (SIPTO) o 3GPP specified Selected IP Traffic Offload (SIPTO)
function[TS23.401] since Release 10 in order to get efficient function[TS23.401] since Release 10 in order to get efficient
route paths. It enables an operator to offload certain types of route paths. It enables an operator to offload certain types of
traffic at a network node close to that device's point of traffic at a network node close to that device's point of
attachment to the access network. attachment to the access network.
o GSMA has defined RAVEL[IR.65] as IMS international roaming o GSMA has defined RAVEL[IR.65] as IMS international roaming
architecture. Local breakout mode has been adopted for the architecture. Local breakout mode has been adopted for the
roaming architecture. roaming architecture.
3. Roaming Scenario: Overview 3. Roaming Scenario
3GPP specifies three types of Packet Data Protocol (PDP)/Packet Data There are two stages happened when a subscriber roams to a visited
Networks (PDN) to describe connections: PDP/PDN Type IPv4, PDP/PDN network and intends to start data services.
Type IPv6 and PDP/PDN Type IPv4v6. When establishing a data session,
user devices are configured to request a particular PDP/PDN Type.
The allowed PDP/PDN types for a particular subscriber are stored in
the Home Subscriber Server (HSS) or Home Location Register (HLR) as
part of the subscriber profile as defined in [TS29.272].
When a subscriber roams and attempts to attach to a visited network, o Nework attachment: it's occurred once the subsriber enters a
the visited network identifies the subscriber's home network. visited network. During an attachment, the visited network should
Afterwards, the visited network will contact the home network and authenticate the subsriber and make location update to the HSS/HLR
request the subscriber profile from the home HSS/HLR. The subscriber in the home network of the subsriber. Accordingly, the subscriber
profile contains the allowed Access Point Names (APN), allowed PDP/ profile is offered from the HSS/HLR. The subscriber profile
PDN Types and policies regarding the routing of data sessions (i.e. contains the allowed Access Point Names (APN), allowed PDP/PDN
home routed or local breakout mode). The failures are happened Types and rules regarding the routing of data sessions (i.e. home
either in the initial network attach stage or the IP address routed or local breakout mode) [TS29.272]. SGSN/MME in the
allocation process due to the mismatch between the subscriber visited network could use those informaiton to facilitate the
requested, allowed PDP/PDN Type and the visited network capability. subsequent PDP/PDN session creation.
The failures in the initial network process are likely occurred in o PDP/PDN context creation: it's occurred after the subsriber makes
both cases of home routed and the local breakout. The visited a sucessful attachment. It's worth nothing that this stage is
network may not be able to parse the subscription information integrated with the attachment stage in the case of 4G, but a
containing the PDP/PDN Type IPv4v6, therefore it would reject the seperated process in 2/3G. 3GPP specifies three types of Packet
attach request from roaming subscribers. Section 4 provides the Data Protocol (PDP)/Packet Data Networks (PDN) to describe
detailed discussion on the causes and known solutions. connections, i.e., PDP/PDN Type IPv4, PDP/PDN Type IPv6 and PDP/
PDN Type IPv4v6. When a subsriber creates a data session, a user
device is configured to request a particular PDP/PDN Type. The
allowed PDP/PDN types for the subscriber are learned from the
attachment stage. Hence, SGSN/MME could initiate PDP/PDN request
to GGSN/PGW if the subscription profile is allowed.
Even if roaming subscribers have a successful attach to the visited The failures are likely happened in both stages due to an incompliant
network, there are still some failures during the IP address implementation or mismatch between the subscriber requested and the
allocation. Those failures are mainly appeared in the local breakout visited network capability. The failures in the attachment stage is
cases. The below table lists the potential cases. Section 5 makes independent with home routed and local breakout mode, while most
further descriptions for the each case. failure cases in the PDP/PDN context creation stage are appeared in
the local breakout cases. Section 4 and 5 make further descriptions
for each cases. The below table lists the several cases regarding
the PDP/PDN creation stage.
+-------------+-------------------+--------------+ +-------------+-------------------+--------------+
| UE request | PDN/PDP IP Type |Local breakout| | UE request | PDN/PDP IP Type |Local breakout|
| | permitted | | | | permitted | |
+-------------+-------------------+--------------+ +-------------+-------------------+--------------+
| IPv4v6 | IPv4 or IPv6 |Failure case 1| | IPv4v6 | IPv4 or IPv6 |Failure case 1|
+-------------+-------------------+--------------+ +-------------+-------------------+--------------+
| IPv4v6 | IPv6 |Failure case 2| | IPv4v6 | IPv6 |Failure case 2|
+-------------+-------------------+--------------+ +-------------+-------------------+--------------+
| IPv6 | IPv4 |Failure case 3| | IPv6 | IPv4 |Failure case 3|
+-------------+-------------------+--------------+ +-------------+-------------------+--------------+
| IPv6 | IPv6 |Failure case 4| | IPv6 | IPv6 |Failure case 4|
| with 464xlat| without NAT64 | | | with 464xlat| without NAT64 | |
+-------------+-------------------+--------------+ +-------------+-------------------+--------------+
Table 1: Roaming Scenario Descriptions Table 1: Roaming Scenario Descriptions
4. Failure Cases in the Attach Stage 4. Failure Case in Attachment Stage
3GPP specified PDP/PDN type IPv4v6 into 3G network since Release 9.
It allows a User Equipment (UE) to request both IPv4 and IPv6 within
a single PDP/PDN request. This feature is stored as a part of
subscription data for a subscriber in the Home Location
Registrar(HLR) or Home Subscriber Server(HSS). It should be
understandable to the Serving GPRS Support Node (SGSN) during the
network attach process. However, operators may have different
strategies to upgrade their network to support this new feature. If
the home network populates the PDP/PDN type IPv4v6 in the
subscription data and the visited network just stay as early as pre-
Release 9, the failure is likely to be encountered.
When a subscriber roams to an IPv4 network, the visited SGSN has to 3GPP specified PDP/PDN type IPv4v6 in order to allow a UE requesting
communicate with HLR/HSS in the home land to retrieve the subscriber both IPv4 and IPv6 within a single PDP/PDN request. This feature is
profile. The issue we observe is that multiple SGSNs will be unable stored as a part of subscription data for a subscriber in the HLR/
to correctly process a subscriber data received in the Insert HSS. PDP/PDN type IPv4v6 is introduced since the inception of
Subscriber Data procedure[TS23.060] if it contains an Ext-PDP-Type Evolved Packet System (EPS) in 4G network. The nodes in 4G networks
defined in 3GPP [TS29.002]. As a consequence , it will likely refuse should no issues with the handling of this PDN type. However, it's
the subscriber attach request. of varing supports in 2/3G networks denpending on Serving GPRS
Support Node (SGSN) software version. In theory, S4-SGSN (i.e., the
SGSN with S4 interface) support the PDP/PDN type IPv4v6 since
Release8 and Gn-SGSN (i.e., the SGSN with Gn interface) support 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
[TS29.002], is used over the Gr interface between SGSN and HLR. The
MAP Information Element (IE) "ext-pdp-Type" contains the IPv4v6 PDP
Type is conveyed to SGSN from HLR within the Insert 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 consequently must
silently discard that IE and continue processing of the rest of the
ISD MAP message. The issue we observe is that multiple SGSNs will be
unable to correctly process a subscriber data received in the Insert
Subscriber Data procedure[TS23.060]. As a consequence , it will
likely refuse the subscriber attach request, which is erroneous
behaviour as they are not 3GPP compliant.
Operators may have to remove the PDP/PDN type IPv4v6 from HLR/HSS in Operators may have to remove the PDP/PDN type IPv4v6 from HLR/HSS in
the home network, that will restrict UEs only initiates IPv4 PDP or the home network, that will restrict UEs only initiates IPv4 PDP or
IPv6 PDP activation. In order to avoid this situation, operators IPv6 PDP activation. In order to avoid this situation, operators
should make a comprehensive roaming agreement to support IPv6 and should make a comprehensive roaming agreement to support IPv6 and
ensure that aligns with GSMA document, e.g [IR.33], [IR.88] and ensure that aligns with GSMA document, e.g [IR.33], [IR.88] and
[IR.21]. Since the agreement requires visited operators to upgrade
all SGSN nodes, some short- or medium-term solutions have been
implemented to fix the issue. There are some specific configurations
in HLS/HSS of home network. Multiple PDP/PDN subscription
information will be added in the subscriber profiles, for example it
may include both PDP/PDN type IPv4 and PDP/PDN type IPv4v6 for a user
profile. Once the HLR/HSS receives an Update Location message from
visited SGSN, only the subscription data with PDP/PDN type IPv4 will
be sent to SGSN/MME in the Insert Subscriber Data procedure. It
guarantee the user profile could compatible with visited SGSN/MME
capability.
5. Failure Cases in the IP Allocation Stage [IR.21]. The agreement requires visited operators to get necessary
patch on all SGSN nodes to support PDP/PDN type IPv4v6.
There are some specific implementation in HLS/HSS of home network as
an alternative solution. Once the HLR/HSS receives an Update
Location message from visited SGSN known to not support the PDP type
IPv4v6, only the subscription data with PDP/PDN type IPv4 will be
sent to SGSN in the Insert Subscriber Data procedure. It guarantee
the user profile could compatible with visited SGSN/MME capability.
5. Failure Cases in PDP/PDN Creation
Once a subscriber succeed in the attach stage, IP allocation process Once a subscriber succeed in the attach stage, IP allocation process
is taken place to allocate IP addresses to the subscriber. This is taken place to allocate IP addresses to the subscriber. This
section has summarized several failures in the break-out cases. section has summarized several failures in the break-out cases.
5.1. Case 1: Splitting Dual-stack Bearer 5.1. Case 1: Splitting Dual-stack Bearer
Dual-stack capability can be provided in a early mobile network (i.e. Dual-stack capability can be provided using separate PDP/PDN
Pre-Release 8 network) using separate PDP/PDN activations. That activations. That means only a single IPv4 and IPv6 PDP/PDN is
means only a single IPv4 and IPv6 PDP/PDN is allowed to be initiated allowed to be initiated to allocate IPv4 and IPv6 address separately.
to allocate IPv4 and IPv6 address separately. The below demonstrates The below lists the cases.
the cases.
o The GGSN/PGW preferences dictate the use of IPv4 addressing only o The SGSN/MME returns Session Manamgement (SM) Cause #52, "Single
or IPv6 prefix only for a specific APN. address bearers only allowed", or SM Cause #28 "Unknown PDP
address or PDP type" as per[TS24.008] and [TS24.301].
o The SGSN/MME does not set the Dual Address Bearer Flag due to the o The SGSN/MME does not set the Dual Address Bearer Flag due to the
operator using single addressing per bearer to support operator using single addressing per bearer to support
interworking with nodes of earlier releases interworking with nodes of earlier releases
A roaming subscriber with IPv4v6 PDP/PDN type have to change the A roaming subscriber with IPv4v6 PDP/PDN type have to change the
request into two separated PDP/PDN requests with single IP version in request into two separated PDP/PDN requests with single IP version in
order to achieve equivalent results. Some drawbacks in this case are order to achieve equivalent results. Some drawbacks in this case are
listed as following: listed as following:
o The parallel PDP/PDN activations would likely double PDP/PDN o The parallel PDP/PDN activations would likely double PDP/PDN
resources consumptions. It impacts the capacity of GGSN/PGW, resources consumptions. It impacts the capacity of GGSN/PGW,
since a certain amount of PDP/PDN activations are only allowed on since a certain amount of PDP/PDN activations are only allowed on
those nodes. those nodes.
o Some networks may only allow one PDP/PDN is alive for each o Some networks may only allow one PDP/PDN is alive for each
subscriber. For example, IPv6 PDP/PDN will be rejected if the subscriber. For example, 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 lost IPv6 connection in the visited network. will lost IPv6 connection in the visited network. It's even worse
that it may have a risk of losing all data connectivity if the
IPv6 PDP gets rejected with a permanent error at the APN-level 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)/Policy and Charging
Enforcement Function (PCEF) treat IPv4 and IPv6 session as Enforcement Function (PCEF) treat IPv4 and IPv6 session as
independent and perform different Quality of Service (QoS) independent and perform different Quality of Service (QoS)
policies. The subscriber may have unstable experiences due to policies. The subscriber may have unstable experiences due to
different behaviors on each IP version connection. different behaviors on each IP version connection.
o Mobile devices may have the limitation of allowed simultaneous PDP o Mobile devices may have the limitation of allowed simultaneous
/PDN activations. Overmuch PDP/PDN activation may result in other PDP/PDN activations. Overmuch PDP/PDN activation may result in
unrelated services broken. other unrelated services broken.
Operators may have to disable the local-break mode to avoid the Operators may have to disable the local-break mode to avoid the
risks. Another approach is to set a dedicated Access Point Name risks. Another approach is to set a dedicated Access Point Name
(APN) profile to only request IPv4 PDP/PDN type in the roaming (APN) profile to only request PDP/PDN type IPv4 in the roaming
network. network.
5.2. Case 2: Lack of IPv6 support in applications 5.2. Case 2: Lack of IPv6 support in applications
Some operators may adopt IPv6-only configuration for the IMS service, Some operators may adopt IPv6-only configuration for the IMS service,
e.g. Voice over LTE(VoLTE)[IR.92] or Rich Communication Suite e.g. Voice over LTE (VoLTE)[IR.92] or Rich Communication Suite
(RCS)[RCC.07]. Since IMS roaming architecture will offload all (RCS)[RCC.07]. Since IMS roaming architecture will offload all
traffic in the visited network, a dual-stack subscriber can only be traffic in the visited network, a dual-stack subscriber can only be
assigned with IPv6 address and no IPv4 address returned. It requires assigned with IPv6 address and no IPv4 address returned. It requires
all the IMS based applications should be IPv6 capable. A all the IMS based applications should be IPv6 capable. A
translation-based method, for example Bump-in-the-host (BIH)[RFC6535] translation-based method, for example Bump-in-the-host (BIH)[RFC6535]
or 464xlat [RFC6877] may help to address the issue if there are IPv6 or 464xlat [RFC6877] may help to address the issue if there are IPv6
compatibility problems. Those functions could be automatically compatibility problems. Those functions could be automatically
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. network.
5.3. Case 3: Fallback Incapability 5.3. Case 3: Fallback Incapability
3GPP specified the PDP/PDN type IPv6 as early as PDP/PDN type IPv4. 3GPP specified the PDP/PDN type IPv6 as early as PDP/PDN type IPv4.
Therefore, the IPv6 single PDP/PDN type has been well supported and Therefore, the IPv6 single PDP/PDN type has been well supported and
interpretable in the 3GPP network nodes. Roaming to IPv4-only interpretable in the 3GPP network nodes. Roaming to IPv4-only
networks with IPv6 PDP/PDN request could guarantee the subscription networks with IPv6 PDP/PDN request could guarantee the subscription
data is compatible with the visited pre-Release 9 SGSN. When a data is compatible with the visited pre-Release 9 SGSN. When a
subscriber requests PDP/PDN type IPv6, the network should only return subscriber requests PDP/PDN type IPv6, the network should only return
the expected IPv6 address. The mobile device may be failed to get IP the expected IPv6 address. The mobile device may be failed to get IP
address if the visited network only allocates an IPv4 address to a address if the visited network only allocates an IPv4 address to a
subscriber. In that case, the request will be dropped and the error subscriber. In that case, the request will be dropped and the cause
code should be sent to the user. code should be sent to the user.
A proper fallback is desirable however the behavior is implementation A proper fallback is desirable however the behavior is implementation
specific. There are some mobile devices have the ability to provide specific. There are some mobile devices have the ability to provide
a different configuration for home network and visited network a different configuration for home network and visited network
respectively. It guarantees UE will always initiate PDP/PDN type respectively. Android system solves the issue by setting the roaming
IPv4 in the roaming area. Android system solves the issue by setting Access Point Name(APN). It guarantees UE will always initiate PDP/
the roaming Access Point Name(APN). The mobile terminal is allowed PDN type IPv4 in the roaming area.
to ignore the original requested protocol and always adhere to IPv4
when roaming.
5.4. Case 4: 464xlat Support 5.4. Case 4: 464xlat Support
464xlat[RFC6877] is proposed to address IPv4 compatibility issue in a 464xlat[RFC6877] is proposed to address IPv4 compatibility issue in a
IPv6 single-stack environment. The function on a mobile terminal IPv6 single-stack environment. The function on a mobile terminal
likely gets along with PDP/PDN IPv6 type request to cooperate with a likely gets along with PDP/PDN IPv6 type request to cooperate with a
remote NAT64[RFC6146] gateway. 464xlat may use the mechanism defined remote NAT64[RFC6146] gateway. 464xlat may use the mechanism defined
in [RFC7050] to automatically detect the presence of DNS64 and learn in [RFC7050] to automatically detect the presence of DNS64 and learn
the IPv6 prefix used for protocol translation. When a mobile device the IPv6 prefix used for protocol translation. When a mobile device
with 464xlat function roams to an IPv6 visited network without the with 464xlat function roams to an IPv6 visited network without the
presence of NAT64 or DNS64, 464xlat may get failed to perform if presence of NAT64 or DNS64, 464xlat may get failed to perform if
traffic is undergoing the local breakout approach. traffic is undergoing the local breakout approach.
The issue has been found mostly in a intra-PLMN mobility case. The issue has been found mostly in a intra-PLMN mobility case for the
Considering the various network's situations, operators may turn off time being. Considering the various network's situations, operators
the local breakout and take home routed mode to perform 464xlat. may turn off the local breakout and take home routed mode to perform
Some devices may support the configuration to adopt 464xlat in the 464xlat. Some devices may support the configuration to adopt 464xlat
home networks and use IPv4-only in the visited networks with in the home networks and use IPv4-only in the visited networks with
different roaming profile configurations. It could also be a different roaming profile configurations. It could also be a
solution to address this issue. solution to address this issue.
6. Discussions 6. Discussions
Several failure cases have been discussed in this memo. It has been Several failure cases have been discussed in this document. It has
testified the major issues are occurred at the two stages, i.e. the been testified the major issues are occurred at the two stages, i.e.,
initial network attach and the IP allocation process. the initial network attach and the IP allocation process.
During the initial network attach, PDP/PDN type IPv4v6 is major During the initial network attach, PDP/PDN type IPv4v6 is major
concern to the visited pre-Release 9 SGSN. The dual-stack deployment concern to the visited pre-Release 9 SGSN. The dual-stack deployment
is recommended in most cases. However, it may take some times in a is recommended in most cases. However, it may take some times in a
mobile environment. 3GPP didn't specify PDP/PDN type IPv4v6 in the mobile environment. 3GPP didn't specify PDP/PDN type IPv4v6 in the
early release. Such PDP/PDN type is supported in new-built Long Term early release. Such PDP/PDN type is supported in new-built EPS
Evolution(LTE)/System Architecture Evolution(SAE) network, but didn't network, but didn't support well in the third generation network.
support well in the third generation network. The situations may The situations may cause the roaming issues dropping the attach
cause the roaming issues dropping the attach request from dual-stack request from dual-stack subscribers. Operators may have to adopt
subscribers. Operators may have to adopt temporary solution unless temporary solution unless all the interworking nodes(i.e. SSGN) in
all the interworking nodes(i.e. SSGN) in the visited network have the visited network have been upgraded to support ext-PDP-Type
been upgraded to support Ext-PDP-Type feature. feature.
The issues in the IP address allocation process are caused due to the The issues in the IP address allocation process are caused due to the
local breakout policy. Since the IP address is allocated by the local breakout policy. Since the IP address is allocated by the
visited GGSN or PGW, the mismatch is found in the following aspects. visited GGSN or PGW, the mismatch is found in the following aspects.
o The mismatch between requested PDP/PDN type and permitted PDP/PDN o The mismatch between requested PDP/PDN type and permitted PDP/PDN
type type
o The mismatch between application capability and allowed network o The mismatch between application capability and allowed network
connections connections
o The mismatch between mobile device function (e.g., 464xlat) and o The mismatch between mobile device function (e.g., 464xlat) and
particular network deployment status particular network deployment status
There are some solutions to overcome the issue. Those solutions can There are some solutions to overcome the issue. Those solutions can
be done either in the network side or mobile devices side. The below be done either in the network side or mobile device side. The below
lists potential workarounds. lists potential workarounds.
o Change local breakout to the home routed mode o Change local breakout to the home routed mode
o A dedicated roaming APN profile is implemented for roamer. When a o A dedicated roaming APN profile is implemented for roamer. When a
subscriber roams to a visited network, PDP/PDN type IPv4 is always subscriber roams to a visited network, PDP/PDN type IPv4 is always
be selected for session activation. be selected for session activation.
o Networks could deploy AAA server to coordinate the mobile device o Networks could deploy AAA server to coordinate the mobile device
capability. Once the GGSN/PGW receive the session creation capability. Once the GGSN/PGW receive the session creation
requests, it will initiate an Access-Request to an AAA server via requests, it will initiate an Access-Request to an AAA server in
the Radius protocol. The Access-Request contains subscriber and the home land via the Radius protocol. The Access-Request
visited network information, e.g. PDP/PDN Type, International contains subscriber and visited network information, e.g. PDP/PDN
Mobile Equipment Id (IMEI), Software Version(SV) and visited SGSN/ Type, International Mobile Equipment Id (IMEI), Software
MME location code, etc. The AAA server could take mobile device Version(SV) and visited SGSN/MME location code, etc. The AAA
capability combining with the visited network information to server could take mobile device capability combining with the
ultimately determine the type of session to be created, i.e. IPv4, visited network information to ultimately determine the type of
IPv6 or IPv4v6. session to be created, i.e. IPv4, IPv6 or IPv4v6.
7. IANA Considerations 7. IANA Considerations
This document makes no request of IANA. This document makes no request of IANA.
8. Security Considerations 8. Security Considerations
Even if this document does not define a new architecture nor a new Even if this document does not define 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.
9. Acknowledgements 9. 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 and Tore Anderson for their helpful Heatley Nick, Alexandru Petrescu, Tore Anderson and Cameron Byrne for
comments. their helpful comments.
10. References 10. References
10.1. Normative References 10.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997. Requirement Levels", BCP 14, RFC 2119, March 1997.
[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,
skipping to change at page 11, line 38 skipping to change at page 11, line 38
[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.
[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.
10.2. Informative References 10.2. Informative References
[EU-Roaming-III]
"http://www.amdocs.com/Products/Revenue-
Management/Documents/
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.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.
skipping to change at page 12, line 14 skipping to change at page 12, line 17
[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.
[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.
[RFC6586] Arkko, J. and A. Keranen, "Experiences from an IPv6-Only [RFC6586] Arkko, J. and A. Keranen, "Experiences from an IPv6-Only
Network", RFC 6586, April 2012. Network", RFC 6586, April 2012.
[TR23.975] [TR23.975]
3rd Generation Partnership Project, 3GPP., "IPv6 migration 3rd Generation Partnership Project, 3GPP., "IPv6 migration
skipping to change at page 12, line 41 skipping to change at page 12, line 40
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.
[TS24.008]
3rd Generation Partnership Project, 3GPP., "Mobile radio
interface Layer 3 specification; Core network protocols;
Stage 3 v9.00", September 2009.
[TS24.301]
3rd Generation Partnership Project, 3GPP., "Non-Access-
Stratum (NAS) protocol for Evolved Packet System (EPS) ;
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.00", December Application Part (MAP) specification v9.00", December
2009. 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.
skipping to change at page 13, line 39 skipping to change at page 14, line 4
Canada Canada
Email: dave.michaud@rci.rogers.com Email: dave.michaud@rci.rogers.com
Jouni Korhonen Jouni Korhonen
Renesas Mobile Renesas Mobile
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
Tomickova 2144/1 Tomickova 2144/1
Prague 4, 149 00 Prague 4, 149 00
Czech Republic Czech Republic
Email: ales.vizdal@t-mobile.cz Email: ales.vizdal@t-mobile.cz
Cameron Byrne
T-Mobile USA
Bellevue
Washington 98105
USA
Email: cameron.byrne@t-mobile.com
 End of changes. 46 change blocks. 
148 lines changed or deleted 174 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/