idnits 2.17.1 draft-binet-v6ops-cellular-host-reqs-rfc3316update-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 (Using the creation date from RFC3316, updated by this document, for RFC5378 checks: 2002-02-27) -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (September 18, 2012) is 4237 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 3315 (Obsoleted by RFC 8415) ** 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 5996 (Obsoleted by RFC 7296) ** 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 (-01) exists of draft-boucadair-6man-sip-proxy-00 == Outdated reference: A later version (-04) exists of draft-chen-pcp-mobile-deployment-01 == Outdated reference: A later version (-17) exists of draft-ietf-behave-nat64-discovery-heuristic-11 == Outdated reference: A later version (-29) exists of draft-ietf-pcp-base-26 == 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: 9 errors (**), 0 flaws (~~), 6 warnings (==), 4 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 Updates: 3316 (if approved) France Telecom 5 Intended status: Informational September 18, 2012 6 Expires: March 22, 2013 8 Internet Protocol Version 6 (IPv6) for Cellular Hosts 9 draft-binet-v6ops-cellular-host-reqs-rfc3316update-00 11 Abstract 13 This document lists a set of IPv6-related requirements to be 14 supported by cellular hosts. 16 This document updates RFC3316. 18 Requirements Language 20 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 21 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 22 document are to be interpreted as described in RFC 2119 [RFC2119]. 24 Status of this Memo 26 This Internet-Draft is submitted in full conformance with the 27 provisions of BCP 78 and BCP 79. 29 Internet-Drafts are working documents of the Internet Engineering 30 Task Force (IETF). Note that other groups may also distribute 31 working documents as Internet-Drafts. The list of current Internet- 32 Drafts is at http://datatracker.ietf.org/drafts/current/. 34 Internet-Drafts are draft documents valid for a maximum of six months 35 and may be updated, replaced, or obsoleted by other documents at any 36 time. It is inappropriate to use Internet-Drafts as reference 37 material or to cite them other than as "work in progress." 39 This Internet-Draft will expire on March 22, 2013. 41 Copyright Notice 43 Copyright (c) 2012 IETF Trust and the persons identified as the 44 document authors. All rights reserved. 46 This document is subject to BCP 78 and the IETF Trust's Legal 47 Provisions Relating to IETF Documents 48 (http://trustee.ietf.org/license-info) in effect on the date of 49 publication of this document. Please review these documents 50 carefully, as they describe your rights and restrictions with respect 51 to this document. Code Components extracted from this document must 52 include Simplified BSD License text as described in Section 4.e of 53 the Trust Legal Provisions and are provided without warranty as 54 described in the Simplified BSD License. 56 Table of Contents 58 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 59 1.1. Scope . . . . . . . . . . . . . . . . . . . . . . . . . . 3 60 2. Basic Connectivity Requirements . . . . . . . . . . . . . . . 3 61 2.1. WiFi Connectivity . . . . . . . . . . . . . . . . . . . . 6 62 3. Advanced Requirements . . . . . . . . . . . . . . . . . . . . 6 63 4. Cellular Hosts with LAN Capabilities . . . . . . . . . . . . . 8 64 5. APIs & Applications . . . . . . . . . . . . . . . . . . . . . 10 65 6. Security Considerations . . . . . . . . . . . . . . . . . . . 10 66 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 67 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 10 68 8.1. Normative References . . . . . . . . . . . . . . . . . . . 10 69 8.2. Informative References . . . . . . . . . . . . . . . . . . 12 70 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 14 72 1. Introduction 74 [RFC3316] lists a set of features to be supported by cellular hosts 75 to connect to GPRS and UMTS networks. Since the publication of that 76 document, new functions have been specified within 3GPP and IETF 77 while others have been updated. 79 Moreover, in light of recent IPv6 experiments and trials, additional 80 features to ease IPv6-only deployments while continuing accessing to 81 IPv4-only service are to be considered. 83 This document updates [RFC3316] with new functionalities to be 84 supported by cellular hosts. Note [RFC3316] considered only GPRS and 85 UMTS networks; this document also considers EPS (Evolved Packet 86 System). 88 A detailed overview of IPv6 support in 3GPP architectures is provided 89 in [RFC6459]. 91 This document makes use of the terms defined in [RFC6459]. 93 1.1. Scope 95 Various types of nodes are likely to be connected to 3GPP networks 96 and will require specific functions. Indeed, a 3GPP network can be 97 used to connect a phone, a CPE, M2M device, etc. Because of the 98 diversity of terminals which may connect to 3GPP networks, this 99 document provides first some generic IPv6 functionalities which are 100 valid for any node to be directly connected to 3GPP networks, 101 whatever its function or whatever the services (e.g., DNS, SIP) it 102 supports. Then, dedicated sections are included to cover specific 103 functionalities to be supported by some type of devices (e.g., 104 smartphones, devices providing some LAN functions (mobile CPE or 105 dongles), M2M devices). 107 M2M devices specifications are not considered in the first version of 108 this document. 110 2. Basic Connectivity Requirements 112 The requirements listed below are valid for 3GPP GPRS, UMTS and 3GPP 113 EPS access except that for EPS the cellular host requests IPv4v6 PDN 114 type (respectively IPv6 PDN type when the GPRS cellular host has to 115 request an IPv4v6 PDP context (respectively an IPv6 PDP context). 117 REQ#1: The cellular host MUST support both IPv6 PDP and IPv4v6 PDP 118 contexts 120 This allows each operator to select its own strategy regarding 121 IPv6 introduction. Both IPv6 and IPv4v6 PDP contexts MUST be 122 supported in addition to IPv4 PDP context. The network will be 123 tuned so that it can honor IPv4, IPv6 or IPv4v6 PDP requests. 125 REQ#2: The cellular host MUST comply with the behavior defined in 126 [TS.23060] and [TS.24008] in terms of requested PDP context type. 127 In particular the cellular host MUST request an IPv6 PDP context 128 if the cellular host is IPv6-only and requesting an IPv4v6 PDP 129 context if the cellular host is dual stack or when the cellular 130 host is not aware of connectivity types requested by devices 131 connected to it (e.g., cellular host with LAN capabilities): 133 * If the requested PDP context IPv4v6 is not supported but IPv4 134 and IPv6 PDP types are allowed, the cellular host is configured 135 with an IPv4 address or an IPv6 prefix. It MAY initiate 136 another PDP request than the one already activated for a given 137 APN. 139 * If the requested PDP type and subscription data allows only one 140 IP address family (IPv4 or IPv6), the cellular host MUST NOT 141 request a second PDP context to the same APN for the other IP 142 address family. 144 REQ#3: The cellular host MUST support the PCO (Protocol 145 Configuration Options) to retrieve the IPv6 address of the 146 Recursive DNS server. 148 In band signaling is a convenient method to inform the cellular 149 host about various services, including DNS server information. 150 It does not require any specific protocol to be supported and 151 it is already deployed in IPv4 cellular networks to convey such 152 DNS information. 154 REQ#4: The cellular host SHOULD support Router Advertisement Options 155 [RFC6106] for DNS configuration. 157 The support of this function allows for consistent method to 158 inform cellular host about DNS recursive server across various 159 access network types. The cellular host SHOULD support RA- 160 based DNS information discovery. 162 REQ#5: The cellular host SHOULD embed a DHCPv6 client [RFC3315] 164 In order to get some consistent way to inform cellular host 165 about DNS recursive server across various access networks and 166 in case [RFC6106] is not supported, the cellular host SHOULD 167 retrieving DNS information using DHCPv6 [RFC3646]. 169 REQ#6: The cellular host SHOULD support a method to locally 170 construct IPv4-embedded IPv6 addresses [RFC6052]. 172 This allows to solve issues related to application which uses 173 referral with IPv4 literals. 175 REQ#7: Particularly, the cellular host SHOULD support Customer Side 176 Translator function (CLAT, [I-D.ietf-v6ops-464xlat]) function 177 which is compliant with [RFC6052][RFC6145][RFC6146]. 179 As reported in [CLAT], 15% of applications are not compatible 180 with IPv6-only connectivity. Activating CLAT function in the 181 cellular host would allow to solve this problem and offer a 182 similar application experience for both users with IPv6-only 183 hosts and IPv4-enabled hosts. CLAT function is compatible with 184 the introduction of NAT64 capabilities in the core network. 186 REQ#8: The cellular device MAY embed a DNS64 function [RFC6147]. 188 This allows to be compatible with DNSSEC. A means to configure 189 PREFIX64 is required to be supported. 191 REQ#9: The cellular host SHOULD support PCP [I-D.ietf-pcp-base]. 193 The support of PCP is seen as a driver to save battery 194 consumption exacerbated b keepalive messages and also to allow 195 for successful incoming connections. Indeed, because several 196 stateful devices may be enabled in mobile networks (e.g., NAT, 197 Firewalls), PCP can be used by the cellular host to control and 198 to retrieve lifetime of NAT bindings, to ease NAT and Firewall 199 traversal for applications embedding IP address, to reduce 200 keep-alive messages and inherently save battery consumption as 201 reported in [I-D.chen-pcp-mobile-deployment]. 203 REQ#10: A method to learn PREFIX64 SHOULD be supported by cellular 204 hosts. 206 In PCP-based environments, cellular hosts SHOULD follow 207 [I-D.boucadair-pcp-nat64-prefix64-option] to learn the IPv6 208 Prefix used by an upstream PCP-controlled NAT64 device. 210 If PCP is not enabled, the cellular host SHOULD implement the 211 method specified in [I-D.ietf-behave-nat64-discovery-heuristic] 212 to retrieve the PREFIX64. 214 REQ#11: The cellular host SHOULD support means to prefer native IPv6 215 connection instead of crossing IPv4/IPv6 interworking devices. 217 Cellular hosts SHOULD follow the procedure specified in 218 [RFC6724] for address selection. 220 REQ#12: The cellular host MAY support the procedure defined in 221 [RFC6555]. 223 2.1. WiFi Connectivity 225 It is more and more common that cellular hosts have some Wi-Fi 226 interfaces in addition to cellular interface. These hosts are likely 227 to be connected to private or public hotspots. Below are listed some 228 generic requirements: 230 REQ#13: IPv6 MUST be supported on the Wi-Fi interface. 232 REQ#14: DHCPv6 client SHOULD be supported on Wi-Fi interface 233 ([RFC3736]) 235 REQ#15: Wi-Fi interface SHOULD support Router Advertisement Options 236 for DNS configuration ([RFC6106]) 238 3. Advanced Requirements 240 REQ#16: The cellular host MUST support IPv6 addressing architecture 241 ([RFC4291]). For address representation, [RFC5952] MUST be 242 supported. 244 REQ#17: The cellular host MUST support the ICMPv6 protocol 245 ([RFC4443]) 247 The base protocol MUST be fully implemented by every IPv6 node 248 as indicated in Section 2 of [RFC4443]. 250 REQ#18: The device MUST support the Neighbor Discovery Protocol 251 ([RFC4861] and [RFC5942]). 253 REQ#19: The cellular host MAY support DHCPv6. 255 DHCPv6 may be useful for cellular host configuration, besides 256 the address configuration itself where stateless addressing is 257 recommended. 259 REQ#20: The cellular host MUST support Stateless Address Auto 260 Configuration ([RFC4862]) apart from the exceptions noted in 261 [TS.23060] (3G) or [TS.23401] (LTE): 263 Stateless mode is the only way to configure a cellular host. 264 The GGSN must allocate a prefix that is unique within its scope 265 to each primary PDP context. 267 The cellular host MUST use the interface identifier sent in PDP 268 Context Accept message to configure its link local address. 269 The cellular host may use a different Interface Identifiers to 270 configure its global addresses. 272 REQ#21: The cellular host SHOULD NOT perform Duplicate Address 273 Detection (DAD) for these Global IPv6 addresses (as the GGSN or 274 PDN-GW must not configure any IPv6 addresses using the prefix 275 allocated to the cellular host). 277 REQ#22: The device SHOULD support the Privacy Extensions for 278 Stateless Address Autoconfiguration in IPv6 ([RFC4941]) 280 The activation of privacy extension make it hard to track a 281 host compared to using the same interface identifier over the 282 time. [RFC4941] does not require any DAD mechanism to be 283 activated as the GGSN (or PDN-GW) MUST NOT configure any global 284 address based on the prefix allocated to the cellular host. 286 REQ#23: The device SHOULD support ROHC for IPv6 ([RFC5795]) 288 Bandwidth in mobile environments must be optimized as much as 289 possible. ROHC provides a solution to reduce bandwidth 290 consumption and to reduce the impact of having bigger header in 291 IPv6 compared to IPv4. 293 REQ#24: The device SHOULD support IPv6 Router Advertisement Flags 294 Options ([RFC5175]). 296 Some flags are used by GGSN (or PDN-GW) to inform cellular 297 hosts about autoconfiguration process. 299 REQ#25: The device SHOULD support Path MTU discovery ([RFC1981]). 300 If MTU used by cellular hosts is larger than 1280 bytes, they can 301 rely on Path MTU discovery function to discover real path MTU. 303 REQ#26: The devices SHOULD support at least IPsec version 2 tunnel 304 mode (IKE2, [RFC5996]). 306 REQ#27: The device MAY support [I-D.boucadair-6man-sip-proxy] to 307 discover a SIP Proxy Server. 309 Access to sensitive SIP-based service offering relies on the 310 provisioning of the IP reachability information (IP address or 311 FQDN) of the outbound SIP Proxy Server [RFC3261]. Two means 312 have been defined in the past to provision such information: 313 (1) DHCPv6 SIP options or (2) Dedicated 3GPP PCO to convey the 314 address of the P-CSCF. Nevertheless, these means are not 315 sufficient because of the following reasons: (1) PCO-IE is not 316 mandatory in 3G networks (e.g., PCO information may not be 317 supported by terminals). (2) DHCPv6 is not required in all 3GPP 318 releases; moreover the support of DHCPv6 client is not 319 mandatory in the IETF IPv6 node requirements. (3) PCO-IE is not 320 available in non-3GPP networks. 322 This is very critical when the UE performs a network attachment 323 in a non-3GPP network because the user won't have access to 324 SIP-based services if no alternative means are supported. 326 4. Cellular Hosts with LAN Capabilities 328 Cellular hosts may provide some IP service access to other devices 329 connected to them. In such case, all connected devices are sharing 330 the same GPRS, UMTS or EPS connection. These cellular hosts can be a 331 CPE or specific cellular hosts commercialized to set up rapidly LANs 332 in various environment, or it can also be a smartphone or a dongles 333 with tethering features. In addition to the generic requirements 334 listed in Section 2, these hosts will have to embed specific 335 functions in order to allow other IP-enabled devices to get IP 336 connectivity services through these cellular devices. 338 REQ#28: The cellular device MUST support ND Proxy function [RFC4389] 339 to enable sharing of the /64 prefix between the 3GPP interface 340 towards the GGSN (WAN interface) and the LAN interfaces 341 recommendation in [TS.23060] and [TS.23401] is to allocate some 342 /64 prefix to cellular hosts. 344 Prefix delegation which allows for allocating shorter prefixes 345 is only available in 3GPP Release 10. As such, the available 346 solution is IPv6-enabled devices connected to cellular device 347 use this /64 prefix for IPv6 address autoconfiguration. This 348 solution has some drawbacks regarding Duplicate Address 349 Detection and multilink subnet requirements but it provides IP 350 connectivity in such scenarios. 352 REQ#29: The cellular device MUST support Prefix Delegation 353 capabilities [RFC3633]. Particularly, it MUST behave as a 354 Requesting Router. 356 Cellular networks are more and more perceived as an alternative 357 to fixed networks for home services delivery; especially with 358 the advent of smartphones and dongles. There is a need for an 359 efficient mechanism to assign shorter prefix than /64 to 360 cellular hosts so that each LAN segment can get its own /64 361 prefix and multilink subnet issues to be avoided. 363 REQ#30: The cellular device SHOULD support Prefix Exclude Option for 364 DHCPv6-based Prefix Delegation as defined in [RFC6603]. 366 In case a prefix is delegated to the cellular host using 367 DHCPv6, the cellular device will be configured with two 368 prefixes: (1) one for 3GPP link allocated using SLAAC mechanism 369 and (2) another one delegated for LANs acquired during Prefix 370 Delegation operation. 372 Without Prefix Exclude Option, the cellular device will be 373 identified with two different prefixes leading to additional 374 complexity to be managed in the operational network management 375 side. With Prefix Exclude Option, /64 prefix obtained during 376 SLAAC phase can be included in shorter prefix obtained through 377 DHCPv6 Prefix Delegation and the cellular device can be 378 identified using only that prefix. 380 REQ#31: The cellular device SHOULD support Customer Side Translator 381 (CLAT) [I-D.ietf-v6ops-464xlat]. 383 Various IP devices are likely to be connected to cellular 384 device, acting as a CPE. Some of these devices can be dual 385 stack, others are IPv6-only or IPv4-only. IPv6-only 386 connectivity for cellular device does not allow IPv4-only 387 sessions to be established for hosts connected on LAN segment 388 of cellular devices. 390 In order to allow IPv4 sessions establishment initiated from 391 devices located on LAN segment side and target IPv4 nodes, a 392 solution consists in integrating the CLAT function in the 393 cellular device. As elaborated in Section 2, the CLAT function 394 allows also IPv4 applications to continue running over an IPv6- 395 only host. 397 REQ#32: The cellular device MUST be compliant with CPE requirements 398 specified in [RFC6204] 400 5. APIs & Applications 402 REQ#33: Name resolution libraries MUST support both IPv4 and IPv6. 404 REQ#34: Applications MUST be independent of the underlying IP 405 address family. 407 REQ#35: Applications using URIs MUST follow [RFC3986]. For example, 408 SIP applications MUST follow the correction defined in [RFC5954]. 410 6. Security Considerations 412 Security considerations identified in [RFC3316] are to be taken into 413 account. 415 REQ#36: If the cellular device provides LAN features, it MUST be 416 compliant with security requirements specified in [RFC6092]. 418 7. IANA Considerations 420 This document does not require any action from IANA. 422 8. References 424 8.1. Normative References 426 [RFC1981] McCann, J., Deering, S., and J. Mogul, "Path MTU Discovery 427 for IP version 6", RFC 1981, August 1996. 429 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 430 Requirement Levels", BCP 14, RFC 2119, March 1997. 432 [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, 433 A., Peterson, J., Sparks, R., Handley, M., and E. 434 Schooler, "SIP: Session Initiation Protocol", RFC 3261, 435 June 2002. 437 [RFC3315] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C., 438 and M. Carney, "Dynamic Host Configuration Protocol for 439 IPv6 (DHCPv6)", RFC 3315, July 2003. 441 [RFC3633] Troan, O. and R. Droms, "IPv6 Prefix Options for Dynamic 442 Host Configuration Protocol (DHCP) version 6", RFC 3633, 443 December 2003. 445 [RFC3646] Droms, R., "DNS Configuration options for Dynamic Host 446 Configuration Protocol for IPv6 (DHCPv6)", RFC 3646, 447 December 2003. 449 [RFC3736] Droms, R., "Stateless Dynamic Host Configuration Protocol 450 (DHCP) Service for IPv6", RFC 3736, April 2004. 452 [RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform 453 Resource Identifier (URI): Generic Syntax", STD 66, 454 RFC 3986, January 2005. 456 [RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing 457 Architecture", RFC 4291, February 2006. 459 [RFC4443] Conta, A., Deering, S., and M. Gupta, "Internet Control 460 Message Protocol (ICMPv6) for the Internet Protocol 461 Version 6 (IPv6) Specification", RFC 4443, March 2006. 463 [RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman, 464 "Neighbor Discovery for IP version 6 (IPv6)", RFC 4861, 465 September 2007. 467 [RFC4862] Thomson, S., Narten, T., and T. Jinmei, "IPv6 Stateless 468 Address Autoconfiguration", RFC 4862, September 2007. 470 [RFC4941] Narten, T., Draves, R., and S. Krishnan, "Privacy 471 Extensions for Stateless Address Autoconfiguration in 472 IPv6", RFC 4941, September 2007. 474 [RFC5175] Haberman, B. and R. Hinden, "IPv6 Router Advertisement 475 Flags Option", RFC 5175, March 2008. 477 [RFC5795] Sandlund, K., Pelletier, G., and L-E. Jonsson, "The RObust 478 Header Compression (ROHC) Framework", RFC 5795, 479 March 2010. 481 [RFC5942] Singh, H., Beebee, W., and E. Nordmark, "IPv6 Subnet 482 Model: The Relationship between Links and Subnet 483 Prefixes", RFC 5942, July 2010. 485 [RFC5952] Kawamura, S. and M. Kawashima, "A Recommendation for IPv6 486 Address Text Representation", RFC 5952, August 2010. 488 [RFC5954] Gurbani, V., Carpenter, B., and B. Tate, "Essential 489 Correction for IPv6 ABNF and URI Comparison in RFC 3261", 490 RFC 5954, August 2010. 492 [RFC5996] Kaufman, C., Hoffman, P., Nir, Y., and P. Eronen, 493 "Internet Key Exchange Protocol Version 2 (IKEv2)", 494 RFC 5996, September 2010. 496 [RFC6052] Bao, C., Huitema, C., Bagnulo, M., Boucadair, M., and X. 497 Li, "IPv6 Addressing of IPv4/IPv6 Translators", RFC 6052, 498 October 2010. 500 [RFC6106] Jeong, J., Park, S., Beloeil, L., and S. Madanapalli, 501 "IPv6 Router Advertisement Options for DNS Configuration", 502 RFC 6106, November 2010. 504 [RFC6145] Li, X., Bao, C., and F. Baker, "IP/ICMP Translation 505 Algorithm", RFC 6145, April 2011. 507 [RFC6146] Bagnulo, M., Matthews, P., and I. van Beijnum, "Stateful 508 NAT64: Network Address and Protocol Translation from IPv6 509 Clients to IPv4 Servers", RFC 6146, April 2011. 511 [RFC6147] Bagnulo, M., Sullivan, A., Matthews, P., and I. van 512 Beijnum, "DNS64: DNS Extensions for Network Address 513 Translation from IPv6 Clients to IPv4 Servers", RFC 6147, 514 April 2011. 516 [RFC6555] Wing, D. and A. Yourtchenko, "Happy Eyeballs: Success with 517 Dual-Stack Hosts", RFC 6555, April 2012. 519 [RFC6603] Korhonen, J., Savolainen, T., Krishnan, S., and O. Troan, 520 "Prefix Exclude Option for DHCPv6-based Prefix 521 Delegation", RFC 6603, May 2012. 523 [RFC6724] Thaler, D., Draves, R., Matsumoto, A., and T. Chown, 524 "Default Address Selection for Internet Protocol Version 6 525 (IPv6)", RFC 6724, September 2012. 527 8.2. Informative References 529 [CLAT] "CLAT", . 531 [I-D.boucadair-6man-sip-proxy] 532 Boucadair, M. and D. Binet, "IPv6 RA Option for SIP Proxy 533 Server", draft-boucadair-6man-sip-proxy-00 (work in 534 progress), May 2011. 536 [I-D.boucadair-pcp-nat64-prefix64-option] 537 Boucadair, M., "Learn NAT64 PREFIX64s using PCP", 538 draft-boucadair-pcp-nat64-prefix64-option-02 (work in 539 progress), September 2012. 541 [I-D.chen-pcp-mobile-deployment] 542 Chen, G., Cao, Z., Boucadair, M., Ales, V., and L. 543 Thiebaut, "Analysis of Port Control Protocol in Mobile 544 Network", draft-chen-pcp-mobile-deployment-01 (work in 545 progress), July 2012. 547 [I-D.ietf-behave-nat64-discovery-heuristic] 548 Savolainen, T., Korhonen, J., and D. Wing, "Discovery of 549 IPv6 Prefix Used for IPv6 Address Synthesis", 550 draft-ietf-behave-nat64-discovery-heuristic-11 (work in 551 progress), July 2012. 553 [I-D.ietf-pcp-base] 554 Wing, D., Cheshire, S., Boucadair, M., Penno, R., and P. 555 Selkirk, "Port Control Protocol (PCP)", 556 draft-ietf-pcp-base-26 (work in progress), June 2012. 558 [I-D.ietf-v6ops-464xlat] 559 Mawatari, M., Kawashima, M., and C. Byrne, "464XLAT: 560 Combination of Stateful and Stateless Translation", 561 draft-ietf-v6ops-464xlat-08 (work in progress), 562 September 2012. 564 [RFC3316] Arkko, J., Kuijpers, G., Soliman, H., Loughney, J., and J. 565 Wiljakka, "Internet Protocol Version 6 (IPv6) for Some 566 Second and Third Generation Cellular Hosts", RFC 3316, 567 April 2003. 569 [RFC4389] Thaler, D., Talwar, M., and C. Patel, "Neighbor Discovery 570 Proxies (ND Proxy)", RFC 4389, April 2006. 572 [RFC6092] Woodyatt, J., "Recommended Simple Security Capabilities in 573 Customer Premises Equipment (CPE) for Providing 574 Residential IPv6 Internet Service", RFC 6092, 575 January 2011. 577 [RFC6204] Singh, H., Beebee, W., Donley, C., Stark, B., and O. 578 Troan, "Basic Requirements for IPv6 Customer Edge 579 Routers", RFC 6204, April 2011. 581 [RFC6459] Korhonen, J., Soininen, J., Patil, B., Savolainen, T., 582 Bajko, G., and K. Iisakkila, "IPv6 in 3rd Generation 583 Partnership Project (3GPP) Evolved Packet System (EPS)", 584 RFC 6459, January 2012. 586 [TS.23060] 587 3GPP, "General Packet Radio Service (GPRS); Service 588 description; Stage 2", September 2011. 590 [TS.23401] 591 3GPP, "General Packet Radio Service (GPRS) enhancements 592 for Evolved Universal Terrestrial Radio Access Network 593 (E-UTRAN) access", September 2011. 595 [TS.24008] 596 3GPP, "Mobile radio interface Layer 3 specification; Core 597 network protocols; Stage 3", June 2011. 599 Authors' Addresses 601 David Binet 602 France Telecom 603 Rennes, 604 France 606 Email: david.binet@orange.com 608 Mohamed Boucadair 609 France Telecom 610 Rennes, 35000 611 France 613 Email: mohamed.boucadair@orange.com