idnits 2.17.1 draft-ietf-v6ops-ipv6-roaming-analysis-02.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 (August 3, 2014) is 3553 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Unused Reference: 'RFC2119' is defined on line 552, but no explicit reference was found in the text == Unused Reference: 'RFC6052' is defined on line 555, but no explicit reference was found in the text == Unused Reference: 'RFC6147' is defined on line 563, but no explicit reference was found in the text == Unused Reference: 'RFC6586' is defined on line 613, 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: February 4, 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 August 3, 2014 15 IPv6 Roaming Behavior Analysis 16 draft-ietf-v6ops-ipv6-roaming-analysis-02 18 Abstract 20 This document identifies a set of failure cases that may be 21 encountered by an IPv6-enabled mobile customers in roaming scenarios. 22 The investigations on those failed cases reveal the causes in order 23 to notice improper configurations, equipment's incomplete functions 24 or inconsistent IPv6 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 February 4, 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. HLR/HSS User Profile Setting . . . . . . . . . . . . . . . . 9 70 7. Discussions . . . . . . . . . . . . . . . . . . . . . . . . . 11 71 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12 72 9. Security Considerations . . . . . . . . . . . . . . . . . . . 12 73 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 12 74 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 12 75 11.1. Normative References . . . . . . . . . . . . . . . . . . 12 76 11.2. Informative References . . . . . . . . . . . . . . . . . 13 77 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 15 79 1. Introduction 81 Many Mobile Operators have deployed IPv6, or are about to, in their 82 operational networks. A customer in such a network can be provided 83 IPv6 connectivity if their User Equipment (UE) is IPv6-compliant. A 84 detailed overview of IPv6 support in 3GPP architectures is provided 85 in [RFC6459]. Operators may adopt various approaches to deploy IPv6 86 in mobile networks, for example the solutions described in 87 [TR23.975]). Depending on network conditions either dual-stack or 88 single-stack IPv6 is selected. 90 In production networks, it has been observed that a mobile subscriber 91 roaming around a different operator's areas may experience service 92 degradations or interruptions due to inconsistent configurations and 93 incomplete functionality of equipment in the network. 95 A mobile subscriber roaming to different operator's network may 96 experience service degradations or interruptions due to inconsistent 97 configurations and incomplete functions in the visited network. 99 2. Roaming Architecture Description 101 Roaming occurs in several scenarios: 103 o International roaming: a mobile UE may enter a visited network, 104 where a different Public Land Mobile Network (PLMN) identity is 105 used. The UEs could, either in an automatic mode or a manual 106 mode, attach to the visited PLMN. 108 o Intra-PLMN mobility: a mobile UE moves to a different area of the 109 Home Public Land Mobile Network (HPLMN). However, the subscriber 110 profile may not be stored in the area. To allow network 111 attachment the subscribers profile needs to be downloaded from the 112 home network area. 114 When a UE is turned on or is transferred via a handover to a visited 115 network, the mobile device will scan all radio channels and find 116 available Public Land Mobile Networks (PLMNs) to attach to. The 117 Serving GPRS Support Node (SGSN) or the Mobility Management Entity 118 (MME) in the visited networks must contact the Home Location 119 Register(HLR) or Home Subscriber Server(HSS) and obtain the 120 subscriber profile. After the authentication and registration 121 process is completed, the Packet Data Protocol (PDP) or Packet Data 122 Networks (PDN) activation and traffic flows may be operated 123 differently according to the subscriber profile stored in HLR or HSS. 124 Two modes are shown in the figure to illustrate, these are "Home 125 routed traffic" (Figure 1) and "Local breakout" (Figure 2). 127 +---------------------------------+ +------------------------+ 128 |Visited Network | |Home Network | 129 | +----+ +--------+ | | +--------+ Traffic Flow 130 | | UE |==========>|SGSN/MME|======================>|GGSN/PGW|============> 131 | +----+ +--------+ | Signaling | +--------+ | 132 | |-------------------------->+--------+ | 133 | | | |HLR/HSS | | 134 | | | +--------+ | 135 +---------------------------------+ +------------------------+ 137 Figure 1: Home Routed Traffic 139 +---------------------------------+ +------------------------+ 140 |Visited Network | |Home Network | 141 | +----+ +--------+ | Signaling | +--------+ | 142 | | UE |==========>|SGSN/MME|---------------------->|HLR/HSS | | 143 | +----+ +--------+ | | +--------+ | 144 | || | | | 145 | +--------+ | | | 146 | |GGSN/PGW| | | | 147 | +--------+ | | | 148 | Traffic Flow || | | | 149 +-----------------------||--------+ +------------------------+ 150 \/ 152 Figure 2: Local Breakout 154 In the home routed mode, the subscriber's UE activates the PDP/PDN 155 context and get an address from the home network. All traffic is 156 routed back to the home network. This is likely to be the case 157 international roaming of Internet data services to facilitate the 158 charging process between the two operators concerned. 160 In the local breakout mode, the subscriber address is assigned by the 161 visited network. The traffic flow is directly offloaded locally at a 162 network node close to that device's point of attachment in the 163 visited network. Therefore,a more efficient route to the data 164 service is achieved. The international roaming of IP Multimedia 165 Subsystem (IMS) based services, e.g. Voice over LTE (VoLTE)[IR.92] , 166 is claimed to select the local breakout mode in [IR.65]. Data 167 service roaming across different areas within an operator network 168 might use local breakout mode in order to get more efficient traffic 169 routing. The local breakout mode could be also applied to an 170 operator's alliance for international roaming of data service. EU 171 Roaming Regulation III[EU-Roaming-III] involves local breakout mode 172 allowing European subscribers roaming in European 2G/3G networks can 173 choose to have their Internet data routed directly to the Internet 174 from their current VPLMN. The following enumerates the more specific 175 configuration considerations. 177 o Operators may add the APN-OI-Replacement flag defined in 3GPP 178 [TS29.272] into user's subscription-data. The visited network 179 indicates a local domain name to replace the user requested Access 180 Point Name (APN). Consequently, the traffic would be steered to 181 the visited network. Those functions are normally deployed for 182 the Intra-PLMN mobility cases. 184 o Operators may also configure the VPLMN-Dynamic-Address-Allowed 185 flag[TS29.272] in the user profile to enable local breakout mode 186 in a Visited Public Land Mobile Networks (VPLMNs). 188 o 3GPP specified Selected IP Traffic Offload (SIPTO) 189 function[TS23.401] since Release 10 in order to get efficient 190 route paths. It enables an operator to offload certain types of 191 traffic at a network node close to that device's point of 192 attachment to the access network. 194 o GSMA has defined RAVEL[IR.65] as the IMS international roaming 195 architecture. Local breakout mode has been adopted for the IMS 196 roaming architecture. 198 3. Roaming Scenario 200 Two stages occur when a subscriber roams to a visited network and 201 intends to start data services. 203 o Network attachment: this occurs when the subscriber enters a 204 visited network. During an attachment, the visited network should 205 authenticate the subscriber and make a location update to the HSS/ 206 HLR in the home network of the subscriber. Accordingly, the 207 subscriber profile is offered from the HSS/HLR. The subscriber 208 profile contains the allowed Access Point Names (APN), the allowed 209 PDP/PDN Types and rules regarding the routing of data sessions 210 (i.e. home routed or local breakout mode) [TS29.272]. The SGSN/ 211 MME in the visited network can use this information to facilitate 212 the subsequent PDP/PDN session creation. 214 o PDP/PDN context creation: this occurs after the subscriber makes a 215 successful attachment. This stage is integrated with the 216 attachment stage in the case of 4G, but is a seperate process in 217 2/3G. 3GPP specifies three types of Packet Data Protocol 218 (PDP)/Packet Data Networks (PDN) to describe connections, i.e. 219 PDP/PDN Type IPv4, PDP/PDN Type IPv6 and PDP/ PDN Type IPv4v6. 220 When a subscriber creates a data session, their device requests a 221 particular PDP/PDN Type. The allowed PDP/PDN types for that 222 subscriber are learned in the attachment stage. Hence, SGSN/MME 223 could initiate PDP/PDN request to GGSN/PGW if the subscription 224 profile is allowed. 226 The failures are likely to occur in both stages due to an incompliant 227 implementation in the visited network or a mismatch between the 228 subscriber requested and the capability of the visited network. The 229 failures in the attachment stage are independent of home routed or 230 the local breakout mode, while most failure cases in the PDP/PDN 231 context creation stage occur in the local breakout cases. Section 4 232 and 5 describe each case. The below table lists several cases 233 concerning the PDP/PDN creation stage. 235 +-------------+-------------------+--------------+ 236 | UE request | PDN/PDP IP Type |Local breakout| 237 | | permitted | | 238 +-------------+-------------------+--------------+ 239 | IPv4v6 | IPv4 or IPv6 |Failure case 1| 240 +-------------+-------------------+--------------+ 241 | IPv4v6 | IPv6 |Failure case 2| 242 +-------------+-------------------+--------------+ 243 | IPv6 | IPv4 |Failure case 3| 244 +-------------+-------------------+--------------+ 245 | IPv6 | IPv6 |Failure case 4| 246 | with 464xlat| without NAT64 | | 247 +-------------+-------------------+--------------+ 249 Table 1: Roaming Scenario Descriptions 251 4. Failure Case in Attachment Stage 253 3GPP specified PDP/PDN type IPv4v6 in order to allow a UE request 254 both IPv4 and IPv6 within a single PDP/PDN request. This option is 255 stored as a part of subscription data for a subscriber in the HLR/ 256 HSS. PDP/PDN type IPv4v6 has been introduced at the inception of 257 Evolved Packet System (EPS) in 4G networks. The nodes in 4G networks 258 should present no issues with the handling of this PDN type. 259 However, support varies in 2/3G networks depending on Serving GPRS 260 Support Node (SGSN) software version. In theory, S4-SGSN (i.e. an 261 SGSN with S4 interface) supports the PDP/PDN type IPv4v6 since 262 Release8 and a Gn-SGSN (i.e. the SGSN with Gn interface) supports it 263 since Release 9. In most cases, operators normally use Gn-SGSN to 264 connect either GGSN in 3G or Packet Data Network Gateway (PGW) in 4G. 265 The MAP (Mobile Application Part) protocol, as defined in 3GPP 266 [TS29.002], is used over the Gr interface between SGSN and HLR. The 267 MAP Information Element (IE) "ext-pdp-Type" contains the IPv4v6 PDP 268 Type that is conveyed to SGSN from the HLR within the Insert 269 Subscriber Data (ISD) MAP operation. If the SGSN does not support 270 the IPv4v6 PDP Type, it will not support the "ext-pdp-Type" IE and 271 consequently it must silently discard that IE and continue processing 272 of the rest of the ISD MAP message. The issue we observe is that 273 multiple SGSNs will be unable to correctly process a subscriber's 274 data received in the Insert Subscriber Data Procedure[TS23.060]. As 275 a consequence, it will likely refuse the subscriber attach request. 276 This is erroneous behavior due to the equipment not being 3GPP 277 Release 9 compliant. 279 Operators may have to remove the PDP/PDN type IPv4v6 from the HLR/HSS 280 in the home network, that will restrict UEs to only initiate IPv4 PDP 281 or IPv6 PDP activation. In order to avoid this situation, operators 282 should make a comprehensive roaming agreement to support IPv6 and 283 ensure that it aligns with the GSMA documents, e.g. [IR.33], [IR.88] 284 and [IR.21]. Such an agreement requires the visited operator to get 285 the necessary patch on all their SGSN nodes to support PDP/PDN type 286 IPv4v6. 288 As an alternative solution there are some specific implementations 289 (not standardised by 3GPP) in the HLS/HSS of the home network. When 290 the HLR/HSS receives an Update Location message from a visited SGSN 291 known to not support the PDP type IPv4v6, subscription data with only 292 PDP/PDN type IPv4 will be sent to that SGSN in the Insert Subscriber 293 Data procedure. It guarantees the user profile is compatible with 294 visited SGSN/MME capability. 296 5. Failure Cases in PDP/PDN Creation 298 When a subscriber succeeds in the attach stage, the IP allocation 299 process takes place to allocate IP addresses to the subscriber. This 300 section summarizes several failures in the break-out cases. 302 5.1. Case 1: Splitting Dual-stack Bearer 304 Dual-stack capability can be provided using separate PDP/PDN 305 activations. That means only separate parallel single-stack IPv4 and 306 IPv6 PDP/PDN connections are allowed to be initiated to separately 307 allocate IPv4 and IPv6 addresses. 309 The cases are listed below: 311 o The SGSN/MME returns Session Management (SM) Cause #52, "Single 312 address bearers only allowed", or SM Cause #28 "Unknown PDP 313 address or PDP type" as per[TS24.008] and [TS24.301]. 315 o The SGSN/MME does not set the Dual Address Bearer Flag because the 316 operator uses single addressing per bearer to support interworking 317 with nodes of earlier releases 319 A roaming subscriber's UE with IPv4v6 PDP/PDN type has to change the 320 request into two separated PDP/PDN requests with a single IP version 321 in order to achieve equivalent results. Some drawbacks of this case 322 are listed as below: 324 o The parallel PDP/PDN activations would likely double PDP/PDN 325 resources consumptions. It also impacts the capacity of GGSN/PGW, 326 since a certain amount of PDP/PDN activations are only allowed on 327 those nodes. 329 o Some networks may only allow one PDP/PDN is alive for each 330 subscriber. For example, an IPv6 PDP/PDN will be rejected if the 331 subscriber has an active IPv4 PDP/PDN. Therefore, the subscriber 332 will lose the IPv6 connection in the visited network. It is even 333 worse as they may have a risk of losing all data connectivity if 334 the IPv6 PDP gets rejected with a permanent error at the APN-level 335 and not specific to the PDP-Type IPv6 requested. 337 o Additional correlations between those two PDP/PDN contexts are 338 required on the charging system. 340 o Policy and Charging Rules Function(PCRF)/Policy and Charging 341 Enforcement Function (PCEF) treats the IPv4 and IPv6 session as 342 independent and performs different Quality of Service (QoS) 343 policies. The subscriber may have unstable experiences due to 344 different behaviors on each IP version connection. 346 o Mobile devices may have a limitation on allowed simultaneous PDP/ 347 PDN activations. Excessive PDP/PDN activation may result in other 348 unrelated services broken. 350 Operators may have to disable the local-break mode to avoid the 351 risks. Another approach is to set a dedicated Access Point Name 352 (APN) profile to only request PDP/PDN type IPv4 in the roaming 353 network. 355 5.2. Case 2: Lack of IPv6 support in applications 357 Some operators may adopt an IPv6-only configuration for the IMS 358 service, e.g. Voice over LTE (VoLTE)[IR.92] or Rich Communication 359 Suite (RCS)[RCC.07]. Since the IMS roaming architecture will offload 360 all traffic in the visited network, a dual-stack subscriber can only 361 be assigned with an IPv6 prefix and no IPv4 address returned. This 362 requires that all the IMS based applications should be IPv6 capable. 363 A translation-based method, for example Bump-in-the-host 364 (BIH)[RFC6535] or 464xlat [RFC6877] may help to address the issue if 365 there are IPv6 compatibility problems. Those functions could be 366 automatically enabled in an IPv6-only network and disabled in a dual- 367 stack or IPv4 network. 369 5.3. Case 3: Fallback Incapability 371 3GPP specified the PDP/PDN type IPv6 as early as PDP/PDN type IPv4. 372 Therefore, the IPv6 single PDP/PDN type has been well supported and 373 interpretable in the 3GPP network nodes. Roaming to IPv4-only 374 networks and making an IPv6 PDP/PDN request should guarantee that the 375 subscription data is compatible with the visited pre-Release 9 SGSN. 376 When a subscriber requests PDP/PDN type IPv6, the network should only 377 return the expected IPv6 prefix. The mobile device may fail to get 378 an IPv6 prefix if the visited network only allocates an IPv4 address 379 to the subscriber. In that case, the request will be dropped and the 380 cause code should be sent to the user. 382 A proper fallback is desirable, however the behavior is 383 implementation specific. There are some mobile devices have the 384 ability to provide a different configuration for home network and 385 visited network respectively. For instance, the Android system 386 solves the issue by setting the roaming protocol to IPv4 for the 387 Access Point Name(APN). It guarantees that UE will always initiate 388 an PDP/PDN type IPv4 in the roaming area. 390 5.4. Case 4: 464xlat Support 392 464xlat[RFC6877] is proposed to address the IPv4 compatibility issue 393 in an IPv6 single-stack environment. The function on a mobile device 394 is likely in conjunction with a PDP/PDN IPv6 type request and 395 cooperates with a remote NAT64[RFC6146] gateway. 464xlat may use the 396 mechanism defined in [RFC7050] to automatically detect the presence 397 of DNS64 and to learn the IPv6 prefix used for protocol translation. 398 In the local breakout approach when a mobile device with 464xlat 399 function roams to an IPv6 visited network without the presence of 400 NAT64 or DNS64, 464xlat will fail to function. 402 The issue has been found mostly in intra-PLMN mobility cases for the 403 time being. Considering the various network's situations, operators 404 may turn off the local breakout and use the home routed mode to 405 perform 464xlat. Some devices may support the configuration to adopt 406 464xlat in the home networks and use IPv4-only in the visited 407 networks with different roaming profile configurations. This could 408 also be a solution to address this issue. 410 6. HLR/HSS User Profile Setting 412 A proper user profile configuration could provide deterministic 413 network control of the connectivity requests from dual-stack, 414 IPv4-only and IPv6-only devices. It's desirable that the network 415 could set-up proper connectivity for any type of the devices.The HLR/ 416 HSS may have to apply extra logic to achieve this. 418 The following are examples to demonstrate the settings for the 419 scenarios and decision criteria to apply when returning user profile 420 information to visited SGSN. 422 Scenario 1: Support IPv6-only, IPv4-only and dual-stack devices 424 user profile #1: 426 PDP-Context ::= SEQUENCE { 427 pdp-ContextId ContextId, 428 pdp-Type PDP-Type-IPv4 429 .... 430 ext-pdp-Type PDP-Type-IPv4v6 431 ... 432 } 434 user profile #2: 436 PDP-Context ::= SEQUENCE { 437 pdp-ContextId ContextId, 438 pdp-Type PDP-Type-IPv6 439 .... 440 } 442 The full PDP-context parameters is refered to Section 17.7.1 "Mobile 443 Sevice date types" of [TS29.002]. User profile 1 and 2 share the 444 same contextId. The setting of user profile #1 enables IPv4-only and 445 dual-stack devices to work. And, the user profile #2 fulfills the 446 request if the device asks for IPv6 only PDP context. 448 Scenario 2: Support dual-stack devices with pre-R9 vSGSN access 450 user profile #1: 452 PDP-Context ::= SEQUENCE { 453 pdp-ContextId ContextId, 454 pdp-Type PDP-Type-IPv4 455 .... 456 ext-pdp-Type PDP-Type-IPv4v6 457 ... 458 } 460 user profile #2: 462 PDP-Context ::= SEQUENCE { 463 pdp-ContextId ContextId, 464 pdp-Type PDP-Type-IPv4 465 .... 466 } 467 User profile 1 and 2 share the same contextId. If a visited SGSN is 468 identified as early as pre-Release 9, HLR/HSS should only send user 469 profile#2 to visited SGSN. 471 7. Discussions 473 Several failure cases have been discussed in this document. It has 474 been testified that the major issues happened at two stages, i.e., 475 the initial network attach and the IP allocation process. 477 During the initial network attach, PDP/PDN type IPv4v6 is the major 478 concern to the visited pre-Release 9 SGSN. The dual-stack deployment 479 is recommended in most cases. However, it may take some times in a 480 mobile environment. 3GPP didn't specify PDP/PDN type IPv4v6 in the 481 early release. Such PDP/PDN type is supported in new-built EPS 482 network, but didn't support well in the third generation network. 483 The situations may cause the roaming issues dropping with the attach 484 request from dual-stack subscribers. Operators may have to adopt 485 temporary solution unless all the interworking nodes(i.e. the SSGN) 486 in the visited network have been upgraded to support the ext-PDP-Type 487 feature. 489 The issues in the IP address allocation process are caused by a local 490 breakout policy. Since the IP address is allocated by the visited 491 GGSN or PGW, the mismatch is found in the following aspects. 493 o The mismatch between the requested PDP/PDN type and the permitted 494 PDP/PDN type 496 o The mismatch between the application capability and allowed 497 network connections 499 o The mismatch between mobile device function (e.g., 464xlat) and 500 the support for that function in the vistited network 502 There are some solutions to overcome the issue. Those solutions can 503 be made either in the network side or mobile device side. There 504 exist several potential workarounds. 506 o Change local breakout to the home routed mode 508 o A dedicated roaming APN profile is implemented for the roamer. 509 When a subscriber roams to a visited network, PDP/PDN type IPv4 is 510 to be always selected for session activation. 512 o Networks could deploy an AAA server to coordinate the mobile 513 device capability. Once the GGSN/PGW receives the session 514 creation request, it will initiate an Access-Request to an AAA 515 server in the home network via the Radius protocol. The Access- 516 Request contains subscriber and visited network information, e.g. 517 PDP/PDN Type, International Mobile Equipment Id (IMEI), Software 518 Version(SV) and visited SGSN/MME location code, etc. The AAA 519 server could take mobile device capability and combine it with the 520 visited network information to ultimately determine the type of 521 session to be created, i.e. IPv4, IPv6 or IPv4v6. 523 8. IANA Considerations 525 This document makes no request of IANA. 527 9. Security Considerations 529 Although this document defines neither a new architecture nor a new 530 protocol, it is encouraged to refer to [RFC6459] for a generic 531 discussion on IPv6-related security considerations. 533 10. Acknowledgements 535 Many thanks to F. Baker and J. Brzozowski for their support. 537 This document is the result of the IETF v6ops IPv6-Roaming design 538 team effort. 540 The authors would like to thank Mikael Abrahamsson, Victor Kuarsingh, 541 Heatley Nick, Alexandru Petrescu, Tore Anderson and Cameron Byrne for 542 their helpful comments. 544 The authors especially thank Fred Baker and Ross Chandler for his 545 efforts and contributions on editing which substantially improves the 546 legibility of the document. 548 11. References 550 11.1. Normative References 552 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 553 Requirement Levels", BCP 14, RFC 2119, March 1997. 555 [RFC6052] Bao, C., Huitema, C., Bagnulo, M., Boucadair, M., and X. 556 Li, "IPv6 Addressing of IPv4/IPv6 Translators", RFC 6052, 557 October 2010. 559 [RFC6146] Bagnulo, M., Matthews, P., and I. van Beijnum, "Stateful 560 NAT64: Network Address and Protocol Translation from IPv6 561 Clients to IPv4 Servers", RFC 6146, April 2011. 563 [RFC6147] Bagnulo, M., Sullivan, A., Matthews, P., and I. van 564 Beijnum, "DNS64: DNS Extensions for Network Address 565 Translation from IPv6 Clients to IPv4 Servers", RFC 6147, 566 April 2011. 568 [RFC6535] Huang, B., Deng, H., and T. Savolainen, "Dual-Stack Hosts 569 Using "Bump-in-the-Host" (BIH)", RFC 6535, February 2012. 571 [RFC6877] Mawatari, M., Kawashima, M., and C. Byrne, "464XLAT: 572 Combination of Stateful and Stateless Translation", RFC 573 6877, April 2013. 575 [RFC7050] Savolainen, T., Korhonen, J., and D. Wing, "Discovery of 576 the IPv6 Prefix Used for IPv6 Address Synthesis", RFC 577 7050, November 2013. 579 11.2. Informative References 581 [EU-Roaming-III] 582 "http://www.amdocs.com/Products/Revenue- 583 Management/Documents/ 584 amdocs-eu-roaming-regulation-III-solution.pdf", July 2013. 586 [IR.21] Global System for Mobile Communications Association, 587 GSMA., "Roaming Database, Structure and Updating 588 Procedures", July 2012. 590 [IR.33] Global System for Mobile Communications Association, 591 GSMA., "GPRS Roaming Guidelines", July 2012. 593 [IR.65] Global System for Mobile Communications Association, 594 GSMA., "IMS Roaming & Interworking Guidelines", May 2012. 596 [IR.88] Global System for Mobile Communications Association, 597 GSMA., "LTE Roaming Guidelines", January 2012. 599 [IR.92] Global System for Mobile Communications Association 600 (GSMA), , "IMS Profile for Voice and SMS Version 7.0", 601 March 2013. 603 [RCC.07] Global System for Mobile Communications Association 604 (GSMA), , "Rich Communication Suite 5.1 Advanced 605 Communications Services and Client Specification Version 606 4.0", November 2013. 608 [RFC6459] Korhonen, J., Soininen, J., Patil, B., Savolainen, T., 609 Bajko, G., and K. Iisakkila, "IPv6 in 3rd Generation 610 Partnership Project (3GPP) Evolved Packet System (EPS)", 611 RFC 6459, January 2012. 613 [RFC6586] Arkko, J. and A. Keranen, "Experiences from an IPv6-Only 614 Network", RFC 6586, April 2012. 616 [TR23.975] 617 3rd Generation Partnership Project, 3GPP., "IPv6 migration 618 guidelines", June 2011. 620 [TS23.060] 621 3rd Generation Partnership Project, 3GPP., "General Packet 622 Radio Service (GPRS); Service description; Stage 2 v9.00", 623 March 2009. 625 [TS23.401] 626 3rd Generation Partnership Project, 3GPP., "General Packet 627 Radio Service (GPRS) enhancements for Evolved Universal 628 Terrestrial Radio Access Network (E-UTRAN) access v9.00", 629 March 2009. 631 [TS24.008] 632 3rd Generation Partnership Project, 3GPP., "Mobile radio 633 interface Layer 3 specification; Core network protocols; 634 Stage 3 v9.00", September 2009. 636 [TS24.301] 637 3rd Generation Partnership Project, 3GPP., "Non-Access- 638 Stratum (NAS) protocol for Evolved Packet System (EPS) ; 639 Stage 3 v9.00", September 2009. 641 [TS29.002] 642 3rd Generation Partnership Project, 3GPP., "Mobile 643 Application Part (MAP) specification v9.12.0", December 644 2009. 646 [TS29.272] 647 3rd Generation Partnership Project, 3GPP., "Mobility 648 Management Entity (MME) and Serving GPRS Support Node 649 (SGSN) related interfaces based on Diameter protocol 650 v9.00", September 2009. 652 Authors' Addresses 654 Gang Chen 655 China Mobile 656 53A,Xibianmennei Ave., 657 Xuanwu District, 658 Beijing 100053 659 China 661 Email: phdgang@gmail.com 663 Hui Deng 664 China Mobile 665 53A,Xibianmennei Ave., 666 Xuanwu District, 667 Beijing 100053 668 China 670 Email: denghui@chinamobile.com 672 Dave Michaud 673 Rogers Communications 674 8200 Dixie Rd. 675 Brampton, ON L6T 0C1 676 Canada 678 Email: dave.michaud@rci.rogers.com 680 Jouni Korhonen 681 Renesas Mobile 682 Porkkalankatu 24 683 FIN-00180 Helsinki, Finland 685 Email: jouni.nospam@gmail.com 687 Mohamed Boucadair 688 France Telecom 689 Rennes, 690 35000 691 France 693 Email: mohamed.boucadair@orange.com 694 Vizdal Ales 695 Deutsche Telekom AG 696 Tomickova 2144/1 697 Prague 4, 149 00 698 Czech Republic 700 Email: ales.vizdal@t-mobile.cz