idnits 2.17.1 draft-ietf-v6ops-mobile-device-profile-17.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 12, 2015) is 3354 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 16, 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 February 12, 2015 15 An Internet Protocol Version 6 (IPv6) Profile for 3GPP Mobile Devices 16 draft-ietf-v6ops-mobile-device-profile-17 18 Abstract 20 This document defines a profile that is a superset of that of the 21 connection to IPv6 cellular networks defined in the IPv6 for Third 22 Generation Partnership Project (3GPP) Cellular Hosts document. This 23 document defines an IPv6 profile that a number of operators recommend 24 in order to connect 3GPP mobile devices to an IPv6-only or dual-stack 25 wireless network (including 3GPP cellular network and IEEE 802.11 26 network) with a special focus on IPv4 service continuity features. 28 Both hosts and devices with capability to share their WAN (Wide Area 29 Network) connectivity are in scope. 31 Status of This Memo 33 This Internet-Draft is submitted in full conformance with the 34 provisions of BCP 78 and BCP 79. 36 Internet-Drafts are working documents of the Internet Engineering 37 Task Force (IETF). Note that other groups may also distribute 38 working documents as Internet-Drafts. The list of current Internet- 39 Drafts is at http://datatracker.ietf.org/drafts/current/. 41 Internet-Drafts are draft documents valid for a maximum of six months 42 and may be updated, replaced, or obsoleted by other documents at any 43 time. It is inappropriate to use Internet-Drafts as reference 44 material or to cite them other than as "work in progress." 46 This Internet-Draft will expire on August 16, 2015. 48 Copyright Notice 50 Copyright (c) 2015 IETF Trust and the persons identified as the 51 document authors. All rights reserved. 53 This document is subject to BCP 78 and the IETF Trust's Legal 54 Provisions Relating to IETF Documents 55 (http://trustee.ietf.org/license-info) in effect on the date of 56 publication of this document. Please review these documents 57 carefully, as they describe your rights and restrictions with respect 58 to this document. Code Components extracted from this document must 59 include Simplified BSD License text as described in Section 4.e of 60 the Trust Legal Provisions and are provided without warranty as 61 described in the Simplified BSD License. 63 Table of Contents 65 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 66 1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3 67 1.2. Scope . . . . . . . . . . . . . . . . . . . . . . . . . . 4 68 2. Connectivity Recommendations . . . . . . . . . . . . . . . . 5 69 2.1. WLAN Connectivity Recommendations . . . . . . . . . . . . 8 70 3. Advanced Recommendations . . . . . . . . . . . . . . . . . . 8 71 4. Recommendations for Cellular Devices with LAN Capabilities . 10 72 5. APIs & Applications Recommendations . . . . . . . . . . . . . 12 73 6. Security Considerations . . . . . . . . . . . . . . . . . . . 13 74 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13 75 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 13 76 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 14 77 9.1. Normative References . . . . . . . . . . . . . . . . . . 14 78 9.2. Informative References . . . . . . . . . . . . . . . . . 15 80 1. Introduction 82 IPv6 deployment in 3GPP mobile networks is the only perennial 83 solution to the exhaustion of IPv4 addresses in those networks. 84 Several mobile operators have already deployed IPv6 [RFC2460] or are 85 in the pre-deployment phase. One of the major hurdles as perceived 86 by some mobile operators is the availability of non-broken IPv6 87 implementation in mobile devices (e.g., Section 3.3 of [OECD]). 89 [RFC7066] lists a set of features to be supported by cellular hosts 90 to connect to 3GPP mobile networks. In the light of recent IPv6 91 production deployments, additional features to facilitate IPv6-only 92 deployments while accessing IPv4-only service are to be considered. 94 This document defines an IPv6 profile for mobile devices listing 95 specifications produced by various Standards Developing Organizations 96 (in particular 3GPP and IETF). The objectives of this effort are: 98 1. List in one single document a comprehensive list of IPv6 features 99 for a mobile device, including both IPv6-only and dual-stack 100 mobile deployment contexts. These features cover various network 101 types such as GPRS (General Packet Radio Service), EPC (Evolved 102 Packet Core) or IEEE 802.11 network. 104 2. Help Operators with the detailed device requirement list 105 preparation (to be exchanged with device suppliers). This is 106 also a contribution to harmonize Operators' requirements towards 107 device vendors. 109 3. Vendors to be aware of a set of features to allow for IPv6 110 connectivity and IPv4 service continuity (over an IPv6-only 111 transport). 113 The recommendations do not include 3GPP release details. For more 114 information on the 3GPP releases detail, the reader may refer to 115 Section 6.2 of [RFC6459]. 117 Some of the features listed in this profile document require to 118 activate dedicated functions at the network side. It is out of scope 119 of this document to list these network-side functions. 121 A detailed overview of IPv6 support in 3GPP architectures is provided 122 in [RFC6459]. 124 1.1. Terminology 126 This document makes use of the terms defined in [RFC6459]. In 127 addition, the following terms are used: 129 o "3GPP cellular host" (or cellular host for short) denotes a 3GPP 130 device which can be connected to 3GPP mobile networks or IEEE 131 802.11 networks. 133 o "3GPP cellular device" (or cellular device for short) refers to a 134 cellular host which supports the capability to share its WAN (Wide 135 Area Network) connectivity. 137 o "Cellular host" and "mobile host" are used interchangeably. 139 o "Cellular device" and "mobile device" are used interchangeably. 141 PREFIX64 denotes an IPv6 prefix used to build IPv4-converted IPv6 142 addresses [RFC6052]. 144 1.2. Scope 146 A 3GPP mobile network can be used to connect various user equipments 147 such as a mobile telephone, a CPE (Customer Premises Equipment) or a 148 machine-to-machine (M2M) device. Because of this diversity of 149 terminals, it is necessary to define a set of IPv6 functionalities 150 valid for any node directly connecting to a 3GPP mobile network. 151 This document describes these functionalities. 153 This document is structured to provide the generic IPv6 154 recommendations which are valid for all nodes, whatever their 155 function (e.g., host or CPE) or service (e.g., Session Initiation 156 Protocol (SIP, [RFC3261])) capability. The document also contains 157 sections covering specific functionalities for devices providing some 158 LAN functions (e.g., mobile CPE or broadband dongles). 160 The recommendations listed below are valid for both 3GPP GPRS and 161 3GPP EPS (Evolved Packet System) access. For EPS, PDN-Connection 162 term is used instead of PDP-Context. 164 This document identifies also some WLAN-related IPv6 recommendations. 165 Other non-3GPP accesses [TS.23402] are out of scope of this document. 167 This profile is a superset of that of the IPv6 profile for 3GPP 168 Cellular Hosts [RFC7066], which is in turn a superset of IPv6 Node 169 Requirements [RFC6434]. It targets cellular nodes, including GPRS, 170 EPC (Evolved Packet Core) and IEEE 802.11 networks, that require 171 features to ensure IPv4 service delivery over an IPv6-only transport 172 in addition to the base IPv6 service. Moreover, this profile covers 173 cellular CPEs that are used in various deployments to offer fixed- 174 like services. Recommendations inspired from real deployment 175 experiences (e.g., roaming) are included in this profile. Also, this 176 profile sketches recommendations for the sake of deterministic 177 behaviors of cellular devices when the same configuration information 178 is received over several channels. 180 For conflicting recommendations in [RFC7066] and [RFC6434] (e.g., 181 Neighbor Discovery Protocol), this profile adheres to [RFC7066]. 182 Indeed, the support of Neighbor Discovery Protocol is mandatory in 183 3GPP cellular environment as it is the only way to convey IPv6 prefix 184 towards the 3GPP cellular device. In particular, MTU (Maximum 185 Transmission Unit) communication via Router Advertisement must be 186 supported since many 3GPP networks do not have a standard MTU 187 setting. 189 This profile uses a stronger language for the support of Prefix 190 Delegation compared to [RFC7066]. The main motivation is that 191 cellular networks are more and more perceived as an alternative to 192 fixed networks for home IP-based services delivery; especially with 193 the advent of smartphones and 3GPP data dongles. There is a need for 194 an efficient mechanism to assign shorter prefix than /64 to cellular 195 hosts so that each LAN segment can get its own /64 prefix and multi- 196 link subnet issues to be avoided. The support of this functionality 197 in both cellular and fixed networks is key for fixed-mobile 198 convergence. 200 This document is not a standard, and conformance with it is not 201 required in order to claim conformance with IETF standards for IPv6. 202 The support of the full set of features may not be required in some 203 deployment contexts. The authors believe that the support of a 204 subset of the features included in this protocol may lead to degraded 205 level of service in some deployment contexts. 207 2. Connectivity Recommendations 209 This section identifies the main connectivity recommendations to be 210 followed by a cellular host to attach to a network using IPv6. Both 211 dual-stack and IPv6-only deployment models are considered. IPv4 212 service continuity features are listed in this section because these 213 are critical for Operators with an IPv6-only deployment model. 215 C_REC#1: In order to allow each operator to select their own 216 strategy regarding IPv6 introduction, the cellular host 217 must support both IPv6 and IPv4v6 PDP-Contexts [TS.23060]. 218 Both IPv6 and IPv4v6 PDP-Contexts must be supported. IPv4, 219 IPv6 or IPv4v6 PDP-Context request acceptance depends on 220 the cellular network configuration. 222 C_REC#2: The cellular host must comply with the behavior defined in 223 [TS.23060] [TS.23401] [TS.24008] for requesting a PDP- 224 Context type. In particular, the cellular host must 225 request by default an IPv6 PDP-Context if the cellular host 226 is IPv6-only and requesting an IPv4v6 PDP-Context if the 227 cellular host is dual-stack or when the cellular host is 228 not aware of connectivity types requested by devices 229 connected to it (e.g., cellular host with LAN capabilities 230 as discussed in Section 4): 232 * If the requested IPv4v6 PDP-Context is not supported by 233 the network, but IPv4 and IPv6 PDP types are allowed, 234 then the cellular host will be configured with an IPv4 235 address or an IPv6 prefix by the network. It must 236 initiate another PDP-Context activation in addition to 237 the one already activated for a given APN (Access Point 238 Name). 240 * If the requested PDP type and subscription data allows 241 only one IP address family (IPv4 or IPv6), the cellular 242 host must not request a second PDP-Context to the same 243 APN for the other IP address family. 245 The text above focuses on the specification part which 246 explains the behavior for requesting IPv6-related PDP- 247 Context(s). Understanding this behavior is important to 248 avoid having broken IPv6 implementations in cellular 249 devices. 251 C_REC#3: The cellular host must support the PCO (Protocol 252 Configuration Options) [TS.24008] to retrieve the IPv6 253 address(es) of the Recursive DNS server(s). 255 In-band signaling is a convenient method to inform the 256 cellular host about various services, including DNS 257 server information. It does not require any specific 258 protocol to be supported and it is already deployed in 259 IPv4 cellular networks to convey such DNS information. 261 C_REC#4: The cellular host must support IPv6 aware Traffic Flow 262 Templates (TFT) [TS.24008]. 264 Traffic Flow Templates are employing a packet filter to 265 couple an IP traffic with a PDP-Context. Thus a 266 dedicated PDP-Context and radio resources can be 267 provided by the cellular network for certain IP traffic. 269 C_REC#5: If the cellular host receives the DNS information in 270 several channels for the same interface, the following 271 preference order must be followed: 273 1. PCO 275 2. RA 277 3. DHCPv6 279 C_REC#6: The cellular host must be able to be configured to limit 280 PDP type(s) for a given APN. The default mode is to allow 281 all supported PDP types. Note, C_REC#2 discusses the 282 default behavior for requesting PDP-Context type(s). 284 This feature is useful to drive the behavior of the UE 285 to be aligned with: (1) service-specific constraints 286 such as the use of IPv6-only for VoLTE (Voice over LTE), 287 (2) network conditions with regards to the support of 288 specific PDP types (e.g., IPv4v6 PDP-Context is not 289 supported), (3) IPv4 sunset objectives, (4) subscription 290 data, etc. 292 Note, a cellular host changing its connection between an 293 IPv6-specific APN and an IPv4-specific APN restarts the 294 ongoing applications. This is a brokenness situation. 296 C_REC#7: Because of potential operational deficiencies to be 297 experienced in some roaming situations, the cellular host 298 must be able to be configured with a home IP profile and a 299 roaming IP profile. The aim of the roaming profile is to 300 limit the PDP type(s) requested by the cellular host when 301 out of the home network. Note that distinct PDP type(s) 302 and APN(s) can be configured for home and roaming cases. 304 C_REC#8: In order to ensure IPv4 service continuity in an IPv6-only 305 deployment context, the cellular host should support a 306 method to locally construct IPv4-embedded IPv6 addresses 307 [RFC6052]. A method to learn PREFIX64 should be supported 308 by the cellular host. 310 This solves the issue when applications use IPv4 311 referrals on IPv6-only access networks. 313 In PCP-based environments, cellular hosts should follow 314 [RFC7225] to learn the IPv6 Prefix used by an upstream 315 PCP-controlled NAT64 device. If PCP is not enabled, the 316 cellular host should implement the method specified in 317 [RFC7050] to retrieve the PREFIX64. 319 C_REC#9: In order to ensure IPv4 service continuity in an IPv6-only 320 deployment context, the cellular host should implement the 321 Customer Side Translator (CLAT, [RFC6877]) function which 322 is compliant with [RFC6052][RFC6145][RFC6146]. 324 CLAT function in the cellular host allows for IPv4-only 325 application and IPv4-referals to work on an IPv6-only 326 connectivity. CLAT function requires a NAT64 capability 327 [RFC6146] in the core network. 329 The IPv4 Service Continuity Prefix used by CLAT is 330 defined in [RFC7335]. 332 2.1. WLAN Connectivity Recommendations 334 It is increasingly common for cellular hosts have a WLAN interface in 335 addition to their cellular interface. These hosts are likely to be 336 connected to private or public hotspots. Below are listed some 337 generic recommendations: 339 W_REC#1: IPv6 must be supported on the WLAN interface. In 340 particular, WLAN interface must behave properly when only 341 an IPv6 connectivity is provided. 343 Some tests revealed that IPv4 configuration is required 344 to enable IPv6-only connectivity. Indeed, some cellular 345 handsets can access a WLAN IPv6-only network by 346 configuring first a static IPv4 address. Once the 347 device is connected to the network and the wlan0 348 interface got an IPv6 global address, the IPv4 address 349 can be deleted from the configuration. This avoids the 350 device to ask automatically for a DHCPv4 server, and 351 allows to connect to IPv6-only networks. Failing to 352 configure an IPv4 address on the interface must not 353 prohibit using IPv6 on the same interface. 355 W_REC#2: If the device receives the DNS information in several 356 channels for the same interface, the following preference 357 order must be followed: 359 1. RA 361 2. DHCPv6 363 3. Advanced Recommendations 365 This section identifies a set of advanced recommendations to fulfill 366 requirements of critical services such as VoLTE. 368 A_REC#1: The cellular host must support ROHC RTP Profile (0x0001) 369 and ROHC UDP Profile (0x0002) for IPv6 ([RFC5795]). Other 370 ROHC profiles may be supported. 372 Bandwidth in cellular networks must be optimized as much 373 as possible. ROHC provides a solution to reduce 374 bandwidth consumption and to reduce the impact of having 375 bigger packet headers in IPv6 compared to IPv4. 377 "RTP/UDP/IP" ROHC profile (0x0001) to compress RTP 378 packets and "UDP/IP" ROHC profile (0x0002) to compress 379 RTCP packets are required for Voice over LTE (VoLTE) by 380 IR.92.4.0 section 4.1 [IR92]. Note, [IR92] indicates 381 also the host must be able to apply the compression to 382 packets that are carried over the radio bearer dedicated 383 for the voice media. 385 A_REC#2: The cellular host should support PCP [RFC6887]. 387 The support of PCP is seen as a driver to save battery 388 consumption exacerbated by keepalive messages. PCP also 389 gives the possibility of enabling incoming connections 390 to the cellular device. Indeed, because several 391 stateful devices may be deployed in wireless networks 392 (e.g., NAT and/or Firewalls), PCP can be used by the 393 cellular host to control network-based NAT and Firewall 394 functions which will reduce per-application signaling 395 and save battery consumption. 397 According to [Power], the consumption of a cellular 398 device with a keep-alive interval equal to 20 seconds 399 (that is the default value in [RFC3948] for example) is 400 29 mA (2G)/34 mA (3G). This consumption is reduced to 401 16 mA (2G)/24 mA (3G) when the interval is increased to 402 40 seconds, to 9.1 mA (2G)/16 mA (3G) if the interval is 403 equal to 150 seconds, and to 7.3 mA (2G)/14 mA (3G) if 404 the interval is equal to 180 seconds. When no keep- 405 alive is issued, the consumption would be 5.2 mA 406 (2G)/6.1 mA (3G). The impact of keepalive messages 407 would be more severe if multiple applications are 408 issuing those messages (e.g., SIP, IPsec, etc.). 410 A_REC#3: In order for host-based validation of DNS Security 411 Extensions (DNSSEC) to continue to function in an IPv6-only 412 with NAT64 deployment context, the cellular host should 413 embed a DNS64 function ([RFC6147]). 415 This is called "DNS64 in stub-resolver mode" in 416 [RFC6147]. 418 As discussed in Section 5.5 of [RFC6147], a security- 419 aware and validating host has to perform the DNS64 420 function locally. 422 Because synthetic AAAA records cannot be successfully 423 validated in a host, learning the PREFIX64 used to 424 construct IPv4-converted IPv6 addresses allows the use 425 of DNSSEC [RFC4033] [RFC4034], [RFC4035]. Means to 426 configure or discover a PREFIX64 are required on the 427 cellular device as discussed in C_REC#8. 429 [RFC7051] discusses why a security-aware and validating 430 host has to perform the DNS64 function locally and why 431 it has to be able to learn the proper PREFIX64(s). 433 A_REC#4: When the cellular host is dual-stack connected (i.e., 434 configured with an IPv4 address and IPv6 prefix), it should 435 support means to prefer native IPv6 connection over 436 connection established through translation devices (e.g., 437 NAT44 and NAT64). 439 When both IPv4 and IPv6 DNS servers are configured, a 440 dual-stack host must contact first its IPv6 DNS server. 442 Cellular hosts should follow the procedure specified in 443 [RFC6724] for source address selection. 445 4. Recommendations for Cellular Devices with LAN Capabilities 447 This section focuses on cellular devices (e.g., CPE, smartphones, or 448 dongles with tethering features) which provide IP connectivity to 449 other devices connected to them. In such case, all connected devices 450 are sharing the same 2G, 3G or LTE connection. In addition to the 451 generic recommendations listed in Section 2, these cellular devices 452 have to meet the recommendations listed below. 454 L_REC#1: The cellular device must support Prefix Delegation 455 capabilities [RFC3633] and must support Prefix Exclude 456 Option for DHCPv6-based Prefix Delegation as defined in 457 [RFC6603]. Particularly, it must behave as a Requesting 458 Router. 460 Cellular networks are more and more perceived as an 461 alternative to fixed networks for home IP-based services 462 delivery; especially with the advent of smartphones and 463 3GPP data dongles. There is a need for an efficient 464 mechanism to assign shorter prefix than /64 to cellular 465 hosts so that each LAN segment can get its own /64 466 prefix and multi-link subnet issues to be avoided. 468 In case a prefix is delegated to a cellular host using 469 DHCPv6, the cellular device will be configured with two 470 prefixes: 472 (1) one for 3GPP link allocated using SLAAC mechanism 473 and 475 (2) another one delegated for LANs acquired during 476 Prefix Delegation operation. 478 Note that the 3GPP network architecture requires both 479 the WAN (Wide Area Network) and the delegated prefix to 480 be aggregatable, so the subscriber can be identified 481 using a single prefix. 483 Without the Prefix Exclude Option, the delegating router 484 (GGSN/PGW) will have to ensure [RFC3633] compliancy 485 (e.g., halving the delegated prefix and assigning the 486 WAN prefix out of the 1st half and the prefix to be 487 delegated to the terminal from the 2nd half). 489 Because Prefix Delegation capabilities may not be 490 available in some attached networks, L_REC#3 is strongly 491 recommended to accommodate early deployments. 493 L_REC#2: The cellular CPE must be compliant with the requirements 494 specified in [RFC7084]. 496 There are several deployments, particularly in emerging 497 countries, that relies on mobile networks to provide 498 broadband services (e.g., customers are provided with 499 mobile CPEs). 501 Note, this profile does not require IPv4 service 502 continuity techniques listed in [RFC7084] because those 503 are specific to fixed networks. IPv4 service continuity 504 techniques specific to the mobile networks are included 505 in this profile. 507 CAUTION: This recommendation does not apply to any 508 cellular device with LAN capabilities; it is specific to 509 cellular CPEs in order to ensure the same IPv6 510 functional parity for both fixed and cellular CPEs. 512 L_REC#3: For deployments requiring to share the same /64 prefix, the 513 cellular device should support [RFC7278] to enable sharing 514 a /64 prefix between the 3GPP interface towards the GGSN/ 515 PGW (WAN interface) and the LAN interfaces. 517 Prefix Delegation (refer to L_REC#1) is the target 518 solution for distributing prefixes in the LAN side but, 519 because the device may attach to earlier 3GPP release 520 networks, a mean to share a /64 prefix is also 521 recommended [RFC7278]. 523 [RFC7278] must be invoked only if Prefix Delegation is 524 not in use. 526 L_REC#4: In order to ensure IPv4 service continuity in an IPv6-only 527 deployment context, the cellular device should support the 528 Customer Side Translator (CLAT) [RFC6877]. 530 Various IP devices are likely to be connected to 531 cellular device, acting as a CPE. Some of these devices 532 can be dual-stack, others are IPv6-only or IPv4-only. 533 IPv6-only connectivity for cellular device does not 534 allow IPv4-only sessions to be established for hosts 535 connected on the LAN segment of cellular devices. 537 In order to allow IPv4 sessions establishment initiated 538 from devices located on LAN segment side and target IPv4 539 nodes, a solution consists in integrating the CLAT 540 function in the cellular device. As elaborated in 541 Section 2, the CLAT function allows also IPv4 542 applications to continue running over an IPv6-only host. 544 The IPv4 Service Continuity Prefix used by CLAT is 545 defined in [RFC7335]. 547 L_REC#5: If a RA MTU is advertised from the 3GPP network, the 548 cellular device should relay that upstream MTU information 549 to the downstream attached LAN devices in RA. 551 Receiving and relaying RA MTU values facilitates a more 552 harmonious functioning of the mobile core network where 553 end nodes transmit packets that do not exceed the MTU 554 size of the mobile network's GTP tunnels. 556 [TS.23060] indicates providing a link MTU value of 1358 557 octets to the 3GPP cellular device will prevent the IP 558 layer fragmentation within the transport network between 559 the cellular device and the GGSN/PGW. 561 5. APIs & Applications Recommendations 563 The use of address family dependent APIs (Application Programming 564 Interfaces) or hard-coded IPv4 address literals may lead to broken 565 applications when IPv6 connectivity is in use. This section 566 identifies a set of recommendations aiming to minimize broken 567 applications when the cellular device is attached to an IPv6 network. 569 APP_REC#1: Name resolution libraries must support both IPv4 and 570 IPv6. 572 In particular, the cellular host must support 573 [RFC3596]. 575 APP_REC#2: Applications provided by the mobile device vendor must be 576 independent of the underlying IP address family. 578 This means applications must be IP version agnostic. 580 APP_REC#3: Applications provided by the mobile device vendor that 581 use Uniform Resource Identifiers (URIs) must follow 582 [RFC3986] and its updates. For example, SIP applications 583 must follow the correction defined in [RFC5954]. 585 6. Security Considerations 587 The security considerations identified in [RFC7066] and [RFC6459] are 588 to be taken into account. 590 In the case of cellular CPEs, compliance with L_REC#2 entails 591 compliance with [RFC7084], which in turn recommends compliance with 592 Recommended Simple Security Capabilities in Customer Premises 593 Equipment (CPE) for Providing Residential IPv6 Internet Service 594 [RFC6092]. Therefore, the security considerations in Section 6 of 595 [RFC6092] are relevant. In particular, it bears repeating here that 596 the true impact of stateful filtering may be a reduction in security, 597 and that IETF make no statement, expressed or implied, as to whether 598 using the capabilities described in any of these documents ultimately 599 improves security for any individual users or for the Internet 600 community as a whole. 602 The cellular host must be able to generate IPv6 addresses which 603 preserve privacy. The activation of privacy extension (e.g., using 604 [RFC7217]) makes it more difficult to track a host over time when 605 compared to using a permanent Interface Identifier. Tracking a host 606 is still possible based on the first 64 bits of the IPv6 address. 607 Means to prevent against such tracking issues may be enabled in the 608 network side. Note, privacy extensions are required by regulatory 609 bodies in some countries. 611 Host-based validation of DNSSEC is discussed in A_REC#3 (see 612 Section 3). 614 7. IANA Considerations 616 This document does not require any action from IANA. 618 8. Acknowledgements 620 Many thanks to C. Byrne, H. Soliman, H. Singh, L. Colliti, T. 621 Lemon, B. Sarikaya, M. Mawatari, M. Abrahamsson, P. Vickers, V. 622 Kuarsingh, E. Kline, S. Josefsson, A. Baryun, J. Woodyatt, T. 624 Kossut, B. Stark, and A. Petrescu for the discussion in the v6ops 625 mailing list. 627 Thanks to A. Farrel, B. Haberman and K. Moriarty for the comments 628 during the IESG review. 630 Special thanks to T. Savolainen, J. Korhonen, J. Jaeggli, and F. 631 Baker for their detailed reviews and comments. 633 9. References 635 9.1. Normative References 637 [IR92] GSMA, "IR.92.V4.0 - IMS Profile for Voice and SMS", March 638 2011, . 641 [RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6 642 (IPv6) Specification", RFC 2460, December 1998. 644 [RFC3596] Thomson, S., Huitema, C., Ksinant, V., and M. Souissi, 645 "DNS Extensions to Support IP Version 6", RFC 3596, 646 October 2003. 648 [RFC3633] Troan, O. and R. Droms, "IPv6 Prefix Options for Dynamic 649 Host Configuration Protocol (DHCP) version 6", RFC 3633, 650 December 2003. 652 [RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform 653 Resource Identifier (URI): Generic Syntax", STD 66, RFC 654 3986, January 2005. 656 [RFC5795] Sandlund, K., Pelletier, G., and L-E. Jonsson, "The RObust 657 Header Compression (ROHC) Framework", RFC 5795, March 658 2010. 660 [RFC5954] Gurbani, V., Carpenter, B., and B. Tate, "Essential 661 Correction for IPv6 ABNF and URI Comparison in RFC 3261", 662 RFC 5954, August 2010. 664 [RFC6052] Bao, C., Huitema, C., Bagnulo, M., Boucadair, M., and X. 665 Li, "IPv6 Addressing of IPv4/IPv6 Translators", RFC 6052, 666 October 2010. 668 [RFC6603] Korhonen, J., Savolainen, T., Krishnan, S., and O. Troan, 669 "Prefix Exclude Option for DHCPv6-based Prefix 670 Delegation", RFC 6603, May 2012. 672 [RFC7066] Korhonen, J., Arkko, J., Savolainen, T., and S. Krishnan, 673 "IPv6 for Third Generation Partnership Project (3GPP) 674 Cellular Hosts", RFC 7066, November 2013. 676 [TS.23060] 677 3GPP, "General Packet Radio Service (GPRS); Service 678 description; Stage 2", September 2011, 679 . 681 [TS.23401] 682 3GPP, "General Packet Radio Service (GPRS) enhancements 683 for Evolved Universal Terrestrial Radio Access Network 684 (E-UTRAN) access", September 2011, 685 . 687 [TS.24008] 688 3GPP, "Mobile radio interface Layer 3 specification; Core 689 network protocols; Stage 3", June 2011, 690 . 692 9.2. Informative References 694 [OECD] Organisation for Economic Cooperation and Development 695 (OECD), "The Economics of the Transition to Internet 696 Protocol version 6 (IPv6)", November 2014, . 700 [Power] Haverinen, H., Siren, J., and P. Eronen, "Energy 701 Consumption of Always-On Applications in WCDMA Networks", 702 April 2007, . 705 [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, 706 A., Peterson, J., Sparks, R., Handley, M., and E. 707 Schooler, "SIP: Session Initiation Protocol", RFC 3261, 708 June 2002. 710 [RFC3948] Huttunen, A., Swander, B., Volpe, V., DiBurro, L., and M. 711 Stenberg, "UDP Encapsulation of IPsec ESP Packets", RFC 712 3948, January 2005. 714 [RFC4033] Arends, R., Austein, R., Larson, M., Massey, D., and S. 715 Rose, "DNS Security Introduction and Requirements", RFC 716 4033, March 2005. 718 [RFC4034] Arends, R., Austein, R., Larson, M., Massey, D., and S. 719 Rose, "Resource Records for the DNS Security Extensions", 720 RFC 4034, March 2005. 722 [RFC4035] Arends, R., Austein, R., Larson, M., Massey, D., and S. 723 Rose, "Protocol Modifications for the DNS Security 724 Extensions", RFC 4035, March 2005. 726 [RFC6092] Woodyatt, J., "Recommended Simple Security Capabilities in 727 Customer Premises Equipment (CPE) for Providing 728 Residential IPv6 Internet Service", RFC 6092, January 729 2011. 731 [RFC6145] Li, X., Bao, C., and F. Baker, "IP/ICMP Translation 732 Algorithm", RFC 6145, April 2011. 734 [RFC6146] Bagnulo, M., Matthews, P., and I. van Beijnum, "Stateful 735 NAT64: Network Address and Protocol Translation from IPv6 736 Clients to IPv4 Servers", RFC 6146, April 2011. 738 [RFC6147] Bagnulo, M., Sullivan, A., Matthews, P., and I. van 739 Beijnum, "DNS64: DNS Extensions for Network Address 740 Translation from IPv6 Clients to IPv4 Servers", RFC 6147, 741 April 2011. 743 [RFC6434] Jankiewicz, E., Loughney, J., and T. Narten, "IPv6 Node 744 Requirements", RFC 6434, December 2011. 746 [RFC6459] Korhonen, J., Soininen, J., Patil, B., Savolainen, T., 747 Bajko, G., and K. Iisakkila, "IPv6 in 3rd Generation 748 Partnership Project (3GPP) Evolved Packet System (EPS)", 749 RFC 6459, January 2012. 751 [RFC6724] Thaler, D., Draves, R., Matsumoto, A., and T. Chown, 752 "Default Address Selection for Internet Protocol Version 6 753 (IPv6)", RFC 6724, September 2012. 755 [RFC6877] Mawatari, M., Kawashima, M., and C. Byrne, "464XLAT: 756 Combination of Stateful and Stateless Translation", RFC 757 6877, April 2013. 759 [RFC6887] Wing, D., Cheshire, S., Boucadair, M., Penno, R., and P. 760 Selkirk, "Port Control Protocol (PCP)", RFC 6887, April 761 2013. 763 [RFC7050] Savolainen, T., Korhonen, J., and D. Wing, "Discovery of 764 the IPv6 Prefix Used for IPv6 Address Synthesis", RFC 765 7050, November 2013. 767 [RFC7051] Korhonen, J. and T. Savolainen, "Analysis of Solution 768 Proposals for Hosts to Learn NAT64 Prefix", RFC 7051, 769 November 2013. 771 [RFC7084] Singh, H., Beebee, W., Donley, C., and B. Stark, "Basic 772 Requirements for IPv6 Customer Edge Routers", RFC 7084, 773 November 2013. 775 [RFC7217] Gont, F., "A Method for Generating Semantically Opaque 776 Interface Identifiers with IPv6 Stateless Address 777 Autoconfiguration (SLAAC)", RFC 7217, April 2014. 779 [RFC7225] Boucadair, M., "Discovering NAT64 IPv6 Prefixes Using the 780 Port Control Protocol (PCP)", RFC 7225, May 2014. 782 [RFC7278] Byrne, C., Drown, D., and A. Vizdal, "Extending an IPv6 783 /64 Prefix from a Third Generation Partnership Project 784 (3GPP) Mobile Interface to a LAN Link", RFC 7278, June 785 2014. 787 [RFC7335] Byrne, C., "IPv4 Service Continuity Prefix", RFC 7335, 788 August 2014. 790 [TS.23402] 791 3GPP, "Architecture enhancements for non-3GPP accesses", 792 September 2011, 793 . 795 Authors' Addresses 797 David Binet 798 France Telecom 799 Rennes 800 France 802 EMail: david.binet@orange.com 804 Mohamed Boucadair 805 France Telecom 806 Rennes 35000 807 France 809 EMail: mohamed.boucadair@orange.com 810 Ales Vizdal 811 Deutsche Telekom AG 813 EMail: ales.vizdal@t-mobile.cz 815 Gang Chen 816 China Mobile 818 EMail: phdgang@gmail.com 820 Nick Heatley 821 EE 822 The Point, 37 North Wharf Road, 823 London W2 1AG 824 U.K 826 EMail: nick.heatley@ee.co.uk 828 Ross Chandler 829 eircom | meteor 830 1HSQ 831 St. John's Road 832 Dublin 8 833 Ireland 835 EMail: ross@eircom.net