idnits 2.17.1 draft-ietf-v6ops-mobile-device-profile-24.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 (December 17, 2015) is 3046 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- ** Obsolete normative reference: RFC 2460 (Obsoleted by RFC 8200) ** Obsolete normative reference: RFC 3633 (Obsoleted by RFC 8415) -- Obsolete informational reference (is this intentional?): RFC 6145 (Obsoleted by RFC 7915) -- Obsolete informational reference (is this intentional?): RFC 6434 (Obsoleted by RFC 8504) Summary: 2 errors (**), 0 flaws (~~), 1 warning (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group D. Binet 3 Internet-Draft M. Boucadair 4 Intended status: Informational Orange 5 Expires: June 19, 2016 A. Vizdal 6 Deutsche Telekom AG 7 G. Chen 8 China Mobile 9 N. Heatley 10 EE 11 R. Chandler 12 eircom | meteor 13 D. Michaud 14 Rogers Communications 15 D. Lopez 16 Telefonica I+D 17 W. Haeffner 18 Vodafone 19 December 17, 2015 21 An Internet Protocol Version 6 (IPv6) Profile for 3GPP Mobile Devices 22 draft-ietf-v6ops-mobile-device-profile-24 24 Abstract 26 This document defines a profile that is a superset of that of the 27 connection to IPv6 cellular networks defined in the IPv6 for Third 28 Generation Partnership Project (3GPP) Cellular Hosts document. This 29 document defines an IPv6 profile that a number of operators recommend 30 in order to connect 3GPP mobile devices to an IPv6-only or dual-stack 31 wireless network (including 3GPP cellular network) with a special 32 focus on IPv4 service continuity features. 34 Both mobile hosts and mobile devices with capability to share their 35 3GPP mobile connectivity are in scope. 37 Status of This Memo 39 This Internet-Draft is submitted in full conformance with the 40 provisions of BCP 78 and BCP 79. 42 Internet-Drafts are working documents of the Internet Engineering 43 Task Force (IETF). Note that other groups may also distribute 44 working documents as Internet-Drafts. The list of current Internet- 45 Drafts is at http://datatracker.ietf.org/drafts/current/. 47 Internet-Drafts are draft documents valid for a maximum of six months 48 and may be updated, replaced, or obsoleted by other documents at any 49 time. It is inappropriate to use Internet-Drafts as reference 50 material or to cite them other than as "work in progress." 52 This Internet-Draft will expire on June 19, 2016. 54 Copyright Notice 56 Copyright (c) 2015 IETF Trust and the persons identified as the 57 document authors. All rights reserved. 59 This document is subject to BCP 78 and the IETF Trust's Legal 60 Provisions Relating to IETF Documents 61 (http://trustee.ietf.org/license-info) in effect on the date of 62 publication of this document. Please review these documents 63 carefully, as they describe your rights and restrictions with respect 64 to this document. Code Components extracted from this document must 65 include Simplified BSD License text as described in Section 4.e of 66 the Trust Legal Provisions and are provided without warranty as 67 described in the Simplified BSD License. 69 Table of Contents 71 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 72 1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 4 73 1.2. Scope . . . . . . . . . . . . . . . . . . . . . . . . . . 4 74 2. Connectivity Recommendations . . . . . . . . . . . . . . . . 6 75 3. Recommendations for Cellular Devices with LAN Capabilities . 10 76 4. Advanced Recommendations . . . . . . . . . . . . . . . . . . 12 77 5. Security Considerations . . . . . . . . . . . . . . . . . . . 14 78 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15 79 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 15 80 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 15 81 8.1. Normative References . . . . . . . . . . . . . . . . . . 15 82 8.2. Informative References . . . . . . . . . . . . . . . . . 17 83 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 20 85 1. Introduction 87 IPv6 deployment in Third Generation Partnership Project (3GPP) mobile 88 networks is the only viable solution to the exhaustion of IPv4 89 addresses in those networks. Several mobile operators have already 90 deployed IPv6 [RFC2460] or are in the pre-deployment phase. One of 91 the major hurdles as perceived by some mobile operators is the lack 92 of availability of working IPv6 implementation in mobile devices 93 (e.g., Section 3.3 of [OECD]). 95 [RFC7066] lists a set of features to be supported by cellular hosts 96 to connect to 3GPP mobile networks. In the light of recent IPv6 97 production deployments, additional features to facilitate IPv6-only 98 deployments while accessing IPv4-only services should be considered. 99 This document fills this void. Concretely, this document lists means 100 to ensure IPv4 service over an IPv6-only connectivity given the 101 adoption rate of this model by mobile operators. Those operators 102 require that no service degradation is experienced by customers 103 serviced with an IPv6-only model compared to the level of service of 104 customers with legacy IPv4-only devices. 106 This document defines an IPv6 profile for mobile devices listing 107 specifications produced by various Standards Developing Organizations 108 (including 3GPP, IETF, and GSMA). The objectives of this effort are: 110 1. List in one single document a comprehensive list of IPv6 features 111 for a mobile device, including both IPv6-only and dual-stack 112 mobile deployment contexts. These features cover various packet 113 core architectures such as GPRS (General Packet Radio Service) or 114 EPC (Evolved Packet Core). 116 2. Help Operators with the detailed device requirement list 117 preparation (to be exchanged with device suppliers). This is 118 also a contribution to harmonize Operators' requirements towards 119 device vendors. 121 3. Vendors to be aware of a set of features to allow for IPv6 122 connectivity and IPv4 service continuity (over an IPv6-only 123 transport). 125 The recommendations do not include 3GPP release details. For more 126 information on the 3GPP releases detail, the reader may refer to 127 Section 6.2 of [RFC6459]. More details can be found at [R3GPP]. 129 Some of the features listed in this profile document could require to 130 activate dedicated functions at the network side. It is out of scope 131 of this document to list these network-side functions. 133 A detailed overview of IPv6 support in 3GPP architectures is provided 134 in [RFC6459]. IPv6-only considerations in mobile networks are 135 further discussed in [RFC6342]. 137 This document is organized as follows: 139 o Section 2 lists generic recommendations including functionalities 140 to provide IPv4 service over an IPv6-only connectivity. 142 o Section 3 enumerates a set of recommendations for cellular devices 143 with Local Area Network (LAN) capabilities (e.g., CE routers 144 (Customer Edge routers) with cellular access link, dongles with 145 tethering features). 147 o Section 4 identifies a set of advanced recommendations to fulfill 148 requirements of critical services such as VoLTE (Voice over Long 149 Term Evolution (LTE)). 151 1.1. Terminology 153 This document makes use of the terms defined in [RFC6459]. In 154 addition, the following terms are used: 156 o 3GPP cellular host (or cellular host for short): denotes a 3GPP 157 device which can be connected to 3GPP mobile networks. 159 o 3GPP cellular device (or cellular device for short): refers to a 160 cellular host which supports the capability to share its 3GPP 161 mobile connectivity. 163 o IPv4 service continuity: denotes the features used to provide 164 access to IPv4-only services to customers serviced with an 165 IPv6-only connectivity. A typical example of IPv4 service 166 continuity technique is NAT64 (Network Address and Protocol 167 Translation from IPv6 Clients to IPv4 Servers, [RFC6146]). 169 PREFIX64 denotes an IPv6 prefix used to build IPv4-converted IPv6 170 addresses [RFC6052]. 172 1.2. Scope 174 A 3GPP mobile network can be used to connect various user equipments 175 such as a mobile telephone or a CE router. Because of this diversity 176 of terminals, it is necessary to define a set of IPv6 functionalities 177 valid for any node directly connecting to a 3GPP mobile network. 178 This document describes these functionalities. 180 Machine-to-machine (M2M) devices profile is out of scope. 182 This document is structured to provide the generic IPv6 183 recommendations which are valid for all nodes, whatever their 184 function (e.g., host or CE router) or service (e.g., Session 185 Initiation Protocol (SIP, [RFC3261])) capability. The document also 186 contains sections covering specific functionalities for devices 187 providing some LAN functions (e.g., mobile CE router or broadband 188 dongles). 190 The recommendations listed below are valid for both 3GPP GPRS and 191 3GPP EPS (Evolved Packet System). For EPS, PDN-Connection term is 192 used instead of PDP-Context. Other non-3GPP accesses [TS.23402] are 193 out of scope of this document. 195 This profile is a superset of that of the IPv6 profile for 3GPP 196 Cellular Hosts [RFC7066], which is in turn a superset of IPv6 Node 197 Requirements [RFC6434]. It targets cellular nodes, including GPRS 198 and EPC (Evolved Packet Core), that require features to ensure IPv4 199 service delivery over an IPv6-only transport in addition to the base 200 IPv6 service. Moreover, this profile also covers cellular CE routers 201 that are used in various mobile broadband deployments. 202 Recommendations inspired from real deployment experiences (e.g., 203 roaming) are included in this profile. Also, this profile sketches 204 recommendations for the sake of deterministic behaviors of cellular 205 devices when the same configuration information is received over 206 several channels. 208 For conflicting recommendations in [RFC7066] and [RFC6434] (e.g., 209 Neighbor Discovery Protocol), this profile adheres to [RFC7066]. 210 Indeed, the support of Neighbor Discovery Protocol is mandatory in 211 3GPP cellular environment as it is the only way to convey IPv6 prefix 212 towards the 3GPP cellular device. In particular, MTU (Maximum 213 Transmission Unit) communication via Router Advertisement must be 214 supported since many 3GPP networks do not have a standard MTU 215 setting. 217 This profile uses a stronger language for the support of Prefix 218 Delegation compared to [RFC7066]. The main motivation is that 219 cellular networks are more and more perceived as an alternative to 220 fixed networks for home IP-based services delivery; especially with 221 the advent of smartphones and 3GPP data dongles. There is a need for 222 an efficient mechanism to assign larger prefixes to cellular hosts so 223 that each LAN segment can get its own /64 prefix and multi-link 224 subnet issues to be avoided. The support of this functionality in 225 both cellular and fixed networks is key for fixed-mobile convergence. 227 The use of address family dependent Application Programming 228 Interfaces (APIs) or hard-coded IPv4 address literals may lead to 229 broken applications when IPv6 connectivity is in use. As such, means 230 to minimize broken applications when the cellular host is attached to 231 an IPv6-only network should be encouraged. Particularly, (1) name 232 resolution libraries (e.g., [RFC3596]) must support both IPv4 and 233 IPv6; (2) applications must be independent of the underlying IP 234 address family; (3) and applications relying upon Uniform Resource 235 Identifiers (URIs) must follow [RFC3986] and its updates. Note, some 236 IETF specifications (e.g., SIP [RFC3261]) contains broken IPv6 237 Augmented Backus-Naur Form (ABNF) and rules to compare URIs with 238 embedded IPv6 addresses; fixes (e.g., [RFC5954]) must be used 239 instead. 241 The recommendations included in each section are listed in a priority 242 order. 244 This document is not a standard, and conformance with it is not 245 required in order to claim conformance with IETF standards for IPv6. 246 Compliance with this profile does not require the support of all 247 enclosed items. Obviously, the support of the full set of features 248 may not be required in some deployment contexts. However, the 249 authors believe that not supporting relevant features included in 250 this profile (e.g., Customer Side Translator (CLAT, [RFC6877])) may 251 lead to a degraded level of service. 253 2. Connectivity Recommendations 255 This section identifies the main connectivity recommendations to be 256 followed by a cellular host to attach to a network using IPv6 in 257 addition to what is defined in [RFC6434] and [RFC7066]. Both dual- 258 stack and IPv6-only deployment models are considered. IPv4 service 259 continuity features are listed in this section because these are 260 critical for Operators with an IPv6-only deployment model. These 261 recommendations apply also for cellular devices (see Section 3). 263 C_REC#1: In order to allow each operator to select their own 264 strategy regarding IPv6 introduction, the cellular host 265 must support both IPv6 and IPv4v6 PDP-Contexts [TS.23060]. 267 IPv4, IPv6 or IPv4v6 PDP-Context request acceptance depends 268 on the cellular network configuration. 270 C_REC#2: The cellular host must comply with the behavior defined in 271 [TS.23060] [TS.23401] [TS.24008] for requesting a PDP- 272 Context type. 274 In particular, the cellular host must request by default an 275 IPv6 PDP-Context if the cellular host is IPv6-only and 276 request an IPv4v6 PDP-Context if the cellular host is dual- 277 stack or when the cellular host is not aware of 278 connectivity types requested by devices connected to it 279 (e.g., cellular host with LAN capabilities as discussed in 280 Section 3): 282 * If the requested IPv4v6 PDP-Context is not supported by 283 the network, but IPv4 and IPv6 PDP types are allowed, 284 then the cellular host will be configured with an IPv4 285 address or an IPv6 prefix by the network. It must 286 initiate another PDP-Context activation of the other 287 address family in addition to the one already activated 288 for a given APN (Access Point Name). The purpose of 289 initiating a second PDP-Context is to achieve dual-stack 290 connectivity by means of two PDP-Contexts. 292 * If the subscription data or network configuration allows 293 only one IP address family (IPv4 or IPv6), the cellular 294 host must not request a second PDP-Context to the same 295 APN for the other IP address family. 297 The network informs the cellular host about allowed PDP 298 types by means of Session Management (SM) cause codes. In 299 particular, the following cause codes can be returned: 301 * cause #50 "PDP type IPv4 only allowed". This cause code 302 is used by the network to indicate that only PDP type 303 IPv4 is allowed for the requested PDN connectivity. 305 * cause #51 "PDP type IPv6 only allowed". This cause code 306 is used by the network to indicate that only PDP type 307 IPv6 is allowed for the requested PDN connectivity. 309 * cause #52 "single address bearers only allowed". This 310 cause code is used by the network to indicate that the 311 requested PDN connectivity is accepted with the 312 restriction that only single IP version bearers are 313 allowed. 315 The text above focuses on the specification (excerpt from 316 [TS.23060] [TS.23401] [TS.24008]) which explains the 317 behavior for requesting IPv6-related PDP-Context(s). 319 C_REC#3: The cellular host must support the PCO (Protocol 320 Configuration Options) [TS.24008] to retrieve the IPv6 321 address(es) of the Recursive DNS server(s). 323 The 3GPP network communicates parameters by means of the 324 protocol configuration options information element when 325 activating, modifying or deactivating a PDP-Context. 326 PCO is a convenient method to inform the cellular host 327 about various services, including DNS server 328 information. It does not require additional protocol to 329 be supported by the cellular host and it is already 330 deployed in IPv4 cellular networks to convey such DNS 331 information. 333 C_REC#4: The cellular host must support IPv6 aware Traffic Flow 334 Templates (TFT) [TS.24008]. 336 Traffic Flow Templates are employing a packet filter to 337 couple an IP traffic with a PDP-Context. Thus a 338 dedicated PDP-Context and radio resources can be 339 provided by the cellular network for certain IP traffic. 341 C_REC#5: If the cellular host receives the DNS information in 342 several channels for the same interface, the following 343 preference order must be followed: 345 1. PCO 347 2. RA 349 3. DHCPv6 351 The purpose of this recommendation is to guarantee for a 352 deterministic behavior to be followed by all cellular hosts 353 when the DNS information is received in various channels. 355 C_REC#6: Because of potential operational deficiencies to be 356 experienced in some roaming situations, the cellular host 357 must be able to be configured with a home PDP-Context 358 type(s) and a roaming PDP-Context type(s). The purpose of 359 the roaming profile is to limit the PDP type(s) requested 360 by the cellular host when out of the home network. Note 361 that distinct PDP type(s) and APN(s) can be configured for 362 home and roaming cases. 364 A detailed analysis of roaming failure cases is included 365 in [RFC7445]. 367 The configuration can be either local to the device or 368 be managed dynamically using, for example, Open Mobile 369 Alliance (OMA) management. The support of dynamic means 370 is encouraged. 372 C_REC#7: In order to ensure IPv4 service continuity in an IPv6-only 373 deployment context, the cellular host should support a 374 method to learn PREFIX64(s). 376 In the context of NAT64, IPv6-enabled applications 377 relying on address referrals will fail because an 378 IPv6-only client will not be able to make use of an IPv4 379 address received in a referral. This feature allows to 380 solve the referral problem (because an IPv6-enabled 381 application can construct IPv4-embedded IPv6 addresses 382 [RFC6052]) and, also, to distinguish between 383 IPv4-converted IPv6 addresses and native IPv6 addresses. 385 In other words, this feature contributes to offload both 386 CLAT module and NAT64 devices. Refer to Section 3 of 387 [RFC7051] for an inventory of the issues related to the 388 discovery of PREFIX64(s). 390 In PCP-based environments, cellular hosts should follow 391 [RFC7225] to learn the IPv6 Prefix used by an upstream 392 PCP-controlled NAT64 device. If PCP is not enabled, the 393 cellular host should implement the method specified in 394 [RFC7050] to retrieve the PREFIX64. 396 C_REC#8: In order to ensure IPv4 service continuity in an IPv6-only 397 deployment context, the cellular host should implement the 398 Customer Side Translator (CLAT, [RFC6877]) function in 399 compliance with [RFC6052][RFC6145][RFC6146]. 401 CLAT function in the cellular host allows for IPv4-only 402 application and IPv4-referals to work on an IPv6-only 403 connectivity. The more applications are address family 404 independent, the less CLAT function is solicited. CLAT 405 function requires a NAT64 capability [RFC6146] in the 406 network. 408 The cellular host should only invoke the CLAT in the 409 absence of the IPv4 connectivity on the cellular side, 410 i.e., when the network does not assign an IPv4 address 411 on the cellular interface. Note, NAT64 assumes an 412 IPv6-only mode [RFC6146]. 414 The IPv4 Service Continuity Prefix used by CLAT is 415 defined in [RFC7335]. 417 CLAT and/or NAT64 do not interfere with native IPv6 418 communications. 420 CLAT may not be required in some contexts, e.g., if 421 other solutions such as Bump-in-the-Host (BIH, 422 [RFC6535]) are supported. 424 The cellular device can act as a CE router connecting 425 various IP hosts on a LAN segment; it is also the case 426 with the use of WLAN (Wireless LAN) tethering or WLAN 427 hotspot from the cellular device. Some of these IP 428 hosts can be dual-stack, others are IPv6-only or 429 IPv4-only. IPv6-only connectivity on the cellular 430 device does not allow IPv4-only sessions to be 431 established for hosts connected on the LAN segment of 432 the cellular device. IPv4 session establishment 433 initiated from hosts located on LAN segment side and 434 destined for IPv4 nodes must be maintained. A solution 435 is to integrate the CLAT function to the LAN segment in 436 the cellular device. 438 C_REC#9: The cellular host may be able to be configured to limit PDP 439 type(s) for a given APN. The default mode is to allow all 440 supported PDP types. Note, C_REC#2 discusses the default 441 behavior for requesting PDP-Context type(s). 443 This feature is useful to drive the behavior of the UE 444 to be aligned with: (1) service-specific constraints 445 such as the use of IPv6-only for VoLTE (Voice over LTE), 446 (2) network conditions with regards to the support of 447 specific PDP types (e.g., IPv4v6 PDP-Context is not 448 supported), (3) IPv4 sunset objectives, (4) subscription 449 data, etc. 451 Note, a cellular host changing its connection between an 452 IPv6-specific APN and an IPv4-specific APN will 453 interrupt related network connections. This may be 454 considered as a brokenness situation by some 455 applications. 457 The configuration can be either local to the device or 458 be managed dynamically using, for example, Open Mobile 459 Alliance (OMA) management. The support of dynamic means 460 is encouraged. 462 3. Recommendations for Cellular Devices with LAN Capabilities 464 This section focuses on cellular devices (e.g., CE router, 465 smartphones or dongles with tethering features) which provide IP 466 connectivity to other devices connected to them. In such case, all 467 connected devices are sharing the same 2G, 3G or LTE connection. In 468 addition to the generic recommendations listed in Section 2, these 469 cellular devices have to meet the recommendations listed below. 471 L_REC#1: For deployments requiring to share the same /64 prefix, the 472 cellular device should support [RFC7278] to enable sharing 473 a /64 prefix between the 3GPP interface towards the GGSN/ 474 PGW (WAN interface) and the LAN interfaces. 476 Prefix Delegation (refer to L_REC#2) is the target 477 solution for distributing prefixes in the LAN side but, 478 because the device may attach to earlier 3GPP release 479 networks, a mean to share a /64 prefix is also 480 recommended [RFC7278]. 482 [RFC7278] must be invoked only if Prefix Delegation is 483 not in use. 485 L_REC#2: The cellular device must support Prefix Delegation 486 capabilities [RFC3633] and must support Prefix Exclude 487 Option for DHCPv6-based Prefix Delegation as defined in 488 [RFC6603]. Particularly, it must behave as a Requesting 489 Router. 491 Cellular networks are more and more perceived as an 492 alternative to fixed broadband networks for home IP- 493 based services delivery; especially with the advent of 494 smartphones and 3GPP data dongles. There is a need for 495 an efficient mechanism to assign larger prefixes (other 496 than /64s) to cellular hosts so that each LAN segment 497 can get its own /64 prefix and multi-link subnet issues 498 to be avoided. 500 In case a prefix is delegated to a cellular host using 501 DHCPv6, the cellular device will be configured with two 502 prefixes: 504 (1) one for 3GPP link allocated using stateless 505 address autoconfiguration (SLAAC) mechanism and 507 (2) another one delegated for LANs acquired during 508 Prefix Delegation operation. 510 Note that the 3GPP network architecture requires both 511 the WAN (Wide Area Network) and the delegated prefix to 512 be aggregatable, so the subscriber can be identified 513 using a single prefix. 515 Without the Prefix Exclude Option, the delegating router 516 (GGSN/PGW) will have to ensure [RFC3633] compliancy 517 (e.g., halving the delegated prefix and assigning the 518 WAN prefix out of the 1st half and the prefix to be 519 delegated to the terminal from the 2nd half). 521 Because Prefix Delegation capabilities may not be 522 available in some attached networks, L_REC#1 is strongly 523 recommended to accommodate early deployments. 525 L_REC#3: The cellular CE router must be compliant with the 526 requirements specified in [RFC7084]. 528 There are several deployments, particularly in emerging 529 countries, that relies on mobile networks to provide 530 broadband services (e.g., customers are provided with 531 mobile CE routers). 533 Note, this profile does not require IPv4 service 534 continuity techniques listed in Section 4.4 of [RFC7084] 535 because those are specific to fixed networks. IPv4 536 service continuity techniques specific to the mobile 537 networks are included in this profile. 539 This recommendation does not apply to handsets with 540 tethering capabilities; it is specific to cellular CE 541 routers in order to ensure the same IPv6 functional 542 parity for both fixed and cellular CE routers. Note, 543 modern CE routers are designed with advanced functions 544 such as link aggregation that consists in optimizing the 545 network usage by aggregating the connectivity resources 546 offered via various interfaces (e.g., Digital Subscriber 547 Line (DSL), LTE, WLAN, etc.) or offloading the traffic 548 via a subset of interfaces. Ensuring IPv6 features 549 parity among these interface types is important for the 550 sake of specification efficiency, service design 551 simplification and validation effort optimization. 553 L_REC#4: If a RA MTU is advertised from the 3GPP network, the 554 cellular device should send RAs to the downstream attached 555 LAN devices with the same MTU as seen on the mobile 556 interface. 558 Receiving and relaying RA MTU values facilitates a more 559 harmonious functioning of the mobile core network where 560 end nodes transmit packets that do not exceed the MTU 561 size of the mobile network's GTP (GPRS Tunnelling 562 Protocol) tunnels. 564 [TS.23060] indicates providing a link MTU value of 1358 565 octets to the 3GPP cellular device will prevent the IP 566 layer fragmentation within the transport network between 567 the cellular device and the GGSN/PGW. More details 568 about link MTU considerations can be found in Annex C of 569 [TS.23060]. 571 4. Advanced Recommendations 573 This section identifies a set of advanced recommendations to fulfill 574 requirements of critical services such as VoLTE. These 575 recommendations apply for mobile hosts, including mobile devices. 577 A_REC#1: The cellular host must support ROHC RTP Profile (0x0001) 578 and ROHC UDP Profile (0x0002) for IPv6 ([RFC5795]). Other 579 ROHC profiles may be supported. 581 Bandwidth in cellular networks must be optimized as much 582 as possible. ROHC provides a solution to reduce 583 bandwidth consumption and to reduce the impact of having 584 bigger packet headers in IPv6 compared to IPv4. 586 "RTP/UDP/IP" ROHC profile (0x0001) to compress RTP 587 packets and "UDP/IP" ROHC profile (0x0002) to compress 588 RTCP packets are required for Voice over LTE (VoLTE) by 589 IR.92.4.0 section 4.1 [IR92]. Note, [IR92] indicates 590 that the host must be able to apply the compression to 591 packets that are carried over the voice media dedicated 592 radio bearer. 594 A_REC#2: The cellular host should support PCP [RFC6887]. 596 The support of PCP is seen as a driver to save battery 597 consumption exacerbated by keepalive messages. PCP also 598 gives the possibility of enabling incoming connections 599 to the cellular device. Indeed, because several 600 stateful devices may be deployed in wireless networks 601 (e.g., NAT64 and/or IPv6 Firewalls), PCP can be used by 602 the cellular host to control network-based NAT64 and 603 IPv6 Firewall functions which will reduce per- 604 application signaling and save battery consumption. 606 According to [Power], the consumption of a cellular 607 device with a keep-alive interval equal to 20 seconds 608 (that is the default value in [RFC3948] for example) is 609 29 mA (2G)/34 mA (3G). This consumption is reduced to 610 16 mA (2G)/24 mA (3G) when the interval is increased to 611 40 seconds, to 9.1 mA (2G)/16 mA (3G) if the interval is 612 equal to 150 seconds, and to 7.3 mA (2G)/14 mA (3G) if 613 the interval is equal to 180 seconds. When no keep- 614 alive is issued, the consumption would be 5.2 mA 615 (2G)/6.1 mA (3G). The impact of keepalive messages 616 would be more severe if multiple applications are 617 issuing those messages (e.g., SIP, IPsec, etc.). 619 PCP allows to avoid embedding ALGs (Application Level 620 Gateways) at the network side (e.g., NAT64) to manage 621 protocols which convey IP addresses and/or port numbers 622 (see Section 2.2 of [RFC6889]). Avoiding soliciting 623 ALGs allows for more easiness to make evolve a service 624 independently of the underlying transport network. 626 A_REC#3: In order for host-based validation of DNS Security 627 Extensions (DNSSEC) to continue to function in an IPv6-only 628 connectivity with NAT64 deployment context, the cellular 629 host should embed a DNS64 function ([RFC6147]). 631 This is called "DNS64 in stub-resolver mode" in 632 [RFC6147]. 634 As discussed in Section 5.5 of [RFC6147], a security- 635 aware and validating host has to perform the DNS64 636 function locally. 638 Because synthetic AAAA records cannot be successfully 639 validated in a host, learning the PREFIX64 used to 640 construct IPv4-converted IPv6 addresses allows the use 641 of DNSSEC [RFC4033] [RFC4034], [RFC4035]. Means to 642 configure or discover a PREFIX64 are required on the 643 cellular device as discussed in C_REC#7. 645 [RFC7051] discusses why a security-aware and validating 646 host has to perform the DNS64 function locally and why 647 it has to be able to learn the proper PREFIX64(s). 649 A_REC#4: When the cellular host is dual-stack connected (i.e., 650 configured with an IPv4 address and IPv6 prefix), it should 651 support means to prefer native IPv6 connection over 652 connection established through translation devices (e.g., 653 NAT44 and NAT64). 655 When both IPv4 and IPv6 DNS servers are configured, a 656 dual-stack host must contact first its IPv6 DNS server. 657 This preference allows to offload IPv4-only DNS servers. 659 Cellular hosts should follow the procedure specified in 660 [RFC6724] for source address selection. 662 5. Security Considerations 664 The security considerations identified in [RFC7066] and [RFC6459] are 665 to be taken into account. 667 In the case of cellular CE routers, compliance with L_REC#3 entails 668 compliance with [RFC7084], which in turn recommends compliance with 669 Recommended Simple Security Capabilities in Customer Premises 670 Equipment (CPE) for Providing Residential IPv6 Internet Service 671 [RFC6092]. Therefore, the security considerations in Section 6 of 672 [RFC6092] are relevant. In particular, it bears repeating here that 673 the true impact of stateful filtering may be a reduction in security, 674 and that IETF make no statement, expressed or implied, as to whether 675 using the capabilities described in any of these documents ultimately 676 improves security for any individual users or for the Internet 677 community as a whole. 679 The cellular host must be able to generate IPv6 addresses which 680 preserve privacy. The activation of privacy extension (e.g., using 681 [RFC7217]) makes it more difficult to track a host over time when 682 compared to using a permanent Interface Identifier. Tracking a host 683 is still possible based on the first 64 bits of the IPv6 address. 684 Means to prevent against such tracking issues may be enabled in the 685 network side. Note, privacy extensions are required by regulatory 686 bodies in some countries. 688 Host-based validation of DNSSEC is discussed in A_REC#3 (see 689 Section 4). 691 6. IANA Considerations 693 This document does not require any action from IANA. 695 7. Acknowledgements 697 Many thanks to C. Byrne, H. Soliman, H. Singh, L. Colliti, T. Lemon, 698 B. Sarikaya, M. Mawatari, M. Abrahamsson, P. Vickers, V. Kuarsingh, 699 E. Kline, S. Josefsson, A. Baryun, J. Woodyatt, T. Kossut, B. Stark, 700 and A. Petrescu for the discussion in the v6ops mailing list and for 701 the comments. 703 Thanks to A. Farrel, B. Haberman, and K. Moriarty for the comments 704 during the IESG review. 706 Special thanks to T. Savolainen, J. Korhonen, J. Jaeggli, F. Baker, 707 L.M. Contreras Murillo, and M. Abrahamsson for their detailed reviews 708 and comments. 710 8. References 712 8.1. Normative References 714 [IR92] GSMA, "IR.92.V4.0 - IMS Profile for Voice and SMS", March 715 2011, . 718 [RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6 719 (IPv6) Specification", RFC 2460, DOI 10.17487/RFC2460, 720 December 1998, . 722 [RFC3596] Thomson, S., Huitema, C., Ksinant, V., and M. Souissi, 723 "DNS Extensions to Support IP Version 6", RFC 3596, 724 DOI 10.17487/RFC3596, October 2003, 725 . 727 [RFC3633] Troan, O. and R. Droms, "IPv6 Prefix Options for Dynamic 728 Host Configuration Protocol (DHCP) version 6", RFC 3633, 729 DOI 10.17487/RFC3633, December 2003, 730 . 732 [RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform 733 Resource Identifier (URI): Generic Syntax", STD 66, 734 RFC 3986, DOI 10.17487/RFC3986, January 2005, 735 . 737 [RFC5795] Sandlund, K., Pelletier, G., and L-E. Jonsson, "The RObust 738 Header Compression (ROHC) Framework", RFC 5795, 739 DOI 10.17487/RFC5795, March 2010, 740 . 742 [RFC5954] Gurbani, V., Ed., Carpenter, B., Ed., and B. Tate, Ed., 743 "Essential Correction for IPv6 ABNF and URI Comparison in 744 RFC 3261", RFC 5954, DOI 10.17487/RFC5954, August 2010, 745 . 747 [RFC6052] Bao, C., Huitema, C., Bagnulo, M., Boucadair, M., and X. 748 Li, "IPv6 Addressing of IPv4/IPv6 Translators", RFC 6052, 749 DOI 10.17487/RFC6052, October 2010, 750 . 752 [RFC6603] Korhonen, J., Ed., Savolainen, T., Krishnan, S., and O. 753 Troan, "Prefix Exclude Option for DHCPv6-based Prefix 754 Delegation", RFC 6603, DOI 10.17487/RFC6603, May 2012, 755 . 757 [RFC7066] Korhonen, J., Ed., Arkko, J., Ed., Savolainen, T., and S. 758 Krishnan, "IPv6 for Third Generation Partnership Project 759 (3GPP) Cellular Hosts", RFC 7066, DOI 10.17487/RFC7066, 760 November 2013, . 762 [TS.23060] 763 3GPP, "General Packet Radio Service (GPRS); Service 764 description; Stage 2", September 2011, 765 . 767 [TS.23401] 768 3GPP, "General Packet Radio Service (GPRS) enhancements 769 for Evolved Universal Terrestrial Radio Access Network 770 (E-UTRAN) access", September 2011, 771 . 773 [TS.24008] 774 3GPP, "Mobile radio interface Layer 3 specification; Core 775 network protocols; Stage 3", June 2011, 776 . 778 8.2. Informative References 780 [OECD] Organisation for Economic Cooperation and Development 781 (OECD), "The Economics of the Transition to Internet 782 Protocol version 6 (IPv6)", November 2014, . 786 [Power] Haverinen, H., Siren, J., and P. Eronen, "Energy 787 Consumption of Always-On Applications in WCDMA Networks", 788 April 2007, . 791 [R3GPP] 3GPP, "The Mobile Broadband Standard, Releases", 2015, 792 . 794 [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, 795 A., Peterson, J., Sparks, R., Handley, M., and E. 796 Schooler, "SIP: Session Initiation Protocol", RFC 3261, 797 DOI 10.17487/RFC3261, June 2002, 798 . 800 [RFC3948] Huttunen, A., Swander, B., Volpe, V., DiBurro, L., and M. 801 Stenberg, "UDP Encapsulation of IPsec ESP Packets", 802 RFC 3948, DOI 10.17487/RFC3948, January 2005, 803 . 805 [RFC4033] Arends, R., Austein, R., Larson, M., Massey, D., and S. 806 Rose, "DNS Security Introduction and Requirements", 807 RFC 4033, DOI 10.17487/RFC4033, March 2005, 808 . 810 [RFC4034] Arends, R., Austein, R., Larson, M., Massey, D., and S. 811 Rose, "Resource Records for the DNS Security Extensions", 812 RFC 4034, DOI 10.17487/RFC4034, March 2005, 813 . 815 [RFC4035] Arends, R., Austein, R., Larson, M., Massey, D., and S. 816 Rose, "Protocol Modifications for the DNS Security 817 Extensions", RFC 4035, DOI 10.17487/RFC4035, March 2005, 818 . 820 [RFC6092] Woodyatt, J., Ed., "Recommended Simple Security 821 Capabilities in Customer Premises Equipment (CPE) for 822 Providing Residential IPv6 Internet Service", RFC 6092, 823 DOI 10.17487/RFC6092, January 2011, 824 . 826 [RFC6145] Li, X., Bao, C., and F. Baker, "IP/ICMP Translation 827 Algorithm", RFC 6145, DOI 10.17487/RFC6145, April 2011, 828 . 830 [RFC6146] Bagnulo, M., Matthews, P., and I. van Beijnum, "Stateful 831 NAT64: Network Address and Protocol Translation from IPv6 832 Clients to IPv4 Servers", RFC 6146, DOI 10.17487/RFC6146, 833 April 2011, . 835 [RFC6147] Bagnulo, M., Sullivan, A., Matthews, P., and I. van 836 Beijnum, "DNS64: DNS Extensions for Network Address 837 Translation from IPv6 Clients to IPv4 Servers", RFC 6147, 838 DOI 10.17487/RFC6147, April 2011, 839 . 841 [RFC6342] Koodli, R., "Mobile Networks Considerations for IPv6 842 Deployment", RFC 6342, DOI 10.17487/RFC6342, August 2011, 843 . 845 [RFC6434] Jankiewicz, E., Loughney, J., and T. Narten, "IPv6 Node 846 Requirements", RFC 6434, DOI 10.17487/RFC6434, December 847 2011, . 849 [RFC6459] Korhonen, J., Ed., Soininen, J., Patil, B., Savolainen, 850 T., Bajko, G., and K. Iisakkila, "IPv6 in 3rd Generation 851 Partnership Project (3GPP) Evolved Packet System (EPS)", 852 RFC 6459, DOI 10.17487/RFC6459, January 2012, 853 . 855 [RFC6535] Huang, B., Deng, H., and T. Savolainen, "Dual-Stack Hosts 856 Using "Bump-in-the-Host" (BIH)", RFC 6535, 857 DOI 10.17487/RFC6535, February 2012, 858 . 860 [RFC6724] Thaler, D., Ed., Draves, R., Matsumoto, A., and T. Chown, 861 "Default Address Selection for Internet Protocol Version 6 862 (IPv6)", RFC 6724, DOI 10.17487/RFC6724, September 2012, 863 . 865 [RFC6877] Mawatari, M., Kawashima, M., and C. Byrne, "464XLAT: 866 Combination of Stateful and Stateless Translation", 867 RFC 6877, DOI 10.17487/RFC6877, April 2013, 868 . 870 [RFC6887] Wing, D., Ed., Cheshire, S., Boucadair, M., Penno, R., and 871 P. Selkirk, "Port Control Protocol (PCP)", RFC 6887, 872 DOI 10.17487/RFC6887, April 2013, 873 . 875 [RFC6889] Penno, R., Saxena, T., Boucadair, M., and S. Sivakumar, 876 "Analysis of Stateful 64 Translation", RFC 6889, 877 DOI 10.17487/RFC6889, April 2013, 878 . 880 [RFC7050] Savolainen, T., Korhonen, J., and D. Wing, "Discovery of 881 the IPv6 Prefix Used for IPv6 Address Synthesis", 882 RFC 7050, DOI 10.17487/RFC7050, November 2013, 883 . 885 [RFC7051] Korhonen, J., Ed. and T. Savolainen, Ed., "Analysis of 886 Solution Proposals for Hosts to Learn NAT64 Prefix", 887 RFC 7051, DOI 10.17487/RFC7051, November 2013, 888 . 890 [RFC7084] Singh, H., Beebee, W., Donley, C., and B. Stark, "Basic 891 Requirements for IPv6 Customer Edge Routers", RFC 7084, 892 DOI 10.17487/RFC7084, November 2013, 893 . 895 [RFC7217] Gont, F., "A Method for Generating Semantically Opaque 896 Interface Identifiers with IPv6 Stateless Address 897 Autoconfiguration (SLAAC)", RFC 7217, 898 DOI 10.17487/RFC7217, April 2014, 899 . 901 [RFC7225] Boucadair, M., "Discovering NAT64 IPv6 Prefixes Using the 902 Port Control Protocol (PCP)", RFC 7225, 903 DOI 10.17487/RFC7225, May 2014, 904 . 906 [RFC7278] Byrne, C., Drown, D., and A. Vizdal, "Extending an IPv6 907 /64 Prefix from a Third Generation Partnership Project 908 (3GPP) Mobile Interface to a LAN Link", RFC 7278, 909 DOI 10.17487/RFC7278, June 2014, 910 . 912 [RFC7335] Byrne, C., "IPv4 Service Continuity Prefix", RFC 7335, 913 DOI 10.17487/RFC7335, August 2014, 914 . 916 [RFC7445] Chen, G., Deng, H., Michaud, D., Korhonen, J., and M. 917 Boucadair, "Analysis of Failure Cases in IPv6 Roaming 918 Scenarios", RFC 7445, DOI 10.17487/RFC7445, March 2015, 919 . 921 [TS.23402] 922 3GPP, "Architecture enhancements for non-3GPP accesses", 923 September 2011, 924 . 926 Authors' Addresses 928 David Binet 929 Orange 930 Rennes 931 France 933 EMail: david.binet@orange.com 935 Mohamed Boucadair 936 Orange 937 Rennes 35000 938 France 940 EMail: mohamed.boucadair@orange.com 942 Ales Vizdal 943 Deutsche Telekom AG 945 EMail: ales.vizdal@t-mobile.cz 947 Gang Chen 948 China Mobile 950 EMail: phdgang@gmail.com 951 Nick Heatley 952 EE 953 The Point, 37 North Wharf Road, 954 London W2 1AG 955 U.K 957 EMail: nick.heatley@ee.co.uk 959 Ross Chandler 960 eircom | meteor 961 1HSQ 962 St. John's Road 963 Dublin 8 964 Ireland 966 EMail: ross@eircom.net 968 Dave Michaud 969 Rogers Communications 970 8200 Dixie Rd. 971 Brampton, ON L6T 0C1 972 Canada 974 EMail: dave.michaud@rci.rogers.com 976 Diego R. Lopez 977 Telefonica I+D 978 Don Ramon de la Cruz, 82 979 Madrid 28006 980 Spain 982 Phone: +34 913 129 041 983 EMail: diego.r.lopez@telefonica.com 985 Walter Haeffner 986 Vodafone D2 GmbH 987 Ferdinand-Braun-Platz 1 988 Duesseldorf 40549 989 DE 991 EMail: walter.haeffner@vodafone.com