idnits 2.17.1 draft-binet-v6ops-cellular-host-requirements-02.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 (January 30, 2013) is 4104 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- ** Obsolete normative reference: RFC 1981 (Obsoleted by RFC 8201) ** Obsolete normative reference: RFC 3633 (Obsoleted by RFC 8415) ** Obsolete normative reference: RFC 3736 (Obsoleted by RFC 8415) ** Obsolete normative reference: RFC 4941 (Obsoleted by RFC 8981) ** Obsolete normative reference: RFC 6106 (Obsoleted by RFC 8106) ** Obsolete normative reference: RFC 6145 (Obsoleted by RFC 7915) ** Obsolete normative reference: RFC 6555 (Obsoleted by RFC 8305) == Outdated reference: A later version (-17) exists of draft-ietf-behave-nat64-discovery-heuristic-13 == Outdated reference: A later version (-11) exists of draft-ietf-mif-happy-eyeballs-extension-01 == Outdated reference: A later version (-10) exists of draft-ietf-v6ops-464xlat-09 == Outdated reference: A later version (-10) exists of draft-ietf-v6ops-64share-01 == Outdated reference: A later version (-06) exists of draft-ietf-v6ops-rfc3316bis-00 -- Obsolete informational reference (is this intentional?): RFC 3316 (Obsoleted by RFC 7066) -- Obsolete informational reference (is this intentional?): RFC 6204 (Obsoleted by RFC 7084) Summary: 7 errors (**), 0 flaws (~~), 6 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 V6OPS Working Group D. Binet 3 Internet-Draft M. Boucadair 4 Intended status: Informational France Telecom 5 Expires: August 3, 2013 A. Vizdal 6 Deutsche Telekom AG 7 C. Byrne 8 T-Mobile 9 G. Chen 10 China Mobile 11 January 30, 2013 13 Internet Protocol Version 6 (IPv6) Requirements for Cellular Hosts 14 draft-binet-v6ops-cellular-host-requirements-02 16 Abstract 18 This document lists a set of IPv6-related requirements to be 19 supported by cellular hosts. 21 Requirements Language 23 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 24 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 25 document are to be interpreted as described in RFC 2119 [RFC2119]. 27 Status of this Memo 29 This Internet-Draft is submitted in full conformance with the 30 provisions of BCP 78 and BCP 79. 32 Internet-Drafts are working documents of the Internet Engineering 33 Task Force (IETF). Note that other groups may also distribute 34 working documents as Internet-Drafts. The list of current Internet- 35 Drafts is at http://datatracker.ietf.org/drafts/current/. 37 Internet-Drafts are draft documents valid for a maximum of six months 38 and may be updated, replaced, or obsoleted by other documents at any 39 time. It is inappropriate to use Internet-Drafts as reference 40 material or to cite them other than as "work in progress." 42 This Internet-Draft will expire on August 3, 2013. 44 Copyright Notice 46 Copyright (c) 2013 IETF Trust and the persons identified as the 47 document authors. All rights reserved. 49 This document is subject to BCP 78 and the IETF Trust's Legal 50 Provisions Relating to IETF Documents 51 (http://trustee.ietf.org/license-info) in effect on the date of 52 publication of this document. Please review these documents 53 carefully, as they describe your rights and restrictions with respect 54 to this document. Code Components extracted from this document must 55 include Simplified BSD License text as described in Section 4.e of 56 the Trust Legal Provisions and are provided without warranty as 57 described in the Simplified BSD License. 59 Table of Contents 61 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 62 1.1. Why this document is needed? . . . . . . . . . . . . . . . 3 63 1.2. Scope . . . . . . . . . . . . . . . . . . . . . . . . . . 4 64 2. Connectivity Requirements . . . . . . . . . . . . . . . . . . 4 65 2.1. WiFi Connectivity . . . . . . . . . . . . . . . . . . . . 8 66 3. Advanced Requirements . . . . . . . . . . . . . . . . . . . . 9 67 4. Cellular Devices with LAN Capabilities . . . . . . . . . . . . 9 68 5. APIs & Applications . . . . . . . . . . . . . . . . . . . . . 11 69 6. Security Considerations . . . . . . . . . . . . . . . . . . . 12 70 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12 71 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 12 72 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 12 73 9.1. Normative References . . . . . . . . . . . . . . . . . . . 12 74 9.2. Informative References . . . . . . . . . . . . . . . . . . 14 75 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 16 77 1. Introduction 79 [RFC3316] lists a set of features to be supported by cellular hosts 80 to connect to 3GPP cellular networks. Since the publication of that 81 document, new functions have been specified within the 3GPP and the 82 IETF whilst others have been updated. Moreover, in the light of 83 recent IPv6 production deployments, additional features to facilitate 84 IPv6-only deployments while accessing IPv4-only service are to be 85 considered. 87 A detailed overview of IPv6 support in 3GPP architectures is provided 88 in [RFC6459]. 90 This document makes use of the terms defined in [RFC6459]. 92 PREFIX64 denotes an IPv6 prefix used to build IPv4-converted IPv6 93 addresses [RFC6052]. 95 1.1. Why this document is needed? 97 IPv6 deployment in mobile networks is the only perennial solution to 98 the exhaustion of IPv4 addresses in those networks. Several mobile 99 operators already deployed IPv6 or are in the pre-deployment phase. 100 One of the major hurdles encountered by mobile operators is the 101 availability of non-broken IPv6 implementation in mobile devices. 102 Some vendors are already proposing some mobile devices with a set of 103 IPv6 features, but the majority of devices are still lacking IPv6 104 support. 106 This document specifies an IPv6 profile for mobile devices listing 107 required specifications produced by various SDOs (in particular 3GPP 108 and IETF). The objectives of this effort are: 110 1. List in one single document all requirements a mobile device is 111 to comply with to connect to an IPv6 or dual stack mobile 112 network. These requirements cover various network types such as 113 GPRS, EPC or Wi-Fi 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 minimal set of requirements to allow for 121 IPv6 connectivity and IPv4 service continuity (over an IPv6- only 122 transport). 124 This document lists the required features while 126 [I-D.ietf-v6ops-rfc3316bis] is doing a good job in identifying issues 127 and explaining how to implement basic IPv6 features in a mobile 128 context. Some of the features discussed in 129 [I-D.ietf-v6ops-rfc3316bis] are also listed in this document as a 130 requirement: the main reason is to collect in one single document a 131 comprehensive list of requirements with the required language. 133 1.2. Scope 135 Various types of nodes can be connected to 3GPP networks requiring 136 specific functions. Indeed, a 3GPP network can be used to connect 137 user equipment such as a mobile telephone, a CPE or a machine-to- 138 machine (M2M) device. Because of this diversity of terminals, it is 139 necessary to define a set of IPv6 functionalities valid for any node 140 directly connecting to a 3GPP network. This document describes these 141 functionalities. 143 This document is structured to initially provide the generic IPv6 144 requirements which are valid for all nodes, whatever their function 145 or service (e.g., SIP [RFC3261]) capability. The document also 146 contains, dedicated sections covering specific functionalities the 147 specific device types must support (e.g., smartphones, devices 148 providing some LAN functions (mobile CPE or broadband dongles)). 150 M2M devices profile is out of scope. 152 The requirements listed below are valid for both 3GPP GPRS and 3GPP 153 EPS access. For EPS, "PDN type" terminology is used instead of "PDP 154 context". 156 2. Connectivity Requirements 158 REQ#1: The cellular host MUST support the IPv6 addressing 159 architecture described in ([RFC4291]). For address 160 representation, [RFC5952] MUST be supported. 162 REQ#2: The cellular host MUST support both IPv6 and IPv4v6 PDP 163 Contexts. 165 This allows each operator to select their own strategy 166 regarding IPv6 introduction. Both IPv6 and IPv4v6 PDP 167 contexts MUST be supported in addition to the IPv4 PDP 168 context. IPv4, IPv6 or IPv4v6 PDP-Context request 169 acceptance depends on the mobile network configuration. 171 REQ#3: The cellular host MUST comply with the behavior defined in 172 [TS.23060] [TS.23401] [TS.24008] for requesting a PDP context 173 type. In particular, the cellular host MUST request an IPv6 PDP 174 context if the cellular host is IPv6-only and requesting an 175 IPv4v6 PDP context if the cellular host is dual stack or when 176 the cellular host is not aware of connectivity types requested 177 by devices connected to it (e.g., cellular host with LAN 178 capabilities): 180 * If the requested IPv4v6 PDP context is not supported by the 181 network, but IPv4 and IPv6 PDP types are allowed, then the 182 cellular host will be configured with an IPv4 address 183 and/or an IPv6 prefix by the network. It MAY initiate 184 another PDP request in addition to the one already 185 activated for a given APN. 187 * If the requested PDP type and subscription data allows only 188 one IP address family (IPv4 or IPv6), the cellular host 189 MUST NOT request a second PDP context to the same APN for 190 the other IP address family. 192 The text above focuses on the specification part which explains 193 the behavior for requesting IPv6-related PDP context(s). 194 Understanding this behavior is important to avoid having broken 195 IPv6 implementations in cellular devices. 197 REQ#4: The cellular host MUST support the PCO (Protocol 198 Configuration Options) [TS.24008] to retrieve the IPv6 199 address(es) of the Recursive DNS server(s). 201 In-band signaling is a convenient method to inform the 202 cellular host about various services, including DNS server 203 information. It does not require any specific protocol to 204 be supported and it is already deployed in IPv4 cellular 205 networks to convey such DNS information. 207 REQ#5: The cellular host MUST support IPv6 aware Traffic Flow 208 Templates (TFT) [TS.24008]. 210 Traffic Flow Templates are employing a Packet Filter to 211 couple an IP traffic with a PDP-Context. Thus a dedicated 212 PDP-Context and radio resources can be provided by the 213 mobile network for certain IP traffic. 215 REQ#6: The cellular host MUST support ICMPv6 ([RFC4443]). 217 The base protocol MUST be fully implemented by every IPv6 218 node as indicated in Section 2 of [RFC4443]. 220 REQ#7: The device MUST support the Neighbor Discovery Protocol 221 ([RFC4861] and [RFC5942]). 223 In particular, MTU communication via Router Advertisement 224 SHOULD be supported since many 3GPP networks do not have a 225 standard MTU setting due to inconsistencies in GTP 226 [RFC3314] mobility tunnel infrastructure deployments. 228 REQ#8: The cellular host MUST support IPv6 Stateless Address 229 Autoconfiguration ([RFC4862]) apart from the exceptions noted in 230 [TS.23060] (3G) and [TS.23401] (LTE): 232 Stateless mode is the only way to configure a cellular 233 host. The GGSN must allocate a prefix that is unique 234 within its scope to each primary PDP context. 236 The cellular host MUST use the interface identifier sent in 237 PDP Context Accept message to configure its link local 238 address. The cellular host may use a different Interface 239 Identifiers to configure its global addresses. 241 REQ#9: The cellular host SHOULD support Router Advertisement Options 242 [RFC6106] for DNS configuration. 244 The support of this function allows for a consistent method 245 of informing cellular hosts about DNS recursive servers 246 across various types of access networks. The cellular host 247 SHOULD support RA-based DNS information discovery. 249 REQ#10: The cellular host SHOULD embed a DHCPv6 client [RFC3736]. 251 Stateless DHCPv6 is useful to retrieve other information 252 than DNS. 254 If [RFC6106] is not supported, the cellular host SHOULD 255 retrieve DNS information using stateless DHCPv6 [RFC3736]. 257 If the cellular host receives the DNS information in 258 several channels for the same interface, the following 259 preference order MUST be followed: 260 1. PCO 261 2. RA 262 3. DHCPv6 264 REQ#11: The cellular host SHOULD support a method to locally 265 construct IPv4-embedded IPv6 addresses [RFC6052]. A method to 266 learn PREFIX64 SHOULD be supported by the cellular host. 268 This solves the issue when applications use IPv4 referrals 269 on IPv6-only access networks. 271 The cellular host SHOULD implement the method specified in 272 [I-D.ietf-behave-nat64-discovery-heuristic] to retrieve the 273 PREFIX64. 275 REQ#12: The cellular host SHOULD implement the Customer Side 276 Translator function (CLAT, [I-D.ietf-v6ops-464xlat]) function 277 which is compliant with [RFC6052][RFC6145][RFC6146]. 279 CLAT function in the cellular host allows for IPv4-only 280 application and IPv4-referals to work on an IPv6-only PDP. 281 CLAT function requires a NAT64 capability [RFC6146] in the 282 core network. 284 REQ#13: The cellular device SHOULD embed a DNS64 function [RFC6147]. 286 Local DNS64 functionality allows for compatibility with 287 DNSSEC. Means to configure or discover a PREFIX64 is also 288 required on the cellular device. 290 REQ#14: The cellular host SHOULD support PCP [I-D.ietf-pcp-base]. 292 The support of PCP is seen as a driver to save battery 293 consumption exacerbated by keepalive messages. PCP also 294 gives the possibility of enabling incoming connections to 295 the user. Indeed, because several stateful devices may be 296 deployed in mobile networks (e.g., NAT and/or Firewalls), 297 PCP can be used by the cellular host to control network 298 based NAT and Firewall functions which will reduce per- 299 application signaling and save battery consumption. 301 REQ#15: When the cellular host is dual stack connected, it SHOULD 302 support means to prefer native IPv6 connection over connection 303 established through translation devices (e.g., NAT44 and NAT64). 305 Cellular hosts SHOULD follow the procedure specified in 306 [RFC6724] for source address selection. 308 Some potential issues are discussed in 309 [I-D.ietf-mif-happy-eyeballs-extension] for MIFed devices. 311 REQ#16: The cellular host SHOULD support Happy Eyeballs procedure 312 defined in [RFC6555]. 314 REQ#17: The cellular host SHOULD NOT perform Duplicate Address 315 Detection (DAD) for these Global IPv6 addresses (as the GGSN or 316 PDN-GW must not configure any IPv6 addresses using the prefix 317 allocated to the cellular host). Refer to Section 4 for DAD 318 considerations on the LAN interface when the 3GPP connection is 319 shared. 321 REQ#18: The cellular device MAY embed a BIH function [RFC6535] 322 facilitating the communication between an IPv4 application and 323 an IPv6 server. 325 2.1. WiFi Connectivity 327 It is increasingly common for cellular hosts have a Wi-Fi interface 328 in addition to their cellular interface. These hosts are likely to 329 be connected to private or public hotspots. Below are listed some 330 generic requirements: 332 REQ#19: IPv6 MUST be supported on the Wi-Fi interface. In 333 particular, IPv6-only connectivity MUST be supported over the 334 Wi-Fi interface. 336 Recent tests revealed that IPv4 configuration is 337 required to enable IPv6-only connectivity. Indeed, 338 some cellular handsets can access a Wi-Fi IPv6-only 339 network by configuring first a static IPv4 address. 340 Once the device is connected to the network and the 341 wlan0 interface got an IPv6 global address, the IPv4 342 address can be deleted from the configuration. This 343 avoids the device to ask automatically for a DHCPv4 344 server, and allows to connect to IPv6-only networks. 346 IPv6 Stateless Address Autoconfiguration ([RFC4862]) 347 MUST be supported. 349 REQ#20: DHCPv6 client SHOULD be supported on Wi-Fi interface 350 ([RFC3736]). 352 REQ#21: Wi-Fi interface SHOULD support Router Advertisement Options 353 for DNS configuration ([RFC6106]). If the device receives the 354 DNS information in several channels for the same interface, 355 the following preference order MUST be followed: 357 1. RA 358 2. DHCPv6 360 3. Advanced Requirements 362 REQ#22: The cellular host MUST support Path MTU discovery 363 ([RFC1981]). If the MTU used by cellular hosts is larger than 364 1280 bytes, they can rely on Path MTU discovery function to 365 discover the real path MTU. 367 REQ#23: The cellular host SHOULD support the Privacy Extensions for 368 Stateless Address Autoconfiguration in IPv6 ([RFC4941]). 370 The activation of privacy extension makes it more 371 difficult to track a host over time when compared to 372 using a permanent interface identifier. [RFC4941] does 373 not require any DAD mechanism to be activated as the 374 GGSN (or PDN-GW) MUST NOT configure any global address 375 based on the prefix allocated to the cellular host. 377 REQ#24: The cellular host SHOULD support ROHC for IPv6 ([RFC5795]). 379 Bandwidth in mobile environments must be optimized as 380 much as possible. ROHC provides a solution to reduce 381 bandwidth consumption and to reduce the impact of 382 having bigger packet headers in IPv6 compared to IPv4. 384 REQ#25: The cellular host SHOULD support IPv6 Router Advertisement 385 Flags Options ([RFC5175]). 387 Some flags are used by the GGSN (or PDN-GW) to inform 388 cellular hosts about the autoconfiguration process. 390 REQ#26: The cellular host SHOULD support Router Advertisement 391 extension for communicating default router preferences and 392 more-specific routes as described in [RFC4191]. 394 This function can be used for instance for traffic 395 offload. 397 4. Cellular Devices with LAN Capabilities 399 This section focuses on cellular devices (e.g., CPE, smartphones or 400 dongles with tethering features) which provide IP connectivity to 401 other devices connected to them. In such case, all connected devices 402 are sharing the same GPRS, UMTS or EPS connection. In addition to 403 the generic requirements listed in Section 2, these cellular devices 404 have to meet the requirements listed below. 406 REQ#27: The cellular device MUST support Prefix Delegation 407 capabilities [RFC3633] and MUST support Prefix Exclude Option 408 for DHCPv6-based Prefix Delegation as defined in [RFC6603]. 409 Particularly, it MUST behave as a Requesting Router. 411 Cellular networks are more and more perceived as an 412 alternative to fixed networks for home IP-based 413 services delivery; especially with the advent of 414 smartphones and 3GPP data dongles. There is a need for 415 an efficient mechanism to assign shorter prefix than 416 /64 to cellular hosts so that each LAN segment can get 417 its own /64 prefix and multilink subnet issues to be 418 avoided. 420 In case a prefix is delegated to a cellular host using 421 DHCPv6, the cellular device will be configured with two 422 prefixes: 424 (1) one for 3GPP link allocated using SLAAC 425 mechanism and 427 (2) another one delegated for LANs acquired 428 during Prefix Delegation operation. 430 Note that the 3GPP network architecture requires both 431 the WAN and the Delegated Prefix to be aggregatable, so 432 the subscriber can be identified using a single prefix. 434 Without the Prefix Exclude Option, the delegating 435 router (GGSN/PDN-GW) will have to ensure [RFC3633] 436 compliancy (e.g., halving the Delegated prefix and 437 assigning the WAN prefix out of the 1st half and the 438 prefix to be delegated to the terminal from the 2nd 439 half). 441 REQ#28: The cellular device MUST be compliant with the CPE 442 requirements specified in [RFC6204]. 444 REQ#29: Prefix delegation which allows to allocate a shorter prefix 445 to a cellular host is only available since 3GPP Release 10. 446 For deployments requiring to share the same /64 prefix, the 447 cellular device SHOULD support [I-D.ietf-v6ops-64share] to 448 enable sharing a /64 prefix between the 3GPP interface towards 449 the GGSN (WAN interface) and the LAN interfaces. 451 REQ#30: The cellular device SHOULD support the Customer Side 452 Translator (CLAT) [I-D.ietf-v6ops-464xlat]. 454 Various IP devices are likely to be connected to 455 cellular device, acting as a CPE. Some of these 456 devices can be dual-stack, others are IPv6-only or 457 IPv4-only. IPv6-only connectivity for cellular device 458 does not allow IPv4-only sessions to be established for 459 hosts connected on the LAN segment of cellular devices. 461 In order to allow IPv4 sessions establishment initiated 462 from devices located on LAN segment side and target 463 IPv4 nodes, a solution consists in integrating the CLAT 464 function in the cellular device. As elaborated in 465 Section 2, the CLAT function allows also IPv4 466 applications to continue running over an IPv6-only 467 host. 469 REQ#31: If a RA MTU is advertised from the 3GPP network, the 470 cellular device SHOULD relay that upstream MTU information to 471 the downstream attached LAN devices in RA. 473 Since 3GPP networks extensively use IP-in-IP/UDP GTP 474 tunnels, the effective MTU is frequently effectively 475 reduced to 1440 bytes. While a host may generate 476 packets with an MTU of 1500 bytes, this results in 477 undesirable fragmentation of the GTP IP/UDP packets. 479 Receiving and relaying RA MTU values facilitates a more 480 harmonious functioning of the mobile core network where 481 end nodes transmit packets that do not exceed the MTU 482 size of the mobile network's GTP tunnels. 484 5. APIs & Applications 486 REQ#32: Name resolution libraries MUST support both IPv4 and IPv6. 488 In particular, the cellular host MUST support 489 [RFC3596]. 491 REQ#33: Applications MUST be independent of the underlying IP 492 address family. 494 This means applications must be IP version agnostic. 496 REQ#34: Applications using URIs MUST follow [RFC3986]. For example, 497 SIP applications MUST follow the correction defined in 498 [RFC5954]. 500 6. Security Considerations 502 The security considerations identified in [RFC3316] are to be taken 503 into account. 505 REQ#35: If the cellular device provides LAN features, it SHOULD be 506 compliant with the security requirements specified in 507 [RFC6092]. 509 7. IANA Considerations 511 This document does not require any action from IANA. 513 8. Acknowledgements 515 Many thanks to H. Soliman, H. Singh, L. Colliti, T. Lemon, B. 516 Sarikaya, J. Korhonen, M. Mawatari, M. Abrahamsson, P. Vickers and V. 517 Kuarsingh for the discussion in the v6ops mailing list. 519 9. References 521 9.1. Normative References 523 [RFC1981] McCann, J., Deering, S., and J. Mogul, "Path MTU Discovery 524 for IP version 6", RFC 1981, August 1996. 526 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 527 Requirement Levels", BCP 14, RFC 2119, March 1997. 529 [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, 530 A., Peterson, J., Sparks, R., Handley, M., and E. 531 Schooler, "SIP: Session Initiation Protocol", RFC 3261, 532 June 2002. 534 [RFC3596] Thomson, S., Huitema, C., Ksinant, V., and M. Souissi, 535 "DNS Extensions to Support IP Version 6", RFC 3596, 536 October 2003. 538 [RFC3633] Troan, O. and R. Droms, "IPv6 Prefix Options for Dynamic 539 Host Configuration Protocol (DHCP) version 6", RFC 3633, 540 December 2003. 542 [RFC3736] Droms, R., "Stateless Dynamic Host Configuration Protocol 543 (DHCP) Service for IPv6", RFC 3736, April 2004. 545 [RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform 546 Resource Identifier (URI): Generic Syntax", STD 66, 547 RFC 3986, January 2005. 549 [RFC4191] Draves, R. and D. Thaler, "Default Router Preferences and 550 More-Specific Routes", RFC 4191, November 2005. 552 [RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing 553 Architecture", RFC 4291, February 2006. 555 [RFC4443] Conta, A., Deering, S., and M. Gupta, "Internet Control 556 Message Protocol (ICMPv6) for the Internet Protocol 557 Version 6 (IPv6) Specification", RFC 4443, March 2006. 559 [RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman, 560 "Neighbor Discovery for IP version 6 (IPv6)", RFC 4861, 561 September 2007. 563 [RFC4862] Thomson, S., Narten, T., and T. Jinmei, "IPv6 Stateless 564 Address Autoconfiguration", RFC 4862, September 2007. 566 [RFC4941] Narten, T., Draves, R., and S. Krishnan, "Privacy 567 Extensions for Stateless Address Autoconfiguration in 568 IPv6", RFC 4941, September 2007. 570 [RFC5175] Haberman, B. and R. Hinden, "IPv6 Router Advertisement 571 Flags Option", RFC 5175, March 2008. 573 [RFC5795] Sandlund, K., Pelletier, G., and L-E. Jonsson, "The RObust 574 Header Compression (ROHC) Framework", RFC 5795, 575 March 2010. 577 [RFC5942] Singh, H., Beebee, W., and E. Nordmark, "IPv6 Subnet 578 Model: The Relationship between Links and Subnet 579 Prefixes", RFC 5942, July 2010. 581 [RFC5952] Kawamura, S. and M. Kawashima, "A Recommendation for IPv6 582 Address Text Representation", RFC 5952, August 2010. 584 [RFC5954] Gurbani, V., Carpenter, B., and B. Tate, "Essential 585 Correction for IPv6 ABNF and URI Comparison in RFC 3261", 586 RFC 5954, August 2010. 588 [RFC6052] Bao, C., Huitema, C., Bagnulo, M., Boucadair, M., and X. 589 Li, "IPv6 Addressing of IPv4/IPv6 Translators", RFC 6052, 590 October 2010. 592 [RFC6106] Jeong, J., Park, S., Beloeil, L., and S. Madanapalli, 593 "IPv6 Router Advertisement Options for DNS Configuration", 594 RFC 6106, November 2010. 596 [RFC6145] Li, X., Bao, C., and F. Baker, "IP/ICMP Translation 597 Algorithm", RFC 6145, April 2011. 599 [RFC6146] Bagnulo, M., Matthews, P., and I. van Beijnum, "Stateful 600 NAT64: Network Address and Protocol Translation from IPv6 601 Clients to IPv4 Servers", RFC 6146, April 2011. 603 [RFC6147] Bagnulo, M., Sullivan, A., Matthews, P., and I. van 604 Beijnum, "DNS64: DNS Extensions for Network Address 605 Translation from IPv6 Clients to IPv4 Servers", RFC 6147, 606 April 2011. 608 [RFC6535] Huang, B., Deng, H., and T. Savolainen, "Dual-Stack Hosts 609 Using "Bump-in-the-Host" (BIH)", RFC 6535, February 2012. 611 [RFC6555] Wing, D. and A. Yourtchenko, "Happy Eyeballs: Success with 612 Dual-Stack Hosts", RFC 6555, April 2012. 614 [RFC6603] Korhonen, J., Savolainen, T., Krishnan, S., and O. Troan, 615 "Prefix Exclude Option for DHCPv6-based Prefix 616 Delegation", RFC 6603, May 2012. 618 [RFC6724] Thaler, D., Draves, R., Matsumoto, A., and T. Chown, 619 "Default Address Selection for Internet Protocol Version 6 620 (IPv6)", RFC 6724, September 2012. 622 9.2. Informative References 624 [I-D.ietf-behave-nat64-discovery-heuristic] 625 Savolainen, T., Korhonen, J., and D. Wing, "Discovery of 626 the IPv6 Prefix Used for IPv6 Address Synthesis", 627 draft-ietf-behave-nat64-discovery-heuristic-13 (work in 628 progress), November 2012. 630 [I-D.ietf-mif-happy-eyeballs-extension] 631 Chen, G., Williams, C., Wing, D., and A. Yourtchenko, 632 "Happy Eyeballs Extension for Multiple Interfaces", 633 draft-ietf-mif-happy-eyeballs-extension-01 (work in 634 progress), October 2012. 636 [I-D.ietf-pcp-base] 637 Wing, D., Cheshire, S., Boucadair, M., Penno, R., and P. 638 Selkirk, "Port Control Protocol (PCP)", 639 draft-ietf-pcp-base-29 (work in progress), November 2012. 641 [I-D.ietf-v6ops-464xlat] 642 Mawatari, M., Kawashima, M., and C. Byrne, "464XLAT: 643 Combination of Stateful and Stateless Translation", 644 draft-ietf-v6ops-464xlat-09 (work in progress), 645 January 2013. 647 [I-D.ietf-v6ops-64share] 648 Byrne, C. and D. Drown, "Extending an IPv6 /64 Prefix from 649 a 3GPP Mobile Interface to a LAN", 650 draft-ietf-v6ops-64share-01 (work in progress), 651 January 2013. 653 [I-D.ietf-v6ops-rfc3316bis] 654 Korhonen, J., Arkko, J., Savolainen, T., and S. Krishnan, 655 "IPv6 for 3GPP Cellular Hosts", 656 draft-ietf-v6ops-rfc3316bis-00 (work in progress), 657 November 2012. 659 [RFC3314] Wasserman, M., "Recommendations for IPv6 in Third 660 Generation Partnership Project (3GPP) Standards", 661 RFC 3314, September 2002. 663 [RFC3316] Arkko, J., Kuijpers, G., Soliman, H., Loughney, J., and J. 664 Wiljakka, "Internet Protocol Version 6 (IPv6) for Some 665 Second and Third Generation Cellular Hosts", RFC 3316, 666 April 2003. 668 [RFC6092] Woodyatt, J., "Recommended Simple Security Capabilities in 669 Customer Premises Equipment (CPE) for Providing 670 Residential IPv6 Internet Service", RFC 6092, 671 January 2011. 673 [RFC6204] Singh, H., Beebee, W., Donley, C., Stark, B., and O. 674 Troan, "Basic Requirements for IPv6 Customer Edge 675 Routers", RFC 6204, April 2011. 677 [RFC6459] Korhonen, J., Soininen, J., Patil, B., Savolainen, T., 678 Bajko, G., and K. Iisakkila, "IPv6 in 3rd Generation 679 Partnership Project (3GPP) Evolved Packet System (EPS)", 680 RFC 6459, January 2012. 682 [TS.23060] 683 3GPP, "General Packet Radio Service (GPRS); Service 684 description; Stage 2", September 2011. 686 [TS.23401] 687 3GPP, "General Packet Radio Service (GPRS) enhancements 688 for Evolved Universal Terrestrial Radio Access Network 689 (E-UTRAN) access", September 2011. 691 [TS.24008] 692 3GPP, "Mobile radio interface Layer 3 specification; Core 693 network protocols; Stage 3", June 2011. 695 Authors' Addresses 697 David Binet 698 France Telecom 699 Rennes, 700 France 702 Email: david.binet@orange.com 704 Mohamed Boucadair 705 France Telecom 706 Rennes, 35000 707 France 709 Email: mohamed.boucadair@orange.com 711 Ales Vizdal 712 Deutsche Telekom AG 714 Phone: 715 Email: ales.vizdal@t-mobile.cz 716 URI: 718 Cameron Byrne 719 T-Mobile 720 USA 722 Phone: 723 Email: Cameron.Byrne@T-Mobile.com 724 Gang Chen 725 China Mobile 727 Email: phdgang@gmail.com