draft-ietf-v6ops-ipv6-roaming-analysis-05.txt   draft-ietf-v6ops-ipv6-roaming-analysis-06.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: March 5, 2015 D. Michaud Expires: April 15, 2015 D. Michaud
Rogers Communications Rogers Communications
J. Korhonen J. Korhonen
Broadcom Broadcom
M. Boucadair M. Boucadair
France Telecom France Telecom
A. Vizdal A. Vizdal
Deutsche Telekom AG Deutsche Telekom AG
September 1, 2014 October 12, 2014
IPv6 Roaming Behavior Analysis IPv6 Roaming Behavior Analysis
draft-ietf-v6ops-ipv6-roaming-analysis-05 draft-ietf-v6ops-ipv6-roaming-analysis-06
Abstract Abstract
This document identifies a set of failure cases that may be This document identifies a set of failure cases that may be
encountered by IPv6-enabled mobile customers in roaming scenarios. encountered by IPv6-enabled mobile customers in roaming scenarios.
The analysis reveals that the failure causes include improper The analysis reveals that the failure causes include improper
configurations, incomplete functionality support in equipment, and configurations, incomplete functionality support in equipment, and
inconsistent IPv6 deployment strategies between the home and the inconsistent IPv6 deployment strategies between the home and the
visited networks. visited networks.
skipping to change at page 1, line 43 skipping to change at page 1, line 43
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 March 5, 2015. This Internet-Draft will expire on April 15, 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
skipping to change at page 2, line 20 skipping to change at page 2, line 20
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3 1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3
2. Background . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Background . . . . . . . . . . . . . . . . . . . . . . . . . 3
2.1. Roaming Architecture: An Overview . . . . . . . . . . . . 3 2.1. Roaming Architecture: An Overview . . . . . . . . . . . . 4
2.1.1. Home Routed Mode . . . . . . . . . . . . . . . . . . 4 2.1.1. Home Routed Mode . . . . . . . . . . . . . . . . . . 4
2.1.2. Local Breakout Mode . . . . . . . . . . . . . . . . . 5 2.1.2. Local Breakout Mode . . . . . . . . . . . . . . . . . 5
2.2. Typical Roaming Scenarios . . . . . . . . . . . . . . . . 6 2.2. Typical Roaming Scenarios . . . . . . . . . . . . . . . . 6
3. Failure Case in the Network Attachment . . . . . . . . . . . 7 3. Failure Case in the Network Attachment . . . . . . . . . . . 7
4. Failure Cases in the PDP/PDN Creation . . . . . . . . . . . . 8 4. Failure Cases in the PDP/PDN Creation . . . . . . . . . . . . 8
4.1. Case 1: Splitting Dual-stack Bearer . . . . . . . . . . . 9 4.1. Case 1: Splitting Dual-stack Bearer . . . . . . . . . . . 9
4.2. Case 2: IPv6 PDP/PDN Unsupported . . . . . . . . . . . . 10 4.2. Case 2: IPv6 PDP/PDN Unsupported . . . . . . . . . . . . 10
4.3. Case 3: Inappropriate Roaming APN Set . . . . . . . . . . 11 4.3. Case 3: Inappropriate Roaming APN Set . . . . . . . . . . 11
4.4. Case 4: Fallback Failure . . . . . . . . . . . . . . . . 11 4.4. Case 4: Fallback Failure . . . . . . . . . . . . . . . . 11
5. Failure Cases in the Service Requests . . . . . . . . . . . . 11 5. Failure Cases in the Service Requests . . . . . . . . . . . . 11
5.1. Lack of IPv6 Support in Applications . . . . . . . . . . 11 5.1. Lack of IPv6 Support in Applications . . . . . . . . . . 11
5.2. 464xlat Support . . . . . . . . . . . . . . . . . . . . . 12 5.2. 464xlat Support . . . . . . . . . . . . . . . . . . . . . 12
6. HLR/HSS User Profile Setting . . . . . . . . . . . . . . . . 12 6. HLR/HSS User Profile Setting . . . . . . . . . . . . . . . . 12
7. Discussion . . . . . . . . . . . . . . . . . . . . . . . . . 14 7. Discussion . . . . . . . . . . . . . . . . . . . . . . . . . 14
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15
9. Security Considerations . . . . . . . . . . . . . . . . . . . 15 9. Security Considerations . . . . . . . . . . . . . . . . . . . 15
10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 15 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 15
11. Informative References . . . . . . . . . . . . . . . . . . . 16 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 16
11.1. Normative References . . . . . . . . . . . . . . . . . . 16
11.2. Informative References . . . . . . . . . . . . . . . . . 17
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 18 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. IPv6 connectivity if their User Equipment (UE) is IPv6-compliant.
Operators may adopt various approaches to deploy IPv6 in mobile Operators may adopt various approaches to deploy IPv6 in mobile
networks such as the solutions described in [TR23.975]). Depending networks such as the solutions described in [TR23.975]). Depending
on network conditions, either dual-stack or IPv6-only deployment on network conditions, either dual-stack or IPv6-only deployment
skipping to change at page 4, line 39 skipping to change at page 4, line 45
The following sub-sections describe two roaming modes: Home routed The following sub-sections describe two roaming modes: Home routed
traffic (Section 2.1.1) and Local breakout (Section 2.1.2). traffic (Section 2.1.1) and Local breakout (Section 2.1.2).
2.1.1. Home Routed Mode 2.1.1. Home Routed Mode
In this mode, the subscriber's UE gets IP addresses from the home In this mode, the subscriber's UE gets IP addresses from the home
network. All traffic belonging to that UE is therefore routed to the network. All traffic belonging to that UE is therefore routed to the
home network (Figure 1). home network (Figure 1).
GPRS roaming exchange (GRX) or Internetwork Packet Exchange (IPX) GPRS roaming exchange (GRX) or Internetwork Packet Exchange (IPX)
networks [IR.34] is likely to be invoked as the transit network to networks [IR.34] are likely to be invoked as the transit network to
deliver the traffic. This is the main mode for international roaming deliver the traffic. This is the main mode for international roaming
of Internet data services to facilitate the charging process between of Internet data services to facilitate the charging process between
the two involved operators. the two involved operators.
+-----------------------------+ +------------------------+ +-----------------------------+ +------------------------+
|Visited Network | |Home Network | |Visited Network | |Home Network |
| +----+ +--------+ | (GRX/IPX) | +--------+ Traffic Flow | +----+ +--------+ | (GRX/IPX) | +--------+ Traffic Flow
| | UE |=======>|SGSN/MME|====================>|GGSN/PGW|============> | | UE |=======>|SGSN/MME|====================>|GGSN/PGW|============>
| +----+ +--------+ | Signaling | +--------+ | | +----+ +--------+ | Signaling | +--------+ |
| |------------------------>+--------+ | | |------------------------>+--------+ |
skipping to change at page 5, line 42 skipping to change at page 5, line 42
| +--------+ | | | | +--------+ | | |
| |GGSN/PGW| | | | | |GGSN/PGW| | | |
| +--------+ | | | | +--------+ | | |
| Traffic Flow || | | | | Traffic Flow || | | |
+--------------------||------+ +----------------+ +--------------------||------+ +----------------+
\/ \/
Figure 2: Local Breakout Figure 2: Local Breakout
The international roaming of IP Multimedia Subsystem (IMS) based The international roaming of IP Multimedia Subsystem (IMS) based
services, e.g. Voice over LTE (VoLTE)[IR.92], is claimed to select services, e.g., Voice over LTE (VoLTE)[IR.92], is claimed to select
the local breakout mode in [IR.65]. Data service roaming across the local breakout mode in [IR.65]. Data service roaming across
different areas within an operator network might use local breakout different areas within an operator network might use local breakout
mode in order to get more efficient traffic forwarding and also ease mode in order to get more efficient traffic forwarding and also ease
emergency services. The local breakout mode could also be applied to emergency services. The local breakout mode could also be applied to
an operator's alliance for international roaming of data service. an operator's alliance for international roaming of data service.
EU Roaming Regulation III [EU-Roaming-III] involves local breakout EU Roaming Regulation III [EU-Roaming-III] involves local breakout
mode allowing European subscribers roaming in European 2G/3G networks mode allowing European subscribers roaming in European 2G/3G networks
to have their Internet data routed directly to the Internet from to have their Internet data routed directly to the Internet from
their current VPLMN. their current VPLMN.
Specific local breakout related configuration considerations are Specific local breakout-related configuration considerations are
listed below: listed below:
o Operators may add the APN-OI-Replacement flag defined in 3GPP o Operators may add the APN-OI-Replacement flag defined in 3GPP
[TS29.272] into the user's subscription-data. The visited network [TS29.272] into the user's subscription-data. The visited network
indicates a local domain name to replace the user requested Access indicates a local domain name to replace the user requested Access
Point Name (APN). Consequently, the traffic would be steered to Point Name (APN). Consequently, the traffic would be steered to
the visited network. Those functions are normally deployed for the visited network. Those functions are normally deployed for
the intra-PLMN mobility cases. the intra-PLMN mobility cases.
o Operators may also configure the VPLMN-Dynamic-Address-Allowed o Operators may also configure the VPLMN-Dynamic-Address-Allowed
flag [TS29.272] in the user's profile to enable local breakout flag [TS29.272] in the user's profile to enable local breakout
mode in a Visited Public Land Mobile Networks (VPLMNs). mode in Visited Public Land Mobile Networks (VPLMNs).
o 3GPP specified Selected IP Traffic Offload (SIPTO) function o 3GPP specified Selected IP Traffic Offload (SIPTO) function
[TS23.401] since Release 10 in order to get efficient route paths. [TS23.401] since Release 10 in order to get efficient route paths.
It enables an operator to offload a portion of the traffic at a It enables an operator to offload a portion of the traffic at a
network node close to the visiting UE's point of attachment to the network node close to the visiting UE's point of attachment to the
visited network. visited network.
o GSMA has defined Roaming Architecture for Voice over LTE with o GSMA has defined Roaming Architecture for Voice over LTE with
Local Breakout (RAVEL) [IR.65] as the IMS international roaming 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
skipping to change at page 6, line 50 skipping to change at page 6, line 50
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 UE has o PDP/PDN context creation: this occurs after the subscriber UE has
been successfully attached to the network. This stage is been successfully attached to the network. This stage is
integrated with the attachment stage in the case of 4G, but is a integrated with the attachment stage in the case of 4G, but is a
separate process in 2/3G. 3GPP specifies three types of PDP/PDN to separate process in 2/3G. 3GPP specifies three types of PDP/PDN to
describe connections, i.e. PDP/PDN Type IPv4, PDP/PDN Type IPv6 describe connections, i.e., PDP/PDN Type IPv4, PDP/PDN Type IPv6
and PDP/ PDN Type IPv4v6. When a subscriber creates a data and PDP/ PDN Type IPv4v6. When a subscriber creates a data
session, their device requests a particular PDP/PDN Type. The session, their device requests a particular PDP/PDN Type. The
allowed PDP/PDN types for that subscriber are learned in the allowed PDP/PDN types for that subscriber are learned in the
attachment stage. Hence, SGSN/MME could initiate PDP/PDN request attachment stage. Hence, SGSN/MME could initiate PDP/PDN request
to GGSN/PGW modulo subscription grants. to GGSN/PGW modulo subscription grants.
o Service requests: when the PDP/PDN context is created o Service requests: when the PDP/PDN context is created
successfully, UEs may launch applications and request services successfully, UEs may launch applications and request services
based on the allocated IP addresses. The service traffic will be based on the allocated IP addresses. The service traffic will be
transmitted via the visited network. transmitted via the visited network.
skipping to change at page 8, line 11 skipping to change at page 8, line 11
In order to avoid encountering this attach problem at a visited SGSN, In order to avoid encountering this attach problem at a visited SGSN,
both operators should make a comprehensive roaming agreement to both operators should make a comprehensive roaming agreement to
support IPv6 and ensure that it aligns with the GSMA documents, e.g., support IPv6 and ensure that it aligns with the GSMA documents, e.g.,
[IR.33], [IR.88] and [IR.21]. Such an agreement requires the visited [IR.33], [IR.88] and [IR.21]. Such an agreement requires the visited
operator to get the necessary patch on all its SGSN nodes to support operator to get the necessary patch on all its SGSN nodes to support
the "ext-pdp-Type" MAP IE sent by the HLR. To ensure data session the "ext-pdp-Type" MAP IE sent by the HLR. To ensure data session
continuity in Radio Access Technology (RAT) handovers the PDN Type continuity in Radio Access Technology (RAT) handovers the PDN Type
sent by the HSS to the MME could be consistent with the PDP Type sent sent by the HSS to the MME could be consistent with the PDP Type sent
by the HLR to the Gn-SGSN. Where roaming agreements and visited SGSN by the HLR to the Gn-SGSN. Where roaming agreements and visited SGSN
nodes have not been updated the HPLMN also has to make use of nodes have not been updated, the HPLMN also has to make use of
specific implementations (not standardized by 3GPP, discussed further specific implementations (not standardized by 3GPP, discussed further
in (Section 6) in the HLR/HSS of the home network. That is, when the 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 HLR/HSS receives an Update Location message from a visited SGSN not
known to support dual-stack in a single bearer, subscription data 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 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 the Insert Subscriber Data procedure. This guarantees that the user
profile is compatible with the visited SGSN/MME capability. In profile is compatible with the visited SGSN/MME capability. In
addition, HSS may not have to change, if the PGW is aware of addition, HSS may not have to change, if the PGW is aware of
subscriber's roaming status and only restricts the accepted PDN type subscriber's roaming status and only restricts the accepted PDN type
consistent with PDP type sent by the HLR. For example, an AAA server consistent with PDP type sent by the HLR. For example, an AAA server
may coordinate with the PGW to decide the allowed PDN type. may coordinate with the PGW to decide the allowed PDN type.
skipping to change at page 9, line 45 skipping to change at page 9, line 45
type" as per [TS24.008] and [TS24.301] to the UE. In this case, the 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 UE may make another PDP/PDN request with a single address PDP type
(IPv4 or IPv6) other than the one already activated. (IPv4 or IPv6) other than the one already activated.
This approach suffers from the followings drawbacks: This approach suffers from the followings drawbacks:
o The parallel PDP/PDN activation would likely double PDP/PDN bearer o The parallel PDP/PDN activation would likely double PDP/PDN bearer
resource on the network side and Radio Access Bearer (RAB) resource on the network side and Radio Access Bearer (RAB)
resource on the RAN side. It also impacts the capacity of the resource on the RAN side. It also impacts the capacity of the
GGSN/PGW, since only a certain amount of PDP/PDN activation is GGSN/PGW, since only a certain amount of PDP/PDN activation is
only allowed on those nodes. allowed on those nodes.
o Some networks may only allow one PDP/PDN be alive for each 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 would not be able to obtain the IPv6 connection in the visited
worse as they may have a risk of losing all data connectivity if network. It is even worse as they may have a risk of losing all
the IPv6 PDP gets rejected with a permanent error at the APN-level data connectivity if the IPv6 PDP gets rejected with a permanent
and not specific to the PDP-Type IPv6 requested. error at the APN-level and not an error 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) [TS29.212]/ Policy and o Policy and Charging Rules Function (PCRF) [TS29.212]/ Policy and
Charging Enforcement Function (PCEF) treats the IPv4 and IPv6 Charging Enforcement Function (PCEF) treats the IPv4 and IPv6
session as independent and performs different Quality of Service session as independent and performs different Quality of Service
(QoS) policies. The subscriber may have unstable experiences due (QoS) policies. The subscriber may have unstable experiences due
to 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 contexts. Excessive PDP/PDN activation may result in service PDN contexts. Excessive PDP/PDN activation may result in service
disruption. disruption.
In order to avoid the issue, the roaming agreement in the home routed In order to avoid the issue, the roaming agreement in the home routed
mode should make sure the visited SGSN support and set the DAF. mode should make sure the visited SGSN supports and set the DAF.
Since the PDP/PDN type IPv4v6 is supported in the GGSN/PGW of home Since the PDP/PDN type IPv4v6 is supported in the GGSN/PGW of home
network, it's expected that the visited SGSN/MME could create dual- network, it's expected that the visited SGSN/MME could create dual-
stack bearer as UE requested. stack bearer as UE requested.
In the local breakout mode, the visited SGSN may only allow single IP In the local breakout mode, the visited SGSN may only allow single IP
version addressing. In this case, DAF on visited SGSN/MME has to be version addressing. In this case, DAF on visited SGSN/MME has to be
unset. One approach is to set a dedicated Access Point Name (APN) 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 [TS23.003] profile to only request PDP/PDN type IPv4 in the roaming
network. Some operators may also consider not adopting the local network. Some operators may also consider not adopting the local
breakout mode to avoid the risks. breakout mode to avoid the risks.
skipping to change at page 10, line 46 skipping to change at page 10, line 46
the network attachment. In order to support the IPv6-only visitors, the network attachment. In order to support the IPv6-only visitors,
SGSN/MME in the visited network is required to accept IPv6-only PDP/ SGSN/MME in the visited network is required to accept IPv6-only PDP/
PDN activation requests and enable IPv6 on user plane towards the PDN activation requests and enable IPv6 on user plane towards the
home network. home network.
In some cases, IPv6-only visitors may still be subject to the SGSN In some cases, IPv6-only visitors may still be subject to the SGSN
capability in visited networks. This becomes especially risky if the capability in visited networks. This becomes especially risky if the
home operator performs roaming steering targeted to an operator that home operator performs roaming steering targeted to an operator that
doesn't allow IPv6. The visited SGSN may just directly reject the doesn't allow IPv6. The visited SGSN may just directly reject the
PDP context activation. Therefore, it's expected that visited PDP context activation. Therefore, it's expected that visited
network is IPv6 roaming friendly to enable the functions on SGSN/MME network is IPv6 roaming-friendly to enable the functions on SGSN/MME
by default. Otherwise, operators may consider steering the roaming by default. Otherwise, operators may consider steering the roaming
traffic to the IPv6-enable visited network that has IPv6 roaming traffic to the IPv6-enable visited network that has IPv6 roaming
agreement. agreement.
4.3. Case 3: Inappropriate Roaming APN Set 4.3. Case 3: Inappropriate Roaming APN Set
If IPv6 single stack with the home routed mode is deployed, the If IPv6 single stack with the home routed mode is deployed, the
requested PDP/PDN type should also be IPv6. Some implementations requested PDP/PDN type should also be IPv6. Some implementations
that support roaming APN profile may set IPv4 as the default PDP/PDN that support roaming APN profile may set IPv4 as the default PDP/PDN
type, since the visited network is incapable to support PDP/PDN type type, since the visited network is incapable of supporting PDP/PDN
IPv4v6 (Section 4.1) and IPv6 (Section 4.2). The PDP/PDN request types IPv4v6 (Section 4.1) and IPv6 (Section 4.2). The PDP/PDN
will fail because the APN in the home network only allows IPv6. request will fail because the APN in the home network only allows
Therefore, the roaming APN have to be compliant with the home network IPv6. Therefore, the roaming APN have to be compliant with the home
configuration when home routed mode is adopted. network configuration when home routed mode is adopted.
4.4. Case 4: Fallback Failure 4.4. Case 4: Fallback Failure
In the local breakout mode, PDP/PDN type IPv6 should have no issues In the local breakout mode, PDP/PDN type IPv6 should have no issues
to pass through network attachment process, since 3GPP specified the to pass through network attachment process, since 3GPP specified the
PDP/PDN type IPv6 as early as PDP/PDN type IPv4. When a visitor PDP/PDN type IPv6 as early as PDP/PDN type IPv4. When a visitor
requests PDP/PDN type IPv6, the network should only return the requests PDP/PDN type IPv6, the network should only return the
expected IPv6 prefix. The UE may fail to get an IPv6 prefix if the expected IPv6 prefix. The UE may fail to get an IPv6 prefix if the
visited network only allocates an IPv4 address. In this case, the visited network only allocates an IPv4 address. In this case, the
visited network will reject the request and send the cause code to visited network will reject the request and send the cause code to
the UE. the UE.
A proper fallback scheme for PDP/PDN type IPv6 is desirable, however A proper fallback scheme for PDP/PDN type IPv6 is desirable, however
there is no the standard way to specify the behavior. Roaming APN there is no standard way to specify this behavior. Roaming APN
profile could help to address the issue by setting PDP/PDN type IPv4. profile could help to address the issue by setting PDP/PDN type IPv4.
For instance, the Android system solves the issue by configuring the For instance, the Android system solves the issue by configuring the
roaming protocol to IPv4 for the Access Point Name (APN). It roaming protocol to IPv4 for the Access Point Name (APN). It
guarantees that UE will always initiate an PDP/PDN type IPv4 in the guarantees that UE will always initiate a PDP/PDN type IPv4 in the
roaming area. roaming area.
5. Failure Cases in the Service Requests 5. Failure Cases in the Service Requests
After the successful network attachment and IP address allocation, After the successful network attachment and IP address allocation,
applications could start to request service based on the activated applications could start to request service based on the activated
PDP/PDN context. The service request may depend on specific IP PDP/PDN context. The service request may depend on specific IP
family or network collaboration. If traffic is offloaded locally family or network collaboration. If traffic is offloaded locally
(Section 2.1.2 ), the visited network may not be able to accommodate (Section 2.1.2 ), the visited network may not be able to accommodate
UE's service requests. This section describes the failures. UE's service requests. This section describes the failures.
5.1. Lack of IPv6 Support in Applications 5.1. Lack of IPv6 Support in Applications
Operators may only allow IPv6 in the IMS APN. VoLTE [IR.92] or Rich Operators may only allow IPv6 in the IMS APN. VoLTE [IR.92] or Rich
Communication Suite (RCS) [RCC.07] use the APN to offer the voice Communication Suite (RCS) [RCC.07] use the APN to offer the voice
service for visitors. The IMS roaming in RAVEL architecture [IR.65] service for visitors. The IMS roaming in RAVEL architecture [IR.65]
offloads voice and video traffic in the visited network, therefore a offloads voice and video traffic in the visited network, therefore a
dual-stack visitor can only be assigned with an IPv6 prefix but no 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 IPv4 address. If the applications can't support IPv6, the service is
likely failed . likely to fail.
Translation-based methods, for example 464xlat [RFC6877] or Bump-in- Translation-based methods, for example 464xlat [RFC6877] or Bump-in-
the-host (BIH) [RFC6535], may help to address the issue if there are the-host (BIH) [RFC6535], may help to address the issue if there are
IPv6 compatibility problems. The translation function could be IPv6 compatibility problems. The translation function could be
enabled in an IPv6-only network and disabled in a dual-stack or IPv4 enabled in an IPv6-only network and disabled in a dual-stack or IPv4
network, therefore the IPv4 applications only get the translation in network, therefore the IPv4 applications only get the translation in
the IPv6 network and perform normally in an IPv4 or dual-stack the IPv6 network and perform normally in an IPv4 or dual-stack
network. network.
5.2. 464xlat Support 5.2. 464xlat Support
464xlat[RFC6877] is proposed to address the IPv4 compatibility issue 464xlat[RFC6877] is proposed to address the IPv4 compatibility issue
in an IPv6-only connectivity environment. The customer-side in an IPv6-only connectivity environment. The customer-side
translator (CLAT) function on a mobile device is likely in translator (CLAT) function on a mobile device is likely used in
conjunction with a PDP/PDN IPv6 type request and cooperates with a conjunction with a PDP/PDN IPv6 type request and cooperates with a
remote NAT64 [RFC6146] device. remote NAT64 [RFC6146] device.
464xlat may use the mechanism defined in [RFC7050] or [RFC7225] to 464xlat may use the mechanism defined in [RFC7050] or [RFC7225] to
detect the presence of NAT64 devices and to learn the IPv6 prefix detect the presence of NAT64 devices and to learn the IPv6 prefix
used for protocol translation[RFC6052]. used for protocol translation[RFC6052].
In the local breakout approach, when a UE with the 464xlat function In local breakout approach, when a UE with the 464xlat function
roaming to an IPv6 visited network may encounter various situations. roaming to an IPv6 visited network may encounter various situations.
For example, the visited network may not deploy DNS64 [RFC6147] but For example, the visited network may not deploy DNS64 [RFC6147] but
only NAT64, CLAT may not be able to discover the provider-side only NAT64, CLAT may not be able to discover the provider-side
translator (PLAT) translation IPv6 prefix used as a destination of translator (PLAT) translation IPv6 prefix used as a destination of
the PLAT. If the visited network doesn't deploy NAT64 and DNS64, the PLAT. If the visited network doesn't deploy NAT64 and DNS64,
464xlat can't perform successfully due to the lack of PLAT 464xlat can't perform successfully due to the lack of PLAT
collaboration. Even in the case of the presence of NAT64 and DNS64, collaboration. Even in the case of the presence of NAT64 and DNS64,
pre-configured PLAT-side IPv6 prefix in the CLAT may cause the pre-configured PLAT-side IPv6 prefix in the CLAT may cause the
failure because it can't match the PLAT translation. failure because it can't match the PLAT translation.
skipping to change at page 13, line 29 skipping to change at page 13, line 29
user profile #2: user profile #2:
PDP-Context ::= SEQUENCE { PDP-Context ::= SEQUENCE {
pdp-ContextId ContextId, pdp-ContextId ContextId,
pdp-Type PDP-Type-IPv6 pdp-Type PDP-Type-IPv6
.... ....
} }
Scenario 1: Support of IPv6-only, IPv4-only and dual-stack devices. Scenario 1: Support of IPv6-only, IPv4-only and dual-stack devices.
The full PDP-context parameters is referred to Section 17.7.1 "Mobile The full PDP-context parameters are referred to Section 17.7.1
Service date types" of [TS29.002]. User profiles #1 and #2 share the "Mobile Service date types" of [TS29.002]. User profiles #1 and #2
same "ContextId". The setting of user profile #1 enables IPv4-only share the same "ContextId". The setting of user profile #1 enables
and dual-stack devices to work. And, the user profile #2 fulfills IPv4-only and dual-stack devices to work. And, the user profile #2
the request if the device asks for IPv6 only PDP context. fulfills the request if the device asks for IPv6 only PDP context.
user profile #1: user profile #1:
PDP-Context ::= SEQUENCE { PDP-Context ::= SEQUENCE {
pdp-ContextId ContextId, pdp-ContextId ContextId,
pdp-Type PDP-Type-IPv4 pdp-Type PDP-Type-IPv4
.... ....
ext-pdp-Type PDP-Type-IPv4v6 ext-pdp-Type PDP-Type-IPv4v6
... ...
} }
skipping to change at page 14, line 32 skipping to change at page 14, line 32
Scenario 2: Support of dual-stack devices with pre-R9 vSGSN access. Scenario 2: Support of dual-stack devices with pre-R9 vSGSN access.
User profiles #1 and #2 share the same "ContextId". If a visited User profiles #1 and #2 share the same "ContextId". If a visited
SGSN is identified as early as pre-Release 9, the HLR/HSS should only SGSN is identified as early as pre-Release 9, the HLR/HSS should only
send user profile#2 to the visited SGSN. send user profile#2 to the visited SGSN.
7. Discussion 7. Discussion
Several failure cases have been discussed in this document. It has Several failure cases have been discussed in this document. It has
been testified that the major issues happened at three stages, i.e., been illustrated that the major problems happen at three stages,
the initial network attachment, the PDP/PDN creation and service i.e., the initial network attachment, the PDP/PDN creation and
requests. service requests.
In the stage of the network attachment, PDP/PDN type IPv4v6 is the In the network attachment stage, PDP/PDN type IPv4v6 is the major
major concern to the visited pre-Release 9 SGSN. 3GPP didn't specify concern to the visited pre-Release 9 SGSN. 3GPP didn't specify PDP/
PDP/PDN type IPv4v6 in the early release. Such PDP/PDN type is PDN type IPv4v6 in the earlier releases. That PDP/PDN type is
supported in new-built EPS network, but didn't support well in the supported in new-built EPS network, but isn't supported well in the
third generation network. The situations may cause the roaming third generation network. The situations may cause the roaming
issues dropping with the attach request from dual-stack subscribers. issues of declining the attach request of dual-stack subscribers.
Operators may have to adopt temporary solutions 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 SGSN) in the visited network have been
upgraded to support the ext-PDP-Type feature. upgraded to support the ext-PDP-Type feature.
In the stage of the PDP/PDN creation, PDP/PDN type IPv4v6 and IPv6 In the PDP/PDN creation stage, PDP/PDN types IPv4v6 and IPv6 support
support on the visited SGSN is the major concern. It has been on the visited SGSN is the major concern. It has been observed that
observed that IPv6 single stack with the home routed mode is a viable IPv6 single stack with the home routed mode is a viable approach to
approach to deploy IPv6. It is desirable the visited SGSN could deploy IPv6. It is desirable that the visited SGSN could enable IPv6
enable IPv6 on the user plane by default. For the PDP/PDN type on the user plane by default. For support of the PDP/PDN type
IPv4v6 supporting, the DAF is suggested to be set. As a IPv4v6, it is suggested to set the DAF. As a complementary function,
complementary function, the implementation of roaming APN the implementation of roaming APN configuration is useful to
configuration is useful to accommodate the visited network. However, accommodate the visited network. However, it should consider roaming
it should consider roaming architecture and permitted PDP/PDN type to architecture and permitted PDP/PDN type to make proper setting on the
make proper setting on the UE. Roaming APN in the home routed mode UE. Roaming APN in the home routed mode is recommended to align with
is recommended to align with home network profile setting. In the home network profile setting. In the local breakout case, PDP/PDN
local breakout case, PDP/PDN type IPv4 could be selected as a safe type IPv4 could be selected as a safe way to initiate PDP/PDN
way to initiate PDP/PDN activation. activation.
In the stage of service requests, the failure cases are mostly In the service requests stage, the failure cases mostly occur in the
occurred in the local breakout case. The visited network may not be local breakout case. The visited network may not be able to satisfy
able to satisfy the requested capability from applications or UEs. the requested capability from applications or UEs. Operators may
Operators may consider to use home routed to avoid the risks. consider using home routed mode to avoid these problems. Several
Several solutions either in the network side or mobile device side solutions either in the network side or mobile device side can also
can also help to address the issue. For example, help to address the issue. For example,
o 464xlat could help IPv4 applications access IPv6 visited networks. o 464xlat could help IPv4 applications access IPv6 visited networks.
o Networks can deploy an AAA server to coordinate the mobile device o Networks can deploy an AAA server to coordinate the mobile device
capability. Once the GGSN/PGW receives the session creation capability. Once the GGSN/PGW receives the session creation
request, it will initiate an Access-Request to an AAA server in request, it will initiate an Access-Request to AAA server in the
the home network via the Radius protocol. The Access-Request home network via the RADIUS protocol. The Access-Request contains
contains subscriber and visited network information, e.g. PDP/PDN subscriber and visited network information, e.g., PDP/PDN Type,
Type, International Mobile Equipment Id (IMEI), Software Version International Mobile Equipment Id (IMEI), Software Version (SV)
(SV) and visited SGSN/MME location code, etc. The AAA server and visited SGSN/MME location code, etc. The AAA server could
could take mobile device capability and combine it with the take mobile device capability and combine it with the visited
visited network information to ultimately determine the type of network information to ultimately determine the type of session to
session to be created, i.e., IPv4, IPv6 or IPv4v6. 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, the reader is encouraged to refer to [RFC6459] for a
discussion on IPv6-related security considerations. generic 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, Heatley Nick, Alexandru Petrescu, Tore Anderson, Cameron Byrne,
Holger Metschulat and Geir Egeland for their helpful discussions and Holger Metschulat and Geir Egeland for their helpful discussions and
comments. comments.
The authors especially thank Fred Baker and Ross Chandler for their The authors especially thank Fred Baker and Ross Chandler for their
efforts and contributions which substantially improved the efforts and contributions which substantially improved the
readability of the document. readability of the document.
11. Informative References 11. References
[EU-Roaming-III] 11.1. Normative References
"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.65] Global System for Mobile Communications Association,
GSMA., "IMS Roaming & Interworking Guidelines", May 2012.
[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.
[RFC6877] Mawatari, M., Kawashima, M., and C. Byrne, "464XLAT:
Combination of Stateful and Stateless Translation", RFC
6877, April 2013.
[TS23.060]
3rd Generation Partnership Project, 3GPP., "General Packet
Radio Service (GPRS); Service description; Stage 2 v9.00",
March 2009.
[TS23.401]
3rd Generation Partnership Project, 3GPP., "General Packet
Radio Service (GPRS) enhancements for Evolved Universal
Terrestrial Radio Access Network (E-UTRAN) access v9.00",
March 2009.
[TS29.002]
3rd Generation Partnership Project, 3GPP., "Mobile
Application Part (MAP) specification v9.12.0", December
2009.
[TS29.272]
3rd Generation Partnership Project, 3GPP., "Mobility
Management Entity (MME) and Serving GPRS Support Node
(SGSN) related interfaces based on Diameter protocol
v9.00", September 2009.
11.2. Informative References
[EU-Roaming-III]
"http://www.amdocs.com/Products/Revenue-
Management/Documents/
amdocs-eu-roaming-regulation-III-solution.pdf", July 2013.
[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, [IR.34] Global System for Mobile Communications Association,
GSMA., "Guidelines for IPX Provider networks", November GSMA., "Guidelines for IPX Provider networks", November
2013. 2013.
[IR.65] Global System for Mobile Communications Association,
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. [RFC6052] Bao, C., Huitema, C., Bagnulo, M., Boucadair, M., and X.
Li, "IPv6 Addressing of IPv4/IPv6 Translators", RFC 6052, Li, "IPv6 Addressing of IPv4/IPv6 Translators", RFC 6052,
October 2010. October 2010.
[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 [RFC6535] Huang, B., Deng, H., and T. Savolainen, "Dual-Stack Hosts
Using "Bump-in-the-Host" (BIH)", RFC 6535, February 2012. Using "Bump-in-the-Host" (BIH)", RFC 6535, February 2012.
[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 [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.
[RFC7225] Boucadair, M., "Discovering NAT64 IPv6 Prefixes Using the [RFC7225] Boucadair, M., "Discovering NAT64 IPv6 Prefixes Using the
Port Control Protocol (PCP)", RFC 7225, May 2014. Port Control Protocol (PCP)", RFC 7225, May 2014.
[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] [TS23.003]
3rd Generation Partnership Project, 3GPP., "Numbering, 3rd Generation Partnership Project, 3GPP., "Numbering,
addressing and identification v9.0.0", September 2009. addressing and identification v9.0.0", September 2009.
[TS23.060]
3rd Generation Partnership Project, 3GPP., "General Packet
Radio Service (GPRS); Service description; Stage 2 v9.00",
March 2009.
[TS23.401]
3rd Generation Partnership Project, 3GPP., "General Packet
Radio Service (GPRS) enhancements for Evolved Universal
Terrestrial Radio Access Network (E-UTRAN) access v9.00",
March 2009.
[TS24.008] [TS24.008]
3rd Generation Partnership Project, 3GPP., "Mobile radio 3rd Generation Partnership Project, 3GPP., "Mobile radio
interface Layer 3 specification; Core network protocols; interface Layer 3 specification; Core network protocols;
Stage 3 v9.00", September 2009. Stage 3 v9.00", September 2009.
[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]
3rd Generation Partnership Project, 3GPP., "Mobile
Application Part (MAP) specification v9.12.0", December
2009.
[TS29.212] [TS29.212]
3rd Generation Partnership Project, 3GPP., "Policy and 3rd Generation Partnership Project, 3GPP., "Policy and
Charging Control (PCC); Reference points v9.0.0", Charging Control (PCC); Reference points v9.0.0",
September 2009. September 2009.
[TS29.272]
3rd Generation Partnership Project, 3GPP., "Mobility
Management Entity (MME) and Serving GPRS Support Node
(SGSN) related interfaces based on Diameter protocol
v9.00", September 2009.
Authors' Addresses Authors' Addresses
Gang Chen Gang Chen
China Mobile China Mobile
53A,Xibianmennei Ave., 53A,Xibianmennei Ave.,
Xuanwu District, Xuanwu District,
Beijing 100053 Beijing 100053
China China
Email: phdgang@gmail.com Email: phdgang@gmail.com
 End of changes. 41 change blocks. 
116 lines changed or deleted 123 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/