draft-ietf-v6ops-ipv6-roaming-analysis-02.txt   draft-ietf-v6ops-ipv6-roaming-analysis-03.txt 
Network Working Group G. Chen Network Working Group G. Chen
Internet-Draft H. Deng Internet-Draft H. Deng
Intended status: Informational China Mobile Intended status: Informational China Mobile
Expires: February 4, 2015 D. Michaud Expires: February 10, 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
August 3, 2014 August 9, 2014
IPv6 Roaming Behavior Analysis IPv6 Roaming Behavior Analysis
draft-ietf-v6ops-ipv6-roaming-analysis-02 draft-ietf-v6ops-ipv6-roaming-analysis-03
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 an IPv6-enabled mobile customers in roaming scenarios. encountered by IPv6-enabled mobile customers in roaming scenarios.
The investigations on those failed cases reveal the causes in order The investigations on those failed cases reveal the causes in order
to notice improper configurations, equipment's incomplete functions to notice improper configurations, equipment's incomplete functions
or inconsistent IPv6 introduction strategy. or inconsistent IPv6 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 February 4, 2015. This Internet-Draft will expire on February 10, 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
2.1. Home Routed Mode . . . . . . . . . . . . . . . . . . . . 3
2.2. Local Breakout Mode . . . . . . . . . . . . . . . . . . . 4
3. Roaming Scenario . . . . . . . . . . . . . . . . . . . . . . 5 3. Roaming Scenario . . . . . . . . . . . . . . . . . . . . . . 5
4. Failure Case in Attachment Stage . . . . . . . . . . . . . . 6 4. Failure Case in Attachment Stage . . . . . . . . . . . . . . 6
5. Failure Cases in PDP/PDN Creation . . . . . . . . . . . . . . 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 . . . . . . . . . . . . . . 9
5.4. Case 4: 464xlat Support . . . . . . . . . . . . . . . . . 9 5.4. Case 4: 464xlat Support . . . . . . . . . . . . . . . . . 9
6. HLR/HSS User Profile Setting . . . . . . . . . . . . . . . . 9 6. HLR/HSS User Profile Setting . . . . . . . . . . . . . . . . 9
7. Discussions . . . . . . . . . . . . . . . . . . . . . . . . . 11 7. Discussion . . . . . . . . . . . . . . . . . . . . . . . . . 11
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12
9. Security Considerations . . . . . . . . . . . . . . . . . . . 12 9. Security Considerations . . . . . . . . . . . . . . . . . . . 12
10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 12 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 13
11. References . . . . . . . . . . . . . . . . . . . . . . . . . 12 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 13
11.1. Normative References . . . . . . . . . . . . . . . . . . 12 11.1. Normative References . . . . . . . . . . . . . . . . . . 13
11.2. Informative References . . . . . . . . . . . . . . . . . 13 11.2. Informative References . . . . . . . . . . . . . . . . . 13
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 15 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 15
1. Introduction 1. Introduction
Many Mobile Operators have deployed IPv6, or are about to, in their Many Mobile Operators have deployed IPv6, or are about to, in their
operational networks. A customer in such a network can be provided operational networks. A customer in such a network can be provided
IPv6 connectivity if their User Equipment (UE) is IPv6-compliant. A IPv6 connectivity if their User Equipment (UE) is IPv6-compliant. A
detailed overview of IPv6 support in 3GPP architectures is provided detailed overview of IPv6 support in 3GPP architectures is provided
in [RFC6459]. Operators may adopt various approaches to deploy IPv6 in [RFC6459]. Operators may adopt various approaches to deploy IPv6
in mobile networks, for example the solutions described in in mobile networks, for example the solutions described in
[TR23.975]). Depending on network conditions either dual-stack or [TR23.975]). Depending on network conditions either dual-stack or
single-stack IPv6 is selected. single-stack IPv6 is selected.
In production networks, it has been observed that a mobile subscriber In production networks, it has been observed that a mobile subscriber
roaming around a different operator's areas may experience service roaming around a different operator's areas may experience service
degradations or interruptions due to inconsistent configurations and degradation or interruptions due to inconsistent configurations and
incomplete functionality of equipment in the network. incomplete functionality of equipment in the network.
A mobile subscriber roaming to different operator's network may
experience service degradations or interruptions due to inconsistent
configurations and incomplete functions in the visited network.
2. Roaming Architecture Description 2. Roaming Architecture Description
Roaming occurs in several scenarios: Roaming occurs in two scenarios:
o International roaming: a mobile UE may enter a visited network, o International roaming: a mobile UE may enter a visited network,
where a different Public Land Mobile Network (PLMN) identity is where a different Public Land Mobile Network (PLMN) identity is
used. The UEs could, either in an automatic mode or a manual used. The UEs could, either in an automatic mode or a manual
mode, attach to the visited PLMN. mode, attach to the visited PLMN.
o Intra-PLMN mobility: a mobile UE moves to a different area of the o Intra-PLMN mobility: a mobile UE moves to a different area of the
Home Public Land Mobile Network (HPLMN). However, the subscriber Home Public Land Mobile Network (HPLMN). However, the subscriber
profile may not be stored in the area. To allow network profile may not be stored in the area. To allow network
attachment the subscribers profile needs to be downloaded from the attachment the subscribers profile needs to be downloaded from the
skipping to change at page 3, line 34 skipping to change at page 3, line 30
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 to. The available Public Land Mobile Networks (PLMNs) to attach to. The
Serving GPRS Support Node (SGSN) or the Mobility Management Entity Serving GPRS Support Node (SGSN) or the Mobility Management Entity
(MME) in the visited networks must contact the Home Location (MME) in the visited networks must contact the Home Location
Register(HLR) or Home Subscriber Server(HSS) and obtain the Register(HLR) or Home Subscriber Server(HSS) and obtain the
subscriber profile. After the authentication and registration subscriber profile. After the authentication and registration
process is completed, the Packet Data Protocol (PDP) or Packet Data process is completed, the Packet Data Protocol (PDP) or Packet Data
Networks (PDN) activation and traffic flows may be operated Networks (PDN) activation and traffic flows may be operated
differently according to the subscriber profile stored in HLR or HSS. differently according to the subscriber profile stored in HLR or HSS.
Two modes are shown in the figure to illustrate, these are "Home
routed traffic" (Figure 1) and "Local breakout" (Figure 2).
+---------------------------------+ +------------------------+ There are two roaming modes illustrated below, i.e. "Home routed
|Visited Network | |Home Network | traffic" (Figure 1) and "Local breakout" (Figure 2).
| +----+ +--------+ | | +--------+ Traffic Flow
| | UE |==========>|SGSN/MME|======================>|GGSN/PGW|============>
| +----+ +--------+ | Signaling | +--------+ |
| |-------------------------->+--------+ |
| | | |HLR/HSS | |
| | | +--------+ |
+---------------------------------+ +------------------------+
Figure 1: Home Routed Traffic
+---------------------------------+ +------------------------+
|Visited Network | |Home Network |
| +----+ +--------+ | Signaling | +--------+ |
| | UE |==========>|SGSN/MME|---------------------->|HLR/HSS | |
| +----+ +--------+ | | +--------+ |
| || | | |
| +--------+ | | |
| |GGSN/PGW| | | |
| +--------+ | | |
| Traffic Flow || | | |
+-----------------------||--------+ +------------------------+
\/
Figure 2: Local Breakout 2.1. Home Routed Mode
In the home routed mode, the subscriber's UE activates the PDP/PDN In the home routed mode, the subscriber's UE activates the PDP/PDN
context and get an address from the home network. All traffic is context and get an address from the home network. All traffic is
routed back to the home network. This is likely to be the case routed back to the home network. This is likely to be the case
international roaming of Internet data services to facilitate the international roaming of Internet data services to facilitate the
charging process between the two operators concerned. charging process between the two operators concerned.
+-----------------------------+ +------------------------+
|Visited Network | |Home Network |
| +----+ +--------+ | (GRX/IPX) | +--------+ Traffic Flow
| | UE |=======>|SGSN/MME|====================>|GGSN/PGW|============>
| +----+ +--------+ | Signaling | +--------+ |
| |------------------------>+--------+ |
| | | |HLR/HSS | |
| | | +--------+ |
+-----------------------------+ +------------------------+
Figure 1: Home Routed Traffic
2.2. Local Breakout Mode
In the local breakout mode, the subscriber address is assigned by the In the local breakout mode, the subscriber address is assigned by the
visited network. The traffic flow is directly offloaded locally at a visited network. The traffic flow is directly offloaded locally at a
network node close to that device's point of attachment in the network node close to that device's point of attachment in the
visited network. Therefore,a more efficient route to the data visited network. Therefore,a more efficient route to the data
service is achieved. The international roaming of IP Multimedia service is achieved. The international roaming of IP Multimedia
Subsystem (IMS) based services, e.g. Voice over LTE (VoLTE)[IR.92] , Subsystem (IMS) based services, e.g. Voice over LTE (VoLTE)[IR.92] ,
is claimed to select the local breakout mode in [IR.65]. Data is claimed to select the local breakout mode in [IR.65]. Data
service roaming across different areas within an operator network service roaming across different areas within an operator network
might use local breakout mode in order to get more efficient traffic might use local breakout mode in order to get more efficient traffic
routing. The local breakout mode could be also applied to an routing. The local breakout mode could be also applied to an
operator's alliance for international roaming of data service. EU operator's alliance for international roaming of data service. EU
Roaming Regulation III[EU-Roaming-III] involves local breakout mode Roaming Regulation III[EU-Roaming-III] involves local breakout mode
allowing European subscribers roaming in European 2G/3G networks can allowing European subscribers roaming in European 2G/3G networks can
choose to have their Internet data routed directly to the Internet choose to have their Internet data routed directly to the Internet
from their current VPLMN. The following enumerates the more specific from their current VPLMN.
configuration considerations.
+----------------------------+ +----------------+
|Visited Network | |Home Network |
| +----+ +--------+ | Signaling | +--------+ |
| | UE |=======>|SGSN/MME|------------------->|HLR/HSS | |
| +----+ +--------+ | (GRX/IPX) | +--------+ |
| || | | |
| +--------+ | | |
| |GGSN/PGW| | | |
| +--------+ | | |
| Traffic Flow || | | |
+--------------------||------+ +----------------+
\/
Figure 2: Local Breakout
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). Consequently, the traffic would be steered to Point Name (APN). Consequently, the traffic would be steered to
the visited network. Those functions are normally deployed for the visited network. Those functions are normally deployed for
the Intra-PLMN mobility cases. the Intra-PLMN mobility cases.
o Operators may also configure the VPLMN-Dynamic-Address-Allowed o Operators may also configure the VPLMN-Dynamic-Address-Allowed
flag[TS29.272] in the user profile to enable local breakout mode flag[TS29.272] in the user profile to enable local breakout mode
skipping to change at page 5, line 43 skipping to change at page 5, line 43
attachment stage in the case of 4G, but is a seperate process in attachment stage in the case of 4G, but is a seperate process in
2/3G. 3GPP specifies three types of Packet Data Protocol 2/3G. 3GPP specifies three types of Packet Data Protocol
(PDP)/Packet Data Networks (PDN) to describe connections, i.e. (PDP)/Packet Data Networks (PDN) to describe connections, i.e.
PDP/PDN Type IPv4, PDP/PDN Type IPv6 and PDP/ PDN Type IPv4v6. PDP/PDN Type IPv4, PDP/PDN Type IPv6 and PDP/ PDN Type IPv4v6.
When a subscriber creates a data session, their device requests a When a subscriber creates a data session, their device requests a
particular PDP/PDN Type. The allowed PDP/PDN types for that particular PDP/PDN Type. The allowed PDP/PDN types for that
subscriber are learned in the attachment stage. Hence, SGSN/MME subscriber are learned in the attachment stage. Hence, SGSN/MME
could initiate PDP/PDN request to GGSN/PGW if the subscription could initiate PDP/PDN request to GGSN/PGW if the subscription
profile is allowed. profile is allowed.
The failures are likely to occur in both stages due to an incompliant In both stages, the failure cases described are likely to occur due
implementation in the visited network or a mismatch between the to an incompliant implementation in the visited network or a mismatch
subscriber requested and the capability of the visited network. The between the subscriber requested and the capability of the visited
failures in the attachment stage are independent of home routed or network. The failures described in the attachment stage are
the local breakout mode, while most failure cases in the PDP/PDN independent of home routed or the local breakout mode. Most failure
context creation stage occur in the local breakout cases. Section 4 cases in the PDP/PDN context creation stage occur in the local
and 5 describe each case. The below table lists several cases breakout mode. Section 4 and 5 describe each case.
concerning the PDP/PDN creation stage.
+-------------+-------------------+--------------+
| UE request | PDN/PDP IP Type |Local breakout|
| | permitted | |
+-------------+-------------------+--------------+
| IPv4v6 | IPv4 or IPv6 |Failure case 1|
+-------------+-------------------+--------------+
| IPv4v6 | IPv6 |Failure case 2|
+-------------+-------------------+--------------+
| IPv6 | IPv4 |Failure case 3|
+-------------+-------------------+--------------+
| IPv6 | IPv6 |Failure case 4|
| with 464xlat| without NAT64 | |
+-------------+-------------------+--------------+
Table 1: Roaming Scenario Descriptions
4. Failure Case in Attachment Stage 4. Failure Case in Attachment Stage
3GPP specified PDP/PDN type IPv4v6 in order to allow a UE request 3GPP specified PDP/PDN type IPv4v6 in order to allow a UE get both
both IPv4 and IPv6 within a single PDP/PDN request. This option is IPv4 and IPv6 address within a single PDP/PDN bearer. This option is
stored as a part of subscription data for a subscriber in the HLR/ stored as a part of subscription data for a subscriber in the HLR/
HSS. PDP/PDN type IPv4v6 has been introduced at the inception of HSS. PDP/PDN type IPv4v6 has been introduced at the inception of
Evolved Packet System (EPS) in 4G networks. The nodes in 4G networks Evolved Packet System (EPS) in 4G networks. The nodes in 4G networks
should present no issues with the handling of this PDN type. should present no issues with the handling of this PDN type.
However, support varies in 2/3G networks depending on Serving GPRS However, support varies in 2/3G networks depending on Serving GPRS
Support Node (SGSN) software version. In theory, S4-SGSN (i.e. an Support Node (SGSN) software version. In theory, S4-SGSN (i.e. an
SGSN with S4 interface) supports the PDP/PDN type IPv4v6 since SGSN with S4 interface) supports the PDP/PDN type IPv4v6 since
Release8 and a Gn-SGSN (i.e. the SGSN with Gn interface) supports it Release8 and a Gn-SGSN (i.e. the SGSN with Gn interface) supports it
since Release 9. In most cases, operators normally use Gn-SGSN to 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. connect either GGSN in 3G or Packet Data Network Gateway (PGW) in 4G.
skipping to change at page 7, line 10 skipping to change at page 6, line 43
Operators may have to remove the PDP/PDN type IPv4v6 from the HLR/HSS Operators may have to remove the PDP/PDN type IPv4v6 from the HLR/HSS
in the home network, that will restrict UEs to only initiate IPv4 PDP in the home network, that will restrict UEs to only initiate IPv4 PDP
or IPv6 PDP activation. In order to avoid this situation, operators or 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 it aligns with the GSMA documents, e.g. [IR.33], [IR.88] ensure that it aligns with the GSMA documents, e.g. [IR.33], [IR.88]
and [IR.21]. Such an agreement requires the visited operator to get and [IR.21]. Such an agreement requires the visited operator to get
the necessary patch on all their SGSN nodes to support PDP/PDN type the necessary patch on all their SGSN nodes to support PDP/PDN type
IPv4v6. IPv4v6.
As an alternative solution there are some specific implementations As an alternative solution there are some specific implementations
(not standardised by 3GPP) in the HLS/HSS of the home network. When (not standardized by 3GPP) in the HLS/HSS of the home network. When
the HLR/HSS receives an Update Location message from a visited SGSN the HLR/HSS receives an Update Location message from a visited SGSN
known to not support the PDP type IPv4v6, subscription data with only known to not support the PDP type IPv4v6, subscription data with only
PDP/PDN type IPv4 will be sent to that SGSN in the Insert Subscriber PDP/PDN type IPv4 will be sent to that SGSN in the Insert Subscriber
Data procedure. It guarantees the user profile is compatible with Data procedure. It guarantees the user profile is compatible with
visited SGSN/MME capability. visited SGSN/MME capability.
5. Failure Cases in PDP/PDN Creation 5. Failure Cases in PDP/PDN Creation
When a subscriber succeeds in the attach stage, the IP allocation When a subscriber succeeds in the attach stage, the IP allocation
process takes place to allocate IP addresses to the subscriber. This process takes place to allocate IP addresses to the subscriber. In
section summarizes several failures in the break-out cases. general, a PDP/PDN type IPv4v6 request implicitly allows a network
side to make several IP assignment options, including IPv4-only,
IPv6-only, IPv4 and IPv6 in single PDP/PDN bearer, IPv4 and IPv6 in
separated PDP/PDN bearers. A PDP/PDN type IPv4 or IPv6 restricts the
network side only allocates requested IP family. This section
summarizes several failures in the Local Breakout mode.
+-------------+-------------------+--------------+
| UE request | PDN/PDP IP Type |Local breakout|
| | permitted | |
+-------------+-------------------+--------------+
| IPv4v6 | IPv4 or IPv6 |Failure case 1|
+-------------+-------------------+--------------+
| IPv4v6 | IPv6 |Failure case 2|
+-------------+-------------------+--------------+
| IPv6 | IPv4 |Failure case 3|
+-------------+-------------------+--------------+
| IPv6 | IPv6 |Failure case 4|
| with 464xlat| without NAT64 | |
+-------------+-------------------+--------------+
Table 1: Local Breakout Failure Cases
5.1. Case 1: Splitting Dual-stack Bearer 5.1. Case 1: Splitting Dual-stack Bearer
Dual-stack capability can be provided using separate PDP/PDN Dual-stack capability can be provided using separate PDP/PDN
activations. That means only separate parallel single-stack IPv4 and activation. That means only separate parallel single-stack IPv4 and
IPv6 PDP/PDN connections are allowed to be initiated to separately IPv6 PDP/PDN connections are allowed to be initiated to separately
allocate IPv4 and IPv6 addresses. allocate IPv4 and IPv6 addresses.
The cases are listed below: The cases are listed below:
o The SGSN/MME returns Session Management (SM) Cause #52, "Single o The SGSN/MME returns Session Management (SM) Cause #52, "Single
address bearers only allowed", or SM Cause #28 "Unknown PDP address bearers only allowed", or SM Cause #28 "Unknown PDP
address or PDP type" as per[TS24.008] and [TS24.301]. address or PDP type" as per[TS24.008] and [TS24.301].
o The SGSN/MME does not set the Dual Address Bearer Flag because the o The SGSN/MME does not set the Dual Address Bearer Flag (DAF)
operator uses single addressing per bearer to support interworking because the operator uses single addressing per bearer to support
with nodes of earlier releases interworking with nodes of earlier releases
A roaming subscriber's UE with IPv4v6 PDP/PDN type has to change the A roaming subscriber's UE with IPv4v6 PDP/PDN type has to change the
request into two separated PDP/PDN requests with a single IP version request into two separated PDP/PDN requests with a single IP version
in order to achieve equivalent results. Some drawbacks of this case in order to achieve equivalent results. Some drawbacks of this case
are listed as below: are listed as below:
o The parallel PDP/PDN activations would likely double PDP/PDN o The parallel PDP/PDN activation would likely double PDP/PDN
resources consumptions. It also impacts the capacity of GGSN/PGW, resources consumption. It also 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 activation is 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, an IPv6 PDP/PDN will be rejected if the subscriber. For example, an IPv6 PDP/PDN will be rejected if the
subscriber has an active IPv4 PDP/PDN. Therefore, the subscriber subscriber has an active IPv4 PDP/PDN. Therefore, the subscriber
will lose the IPv6 connection in the visited network. It is even will lose the IPv6 connection in the visited network. It is even
worse as they may have a risk of losing all data connectivity if worse as they may have a risk of losing all data connectivity if
the IPv6 PDP gets rejected with a permanent error at the APN-level the IPv6 PDP gets rejected with a permanent error at the APN-level
and not specific to the PDP-Type IPv6 requested. and not specific to the PDP-Type IPv6 requested.
o Additional correlations between those two PDP/PDN contexts are o Additional correlations between those two PDP/PDN contexts are
required on the charging system. required on the charging system.
o Policy and Charging Rules Function(PCRF)/Policy and Charging o Policy and Charging Rules Function(PCRF)/Policy and Charging
Enforcement Function (PCEF) treats the IPv4 and IPv6 session as Enforcement Function (PCEF) treats the IPv4 and IPv6 session as
independent and performs different Quality of Service (QoS) independent and performs 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 a limitation on allowed simultaneous PDP/ o Mobile devices may have a limitation on allowed simultaneous PDP/
PDN activations. Excessive PDP/PDN activation may result in other PDN activation. Excessive PDP/PDN activation may result in other
unrelated services broken. 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 PDP/PDN type IPv4 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 an IPv6-only configuration for the IMS Some operators may adopt an IPv6-only configuration for the IMS
skipping to change at page 8, line 47 skipping to change at page 9, line 10
(BIH)[RFC6535] or 464xlat [RFC6877] may help to address the issue if (BIH)[RFC6535] or 464xlat [RFC6877] may help to address the issue if
there are IPv6 compatibility problems. Those functions could be there are IPv6 compatibility problems. Those functions could be
automatically enabled in an IPv6-only network and disabled in a dual- automatically enabled in an IPv6-only network and disabled in a dual-
stack or IPv4 network. stack or IPv4 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 and making an IPv6 PDP/PDN request should guarantee that the networks and making an IPv6 PDP/PDN request could guarantee that the
subscription data is compatible with the visited pre-Release 9 SGSN. subscription data is compatible with the visited pre-Release 9 SGSN.
When a subscriber requests PDP/PDN type IPv6, the network should only When a subscriber requests PDP/PDN type IPv6, the network should only
return the expected IPv6 prefix. The mobile device may fail to get return the expected IPv6 prefix. The mobile device may fail to get
an IPv6 prefix if the visited network only allocates an IPv4 address an IPv6 prefix if the visited network only allocates an IPv4 address
to the subscriber. In that case, the request will be dropped and the to the subscriber. In that case, the request will be dropped and the
cause code should be sent to the user. cause code should be sent to the user.
A proper fallback is desirable, however the behavior is A proper fallback is desirable, however the behavior is
implementation specific. There are some mobile devices have the implementation specific. There are some mobile devices have the
ability to provide a different configuration for home network and ability to provide a different configuration for home network and
skipping to change at page 9, line 37 skipping to change at page 9, line 48
The issue has been found mostly in intra-PLMN mobility cases for the The issue has been found mostly in intra-PLMN mobility cases for the
time being. Considering the various network's situations, operators time being. Considering the various network's situations, operators
may turn off the local breakout and use the home routed mode to may turn off the local breakout and use the home routed mode to
perform 464xlat. Some devices may support the configuration to adopt perform 464xlat. Some devices may support the configuration to adopt
464xlat in the home networks and use IPv4-only in the visited 464xlat in the home networks and use IPv4-only in the visited
networks with different roaming profile configurations. This could networks with different roaming profile configurations. This could
also be a solution to address this issue. also be a solution to address this issue.
6. HLR/HSS User Profile Setting 6. HLR/HSS User Profile Setting
A proper user profile configuration could provide deterministic A proper user profile configuration would provide a deterministic
network control of the connectivity requests from dual-stack, outcome to the PDP/PDN Creation stage where dual-stack, IPv4-only and
IPv4-only and IPv6-only devices. It's desirable that the network IPv6-only connectivity requests may come from devices. The HLR/HSS
could set-up proper connectivity for any type of the devices.The HLR/ may have to apply extra logic to achieve this. It's also desirable
HSS may have to apply extra logic to achieve this. that the network could set-up connectivity of any requested PDP/PDN
context type.
The following are examples to demonstrate the settings for the The following are examples to demonstrate the settings for the
scenarios and decision criteria to apply when returning user profile scenarios and decision criteria to apply when returning user profile
information to visited SGSN. information to visited SGSN.
Scenario 1: Support IPv6-only, IPv4-only and dual-stack devices Scenario 1: Support IPv6-only, IPv4-only and dual-stack devices
user profile #1: user profile #1:
PDP-Context ::= SEQUENCE { PDP-Context ::= SEQUENCE {
skipping to change at page 10, line 25 skipping to change at page 10, line 31
} }
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
.... ....
} }
The full PDP-context parameters is refered to Section 17.7.1 "Mobile The full PDP-context parameters is referred to Section 17.7.1 "Mobile
Sevice date types" of [TS29.002]. User profile 1 and 2 share the Sevice date types" of [TS29.002]. User profile 1 and 2 share the
same contextId. The setting of user profile #1 enables IPv4-only and same contextId. The setting of user profile #1 enables IPv4-only and
dual-stack devices to work. And, the user profile #2 fulfills the dual-stack devices to work. And, the user profile #2 fulfills the
request if the device asks for IPv6 only PDP context. request if the device asks for IPv6 only PDP context.
Scenario 2: Support dual-stack devices with pre-R9 vSGSN access Scenario 2: Support dual-stack devices with pre-R9 vSGSN access
user profile #1: user profile #1:
PDP-Context ::= SEQUENCE { PDP-Context ::= SEQUENCE {
skipping to change at page 11, line 4 skipping to change at page 11, line 24
... ...
} }
user profile #2: user profile #2:
PDP-Context ::= SEQUENCE { PDP-Context ::= SEQUENCE {
pdp-ContextId ContextId, pdp-ContextId ContextId,
pdp-Type PDP-Type-IPv4 pdp-Type PDP-Type-IPv4
.... ....
} }
User profile 1 and 2 share the same contextId. If a visited SGSN is User profile 1 and 2 share the same contextId. If a visited SGSN is
identified as early as pre-Release 9, HLR/HSS should only send user identified as early as pre-Release 9, the HLR/HSS should only send
profile#2 to visited SGSN. user profile#2 to visited SGSN.
7. Discussions 7. Discussion
Several failure cases have been discussed in this document. It has Several failure cases have been discussed in this document. It has
been testified that the major issues happened at two stages, i.e., been testified that the major issues happened at two stages, i.e.,
the initial network attach and the IP allocation process. the initial network attachment and the IP allocation process.
During the initial network attach, PDP/PDN type IPv4v6 is the major During the initial network attach, PDP/PDN type IPv4v6 is the major
concern to the visited pre-Release 9 SGSN. The dual-stack deployment concern to the visited pre-Release 9 SGSN. 3GPP didn't specify PDP/
is recommended in most cases. However, it may take some times in a PDN type IPv4v6 in the early release. Such PDP/PDN type is supported
mobile environment. 3GPP didn't specify PDP/PDN type IPv4v6 in the in new-built EPS network, but didn't support well in the third
early release. Such PDP/PDN type is supported in new-built EPS generation network. The situations may cause the roaming issues
network, but didn't support well in the third generation network. dropping with the attach request from dual-stack subscribers.
The situations may cause the roaming issues dropping with the attach Operators may have to adopt temporary solution unless all the
request from dual-stack subscribers. Operators may have to adopt interworking nodes(i.e. the SSGN) in the visited network have been
temporary solution unless all the interworking nodes(i.e. the SSGN) upgraded to support the ext-PDP-Type feature.
in the visited network have been upgraded to support the ext-PDP-Type
feature.
The issues in the IP address allocation process are caused by a local PDP/PDN type IPv6 has good compatibility to visited networks during
breakout policy. Since the IP address is allocated by the visited the network attachment. It has been observed that IPv6 single stack
GGSN or PGW, the mismatch is found in the following aspects. with the home routed mode is a viable approach to deploy IPv6. In
order to support the IPv6-only visitors, SGSN/MME in the visited
network is required to accept IPv6-only PDP/PDN activation requests
and enable IPv6 on user plane towards the home network. In some
cases, IPv6-only visitors may still be subject to the SGSN capability
in visited networks. This becomes especially apparent if the home
operator performs roaming steering targeted to an operator that
doesn't allow IPv6. Therefore, it's expected that visited network is
IPv6 roaming friendly to enable the functions on SGSN/MME by default.
In the local breakout mode, the IP address is allocated by the
visited GGSN or PGW. The mismatch is found in the following aspects.
o The mismatch between the requested PDP/PDN type and the permitted o The mismatch between the requested PDP/PDN type and the permitted
PDP/PDN type PDP/PDN type
o The mismatch between the application capability and allowed o The mismatch between the application capability and allowed
network connections network connections
o The mismatch between mobile device function (e.g., 464xlat) and o The mismatch between mobile device function (e.g., 464xlat) and
the support for that function in the vistited network the support for that function in the visited network
There are some solutions to overcome the issue. Those solutions can There are some solutions to overcome the issue. Those solutions can
be made either in the network side or mobile device side. There be made either in the network side or mobile device side.
exist several 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 the roamer. o A dedicated roaming APN profile is implemented for the roamer.
When a subscriber roams to a visited network, PDP/PDN type IPv4 is When a subscriber roams to a visited network, PDP/PDN type IPv4 is
to be always selected for session activation. to be always selected for session activation.
o Networks could deploy an AAA server to coordinate the mobile o Networks could deploy an AAA server to coordinate the mobile
device capability. Once the GGSN/PGW receives the session device capability. Once the GGSN/PGW receives the session
creation request, it will initiate an Access-Request to an AAA creation request, it will initiate an Access-Request to an AAA
skipping to change at page 12, line 30 skipping to change at page 13, line 13
discussion on IPv6-related security considerations. discussion on IPv6-related security considerations.
10. Acknowledgements 10. Acknowledgements
Many thanks to F. Baker and J. Brzozowski for their support. Many thanks to F. Baker and J. Brzozowski for their support.
This document is the result of the IETF v6ops IPv6-Roaming design This document is the result of the IETF v6ops IPv6-Roaming design
team effort. team effort.
The authors would like to thank Mikael Abrahamsson, Victor Kuarsingh, The authors would like to thank Mikael Abrahamsson, Victor Kuarsingh,
Heatley Nick, Alexandru Petrescu, Tore Anderson and Cameron Byrne for Heatley Nick, Alexandru Petrescu, Tore Anderson, Cameron Byrne and
their helpful comments. Holger Metschulat for their helpful comments.
The authors especially thank Fred Baker and Ross Chandler for his The authors especially thank Fred Baker and Ross Chandler for his
efforts and contributions on editing which substantially improves the efforts and contributions on editing which substantially improves the
legibility of the document. legibility of the document.
11. References 11. References
11.1. Normative References 11.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC6052] Bao, C., Huitema, C., Bagnulo, M., Boucadair, M., and X.
Li, "IPv6 Addressing of IPv4/IPv6 Translators", RFC 6052,
October 2010.
[RFC6146] Bagnulo, M., Matthews, P., and I. van Beijnum, "Stateful [RFC6146] Bagnulo, M., Matthews, P., and I. van Beijnum, "Stateful
NAT64: Network Address and Protocol Translation from IPv6 NAT64: Network Address and Protocol Translation from IPv6
Clients to IPv4 Servers", RFC 6146, April 2011. Clients to IPv4 Servers", RFC 6146, April 2011.
[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.
[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: [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.
skipping to change at page 14, line 10 skipping to change at page 14, line 25
[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.
[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
Network", RFC 6586, April 2012.
[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.060] [TS23.060]
3rd Generation Partnership Project, 3GPP., "General Packet 3rd Generation Partnership Project, 3GPP., "General Packet
Radio Service (GPRS); Service description; Stage 2 v9.00", Radio Service (GPRS); Service description; Stage 2 v9.00",
March 2009. March 2009.
[TS23.401] [TS23.401]
 End of changes. 40 change blocks. 
126 lines changed or deleted 130 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/