idnits 2.17.1 draft-ietf-v6ops-ipv6-roaming-analysis-05.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 (September 1, 2014) is 3524 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: March 5, 2015 D. Michaud 6 Rogers Communications 7 J. Korhonen 8 Broadcom 9 M. Boucadair 10 France Telecom 11 A. Vizdal 12 Deutsche Telekom AG 13 September 1, 2014 15 IPv6 Roaming Behavior Analysis 16 draft-ietf-v6ops-ipv6-roaming-analysis-05 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 analysis reveals that the failure causes include improper 23 configurations, incomplete functionality support in equipment, and 24 inconsistent IPv6 deployment strategies between the home and the 25 visited networks. 27 Status of This Memo 29 This Internet-Draft is submitted in full conformance with the 30 provisions of BCP 78 and BCP 79. 32 Internet-Drafts are working documents of the Internet Engineering 33 Task Force (IETF). Note that other groups may also distribute 34 working documents as Internet-Drafts. The list of current Internet- 35 Drafts is at http://datatracker.ietf.org/drafts/current/. 37 Internet-Drafts are draft documents valid for a maximum of six months 38 and may be updated, replaced, or obsoleted by other documents at any 39 time. It is inappropriate to use Internet-Drafts as reference 40 material or to cite them other than as "work in progress." 42 This Internet-Draft will expire on March 5, 2015. 44 Copyright Notice 46 Copyright (c) 2014 IETF Trust and the persons identified as the 47 document authors. All rights reserved. 49 This document is subject to BCP 78 and the IETF Trust's Legal 50 Provisions Relating to IETF Documents 51 (http://trustee.ietf.org/license-info) in effect on the date of 52 publication of this document. Please review these documents 53 carefully, as they describe your rights and restrictions with respect 54 to this document. Code Components extracted from this document must 55 include Simplified BSD License text as described in Section 4.e of 56 the Trust Legal Provisions and are provided without warranty as 57 described in the Simplified BSD License. 59 Table of Contents 61 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 62 1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3 63 2. Background . . . . . . . . . . . . . . . . . . . . . . . . . 3 64 2.1. Roaming Architecture: An Overview . . . . . . . . . . . . 3 65 2.1.1. Home Routed Mode . . . . . . . . . . . . . . . . . . 4 66 2.1.2. Local Breakout Mode . . . . . . . . . . . . . . . . . 5 67 2.2. Typical Roaming Scenarios . . . . . . . . . . . . . . . . 6 68 3. Failure Case in the Network Attachment . . . . . . . . . . . 7 69 4. Failure Cases in the PDP/PDN Creation . . . . . . . . . . . . 8 70 4.1. Case 1: Splitting Dual-stack Bearer . . . . . . . . . . . 9 71 4.2. Case 2: IPv6 PDP/PDN Unsupported . . . . . . . . . . . . 10 72 4.3. Case 3: Inappropriate Roaming APN Set . . . . . . . . . . 11 73 4.4. Case 4: Fallback Failure . . . . . . . . . . . . . . . . 11 74 5. Failure Cases in the Service Requests . . . . . . . . . . . . 11 75 5.1. Lack of IPv6 Support in Applications . . . . . . . . . . 11 76 5.2. 464xlat Support . . . . . . . . . . . . . . . . . . . . . 12 77 6. HLR/HSS User Profile Setting . . . . . . . . . . . . . . . . 12 78 7. Discussion . . . . . . . . . . . . . . . . . . . . . . . . . 14 79 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15 80 9. Security Considerations . . . . . . . . . . . . . . . . . . . 15 81 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 15 82 11. Informative References . . . . . . . . . . . . . . . . . . . 16 83 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 18 85 1. Introduction 87 Many Mobile Operators have deployed IPv6, or are about to, in their 88 operational networks. A customer in such a network can be provided 89 IPv6 connectivity if their User Equipment (UE) is IPv6-compliant. 90 Operators may adopt various approaches to deploy IPv6 in mobile 91 networks such as the solutions described in [TR23.975]). Depending 92 on network conditions, either dual-stack or IPv6-only deployment 93 schemes can be enabled. 95 A detailed overview of IPv6 support in 3GPP architectures is provided 96 in [RFC6459]. 98 It has been observed and reported that a mobile subscriber roaming 99 around a different operator's areas may experience service disruption 100 due to inconsistent configurations and incomplete functionality of 101 equipment in the network. This document focuses on these issues. 103 1.1. Terminology 105 This document makes use of these terms: 107 o Mobile networks refer to 3GPP mobile networks. 109 o Mobile UE denotes a 3GPP device which can be connected to 3GPP 110 mobile networks. 112 o The Public Land Mobile Network (PLMN) is a network that is 113 operated by a single administrative entity. A PLMN (and therefore 114 also an operator) is identified by the Mobile Country Code (MCC) 115 and the Mobile Network Code (MNC). Each (telecommunications) 116 operator providing mobile services has its own PLMN [RFC6459]. 118 o The Home Location Register (HLR) is a pre-Release-5 database (but 119 is also used in Release-5 and later networks in real deployments) 120 that contains subscriber data and information related to call 121 routing. All subscribers of an operator, and the subscribers' 122 enabled services, are provisioned in the HLR [RFC6459]. 124 o The Home Subscriber Server (HSS) is a database for a given 125 subscriber and was introduced in 3GPP Release-5. It is the entity 126 containing the subscription-related information to support the 127 network entities actually handling calls/sessions [RFC6459]. 129 "HLR/HSS" is used collectively for the subscriber database unless 130 referring to the failure case related to General Packet Radio Service 131 (GPRS) Subscriber data from the HLR. 133 An overview of key 3GPP functional elements is documented in 134 [RFC6459]. 136 "Mobile device" and "mobile UE" are used interchangeably. 138 2. Background 140 2.1. Roaming Architecture: An Overview 142 Roaming occurs in two scenarios: 144 o International roaming: a mobile UE enters a visited network 145 operated by a different operator, where a different Public Land 146 Mobile Network (PLMN) code is used. The UEs could, either in an 147 automatic mode or in a manual mode, attach to the visited PLMN. 149 o Intra-PLMN mobility: an operator may have one or multiple PLMN 150 codes. A mobile UE could pre-configure the codes to identify the 151 Home PLMN (HPLMN) or Equivalent HPLMN (EHPLMN). Intra-PLMN 152 mobility allows the UE moving to a different area of HPLMN and 153 EHPLMN. When the subscriber profile is not stored in the visited 154 area, HLR/HSS in the Home area will transmit the profile to 155 Serving GPRS Support Node (SGSN)/Mobility Management Entity (MME) 156 in the visited area so as to complete network attachment. 158 When a UE is turned on or is transferred via a hand-over to a visited 159 network, the mobile device will scan all radio channels and find 160 available PLMNs to attach to. The SGSN or the MME in the visited 161 networks must contact the HLR or HSS to retrieve the subscriber 162 profile. 164 Steering of roaming may also be used by the HPLMN to further restrict 165 which of the available networks the UE may be attached to. Once the 166 authentication and registration stage is completed, the Packet Data 167 Protocol (PDP) or Packet Data Networks (PDN) activation and traffic 168 flows may be operated differently according to the subscriber profile 169 stored in the HLR or the HSS. 171 The following sub-sections describe two roaming modes: Home routed 172 traffic (Section 2.1.1) and Local breakout (Section 2.1.2). 174 2.1.1. Home Routed Mode 176 In this mode, the subscriber's UE gets IP addresses from the home 177 network. All traffic belonging to that UE is therefore routed to the 178 home network (Figure 1). 180 GPRS roaming exchange (GRX) or Internetwork Packet Exchange (IPX) 181 networks [IR.34] is likely to be invoked as the transit network to 182 deliver the traffic. This is the main mode for international roaming 183 of Internet data services to facilitate the charging process between 184 the two involved operators. 186 +-----------------------------+ +------------------------+ 187 |Visited Network | |Home Network | 188 | +----+ +--------+ | (GRX/IPX) | +--------+ Traffic Flow 189 | | UE |=======>|SGSN/MME|====================>|GGSN/PGW|============> 190 | +----+ +--------+ | Signaling | +--------+ | 191 | |------------------------>+--------+ | 192 | | | |HLR/HSS | | 193 | | | +--------+ | 194 +-----------------------------+ +------------------------+ 196 Figure 1: Home Routed Traffic 198 2.1.2. Local Breakout Mode 200 In the local breakout mode, IP addresses are assigned by the visited 201 network to a roaming mobile UE. Unlike the home mode, the traffic 202 doesn't have to traverse GRX/IPX; it is offloaded locally at a 203 network node close to that device's point of attachment in the 204 visited network. This mode ensures a more optimized forwarding path 205 for the delivery of packets belonging to a visiting UE (Figure 2). 207 +----------------------------+ +----------------+ 208 |Visited Network | |Home Network | 209 | +----+ +--------+ | Signaling | +--------+ | 210 | | UE |=======>|SGSN/MME|------------------->|HLR/HSS | | 211 | +----+ +--------+ | (GRX/IPX) | +--------+ | 212 | || | | | 213 | +--------+ | | | 214 | |GGSN/PGW| | | | 215 | +--------+ | | | 216 | Traffic Flow || | | | 217 +--------------------||------+ +----------------+ 218 \/ 220 Figure 2: Local Breakout 222 The international roaming of IP Multimedia Subsystem (IMS) based 223 services, e.g. Voice over LTE (VoLTE)[IR.92], is claimed to select 224 the local breakout mode in [IR.65]. Data service roaming across 225 different areas within an operator network might use local breakout 226 mode in order to get more efficient traffic forwarding and also ease 227 emergency services. The local breakout mode could also be applied to 228 an operator's alliance for international roaming of data service. 230 EU Roaming Regulation III [EU-Roaming-III] involves local breakout 231 mode allowing European subscribers roaming in European 2G/3G networks 232 to have their Internet data routed directly to the Internet from 233 their current VPLMN. 235 Specific local breakout related configuration considerations are 236 listed below: 238 o Operators may add the APN-OI-Replacement flag defined in 3GPP 239 [TS29.272] into the user's subscription-data. The visited network 240 indicates a local domain name to replace the user requested Access 241 Point Name (APN). Consequently, the traffic would be steered to 242 the visited network. Those functions are normally deployed for 243 the intra-PLMN mobility cases. 245 o Operators may also configure the VPLMN-Dynamic-Address-Allowed 246 flag [TS29.272] in the user's profile to enable local breakout 247 mode in a Visited Public Land Mobile Networks (VPLMNs). 249 o 3GPP specified Selected IP Traffic Offload (SIPTO) function 250 [TS23.401] since Release 10 in order to get efficient route paths. 251 It enables an operator to offload a portion of the traffic at a 252 network node close to the visiting UE's point of attachment to the 253 visited network. 255 o GSMA has defined Roaming Architecture for Voice over LTE with 256 Local Breakout (RAVEL) [IR.65] as the IMS international roaming 257 architecture. Local breakout mode has been adopted for the IMS 258 roaming architecture. 260 2.2. Typical Roaming Scenarios 262 Three stages occur when a subscriber roams to a visited network and 263 intends to invoke services: 265 o Network attachment: this occurs when the UE enters a visited 266 network. During the attachment phase, the visited network should 267 authenticate the subscriber and make a location update to the HSS/ 268 HLR in the home network of the subscriber. Accordingly, the 269 subscriber profile is offered from the HSS/HLR. The subscriber 270 profile contains the allowed Access Point Names (APN), the allowed 271 PDP/PDN Types and rules regarding the routing of data sessions 272 (i.e., home routed or local breakout mode) [TS29.272]. The SGSN/ 273 MME in the visited network can use this information to facilitate 274 the subsequent PDP/PDN session creation. 276 o PDP/PDN context creation: this occurs after the subscriber UE has 277 been successfully attached to the network. This stage is 278 integrated with the attachment stage in the case of 4G, but is a 279 separate process in 2/3G. 3GPP specifies three types of PDP/PDN to 280 describe connections, i.e. PDP/PDN Type IPv4, PDP/PDN Type IPv6 281 and PDP/ PDN Type IPv4v6. When a subscriber creates a data 282 session, their device requests a particular PDP/PDN Type. The 283 allowed PDP/PDN types for that subscriber are learned in the 284 attachment stage. Hence, SGSN/MME could initiate PDP/PDN request 285 to GGSN/PGW modulo subscription grants. 287 o Service requests: when the PDP/PDN context is created 288 successfully, UEs may launch applications and request services 289 based on the allocated IP addresses. The service traffic will be 290 transmitted via the visited network. 292 Failures that occur at the attachment stage (Section 3) are 293 independent of home routed and the local breakout mode. Most failure 294 cases in the PDP/PDN context creation (Section 4) and service 295 requests (Section 5) occur in the local breakout mode. 297 3. Failure Case in the Network Attachment 299 3GPP specified PDP/PDN type IPv4v6 in order to allow a UE get both an 300 IPv4 address and an IPv6 prefix within a single PDP/PDN bearer. This 301 option is stored as a part of subscription data for a subscriber in 302 the HLR/HSS. PDP/PDN type IPv4v6 has been introduced at the 303 inception of Evolved Packet System (EPS) in 4G networks. 305 The nodes in 4G networks should present no issues with the handling 306 of this PDN type. However, the level of support varies in 2/3G 307 networks depending on SGSN software version. In theory, S4-SGSN 308 (i.e., an SGSN with S4 interface) supports the PDP/PDN type IPv4v6 309 since Release 8 and a Gn-SGSN (i.e., the SGSN with Gn interface) 310 supports it since Release 9. In most cases, operators normally use 311 Gn-SGSN to connect either GGSN in 3G or Packet Data Network Gateway 312 (PGW) in 4G. 314 The MAP (Mobile Application Part) protocol, as defined in 3GPP 315 [TS29.002], is used over the Gr interface between SGSN and HLR. The 316 MAP Information Element (IE) "ext-pdp-Type" contains the IPv4v6 PDP 317 Type that is conveyed to SGSN from the HLR within the Insert 318 Subscriber Data (ISD) MAP operation. If the SGSN does not support 319 the IPv4v6 PDP Type, it will not support the "ext-pdp-Type" IE and 320 consequently it must silently discard that IE and continue processing 321 of the rest of the ISD MAP message. An issue that has been observed 322 is that multiple SGSNs are unable to correctly process a subscriber's 323 data received in the Insert Subscriber Data Procedure [TS23.060]. As 324 a consequence, it will likely discard the subscriber attach request. 325 This is erroneous behavior due to the equipment not being compliant 326 with 3GPP Release 9. 328 In order to avoid encountering this attach problem at a visited SGSN, 329 both operators should make a comprehensive roaming agreement to 330 support IPv6 and ensure that it aligns with the GSMA documents, e.g., 332 [IR.33], [IR.88] and [IR.21]. Such an agreement requires the visited 333 operator to get the necessary patch on all its SGSN nodes to support 334 the "ext-pdp-Type" MAP IE sent by the HLR. To ensure data session 335 continuity in Radio Access Technology (RAT) handovers the PDN Type 336 sent by the HSS to the MME could be consistent with the PDP Type sent 337 by the HLR to the Gn-SGSN. Where roaming agreements and visited SGSN 338 nodes have not been updated the HPLMN also has to make use of 339 specific implementations (not standardized by 3GPP, discussed further 340 in (Section 6) in the HLR/HSS of the home network. That is, when the 341 HLR/HSS receives an Update Location message from a visited SGSN not 342 known to support dual-stack in a single bearer, subscription data 343 allowing only PDP/PDN type IPv4 or IPv6 will be sent to that SGSN in 344 the Insert Subscriber Data procedure. This guarantees that the user 345 profile is compatible with the visited SGSN/MME capability. In 346 addition, HSS may not have to change, if the PGW is aware of 347 subscriber's roaming status and only restricts the accepted PDN type 348 consistent with PDP type sent by the HLR. For example, an AAA server 349 may coordinate with the PGW to decide the allowed PDN type. 351 Alternatively, HPLMNs without the non-standardized capability to 352 suppress the sending of "ext-pdp-Type" by the HLR may have to remove 353 this attribute from APNs with roaming service. PDN Type IPv4v6 must 354 also be removed from the corresponding profile for the APN in the 355 HSS. This will restrict their roaming UEs to only IPv4 or IPv6 PDP/ 356 PDN activation. This alternative has problems: 358 o The HPLMN cannot support dual-stack in a single bearer at home 359 either where the APN profile in the HLR/HSS is also used for 360 roaming. 362 o The UE may set-up separate parallel bearers for IPv4 and IPv6 363 where only single stack IPv4 or IPv6 service is preferred by the 364 operator. 366 4. Failure Cases in the PDP/PDN Creation 368 When a subscriber's UE succeeds in the attach stage, the IP 369 allocation process takes place to retrieve IP addresses. In general, 370 a PDP/PDN type IPv4v6 request implicitly allows the network side to 371 make several IP assignment options, including IPv4-only, IPv6-only, 372 IPv4 and IPv6 in single PDP/PDN bearer, IPv4 and IPv6 in separated 373 PDP/PDN bearers. 375 A PDP/PDN type IPv4 or IPv6 restricts the network side to only 376 allocate requested IP address family. 378 This section summarizes several failures in the Home Routed (HR) and 379 Local Breakout (LBO) mode as shown in Table 1. 381 +-------+-------------+------------------------+---------+ 382 | Case# | UE request | PDP/PDN IP Type | Mode | 383 | | | permitted on GGSN/PGW | | 384 +-------+-------------+------------------------+---------+ 385 | | IPv4v6 | IPv4v6 | HR | 386 | #1 |-------------+------------------------+---------+ 387 | | IPv4v6 | IPv4 or IPv6 | LBO | 388 +-------+-------------+------------------------+---------+ 389 | #2 | IPv6 | IPv6 | HR | 390 +-------+-------------+------------------------+---------+ 391 | #3 | IPv4 | IPv6 | HR | 392 +-------+-------------+------------------------+---------+ 393 | #4 | IPv6 | IPv4 | LBO | 394 +-------+-------------+------------------------+---------+ 396 Table 1: Failure Cases in the PDP/PDN Creation 398 4.1. Case 1: Splitting Dual-stack Bearer 400 Dual-stack capability is provided using separate PDP/PDN activation 401 in the visited network that doesn't support PDP/PDN type IPv4v6. 402 That means only separate parallel single-stack IPv4 and IPv6 PDP/PDN 403 connections are allowed to be initiated to separately allocate an 404 IPv4 address and an IPv6 prefix. The SGSN does not support the Dual 405 Address Bearer Flag (DAF) or does not set DAF because the operator 406 uses single addressing per bearer to support interworking with nodes 407 of earlier releases. Regardless of home routed or local breakout 408 mode, GGSN/PGW will change PDN/PDP type to a single address PDP/PDN 409 type and return the Session Management (SM) Cause #52 "Single address 410 bearers only allowed" or SM Cause #28 "Unknown PDP address or PDP 411 type" as per [TS24.008] and [TS24.301] to the UE. In this case, the 412 UE may make another PDP/PDN request with a single address PDP type 413 (IPv4 or IPv6) other than the one already activated. 415 This approach suffers from the followings drawbacks: 417 o The parallel PDP/PDN activation would likely double PDP/PDN bearer 418 resource on the network side and Radio Access Bearer (RAB) 419 resource on the RAN side. It also impacts the capacity of the 420 GGSN/PGW, since only a certain amount of PDP/PDN activation is 421 only allowed on those nodes. 423 o Some networks may only allow one PDP/PDN be alive for each 424 subscriber. For example, an IPv6 PDP/PDN will be rejected if the 425 subscriber has an active IPv4 PDP/PDN. Therefore, the subscriber 426 will lose the IPv6 connection in the visited network. It is even 427 worse as they may have a risk of losing all data connectivity if 428 the IPv6 PDP gets rejected with a permanent error at the APN-level 429 and not specific to the PDP-Type IPv6 requested. 431 o Additional correlations between those two PDP/PDN contexts are 432 required on the charging system. 434 o Policy and Charging Rules Function (PCRF) [TS29.212]/ Policy and 435 Charging Enforcement Function (PCEF) treats the IPv4 and IPv6 436 session as independent and performs different Quality of Service 437 (QoS) policies. The subscriber may have unstable experiences due 438 to different behaviors on each IP version connection. 440 o Mobile devices may have a limitation on allowed simultaneous PDP/ 441 PDN contexts. Excessive PDP/PDN activation may result in service 442 disruption. 444 In order to avoid the issue, the roaming agreement in the home routed 445 mode should make sure the visited SGSN support and set the DAF. 446 Since the PDP/PDN type IPv4v6 is supported in the GGSN/PGW of home 447 network, it's expected that the visited SGSN/MME could create dual- 448 stack bearer as UE requested. 450 In the local breakout mode, the visited SGSN may only allow single IP 451 version addressing. In this case, DAF on visited SGSN/MME has to be 452 unset. One approach is to set a dedicated Access Point Name (APN) 453 [TS23.003] profile to only request PDP/PDN type IPv4 in the roaming 454 network. Some operators may also consider not adopting the local 455 breakout mode to avoid the risks. 457 4.2. Case 2: IPv6 PDP/PDN Unsupported 459 PDP/PDN type IPv6 has good compatibility to visited networks during 460 the network attachment. In order to support the IPv6-only visitors, 461 SGSN/MME in the visited network is required to accept IPv6-only PDP/ 462 PDN activation requests and enable IPv6 on user plane towards the 463 home network. 465 In some cases, IPv6-only visitors may still be subject to the SGSN 466 capability in visited networks. This becomes especially risky if the 467 home operator performs roaming steering targeted to an operator that 468 doesn't allow IPv6. The visited SGSN may just directly reject the 469 PDP context activation. Therefore, it's expected that visited 470 network is IPv6 roaming friendly to enable the functions on SGSN/MME 471 by default. Otherwise, operators may consider steering the roaming 472 traffic to the IPv6-enable visited network that has IPv6 roaming 473 agreement. 475 4.3. Case 3: Inappropriate Roaming APN Set 477 If IPv6 single stack with the home routed mode is deployed, the 478 requested PDP/PDN type should also be IPv6. Some implementations 479 that support roaming APN profile may set IPv4 as the default PDP/PDN 480 type, since the visited network is incapable to support PDP/PDN type 481 IPv4v6 (Section 4.1) and IPv6 (Section 4.2). The PDP/PDN request 482 will fail because the APN in the home network only allows IPv6. 483 Therefore, the roaming APN have to be compliant with the home network 484 configuration when home routed mode is adopted. 486 4.4. Case 4: Fallback Failure 488 In the local breakout mode, PDP/PDN type IPv6 should have no issues 489 to pass through network attachment process, since 3GPP specified the 490 PDP/PDN type IPv6 as early as PDP/PDN type IPv4. When a visitor 491 requests PDP/PDN type IPv6, the network should only return the 492 expected IPv6 prefix. The UE may fail to get an IPv6 prefix if the 493 visited network only allocates an IPv4 address. In this case, the 494 visited network will reject the request and send the cause code to 495 the UE. 497 A proper fallback scheme for PDP/PDN type IPv6 is desirable, however 498 there is no the standard way to specify the behavior. Roaming APN 499 profile could help to address the issue by setting PDP/PDN type IPv4. 500 For instance, the Android system solves the issue by configuring the 501 roaming protocol to IPv4 for the Access Point Name (APN). It 502 guarantees that UE will always initiate an PDP/PDN type IPv4 in the 503 roaming area. 505 5. Failure Cases in the Service Requests 507 After the successful network attachment and IP address allocation, 508 applications could start to request service based on the activated 509 PDP/PDN context. The service request may depend on specific IP 510 family or network collaboration. If traffic is offloaded locally 511 (Section 2.1.2 ), the visited network may not be able to accommodate 512 UE's service requests. This section describes the failures. 514 5.1. Lack of IPv6 Support in Applications 516 Operators may only allow IPv6 in the IMS APN. VoLTE [IR.92] or Rich 517 Communication Suite (RCS) [RCC.07] use the APN to offer the voice 518 service for visitors. The IMS roaming in RAVEL architecture [IR.65] 519 offloads voice and video traffic in the visited network, therefore a 520 dual-stack visitor can only be assigned with an IPv6 prefix but no 521 IPv4 address. If the applications can't support IPv6, the service is 522 likely failed . 524 Translation-based methods, for example 464xlat [RFC6877] or Bump-in- 525 the-host (BIH) [RFC6535], may help to address the issue if there are 526 IPv6 compatibility problems. The translation function could be 527 enabled in an IPv6-only network and disabled in a dual-stack or IPv4 528 network, therefore the IPv4 applications only get the translation in 529 the IPv6 network and perform normally in an IPv4 or dual-stack 530 network. 532 5.2. 464xlat Support 534 464xlat[RFC6877] is proposed to address the IPv4 compatibility issue 535 in an IPv6-only connectivity environment. The customer-side 536 translator (CLAT) function on a mobile device is likely in 537 conjunction with a PDP/PDN IPv6 type request and cooperates with a 538 remote NAT64 [RFC6146] device. 540 464xlat may use the mechanism defined in [RFC7050] or [RFC7225] to 541 detect the presence of NAT64 devices and to learn the IPv6 prefix 542 used for protocol translation[RFC6052]. 544 In the local breakout approach, when a UE with the 464xlat function 545 roaming to an IPv6 visited network may encounter various situations. 546 For example, the visited network may not deploy DNS64 [RFC6147] but 547 only NAT64, CLAT may not be able to discover the provider-side 548 translator (PLAT) translation IPv6 prefix used as a destination of 549 the PLAT. If the visited network doesn't deploy NAT64 and DNS64, 550 464xlat can't perform successfully due to the lack of PLAT 551 collaboration. Even in the case of the presence of NAT64 and DNS64, 552 pre-configured PLAT-side IPv6 prefix in the CLAT may cause the 553 failure because it can't match the PLAT translation. 555 Considering the various network's situations, operators may turn off 556 the local breakout and use the home routed mode to perform 464xlat. 557 Alternatively, UE may support the different roaming profile 558 configurations to adopt 464xlat in the home networks and use 559 IPv4-only in the visited networks. 561 6. HLR/HSS User Profile Setting 563 A proper user profile configuration would provide a deterministic 564 outcome to the PDP/PDN creation stage where dual-stack, IPv4-only and 565 IPv6-only connectivity requests may come from devices. The HLR/HSS 566 may have to apply extra logic (not standardized by 3GPP) to achieve 567 this. It is also desirable that the network could set-up 568 connectivity of any requested PDP/PDN context type. 570 The following are examples to illustrate the settings for the 571 scenarios and decision criteria to apply when returning user profile 572 information to the visited SGSN. 574 user profile #1: 576 PDP-Context ::= SEQUENCE { 577 pdp-ContextId ContextId, 578 pdp-Type PDP-Type-IPv4 579 .... 580 ext-pdp-Type PDP-Type-IPv4v6 581 ... 582 } 584 user profile #2: 586 PDP-Context ::= SEQUENCE { 587 pdp-ContextId ContextId, 588 pdp-Type PDP-Type-IPv6 589 .... 590 } 592 Scenario 1: Support of IPv6-only, IPv4-only and dual-stack devices. 594 The full PDP-context parameters is referred to Section 17.7.1 "Mobile 595 Service date types" of [TS29.002]. User profiles #1 and #2 share the 596 same "ContextId". The setting of user profile #1 enables IPv4-only 597 and dual-stack devices to work. And, the user profile #2 fulfills 598 the request if the device asks for IPv6 only PDP context. 600 user profile #1: 602 PDP-Context ::= SEQUENCE { 603 pdp-ContextId ContextId, 604 pdp-Type PDP-Type-IPv4 605 .... 606 ext-pdp-Type PDP-Type-IPv4v6 607 ... 608 } 610 user profile #2: 612 PDP-Context ::= SEQUENCE { 613 pdp-ContextId ContextId, 614 pdp-Type PDP-Type-IPv4 615 .... 616 } 618 Scenario 2: Support of dual-stack devices with pre-R9 vSGSN access. 620 User profiles #1 and #2 share the same "ContextId". If a visited 621 SGSN is identified as early as pre-Release 9, the HLR/HSS should only 622 send user profile#2 to the visited SGSN. 624 7. Discussion 626 Several failure cases have been discussed in this document. It has 627 been testified that the major issues happened at three stages, i.e., 628 the initial network attachment, the PDP/PDN creation and service 629 requests. 631 In the stage of the network attachment, PDP/PDN type IPv4v6 is the 632 major concern to the visited pre-Release 9 SGSN. 3GPP didn't specify 633 PDP/PDN type IPv4v6 in the early release. Such PDP/PDN type is 634 supported in new-built EPS network, but didn't support well in the 635 third generation network. The situations may cause the roaming 636 issues dropping with the attach request from dual-stack subscribers. 637 Operators may have to adopt temporary solutions unless all the 638 interworking nodes (i.e., the SSGN) in the visited network have been 639 upgraded to support the ext-PDP-Type feature. 641 In the stage of the PDP/PDN creation, PDP/PDN type IPv4v6 and IPv6 642 support on the visited SGSN is the major concern. It has been 643 observed that IPv6 single stack with the home routed mode is a viable 644 approach to deploy IPv6. It is desirable the visited SGSN could 645 enable IPv6 on the user plane by default. For the PDP/PDN type 646 IPv4v6 supporting, the DAF is suggested to be set. As a 647 complementary function, the implementation of roaming APN 648 configuration is useful to accommodate the visited network. However, 649 it should consider roaming architecture and permitted PDP/PDN type to 650 make proper setting on the UE. Roaming APN in the home routed mode 651 is recommended to align with home network profile setting. In the 652 local breakout case, PDP/PDN type IPv4 could be selected as a safe 653 way to initiate PDP/PDN activation. 655 In the stage of service requests, the failure cases are mostly 656 occurred in the local breakout case. The visited network may not be 657 able to satisfy the requested capability from applications or UEs. 658 Operators may consider to use home routed to avoid the risks. 659 Several solutions either in the network side or mobile device side 660 can also help to address the issue. For example, 662 o 464xlat could help IPv4 applications access IPv6 visited networks. 664 o Networks can deploy an AAA server to coordinate the mobile device 665 capability. Once the GGSN/PGW receives the session creation 666 request, it will initiate an Access-Request to an AAA server in 667 the home network via the Radius protocol. The Access-Request 668 contains subscriber and visited network information, e.g. PDP/PDN 669 Type, International Mobile Equipment Id (IMEI), Software Version 670 (SV) and visited SGSN/MME location code, etc. The AAA server 671 could take mobile device capability and combine it with the 672 visited network information to ultimately determine the type of 673 session to be created, i.e., IPv4, IPv6 or IPv4v6. 675 8. IANA Considerations 677 This document makes no request of IANA. 679 9. Security Considerations 681 Although this document defines neither a new architecture nor a new 682 protocol, it is encouraged to refer to [RFC6459] for a generic 683 discussion on IPv6-related security considerations. 685 10. Acknowledgements 687 Many thanks to F. Baker and J. Brzozowski for their support. 689 This document is the result of the IETF v6ops IPv6-Roaming design 690 team effort. 692 The authors would like to thank Mikael Abrahamsson, Victor Kuarsingh, 693 Heatley Nick, Alexandru Petrescu, Tore Anderson, Cameron Byrne, 694 Holger Metschulat and Geir Egeland for their helpful discussions and 695 comments. 697 The authors especially thank Fred Baker and Ross Chandler for their 698 efforts and contributions which substantially improved the 699 readability of the document. 701 11. Informative References 703 [EU-Roaming-III] 704 "http://www.amdocs.com/Products/Revenue- 705 Management/Documents/ 706 amdocs-eu-roaming-regulation-III-solution.pdf", July 2013. 708 [IR.21] Global System for Mobile Communications Association, 709 GSMA., "Roaming Database, Structure and Updating 710 Procedures", July 2012. 712 [IR.33] Global System for Mobile Communications Association, 713 GSMA., "GPRS Roaming Guidelines", July 2012. 715 [IR.34] Global System for Mobile Communications Association, 716 GSMA., "Guidelines for IPX Provider networks", November 717 2013. 719 [IR.65] Global System for Mobile Communications Association, 720 GSMA., "IMS Roaming & Interworking Guidelines", May 2012. 722 [IR.88] Global System for Mobile Communications Association, 723 GSMA., "LTE Roaming Guidelines", January 2012. 725 [IR.92] Global System for Mobile Communications Association 726 (GSMA), , "IMS Profile for Voice and SMS Version 7.0", 727 March 2013. 729 [RCC.07] Global System for Mobile Communications Association 730 (GSMA), , "Rich Communication Suite 5.1 Advanced 731 Communications Services and Client Specification Version 732 4.0", November 2013. 734 [RFC6052] Bao, C., Huitema, C., Bagnulo, M., Boucadair, M., and X. 735 Li, "IPv6 Addressing of IPv4/IPv6 Translators", RFC 6052, 736 October 2010. 738 [RFC6146] Bagnulo, M., Matthews, P., and I. van Beijnum, "Stateful 739 NAT64: Network Address and Protocol Translation from IPv6 740 Clients to IPv4 Servers", RFC 6146, April 2011. 742 [RFC6147] Bagnulo, M., Sullivan, A., Matthews, P., and I. van 743 Beijnum, "DNS64: DNS Extensions for Network Address 744 Translation from IPv6 Clients to IPv4 Servers", RFC 6147, 745 April 2011. 747 [RFC6459] Korhonen, J., Soininen, J., Patil, B., Savolainen, T., 748 Bajko, G., and K. Iisakkila, "IPv6 in 3rd Generation 749 Partnership Project (3GPP) Evolved Packet System (EPS)", 750 RFC 6459, January 2012. 752 [RFC6535] Huang, B., Deng, H., and T. Savolainen, "Dual-Stack Hosts 753 Using "Bump-in-the-Host" (BIH)", RFC 6535, February 2012. 755 [RFC6877] Mawatari, M., Kawashima, M., and C. Byrne, "464XLAT: 756 Combination of Stateful and Stateless Translation", RFC 757 6877, April 2013. 759 [RFC7050] Savolainen, T., Korhonen, J., and D. Wing, "Discovery of 760 the IPv6 Prefix Used for IPv6 Address Synthesis", RFC 761 7050, November 2013. 763 [RFC7225] Boucadair, M., "Discovering NAT64 IPv6 Prefixes Using the 764 Port Control Protocol (PCP)", RFC 7225, May 2014. 766 [TR23.975] 767 3rd Generation Partnership Project, 3GPP., "IPv6 migration 768 guidelines", June 2011. 770 [TS23.003] 771 3rd Generation Partnership Project, 3GPP., "Numbering, 772 addressing and identification v9.0.0", September 2009. 774 [TS23.060] 775 3rd Generation Partnership Project, 3GPP., "General Packet 776 Radio Service (GPRS); Service description; Stage 2 v9.00", 777 March 2009. 779 [TS23.401] 780 3rd Generation Partnership Project, 3GPP., "General Packet 781 Radio Service (GPRS) enhancements for Evolved Universal 782 Terrestrial Radio Access Network (E-UTRAN) access v9.00", 783 March 2009. 785 [TS24.008] 786 3rd Generation Partnership Project, 3GPP., "Mobile radio 787 interface Layer 3 specification; Core network protocols; 788 Stage 3 v9.00", September 2009. 790 [TS24.301] 791 3rd Generation Partnership Project, 3GPP., "Non-Access- 792 Stratum (NAS) protocol for Evolved Packet System (EPS) ; 793 Stage 3 v9.00", September 2009. 795 [TS29.002] 796 3rd Generation Partnership Project, 3GPP., "Mobile 797 Application Part (MAP) specification v9.12.0", December 798 2009. 800 [TS29.212] 801 3rd Generation Partnership Project, 3GPP., "Policy and 802 Charging Control (PCC); Reference points v9.0.0", 803 September 2009. 805 [TS29.272] 806 3rd Generation Partnership Project, 3GPP., "Mobility 807 Management Entity (MME) and Serving GPRS Support Node 808 (SGSN) related interfaces based on Diameter protocol 809 v9.00", September 2009. 811 Authors' Addresses 813 Gang Chen 814 China Mobile 815 53A,Xibianmennei Ave., 816 Xuanwu District, 817 Beijing 100053 818 China 820 Email: phdgang@gmail.com 822 Hui Deng 823 China Mobile 824 53A,Xibianmennei Ave., 825 Xuanwu District, 826 Beijing 100053 827 China 829 Email: denghui@chinamobile.com 830 Dave Michaud 831 Rogers Communications 832 8200 Dixie Rd. 833 Brampton, ON L6T 0C1 834 Canada 836 Email: dave.michaud@rci.rogers.com 838 Jouni Korhonen 839 Broadcom 840 Porkkalankatu 24 841 FIN-00180 Helsinki, Finland 843 Email: jouni.nospam@gmail.com 845 Mohamed Boucadair 846 France Telecom 847 Rennes, 848 35000 849 France 851 Email: mohamed.boucadair@orange.com 853 Vizdal Ales 854 Deutsche Telekom AG 855 Tomickova 2144/1 856 Prague 4, 149 00 857 Czech Republic 859 Email: ales.vizdal@t-mobile.cz