idnits 2.17.1 draft-ietf-v6ops-ipv6-roaming-analysis-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** There are 20 instances of too long lines in the document, the longest one being 4 characters in excess of 72. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (July 4, 2014) is 3556 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Unused Reference: 'RFC2119' is defined on line 479, but no explicit reference was found in the text == Unused Reference: 'RFC6052' is defined on line 482, but no explicit reference was found in the text == Unused Reference: 'RFC6147' is defined on line 490, but no explicit reference was found in the text == Unused Reference: 'RFC6586' is defined on line 540, but no explicit reference was found in the text Summary: 1 error (**), 0 flaws (~~), 5 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group G. Chen 3 Internet-Draft H. Deng 4 Intended status: Informational China Mobile 5 Expires: January 5, 2015 D. Michaud 6 Rogers Communications 7 J. Korhonen 8 Renesas Mobile 9 M. Boucadair 10 France Telecom 11 A. Vizdal 12 Deutsche Telekom AG 13 July 4, 2014 15 IPv6 Roaming Behavior Analysis 16 draft-ietf-v6ops-ipv6-roaming-analysis-01 18 Abstract 20 This document identifies a set of failure cases encountered by an 21 IPv6-enabled IPv6 customers in roaming scenarios. The investigations 22 on those failed cases reveal the causes in order to notice improper 23 configurations, equipment's incomplete functions or inconsistent IPv6 24 introduction strategy. 26 Status of This Memo 28 This Internet-Draft is submitted in full conformance with the 29 provisions of BCP 78 and BCP 79. 31 Internet-Drafts are working documents of the Internet Engineering 32 Task Force (IETF). Note that other groups may also distribute 33 working documents as Internet-Drafts. The list of current Internet- 34 Drafts is at http://datatracker.ietf.org/drafts/current/. 36 Internet-Drafts are draft documents valid for a maximum of six months 37 and may be updated, replaced, or obsoleted by other documents at any 38 time. It is inappropriate to use Internet-Drafts as reference 39 material or to cite them other than as "work in progress." 41 This Internet-Draft will expire on January 5, 2015. 43 Copyright Notice 45 Copyright (c) 2014 IETF Trust and the persons identified as the 46 document authors. All rights reserved. 48 This document is subject to BCP 78 and the IETF Trust's Legal 49 Provisions Relating to IETF Documents 50 (http://trustee.ietf.org/license-info) in effect on the date of 51 publication of this document. Please review these documents 52 carefully, as they describe your rights and restrictions with respect 53 to this document. Code Components extracted from this document must 54 include Simplified BSD License text as described in Section 4.e of 55 the Trust Legal Provisions and are provided without warranty as 56 described in the Simplified BSD License. 58 Table of Contents 60 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 61 2. Roaming Architecture Description . . . . . . . . . . . . . . 3 62 3. Roaming Scenario . . . . . . . . . . . . . . . . . . . . . . 5 63 4. Failure Case in Attachment Stage . . . . . . . . . . . . . . 6 64 5. Failure Cases in PDP/PDN Creation . . . . . . . . . . . . . . 7 65 5.1. Case 1: Splitting Dual-stack Bearer . . . . . . . . . . . 7 66 5.2. Case 2: Lack of IPv6 support in applications . . . . . . 8 67 5.3. Case 3: Fallback Incapability . . . . . . . . . . . . . . 8 68 5.4. Case 4: 464xlat Support . . . . . . . . . . . . . . . . . 9 69 6. Discussions . . . . . . . . . . . . . . . . . . . . . . . . . 9 70 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 71 8. Security Considerations . . . . . . . . . . . . . . . . . . . 10 72 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 10 73 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 11 74 10.1. Normative References . . . . . . . . . . . . . . . . . . 11 75 10.2. Informative References . . . . . . . . . . . . . . . . . 11 76 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 13 78 1. Introduction 80 Many Mobile Operators deployed or are in a per-deployment stage of 81 IPv6 in their operational networks. Customers will be delivered with 82 IPv6 connectivity if their User Equipment (UE) are IPv6-compliant. A 83 detailed overview of IPv6 support in 3GPP architectures is provided 84 in [RFC6459]. Operators may adopt various approaches to deploy IPv6 85 in mobile networks, for example the solutions described in 86 [TR23.975]). Dual-stack or IPv6 single-stack has been selected 87 depending on network's conditions. It has been observed that a 88 mobile subscriber roaming around different operator's areas may 89 experience service degradations or interruptions due to the 90 inconsistent configurations and incomplete functions on the networks 91 nodes. 93 This memo intends to document the observed failed cases and analyze 94 the causes. 96 2. Roaming Architecture Description 98 The roaming process has been occurred in the following scenarios: 100 o International roaming: a mobile UE may entry a visited network, 101 where different Public Land Mobile Network (PLMN) identity is 102 used. UEs could, either in an automatic mode or a manual mode, 103 attach to the visited PLMN. 105 o Intra-PLMN mobility: a UE moves to a visited network as that of 106 the Home Public Land Mobile Network (HPLMN). However, the 107 subscriber profiles may not be stored in the area. Once the 108 subscriber attached to the network, the subscriber profile should 109 be extracted from the home network for the network attachment. 111 When a UE is turned on or is transferred via a handover to a visited 112 network, the mobile device will scan all radio channels and find 113 available Public Land Mobile Networks (PLMNs) to attach. Serving 114 GPRS Support Node (SGSN) or Mobility Management Entity (MME) in the 115 visited networks must contact the Home Location Register(HLR) or Home 116 Subscriber Server(HSS) and obtain the subscriber profile. Once the 117 authentication and registration process is completed, the Packet Data 118 Protocol (PDP) or Packet Data Networks (PDN) activation and traffic 119 flows may be operated differently according to the subscriber profile 120 stored in HLR or HSS. Two modes have been shown at the figure to 121 illustrate, that are "Home routed traffic" (Figure 1) and "Local 122 breakout" (Figure 2). 124 +---------------------------------+ +------------------------+ 125 |Visited Network | |Home Network | 126 | +----+ +--------+ | | +--------+ Traffic Flow 127 | | UE |==========>|SGSN/MME|======================>|GGSN/PGW|============> 128 | +----+ +--------+ | Signaling | +--------+ | 129 | |-------------------------->+--------+ | 130 | | | |HLR/HSS | | 131 | | | +--------+ | 132 +---------------------------------+ +------------------------+ 134 Figure 1: Home Routed Traffic 136 +---------------------------------+ +------------------------+ 137 |Visited Network | |Home Network | 138 | +----+ +--------+ | Signaling | +--------+ | 139 | | UE |==========>|SGSN/MME|---------------------->|HLR/HSS | | 140 | +----+ +--------+ | | +--------+ | 141 | || | | | 142 | +--------+ | | | 143 | |GGSN/PGW| | | | 144 | +--------+ | | | 145 | Traffic Flow || | | | 146 +-----------------------||--------+ +------------------------+ 147 \/ 149 Figure 2: Local Breadkout 151 In the home routed mode, subscribers will activate the PDP/PDN 152 context and get address from the home network. All traffic would be 153 routed back to the home networks. It's likely most cases for 154 international roaming of Internet data services to facilitate the 155 charging process between two operators. 157 In the local breakout mode, the subscriber address will be assigned 158 from the visited network. The traffic flow is directly offloaded 159 locally at a network node close to that device's point of attachment 160 in the visited networks. Therefore, more efficient route is 161 achieved. The international roaming of IP Multimedia Subsystem (IMS) 162 based services, e.g. Voice over LTE (VoLTE)[IR.92] , is claimed to 163 select the local breakout mode in [IR.65]. Data service roaming 164 across different areas within a operator network could use local 165 breakout mode in order to get efficient traffic route. The local 166 breakout mode could be also applied to an operators alliance for 167 international roaming of data service. EU Roaming Regulation 168 III[EU-Roaming-III] involves local breakout mode allowing european 169 subscribers roaming in european 2G/3G networks can choose to have 170 their Internet data routed directly to the Internet from their 171 current VPLMN. The following enumerates the more specific 172 configuration considerations. 174 o Operators may add the APN-OI-Replacement flag defined in 3GPP 175 [TS29.272] into user's subscription-data. The visited network 176 indicates a local domain name to replace the user requested Access 177 Point Name (APN). As the consequence, the traffic would be 178 steered to the visited network. Those functions are normally 179 deployed for the Intra-PLMN mobility cases. 181 o Operators could also configure VPLMN-Dynamic-Address-Allowed 182 flag[TS29.272] in the user profile to enable local breakout mode 183 in Visited Public Land Mobile Networks (VPLMNs). 185 o 3GPP specified Selected IP Traffic Offload (SIPTO) 186 function[TS23.401] since Release 10 in order to get efficient 187 route paths. It enables an operator to offload certain types of 188 traffic at a network node close to that device's point of 189 attachment to the access network. 191 o GSMA has defined RAVEL[IR.65] as IMS international roaming 192 architecture. Local breakout mode has been adopted for the 193 roaming architecture. 195 3. Roaming Scenario 197 There are two stages happened when a subscriber roams to a visited 198 network and intends to start data services. 200 o Nework attachment: it's occurred once the subsriber enters a 201 visited network. During an attachment, the visited network should 202 authenticate the subsriber and make location update to the HSS/HLR 203 in the home network of the subsriber. Accordingly, the subscriber 204 profile is offered from the HSS/HLR. The subscriber profile 205 contains the allowed Access Point Names (APN), allowed PDP/PDN 206 Types and rules regarding the routing of data sessions (i.e. home 207 routed or local breakout mode) [TS29.272]. SGSN/MME in the 208 visited network could use those informaiton to facilitate the 209 subsequent PDP/PDN session creation. 211 o PDP/PDN context creation: it's occurred after the subsriber makes 212 a sucessful attachment. It's worth nothing that this stage is 213 integrated with the attachment stage in the case of 4G, but a 214 seperated process in 2/3G. 3GPP specifies three types of Packet 215 Data Protocol (PDP)/Packet Data Networks (PDN) to describe 216 connections, i.e., PDP/PDN Type IPv4, PDP/PDN Type IPv6 and PDP/ 217 PDN Type IPv4v6. When a subsriber creates a data session, a user 218 device is configured to request a particular PDP/PDN Type. The 219 allowed PDP/PDN types for the subscriber are learned from the 220 attachment stage. Hence, SGSN/MME could initiate PDP/PDN request 221 to GGSN/PGW if the subscription profile is allowed. 223 The failures are likely happened in both stages due to an incompliant 224 implementation or mismatch between the subscriber requested and the 225 visited network capability. The failures in the attachment stage is 226 independent with home routed and local breakout mode, while most 227 failure cases in the PDP/PDN context creation stage are appeared in 228 the local breakout cases. Section 4 and 5 make further descriptions 229 for each cases. The below table lists the several cases regarding 230 the PDP/PDN creation stage. 232 +-------------+-------------------+--------------+ 233 | UE request | PDN/PDP IP Type |Local breakout| 234 | | permitted | | 235 +-------------+-------------------+--------------+ 236 | IPv4v6 | IPv4 or IPv6 |Failure case 1| 237 +-------------+-------------------+--------------+ 238 | IPv4v6 | IPv6 |Failure case 2| 239 +-------------+-------------------+--------------+ 240 | IPv6 | IPv4 |Failure case 3| 241 +-------------+-------------------+--------------+ 242 | IPv6 | IPv6 |Failure case 4| 243 | with 464xlat| without NAT64 | | 244 +-------------+-------------------+--------------+ 246 Table 1: Roaming Scenario Descriptions 248 4. Failure Case in Attachment Stage 250 3GPP specified PDP/PDN type IPv4v6 in order to allow a UE requesting 251 both IPv4 and IPv6 within a single PDP/PDN request. This feature is 252 stored as a part of subscription data for a subscriber in the HLR/ 253 HSS. PDP/PDN type IPv4v6 is introduced since the inception of 254 Evolved Packet System (EPS) in 4G network. The nodes in 4G networks 255 should no issues with the handling of this PDN type. However, it's 256 of varing supports in 2/3G networks denpending on Serving GPRS 257 Support Node (SGSN) software version. In theory, S4-SGSN (i.e., the 258 SGSN with S4 interface) support the PDP/PDN type IPv4v6 since 259 Release8 and Gn-SGSN (i.e., the SGSN with Gn interface) support it 260 since Release 9. In most cases, operators normally use Gn-SGSN to 261 connect either GGSN in 3G or Packet Data Network Gateway (PGW) in 4G. 262 The MAP (Mobile Application Part) protocol, as defined in 3GPP 263 [TS29.002], is used over the Gr interface between SGSN and HLR. The 264 MAP Information Element (IE) "ext-pdp-Type" contains the IPv4v6 PDP 265 Type is conveyed to SGSN from HLR within the Insert Subscriber Data 266 (ISD) MAP operation. If the SGSN does not support the IPv4v6 PDP 267 Type, it will not support the "ext-pdp-Type" IE and consequently must 268 silently discard that IE and continue processing of the rest of the 269 ISD MAP message. The issue we observe is that multiple SGSNs will be 270 unable to correctly process a subscriber data received in the Insert 271 Subscriber Data procedure[TS23.060]. As a consequence , it will 272 likely refuse the subscriber attach request, which is erroneous 273 behaviour as they are not 3GPP compliant. 275 Operators may have to remove the PDP/PDN type IPv4v6 from HLR/HSS in 276 the home network, that will restrict UEs only initiates IPv4 PDP or 277 IPv6 PDP activation. In order to avoid this situation, operators 278 should make a comprehensive roaming agreement to support IPv6 and 279 ensure that aligns with GSMA document, e.g [IR.33], [IR.88] and 281 [IR.21]. The agreement requires visited operators to get necessary 282 patch on all SGSN nodes to support PDP/PDN type IPv4v6. 284 There are some specific implementation in HLS/HSS of home network as 285 an alternative solution. Once the HLR/HSS receives an Update 286 Location message from visited SGSN known to not support the PDP type 287 IPv4v6, only the subscription data with PDP/PDN type IPv4 will be 288 sent to SGSN in the Insert Subscriber Data procedure. It guarantee 289 the user profile could compatible with visited SGSN/MME capability. 291 5. Failure Cases in PDP/PDN Creation 293 Once a subscriber succeed in the attach stage, IP allocation process 294 is taken place to allocate IP addresses to the subscriber. This 295 section has summarized several failures in the break-out cases. 297 5.1. Case 1: Splitting Dual-stack Bearer 299 Dual-stack capability can be provided using separate PDP/PDN 300 activations. That means only a single IPv4 and IPv6 PDP/PDN is 301 allowed to be initiated to allocate IPv4 and IPv6 address separately. 302 The below lists the cases. 304 o The SGSN/MME returns Session Manamgement (SM) Cause #52, "Single 305 address bearers only allowed", or SM Cause #28 "Unknown PDP 306 address or PDP type" as per[TS24.008] and [TS24.301]. 308 o The SGSN/MME does not set the Dual Address Bearer Flag due to the 309 operator using single addressing per bearer to support 310 interworking with nodes of earlier releases 312 A roaming subscriber with IPv4v6 PDP/PDN type have to change the 313 request into two separated PDP/PDN requests with single IP version in 314 order to achieve equivalent results. Some drawbacks in this case are 315 listed as following: 317 o The parallel PDP/PDN activations would likely double PDP/PDN 318 resources consumptions. It impacts the capacity of GGSN/PGW, 319 since a certain amount of PDP/PDN activations are only allowed on 320 those nodes. 322 o Some networks may only allow one PDP/PDN is alive for each 323 subscriber. For example, IPv6 PDP/PDN will be rejected if the 324 subscriber has an active IPv4 PDP/PDN. Therefore, the subscriber 325 will lost IPv6 connection in the visited network. It's even worse 326 that it may have a risk of losing all data connectivity if the 327 IPv6 PDP gets rejected with a permanent error at the APN-level and 328 not specific to the PDP-Type IPv6 requested. 330 o Additional correlations between those two PDP/PDN contexts are 331 required on the charging system. 333 o Policy and Charging Rules Function(PCRF)/Policy and Charging 334 Enforcement Function (PCEF) treat IPv4 and IPv6 session as 335 independent and perform different Quality of Service (QoS) 336 policies. The subscriber may have unstable experiences due to 337 different behaviors on each IP version connection. 339 o Mobile devices may have the limitation of allowed simultaneous 340 PDP/PDN activations. Overmuch PDP/PDN activation may result in 341 other unrelated services broken. 343 Operators may have to disable the local-break mode to avoid the 344 risks. Another approach is to set a dedicated Access Point Name 345 (APN) profile to only request PDP/PDN type IPv4 in the roaming 346 network. 348 5.2. Case 2: Lack of IPv6 support in applications 350 Some operators may adopt IPv6-only configuration for the IMS service, 351 e.g. Voice over LTE (VoLTE)[IR.92] or Rich Communication Suite 352 (RCS)[RCC.07]. Since IMS roaming architecture will offload all 353 traffic in the visited network, a dual-stack subscriber can only be 354 assigned with IPv6 address and no IPv4 address returned. It requires 355 all the IMS based applications should be IPv6 capable. A 356 translation-based method, for example Bump-in-the-host (BIH)[RFC6535] 357 or 464xlat [RFC6877] may help to address the issue if there are IPv6 358 compatibility problems. Those functions could be automatically 359 enabled in an IPv6-only network and disabled in a dual-stack or IPv4 360 network. 362 5.3. Case 3: Fallback Incapability 364 3GPP specified the PDP/PDN type IPv6 as early as PDP/PDN type IPv4. 365 Therefore, the IPv6 single PDP/PDN type has been well supported and 366 interpretable in the 3GPP network nodes. Roaming to IPv4-only 367 networks with IPv6 PDP/PDN request could guarantee the subscription 368 data is compatible with the visited pre-Release 9 SGSN. When a 369 subscriber requests PDP/PDN type IPv6, the network should only return 370 the expected IPv6 address. The mobile device may be failed to get IP 371 address if the visited network only allocates an IPv4 address to a 372 subscriber. In that case, the request will be dropped and the cause 373 code should be sent to the user. 375 A proper fallback is desirable however the behavior is implementation 376 specific. There are some mobile devices have the ability to provide 377 a different configuration for home network and visited network 378 respectively. Android system solves the issue by setting the roaming 379 Access Point Name(APN). It guarantees UE will always initiate PDP/ 380 PDN type IPv4 in the roaming area. 382 5.4. Case 4: 464xlat Support 384 464xlat[RFC6877] is proposed to address IPv4 compatibility issue in a 385 IPv6 single-stack environment. The function on a mobile terminal 386 likely gets along with PDP/PDN IPv6 type request to cooperate with a 387 remote NAT64[RFC6146] gateway. 464xlat may use the mechanism defined 388 in [RFC7050] to automatically detect the presence of DNS64 and learn 389 the IPv6 prefix used for protocol translation. When a mobile device 390 with 464xlat function roams to an IPv6 visited network without the 391 presence of NAT64 or DNS64, 464xlat may get failed to perform if 392 traffic is undergoing the local breakout approach. 394 The issue has been found mostly in a intra-PLMN mobility case for the 395 time being. Considering the various network's situations, operators 396 may turn off the local breakout and take home routed mode to perform 397 464xlat. Some devices may support the configuration to adopt 464xlat 398 in the home networks and use IPv4-only in the visited networks with 399 different roaming profile configurations. It could also be a 400 solution to address this issue. 402 6. Discussions 404 Several failure cases have been discussed in this document. It has 405 been testified the major issues are occurred at the two stages, i.e., 406 the initial network attach and the IP allocation process. 408 During the initial network attach, PDP/PDN type IPv4v6 is major 409 concern to the visited pre-Release 9 SGSN. The dual-stack deployment 410 is recommended in most cases. However, it may take some times in a 411 mobile environment. 3GPP didn't specify PDP/PDN type IPv4v6 in the 412 early release. Such PDP/PDN type is supported in new-built EPS 413 network, but didn't support well in the third generation network. 414 The situations may cause the roaming issues dropping the attach 415 request from dual-stack subscribers. Operators may have to adopt 416 temporary solution unless all the interworking nodes(i.e. SSGN) in 417 the visited network have been upgraded to support ext-PDP-Type 418 feature. 420 The issues in the IP address allocation process are caused due to the 421 local breakout policy. Since the IP address is allocated by the 422 visited GGSN or PGW, the mismatch is found in the following aspects. 424 o The mismatch between requested PDP/PDN type and permitted PDP/PDN 425 type 427 o The mismatch between application capability and allowed network 428 connections 430 o The mismatch between mobile device function (e.g., 464xlat) and 431 particular network deployment status 433 There are some solutions to overcome the issue. Those solutions can 434 be done either in the network side or mobile device side. The below 435 lists potential workarounds. 437 o Change local breakout to the home routed mode 439 o A dedicated roaming APN profile is implemented for roamer. When a 440 subscriber roams to a visited network, PDP/PDN type IPv4 is always 441 be selected for session activation. 443 o Networks could deploy AAA server to coordinate the mobile device 444 capability. Once the GGSN/PGW receive the session creation 445 requests, it will initiate an Access-Request to an AAA server in 446 the home land via the Radius protocol. The Access-Request 447 contains subscriber and visited network information, e.g. PDP/PDN 448 Type, International Mobile Equipment Id (IMEI), Software 449 Version(SV) and visited SGSN/MME location code, etc. The AAA 450 server could take mobile device capability combining with the 451 visited network information to ultimately determine the type of 452 session to be created, i.e. IPv4, IPv6 or IPv4v6. 454 7. IANA Considerations 456 This document makes no request of IANA. 458 8. Security Considerations 460 Even if this document does not define a new architecture nor a new 461 protocol, it is encouraged to refer to [RFC6459] for a generic 462 discussion on IPv6-related security considerations. 464 9. Acknowledgements 466 Many thanks to F. Baker and J. Brzozowski for their support. 468 This document is the result of the IETF v6ops IPv6-Roaming design 469 team effort. 471 The authors would like to thank Mikael Abrahamsson, Victor Kuarsingh, 472 Heatley Nick, Alexandru Petrescu, Tore Anderson and Cameron Byrne for 473 their helpful comments. 475 10. References 477 10.1. Normative References 479 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 480 Requirement Levels", BCP 14, RFC 2119, March 1997. 482 [RFC6052] Bao, C., Huitema, C., Bagnulo, M., Boucadair, M., and X. 483 Li, "IPv6 Addressing of IPv4/IPv6 Translators", RFC 6052, 484 October 2010. 486 [RFC6146] Bagnulo, M., Matthews, P., and I. van Beijnum, "Stateful 487 NAT64: Network Address and Protocol Translation from IPv6 488 Clients to IPv4 Servers", RFC 6146, April 2011. 490 [RFC6147] Bagnulo, M., Sullivan, A., Matthews, P., and I. van 491 Beijnum, "DNS64: DNS Extensions for Network Address 492 Translation from IPv6 Clients to IPv4 Servers", RFC 6147, 493 April 2011. 495 [RFC6535] Huang, B., Deng, H., and T. Savolainen, "Dual-Stack Hosts 496 Using "Bump-in-the-Host" (BIH)", RFC 6535, February 2012. 498 [RFC6877] Mawatari, M., Kawashima, M., and C. Byrne, "464XLAT: 499 Combination of Stateful and Stateless Translation", RFC 500 6877, April 2013. 502 [RFC7050] Savolainen, T., Korhonen, J., and D. Wing, "Discovery of 503 the IPv6 Prefix Used for IPv6 Address Synthesis", RFC 504 7050, November 2013. 506 10.2. Informative References 508 [EU-Roaming-III] 509 "http://www.amdocs.com/Products/Revenue- 510 Management/Documents/ 511 amdocs-eu-roaming-regulation-III-solution.pdf", July 2013. 513 [IR.21] Global System for Mobile Communications Association, 514 GSMA., "Roaming Database, Structure and Updating 515 Procedures", July 2012. 517 [IR.33] Global System for Mobile Communications Association, 518 GSMA., "GPRS Roaming Guidelines", July 2012. 520 [IR.65] Global System for Mobile Communications Association, 521 GSMA., "IMS Roaming & Interworking Guidelines", May 2012. 523 [IR.88] Global System for Mobile Communications Association, 524 GSMA., "LTE Roaming Guidelines", January 2012. 526 [IR.92] Global System for Mobile Communications Association 527 (GSMA), , "IMS Profile for Voice and SMS Version 7.0", 528 March 2013. 530 [RCC.07] Global System for Mobile Communications Association 531 (GSMA), , "Rich Communication Suite 5.1 Advanced 532 Communications Services and Client Specification Version 533 4.0", November 2013. 535 [RFC6459] Korhonen, J., Soininen, J., Patil, B., Savolainen, T., 536 Bajko, G., and K. Iisakkila, "IPv6 in 3rd Generation 537 Partnership Project (3GPP) Evolved Packet System (EPS)", 538 RFC 6459, January 2012. 540 [RFC6586] Arkko, J. and A. Keranen, "Experiences from an IPv6-Only 541 Network", RFC 6586, April 2012. 543 [TR23.975] 544 3rd Generation Partnership Project, 3GPP., "IPv6 migration 545 guidelines", June 2011. 547 [TS23.060] 548 3rd Generation Partnership Project, 3GPP., "General Packet 549 Radio Service (GPRS); Service description; Stage 2 v9.00", 550 March 2009. 552 [TS23.401] 553 3rd Generation Partnership Project, 3GPP., "General Packet 554 Radio Service (GPRS) enhancements for Evolved Universal 555 Terrestrial Radio Access Network (E-UTRAN) access v9.00", 556 March 2009. 558 [TS24.008] 559 3rd Generation Partnership Project, 3GPP., "Mobile radio 560 interface Layer 3 specification; Core network protocols; 561 Stage 3 v9.00", September 2009. 563 [TS24.301] 564 3rd Generation Partnership Project, 3GPP., "Non-Access- 565 Stratum (NAS) protocol for Evolved Packet System (EPS) ; 566 Stage 3 v9.00", September 2009. 568 [TS29.002] 569 3rd Generation Partnership Project, 3GPP., "Mobile 570 Application Part (MAP) specification v9.00", December 571 2009. 573 [TS29.272] 574 3rd Generation Partnership Project, 3GPP., "Mobility 575 Management Entity (MME) and Serving GPRS Support Node 576 (SGSN) related interfaces based on Diameter protocol 577 v9.00", September 2009. 579 Authors' Addresses 581 Gang Chen 582 China Mobile 583 53A,Xibianmennei Ave., 584 Xuanwu District, 585 Beijing 100053 586 China 588 Email: phdgang@gmail.com 590 Hui Deng 591 China Mobile 592 53A,Xibianmennei Ave., 593 Xuanwu District, 594 Beijing 100053 595 China 597 Email: denghui@chinamobile.com 599 Dave Michaud 600 Rogers Communications 601 8200 Dixie Rd. 602 Brampton, ON L6T 0C1 603 Canada 605 Email: dave.michaud@rci.rogers.com 607 Jouni Korhonen 608 Renesas Mobile 609 Porkkalankatu 24 610 FIN-00180 Helsinki, Finland 612 Email: jouni.nospam@gmail.com 613 Mohamed Boucadair 614 France Telecom 615 Rennes, 616 35000 617 France 619 Email: mohamed.boucadair@orange.com 621 Vizdal Ales 622 Deutsche Telekom AG 623 Tomickova 2144/1 624 Prague 4, 149 00 625 Czech Republic 627 Email: ales.vizdal@t-mobile.cz