idnits 2.17.1 draft-ietf-v6ops-mobile-device-profile-10.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 (August 29, 2014) is 3527 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 3736 (Obsoleted by RFC 8415) -- Obsolete informational reference (is this intentional?): RFC 4941 (Obsoleted by RFC 8981) -- Obsolete informational reference (is this intentional?): RFC 6106 (Obsoleted by RFC 8106) -- Obsolete informational reference (is this intentional?): RFC 6145 (Obsoleted by RFC 7915) -- Obsolete informational reference (is this intentional?): RFC 6204 (Obsoleted by RFC 7084) -- Obsolete informational reference (is this intentional?): RFC 6434 (Obsoleted by RFC 8504) -- Obsolete informational reference (is this intentional?): RFC 6555 (Obsoleted by RFC 8305) Summary: 2 errors (**), 0 flaws (~~), 1 warning (==), 8 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: March 2, 2015 A. Vizdal 6 Deutsche Telekom AG 7 G. Chen 8 China Mobile 9 August 29, 2014 11 An Internet Protocol Version 6 (IPv6) Profile for 3GPP Mobile Devices 12 draft-ietf-v6ops-mobile-device-profile-10 14 Abstract 16 This document defines an IPv6 profile that a number of operators 17 recommend in order to connect 3GPP mobile devices to an IPv6-only or 18 dual-stack wireless network (including 3GPP cellular network and IEEE 19 802.11 network). 21 This document defines a different profile than the one for general 22 connection to IPv6 cellular networks defined in the IPv6 for Third 23 Generation Partnership Project (3GPP) Cellular Hosts document. In 24 particular, this document identifies also features to deliver IPv4 25 connectivity service over an IPv6-only transport. 27 Both hosts and devices with capability to share their WAN (Wide Area 28 Network) connectivity are in scope. 30 Status of This Memo 32 This Internet-Draft is submitted in full conformance with the 33 provisions of BCP 78 and BCP 79. 35 Internet-Drafts are working documents of the Internet Engineering 36 Task Force (IETF). Note that other groups may also distribute 37 working documents as Internet-Drafts. The list of current Internet- 38 Drafts is at http://datatracker.ietf.org/drafts/current/. 40 Internet-Drafts are draft documents valid for a maximum of six months 41 and may be updated, replaced, or obsoleted by other documents at any 42 time. It is inappropriate to use Internet-Drafts as reference 43 material or to cite them other than as "work in progress." 45 This Internet-Draft will expire on March 2, 2015. 47 Copyright Notice 49 Copyright (c) 2014 IETF Trust and the persons identified as the 50 document authors. All rights reserved. 52 This document is subject to BCP 78 and the IETF Trust's Legal 53 Provisions Relating to IETF Documents 54 (http://trustee.ietf.org/license-info) in effect on the date of 55 publication of this document. Please review these documents 56 carefully, as they describe your rights and restrictions with respect 57 to this document. Code Components extracted from this document must 58 include Simplified BSD License text as described in Section 4.e of 59 the Trust Legal Provisions and are provided without warranty as 60 described in the Simplified BSD License. 62 Table of Contents 64 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 65 1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 4 66 1.2. Scope . . . . . . . . . . . . . . . . . . . . . . . . . . 4 67 1.3. Language Considerations . . . . . . . . . . . . . . . . . 4 68 2. Connectivity Recommendations . . . . . . . . . . . . . . . . 5 69 2.1. WLAN Connectivity Recommendations . . . . . . . . . . . . 8 70 3. Advanced Recommendations . . . . . . . . . . . . . . . . . . 9 71 4. Recommendations for Cellular Devices with LAN Capabilities . 12 72 5. APIs & Applications Recommendations . . . . . . . . . . . . . 14 73 6. Security Considerations . . . . . . . . . . . . . . . . . . . 14 74 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14 75 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 14 76 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 15 77 9.1. Normative References . . . . . . . . . . . . . . . . . . 15 78 9.2. Informative References . . . . . . . . . . . . . . . . . 16 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 encountered by 86 mobile operators is the availability of non-broken IPv6 87 implementation in mobile devices. 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 a different profile than the one for general 95 connection to IPv6 mobile networks defined in [RFC7066]; in 96 particular: 98 o It lists an extended list of features while [RFC7066] identifies 99 issues and explains how to implement basic IPv6 features in a 100 cellular context. 102 o It identifies also features to ensure IPv4 service delivery over 103 an IPv6-only transport. 105 This document defines an IPv6 profile for mobile devices listing 106 specifications produced by various Standards Developing Organizations 107 (in particular 3GPP and IETF). 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), EPC (Evolved 113 Packet Core) or IEEE 802.11 network. 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 Pointers to some requirements listed in [RFC6434] are included in 125 this profile. The justification for using a stronger language 126 compared to what is specified in [RFC6434] is provided for some 127 recommendations. 129 The recommendations do not include 3GPP release details. For more 130 information on the 3GPP releases detail, the reader may refer to 131 Section 6.2 of [RFC6459]. 133 Some of the features listed in this profile document require to 134 activate dedicated functions at the network side. It is out of scope 135 of this document to list these network-side functions. 137 A detailed overview of IPv6 support in 3GPP architectures is provided 138 in [RFC6459]. 140 1.1. Terminology 142 This document makes use of the terms defined in [RFC6459]. In 143 addition, the following terms are used: 145 o "3GPP cellular host" (or cellular host for short) denotes a 3GPP 146 device which can be connected to 3GPP mobile networks or IEEE 147 802.11 networks. 149 o "3GPP cellular device" (or cellular device for short) refers to a 150 cellular host which supports the capability to share its WAN (Wide 151 Area Network) connectivity. 153 o "Cellular host" and "mobile host" are used interchangeably. 155 o "Cellular device" and "mobile device" are used interchangeably. 157 PREFIX64 denotes an IPv6 prefix used to build IPv4-converted IPv6 158 addresses [RFC6052]. 160 1.2. Scope 162 A 3GPP mobile network can be used to connect various user equipments 163 such as a mobile telephone, a CPE (Customer Premises Equipment) or a 164 M2M (machine-to-machine) device. Because of this diversity of 165 terminals, it is necessary to define a set of IPv6 functionalities 166 valid for any node directly connecting to a 3GPP mobile network. 167 This document describes these functionalities. 169 This document is structured to provide the generic IPv6 170 recommendations which are valid for all nodes, whatever their 171 function (e.g., host or CPE) or service (e.g., Session Initiation 172 Protocol (SIP, [RFC3261])) capability. The document also contains 173 sections covering specific functionalities for devices providing some 174 LAN functions (e.g., mobile CPE or broadband dongles). 176 The recommendations listed below are valid for both 3GPP GPRS and 177 3GPP EPS (Evolved Packet System) access. For EPS, PDN-Connection 178 term is used instead of PDP-Context. 180 This document identifies also some WLAN-related IPv6 recommendations. 181 Other non-3GPP accesses [TS.23402] are out of scope of this document. 183 1.3. Language Considerations 185 The key words "must", "must not", "should", "should not", and "may" 186 in this document are to be interpreted as described in RFC 2119 187 [RFC2119]. 189 This document is not a standard, and conformance with it is not 190 required in order to claim conformance with IETF standards for IPv6. 191 The support of the full set of features may not be required in some 192 deployment contexts. The authors believe that the support of a 193 subset of the features included in this protocol may lead to degraded 194 level of service in some deployment contexts. 196 This document uses these keywords only for precision. 198 2. Connectivity Recommendations 200 This section identifies the main connectivity recommendations to be 201 followed by a cellular host to attach to a network using IPv6. Both 202 dual-stack and IPv6-only deployment models are considered. IPv4 203 service continuity features are listed in this section because these 204 are critical for Operators with an IPv6-only deployment model. 206 C_REC#1: The cellular host must be compliant with Section 5.9.1 207 (IPv6 Addressing Architecture) and Section 5.8 (ICMPv6 208 support) of [RFC6434]. 210 C_REC#2: In order to allow each operator to select their own 211 strategy regarding IPv6 introduction, the cellular host 212 must support both IPv6 and IPv4v6 PDP-Contexts [TS.23060]. 213 Both IPv6 and IPv4v6 PDP-Contexts must be supported. 214 IPv4, IPv6 or IPv4v6 PDP-Context request acceptance 215 depends on the cellular network configuration. 217 C_REC#3: The cellular host must comply with the behavior defined in 218 [TS.23060] [TS.23401] [TS.24008] for requesting a PDP- 219 Context type. In particular, the cellular host must 220 request by default an IPv6 PDP-Context if the cellular 221 host is IPv6-only and requesting an IPv4v6 PDP-Context if 222 the cellular host is dual-stack or when the cellular host 223 is not aware of connectivity types requested by devices 224 connected to it (e.g., cellular host with LAN capabilities 225 as discussed in Section 4): 227 * If the requested IPv4v6 PDP-Context is not supported by 228 the network, but IPv4 and IPv6 PDP types are allowed, 229 then the cellular host will be configured with an IPv4 230 address or an IPv6 prefix by the network. It must 231 initiate another PDP-Context activation in addition to 232 the one already activated for a given APN (Access Point 233 Name). 235 * If the requested PDP type and subscription data allows 236 only one IP address family (IPv4 or IPv6), the cellular 237 host must not request a second PDP-Context to the same 238 APN for the other IP address family. 240 The text above focuses on the specification part which 241 explains the behavior for requesting IPv6-related PDP- 242 Context(s). Understanding this behavior is important to 243 avoid having broken IPv6 implementations in cellular 244 devices. 246 C_REC#4: The cellular host must support the PCO (Protocol 247 Configuration Options) [TS.24008] to retrieve the IPv6 248 address(es) of the Recursive DNS server(s). 250 In-band signaling is a convenient method to inform the 251 cellular host about various services, including DNS 252 server information. It does not require any specific 253 protocol to be supported and it is already deployed in 254 IPv4 cellular networks to convey such DNS information. 256 C_REC#5: The cellular host must support IPv6 aware Traffic Flow 257 Templates (TFT) [TS.24008]. 259 Traffic Flow Templates are employing a packet filter to 260 couple an IP traffic with a PDP-Context. Thus a 261 dedicated PDP-Context and radio resources can be 262 provided by the cellular network for certain IP 263 traffic. 265 C_REC#6: The cellular host must support the Neighbor Discovery 266 Protocol ([RFC4861] and [RFC5942]). 268 This is a stronger form compared to what is specified 269 in Section 5.2 and Section 12.2 of [RFC6434]. 271 The support of Neighbor Discovery Protocol is mandatory 272 in 3GPP cellular environment as it is the only way to 273 convey IPv6 prefix towards the 3GPP cellular device. 275 In particular, MTU (Maximum Transmission Unit) 276 communication via Router Advertisement must be 277 supported since many 3GPP networks do not have a 278 standard MTU setting. 280 C_REC#7: The cellular host must comply with Section 5.6.1 of 281 [RFC6434]. If the MTU used by cellular hosts is larger 282 than 1280 bytes, they can rely on Path MTU discovery 283 function to discover the real path MTU. 285 C_REC#8: The cellular host must support IPv6 Stateless Address 286 Autoconfiguration ([RFC4862]) apart from the exceptions 287 noted in [TS.23060] (3G) and [TS.23401] (LTE): 289 Stateless mode is the only way to configure a cellular 290 host. The GGSN/PGW must allocate a prefix that is 291 unique within its scope to each primary PDP-Context. 293 To configure its link local address, the cellular host 294 must use the Interface Identifier conveyed in 3GPP PDP- 295 Context setup signaling received from a GGSN/PGW. The 296 cellular host may use a different Interface Identifiers 297 to configure its global addresses (see also A_REC#1 298 about privacy addressing recommendation). 300 For more details, refer to [RFC6459] and [RFC7066]. 302 C_REC#9: The cellular host must comply with Section 7.3 of 303 [RFC6434]. 305 C_REC#10: The cellular host must comply with Section 7.2.1 of 306 [RFC6434]. 308 Stateless DHCPv6 is useful to retrieve other 309 information than DNS. 311 If [RFC6106] is not supported at the network side, the 312 cellular host should retrieve DNS information using 313 stateless DHCPv6 [RFC3736]. 315 C_REC#11: If the cellular host receives the DNS information in 316 several channels for the same interface, the following 317 preference order must be followed: 319 1. PCO 321 2. RA 323 3. DHCPv6 325 C_REC#12: The cellular host must be able to be configured to limit 326 PDP type(s) for a given APN. The default mode is to allow 327 all supported PDP types. Note, C_REC#3 discusses the 328 default behavior for requesting PDP-Context type(s). 330 This feature is useful to drive the behavior of the UE 331 to be aligned with: (1) service-specific constraints 332 such as the use of IPv6-only for VoLTE (Voice over 333 LTE), (2) network conditions with regards to the 334 support of specific PDP types (e.g., IPv4v6 PDP-Context 335 is not supported), (3) IPv4 sunset objectives, (4) 336 subscription data, etc. 338 C_REC#13: Because of potential operational deficiencies to be 339 experienced in some roaming situations, the cellular host 340 must be able to be configured with a home IP profile and a 341 roaming IP profile. The aim of the roaming profile is to 342 limit the PDP type(s) requested by the cellular host when 343 out of the home network. Note, distinct PDP type(s) can 344 be configured for home and roaming cases. 346 C_REC#14: In order to ensure IPv4 service continuity in an IPv6-only 347 deployment context, the cellular host should support a 348 method to locally construct IPv4-embedded IPv6 addresses 349 [RFC6052]. A method to learn PREFIX64 should be supported 350 by the cellular host. 352 This solves the issue when applications use IPv4 353 referrals on IPv6-only access networks. 355 In PCP-based environments, cellular hosts should follow 356 [RFC7225] to learn the IPv6 Prefix used by an upstream 357 PCP-controlled NAT64 device. If PCP is not enabled, 358 the cellular host should implement the method specified 359 in [RFC7050] to retrieve the PREFIX64. 361 C_REC#15: In order to ensure IPv4 service continuity in an IPv6-only 362 deployment context, the cellular host should implement the 363 Customer Side Translator (CLAT, [RFC6877]) function which 364 is compliant with [RFC6052][RFC6145][RFC6146]. 366 CLAT function in the cellular host allows for IPv4-only 367 application and IPv4-referals to work on an IPv6-only 368 connectivity. CLAT function requires a NAT64 369 capability [RFC6146] in the core network. 371 The IPv4 Service Continuity Prefix used by CLAT is 372 defined in [RFC7335]. 374 2.1. WLAN Connectivity Recommendations 376 It is increasingly common for cellular hosts have a WLAN interface in 377 addition to their cellular interface. These hosts are likely to be 378 connected to private or public hotspots. Below are listed some 379 generic recommendations: 381 W_REC#1: IPv6 must be supported on the WLAN interface. In 382 particular, WLAN interface must behave properly when only 383 an IPv6 connectivity is provided. 385 Some tests revealed that IPv4 configuration is required 386 to enable IPv6-only connectivity. Indeed, some cellular 387 handsets can access a WLAN IPv6-only network by 388 configuring first a static IPv4 address. Once the 389 device is connected to the network and the wlan0 390 interface got an IPv6 global address, the IPv4 address 391 can be deleted from the configuration. This avoids the 392 device to ask automatically for a DHCPv4 server, and 393 allows to connect to IPv6-only networks. Failing to 394 configure an IPv4 address on the interface must not 395 prohibit using IPv6 on the same interface. 397 IPv6 Stateless Address Autoconfiguration ([RFC4862]) 398 must be supported. 400 W_REC#2: DHCPv6 client should be supported on WLAN interface. 402 Refer to Section 7.2.1 of [RFC6434]. 404 W_REC#3: WLAN interface should support Router Advertisement Options 405 for DNS configuration (See Section 7.3 of [RFC6434]). 407 W_REC#4: If the device receives the DNS information in several 408 channels for the same interface, the following preference 409 order must be followed: 411 1. RA 413 2. DHCPv6 415 3. Advanced Recommendations 417 This section identifies a set of advanced recommendations to meet 418 regulatory constraints in some countries, fulfill requirements of 419 critical services such as VoLTE, or enforce policies such as traffic 420 offload. 422 A_REC#1: The cellular host must be able to generate IPv6 addresses 423 which preserve privacy. 425 The activation of privacy extension (e.g., using 426 [RFC4941] or [RFC7217]) makes it more difficult to track 427 a host over time when compared to using a permanent 428 Interface Identifier. Note, [RFC4941] does not require 429 any DAD mechanism to be activated as the GGSN/PGW must 430 not configure any global address based on the prefix 431 allocated to the cellular host. 433 Tracking a host is still possible based on the first 64 434 bits of the IPv6 address. Means to prevent against such 435 tracking issues may be enabled in the network side. 437 Privacy extensions are required by regulatory bodies in 438 some countries. 440 A_REC#2: The cellular host must support ROHC RTP Profile (0x0001) 441 and ROHC UDP Profile (0x0002) for IPv6 ([RFC5795]). Other 442 ROHC profiles may be supported. 444 Bandwidth in cellular networks must be optimized as much 445 as possible. ROHC provides a solution to reduce 446 bandwidth consumption and to reduce the impact of having 447 bigger packet headers in IPv6 compared to IPv4. 449 "RTP/UDP/IP" ROHC profile (0x0001) to compress RTP 450 packets [RFC3550] and "UDP/IP" ROHC profile (0x0002) to 451 compress RTCP packets [RFC3550] are required for Voice 452 over LTE (VoLTE) by IR.92.4.0 section 4.1 [IR92]. Note, 453 [IR92] indicates also the host must be able to apply the 454 compression to packets that are carried over the radio 455 bearer dedicated for the voice media. 457 A_REC#3: The cellular host should support PCP [RFC6887]. 459 The support of PCP is seen as a driver to save battery 460 consumption exacerbated by keepalive messages. PCP also 461 gives the possibility of enabling incoming connections 462 to the cellular device. Indeed, because several 463 stateful devices may be deployed in wireless networks 464 (e.g., NAT and/or Firewalls), PCP can be used by the 465 cellular host to control network-based NAT and Firewall 466 functions which will reduce per-application signaling 467 and save battery consumption. 469 According to [Power], the consumption of a cellular 470 device with a keep-alive interval equal to 20 seconds 471 (that is the default value in [RFC3948] for example) is 472 29mA (2G)/34mA (3G). This consumption is reduced to 473 16mA (2G)/24mA (3G) when the interval is increased to 40 474 seconds, to 9.1mA (2G)/16mA (3G) if the interval is 475 equal to 150s, and to 7.3mA (2G)/14mA (3G) if the 476 interval is equal to 180s. When no keep-alive is 477 issued, the consumption would be 5.2mA (2G)/6.1mA (3G). 478 The impact of keepalive messages would be more severe if 479 multiple applications are issuing those messages (e.g., 480 SIP, IPsec, etc.). 482 A_REC#4: In order for host-based validation of DNS Security 483 Extensions (DNSSEC) to continue to function in an IPv6-only 484 with NAT64 deployment context, the cellular host should 485 embed a DNS64 function ([RFC6147]). 487 This is called "DNS64 in stub-resolver mode" in 488 [RFC6147]. 490 As discussed in Section 5.5 of [RFC6147], a security- 491 aware and validating host has to perform the DNS64 492 function locally. 494 Because synthetic AAAA records cannot be successfully 495 validated in a host, learning the PREFIX64 used to 496 construct IPv4-converted IPv6 addresses allows the use 497 of DNSSEC [RFC4033] [RFC4034], [RFC4035]. Means to 498 configure or discover a PREFIX64 are required on the 499 cellular device as discussed in C_REC#14. 501 [RFC7051] discusses why a security-aware and validating 502 host has to perform the DNS64 function locally and why 503 it has to be able to learn the proper PREFIX64(s). 505 A_REC#5: When the cellular host is dual-stack connected (i.e., 506 configured with an IPv4 address and IPv6 prefix), it should 507 support means to prefer native IPv6 connection over 508 connection established through translation devices (e.g., 509 NAT44 and NAT64). 511 When both IPv4 and IPv6 DNS servers are configured, a 512 dual-stack host must contact first its IPv6 DNS server. 514 Cellular hosts should follow the procedure specified in 515 [RFC6724] for source address selection. 517 A_REC#6: The cellular host should support Happy Eyeballs procedure 518 defined in [RFC6555]. 520 A_REC#7: The cellular host must comply with Section 5.3 of [RFC6434] 521 and should support Router Advertisement extension for 522 communicating default router preferences and more-specific 523 routes as described in [RFC4191]. 525 This function can be used for instance for traffic 526 offload. 528 4. Recommendations for Cellular Devices with LAN Capabilities 530 This section focuses on cellular devices (e.g., CPE, smartphones, or 531 dongles with tethering features) which provide IP connectivity to 532 other devices connected to them. In such case, all connected devices 533 are sharing the same 2G, 3G or LTE connection. In addition to the 534 generic recommendations listed in Section 2, these cellular devices 535 have to meet the recommendations listed below. 537 L_REC#1: The cellular device must support Prefix Delegation 538 capabilities [RFC3633] and must support Prefix Exclude 539 Option for DHCPv6-based Prefix Delegation as defined in 540 [RFC6603]. Particularly, it must behave as a Requesting 541 Router. 543 Cellular networks are more and more perceived as an 544 alternative to fixed networks for home IP-based services 545 delivery; especially with the advent of smartphones and 546 3GPP data dongles. There is a need for an efficient 547 mechanism to assign shorter prefix than /64 to cellular 548 hosts so that each LAN segment can get its own /64 549 prefix and multi-link subnet issues to be avoided. 551 In case a prefix is delegated to a cellular host using 552 DHCPv6, the cellular device will be configured with two 553 prefixes: 555 (1) one for 3GPP link allocated using SLAAC mechanism 556 and 558 (2) another one delegated for LANs acquired during 559 Prefix Delegation operation. 561 Note that the 3GPP network architecture requires both 562 the WAN (Wide Area Network) and the delegated prefix to 563 be aggregatable, so the subscriber can be identified 564 using a single prefix. 566 Without the Prefix Exclude Option, the delegating router 567 (GGSN/PGW) will have to ensure [RFC3633] compliancy 568 (e.g., halving the delegated prefix and assigning the 569 WAN prefix out of the 1st half and the prefix to be 570 delegated to the terminal from the 2nd half). 572 L_REC#2: The cellular CPE must be compliant with the requirements 573 specified in [RFC6204]. 575 There are several deployments, particularly in emerging 576 countries, that relies on mobile networks to provide 577 broadband services (e.g., customers are provided with 578 mobile CPEs). 580 L_REC#3: For deployments requiring to share the same /64 prefix, the 581 cellular device should support [RFC7278] to enable sharing 582 a /64 prefix between the 3GPP interface towards the GGSN/ 583 PGW (WAN interface) and the LAN interfaces. 585 L_REC#4: In order to ensure IPv4 service continuity in an IPv6-only 586 deployment context, the cellular device should support the 587 Customer Side Translator (CLAT) [RFC6877]. 589 Various IP devices are likely to be connected to 590 cellular device, acting as a CPE. Some of these devices 591 can be dual-stack, others are IPv6-only or IPv4-only. 592 IPv6-only connectivity for cellular device does not 593 allow IPv4-only sessions to be established for hosts 594 connected on the LAN segment of cellular devices. 596 In order to allow IPv4 sessions establishment initiated 597 from devices located on LAN segment side and target IPv4 598 nodes, a solution consists in integrating the CLAT 599 function in the cellular device. As elaborated in 600 Section 2, the CLAT function allows also IPv4 601 applications to continue running over an IPv6-only host. 603 The IPv4 Service Continuity Prefix used by CLAT is 604 defined in [RFC7335]. 606 L_REC#5: If a RA MTU is advertised from the 3GPP network, the 607 cellular device should relay that upstream MTU information 608 to the downstream attached LAN devices in RA. 610 Receiving and relaying RA MTU values facilitates a more 611 harmonious functioning of the mobile core network where 612 end nodes transmit packets that do not exceed the MTU 613 size of the mobile network's GTP tunnels. 615 [TS.23060] indicates providing a link MTU value of 1358 616 octets to the 3GPP cellular device will prevent the IP 617 layer fragmentation within the transport network between 618 the cellular device and the GGSN/PGW. 620 5. APIs & Applications Recommendations 622 The use of address family dependent APIs (Application Programming 623 Interfaces) or hard-coded IPv4 address literals may lead to broken 624 applications when IPv6 connectivity is in use. This section 625 identifies a set of recommendations aiming to minimize broken 626 applications when the cellular device is attached to an IPv6 network. 628 APP_REC#1: Name resolution libraries must support both IPv4 and 629 IPv6. 631 In particular, the cellular host must support 632 [RFC3596]. 634 APP_REC#2: Applications provided by the mobile device vendor must be 635 independent of the underlying IP address family. 637 This means applications must be IP version agnostic. 639 APP_REC#3: Applications provided by the mobile device vendor that 640 use Uniform Resource Identifiers (URIs) must follow 641 [RFC3986]. For example, SIP applications must follow the 642 correction defined in [RFC5954]. 644 6. Security Considerations 646 The security considerations identified in [RFC7066] and [RFC6459] are 647 to be taken into account. 649 Security-related considerations that apply when the cellular device 650 provides LAN features are specified in [RFC6092]. 652 Address privacy considerations are discussed in [RFC4941] [RFC7217]. 654 7. IANA Considerations 656 This document does not require any action from IANA. 658 8. Acknowledgements 660 Many thanks to C. Byrne, H. Soliman, H. Singh, L. Colliti, T. 661 Lemon, B. Sarikaya, M. Mawatari, M. Abrahamsson, P. Vickers, V. 662 Kuarsingh, N. Heatley, E. Kline, S. Josefsson, A. Baryun, J. 663 Woodyatt, and R. Chandler for the discussion in the v6ops mailing 664 list. 666 Special thanks to T. Savolainen, J. Korhonen, and J. Jaeggli for 667 their detailed reviews and comments. 669 9. References 671 9.1. Normative References 673 [IR92] GSMA, "IR.92.V4.0 - IMS Profile for Voice and SMS", March 674 2011, . 677 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 678 Requirement Levels", BCP 14, RFC 2119, March 1997. 680 [RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6 681 (IPv6) Specification", RFC 2460, December 1998. 683 [RFC3596] Thomson, S., Huitema, C., Ksinant, V., and M. Souissi, 684 "DNS Extensions to Support IP Version 6", RFC 3596, 685 October 2003. 687 [RFC3633] Troan, O. and R. Droms, "IPv6 Prefix Options for Dynamic 688 Host Configuration Protocol (DHCP) version 6", RFC 3633, 689 December 2003. 691 [RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform 692 Resource Identifier (URI): Generic Syntax", STD 66, RFC 693 3986, January 2005. 695 [RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman, 696 "Neighbor Discovery for IP version 6 (IPv6)", RFC 4861, 697 September 2007. 699 [RFC4862] Thomson, S., Narten, T., and T. Jinmei, "IPv6 Stateless 700 Address Autoconfiguration", RFC 4862, September 2007. 702 [RFC5795] Sandlund, K., Pelletier, G., and L-E. Jonsson, "The RObust 703 Header Compression (ROHC) Framework", RFC 5795, March 704 2010. 706 [RFC5942] Singh, H., Beebee, W., and E. Nordmark, "IPv6 Subnet 707 Model: The Relationship between Links and Subnet 708 Prefixes", RFC 5942, July 2010. 710 [RFC5954] Gurbani, V., Carpenter, B., and B. Tate, "Essential 711 Correction for IPv6 ABNF and URI Comparison in RFC 3261", 712 RFC 5954, August 2010. 714 [RFC6052] Bao, C., Huitema, C., Bagnulo, M., Boucadair, M., and X. 715 Li, "IPv6 Addressing of IPv4/IPv6 Translators", RFC 6052, 716 October 2010. 718 [RFC6603] Korhonen, J., Savolainen, T., Krishnan, S., and O. Troan, 719 "Prefix Exclude Option for DHCPv6-based Prefix 720 Delegation", RFC 6603, May 2012. 722 [RFC7066] Korhonen, J., Arkko, J., Savolainen, T., and S. Krishnan, 723 "IPv6 for Third Generation Partnership Project (3GPP) 724 Cellular Hosts", RFC 7066, November 2013. 726 [TS.23060] 727 3GPP, "General Packet Radio Service (GPRS); Service 728 description; Stage 2", September 2011, 729 . 731 [TS.23401] 732 3GPP, "General Packet Radio Service (GPRS) enhancements 733 for Evolved Universal Terrestrial Radio Access Network 734 (E-UTRAN) access", September 2011, 735 . 737 [TS.24008] 738 3GPP, "Mobile radio interface Layer 3 specification; Core 739 network protocols; Stage 3", June 2011, 740 . 742 9.2. Informative References 744 [Power] Haverinen, H., Siren, J., and P. Eronen, "Energy 745 Consumption of Always-On Applications in WCDMA Networks", 746 April 2007, . 749 [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, 750 A., Peterson, J., Sparks, R., Handley, M., and E. 751 Schooler, "SIP: Session Initiation Protocol", RFC 3261, 752 June 2002. 754 [RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V. 755 Jacobson, "RTP: A Transport Protocol for Real-Time 756 Applications", STD 64, RFC 3550, July 2003. 758 [RFC3736] Droms, R., "Stateless Dynamic Host Configuration Protocol 759 (DHCP) Service for IPv6", RFC 3736, April 2004. 761 [RFC3948] Huttunen, A., Swander, B., Volpe, V., DiBurro, L., and M. 762 Stenberg, "UDP Encapsulation of IPsec ESP Packets", RFC 763 3948, January 2005. 765 [RFC4033] Arends, R., Austein, R., Larson, M., Massey, D., and S. 766 Rose, "DNS Security Introduction and Requirements", RFC 767 4033, March 2005. 769 [RFC4034] Arends, R., Austein, R., Larson, M., Massey, D., and S. 770 Rose, "Resource Records for the DNS Security Extensions", 771 RFC 4034, March 2005. 773 [RFC4035] Arends, R., Austein, R., Larson, M., Massey, D., and S. 774 Rose, "Protocol Modifications for the DNS Security 775 Extensions", RFC 4035, March 2005. 777 [RFC4191] Draves, R. and D. Thaler, "Default Router Preferences and 778 More-Specific Routes", RFC 4191, November 2005. 780 [RFC4941] Narten, T., Draves, R., and S. Krishnan, "Privacy 781 Extensions for Stateless Address Autoconfiguration in 782 IPv6", RFC 4941, September 2007. 784 [RFC6092] Woodyatt, J., "Recommended Simple Security Capabilities in 785 Customer Premises Equipment (CPE) for Providing 786 Residential IPv6 Internet Service", RFC 6092, January 787 2011. 789 [RFC6106] Jeong, J., Park, S., Beloeil, L., and S. Madanapalli, 790 "IPv6 Router Advertisement Options for DNS Configuration", 791 RFC 6106, November 2010. 793 [RFC6145] Li, X., Bao, C., and F. Baker, "IP/ICMP Translation 794 Algorithm", RFC 6145, April 2011. 796 [RFC6146] Bagnulo, M., Matthews, P., and I. van Beijnum, "Stateful 797 NAT64: Network Address and Protocol Translation from IPv6 798 Clients to IPv4 Servers", RFC 6146, April 2011. 800 [RFC6147] Bagnulo, M., Sullivan, A., Matthews, P., and I. van 801 Beijnum, "DNS64: DNS Extensions for Network Address 802 Translation from IPv6 Clients to IPv4 Servers", RFC 6147, 803 April 2011. 805 [RFC6204] Singh, H., Beebee, W., Donley, C., Stark, B., and O. 806 Troan, "Basic Requirements for IPv6 Customer Edge 807 Routers", RFC 6204, April 2011. 809 [RFC6434] Jankiewicz, E., Loughney, J., and T. Narten, "IPv6 Node 810 Requirements", RFC 6434, December 2011. 812 [RFC6459] Korhonen, J., Soininen, J., Patil, B., Savolainen, T., 813 Bajko, G., and K. Iisakkila, "IPv6 in 3rd Generation 814 Partnership Project (3GPP) Evolved Packet System (EPS)", 815 RFC 6459, January 2012. 817 [RFC6555] Wing, D. and A. Yourtchenko, "Happy Eyeballs: Success with 818 Dual-Stack Hosts", RFC 6555, April 2012. 820 [RFC6724] Thaler, D., Draves, R., Matsumoto, A., and T. Chown, 821 "Default Address Selection for Internet Protocol Version 6 822 (IPv6)", RFC 6724, September 2012. 824 [RFC6877] Mawatari, M., Kawashima, M., and C. Byrne, "464XLAT: 825 Combination of Stateful and Stateless Translation", RFC 826 6877, April 2013. 828 [RFC6887] Wing, D., Cheshire, S., Boucadair, M., Penno, R., and P. 829 Selkirk, "Port Control Protocol (PCP)", RFC 6887, April 830 2013. 832 [RFC7050] Savolainen, T., Korhonen, J., and D. Wing, "Discovery of 833 the IPv6 Prefix Used for IPv6 Address Synthesis", RFC 834 7050, November 2013. 836 [RFC7051] Korhonen, J. and T. Savolainen, "Analysis of Solution 837 Proposals for Hosts to Learn NAT64 Prefix", RFC 7051, 838 November 2013. 840 [RFC7217] Gont, F., "A Method for Generating Semantically Opaque 841 Interface Identifiers with IPv6 Stateless Address 842 Autoconfiguration (SLAAC)", RFC 7217, April 2014. 844 [RFC7225] Boucadair, M., "Discovering NAT64 IPv6 Prefixes Using the 845 Port Control Protocol (PCP)", RFC 7225, May 2014. 847 [RFC7278] Byrne, C., Drown, D., and A. Vizdal, "Extending an IPv6 848 /64 Prefix from a Third Generation Partnership Project 849 (3GPP) Mobile Interface to a LAN Link", RFC 7278, June 850 2014. 852 [RFC7335] Byrne, C., "IPv4 Service Continuity Prefix", RFC 7335, 853 August 2014. 855 [TS.23402] 856 3GPP, "Architecture enhancements for non-3GPP accesses", 857 September 2011, 858 . 860 Authors' Addresses 862 David Binet 863 France Telecom 864 Rennes 865 France 867 EMail: david.binet@orange.com 869 Mohamed Boucadair 870 France Telecom 871 Rennes 35000 872 France 874 EMail: mohamed.boucadair@orange.com 876 Ales Vizdal 877 Deutsche Telekom AG 879 EMail: ales.vizdal@t-mobile.cz 881 Gang Chen 882 China Mobile 884 EMail: phdgang@gmail.com