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