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