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