idnits 2.17.1 draft-ietf-v6ops-mobile-device-profile-09.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 13, 2014) is 3542 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: February 14, 2015 A. Vizdal 6 Deutsche Telekom AG 7 C. Byrne 8 T-Mobile 9 G. Chen 10 China Mobile 11 August 13, 2014 13 An Internet Protocol Version 6 (IPv6) Profile for 3GPP Mobile Devices 14 draft-ietf-v6ops-mobile-device-profile-09 16 Abstract 18 This document defines an IPv6 profile that a number of operators 19 recommend in order to connect 3GPP mobile devices to an IPv6-only or 20 dual-stack wireless network (including 3GPP cellular network and IEEE 21 802.11 network). 23 This document defines a different profile than the one for general 24 connection to IPv6 cellular networks defined in the IPv6 for Third 25 Generation Partnership Project (3GPP) Cellular Hosts document. In 26 particular, this document identifies also features to deliver IPv4 27 connectivity service over an IPv6-only transport. 29 Both hosts and devices with capability to share their WAN (Wide Area 30 Network) connectivity are in scope. 32 Status of This Memo 34 This Internet-Draft is submitted in full conformance with the 35 provisions of BCP 78 and BCP 79. 37 Internet-Drafts are working documents of the Internet Engineering 38 Task Force (IETF). Note that other groups may also distribute 39 working documents as Internet-Drafts. The list of current Internet- 40 Drafts is at http://datatracker.ietf.org/drafts/current/. 42 Internet-Drafts are draft documents valid for a maximum of six months 43 and may be updated, replaced, or obsoleted by other documents at any 44 time. It is inappropriate to use Internet-Drafts as reference 45 material or to cite them other than as "work in progress." 47 This Internet-Draft will expire on February 14, 2015. 49 Copyright Notice 51 Copyright (c) 2014 IETF Trust and the persons identified as the 52 document authors. All rights reserved. 54 This document is subject to BCP 78 and the IETF Trust's Legal 55 Provisions Relating to IETF Documents 56 (http://trustee.ietf.org/license-info) in effect on the date of 57 publication of this document. Please review these documents 58 carefully, as they describe your rights and restrictions with respect 59 to this document. Code Components extracted from this document must 60 include Simplified BSD License text as described in Section 4.e of 61 the Trust Legal Provisions and are provided without warranty as 62 described in the Simplified BSD License. 64 Table of Contents 66 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 67 1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 4 68 1.2. Scope . . . . . . . . . . . . . . . . . . . . . . . . . . 4 69 1.3. Language Considerations . . . . . . . . . . . . . . . . . 4 70 2. Connectivity Recommendations . . . . . . . . . . . . . . . . 5 71 2.1. WLAN Connectivity Recommendations . . . . . . . . . . . . 9 72 3. Advanced Recommendations . . . . . . . . . . . . . . . . . . 10 73 4. Recommendations for Cellular Devices with LAN Capabilities . 11 74 5. APIs & Applications Recommendations . . . . . . . . . . . . . 13 75 6. Security Considerations . . . . . . . . . . . . . . . . . . . 13 76 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14 77 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 14 78 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 14 79 9.1. Normative References . . . . . . . . . . . . . . . . . . 14 80 9.2. Informative References . . . . . . . . . . . . . . . . . 15 82 1. Introduction 84 IPv6 deployment in 3GPP mobile networks is the only perennial 85 solution to the exhaustion of IPv4 addresses in those networks. 86 Several mobile operators have already deployed IPv6 [RFC2460] or are 87 in the pre-deployment phase. One of the major hurdles encountered by 88 mobile operators is the availability of non-broken IPv6 89 implementation in mobile devices. 91 [RFC7066] lists a set of features to be supported by cellular hosts 92 to connect to 3GPP mobile networks. In the light of recent IPv6 93 production deployments, additional features to facilitate IPv6-only 94 deployments while accessing IPv4-only service are to be considered. 96 This document defines a different profile than the one for general 97 connection to IPv6 mobile networks defined in [RFC7066]; in 98 particular: 100 o It lists an extended list of features while [RFC7066] identifies 101 issues and explains how to implement basic IPv6 features in a 102 cellular context. 104 o It identifies also features to ensure IPv4 service delivery over 105 an IPv6-only transport. 107 This document defines an IPv6 profile for mobile devices listing 108 specifications produced by various Standards Developing Organizations 109 (in particular 3GPP and IETF). The objectives of this effort are: 111 1. List in one single document a comprehensive list of IPv6 features 112 for a mobile device, including both IPv6-only and dual-stack 113 mobile deployment contexts. These features cover various network 114 types such as GPRS (General Packet Radio Service), EPC (Evolved 115 Packet Core) or IEEE 802.11 network. 117 2. Help Operators with the detailed device requirement list 118 preparation (to be exchanged with device suppliers). This is 119 also a contribution to harmonize Operators' requirements towards 120 device vendors. 122 3. Vendors to be aware of a set of features to allow for IPv6 123 connectivity and IPv4 service continuity (over an IPv6-only 124 transport). 126 Pointers to some requirements listed in [RFC6434] are included in 127 this profile. The justification for using a stronger language 128 compared to what is specified in [RFC6434] is provided for some 129 recommendations. 131 The recommendations do not include 3GPP release details. For more 132 information on the 3GPP releases detail, the reader may refer to 133 Section 6.2 of [RFC6459]. 135 Some of the features listed in this profile document require to 136 activate dedicated functions at the network side. It is out of scope 137 of this document to list these network-side functions. 139 A detailed overview of IPv6 support in 3GPP architectures is provided 140 in [RFC6459]. 142 1.1. Terminology 144 This document makes use of the terms defined in [RFC6459]. In 145 addition, the following terms are used: 147 o "3GPP cellular host" (or cellular host for short) denotes a 3GPP 148 device which can be connected to 3GPP mobile networks or IEEE 149 802.11 networks. 151 o "3GPP cellular device" (or cellular device for short) refers to a 152 cellular host which supports the capability to share its WAN (Wide 153 Area Network) connectivity. 155 o "Cellular host" and "mobile host" are used interchangeably. 157 o "Cellular device" and "mobile device" are used interchangeably. 159 PREFIX64 denotes an IPv6 prefix used to build IPv4-converted IPv6 160 addresses [RFC6052]. 162 1.2. Scope 164 A 3GPP mobile network can be used to connect various user equipments 165 such as a mobile telephone, a CPE (Customer Premises Equipment) or a 166 M2M (machine-to-machine) device. Because of this diversity of 167 terminals, it is necessary to define a set of IPv6 functionalities 168 valid for any node directly connecting to a 3GPP mobile network. 169 This document describes these functionalities. 171 This document is structured to provide the generic IPv6 172 recommendations which are valid for all nodes, whatever their 173 function (e.g., host or CPE) or service (e.g., Session Initiation 174 Protocol (SIP, [RFC3261])) capability. The document also contains 175 sections covering specific functionalities for devices providing some 176 LAN functions (e.g., mobile CPE or broadband dongles). 178 The recommendations listed below are valid for both 3GPP GPRS and 179 3GPP EPS (Evolved Packet System) access. For EPS, PDN-Connection 180 term is used instead of PDP-Context. 182 This document identifies also some WLAN-related IPv6 recommendations. 183 Other non-3GPP accesses [TS.23402] are out of scope of this document. 185 1.3. Language Considerations 187 The key words "must", "must not", "should", "should not", and "may" 188 in this document are to be interpreted as described in RFC 2119 189 [RFC2119]. 191 This document is not a standard, and conformance with it is not 192 required in order to claim conformance with IETF standards for IPv6. 193 The support of the full set of features may not be required in some 194 deployment contexts. The authors believe that the support of a 195 subset of the features included in this protocol may lead to degraded 196 level of service in some deployment contexts. 198 This document uses these keywords only for precision. 200 2. Connectivity Recommendations 202 This section identifies the main connectivity recommendations to be 203 followed by a cellular host to attach to a network using IPv6. Both 204 dual-stack and IPv6-only deployment models are considered. IPv4 205 service continuity features are listed in this section because these 206 are critical for Operators with an IPv6-only deployment model. 208 C_REC#1: The cellular host must be compliant with Section 5.9.1 209 (IPv6 Addressing Architecture) and Section 5.8 (ICMPv6 210 support) of [RFC6434]. 212 C_REC#2: In order to allow each operator to select their own 213 strategy regarding IPv6 introduction, the cellular host 214 must support both IPv6 and IPv4v6 PDP-Contexts [TS.23060]. 215 Both IPv6 and IPv4v6 PDP-Contexts must be supported. 216 IPv4, IPv6 or IPv4v6 PDP-Context request acceptance 217 depends on the cellular network configuration. 219 C_REC#3: The cellular host must comply with the behavior defined in 220 [TS.23060] [TS.23401] [TS.24008] for requesting a PDP- 221 Context type. In particular, the cellular host must 222 request by default an IPv6 PDP-Context if the cellular 223 host is IPv6-only and requesting an IPv4v6 PDP-Context if 224 the cellular host is dual-stack or when the cellular host 225 is not aware of connectivity types requested by devices 226 connected to it (e.g., cellular host with LAN capabilities 227 as discussed in Section 4): 229 * If the requested IPv4v6 PDP-Context is not supported by 230 the network, but IPv4 and IPv6 PDP types are allowed, 231 then the cellular host will be configured with an IPv4 232 address or an IPv6 prefix by the network. It must 233 initiate another PDP-Context activation in addition to 234 the one already activated for a given APN (Access Point 235 Name). 237 * If the requested PDP type and subscription data allows 238 only one IP address family (IPv4 or IPv6), the cellular 239 host must not request a second PDP-Context to the same 240 APN for the other IP address family. 242 The text above focuses on the specification part which 243 explains the behavior for requesting IPv6-related PDP- 244 Context(s). Understanding this behavior is important to 245 avoid having broken IPv6 implementations in cellular 246 devices. 248 C_REC#4: The cellular host must support the PCO (Protocol 249 Configuration Options) [TS.24008] to retrieve the IPv6 250 address(es) of the Recursive DNS server(s). 252 In-band signaling is a convenient method to inform the 253 cellular host about various services, including DNS 254 server information. It does not require any specific 255 protocol to be supported and it is already deployed in 256 IPv4 cellular networks to convey such DNS information. 258 C_REC#5: The cellular host must support IPv6 aware Traffic Flow 259 Templates (TFT) [TS.24008]. 261 Traffic Flow Templates are employing a packet filter to 262 couple an IP traffic with a PDP-Context. Thus a 263 dedicated PDP-Context and radio resources can be 264 provided by the cellular network for certain IP 265 traffic. 267 C_REC#6: The cellular host must support the Neighbor Discovery 268 Protocol ([RFC4861] and [RFC5942]). 270 This is a stronger form compared to what is specified 271 in Section 5.2 and Section 12.2 of [RFC6434]. 273 The support of Neighbor Discovery Protocol is mandatory 274 in 3GPP cellular environment as it is the only way to 275 convey IPv6 prefix towards the 3GPP cellular device. 277 In particular, MTU (Maximum Transmission Unit) 278 communication via Router Advertisement must be 279 supported since many 3GPP networks do not have a 280 standard MTU setting. 282 C_REC#7: The cellular host must comply with Section 5.6.1 of 283 [RFC6434]. If the MTU used by cellular hosts is larger 284 than 1280 bytes, they can rely on Path MTU discovery 285 function to discover the real path MTU. 287 C_REC#8: The cellular host must support IPv6 Stateless Address 288 Autoconfiguration ([RFC4862]) apart from the exceptions 289 noted in [TS.23060] (3G) and [TS.23401] (LTE): 291 Stateless mode is the only way to configure a cellular 292 host. The GGSN/PGW must allocate a prefix that is 293 unique within its scope to each primary PDP-Context. 295 To configure its link local address, the cellular host 296 must use the Interface Identifier conveyed in 3GPP PDP- 297 Context setup signaling received from a GGSN/PGW. The 298 cellular host may use a different Interface Identifiers 299 to configure its global addresses (see also A_REC#1 300 about privacy addressing recommendation). 302 For more details, refer to [RFC6459] and [RFC7066]. 304 C_REC#9: The cellular host must comply with Section 7.3 of 305 [RFC6434]. 307 C_REC#10: The cellular host must comply with Section 7.2.1 of 308 [RFC6434]. 310 Stateless DHCPv6 is useful to retrieve other 311 information than DNS. 313 If [RFC6106] is not supported at the network side, the 314 cellular host should retrieve DNS information using 315 stateless DHCPv6 [RFC3736]. 317 C_REC#11: If the cellular host receives the DNS information in 318 several channels for the same interface, the following 319 preference order must be followed: 321 1. PCO 323 2. RA 325 3. DHCPv6 327 C_REC#12: The cellular host must be able to be configured to limit 328 PDP type(s) for a given APN. The default mode is to allow 329 all supported PDP types. Note, C_REC#3 discusses the 330 default behavior for requesting PDP-Context type(s). 332 This feature is useful to drive the behavior of the UE 333 to be aligned with: (1) service-specific constraints 334 such as the use of IPv6-only for VoLTE (Voice over 335 LTE), (2) network conditions with regards to the 336 support of specific PDP types (e.g., IPv4v6 PDP-Context 337 is not supported), (3) IPv4 sunset objectives, (4) 338 subscription data, etc. 340 C_REC#13: Because of potential operational deficiencies to be 341 experienced in some roaming situations, the cellular host 342 must be able to be configured with a home IP profile and a 343 roaming IP profile. The aim of the roaming profile is to 344 limit the PDP type(s) requested by the cellular host when 345 out of the home network. Note, distinct PDP type(s) can 346 be configured for home and roaming cases. 348 C_REC#14: In order to ensure IPv4 service continuity in an IPv6-only 349 deployment context, the cellular host should support a 350 method to locally construct IPv4-embedded IPv6 addresses 351 [RFC6052]. A method to learn PREFIX64 should be supported 352 by the cellular host. 354 This solves the issue when applications use IPv4 355 referrals on IPv6-only access networks. 357 In PCP-based environments, cellular hosts should follow 358 [RFC7225] to learn the IPv6 Prefix used by an upstream 359 PCP-controlled NAT64 device. If PCP is not enabled, 360 the cellular host should implement the method specified 361 in [RFC7050] to retrieve the PREFIX64. 363 C_REC#15: In order to ensure IPv4 service continuity in an IPv6-only 364 deployment context, the cellular host should implement the 365 Customer Side Translator (CLAT, [RFC6877]) function which 366 is compliant with [RFC6052][RFC6145][RFC6146]. 368 CLAT function in the cellular host allows for IPv4-only 369 application and IPv4-referals to work on an IPv6-only 370 connectivity. CLAT function requires a NAT64 371 capability [RFC6146] in the core network. 373 C_REC#16: In order to ensure IPv4 service continuity in an IPv6-only 374 deployment context, the cellular host should embed a DNS64 375 function [RFC6147]. 377 Local DNS64 functionality allows for compatibility with 378 DNS Security Extensions (DNSSEC, [RFC4033], [RFC4034], 379 [RFC4035]). Means to configure or discover a PREFIX64 380 is also required on the cellular device as discussed in 381 C_REC#14. 383 C_REC#17: The cellular host should support PCP [RFC6887]. 385 The support of PCP is seen as a driver to save battery 386 consumption exacerbated by keepalive messages. PCP 387 also gives the possibility of enabling incoming 388 connections to the cellular device. Indeed, because 389 several stateful devices may be deployed in wireless 390 networks (e.g., NAT and/or Firewalls), PCP can be used 391 by the cellular host to control network-based NAT and 392 Firewall functions which will reduce per-application 393 signaling and save battery consumption. 395 C_REC#18: When the cellular host is dual-stack connected (i.e., 396 configured with an IPv4 address and IPv6 prefix), it 397 should support means to prefer native IPv6 connection over 398 connection established through translation devices (e.g., 399 NAT44 and NAT64). 401 When both IPv4 and IPv6 DNS servers are configured, a 402 dual-stack host must contact first its IPv6 DNS server. 404 Cellular hosts should follow the procedure specified in 405 [RFC6724] for source address selection. 407 C_REC#19: The cellular host should support Happy Eyeballs procedure 408 defined in [RFC6555]. 410 2.1. WLAN Connectivity Recommendations 412 It is increasingly common for cellular hosts have a WLAN interface in 413 addition to their cellular interface. These hosts are likely to be 414 connected to private or public hotspots. Below are listed some 415 generic recommendations: 417 W_REC#1: IPv6 must be supported on the WLAN interface. In 418 particular, WLAN interface must behave properly when only 419 an IPv6 connectivity is provided. 421 Some tests revealed that IPv4 configuration is required 422 to enable IPv6-only connectivity. Indeed, some cellular 423 handsets can access a WLAN IPv6-only network by 424 configuring first a static IPv4 address. Once the 425 device is connected to the network and the wlan0 426 interface got an IPv6 global address, the IPv4 address 427 can be deleted from the configuration. This avoids the 428 device to ask automatically for a DHCPv4 server, and 429 allows to connect to IPv6-only networks. Failing to 430 configure an IPv4 address on the interface must not 431 prohibit using IPv6 on the same interface. 433 IPv6 Stateless Address Autoconfiguration ([RFC4862]) 434 must be supported. 436 W_REC#2: DHCPv6 client should be supported on WLAN interface. 438 Refer to Section 7.2.1 of [RFC6434]. 440 W_REC#3: WLAN interface should support Router Advertisement Options 441 for DNS configuration (See Section 7.3 of [RFC6434]). 443 W_REC#4: If the device receives the DNS information in several 444 channels for the same interface, the following preference 445 order must be followed: 447 1. RA 449 2. DHCPv6 451 3. Advanced Recommendations 453 This section identifies a set of advanced recommendations to meet 454 regulatory constraints in some countries, fulfill requirements of 455 critical services such as VoLTE, or enforce policies such as traffic 456 offload. 458 A_REC#1: The cellular host must be able to generate IPv6 addresses 459 which preserve privacy. 461 The activation of privacy extension (e.g., using 462 [RFC4941] or [RFC7217]) makes it more difficult to track 463 a host over time when compared to using a permanent 464 Interface Identifier. Note, [RFC4941] does not require 465 any DAD mechanism to be activated as the GGSN/PGW must 466 not configure any global address based on the prefix 467 allocated to the cellular host. 469 Tracking a host is still possible based on the first 64 470 bits of the IPv6 address. Means to prevent against such 471 tracking issues may be enabled in the network side. 473 Privacy extensions are required by regulatory bodies in 474 some countries. 476 A_REC#2: The cellular host must support ROHC RTP Profile (0x0001) 477 and ROHC UDP Profile (0x0002) for IPv6 ([RFC5795]). Other 478 ROHC profiles may be supported. 480 Bandwidth in cellular networks must be optimized as much 481 as possible. ROHC provides a solution to reduce 482 bandwidth consumption and to reduce the impact of having 483 bigger packet headers in IPv6 compared to IPv4. 485 "RTP/UDP/IP" ROHC profile (0x0001) to compress RTP 486 packets [RFC3550] and "UDP/IP" ROHC profile (0x0002) to 487 compress RTCP packets [RFC3550] are required for Voice 488 over LTE (VoLTE) by IR.92.4.0 section 4.1 [IR92]. Note, 489 [IR92] indicates also the host must be able to apply the 490 compression to packets that are carried over the radio 491 bearer dedicated for the voice media. 493 A_REC#3: The cellular host must comply with Section 5.3 of [RFC6434] 494 and should support Router Advertisement extension for 495 communicating default router preferences and more-specific 496 routes as described in [RFC4191]. 498 This function can be used for instance for traffic 499 offload. 501 4. Recommendations for Cellular Devices with LAN Capabilities 503 This section focuses on cellular devices (e.g., CPE, smartphones, or 504 dongles with tethering features) which provide IP connectivity to 505 other devices connected to them. In such case, all connected devices 506 are sharing the same 2G, 3G or LTE connection. In addition to the 507 generic recommendations listed in Section 2, these cellular devices 508 have to meet the recommendations listed below. 510 L_REC#1: The cellular device must support Prefix Delegation 511 capabilities [RFC3633] and must support Prefix Exclude 512 Option for DHCPv6-based Prefix Delegation as defined in 513 [RFC6603]. Particularly, it must behave as a Requesting 514 Router. 516 Cellular networks are more and more perceived as an 517 alternative to fixed networks for home IP-based services 518 delivery; especially with the advent of smartphones and 519 3GPP data dongles. There is a need for an efficient 520 mechanism to assign shorter prefix than /64 to cellular 521 hosts so that each LAN segment can get its own /64 522 prefix and multi-link subnet issues to be avoided. 524 In case a prefix is delegated to a cellular host using 525 DHCPv6, the cellular device will be configured with two 526 prefixes: 528 (1) one for 3GPP link allocated using SLAAC mechanism 529 and 531 (2) another one delegated for LANs acquired during 532 Prefix Delegation operation. 534 Note that the 3GPP network architecture requires both 535 the WAN (Wide Area Network) and the delegated prefix to 536 be aggregatable, so the subscriber can be identified 537 using a single prefix. 539 Without the Prefix Exclude Option, the delegating router 540 (GGSN/PGW) will have to ensure [RFC3633] compliancy 541 (e.g., halving the delegated prefix and assigning the 542 WAN prefix out of the 1st half and the prefix to be 543 delegated to the terminal from the 2nd half). 545 L_REC#2: The cellular CPE must be compliant with the requirements 546 specified in [RFC6204]. 548 There are several deployments, particularly in emerging 549 countries, that relies on mobile networks to provide 550 broadband services (e.g., customers are provided with 551 mobile CPEs). 553 L_REC#3: For deployments requiring to share the same /64 prefix, the 554 cellular device should support [RFC7278] to enable sharing 555 a /64 prefix between the 3GPP interface towards the GGSN/ 556 PGW (WAN interface) and the LAN interfaces. 558 L_REC#4: In order to ensure IPv4 service continuity in an IPv6-only 559 deployment context, the cellular device should support the 560 Customer Side Translator (CLAT) [RFC6877]. 562 Various IP devices are likely to be connected to 563 cellular device, acting as a CPE. Some of these devices 564 can be dual-stack, others are IPv6-only or IPv4-only. 565 IPv6-only connectivity for cellular device does not 566 allow IPv4-only sessions to be established for hosts 567 connected on the LAN segment of cellular devices. 569 In order to allow IPv4 sessions establishment initiated 570 from devices located on LAN segment side and target IPv4 571 nodes, a solution consists in integrating the CLAT 572 function in the cellular device. As elaborated in 573 Section 2, the CLAT function allows also IPv4 574 applications to continue running over an IPv6-only host. 576 L_REC#5: If a RA MTU is advertised from the 3GPP network, the 577 cellular device should relay that upstream MTU information 578 to the downstream attached LAN devices in RA. 580 Receiving and relaying RA MTU values facilitates a more 581 harmonious functioning of the mobile core network where 582 end nodes transmit packets that do not exceed the MTU 583 size of the mobile network's GTP tunnels. 585 [TS.23060] indicates providing a link MTU value of 1358 586 octets to the 3GPP cellular device will prevent the IP 587 layer fragmentation within the transport network between 588 the cellular device and the GGSN/PGW. 590 5. APIs & Applications Recommendations 592 The use of address family dependent APIs (Application Programming 593 Interfaces) or hard-coded IPv4 address literals may lead to broken 594 applications when IPv6 connectivity is in use. This section 595 identifies a set of recommendations aiming to minimize broken 596 applications when the cellular device is attached to an IPv6 network. 598 APP_REC#1: Name resolution libraries must support both IPv4 and 599 IPv6. 601 In particular, the cellular host must support 602 [RFC3596]. 604 APP_REC#2: Applications provided by the mobile device vendor must be 605 independent of the underlying IP address family. 607 This means applications must be IP version agnostic. 609 APP_REC#3: Applications provided by the mobile device vendor that 610 use Uniform Resource Identifiers (URIs) must follow 611 [RFC3986]. For example, SIP applications must follow the 612 correction defined in [RFC5954]. 614 6. Security Considerations 616 The security considerations identified in [RFC7066] and [RFC6459] are 617 to be taken into account. 619 Security-related considerations that apply when the cellular device 620 provides LAN features are specified in [RFC6092]. 622 Address privacy considerations are discussed in [RFC4941] [RFC7217]. 624 7. IANA Considerations 626 This document does not require any action from IANA. 628 8. Acknowledgements 630 Many thanks to H. Soliman, H. Singh, L. Colliti, T. Lemon, B. 631 Sarikaya, M. Mawatari, M. Abrahamsson, P. Vickers, V. Kuarsingh, 632 N. Heatley, E. Kline, S. Josefsson, A. Baryun, J. Woodyatt, and 633 R. Chandler for the discussion in the v6ops mailing list. 635 Special thanks to T. Savolainen, J. Korhonen, and J. Jaeggli for 636 their detailed reviews and comments. 638 9. References 640 9.1. Normative References 642 [IR92] GSMA, "IR.92.V4.0 - IMS Profile for Voice and SMS", March 643 2011, . 646 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 647 Requirement Levels", BCP 14, RFC 2119, March 1997. 649 [RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6 650 (IPv6) Specification", RFC 2460, December 1998. 652 [RFC3596] Thomson, S., Huitema, C., Ksinant, V., and M. Souissi, 653 "DNS Extensions to Support IP Version 6", RFC 3596, 654 October 2003. 656 [RFC3633] Troan, O. and R. Droms, "IPv6 Prefix Options for Dynamic 657 Host Configuration Protocol (DHCP) version 6", RFC 3633, 658 December 2003. 660 [RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform 661 Resource Identifier (URI): Generic Syntax", STD 66, RFC 662 3986, January 2005. 664 [RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman, 665 "Neighbor Discovery for IP version 6 (IPv6)", RFC 4861, 666 September 2007. 668 [RFC4862] Thomson, S., Narten, T., and T. Jinmei, "IPv6 Stateless 669 Address Autoconfiguration", RFC 4862, September 2007. 671 [RFC5795] Sandlund, K., Pelletier, G., and L-E. Jonsson, "The RObust 672 Header Compression (ROHC) Framework", RFC 5795, March 673 2010. 675 [RFC5942] Singh, H., Beebee, W., and E. Nordmark, "IPv6 Subnet 676 Model: The Relationship between Links and Subnet 677 Prefixes", RFC 5942, July 2010. 679 [RFC5954] Gurbani, V., Carpenter, B., and B. Tate, "Essential 680 Correction for IPv6 ABNF and URI Comparison in RFC 3261", 681 RFC 5954, August 2010. 683 [RFC6052] Bao, C., Huitema, C., Bagnulo, M., Boucadair, M., and X. 684 Li, "IPv6 Addressing of IPv4/IPv6 Translators", RFC 6052, 685 October 2010. 687 [RFC6603] Korhonen, J., Savolainen, T., Krishnan, S., and O. Troan, 688 "Prefix Exclude Option for DHCPv6-based Prefix 689 Delegation", RFC 6603, May 2012. 691 [RFC7066] Korhonen, J., Arkko, J., Savolainen, T., and S. Krishnan, 692 "IPv6 for Third Generation Partnership Project (3GPP) 693 Cellular Hosts", RFC 7066, November 2013. 695 [TS.23060] 696 3GPP, "General Packet Radio Service (GPRS); Service 697 description; Stage 2", September 2011. 699 [TS.23401] 700 3GPP, "General Packet Radio Service (GPRS) enhancements 701 for Evolved Universal Terrestrial Radio Access Network 702 (E-UTRAN) access", September 2011. 704 [TS.24008] 705 3GPP, "Mobile radio interface Layer 3 specification; Core 706 network protocols; Stage 3", June 2011. 708 9.2. Informative References 710 [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, 711 A., Peterson, J., Sparks, R., Handley, M., and E. 712 Schooler, "SIP: Session Initiation Protocol", RFC 3261, 713 June 2002. 715 [RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V. 716 Jacobson, "RTP: A Transport Protocol for Real-Time 717 Applications", STD 64, RFC 3550, July 2003. 719 [RFC3736] Droms, R., "Stateless Dynamic Host Configuration Protocol 720 (DHCP) Service for IPv6", RFC 3736, April 2004. 722 [RFC4033] Arends, R., Austein, R., Larson, M., Massey, D., and S. 723 Rose, "DNS Security Introduction and Requirements", RFC 724 4033, March 2005. 726 [RFC4034] Arends, R., Austein, R., Larson, M., Massey, D., and S. 727 Rose, "Resource Records for the DNS Security Extensions", 728 RFC 4034, March 2005. 730 [RFC4035] Arends, R., Austein, R., Larson, M., Massey, D., and S. 731 Rose, "Protocol Modifications for the DNS Security 732 Extensions", RFC 4035, March 2005. 734 [RFC4191] Draves, R. and D. Thaler, "Default Router Preferences and 735 More-Specific Routes", RFC 4191, November 2005. 737 [RFC4941] Narten, T., Draves, R., and S. Krishnan, "Privacy 738 Extensions for Stateless Address Autoconfiguration in 739 IPv6", RFC 4941, September 2007. 741 [RFC6092] Woodyatt, J., "Recommended Simple Security Capabilities in 742 Customer Premises Equipment (CPE) for Providing 743 Residential IPv6 Internet Service", RFC 6092, January 744 2011. 746 [RFC6106] Jeong, J., Park, S., Beloeil, L., and S. Madanapalli, 747 "IPv6 Router Advertisement Options for DNS Configuration", 748 RFC 6106, November 2010. 750 [RFC6145] Li, X., Bao, C., and F. Baker, "IP/ICMP Translation 751 Algorithm", RFC 6145, April 2011. 753 [RFC6146] Bagnulo, M., Matthews, P., and I. van Beijnum, "Stateful 754 NAT64: Network Address and Protocol Translation from IPv6 755 Clients to IPv4 Servers", RFC 6146, April 2011. 757 [RFC6147] Bagnulo, M., Sullivan, A., Matthews, P., and I. van 758 Beijnum, "DNS64: DNS Extensions for Network Address 759 Translation from IPv6 Clients to IPv4 Servers", RFC 6147, 760 April 2011. 762 [RFC6204] Singh, H., Beebee, W., Donley, C., Stark, B., and O. 763 Troan, "Basic Requirements for IPv6 Customer Edge 764 Routers", RFC 6204, April 2011. 766 [RFC6434] Jankiewicz, E., Loughney, J., and T. Narten, "IPv6 Node 767 Requirements", RFC 6434, December 2011. 769 [RFC6459] Korhonen, J., Soininen, J., Patil, B., Savolainen, T., 770 Bajko, G., and K. Iisakkila, "IPv6 in 3rd Generation 771 Partnership Project (3GPP) Evolved Packet System (EPS)", 772 RFC 6459, January 2012. 774 [RFC6555] Wing, D. and A. Yourtchenko, "Happy Eyeballs: Success with 775 Dual-Stack Hosts", RFC 6555, April 2012. 777 [RFC6724] Thaler, D., Draves, R., Matsumoto, A., and T. Chown, 778 "Default Address Selection for Internet Protocol Version 6 779 (IPv6)", RFC 6724, September 2012. 781 [RFC6877] Mawatari, M., Kawashima, M., and C. Byrne, "464XLAT: 782 Combination of Stateful and Stateless Translation", RFC 783 6877, April 2013. 785 [RFC6887] Wing, D., Cheshire, S., Boucadair, M., Penno, R., and P. 786 Selkirk, "Port Control Protocol (PCP)", RFC 6887, April 787 2013. 789 [RFC7050] Savolainen, T., Korhonen, J., and D. Wing, "Discovery of 790 the IPv6 Prefix Used for IPv6 Address Synthesis", RFC 791 7050, November 2013. 793 [RFC7217] Gont, F., "A Method for Generating Semantically Opaque 794 Interface Identifiers with IPv6 Stateless Address 795 Autoconfiguration (SLAAC)", RFC 7217, April 2014. 797 [RFC7225] Boucadair, M., "Discovering NAT64 IPv6 Prefixes Using the 798 Port Control Protocol (PCP)", RFC 7225, May 2014. 800 [RFC7278] Byrne, C., Drown, D., and A. Vizdal, "Extending an IPv6 801 /64 Prefix from a Third Generation Partnership Project 802 (3GPP) Mobile Interface to a LAN Link", RFC 7278, June 803 2014. 805 [TS.23402] 806 3GPP, "Architecture enhancements for non-3GPP accesses", 807 September 2011. 809 Authors' Addresses 811 David Binet 812 France Telecom 813 Rennes 814 France 816 EMail: david.binet@orange.com 818 Mohamed Boucadair 819 France Telecom 820 Rennes 35000 821 France 823 EMail: mohamed.boucadair@orange.com 825 Ales Vizdal 826 Deutsche Telekom AG 828 EMail: ales.vizdal@t-mobile.cz 830 Cameron Byrne 831 T-Mobile 832 USA 834 EMail: Cameron.Byrne@T-Mobile.com 836 Gang Chen 837 China Mobile 839 EMail: phdgang@gmail.com