Network Working Group G. Chen Internet-Draft H. Deng Intended status: Informational China Mobile Expires: February 10, 2015 D. Michaud Rogers Communications J. Korhonen Renesas Mobile M. Boucadair France Telecom A. Vizdal Deutsche Telekom AG August 9, 2014 IPv6 Roaming Behavior Analysis draft-ietf-v6ops-ipv6-roaming-analysis-03 Abstract This document identifies a set of failure cases that may be encountered by IPv6-enabled mobile customers in roaming scenarios. The investigations on those failed cases reveal the causes in order to notice improper configurations, equipment's incomplete functions or inconsistent IPv6 introduction strategy. Status of This Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at http://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." This Internet-Draft will expire on February 10, 2015. Copyright Notice Copyright (c) 2014 IETF Trust and the persons identified as the document authors. All rights reserved. Chen, et al. Expires February 10, 2015 [Page 1] Internet-Draft IPv6 Roaming Analysis August 2014 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 . . . . . . . . . . . . . . . . . . . . . . . . 2 2. Roaming Architecture Description . . . . . . . . . . . . . . 3 2.1. Home Routed Mode . . . . . . . . . . . . . . . . . . . . 3 2.2. Local Breakout Mode . . . . . . . . . . . . . . . . . . . 4 3. Roaming Scenario . . . . . . . . . . . . . . . . . . . . . . 5 4. Failure Case in Attachment Stage . . . . . . . . . . . . . . 6 5. Failure Cases in PDP/PDN Creation . . . . . . . . . . . . . . 7 5.1. Case 1: Splitting Dual-stack Bearer . . . . . . . . . . . 7 5.2. Case 2: Lack of IPv6 support in applications . . . . . . 8 5.3. Case 3: Fallback Incapability . . . . . . . . . . . . . . 9 5.4. Case 4: 464xlat Support . . . . . . . . . . . . . . . . . 9 6. HLR/HSS User Profile Setting . . . . . . . . . . . . . . . . 9 7. Discussion . . . . . . . . . . . . . . . . . . . . . . . . . 11 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12 9. Security Considerations . . . . . . . . . . . . . . . . . . . 12 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 13 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 13 11.1. Normative References . . . . . . . . . . . . . . . . . . 13 11.2. Informative References . . . . . . . . . . . . . . . . . 13 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 15 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. A detailed overview of IPv6 support in 3GPP architectures is provided in [RFC6459]. Operators may adopt various approaches to deploy IPv6 in mobile networks, for example the solutions described in [TR23.975]). Depending on network conditions either dual-stack or single-stack IPv6 is selected. In production networks, it has been observed that a mobile subscriber roaming around a different operator's areas may experience service degradation or interruptions due to inconsistent configurations and incomplete functionality of equipment in the network. Chen, et al. Expires February 10, 2015 [Page 2] Internet-Draft IPv6 Roaming Analysis August 2014 2. Roaming Architecture Description Roaming occurs in two scenarios: o International roaming: a mobile UE may enter a visited network, where a different Public Land Mobile Network (PLMN) identity is used. The UEs could, either in an automatic mode or a manual mode, attach to the visited PLMN. o Intra-PLMN mobility: a mobile UE moves to a different area of the Home Public Land Mobile Network (HPLMN). However, the subscriber profile may not be stored in the area. To allow network attachment the subscribers profile needs to be downloaded from the home network area. 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 Public Land Mobile Networks (PLMNs) to attach to. The Serving GPRS Support Node (SGSN) or the Mobility Management Entity (MME) in the visited networks must contact the Home Location Register(HLR) or Home Subscriber Server(HSS) and obtain the subscriber profile. After the authentication and registration process 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 HLR or HSS. There are two roaming modes illustrated below, i.e. "Home routed traffic" (Figure 1) and "Local breakout" (Figure 2). 2.1. Home Routed Mode 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 routed back to the home network. This is likely to be the case international roaming of Internet data services to facilitate the 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 Chen, et al. Expires February 10, 2015 [Page 3] Internet-Draft IPv6 Roaming Analysis August 2014 2.2. Local Breakout Mode In the local breakout mode, the subscriber address is assigned by the visited network. The traffic flow is directly offloaded locally at a network node close to that device's point of attachment in the visited network. Therefore,a more efficient route to the data service is achieved. The international roaming of IP Multimedia Subsystem (IMS) based services, e.g. Voice over LTE (VoLTE)[IR.92] , is claimed to select the local breakout mode in [IR.65]. Data service roaming across different areas within an operator network might use local breakout mode in order to get more efficient traffic routing. The local breakout mode could be also 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 can choose to have their Internet data routed directly to the Internet from their current VPLMN. +----------------------------+ +----------------+ |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 [TS29.272] into 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 profile to enable local breakout mode in a Visited Public Land Mobile Networks (VPLMNs). Chen, et al. Expires February 10, 2015 [Page 4] Internet-Draft IPv6 Roaming Analysis August 2014 o 3GPP specified Selected IP Traffic Offload (SIPTO) function[TS23.401] since Release 10 in order to get efficient route paths. It enables an operator to offload certain types of traffic at a network node close to that device's point of attachment to the access network. o GSMA has defined RAVEL[IR.65] as the IMS international roaming architecture. Local breakout mode has been adopted for the IMS roaming architecture. 3. Roaming Scenario Two stages occur when a subscriber roams to a visited network and intends to start data services. o Network attachment: this occurs when the subscriber enters a visited network. During an attachment, 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 Access Point Names (APN), the allowed PDP/PDN Types and rules regarding the routing of data sessions (i.e. home routed or 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 makes a successful attachment. This stage is integrated with the attachment stage in the case of 4G, but is a seperate process in 2/3G. 3GPP specifies three types of Packet Data Protocol (PDP)/Packet Data Networks (PDN) to describe connections, i.e. 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, SGSN/MME could initiate PDP/PDN request to GGSN/PGW if the subscription profile is allowed. In both stages, the failure cases described are likely to occur due to an incompliant implementation in the visited network or a mismatch between the subscriber requested and the capability of the visited network. The failures described in the attachment stage are independent of home routed or the local breakout mode. Most failure cases in the PDP/PDN context creation stage occur in the local breakout mode. Section 4 and 5 describe each case. Chen, et al. Expires February 10, 2015 [Page 5] Internet-Draft IPv6 Roaming Analysis August 2014 4. Failure Case in Attachment Stage 3GPP specified PDP/PDN type IPv4v6 in order to allow a UE get both 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/ HSS. PDP/PDN type IPv4v6 has been introduced at the inception of Evolved Packet System (EPS) in 4G networks. The nodes in 4G networks should present no issues with the handling of this PDN type. However, support varies in 2/3G networks depending on Serving GPRS Support Node (SGSN) software version. In theory, S4-SGSN (i.e. an 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 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 the IPv4v6 PDP Type, it will not support the "ext-pdp-Type" IE and consequently it must silently discard that IE and continue processing of the rest of the ISD MAP message. The issue we observe is that multiple SGSNs will be unable to correctly process a subscriber's data received in the Insert Subscriber Data Procedure[TS23.060]. As a consequence, it will likely refuse the subscriber attach request. 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 the HLR/HSS in the home network, that will restrict UEs to only initiate IPv4 PDP or IPv6 PDP activation. In order to avoid this situation, 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 their SGSN nodes to support PDP/PDN type IPv4v6. As an alternative solution there are some specific implementations (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 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 Data procedure. It guarantees the user profile is compatible with visited SGSN/MME capability. Chen, et al. Expires February 10, 2015 [Page 6] Internet-Draft IPv6 Roaming Analysis August 2014 5. Failure Cases in PDP/PDN Creation When a subscriber succeeds in the attach stage, the IP allocation process takes place to allocate IP addresses to the subscriber. In 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 Dual-stack capability can be provided using separate PDP/PDN activation. That means only separate parallel single-stack IPv4 and IPv6 PDP/PDN connections are allowed to be initiated to separately allocate IPv4 and IPv6 addresses. 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 or PDP type" as per[TS24.008] and [TS24.301]. o The SGSN/MME does not set the Dual Address Bearer Flag (DAF) because the operator uses single addressing per bearer to support interworking with nodes of earlier releases 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 in order to achieve equivalent results. Some drawbacks of this case are listed as below: Chen, et al. Expires February 10, 2015 [Page 7] Internet-Draft IPv6 Roaming Analysis August 2014 o The parallel PDP/PDN activation would likely double PDP/PDN resources consumption. It also impacts the capacity of GGSN/PGW, since a certain amount of PDP/PDN activation is only allowed on those nodes. 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 has an active IPv4 PDP/PDN. Therefore, the subscriber 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 the IPv6 PDP gets rejected with a permanent error at the APN-level and not specific to the PDP-Type IPv6 requested. o Additional correlations between those two PDP/PDN contexts are required on the charging system. o Policy and Charging Rules Function(PCRF)/Policy and Charging Enforcement Function (PCEF) treats the IPv4 and IPv6 session as independent and performs different Quality of Service (QoS) policies. The subscriber may have unstable experiences due to different behaviors on each IP version connection. o Mobile devices may have a limitation on allowed simultaneous PDP/ PDN activation. Excessive PDP/PDN activation may result in other unrelated services broken. Operators may have to disable the local-break mode to avoid the risks. Another approach is to set a dedicated Access Point Name (APN) profile to only request PDP/PDN type IPv4 in the roaming network. 5.2. Case 2: Lack of IPv6 support in applications Some operators may adopt an IPv6-only configuration for the IMS service, e.g. Voice over LTE (VoLTE)[IR.92] or Rich Communication Suite (RCS)[RCC.07]. Since the IMS roaming architecture will offload all traffic in the visited network, a dual-stack subscriber can only be assigned with an IPv6 prefix and no IPv4 address returned. This requires that all the IMS based applications should be IPv6 capable. A translation-based method, for example Bump-in-the-host (BIH)[RFC6535] or 464xlat [RFC6877] may help to address the issue if there are IPv6 compatibility problems. Those functions could be automatically enabled in an IPv6-only network and disabled in a dual- stack or IPv4 network. Chen, et al. Expires February 10, 2015 [Page 8] Internet-Draft IPv6 Roaming Analysis August 2014 5.3. Case 3: Fallback Incapability 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 interpretable in the 3GPP network nodes. Roaming to IPv4-only networks and making an IPv6 PDP/PDN request could guarantee that the subscription data is compatible with the visited pre-Release 9 SGSN. When a subscriber requests PDP/PDN type IPv6, the network should only return the expected IPv6 prefix. The mobile device may fail to get 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 cause code should be sent to the user. A proper fallback is desirable, however the behavior is implementation specific. There are some mobile devices have the ability to provide a different configuration for home network and visited network respectively. For instance, the Android system solves the issue by setting the roaming protocol to IPv4 for the 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 464xlat[RFC6877] is proposed to address the IPv4 compatibility issue in an IPv6 single-stack environment. The function on a mobile device is likely in conjunction with a PDP/PDN IPv6 type request and cooperates with a remote NAT64[RFC6146] gateway. 464xlat may use the mechanism defined in [RFC7050] to automatically detect the presence of DNS64 and to learn the IPv6 prefix used for protocol translation. In the local breakout approach when a mobile device with 464xlat function roams to an IPv6 visited network without the presence of NAT64 or DNS64, 464xlat will fail to function. The issue has been found mostly in intra-PLMN mobility cases for the time being. Considering the various network's situations, operators may turn off the local breakout and use the home routed mode to perform 464xlat. Some devices may support the configuration to adopt 464xlat in the home networks and use IPv4-only in the visited networks with different roaming profile configurations. This could also be a solution to address this issue. 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 to achieve this. It's also desirable Chen, et al. Expires February 10, 2015 [Page 9] Internet-Draft IPv6 Roaming Analysis August 2014 that the network could set-up connectivity of any requested PDP/PDN context type. 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 referred 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. Chen, et al. Expires February 10, 2015 [Page 10] Internet-Draft IPv6 Roaming Analysis August 2014 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, the HLR/HSS should only send user profile#2 to visited SGSN. 7. Discussion Several failure cases have been discussed in this document. It has been testified that the major issues happened at two stages, i.e., the initial network attachment and the IP allocation process. During the initial network attach, 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 early release. Such PDP/PDN type is supported in new-built EPS network, but didn't support well in the third generation network. The situations may cause the roaming issues dropping with the attach request from dual-stack subscribers. Operators may have to adopt temporary solution unless all the interworking nodes(i.e. the SSGN) in the visited network have been upgraded to support the ext-PDP-Type feature. PDP/PDN type IPv6 has good compatibility to visited networks during the network attachment. It has been observed that IPv6 single stack 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 Chen, et al. Expires February 10, 2015 [Page 11] Internet-Draft IPv6 Roaming Analysis August 2014 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 PDP/PDN type o The mismatch between the application capability and allowed network connections o The mismatch between mobile device function (e.g., 464xlat) and the support for that function in the visited network There are some solutions to overcome the issue. Those solutions can be made either in the network side or mobile device side. o Change local breakout to the home routed mode o A dedicated roaming APN profile is implemented for the roamer. When a subscriber roams to a visited network, PDP/PDN type IPv4 is to be always selected for session activation. o Networks could deploy an AAA server to coordinate the mobile device capability. Once the GGSN/PGW receives the session creation request, it will initiate an Access-Request to an AAA server in the home network via the Radius protocol. The Access- Request contains subscriber and visited network information, e.g. PDP/PDN Type, International Mobile Equipment Id (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. IANA Considerations This document makes no request of IANA. 9. Security Considerations Although this document defines neither a new architecture nor a new protocol, it is encouraged to refer to [RFC6459] for a generic discussion on IPv6-related security considerations. Chen, et al. Expires February 10, 2015 [Page 12] Internet-Draft IPv6 Roaming Analysis August 2014 10. 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, Heatley Nick, Alexandru Petrescu, Tore Anderson, Cameron Byrne and Holger Metschulat for their helpful comments. The authors especially thank Fred Baker and Ross Chandler for his efforts and contributions on editing which substantially improves the legibility of the document. 11. References 11.1. Normative References [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. [RFC6535] Huang, B., Deng, H., and T. Savolainen, "Dual-Stack Hosts Using "Bump-in-the-Host" (BIH)", RFC 6535, February 2012. [RFC6877] Mawatari, M., Kawashima, M., and C. Byrne, "464XLAT: Combination of Stateful and Stateless Translation", RFC 6877, April 2013. [RFC7050] Savolainen, T., Korhonen, J., and D. Wing, "Discovery of the IPv6 Prefix Used for IPv6 Address Synthesis", RFC 7050, November 2013. 11.2. Informative References [EU-Roaming-III] "http://www.amdocs.com/Products/Revenue- Management/Documents/ amdocs-eu-roaming-regulation-III-solution.pdf", July 2013. [IR.21] Global System for Mobile Communications Association, GSMA., "Roaming Database, Structure and Updating Procedures", July 2012. [IR.33] Global System for Mobile Communications Association, GSMA., "GPRS Roaming Guidelines", July 2012. Chen, et al. Expires February 10, 2015 [Page 13] Internet-Draft IPv6 Roaming Analysis August 2014 [IR.65] Global System for Mobile Communications Association, GSMA., "IMS Roaming & Interworking Guidelines", May 2012. [IR.88] Global System for Mobile Communications Association, GSMA., "LTE Roaming Guidelines", January 2012. [IR.92] Global System for Mobile Communications Association (GSMA), , "IMS Profile for Voice and SMS Version 7.0", March 2013. [RCC.07] Global System for Mobile Communications Association (GSMA), , "Rich Communication Suite 5.1 Advanced Communications Services and Client Specification Version 4.0", November 2013. [RFC6459] Korhonen, J., 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. [TR23.975] 3rd Generation Partnership Project, 3GPP., "IPv6 migration guidelines", June 2011. [TS23.060] 3rd Generation Partnership Project, 3GPP., "General Packet Radio Service (GPRS); Service description; Stage 2 v9.00", March 2009. [TS23.401] 3rd Generation Partnership Project, 3GPP., "General Packet Radio Service (GPRS) enhancements for Evolved Universal Terrestrial Radio Access Network (E-UTRAN) access v9.00", March 2009. [TS24.008] 3rd Generation Partnership Project, 3GPP., "Mobile radio interface Layer 3 specification; Core network protocols; Stage 3 v9.00", September 2009. [TS24.301] 3rd Generation Partnership Project, 3GPP., "Non-Access- Stratum (NAS) protocol for Evolved Packet System (EPS) ; Stage 3 v9.00", September 2009. Chen, et al. Expires February 10, 2015 [Page 14] Internet-Draft IPv6 Roaming Analysis August 2014 [TS29.002] 3rd Generation Partnership Project, 3GPP., "Mobile Application Part (MAP) specification v9.12.0", December 2009. [TS29.272] 3rd Generation Partnership Project, 3GPP., "Mobility Management Entity (MME) and Serving GPRS Support Node (SGSN) related interfaces based on Diameter protocol v9.00", September 2009. Authors' Addresses Gang Chen China Mobile 53A,Xibianmennei Ave., Xuanwu District, Beijing 100053 China Email: phdgang@gmail.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 Renesas Mobile Porkkalankatu 24 FIN-00180 Helsinki, Finland Email: jouni.nospam@gmail.com Chen, et al. Expires February 10, 2015 [Page 15] Internet-Draft IPv6 Roaming Analysis August 2014 Mohamed Boucadair France Telecom Rennes, 35000 France Email: mohamed.boucadair@orange.com Vizdal Ales Deutsche Telekom AG Tomickova 2144/1 Prague 4, 149 00 Czech Republic Email: ales.vizdal@t-mobile.cz Chen, et al. Expires February 10, 2015 [Page 16]