draft-ietf-v6ops-ipv6-roaming-analysis-01.txt   draft-ietf-v6ops-ipv6-roaming-analysis-02.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: January 5, 2015 D. Michaud Expires: February 4, 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
July 4, 2014 August 3, 2014
IPv6 Roaming Behavior Analysis IPv6 Roaming Behavior Analysis
draft-ietf-v6ops-ipv6-roaming-analysis-01 draft-ietf-v6ops-ipv6-roaming-analysis-02
Abstract Abstract
This document identifies a set of failure cases encountered by an This document identifies a set of failure cases that may be
IPv6-enabled IPv6 customers in roaming scenarios. The investigations encountered by an IPv6-enabled mobile customers in roaming scenarios.
on those failed cases reveal the causes in order to notice improper The investigations on those failed cases reveal the causes in order
configurations, equipment's incomplete functions or inconsistent IPv6 to notice improper configurations, equipment's incomplete functions
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 January 5, 2015. This Internet-Draft will expire on February 4, 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 26 skipping to change at page 2, line 26
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Roaming Architecture Description . . . . . . . . . . . . . . 3 2. Roaming Architecture Description . . . . . . . . . . . . . . 3
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 . . . . . . . . . . . . . . 8
5.4. Case 4: 464xlat Support . . . . . . . . . . . . . . . . . 9 5.4. Case 4: 464xlat Support . . . . . . . . . . . . . . . . . 9
6. Discussions . . . . . . . . . . . . . . . . . . . . . . . . . 9 6. HLR/HSS User Profile Setting . . . . . . . . . . . . . . . . 9
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 7. Discussions . . . . . . . . . . . . . . . . . . . . . . . . . 11
8. Security Considerations . . . . . . . . . . . . . . . . . . . 10 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12
9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 10 9. Security Considerations . . . . . . . . . . . . . . . . . . . 12
10. References . . . . . . . . . . . . . . . . . . . . . . . . . 11 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 12
10.1. Normative References . . . . . . . . . . . . . . . . . . 11 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 12
10.2. Informative References . . . . . . . . . . . . . . . . . 11 11.1. Normative References . . . . . . . . . . . . . . . . . . 12
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 13 11.2. Informative References . . . . . . . . . . . . . . . . . 13
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 15
1. Introduction 1. Introduction
Many Mobile Operators deployed or are in a per-deployment stage of Many Mobile Operators have deployed IPv6, or are about to, in their
IPv6 in their operational networks. Customers will be delivered with operational networks. A customer in such a network can be provided
IPv6 connectivity if their User Equipment (UE) are 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]). Dual-stack or IPv6 single-stack has been selected [TR23.975]). Depending on network conditions either dual-stack or
depending on network's conditions. It has been observed that a single-stack IPv6 is selected.
mobile subscriber roaming around different operator's areas may
experience service degradations or interruptions due to the
inconsistent configurations and incomplete functions on the networks
nodes.
This memo intends to document the observed failed cases and analyze In production networks, it has been observed that a mobile subscriber
the causes. roaming around a different operator's areas may experience service
degradations or interruptions due to inconsistent configurations and
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
The roaming process has been occurred in the following scenarios: Roaming occurs in several scenarios:
o International roaming: a mobile UE may entry a visited network, o International roaming: a mobile UE may enter a visited network,
where different Public Land Mobile Network (PLMN) identity is where a different Public Land Mobile Network (PLMN) identity is
used. UEs could, either in an automatic mode or a manual mode, used. The UEs could, either in an automatic mode or a manual
attach to the visited PLMN. mode, attach to the visited PLMN.
o Intra-PLMN mobility: a UE moves to a visited network as that of o Intra-PLMN mobility: a mobile UE moves to a different area of the
the Home Public Land Mobile Network (HPLMN). However, the Home Public Land Mobile Network (HPLMN). However, the subscriber
subscriber profiles may not be stored in the area. Once the profile may not be stored in the area. To allow network
subscriber attached to the network, the subscriber profile should attachment the subscribers profile needs to be downloaded from the
be extracted from the home network for the network attachment. home network area.
When a UE is turned on or is transferred via a handover to a visited When a UE is turned on or is transferred via a handover to a visited
network, the mobile device will scan all radio channels and find network, the mobile device will scan all radio channels and find
available Public Land Mobile Networks (PLMNs) to attach. Serving available Public Land Mobile Networks (PLMNs) to attach to. The
GPRS Support Node (SGSN) or Mobility Management Entity (MME) in the Serving GPRS Support Node (SGSN) or the Mobility Management Entity
visited networks must contact the Home Location Register(HLR) or Home (MME) in the visited networks must contact the Home Location
Subscriber Server(HSS) and obtain the subscriber profile. Once the Register(HLR) or Home Subscriber Server(HSS) and obtain the
authentication and registration process is completed, the Packet Data subscriber profile. After the authentication and registration
Protocol (PDP) or Packet Data Networks (PDN) activation and traffic process is completed, the Packet Data Protocol (PDP) or Packet Data
flows may be operated differently according to the subscriber profile Networks (PDN) activation and traffic flows may be operated
stored in HLR or HSS. Two modes have been shown at the figure to differently according to the subscriber profile stored in HLR or HSS.
illustrate, that are "Home routed traffic" (Figure 1) and "Local Two modes are shown in the figure to illustrate, these are "Home
breakout" (Figure 2). routed traffic" (Figure 1) and "Local breakout" (Figure 2).
+---------------------------------+ +------------------------+ +---------------------------------+ +------------------------+
|Visited Network | |Home Network | |Visited Network | |Home Network |
| +----+ +--------+ | | +--------+ Traffic Flow | +----+ +--------+ | | +--------+ Traffic Flow
| | UE |==========>|SGSN/MME|======================>|GGSN/PGW|============> | | UE |==========>|SGSN/MME|======================>|GGSN/PGW|============>
| +----+ +--------+ | Signaling | +--------+ | | +----+ +--------+ | Signaling | +--------+ |
| |-------------------------->+--------+ | | |-------------------------->+--------+ |
| | | |HLR/HSS | | | | | |HLR/HSS | |
| | | +--------+ | | | | +--------+ |
+---------------------------------+ +------------------------+ +---------------------------------+ +------------------------+
skipping to change at page 4, line 18 skipping to change at page 4, line 18
| | UE |==========>|SGSN/MME|---------------------->|HLR/HSS | | | | UE |==========>|SGSN/MME|---------------------->|HLR/HSS | |
| +----+ +--------+ | | +--------+ | | +----+ +--------+ | | +--------+ |
| || | | | | || | | |
| +--------+ | | | | +--------+ | | |
| |GGSN/PGW| | | | | |GGSN/PGW| | | |
| +--------+ | | | | +--------+ | | |
| Traffic Flow || | | | | Traffic Flow || | | |
+-----------------------||--------+ +------------------------+ +-----------------------||--------+ +------------------------+
\/ \/
Figure 2: Local Breadkout Figure 2: Local Breakout
In the home routed mode, subscribers will activate the PDP/PDN In the home routed mode, the subscriber's UE activates the PDP/PDN
context and get address from the home network. All traffic would be context and get an address from the home network. All traffic is
routed back to the home networks. It's likely most cases for 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 two operators. charging process between the two operators concerned.
In the local breakout mode, the subscriber address will be assigned In the local breakout mode, the subscriber address is assigned by the
from the visited network. The traffic flow is directly offloaded visited network. The traffic flow is directly offloaded locally at a
locally at a network node close to that device's point of attachment network node close to that device's point of attachment in the
in the visited networks. Therefore, more efficient route is visited network. Therefore,a more efficient route to the data
achieved. The international roaming of IP Multimedia Subsystem (IMS) service is achieved. The international roaming of IP Multimedia
based services, e.g. Voice over LTE (VoLTE)[IR.92] , is claimed to Subsystem (IMS) based services, e.g. Voice over LTE (VoLTE)[IR.92] ,
select the local breakout mode in [IR.65]. Data service roaming is claimed to select the local breakout mode in [IR.65]. Data
across different areas within a operator network could use local service roaming across different areas within an operator network
breakout mode in order to get efficient traffic route. The local might use local breakout mode in order to get more efficient traffic
breakout mode could be also applied to an operators alliance for routing. The local breakout mode could be also applied to an
international roaming of data service. EU Roaming Regulation operator's alliance for international roaming of data service. EU
III[EU-Roaming-III] involves local breakout mode allowing european Roaming Regulation III[EU-Roaming-III] involves local breakout mode
subscribers roaming in european 2G/3G networks can choose to have allowing European subscribers roaming in European 2G/3G networks can
their Internet data routed directly to the Internet from their choose to have their Internet data routed directly to the Internet
current VPLMN. The following enumerates the more specific from their current VPLMN. The following enumerates the more specific
configuration considerations. configuration considerations.
o Operators may add the APN-OI-Replacement flag defined in 3GPP o Operators may add the APN-OI-Replacement flag defined in 3GPP
[TS29.272] into user's subscription-data. The visited network [TS29.272] into user's subscription-data. The visited network
indicates a local domain name to replace the user requested Access indicates a local domain name to replace the user requested Access
Point Name (APN). As the consequence, the traffic would be Point Name (APN). Consequently, the traffic would be steered to
steered to the visited network. Those functions are normally the visited network. Those functions are normally deployed for
deployed for the Intra-PLMN mobility cases. the Intra-PLMN mobility cases.
o Operators could also configure 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
in Visited Public Land Mobile Networks (VPLMNs). in a Visited Public Land Mobile Networks (VPLMNs).
o 3GPP specified Selected IP Traffic Offload (SIPTO) o 3GPP specified Selected IP Traffic Offload (SIPTO)
function[TS23.401] since Release 10 in order to get efficient function[TS23.401] since Release 10 in order to get efficient
route paths. It enables an operator to offload certain types of route paths. It enables an operator to offload certain types of
traffic at a network node close to that device's point of traffic at a network node close to that device's point of
attachment to the access network. attachment to the access network.
o GSMA has defined RAVEL[IR.65] as IMS international roaming o GSMA has defined RAVEL[IR.65] as the IMS international roaming
architecture. Local breakout mode has been adopted for the architecture. Local breakout mode has been adopted for the IMS
roaming architecture. roaming architecture.
3. Roaming Scenario 3. Roaming Scenario
There are two stages happened when a subscriber roams to a visited Two stages occur when a subscriber roams to a visited network and
network and intends to start data services. intends to start data services.
o Nework attachment: it's occurred once the subsriber enters a o Network attachment: this occurs when the subscriber enters a
visited network. During an attachment, the visited network should visited network. During an attachment, the visited network should
authenticate the subsriber and make location update to the HSS/HLR authenticate the subscriber and make a location update to the HSS/
in the home network of the subsriber. Accordingly, the subscriber HLR in the home network of the subscriber. Accordingly, the
profile is offered from the HSS/HLR. The subscriber profile subscriber profile is offered from the HSS/HLR. The subscriber
contains the allowed Access Point Names (APN), allowed PDP/PDN profile contains the allowed Access Point Names (APN), the allowed
Types and rules regarding the routing of data sessions (i.e. home PDP/PDN Types and rules regarding the routing of data sessions
routed or local breakout mode) [TS29.272]. SGSN/MME in the (i.e. home routed or local breakout mode) [TS29.272]. The SGSN/
visited network could use those informaiton to facilitate the MME in the visited network can use this information to facilitate
subsequent PDP/PDN session creation. the subsequent PDP/PDN session creation.
o PDP/PDN context creation: it's occurred after the subsriber makes o PDP/PDN context creation: this occurs after the subscriber makes a
a sucessful attachment. It's worth nothing that this stage is successful attachment. This stage is integrated with the
integrated with the attachment stage in the case of 4G, but a attachment stage in the case of 4G, but is a seperate process in
seperated process in 2/3G. 3GPP specifies three types of Packet 2/3G. 3GPP specifies three types of Packet Data Protocol
Data Protocol (PDP)/Packet Data Networks (PDN) to describe (PDP)/Packet Data Networks (PDN) to describe connections, i.e.
connections, i.e., PDP/PDN Type IPv4, PDP/PDN Type IPv6 and PDP/ PDP/PDN Type IPv4, PDP/PDN Type IPv6 and PDP/ PDN Type IPv4v6.
PDN Type IPv4v6. When a subsriber creates a data session, a user When a subscriber creates a data session, their device requests a
device is configured to request a particular PDP/PDN Type. The particular PDP/PDN Type. The allowed PDP/PDN types for that
allowed PDP/PDN types for the subscriber are learned from the subscriber are learned in the attachment stage. Hence, SGSN/MME
attachment stage. Hence, SGSN/MME could initiate PDP/PDN request could initiate PDP/PDN request to GGSN/PGW if the subscription
to GGSN/PGW if the subscription profile is allowed. profile is allowed.
The failures are likely happened in both stages due to an incompliant The failures are likely to occur in both stages due to an incompliant
implementation or mismatch between the subscriber requested and the implementation in the visited network or a mismatch between the
visited network capability. The failures in the attachment stage is subscriber requested and the capability of the visited network. The
independent with home routed and local breakout mode, while most failures in the attachment stage are independent of home routed or
failure cases in the PDP/PDN context creation stage are appeared in the local breakout mode, while most failure cases in the PDP/PDN
the local breakout cases. Section 4 and 5 make further descriptions context creation stage occur in the local breakout cases. Section 4
for each cases. The below table lists the several cases regarding and 5 describe each case. The below table lists several cases
the PDP/PDN creation stage. concerning the PDP/PDN creation stage.
+-------------+-------------------+--------------+ +-------------+-------------------+--------------+
| UE request | PDN/PDP IP Type |Local breakout| | UE request | PDN/PDP IP Type |Local breakout|
| | permitted | | | | permitted | |
+-------------+-------------------+--------------+ +-------------+-------------------+--------------+
| IPv4v6 | IPv4 or IPv6 |Failure case 1| | IPv4v6 | IPv4 or IPv6 |Failure case 1|
+-------------+-------------------+--------------+ +-------------+-------------------+--------------+
| IPv4v6 | IPv6 |Failure case 2| | IPv4v6 | IPv6 |Failure case 2|
+-------------+-------------------+--------------+ +-------------+-------------------+--------------+
| IPv6 | IPv4 |Failure case 3| | IPv6 | IPv4 |Failure case 3|
+-------------+-------------------+--------------+ +-------------+-------------------+--------------+
| IPv6 | IPv6 |Failure case 4| | IPv6 | IPv6 |Failure case 4|
| with 464xlat| without NAT64 | | | with 464xlat| without NAT64 | |
+-------------+-------------------+--------------+ +-------------+-------------------+--------------+
Table 1: Roaming Scenario Descriptions Table 1: Roaming Scenario Descriptions
4. Failure Case in Attachment Stage 4. Failure Case in Attachment Stage
3GPP specified PDP/PDN type IPv4v6 in order to allow a UE requesting 3GPP specified PDP/PDN type IPv4v6 in order to allow a UE request
both IPv4 and IPv6 within a single PDP/PDN request. This feature is both IPv4 and IPv6 within a single PDP/PDN request. 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 is introduced since the inception of HSS. PDP/PDN type IPv4v6 has been introduced at the inception of
Evolved Packet System (EPS) in 4G network. The nodes in 4G networks Evolved Packet System (EPS) in 4G networks. The nodes in 4G networks
should no issues with the handling of this PDN type. However, it's should present no issues with the handling of this PDN type.
of varing supports in 2/3G networks denpending 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., the Support Node (SGSN) software version. In theory, S4-SGSN (i.e. an
SGSN with S4 interface) support the PDP/PDN type IPv4v6 since SGSN with S4 interface) supports the PDP/PDN type IPv4v6 since
Release8 and Gn-SGSN (i.e., the SGSN with Gn interface) support 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.
The MAP (Mobile Application Part) protocol, as defined in 3GPP The MAP (Mobile Application Part) protocol, as defined in 3GPP
[TS29.002], is used over the Gr interface between SGSN and HLR. The [TS29.002], is used over the Gr interface between SGSN and HLR. The
MAP Information Element (IE) "ext-pdp-Type" contains the IPv4v6 PDP MAP Information Element (IE) "ext-pdp-Type" contains the IPv4v6 PDP
Type is conveyed to SGSN from HLR within the Insert Subscriber Data Type that is conveyed to SGSN from the HLR within the Insert
(ISD) MAP operation. If the SGSN does not support the IPv4v6 PDP Subscriber Data (ISD) MAP operation. If the SGSN does not support
Type, it will not support the "ext-pdp-Type" IE and consequently must the IPv4v6 PDP Type, it will not support the "ext-pdp-Type" IE and
silently discard that IE and continue processing of the rest of the consequently it must silently discard that IE and continue processing
ISD MAP message. The issue we observe is that multiple SGSNs will be of the rest of the ISD MAP message. The issue we observe is that
unable to correctly process a subscriber data received in the Insert multiple SGSNs will be unable to correctly process a subscriber's
Subscriber Data procedure[TS23.060]. As a consequence , it will data received in the Insert Subscriber Data Procedure[TS23.060]. As
likely refuse the subscriber attach request, which is erroneous a consequence, it will likely refuse the subscriber attach request.
behaviour as they are not 3GPP compliant. This is erroneous behavior due to the equipment not being 3GPP
Release 9 compliant.
Operators may have to remove the PDP/PDN type IPv4v6 from HLR/HSS in Operators may have to remove the PDP/PDN type IPv4v6 from the HLR/HSS
the home network, that will restrict UEs only initiates IPv4 PDP or in the home network, that will restrict UEs to only initiate IPv4 PDP
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 aligns with GSMA document, e.g [IR.33], [IR.88] and ensure that it aligns with the GSMA documents, e.g. [IR.33], [IR.88]
and [IR.21]. Such an agreement requires the visited operator to get
[IR.21]. The agreement requires visited operators to get necessary the necessary patch on all their SGSN nodes to support PDP/PDN type
patch on all SGSN nodes to support PDP/PDN type IPv4v6. IPv4v6.
There are some specific implementation in HLS/HSS of home network as As an alternative solution there are some specific implementations
an alternative solution. Once the HLR/HSS receives an Update (not standardised by 3GPP) in the HLS/HSS of the home network. When
Location message from visited SGSN known to not support the PDP type the HLR/HSS receives an Update Location message from a visited SGSN
IPv4v6, only the subscription data with PDP/PDN type IPv4 will be known to not support the PDP type IPv4v6, subscription data with only
sent to SGSN in the Insert Subscriber Data procedure. It guarantee PDP/PDN type IPv4 will be sent to that SGSN in the Insert Subscriber
the user profile could compatible with visited SGSN/MME capability. Data procedure. It guarantees the user profile is compatible with
visited SGSN/MME capability.
5. Failure Cases in PDP/PDN Creation 5. Failure Cases in PDP/PDN Creation
Once a subscriber succeed in the attach stage, IP allocation process When a subscriber succeeds in the attach stage, the IP allocation
is taken place to allocate IP addresses to the subscriber. This process takes place to allocate IP addresses to the subscriber. This
section has summarized several failures in the break-out cases. section summarizes several failures in the break-out cases.
5.1. Case 1: Splitting Dual-stack Bearer 5.1. Case 1: Splitting Dual-stack Bearer
Dual-stack capability can be provided using separate PDP/PDN Dual-stack capability can be provided using separate PDP/PDN
activations. That means only a single IPv4 and IPv6 PDP/PDN is activations. That means only separate parallel single-stack IPv4 and
allowed to be initiated to allocate IPv4 and IPv6 address separately. IPv6 PDP/PDN connections are allowed to be initiated to separately
The below lists the cases. allocate IPv4 and IPv6 addresses.
o The SGSN/MME returns Session Manamgement (SM) Cause #52, "Single The cases are listed below:
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 due to the o The SGSN/MME does not set the Dual Address Bearer Flag because the
operator using single addressing per bearer to support operator uses single addressing per bearer to support interworking
interworking with nodes of earlier releases with nodes of earlier releases
A roaming subscriber with IPv4v6 PDP/PDN type have 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 single IP version in request into two separated PDP/PDN requests with a single IP version
order to achieve equivalent results. Some drawbacks in this case are in order to achieve equivalent results. Some drawbacks of this case
listed as following: are listed as below:
o The parallel PDP/PDN activations would likely double PDP/PDN o The parallel PDP/PDN activations would likely double PDP/PDN
resources consumptions. It impacts the capacity of GGSN/PGW, resources consumptions. It 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 activations are only allowed on
those nodes. those nodes.
o Some networks may only allow one PDP/PDN is alive for each o Some networks may only allow one PDP/PDN is alive for each
subscriber. For example, IPv6 PDP/PDN will be rejected if the subscriber. For example, 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 lost IPv6 connection in the visited network. It's even worse will lose the IPv6 connection in the visited network. It is even
that it may have a risk of losing all data connectivity if the worse as they may have a risk of losing all data connectivity if
IPv6 PDP gets rejected with a permanent error at the APN-level and the IPv6 PDP gets rejected with a permanent error at the APN-level
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) treat IPv4 and IPv6 session as Enforcement Function (PCEF) treats the IPv4 and IPv6 session as
independent and perform 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 the limitation of allowed simultaneous o Mobile devices may have a limitation on allowed simultaneous PDP/
PDP/PDN activations. Overmuch PDP/PDN activation may result in PDN activations. Excessive PDP/PDN activation may result in other
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 IPv6-only configuration for the IMS service, Some operators may adopt an IPv6-only configuration for the IMS
e.g. Voice over LTE (VoLTE)[IR.92] or Rich Communication Suite service, e.g. Voice over LTE (VoLTE)[IR.92] or Rich Communication
(RCS)[RCC.07]. Since IMS roaming architecture will offload all Suite (RCS)[RCC.07]. Since the IMS roaming architecture will offload
traffic in the visited network, a dual-stack subscriber can only be all traffic in the visited network, a dual-stack subscriber can only
assigned with IPv6 address and no IPv4 address returned. It requires be assigned with an IPv6 prefix and no IPv4 address returned. This
all the IMS based applications should be IPv6 capable. A requires that all the IMS based applications should be IPv6 capable.
translation-based method, for example Bump-in-the-host (BIH)[RFC6535] A translation-based method, for example Bump-in-the-host
or 464xlat [RFC6877] may help to address the issue if there are IPv6 (BIH)[RFC6535] or 464xlat [RFC6877] may help to address the issue if
compatibility problems. Those functions could be automatically there are IPv6 compatibility problems. Those functions could be
enabled in an IPv6-only network and disabled in a dual-stack or IPv4 automatically enabled in an IPv6-only network and disabled in a dual-
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 with IPv6 PDP/PDN request could guarantee the subscription networks and making an IPv6 PDP/PDN request should guarantee that the
data is compatible with the visited pre-Release 9 SGSN. When a subscription data is compatible with the visited pre-Release 9 SGSN.
subscriber requests PDP/PDN type IPv6, the network should only return When a subscriber requests PDP/PDN type IPv6, the network should only
the expected IPv6 address. The mobile device may be failed to get IP return the expected IPv6 prefix. The mobile device may fail to get
address if the visited network only allocates an IPv4 address to a an IPv6 prefix if the visited network only allocates an IPv4 address
subscriber. In that case, the request will be dropped and the cause to the subscriber. In that case, the request will be dropped and the
code should be sent to the user. cause code should be sent to the user.
A proper fallback is desirable however the behavior is implementation A proper fallback is desirable, however the behavior is
specific. There are some mobile devices have the ability to provide implementation specific. There are some mobile devices have the
a different configuration for home network and visited network ability to provide a different configuration for home network and
respectively. Android system solves the issue by setting the roaming visited network respectively. For instance, the Android system
Access Point Name(APN). It guarantees UE will always initiate PDP/ solves the issue by setting the roaming protocol to IPv4 for the
PDN type IPv4 in the roaming area. Access Point Name(APN). It guarantees that UE will always initiate
an PDP/PDN type IPv4 in the roaming area.
5.4. Case 4: 464xlat Support 5.4. Case 4: 464xlat Support
464xlat[RFC6877] is proposed to address IPv4 compatibility issue in a 464xlat[RFC6877] is proposed to address the IPv4 compatibility issue
IPv6 single-stack environment. The function on a mobile terminal in an IPv6 single-stack environment. The function on a mobile device
likely gets along with PDP/PDN IPv6 type request to cooperate with a is likely in conjunction with a PDP/PDN IPv6 type request and
remote NAT64[RFC6146] gateway. 464xlat may use the mechanism defined cooperates with a remote NAT64[RFC6146] gateway. 464xlat may use the
in [RFC7050] to automatically detect the presence of DNS64 and learn mechanism defined in [RFC7050] to automatically detect the presence
the IPv6 prefix used for protocol translation. When a mobile device of DNS64 and to learn the IPv6 prefix used for protocol translation.
with 464xlat function roams to an IPv6 visited network without the In the local breakout approach when a mobile device with 464xlat
presence of NAT64 or DNS64, 464xlat may get failed to perform if function roams to an IPv6 visited network without the presence of
traffic is undergoing the local breakout approach. NAT64 or DNS64, 464xlat will fail to function.
The issue has been found mostly in a intra-PLMN mobility case 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 take home routed mode to perform may turn off the local breakout and use the home routed mode to
464xlat. Some devices may support the configuration to adopt 464xlat perform 464xlat. Some devices may support the configuration to adopt
in the home networks and use IPv4-only in the visited networks with 464xlat in the home networks and use IPv4-only in the visited
different roaming profile configurations. It could also be a networks with different roaming profile configurations. This could
solution to address this issue. also be a solution to address this issue.
6. Discussions 6. HLR/HSS User Profile Setting
A proper user profile configuration could provide deterministic
network control of the connectivity requests from dual-stack,
IPv4-only and IPv6-only devices. It's desirable that the network
could set-up proper connectivity for any type of the devices.The HLR/
HSS may have to apply extra logic to achieve this.
The following are examples to demonstrate the settings for the
scenarios and decision criteria to apply when returning user profile
information to visited SGSN.
Scenario 1: Support IPv6-only, IPv4-only and dual-stack devices
user profile #1:
PDP-Context ::= SEQUENCE {
pdp-ContextId ContextId,
pdp-Type PDP-Type-IPv4
....
ext-pdp-Type PDP-Type-IPv4v6
...
}
user profile #2:
PDP-Context ::= SEQUENCE {
pdp-ContextId ContextId,
pdp-Type PDP-Type-IPv6
....
}
The full PDP-context parameters is refered to Section 17.7.1 "Mobile
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
dual-stack devices to work. And, the user profile #2 fulfills the
request if the device asks for IPv6 only PDP context.
Scenario 2: Support dual-stack devices with pre-R9 vSGSN access
user profile #1:
PDP-Context ::= SEQUENCE {
pdp-ContextId ContextId,
pdp-Type PDP-Type-IPv4
....
ext-pdp-Type PDP-Type-IPv4v6
...
}
user profile #2:
PDP-Context ::= SEQUENCE {
pdp-ContextId ContextId,
pdp-Type PDP-Type-IPv4
....
}
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
profile#2 to visited SGSN.
7. Discussions
Several failure cases have been discussed in this document. It has Several failure cases have been discussed in this document. It has
been testified the major issues are occurred at the 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 attach and the IP allocation process.
During the initial network attach, PDP/PDN type IPv4v6 is major During the initial network attach, PDP/PDN type IPv4v6 is the major
concern to the visited pre-Release 9 SGSN. The dual-stack deployment concern to the visited pre-Release 9 SGSN. The dual-stack deployment
is recommended in most cases. However, it may take some times in a is recommended in most cases. However, it may take some times in a
mobile environment. 3GPP didn't specify PDP/PDN type IPv4v6 in the mobile environment. 3GPP didn't specify PDP/PDN type IPv4v6 in the
early release. Such PDP/PDN type is supported in new-built EPS early release. Such PDP/PDN type is supported in new-built EPS
network, but didn't support well in the third generation network. network, but didn't support well in the third generation network.
The situations may cause the roaming issues dropping the attach The situations may cause the roaming issues dropping with the attach
request from dual-stack subscribers. Operators may have to adopt request from dual-stack subscribers. Operators may have to adopt
temporary solution unless all the interworking nodes(i.e. SSGN) in temporary solution unless all the interworking nodes(i.e. the SSGN)
the visited network have been upgraded to support ext-PDP-Type in the visited network have been upgraded to support the ext-PDP-Type
feature. feature.
The issues in the IP address allocation process are caused due to the The issues in the IP address allocation process are caused by a local
local breakout policy. Since the IP address is allocated by the breakout policy. Since the IP address is allocated by the visited
visited GGSN or PGW, the mismatch is found in the following aspects. GGSN or PGW, the mismatch is found in the following aspects.
o The mismatch between requested PDP/PDN type and permitted PDP/PDN o The mismatch between the requested PDP/PDN type and the permitted
type PDP/PDN type
o The mismatch between application capability and allowed network o The mismatch between the application capability and allowed
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
particular network deployment status the support for that function in the vistited network
There are some solutions to overcome the issue. Those solutions can There are some solutions to overcome the issue. Those solutions can
be done either in the network side or mobile device side. The below be made either in the network side or mobile device side. There
lists potential workarounds. 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 roamer. When a o A dedicated roaming APN profile is implemented for the roamer.
subscriber roams to a visited network, PDP/PDN type IPv4 is always When a subscriber roams to a visited network, PDP/PDN type IPv4 is
be selected for session activation. to be always selected for session activation.
o Networks could deploy AAA server to coordinate the mobile device o Networks could deploy an AAA server to coordinate the mobile
capability. Once the GGSN/PGW receive the session creation device capability. Once the GGSN/PGW receives the session
requests, it will initiate an Access-Request to an AAA server in creation request, it will initiate an Access-Request to an AAA
the home land via the Radius protocol. The Access-Request server in the home network via the Radius protocol. The Access-
contains subscriber and visited network information, e.g. PDP/PDN Request contains subscriber and visited network information, e.g.
Type, International Mobile Equipment Id (IMEI), Software PDP/PDN Type, International Mobile Equipment Id (IMEI), Software
Version(SV) and visited SGSN/MME location code, etc. The AAA Version(SV) and visited SGSN/MME location code, etc. The AAA
server could take mobile device capability combining with the server could take mobile device capability and combine it with the
visited network information to ultimately determine the type of visited network information to ultimately determine the type of
session to be created, i.e. IPv4, IPv6 or IPv4v6. session to be created, i.e. IPv4, IPv6 or IPv4v6.
7. IANA Considerations 8. IANA Considerations
This document makes no request of IANA. This document makes no request of IANA.
8. Security Considerations 9. Security Considerations
Even if this document does not define a new architecture nor a new Although this document defines neither a new architecture nor a new
protocol, it is encouraged to refer to [RFC6459] for a generic protocol, it is encouraged to refer to [RFC6459] for a generic
discussion on IPv6-related security considerations. discussion on IPv6-related security considerations.
9. 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 and Cameron Byrne for
their helpful comments. their helpful comments.
10. References The authors especially thank Fred Baker and Ross Chandler for his
efforts and contributions on editing which substantially improves the
legibility of the document.
10.1. Normative References 11. References
11.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997. Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC6052] Bao, C., Huitema, C., Bagnulo, M., Boucadair, M., and X. [RFC6052] Bao, C., Huitema, C., Bagnulo, M., Boucadair, M., and X.
Li, "IPv6 Addressing of IPv4/IPv6 Translators", RFC 6052, Li, "IPv6 Addressing of IPv4/IPv6 Translators", RFC 6052,
October 2010. 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
skipping to change at page 11, line 36 skipping to change at page 13, line 21
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.
10.2. Informative References 11.2. Informative References
[EU-Roaming-III] [EU-Roaming-III]
"http://www.amdocs.com/Products/Revenue- "http://www.amdocs.com/Products/Revenue-
Management/Documents/ Management/Documents/
amdocs-eu-roaming-regulation-III-solution.pdf", July 2013. amdocs-eu-roaming-regulation-III-solution.pdf", July 2013.
[IR.21] Global System for Mobile Communications Association, [IR.21] Global System for Mobile Communications Association,
GSMA., "Roaming Database, Structure and Updating GSMA., "Roaming Database, Structure and Updating
Procedures", July 2012. Procedures", July 2012.
skipping to change at page 13, line 7 skipping to change at page 14, line 40
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] [TS29.002]
3rd Generation Partnership Project, 3GPP., "Mobile 3rd Generation Partnership Project, 3GPP., "Mobile
Application Part (MAP) specification v9.00", December Application Part (MAP) specification v9.12.0", December
2009. 2009.
[TS29.272] [TS29.272]
3rd Generation Partnership Project, 3GPP., "Mobility 3rd Generation Partnership Project, 3GPP., "Mobility
Management Entity (MME) and Serving GPRS Support Node Management Entity (MME) and Serving GPRS Support Node
(SGSN) related interfaces based on Diameter protocol (SGSN) related interfaces based on Diameter protocol
v9.00", September 2009. v9.00", September 2009.
Authors' Addresses Authors' Addresses
 End of changes. 69 change blocks. 
234 lines changed or deleted 307 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/