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