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