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