diff options
Diffstat (limited to 'doc/rfc/rfc7445.txt')
| -rw-r--r-- | doc/rfc/rfc7445.txt | 1067 |
1 files changed, 1067 insertions, 0 deletions
diff --git a/doc/rfc/rfc7445.txt b/doc/rfc/rfc7445.txt new file mode 100644 index 0000000..953cbea --- /dev/null +++ b/doc/rfc/rfc7445.txt @@ -0,0 +1,1067 @@ + + + + + + +Internet Engineering Task Force (IETF) G. Chen +Request for Comments: 7445 H. Deng +Category: Informational China Mobile +ISSN: 2070-1721 D. Michaud + Rogers Communications + J. Korhonen + Broadcom Corporation + M. Boucadair + France Telecom + March 2015 + + + Analysis of Failure Cases in IPv6 Roaming Scenarios + +Abstract + + This document identifies a set of failure cases that may be + encountered by IPv6-enabled mobile customers in roaming scenarios. + The analysis reveals that the failure causes include improper + configurations, incomplete functionality support in equipment, and + inconsistent IPv6 deployment strategies between the home and the + visited networks. + +Status of This Memo + + This document is not an Internet Standards Track specification; it is + published for informational purposes. + + This document is a product of the Internet Engineering Task Force + (IETF). It represents the consensus of the IETF community. It has + received public review and has been approved for publication by the + Internet Engineering Steering Group (IESG). Not all documents + approved by the IESG are a candidate for any level of Internet + Standard; see Section 2 of RFC 5741. + + Information about the current status of this document, any errata, + and how to provide feedback on it may be obtained at + http://www.rfc-editor.org/info/rfc7445. + + + + + + + + + + + + + +Chen, et al. Informational [Page 1] + +RFC 7445 IPv6 Roaming Analysis March 2015 + + +Copyright Notice + + Copyright (c) 2015 IETF Trust and the persons identified as the + document authors. All rights reserved. + + This document is subject to BCP 78 and the IETF Trust's Legal + Provisions Relating to IETF Documents + (http://trustee.ietf.org/license-info) in effect on the date of + publication of this document. Please review these documents + carefully, as they describe your rights and restrictions with respect + to this document. Code Components extracted from this document must + include Simplified BSD License text as described in Section 4.e of + the Trust Legal Provisions and are provided without warranty as + described in the Simplified BSD License. + +Table of Contents + + 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 + 1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3 + 2. Background . . . . . . . . . . . . . . . . . . . . . . . . . 4 + 2.1. Roaming Architecture: An Overview . . . . . . . . . . . . 4 + 2.1.1. Home Routed Mode . . . . . . . . . . . . . . . . . . 4 + 2.1.2. Local Breakout Mode . . . . . . . . . . . . . . . . . 5 + 2.2. Typical Roaming Scenarios . . . . . . . . . . . . . . . . 6 + 3. Failure Case in the Network Attachment . . . . . . . . . . . 7 + 4. Failure Cases in the PDP/PDN Creation . . . . . . . . . . . . 9 + 4.1. Case 1: Splitting Dual-Stack Bearer . . . . . . . . . . . 9 + 4.2. Case 2: IPv6 PDP/PDN Unsupported . . . . . . . . . . . . 11 + 4.3. Case 3: Inappropriate Roaming APN Set . . . . . . . . . . 11 + 4.4. Case 4: Fallback Failure . . . . . . . . . . . . . . . . 11 + 5. Failure Cases in the Service Requests . . . . . . . . . . . . 12 + 5.1. Lack of IPv6 Support in Applications . . . . . . . . . . 12 + 5.2. 464XLAT Support . . . . . . . . . . . . . . . . . . . . . 12 + 6. HLR/HSS User Profile Setting . . . . . . . . . . . . . . . . 13 + 7. Discussion . . . . . . . . . . . . . . . . . . . . . . . . . 14 + 8. Security Considerations . . . . . . . . . . . . . . . . . . . 15 + 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 16 + 9.1. Normative References . . . . . . . . . . . . . . . . . . 16 + 9.2. Informative References . . . . . . . . . . . . . . . . . 16 + Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 18 + Contributors . . . . . . . . . . . . . . . . . . . . . . . . . . 18 + Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 19 + + + + + + + + + +Chen, et al. Informational [Page 2] + +RFC 7445 IPv6 Roaming Analysis March 2015 + + +1. Introduction + + Many mobile operators have deployed IPv6, or are about to, in their + operational networks. A customer in such a network can be provided + IPv6 connectivity if their User Equipment (UE) is IPv6 compliant. + Operators may adopt various approaches to deploy IPv6 in mobile + networks, such as the solutions described in [TR23.975]. Depending + on network conditions, either dual-stack or IPv6-only deployment + schemes can be enabled. + + A detailed overview of IPv6 support in 3GPP architectures is provided + in [RFC6459]. + + It has been observed and reported that a mobile subscriber roaming + around a different operator's areas may experience service disruption + due to inconsistent configurations and incomplete functionality of + equipment in the network. This document focuses on these issues. + +1.1. Terminology + + This document makes use of these terms: + + o Mobile networks refer to 3GPP mobile networks. + + o Mobile UE denotes a 3GPP device that can be connected to 3GPP + mobile networks. + + o The Public Land Mobile Network (PLMN) is a network that is + operated by a single administrative entity. A PLMN (and therefore + also an operator) is identified by the Mobile Country Code (MCC) + and the Mobile Network Code (MNC). Each (telecommunications) + operator providing mobile services has its own PLMN [RFC6459]. + + o The Home Location Register (HLR) is a pre-Release 5 database (but + is also used in real deployments of Release 5 and later) that + contains subscriber data and information related to call routing. + All subscribers of an operator and the subscribers' enabled + services are provisioned in the HLR [RFC6459]. + + o The Home Subscriber Server (HSS) is a database for a given + subscriber and was introduced in 3GPP Release 5. It is the entity + containing the subscription-related information to support the + network entities actually handling calls/sessions [RFC6459]. + + o "HLR/HSS" is used collectively for the subscriber database unless + referring to the failure case related to General Packet Radio + Service (GPRS) Subscriber data from the HLR. + + + + +Chen, et al. Informational [Page 3] + +RFC 7445 IPv6 Roaming Analysis March 2015 + + + An overview of key 3GPP functional elements is documented in + [RFC6459]. + + "Mobile device" and "mobile UE" are used interchangeably. + +2. Background + +2.1. Roaming Architecture: An Overview + + Roaming occurs in two scenarios: + + o International roaming: a mobile UE enters a visited network + operated by a different operator, where a different PLMN code is + used. The UEs could, either in an automatic mode or in a manual + mode, attach to the visited PLMN. + + o Intra-PLMN mobility: an operator may have one or multiple PLMN + codes. A mobile UE could pre-configure the codes to identify the + Home PLMN (HPLMN) or Equivalent HPLMN (EHPLMN). Intra-PLMN + mobility allows the UE to move to a different area of HPLMN and + EHPLMN. When the subscriber profile is not stored in the visited + area, HLR/HSS in the Home area will transmit the profile to the + Serving GPRS Support Node (SGSN) / Mobility Management Entity + (MME) in the visited area so as to complete network attachment. + + When a UE is turned on or is transferred via a handover to a visited + network, the mobile device will scan all radio channels and find + available PLMNs to attach to. The SGSN or the MME in the visited + networks must contact the HLR or HSS to retrieve the subscriber + profile. + + Steering of roaming may also be used by the HPLMN to further restrict + which of the available networks the UE may be attached to. Once the + authentication and registration stage is completed, the Packet Data + Protocol (PDP) or Packet Data Networks (PDN) activation and traffic + flows may be operated differently according to the subscriber profile + stored in the HLR or the HSS. + + The following subsections describe two roaming modes: Home-routed + traffic (Section 2.1.1) and Local breakout (Section 2.1.2). + +2.1.1. Home Routed Mode + + In this mode, the subscriber's UE gets IP addresses from the home + network. All traffic belonging to that UE is therefore routed to the + home network (Figure 1). + + + + + +Chen, et al. Informational [Page 4] + +RFC 7445 IPv6 Roaming Analysis March 2015 + + + GPRS roaming exchange (GRX) or Internetwork Packet Exchange (IPX) + networks [IR.34] are likely to be invoked as the transit network to + deliver the traffic. This is the main mode for international roaming + of Internet data services to facilitate the charging process between + the two involved operators. + + +-----------------------------+ +------------------------+ + |Visited Network | |Home Network | + | +----+ +----+---+ | (GRX/IPX) | +--------+ Traffic Flow + | | UE |=======>|SGSN/SGW|====================>|GGSN/PGW|============> + | +----+ +----+---+ | | +--------+ | + | |MME | | | | + | +----+ | Signaling | +--------+ | + | |-------------------------->|HLR/HSS | | + | | | +--------+ | + +-----------------------------+ +------------------------+ + + Figure 1: Home Routed Traffic + +2.1.2. Local Breakout Mode + + In the local breakout mode, IP addresses are assigned by the visited + network to a roaming mobile UE. Unlike the home routed mode, the + traffic doesn't have to traverse GRX/IPX; it is offloaded locally at + a network node close to that device's point of attachment in the + visited network. This mode ensures a more optimized forwarding path + for the delivery of packets belonging to a visiting UE (Figure 2). + + +----------------------------+ +----------------+ + |Visited Network | |Home Network | + | +----+ +--------+ | Signaling | +--------+ | + | | UE |=======>|SGSN/MME|------------------->|HLR/HSS | | + | +----+ +---+----+ | (GRX/IPX) | +--------+ | + | |SGW| | | | + | +---+ | | | + | || | | | + | +--------+ | | | + | |GGSN/PGW| | | | + | +--------+ | | | + | Traffic Flow || | | | + +------------------||--------+ +----------------+ + \/ + + Figure 2: Local Breakout + + The international roaming of services based on the IP Multimedia + Subsystem (IMS), e.g., Voice over LTE (VoLTE)[IR.92], is claimed to + select the local breakout mode in [IR.65]. Data service roaming + + + +Chen, et al. Informational [Page 5] + +RFC 7445 IPv6 Roaming Analysis March 2015 + + + across different areas within an operator network might use local + breakout mode in order to get more efficient traffic forwarding and + also ease emergency services. The local breakout mode could also be + applied to an operator's alliance for international roaming of data + service. + + EU Roaming Regulation III [EU-Roaming-III] involves local breakout + mode allowing European subscribers roaming in European 2G/3G networks + to have their Internet data routed directly to the Internet from + their current Visited Public Land Mobile Network (VPLMN). + + Specific local breakout-related configuration considerations are + listed below: + + o Operators may add the APN-OI-Replacement flag defined in 3GPP + [TS29.272] into the user's subscription data. The visited network + indicates a local domain name to replace the user requested Access + Point Name (APN). Consequently, the traffic would be steered to + the visited network. Those functions are normally deployed for + the intra-PLMN mobility cases. + + o Operators may also configure the VPLMN-Dynamic-Address-Allowed + flag [TS29.272] in the user's profile to enable local breakout + mode in VPLMNs. + + o 3GPP specified the Selected IP Traffic Offload (SIPTO) function + [TS23.401] since Release 10 in order to get efficient route paths. + It enables an operator to offload a portion of the traffic at a + network node close to the UE's point of attachment to the network. + + o The Global System for Mobile Communications Association (GSMA) has + defined Roaming Architecture for Voice over LTE with Local + Breakout (RAVEL) [IR.65] as the IMS international roaming + architecture. Local breakout mode has been adopted for the IMS + roaming architecture. + +2.2. Typical Roaming Scenarios + + Three stages occur when a subscriber roams to a visited network and + intends to invoke services: + + o Network attachment: this occurs when the UE enters a visited + network. During the attachment phase, the visited network should + authenticate the subscriber and make a location update to the + HSS/HLR in the home network of the subscriber. Accordingly, the + subscriber profile is offered from the HSS/HLR. The subscriber + profile contains the allowed APNs, the allowed PDP/PDN Types, and + rules regarding the routing of data sessions (i.e., home routed or + + + +Chen, et al. Informational [Page 6] + +RFC 7445 IPv6 Roaming Analysis March 2015 + + + local breakout mode) [TS29.272]. The SGSN/MME in the visited + network can use this information to facilitate the subsequent + PDP/PDN session creation. + + o PDP/PDN context creation: this occurs after the subscriber's UE + has been successfully attached to the network. This stage is + integrated with the attachment stage in the case of 4G, but is a + separate process in 2G/3G. 3GPP specifies three types of PDP/PDN + to describe connections: PDP/PDN Type IPv4, PDP/PDN Type IPv6, and + PDP/PDN Type IPv4v6. When a subscriber creates a data session, + their device requests a particular PDP/PDN Type. The allowed + PDP/PDN Types for that subscriber are learned in the attachment + stage. Hence, the SGSN and MME via the Serving Gateway (SGW) + could initiate a PDP/PDN request to Gateway GSN (GGSN) / Packet + Data Network Gateway (PGW) modulo subscription grants. + + o Service requests: when the PDP/PDN context is created + successfully, UEs may launch applications and request services + based on the allocated IP addresses. The service traffic will be + transmitted via the visited network. + + Failures that occur at the attachment stage (Section 3) are + independent of home routed and the local breakout modes. Most + failure cases in the PDP/PDN context creation (Section 4) and in + service requests (Section 5) occur in the local breakout mode. + +3. Failure Case in the Network Attachment + + 3GPP specified PDP/PDN Type IPv4v6 in order to allow a UE to get both + an IPv4 address and an IPv6 prefix within a single PDP/PDN bearer. + This option is stored as a part of subscription data for a subscriber + in the HLR/HSS. PDP/PDN Type IPv4v6 has been introduced at the + inception of the Evolved Packet System (EPS) in 4G networks. + + The nodes in 4G networks should present no issues with the handling + of this PDN Type. However, the level of support varies in 2G/3G + networks depending on the SGSN software version. In theory, S4-SGSN + (i.e., an SGSN with S4 interface) has supported the PDP/PDN Type + IPv4v6 since Release 8, and Gn-SGSN (i.e., the SGSN with Gn + interface) has supported it since Release 9. In most cases, + operators normally use Gn-SGSN to connect either GGSN in 3G or Packet + Data Network Gateway (PGW) in 4G. + + The MAP (Mobile Application Part) protocol, as defined in 3GPP + [TS29.002], is used over the Gr interface between SGSN and HLR. The + MAP Information Element (IE) "ext-pdp-Type" contains the IPv4v6 PDP + Type that is conveyed to SGSN from the HLR within the Insert + Subscriber Data (ISD) MAP operation. If the SGSN does not support + + + +Chen, et al. Informational [Page 7] + +RFC 7445 IPv6 Roaming Analysis March 2015 + + + the IPv4v6 PDP Type, it will not support the "ext-pdp-Type" IE; + consequently, it must silently discard that IE and continue + processing the rest of the ISD MAP message. An issue that has been + observed is that multiple SGSNs are unable to correctly process a + subscriber's data received in the Insert Subscriber Data Procedure + [TS23.060]. As a consequence, it will likely discard the subscriber + attach request. This is erroneous behavior due to the equipment not + being compliant with 3GPP Release 9. + + In order to avoid encountering this attach problem at a visited SGSN, + both operators should make a comprehensive roaming agreement to + support IPv6 and ensure that it aligns with the GSMA documents, e.g., + [IR.33], [IR.88], and [IR.21]. Such an agreement requires the + visited operator to get the necessary patch on all its SGSN nodes to + support the "ext-pdp-Type" MAP IE sent by the HLR. To ensure data- + session continuity in Radio Access Technology (RAT) handovers, the + PDN Type sent by the HSS to the MME should be consistent with the PDP + Type sent by the HLR to the Gn-SGSN. Where roaming agreements and + visited SGSN nodes have not been updated, the HPLMN also has to make + use of specific implementations (not standardized by 3GPP, discussed + further in Section 6) in the HLR/HSS of the home network. That is, + when the HLR/HSS receives an Update Location message from a visited + SGSN not known to support dual-stack in a single bearer, subscription + data allowing only PDP/PDN Type IPv4 or IPv6 will be sent to that + SGSN in the Insert Subscriber Data procedure. This guarantees that + the user profile is compatible with the visited SGSN/MME capability. + In addition, HSS may not have to change if the PGW is aware of the + subscriber's roaming status and only restricts the accepted PDN Type + consistent with PDP Type sent by the HLR. For example, a AAA server + may coordinate with the PGW to decide the allowed PDN Type. + + Alternatively, HPLMNs without the non-standardized capability to + suppress the sending of "ext-pdp-Type" by the HLR may have to remove + this attribute from APNs with roaming service. PDN Type IPv4v6 must + also be removed from the corresponding profile for the APN in the + HSS. This will restrict their roaming UEs to only IPv4 or IPv6 + PDP/PDN activation. This alternative has problems: + + o The HPLMN cannot support dual-stack in a single bearer at home + where the APN profile in the HLR/HSS is also used for roaming. + + o The UE may set up separate parallel bearers for IPv4 and IPv6, + where only single-stack IPv4 or IPv6 service is preferred by the + operator. + + + + + + + +Chen, et al. Informational [Page 8] + +RFC 7445 IPv6 Roaming Analysis March 2015 + + +4. Failure Cases in the PDP/PDN Creation + + When a subscriber's UE succeeds in the attach stage, the IP + allocation process takes place to retrieve IP addresses. In general, + a PDP/PDN Type IPv4v6 request implicitly allows the network side to + make several IP assignment options, including IPv4-only, IPv6-only, + IPv4 and IPv6 in single PDP/PDN bearer, and IPv4 and IPv6 in + separated PDP/PDN bearers. + + A PDP/PDN Type IPv4 or IPv6 restricts the network side to only + allocate the requested IP address family. + + This section summarizes several failures in the Home Routed (HR) and + Local Breakout (LBO) mode as shown in Table 1. + + +-------+-------------+------------------------+---------+ + | Case# | UE request | PDP/PDN IP Type | Mode | + | | | permitted on GGSN/PGW | | + +-------+-------------+------------------------+---------+ + | | IPv4v6 | IPv4v6 | HR | + | #1 |-------------+------------------------+---------+ + | | IPv4v6 | IPv4 or IPv6 | LBO | + +-------+-------------+------------------------+---------+ + | #2 | IPv6 | IPv6 | HR | + +-------+-------------+------------------------+---------+ + | #3 | IPv4 | IPv6 | HR | + +-------+-------------+------------------------+---------+ + | #4 | IPv6 | IPv4 | LBO | + +-------+-------------+------------------------+---------+ + + Table 1: Failure Cases in the PDP/PDN Creation + +4.1. Case 1: Splitting Dual-Stack Bearer + + Dual-stack capability is provided using separate PDP/PDN activation + in the visited network that doesn't support PDP/PDN Type IPv4v6. + That means only separate, parallel, single-stack IPv4 and IPv6 + PDP/PDN connections are allowed to be initiated to separately + allocate an IPv4 address and an IPv6 prefix. The SGSN does not + support the Dual Address Bearer Flag (DAF) or does not set the DAF + because the operator uses single addressing per bearer to support + interworking with nodes of earlier releases. Regardless of home + routed or local breakout mode, GGSN/PGW will change PDN/PDP Type to a + single address PDP/PDN Type and return the Session Management (SM) + Cause #52 "single address bearers only allowed" or SM Cause #28 + "unknown PDP address or PDP type" as per [TS24.008] and [TS24.301] to + + + + + +Chen, et al. Informational [Page 9] + +RFC 7445 IPv6 Roaming Analysis March 2015 + + + the UE. In this case, the UE may make another PDP/PDN request with a + single address PDP Type (IPv4 or IPv6) other than the one already + activated. + + This approach suffers from the following drawbacks: + + o The parallel PDP/PDN activation would likely double PDP/PDN bearer + resource on the network side and Radio Access Bearer (RAB) + resource on the Radio Access Network (RAN) side. It also impacts + the capacity of the GGSN/PGW, since only a certain amount of + PDP/PDN activation is allowed on those nodes. + + o Some networks may allow only one PDP/PDN to be alive for each + subscriber. For example, an IPv6 PDP/PDN will be rejected if the + subscriber has an active IPv4 PDP/PDN. Therefore, the subscriber + would not be able to obtain the IPv6 connection in the visited + network. It is even 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 and not an error specific to the PDP-Type + IPv6 requested. + + o Additional correlations between those two PDP/PDN contexts are + required on the charging system. + + o Policy and Charging Rules Function (PCRF) [TS29.212] / Policy and + Charging Enforcement Function (PCEF) treats the IPv4 and IPv6 + sessions as independent and performs different quality-of-service + (QoS) policies. The subscriber may have an unstable experience + due to different behaviors on each IP version connection. + + o Mobile devices may have a limitation on the number of allowed + simultaneous PDP/PDN contexts. Excessive PDP/PDN activations may + result in service disruption. + + In order to avoid the issue, the roaming agreement in the home routed + mode should make sure the visited SGSN supports and sets the DAF. + Since the PDP/PDN Type IPv4v6 is supported in the GGSN/PGW of the + home network, it's expected that the visited SGSN/MME could create a + dual-stack bearer as the UE requested. + + In the local breakout mode, the visited SGSN may only allow single IP + version addressing. In this case, the DAF on the visited SGSN/MME + has to be unset. One approach is to set a dedicated APN [TS23.003] + profile to only request PDP/PDN Type IPv4 in the roaming network. + Some operators may also consider not adopting the local breakout mode + to avoid the risks. + + + + + +Chen, et al. Informational [Page 10] + +RFC 7445 IPv6 Roaming Analysis March 2015 + + +4.2. Case 2: IPv6 PDP/PDN Unsupported + + PDP/PDN Type IPv6 has good compatibility to visited networks during + the network attachment. In order to support the IPv6-only visitors, + SGSN/MME in the visited network is required to accept IPv6-only + PDP/PDN activation requests and enable IPv6 on the user plane in the + direction of the home network. + + In some cases, IPv6-only visitors may still be subject to the SGSN + capability in visited networks. This becomes especially risky if the + home operator performs roaming steering targeted to an operator that + doesn't allow IPv6. The visited SGSN may just directly reject the + PDP context activation. Therefore, it's expected that the visited + network is IPv6 roaming-friendly to enable the functions on SGSN/MME + by default. Otherwise, operators may consider steering the roaming + traffic to the IPv6-enabled visited network that has an IPv6 roaming + agreement. + +4.3. Case 3: Inappropriate Roaming APN Set + + If IPv6 single stack with the home routed mode is deployed, the + requested PDP/PDN Type should also be IPv6. Some implementations + that support the roaming APN profile may set IPv4 as the default + PDP/PDN Type, since the visited network is incapable of supporting + PDP/PDN Types IPv4v6 (Section 4.1) and IPv6 (Section 4.2). The + PDP/PDN request will fail because the APN in the home network only + allows IPv6. Therefore, the roaming APNs have to be compliant with + the home network configuration when home routed mode is adopted. + +4.4. Case 4: Fallback Failure + + In the local breakout mode, PDP/PDN Type IPv6 should have no issues + to pass through the network attachment process, since 3GPP specified + the PDP/PDN Type IPv6 as early as PDP/PDN Type IPv4. When a visitor + requests PDP/PDN Type IPv6, the network should only return the + expected IPv6 prefix. The UE may fail to get an IPv6 prefix if the + visited network only allocates an IPv4 address. In this case, the + visited network will reject the request and send the cause code to + the UE. + + A proper fallback scheme for PDP/PDN Type IPv6 is desirable; however, + there is no standard way to specify this behavior. The roaming APN + profile could help to address the issue by setting the PDP/PDN Type + to IPv4. For instance, the Android system solves the issue by + configuring the roaming protocol to IPv4 for the APN. It guarantees + that UE will always initiate a PDP/PDN Type IPv4 in the roaming area. + + + + + +Chen, et al. Informational [Page 11] + +RFC 7445 IPv6 Roaming Analysis March 2015 + + +5. Failure Cases in the Service Requests + + After the successful network attachment and IP address allocation, + applications could start to request service based on the activated + PDP/PDN context. The service request may depend on specific IP + family or network collaboration. If traffic is offloaded locally + (Section 2.1.2), the visited network may not be able to accommodate + the UE's service requests. This section describes the failures. + +5.1. Lack of IPv6 Support in Applications + + Operators may only allow IPv6 in the IMS APN. VoLTE [IR.92] and Rich + Communication Suite (RCS) [RCC.07] use the APN to offer voice service + for visitors. The IMS roaming in RAVEL architecture [IR.65] offloads + voice and video traffic in the visited network; therefore, a dual- + stack visitor can only be assigned with an IPv6 prefix but no IPv4 + address. If the applications can't support IPv6, the service is + likely to fail. + + Translation-based methods, for example, 464XLAT [RFC6877] or Bump-in- + the-Host (BIH) [RFC6535], may help to address the issue if there are + IPv6 compatibility problems. The translation function could be + enabled in an IPv6-only network and disabled in a dual-stack or IPv4 + network; therefore, the IPv4 applications only get the translation in + the IPv6 network and they perform normally in an IPv4 or dual-stack + network. + +5.2. 464XLAT Support + + 464XLAT [RFC6877] is proposed to address the IPv4 compatibility issue + in an IPv6-only connectivity environment. The customer-side + translator (CLAT) function on a mobile device is likely used in + conjunction with a PDP/PDN IPv6 Type request and cooperates with a + remote NAT64 [RFC6146] device. + + 464XLAT may use the mechanism defined in [RFC7050] or [RFC7225] to + detect the presence of NAT64 devices and to learn the IPv6 prefix + used for protocol translation [RFC6052]. + + In the local breakout approach, a UE with the 464XLAT function + roaming on an IPv6 visited network may encounter various situations. + For example, the visited network may not have deployed DNS64 + [RFC6147] but only NAT64, or CLAT may not be able to discover the + provider-side translator (PLAT) translation IPv6 prefix used as a + destination of the PLAT. If the visited network doesn't have a NAT64 + and DNS64 deployed, 464XLAT can't perform successfully due to the + + + + + +Chen, et al. Informational [Page 12] + +RFC 7445 IPv6 Roaming Analysis March 2015 + + + lack of PLAT collaboration. Even in the case of the presence of + NAT64 and DNS64, a pre-configured PLAT IPv6 prefix in the CLAT may + cause failure because it can't match the PLAT translation. + + Considering the various network configurations, operators may turn + off local breakout and use the home routed mode to perform 464XLAT. + Alternatively, UE may support the different roaming profile + configuration to adopt 464XLAT in the home network and use IPv4-only + in the visited networks. + +6. HLR/HSS User Profile Setting + + A proper user profile configuration would provide a deterministic + outcome to the PDP/PDN creation stage where dual-stack, IPv4-only, + and IPv6-only connectivity requests may come from devices. The + HLR/HSS may have to apply extra logic (not standardized by 3GPP) to + achieve this. It is also desirable that the network be able to set + up connectivity of any requested PDP/PDN context type. + + The following are examples to illustrate the settings for the + scenarios and the decision criteria to be applied when returning user + profile information from the HLR to the visited SGSN. + + 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 + .... + } + + Scenario 1: Support of IPv6-Only, IPv4-Only, and Dual-Stack Devices + + + + + + + + +Chen, et al. Informational [Page 13] + +RFC 7445 IPv6 Roaming Analysis March 2015 + + + The full PDP-context parameters are referred to Section 17.7.1 + ("Mobile Service data types") of [TS29.002]. User profiles #1 and #2 + share the same "ContextId". The setting of user profile #1 enables + IPv4-only and dual-stack devices to work. User profile #2 fulfills + the request if the device asks for IPv6-only PDP context. + + 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 + .... + } + + Scenario 2: Support of Dual-Stack Devices with Pre-Release 9 Visited + SGSN (vSGSN) Access + + User profiles #1 and #2 share the same "ContextId". If a visited + SGSN is identified as early as pre-Release 9, the HLR/HSS should only + send user profile #2 to the visited SGSN. + +7. Discussion + + Several failure cases have been discussed in this document. It has + been illustrated that the major problems happen at three stages: the + initial network attachment, the PDP/PDN creation, and service + requests. + + In the network attachment stage, PDP/PDN Type IPv4v6 is the major + concern to the visited pre-Release 9 SGSN. 3GPP didn't specify + PDP/PDN Type IPv4v6 in the earlier releases. That PDP/PDN Type is + supported in the newly built EPS network, but it isn't supported well + in the third-generation network. Visited SGSNs may discard the + subscriber's attach requests because the SGSN is unable to correctly + process PDP/PDN Type IPv4v6. Operators may have to adopt temporary + + + + + +Chen, et al. Informational [Page 14] + +RFC 7445 IPv6 Roaming Analysis March 2015 + + + solutions unless all the interworking nodes (i.e., the SGSN) in the + visited network have been upgraded to support the ext-PDP-Type + feature. + + In the PDP/PDN creation stage, support of PDP/PDN Types IPv4v6 and + IPv6 on the visited SGSN is the major concern. It has been observed + that single-stack IPv6 in the home routed mode is a viable approach + to deploy IPv6. It is desirable that the visited SGSN have the + ability to enable IPv6 on the user plane by default. For support of + the PDP/PDN Type IPv4v6, it is suggested to set the DAF. As a + complementary function, the implementation of a roaming APN + configuration is useful to accommodate the visited network. However, + it should consider roaming architecture and the permitted PDP/PDN + Type to properly set the UE. Roaming APN in the home routed mode is + recommended to align with home network profile setting. In the local + breakout case, PDP/PDN Type IPv4 could be selected as a safe way to + initiate PDP/PDN activation. + + In the service requests stage, the failure cases mostly occur in the + local breakout case. The visited network may not be able to satisfy + the requested capability from applications or UEs. Operators may + consider using home routed mode to avoid these problems. Several + solutions, in either the network side or mobile device side, can also + help to address the issue. For example, + + o 464XLAT could help IPv4 applications access IPv6 visited networks. + + o Networks can deploy a AAA server to coordinate the mobile device + capability. Once the GGSN/PGW receives the session creation + request, it will initiate a request to a AAA server in the home + network via the RADIUS or Diameter protocol [TS29.061]. The + request contains subscriber and visited network information, e.g., + PDP/PDN Type, International Mobile Equipment Identity (IMEI), + Software Version (SV) and visited SGSN/MME location code, etc. + The AAA server could take mobile device capability and combine it + with the visited network information to ultimately determine the + type of session to be created, i.e., IPv4, IPv6, or IPv4v6. + +8. Security Considerations + + Although this document defines neither a new architecture nor a new + protocol, the reader is encouraged to refer to [RFC6459] for a + generic discussion on IPv6-related security considerations. + + + + + + + + +Chen, et al. Informational [Page 15] + +RFC 7445 IPv6 Roaming Analysis March 2015 + + +9. References + +9.1. Normative References + + [IR.21] Global System for Mobile Communications Association + (GSMA), "Roaming Database, Structure and Updating + Procedures", IR.21, Version 7.4, November 2013. + + [IR.65] Global System for Mobile Communications Association + (GSMA), "IMS Roaming and Interworking Guidelines", IR.65, + Version 15.0, January 2015. + + [RFC6146] Bagnulo, M., Matthews, P., and I. van Beijnum, "Stateful + NAT64: Network Address and Protocol Translation from IPv6 + Clients to IPv4 Servers", RFC 6146, April 2011, + <http://www.rfc-editor.org/info/rfc6146>. + + [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, <http://www.rfc-editor.org/info/rfc6147>. + + [RFC6877] Mawatari, M., Kawashima, M., and C. Byrne, "464XLAT: + Combination of Stateful and Stateless Translation", RFC + 6877, April 2013, + <http://www.rfc-editor.org/info/rfc6877>. + + [TS23.060] 3GPP, "General Packet Radio Service (GPRS); Service + description; Stage 2 v9.00", TS 23.060, March 2009. + + [TS23.401] 3GPP, "General Packet Radio Service (GPRS) enhancements + for Evolved Universal Terrestrial Radio Access Network + (E-UTRAN) access v9.00", TS 23.401, March 2009. + + [TS29.002] 3GPP, "Mobile Application Part (MAP) specification + v9.12.0", TS 29.002, December 2009. + + [TS29.272] 3GPP, "Mobility Management Entity (MME) and Serving GPRS + Support Node (SGSN) related interfaces based on Diameter protocol + v9.00", TS 29.272, September 2009. + +9.2. Informative References + + [EU-Roaming-III] + Amdocs Inc., "Amdocs 2014 EU Roaming Regulation III + Solution", July 2013, <http://www.amdocs.com/Products/ + Revenue-Management/Documents/ + amdocs-eu-roaming-regulation-III-solution.pdf>. + + + +Chen, et al. Informational [Page 16] + +RFC 7445 IPv6 Roaming Analysis March 2015 + + + [IR.33] Global System for Mobile Communications Association + (GSMA), "GPRS Roaming Guidelines", IR.33, Version 7.0, + June 2014. + + [IR.34] Global System for Mobile Communications Association + (GSMA), "Guidelines for IPX Provider networks", IR.34 + Version 11.0, January 2015. + + [IR.88] Global System for Mobile Communications Association + (GSMA), "LTE Roaming Guidelines", IR.88, Version 12.0, + January 2015. + + [IR.92] Global System for Mobile Communications Association + (GSMA), "IMS Profile for Voice and SMS", IR.92, Version + 7.1, January 2015. + + [RCC.07] Global System for Mobile Communications Association + (GSMA), "Rich Communication Suite 5.2 Advanced + Communications Services and Client Specification", RCC.07, + Version 5.0, May 2014. + + [RFC6052] Bao, C., Huitema, C., Bagnulo, M., Boucadair, M., and X. + Li, "IPv6 Addressing of IPv4/IPv6 Translators", RFC 6052, + October 2010, <http://www.rfc-editor.org/info/rfc6052>. + + [RFC6459] Korhonen, J., Ed., Soininen, J., Patil, B., Savolainen, + T., Bajko, G., and K. Iisakkila, "IPv6 in 3rd Generation + Partnership Project (3GPP) Evolved Packet System (EPS)", + RFC 6459, January 2012, + <http://www.rfc-editor.org/info/rfc6459>. + + [RFC6535] Huang, B., Deng, H., and T. Savolainen, "Dual-Stack Hosts + Using "Bump-in-the-Host" (BIH)", RFC 6535, February 2012, + <http://www.rfc-editor.org/info/rfc6535>. + + [RFC7050] Savolainen, T., Korhonen, J., and D. Wing, "Discovery of + the IPv6 Prefix Used for IPv6 Address Synthesis", RFC + 7050, November 2013, + <http://www.rfc-editor.org/info/rfc7050>. + + [RFC7225] Boucadair, M., "Discovering NAT64 IPv6 Prefixes Using the + Port Control Protocol (PCP)", RFC 7225, May 2014, + <http://www.rfc-editor.org/info/rfc7225>. + + [TR23.975] 3GPP, "IPv6 migration guidelines", TR 23.975, June 2011. + + [TS23.003] 3GPP, "Numbering, addressing and identification v9.0.0", + TS 23.003, September 2009. + + + +Chen, et al. Informational [Page 17] + +RFC 7445 IPv6 Roaming Analysis March 2015 + + + [TS24.008] 3GPP, "Mobile radio interface Layer 3 specification; Core + network protocols; Stage 3 v9.00", TS 24.008, September + 2009. + + [TS24.301] 3GPP, "Non-Access-Stratum (NAS) protocol for Evolved + Packet System (EPS) ; Stage 3 v9.00", TS 24.301, September + 2009. + + [TS29.061] 3GPP, "Interworking between the Public Land Mobile Network + (PLMN) supporting packet based services and Packet Data + Networks (PDN) v9.14.0", TS 29.061, January 2015. + + [TS29.212] 3GPP, "Policy and Charging Control (PCC); Reference points + v9.0.0", TS 29.212, September 2009. + +Acknowledgements + + Many thanks to F. Baker and J. Brzozowski for their support. + + This document is the result of the IETF v6ops IPv6-Roaming design + team effort. + + The authors would like to thank Mikael Abrahamsson, Victor Kuarsingh, + Nick Heatley, Alexandru Petrescu, Tore Anderson, Cameron Byrne, + Holger Metschulat, and Geir Egeland for their helpful discussions and + comments. + + The authors especially thank Fred Baker and Ross Chandler for their + efforts and contributions that substantially improved the readability + of the document. + +Contributors + + The following individual contributed to this document. + + Vizdal Ales + Deutsche Telekom AG + Tomickova 2144/1 + Prague 4, 149 00 + Czech Republic + + EMail: ales.vizdal@t-mobile.cz + + + + + + + + + +Chen, et al. Informational [Page 18] + +RFC 7445 IPv6 Roaming Analysis March 2015 + + +Authors' Addresses + + Gang Chen + China Mobile + 53A,Xibianmennei Ave., + Xicheng District, + Beijing 100053 + China + + EMail: phdgang@gmail.com, chengang@chinamobile.com + + + Hui Deng + China Mobile + 53A,Xibianmennei Ave., + Xuanwu District, + Beijing 100053 + China + + EMail: denghui@chinamobile.com + + + Dave Michaud + Rogers Communications + 8200 Dixie Rd. + Brampton, ON L6T 0C1 + Canada + + EMail: dave.michaud@rci.rogers.com + + + Jouni Korhonen + Broadcom Corporation + 3151 Zanker Rd. + San Jose, CA 95134 + United States + + EMail: jouni.nospam@gmail.com + + + Mohamed Boucadair + France Telecom + Rennes, + 35000 + France + + EMail: mohamed.boucadair@orange.com + + + + +Chen, et al. Informational [Page 19] + |