idnits 2.17.1 draft-binet-v6ops-cellular-host-requirements-00.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 (November 12, 2012) is 4182 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Missing Reference: 'I-D.ietf-v6ops-64share' is mentioned on line 378, but not defined ** 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-12 == 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-08 -- 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 (~~), 5 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: May 16, 2013 A. Vizdal 6 Deutsche Telekom AG 7 C. Byrne 8 T-Mobile 9 G. Chen 10 China Mobile 11 November 12, 2012 13 Internet Protocol Version 6 (IPv6) Requirements for Cellular Hosts 14 draft-binet-v6ops-cellular-host-requirements-00 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 May 16, 2013. 44 Copyright Notice 46 Copyright (c) 2012 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. Scope . . . . . . . . . . . . . . . . . . . . . . . . . . 3 63 2. Connectivity Requirements . . . . . . . . . . . . . . . . . . 3 64 2.1. WiFi Connectivity . . . . . . . . . . . . . . . . . . . . 7 65 3. Advanced Requirements . . . . . . . . . . . . . . . . . . . . 7 66 4. Cellular Devices with LAN Capabilities . . . . . . . . . . . . 8 67 5. APIs & Applications . . . . . . . . . . . . . . . . . . . . . 10 68 6. Security Considerations . . . . . . . . . . . . . . . . . . . 10 69 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11 70 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 11 71 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 11 72 9.1. Normative References . . . . . . . . . . . . . . . . . . . 11 73 9.2. Informative References . . . . . . . . . . . . . . . . . . 13 74 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 14 76 1. Introduction 78 [RFC3316] lists a set of features to be supported by cellular hosts 79 to connect to 3GPP cellular networks. Since the publication of that 80 document, new functions have been specified within the 3GPP and the 81 IETF whilst others have been updated. Moreover, in the light of 82 recent IPv6 production deployments, additional features to facilitate 83 IPv6-only deployments while accessing IPv4-only service are to be 84 considered. 86 A detailed overview of IPv6 support in 3GPP architectures is provided 87 in [RFC6459]. 89 This document makes use of the terms defined in [RFC6459]. 91 PREFIX64 denotes an IPv6 prefix used to build IPv4-converted IPv6 92 addresses [RFC6052]. 94 1.1. Scope 96 Various types of nodes can be connected to 3GPP networks requiring 97 specific functions. Indeed, a 3GPP network can be used to connect 98 user equipment such as a mobile telephone, a CPE or a machine-to- 99 machine (M2M) device. Because of this diversity of terminals, it is 100 necessary to define a set of IPv6 functionalities valid for any node 101 directly connecting to a 3GPP network. This document describes these 102 functionalities. 104 This document is structured to initially provide the generic IPv6 105 requirements which are valid for all nodes, whatever their function 106 or service (e.g., SIP [RFC3261]) capability. The document also 107 contains, dedicated sections covering specific functionalities the 108 specific device types must support (e.g., smartphones, devices 109 providing some LAN functions (mobile CPE or broadband dongles)). 111 M2M devices profile is not considered in the first version of this 112 document. 114 The requirements listed below are valid for both 3GPP GPRS and 3GPP 115 EPS access. For EPS, "PDN type" terminology is used instead of "PDP 116 context". 118 2. Connectivity Requirements 119 REQ#1: The cellular host MUST support the IPv6 addressing 120 architecture described in ([RFC4291]). For address 121 representation, [RFC5952] MUST be supported. 123 REQ#2: The cellular host MUST support both IPv6 and IPv4v6 PDP 124 Contexts. 126 This allows each operator to select their own strategy 127 regarding IPv6 introduction. Both IPv6 and IPv4v6 PDP 128 contexts MUST be supported in addition to the IPv4 PDP 129 context. IPv4, IPv6 or IPv4v6 PDP-Context request 130 acceptance depends on the mobile network configuration. 132 REQ#3: The cellular host MUST comply with the behavior defined in 133 [TS.23060] [TS.23401] [TS.24008] for requesting a PDP context 134 type. In particular, the cellular host MUST request an IPv6 PDP 135 context if the cellular host is IPv6-only and requesting an 136 IPv4v6 PDP context if the cellular host is dual stack or when 137 the cellular host is not aware of connectivity types requested 138 by devices connected to it (e.g., cellular host with LAN 139 capabilities): 141 * If the requested IPv4v6 PDP context is not supported by the 142 network, but IPv4 and IPv6 PDP types are allowed, then the 143 cellular host will be configured with an IPv4 address 144 and/or an IPv6 prefix by the network. It MAY initiate 145 another PDP request in addition to the one already 146 activated for a given APN. 148 * If the requested PDP type and subscription data allows only 149 one IP address family (IPv4 or IPv6), the cellular host 150 MUST NOT request a second PDP context to the same APN for 151 the other IP address family. 153 REQ#4: The cellular host MUST support the PCO (Protocol 154 Configuration Options) [TS.24008] to retrieve the IPv6 155 address(es) of the Recursive DNS server(s). 157 In-band signaling is a convenient method to inform the 158 cellular host about various services, including DNS server 159 information. It does not require any specific protocol to 160 be supported and it is already deployed in IPv4 cellular 161 networks to convey such DNS information. 163 REQ#5: The cellular host MUST support IPv6 aware Traffic Flow 164 Templates (TFT) [TS.24008]. 166 Traffic Flow Templates are employing a Packet Filter to 167 couple an IP traffic with a PDP-Context. Thus a dedicated 168 PDP-Context and radio resources can be provided by the 169 mobile network for certain IP traffic. 171 REQ#6: The cellular host MUST support ICMPv6 ([RFC4443]). 173 The base protocol MUST be fully implemented by every IPv6 174 node as indicated in Section 2 of [RFC4443]. 176 REQ#7: The device MUST support the Neighbor Discovery Protocol 177 ([RFC4861] and [RFC5942]). 179 In particular, MTU communication via Router Advertisement 180 SHOULD be supported since many 3GPP networks do not have a 181 standard MTU setting due to inconsistencies in GTP 182 [RFC3314] mobility tunnel infrastructure deployments. 184 REQ#8: The cellular host MUST support IPv6 Stateless Address 185 Autoconfiguration ([RFC4862]) apart from the exceptions noted in 186 [TS.23060] (3G) and [TS.23401] (LTE): 188 Stateless mode is the only way to configure a cellular 189 host. The GGSN must allocate a prefix that is unique 190 within its scope to each primary PDP context. 192 The cellular host MUST use the interface identifier sent in 193 PDP Context Accept message to configure its link local 194 address. The cellular host may use a different Interface 195 Identifiers to configure its global addresses. 197 REQ#9: The cellular host SHOULD support Router Advertisement Options 198 [RFC6106] for DNS configuration. 200 The support of this function allows for a consistent method 201 of informing cellular hosts about DNS recursive servers 202 across various types of access networks. The cellular host 203 SHOULD support RA-based DNS information discovery. 205 REQ#10: The cellular host SHOULD embed a DHCPv6 client [RFC3736]. 207 If [RFC6106] is not supported, the cellular host SHOULD 208 retrieve DNS information using stateless DHCPv6 [RFC3736]. 210 If the cellular host receives the DNS information in 211 several channels for the same interface, the following 212 preference order MUST be followed: 213 1. PCO 214 2. RA 215 3. DHCPv6 217 REQ#11: The cellular host SHOULD support a method to locally 218 construct IPv4-embedded IPv6 addresses [RFC6052]. A method to 219 learn PREFIX64 SHOULD be supported by the cellular host. 221 This solves the issue when applications use IPv4 referrals 222 on IPv6-only access networks. 224 The cellular host SHOULD implement the method specified in 225 [I-D.ietf-behave-nat64-discovery-heuristic] to retrieve the 226 PREFIX64. 228 REQ#12: The cellular host SHOULD implement the Customer Side 229 Translator function (CLAT, [I-D.ietf-v6ops-464xlat]) function 230 which is compliant with [RFC6052][RFC6145][RFC6146]. 232 CLAT function in the cellular host allows for IPv4-only 233 application and IPv4-referals to work on an IPv6-only PDP. 234 CLAT function requires a NAT64 capability [RFC6146] in the 235 core network. 237 REQ#13: The cellular device SHOULD embed a DNS64 function [RFC6147]. 239 Local DNS64 functionality allows for compatibility with 240 DNSSEC. Means to configure or discover a PREFIX64 is also 241 required on the cellular device. 243 REQ#14: The cellular host SHOULD support PCP [I-D.ietf-pcp-base]. 245 The support of PCP is seen as a driver to save battery 246 consumption exacerbated by keepalive messages. PCP also 247 gives the possibility of enabling incoming connections to 248 the user. Indeed, because several stateful devices may be 249 deployed in mobile networks (e.g., NAT and/or Firewalls), 250 PCP can be used by the cellular host to control network 251 based NAT and Firewall functions which will reduce per- 252 application signaling and save battery consumption. 254 REQ#15: The cellular host SHOULD support means to prefer native IPv6 255 connection over NAT64 devices or NAT44 when the cellular host 256 gets dual stack connectivity. 258 Cellular hosts SHOULD follow the procedure specified in 259 [RFC6724] for source address selection. 261 Some potential issues are discussed in 262 [I-D.ietf-mif-happy-eyeballs-extension] for MIFed devices. 264 REQ#16: The cellular host SHOULD support the procedure defined in 265 [RFC6555]. 267 REQ#17: The cellular host SHOULD NOT perform Duplicate Address 268 Detection (DAD) for these Global IPv6 addresses (as the GGSN or 269 PDN-GW must not configure any IPv6 addresses using the prefix 270 allocated to the cellular host). 272 REQ#18: The cellular device MAY embed a BIH function [RFC6535] 273 facilitating the communication between an IPv4 application and 274 an IPv6 server. 276 2.1. WiFi Connectivity 278 It is increasingly common for cellular hosts have a Wi-Fi interface 279 in addition to their cellular interface. These hosts are likely to 280 be connected to private or public hotspots. Below are listed some 281 generic requirements: 283 REQ#19: IPv6 MUST be supported on the Wi-Fi interface. 285 REQ#20: DHCPv6 client SHOULD be supported on Wi-Fi interface 286 ([RFC3736]). 288 REQ#21: Wi-Fi interface SHOULD support Router Advertisement Options 289 for DNS configuration ([RFC6106]). 291 3. Advanced Requirements 293 REQ#22: The cellular host MUST support Path MTU discovery 294 ([RFC1981]). If the MTU used by cellular hosts is larger than 295 1280 bytes, they can rely on Path MTU discovery function to 296 discover the real path MTU. 298 REQ#23: The cellular host SHOULD support the Privacy Extensions for 299 Stateless Address Autoconfiguration in IPv6 ([RFC4941]). 301 The activation of privacy extension makes it more 302 difficult to track a host over time when compared to 303 using a permanent interface identifier. [RFC4941] does 304 not require any DAD mechanism to be activated as the 305 GGSN (or PDN-GW) MUST NOT configure any global address 306 based on the prefix allocated to the cellular host. 308 REQ#24: The cellular host SHOULD support ROHC for IPv6 ([RFC5795]). 310 Bandwidth in mobile environments must be optimized as 311 much as possible. ROHC provides a solution to reduce 312 bandwidth consumption and to reduce the impact of 313 having bigger packet headers in IPv6 compared to IPv4. 315 REQ#25: The cellular host SHOULD support IPv6 Router Advertisement 316 Flags Options ([RFC5175]). 318 Some flags are used by the GGSN (or PDN-GW) to inform 319 cellular hosts about the autoconfiguration process. 321 REQ#26: The cellular host SHOULD support Router Advertisement 322 extension for communicating default router preferences and 323 more-specific routes as described in [RFC4191]. 325 This function can be used for instance for traffic 326 offload. 328 4. Cellular Devices with LAN Capabilities 330 This section focuses on cellular devices (e.g., CPE, smartphones or 331 dongles with tethering features) which provide IP connectivity to 332 other devices connected to them. In such case, all connected devices 333 are sharing the same GPRS, UMTS or EPS connection. In addition to 334 the generic requirements listed in Section 2, these cellular devices 335 have to meet the requirements listed below. 337 REQ#27: The cellular device MUST support Prefix Delegation 338 capabilities [RFC3633] and MUST support Prefix Exclude Option 339 for DHCPv6-based Prefix Delegation as defined in [RFC6603]. 340 Particularly, it MUST behave as a Requesting Router. 342 Cellular networks are more and more perceived as an 343 alternative to fixed networks for home IP-based 344 services delivery; especially with the advent of 345 smartphones and 3GPP data dongles. There is a need for 346 an efficient mechanism to assign shorter prefix than 347 /64 to cellular hosts so that each LAN segment can get 348 its own /64 prefix and multilink subnet issues to be 349 avoided. 351 In case a prefix is delegated to a cellular host using 352 DHCPv6, the cellular device will be configured with two 353 prefixes: 355 (1) one for 3GPP link allocated using SLAAC 356 mechanism and 358 (2) another one delegated for LANs acquired 359 during Prefix Delegation operation. 361 Note that the 3GPP network architecture requires both 362 the WAN and the Delegated Prefix to be aggregatable, so 363 the subscriber can be identified using a single prefix. 365 Without the Prefix Exclude Option, the delegating 366 router (GGSN/PDN-GW) will have to ensure [RFC3633] 367 compliancy (e.g., halving the Delegated prefix and 368 assigning the WAN prefix out of the 1st half and the 369 prefix to be delegated to the terminal from the 2nd 370 half). 372 REQ#28: The cellular device MUST be compliant with the CPE 373 requirements specified in [RFC6204]. 375 REQ#29: Prefix delegation which allows to allocate a shorter prefix 376 to a cellular host is only available since 3GPP Release 10. 377 For deployments requiring to share the same /64 prefix, the 378 cellular device SHOULD support [I-D.ietf-v6ops-64share] to 379 enable sharing a /64 prefix between the 3GPP interface towards 380 the GGSN (WAN interface) and the LAN interfaces. 382 REQ#30: The cellular device SHOULD support the Customer Side 383 Translator (CLAT) [I-D.ietf-v6ops-464xlat]. 385 Various IP devices are likely to be connected to 386 cellular device, acting as a CPE. Some of these 387 devices can be dual-stack, others are IPv6-only or 388 IPv4-only. IPv6-only connectivity for cellular device 389 does not allow IPv4-only sessions to be established for 390 hosts connected on the LAN segment of cellular devices. 392 In order to allow IPv4 sessions establishment initiated 393 from devices located on LAN segment side and target 394 IPv4 nodes, a solution consists in integrating the CLAT 395 function in the cellular device. As elaborated in 396 Section 2, the CLAT function allows also IPv4 397 applications to continue running over an IPv6-only 398 host. 400 REQ#31: If a RA MTU is advertised from the 3GPP network, the 401 cellular device SHOULD relay that upstream MTU information to 402 the downstream attached LAN devices in RA. 404 Since 3GPP networks extensively use IP-in-IP/UDP GTP 405 tunnels, the effective MTU is frequently effectively 406 reduced to 1440 bytes. While a host may generate 407 packets with an MTU of 1500 bytes, this results in 408 undesirable fragmentation of the GTP IP/UDP packets. 410 Receiving and relaying RA MTU values facilitates a more 411 harmonious functioning of the mobile core network where 412 end nodes transmit packets that do not exceed the MTU 413 size of the mobile network's GTP tunnels. 415 5. APIs & Applications 417 REQ#32: Name resolution libraries MUST support both IPv4 and IPv6. 419 In particular, the cellular host MUST support 420 [RFC3596]. 422 REQ#33: Applications MUST be independent of the underlying IP 423 address family. 425 This means applications must be IP version agnostic. 427 REQ#34: Applications using URIs MUST follow [RFC3986]. For example, 428 SIP applications MUST follow the correction defined in 429 [RFC5954]. 431 6. Security Considerations 433 The security considerations identified in [RFC3316] are to be taken 434 into account. 436 REQ#35: If the cellular device provides LAN features, it SHOULD be 437 compliant with the security requirements specified in 438 [RFC6092]. 440 7. IANA Considerations 442 This document does not require any action from IANA. 444 8. Acknowledgements 446 Many thanks to H. Soliman, H. Singh, L. Colliti, T. Lemon, B. 447 Sarikaya, J. Korhonen and M. Mawatari for the discussion in the v6ops 448 mailing list. 450 9. References 452 9.1. Normative References 454 [RFC1981] McCann, J., Deering, S., and J. Mogul, "Path MTU Discovery 455 for IP version 6", RFC 1981, August 1996. 457 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 458 Requirement Levels", BCP 14, RFC 2119, March 1997. 460 [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, 461 A., Peterson, J., Sparks, R., Handley, M., and E. 462 Schooler, "SIP: Session Initiation Protocol", RFC 3261, 463 June 2002. 465 [RFC3596] Thomson, S., Huitema, C., Ksinant, V., and M. Souissi, 466 "DNS Extensions to Support IP Version 6", RFC 3596, 467 October 2003. 469 [RFC3633] Troan, O. and R. Droms, "IPv6 Prefix Options for Dynamic 470 Host Configuration Protocol (DHCP) version 6", RFC 3633, 471 December 2003. 473 [RFC3736] Droms, R., "Stateless Dynamic Host Configuration Protocol 474 (DHCP) Service for IPv6", RFC 3736, April 2004. 476 [RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform 477 Resource Identifier (URI): Generic Syntax", STD 66, 478 RFC 3986, January 2005. 480 [RFC4191] Draves, R. and D. Thaler, "Default Router Preferences and 481 More-Specific Routes", RFC 4191, November 2005. 483 [RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing 484 Architecture", RFC 4291, February 2006. 486 [RFC4443] Conta, A., Deering, S., and M. Gupta, "Internet Control 487 Message Protocol (ICMPv6) for the Internet Protocol 488 Version 6 (IPv6) Specification", RFC 4443, March 2006. 490 [RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman, 491 "Neighbor Discovery for IP version 6 (IPv6)", RFC 4861, 492 September 2007. 494 [RFC4862] Thomson, S., Narten, T., and T. Jinmei, "IPv6 Stateless 495 Address Autoconfiguration", RFC 4862, September 2007. 497 [RFC4941] Narten, T., Draves, R., and S. Krishnan, "Privacy 498 Extensions for Stateless Address Autoconfiguration in 499 IPv6", RFC 4941, September 2007. 501 [RFC5175] Haberman, B. and R. Hinden, "IPv6 Router Advertisement 502 Flags Option", RFC 5175, March 2008. 504 [RFC5795] Sandlund, K., Pelletier, G., and L-E. Jonsson, "The RObust 505 Header Compression (ROHC) Framework", RFC 5795, 506 March 2010. 508 [RFC5942] Singh, H., Beebee, W., and E. Nordmark, "IPv6 Subnet 509 Model: The Relationship between Links and Subnet 510 Prefixes", RFC 5942, July 2010. 512 [RFC5952] Kawamura, S. and M. Kawashima, "A Recommendation for IPv6 513 Address Text Representation", RFC 5952, August 2010. 515 [RFC5954] Gurbani, V., Carpenter, B., and B. Tate, "Essential 516 Correction for IPv6 ABNF and URI Comparison in RFC 3261", 517 RFC 5954, August 2010. 519 [RFC6052] Bao, C., Huitema, C., Bagnulo, M., Boucadair, M., and X. 520 Li, "IPv6 Addressing of IPv4/IPv6 Translators", RFC 6052, 521 October 2010. 523 [RFC6106] Jeong, J., Park, S., Beloeil, L., and S. Madanapalli, 524 "IPv6 Router Advertisement Options for DNS Configuration", 525 RFC 6106, November 2010. 527 [RFC6145] Li, X., Bao, C., and F. Baker, "IP/ICMP Translation 528 Algorithm", RFC 6145, April 2011. 530 [RFC6146] Bagnulo, M., Matthews, P., and I. van Beijnum, "Stateful 531 NAT64: Network Address and Protocol Translation from IPv6 532 Clients to IPv4 Servers", RFC 6146, April 2011. 534 [RFC6147] Bagnulo, M., Sullivan, A., Matthews, P., and I. van 535 Beijnum, "DNS64: DNS Extensions for Network Address 536 Translation from IPv6 Clients to IPv4 Servers", RFC 6147, 537 April 2011. 539 [RFC6535] Huang, B., Deng, H., and T. Savolainen, "Dual-Stack Hosts 540 Using "Bump-in-the-Host" (BIH)", RFC 6535, February 2012. 542 [RFC6555] Wing, D. and A. Yourtchenko, "Happy Eyeballs: Success with 543 Dual-Stack Hosts", RFC 6555, April 2012. 545 [RFC6603] Korhonen, J., Savolainen, T., Krishnan, S., and O. Troan, 546 "Prefix Exclude Option for DHCPv6-based Prefix 547 Delegation", RFC 6603, May 2012. 549 [RFC6724] Thaler, D., Draves, R., Matsumoto, A., and T. Chown, 550 "Default Address Selection for Internet Protocol Version 6 551 (IPv6)", RFC 6724, September 2012. 553 9.2. Informative References 555 [I-D.ietf-behave-nat64-discovery-heuristic] 556 Savolainen, T., Korhonen, J., and D. Wing, "Discovery of 557 the IPv6 Prefix Used for IPv6 Address Synthesis", 558 draft-ietf-behave-nat64-discovery-heuristic-12 (work in 559 progress), November 2012. 561 [I-D.ietf-mif-happy-eyeballs-extension] 562 Chen, G., Williams, C., Wing, D., and A. Yourtchenko, 563 "Happy Eyeballs Extension for Multiple Interfaces", 564 draft-ietf-mif-happy-eyeballs-extension-01 (work in 565 progress), October 2012. 567 [I-D.ietf-pcp-base] 568 Wing, D., Cheshire, S., Boucadair, M., Penno, R., and P. 569 Selkirk, "Port Control Protocol (PCP)", 570 draft-ietf-pcp-base-29 (work in progress), November 2012. 572 [I-D.ietf-v6ops-464xlat] 573 Mawatari, M., Kawashima, M., and C. Byrne, "464XLAT: 574 Combination of Stateful and Stateless Translation", 575 draft-ietf-v6ops-464xlat-08 (work in progress), 576 September 2012. 578 [RFC3314] Wasserman, M., "Recommendations for IPv6 in Third 579 Generation Partnership Project (3GPP) Standards", 580 RFC 3314, September 2002. 582 [RFC3316] Arkko, J., Kuijpers, G., Soliman, H., Loughney, J., and J. 583 Wiljakka, "Internet Protocol Version 6 (IPv6) for Some 584 Second and Third Generation Cellular Hosts", RFC 3316, 585 April 2003. 587 [RFC6092] Woodyatt, J., "Recommended Simple Security Capabilities in 588 Customer Premises Equipment (CPE) for Providing 589 Residential IPv6 Internet Service", RFC 6092, 590 January 2011. 592 [RFC6204] Singh, H., Beebee, W., Donley, C., Stark, B., and O. 593 Troan, "Basic Requirements for IPv6 Customer Edge 594 Routers", RFC 6204, April 2011. 596 [RFC6459] Korhonen, J., Soininen, J., Patil, B., Savolainen, T., 597 Bajko, G., and K. Iisakkila, "IPv6 in 3rd Generation 598 Partnership Project (3GPP) Evolved Packet System (EPS)", 599 RFC 6459, January 2012. 601 [TS.23060] 602 3GPP, "General Packet Radio Service (GPRS); Service 603 description; Stage 2", September 2011. 605 [TS.23401] 606 3GPP, "General Packet Radio Service (GPRS) enhancements 607 for Evolved Universal Terrestrial Radio Access Network 608 (E-UTRAN) access", September 2011. 610 [TS.24008] 611 3GPP, "Mobile radio interface Layer 3 specification; Core 612 network protocols; Stage 3", June 2011. 614 Authors' Addresses 616 David Binet 617 France Telecom 618 Rennes, 619 France 621 Email: david.binet@orange.com 622 Mohamed Boucadair 623 France Telecom 624 Rennes, 35000 625 France 627 Email: mohamed.boucadair@orange.com 629 Ales Vizdal 630 Deutsche Telekom AG 632 Phone: 633 Email: ales.vizdal@t-mobile.cz 634 URI: 636 Cameron Byrne 637 T-Mobile 638 USA 640 Phone: 641 Email: Cameron.Byrne@T-Mobile.com 643 Gang Chen 644 China Mobile 646 Email: phdgang@gmail.com