idnits 2.17.1 draft-ietf-v6ops-host-addr-availability-07.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 : ---------------------------------------------------------------------------- == There are 2 instances of lines with private range IPv4 addresses in the document. If these are generic example addresses, they should be changed to use any of the ranges defined in RFC 6890 (or successor): 192.0.2.x, 198.51.100.x or 203.0.113.x. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (May 25, 2016) is 2891 days in the past. Is this intentional? Checking references for intended status: Best Current Practice ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Outdated reference: A later version (-04) exists of draft-herbert-nvo3-ila-02 -- Obsolete informational reference (is this intentional?): RFC 2460 (Obsoleted by RFC 8200) -- Obsolete informational reference (is this intentional?): RFC 3315 (Obsoleted by RFC 8415) -- Obsolete informational reference (is this intentional?): RFC 3633 (Obsoleted by RFC 8415) -- Obsolete informational reference (is this intentional?): RFC 4941 (Obsoleted by RFC 8981) -- Obsolete informational reference (is this intentional?): RFC 6434 (Obsoleted by RFC 8504) Summary: 0 errors (**), 0 flaws (~~), 3 warnings (==), 6 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 IPv6 Operations L. Colitti 3 Internet-Draft V. Cerf 4 Intended status: Best Current Practice Google 5 Expires: November 26, 2016 S. Cheshire 6 D. Schinazi 7 Apple Inc. 8 May 25, 2016 10 Host address availability recommendations 11 draft-ietf-v6ops-host-addr-availability-07 13 Abstract 15 This document recommends that networks provide general-purpose end 16 hosts with multiple global IPv6 addresses when they attach, and 17 describes the benefits of and the options for doing so. 19 Status of This Memo 21 This Internet-Draft is submitted in full conformance with the 22 provisions of BCP 78 and BCP 79. 24 Internet-Drafts are working documents of the Internet Engineering 25 Task Force (IETF). Note that other groups may also distribute 26 working documents as Internet-Drafts. The list of current Internet- 27 Drafts is at http://datatracker.ietf.org/drafts/current/. 29 Internet-Drafts are draft documents valid for a maximum of six months 30 and may be updated, replaced, or obsoleted by other documents at any 31 time. It is inappropriate to use Internet-Drafts as reference 32 material or to cite them other than as "work in progress." 34 This Internet-Draft will expire on November 26, 2016. 36 Copyright Notice 38 Copyright (c) 2016 IETF Trust and the persons identified as the 39 document authors. All rights reserved. 41 This document is subject to BCP 78 and the IETF Trust's Legal 42 Provisions Relating to IETF Documents 43 (http://trustee.ietf.org/license-info) in effect on the date of 44 publication of this document. Please review these documents 45 carefully, as they describe your rights and restrictions with respect 46 to this document. Code Components extracted from this document must 47 include Simplified BSD License text as described in Section 4.e of 48 the Trust Legal Provisions and are provided without warranty as 49 described in the Simplified BSD License. 51 Table of Contents 53 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 54 1.1. Requirements Language . . . . . . . . . . . . . . . . . . 3 55 2. Common IPv6 deployment model . . . . . . . . . . . . . . . . 3 56 3. Benefits of providing multiple addresses . . . . . . . . . . 3 57 4. Problems with restricting the number of addresses per host . 4 58 5. Overcoming limits using Network Address Translation . . . . . 5 59 6. Options for providing more than one address . . . . . . . . . 6 60 7. Number of addresses required . . . . . . . . . . . . . . . . 7 61 8. Recommendations . . . . . . . . . . . . . . . . . . . . . . . 8 62 9. Operational considerations . . . . . . . . . . . . . . . . . 8 63 9.1. Host tracking . . . . . . . . . . . . . . . . . . . . . . 8 64 9.2. Address space management . . . . . . . . . . . . . . . . 9 65 9.3. Addressing link layer scalability issues via IP routing . 10 66 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 11 67 11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11 68 12. Security Considerations . . . . . . . . . . . . . . . . . . . 11 69 13. References . . . . . . . . . . . . . . . . . . . . . . . . . 11 70 13.1. Normative References . . . . . . . . . . . . . . . . . . 11 71 13.2. Informative References . . . . . . . . . . . . . . . . . 11 72 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 14 74 1. Introduction 76 In most aspects, the IPv6 protocol is very similar to IPv4. This 77 similarity can create a tendency to think of IPv6 as 128-bit IPv4, 78 and thus lead network designers and operators to apply identical 79 configurations and operational practices to both. This is generally 80 a good thing because it eases the transition to IPv6 and the 81 operation of dual-stack networks. However, in some design and 82 operational areas it can lead to carrying over IPv4 practices that 83 are limiting or not appropriate in IPv6 due to differences between 84 the protocols. 86 One such area is IP addressing, particularly IP addressing of hosts. 87 This is substantially different because unlike IPv4 addresses, IPv6 88 addresses are not a scarce resource. In IPv6, a single link provides 89 over four billion times more address space than the whole IPv4 90 Internet [RFC7421]. Thus, unlike IPv4, IPv6 networks are not forced 91 by address availability considerations to provide only one address 92 per host. On the other hand, providing multiple addresses has many 93 benefits including application functionality and simplicity, privacy, 94 flexibility to accommodate future applications, and the ability to 95 provide Internet access without the use of NAT. Providing only one 96 IPv6 address per host negates these benefits. 98 This document describes the benefits of providing multiple addresses 99 per host and the problems with not doing so. It recommends that 100 networks provide general-purpose end hosts with multiple global 101 addresses when they attach, and lists current options for doing so. 102 It does not specify any changes to protocols or host behavior. 104 1.1. Requirements Language 106 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 107 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 108 "OPTIONAL" in this document are to be interpreted as described in 109 "Key words for use in RFCs to Indicate Requirement Levels" [RFC2119]. 111 2. Common IPv6 deployment model 113 IPv6 is designed to support multiple addresses, including multiple 114 global addresses, per interface ([RFC4291] section 2.1, [RFC6434] 115 section 5.9.4). Today, many general-purpose IPv6 hosts are 116 configured with three or more addresses per interface: a link-local 117 address, a stable address (e.g., using EUI-64 or Opaque Interface 118 Identifiers [RFC7217]), one or more privacy addresses [RFC4941], and 119 possibly one or more temporary or non-temporary addresses obtained 120 using DHCPv6 [RFC3315]. 122 In most general-purpose IPv6 networks, including all 3GPP networks 123 ([RFC6459] section 5.2) and Ethernet and Wi-Fi networks using SLAAC 124 [RFC4862], IPv6 hosts have the ability to configure additional IPv6 125 addresses from the link prefix(es) without explicit requests to the 126 network. 128 3. Benefits of providing multiple addresses 130 Today, there are many host functions that require more than one IP 131 address to be available to the host, including: 133 o Privacy addressing to prevent tracking by off-network hosts 134 [RFC4941]. 136 o Multiple processors inside the same device. For example, in many 137 mobile devices both the application processor and baseband 138 processor need to communicate with the network, particularly for 139 technologies like I-WLAN [TS.24327] where the two processors share 140 the Wi-Fi network connection. 142 o Extending the network (e.g., "tethering"). 144 o Running virtual machines on hosts. 146 o Translation-based transition technologies such as 464XLAT 147 [RFC6877] that provide IPv4 over IPv6. Some of these technologies 148 require the availability of a dedicated IPv6 address in order to 149 determine whether inbound packets are translated or native 150 ([RFC6877] section 6.3). 152 o ILA ("Identifier-locator addressing") [I-D.herbert-nvo3-ila]. 154 o Future applications (e.g., per-application IPv6 addresses [TARP]). 156 Examples of how the availability of multiple addresses per host has 157 already allowed substantial deployment of new applications without 158 explicit requests to the network are: 160 o 464XLAT. 464XLAT is usually deployed within a particular network, 161 and in this model the operator can ensure that the network is 162 appropriately configured to provide the CLAT with the additional 163 IPv6 address it needs to implement 464XLAT. However, there are 164 deployments where the PLAT (i.e., NAT64) is provided as a service 165 by a different network, without the knowledge or cooperation of 166 the residential ISP (e.g., the IPv6v4 Exchange Service 167 ). This type of 168 deployment is only possible because those residential ISPs provide 169 multiple IP addresses to their users, and thus those users can 170 freely obtain the extra IPv6 address required to run 464XLAT. 172 o /64 sharing [RFC7278]. When the topology supports it, this is a 173 way to provide IPv6 tethering without needing to wait for network 174 operators to deploy DHCPv6 PD, which is only available in 3GPP 175 release 10 or above ([RFC6459] section 5.3). 177 4. Problems with restricting the number of addresses per host 179 Providing a restricted number of addresses per host implies that 180 functions that require multiple addresses will either be unavailable 181 (e.g., if the network provides only one IPv6 address per host, or if 182 the host has reached the limit of the number of addresses available), 183 or that the functions will only be available after an explicit 184 request to the network is granted. The necessity of explicit 185 requests has the following drawbacks: 187 o Increased latency, because a provisioning operation, and possibly 188 human intervention with an update to the service level agreement, 189 must complete before the functionality is available. 191 o Uncertainty, because it is not known if a particular operation 192 function will be available until the provisioning operation 193 succeeds or fails. 195 o Complexity, because implementations need to deal with failures and 196 somehow present them to the user. Failures may manifest as 197 timeouts, which may be slow and frustrating to users. 199 o Increased load on the network's provisioning servers. 201 Some operators may desire to configure their networks to limit the 202 number of IPv6 addresses per host. Reasons might include hardware 203 limitations (e.g., TCAM or neighbor cache table size constraints), 204 business models (e.g., a desire to charge the network's users on a 205 per-device basis), or operational consistency with IPv4 (e.g., an IP 206 address management system that only supports one address per host). 207 However, hardware limitations are expected to ease over time, and an 208 attempt to generate additional revenue by charging per device may 209 prove counterproductive if customers respond (as they did with IPv4) 210 by using NAT, which results in no additional revenue, but leads to 211 more operational problems and higher support costs. 213 5. Overcoming limits using Network Address Translation 215 These limits can mostly be overcome by end hosts by using NAT, and 216 indeed in IPv4 most of these functions are provided by using NAT on 217 the host. Thus, the limits could be overcome in IPv6 as well by 218 implementing NAT66 on the host. 220 Unfortunately NAT has well-known drawbacks. For example, it causes 221 application complexity due to the need to implement NAT traversal. 222 It hinders development of new applications. On mobile devices, it 223 reduces battery life due to the necessity of frequent keepalives, 224 particularly for UDP. Applications using UDP that need to work on 225 most of the Internet are forced to send keepalives at least every 30 226 seconds . For example, the QUIC protocol uses a 15-second keepalive 228 [I-D.tsvwg-quic-protocol]. Other drawbacks of NAT are well known and 229 documented [RFC2993]. While IPv4 NAT is inevitable due to the 230 limited amount of IPv4 space available, that argument does not apply 231 to IPv6. Guidance from the IAB is that deployment of IPv6 NAT is not 232 desirable [RFC5902]. 234 The desire to overcome the problems listed in Section 4 without 235 disabling any features has resulted in developers implementing IPv6 236 NAT. There are fully-stateful address+port NAT66 implementations in 237 client operating systems today: for example, Linux has supported 238 NAT66 since late 2012 . A popular software 240 hypervisor also recently implemented NAT66 to work around these 241 issues . Wide 242 deployment of networks that provide a restricted number of addresses 243 will cause proliferation of NAT66 implementations. 245 This is not a desirable outcome. It is not desirable for users 246 because they may experience application brittleness. It is likely 247 not desirable for network operators either, as they may suffer higher 248 support costs, and even when the decision to provide only one IPv6 249 address per device is dictated by the network's business model, there 250 may be little in the way of incremental revenue, because devices can 251 share their IPv6 address with other devices. Finally, it is not 252 desirable for operating system manufacturers and application 253 developers, who will have to build more complexity, lengthening 254 development time and/or reducing the time spent on other features. 256 Indeed, it could be argued that the main reason for deploying IPv6, 257 instead of continuing to scale the Internet using only IPv4 and 258 large-scale NAT44, is because doing so can provide all the hosts on 259 the planet with end-to-end connectivity that is constrained not by 260 accidental technical limitations, but only by intentional security 261 policies. 263 6. Options for providing more than one address 265 Multiple IPv6 addresses can be provided in the following ways: 267 o Using Stateless Address Autoconfiguration [RFC4862]. SLAAC allows 268 hosts to create global IPv6 addresses on demand by simply forming 269 new addresses from the global prefix(es) assigned to the link. 270 Typically, SLAAC is used on shared links, but it is also possible 271 to use SLAAC while providing a dedicated /64 prefix to each host. 272 This is the case, for example, if the host is connected via a 273 point-to-point link such as in 3GPP networks, on a network where 274 each host has its own dedicated VLAN, or on a wireless network 275 where every MAC address is placed in its own broadcast domain. 277 o Using stateful DHCPv6 address assignment [RFC3315]. Most DHCPv6 278 clients only ask for one non-temporary address, but the protocol 279 allows requesting multiple temporary and even multiple non- 280 temporary addresses, and the server could choose to provide 281 multiple addresses. It is also technically possible for a client 282 to request additional addresses using a different DUID, though the 283 DHCPv6 specification implies that this is not expected behavior 284 ([RFC3315] section 9). The DHCPv6 server will decide whether to 285 grant or reject the request based on information about the client, 286 including its DUID, MAC address, and so on. The maximum number of 287 IPv6 addresses that can be provided in a single DHCPv6 packet, 288 given a typical MTU of 1500 bytes or smaller, is approximately 30. 290 o DHCPv6 prefix delegation [RFC3633]. DHCPv6 PD allows the client 291 to request and be delegated a prefix, from which it can 292 autonomously form other addresses. If the prefix is shorter than 293 /64, it can be divided into multiple subnets which can be further 294 delegated to downstream clients. If the prefix is a /64, it can 295 be extended via L2 bridging, ND proxying [RFC4389] or /64 sharing 296 [RFC7278], but it cannot be further subdivided, as a prefix longer 297 than /64 is outside the current IPv6 specifications [RFC7421]. 298 While [RFC3633] assumes that the DHCPv6 client is a router, DHCPv6 299 PD itself does not require that the client forward IPv6 packets 300 not addressed to itself, and thus does not require that the client 301 be an IPv6 router as defined in [RFC2460]. Also, in many cases 302 (such as tethering, or hosting virtual machines), hosts are 303 already forwarding IPv6 packets and thus operating as IPv6 routers 304 as defined in [RFC2460]. 306 +--------------------------+-------+-------------+--------+---------+ 307 | | SLAAC | DHCPv6 | DHCPv6 | DHCPv4 | 308 | | | IA_NA / | PD | | 309 | | | IA_TA | | | 310 +--------------------------+-------+-------------+--------+---------+ 311 | Can extend network | No+ | No | Yes | Yes | 312 | | | | | (NAT44) | 313 | Can number "unlimited" | Yes* | Yes* | No | No | 314 | endpoints | | | | | 315 | Uses stateful, request- | No | Yes | Yes | Yes | 316 | based assignment | | | | | 317 | Is immune to layer 3 on- | No | Yes | Yes | Yes | 318 | link resource exhaustion | | | | | 319 | attacks | | | | | 320 +--------------------------+-------+-------------+--------+---------+ 322 [*] Subject to network limitations, e.g., ND cache entry size limits. 323 [+] Except on certain networks, e.g., [RFC7278]. 325 Table 1: Comparison of multiple address assignment options 327 7. Number of addresses required 329 If we itemize the use cases from section Section 3, we can estimate 330 the number of addresses currently used in normal operations. In 331 typical implementations, privacy addresses use up to 8 addresses - 332 one per day ([RFC4941] section 3.5). Current mobile devices may 333 typically support 8 clients, with each one requiring one or more 334 addresses. A client might choose to run several virtual machines. 336 Current implementations of 464XLAT require use of a separate address. 337 Some devices require another address for their baseband chip. Even a 338 host performing just a few of these functions simultaneously might 339 need on the order of 20 addresses at the same time. Future 340 applications designed to use an address per application or even per 341 resource will require many more. These will not function on networks 342 that enforce a hard limit on the number of addresses provided to 343 hosts. Thus, in general is is not possible to estimate in advance 344 how many addresses are required. 346 8. Recommendations 348 In order to avoid the problems described above, and preserve the 349 Internet's ability to support new applications that use more than one 350 IPv6 address, it is RECOMMENDED that IPv6 network deployments provide 351 multiple IPv6 addresses from each prefix to general-purpose hosts. 352 To support future use cases, it is NOT RECOMMENDED to impose a hard 353 limit on the size of the address pool assigned to a host. 354 Particularly, it is NOT RECOMMENDED to limit a host to only one IPv6 355 address per prefix. 357 Due to the drawbacks imposed by requiring explicit requests for 358 address space (see section Section 4), it is RECOMMENDED that the 359 network give the host the ability to use new addresses without 360 requiring explicit requests. This can be achieved either by allowing 361 the host to form new addresses autonomously (e.g., via SLAAC), or by 362 providing the host with a dedicated /64 prefix. The prefix MAY be 363 provided using DHCPv6 PD, SLAAC with per-device VLANs, or any other 364 means. 366 Using stateful address assignment (DHCPv6 IA_NA or IA_TA) to provide 367 multiple addresses when the host connects (e.g. the approximately 30 368 addresses that can fit into a single packet) would accommodate 369 current clients, but sets a limit on the number of addresses 370 available to hosts when they attach and would limit the development 371 of future applications. 373 9. Operational considerations 375 9.1. Host tracking 377 Some network operators - often operators of networks that provide 378 services to third parties such as university campus networks - are 379 required to track which IP addresses are assigned to which hosts on 380 their network. Maintaining persistent logs that map user IP 381 addresses and timestamps to hardware identifiers such as MAC 382 addresses may be used to attribute liability for copyright 383 infringement or other illegal activity. 385 It is worth noting that this requirement can be met without using 386 DHCPv6 address assignment. For example, it is possible to maintain 387 these mappings by monitoring IPv6 neighbor table: routers typically 388 allow periodic dumps of the neighbor cache via SNMP or other means, 389 and many can be configured to log every change to the neighbor cache. 390 Using SLAAC with a dedicated /64 prefix simplifies tracking, as it 391 does not require logging each address formed by the host, but only 392 the prefix assigned to the host when it attaches to the network. 393 Similarly, providing address space using DHCPv6 PD has the same 394 tracking properties as DHCPv6 address assignment, but allows the 395 network to provide unrestricted address space. 397 Many large enterprise networks are fully dual-stack and implement 398 address monitoring without using or supporting DHCPv6. The authors 399 are directly aware of several networks that operate in this way, 400 including the Universities of Loughborough, Minnesota, Reading, 401 Southampton, Wisconsin and Imperial College London, in addition to 402 the enterprise networks of the authors' employers. 404 It should also be noted that using DHCPv6 address assignment does not 405 ensure that the network can reliably track the IPv6 addresses used by 406 hosts. On any shared network without L2 edge port security, hosts 407 are able to choose their own addresses regardless of what address 408 provisioning methodology is in use. The only way to restrict the 409 addresses used by hosts is to use layer 2 security mechanisms that 410 enforce that particular IPv6 addresses are used by particular link- 411 layer addresses (for example, SAVI [RFC7039]). If those mechanisms 412 are available, it is possible to use them to provide tracking; this 413 form of tracking is more secure and reliable than server logs because 414 it operates independently of how addresses are allocated. Finally, 415 tracking address information via DHCPv6 server logs is likely to 416 become decreasingly viable due to ongoing efforts to improve the 417 privacy of DHCPv6 and MAC address randomization [RFC7844]. 419 9.2. Address space management 421 In IPv4, all but the world's largest networks can be addressed using 422 private space [RFC1918], with each host receiving one IPv4 address. 423 Many networks can be numbered in 192.168.0.0/16 which has roughly 64k 424 addresses. In IPv6, that is equivalent to a /48, with each of 64k 425 hosts receiving a /64 prefix. Under current RIR policies, a /48 is 426 easy to obtain for an enterprise network. Networks that need a 427 bigger block of private space use 10.0.0.0/8, which has roughly 16 428 million addresses. In IPv6, that is equivalent to a /40, with each 429 host receiving /64 prefix. Enterprises of such size can easily 430 obtain a /40 under current RIR policies. 432 In the above cases, aggregation and routing can be equivalent to 433 IPv4: if a network aggregates per-host IPv4 addresses into prefixes 434 of length /32 - n, it can aggregate per-host /64 prefixes into the 435 same number of prefixes of length /64 - n. 437 Currently, residential users typically receive one IPv4 address and a 438 /48, /56 or /60 IPv6 prefix. While such networks do not provide 439 enough space to assign a /64 per host, such networks almost 440 universally use SLAAC, and thus do not pose any particular limit to 441 the number of addresses hosts can use. 443 Unlike IPv4 where addresses came at a premium, in all these networks, 444 there is enough IPv6 address space to supply clients with multiple 445 IPv6 addresses. 447 9.3. Addressing link layer scalability issues via IP routing 449 The number of IPv6 addresses on a link has direct impact for 450 networking infrastructure nodes (routers, switches) and other nodes 451 on the link. Setting aside exhaustion attacks via Layer 2 address 452 spoofing, every (Layer 2, IP) address pair impacts networking 453 hardware requirements in terms of memory, MLD snooping, solicited 454 node multicast groups, etc. Many of these costs are incurred by 455 neighboring hosts. 457 Hosts on such networks that create unreasonable numbers of addresses 458 risk impairing network connectivity for themselves and other hosts on 459 the network, and in extreme cases (e.g., hundreds or thousands of 460 addresses) may even find their network access restricted by denial- 461 of-service protection mechanisms. 463 We expect these scaling limitations to change over time as hardware 464 and applications evolve. However, switching to a dedicated /64 465 prefix per host can resolve these scaling limitations. If the prefix 466 is provided via DHCPv6 PD, or if the prefix can be used by only one 467 link-layer address (e.g., if the link layer uniquely identifies or 468 authenticates hosts based on MAC addresses), then there will be only 469 one routing entry and one ND cache entry per host on the network. 470 Furthermore, if the host is aware that the prefix is dedicated (e.g., 471 if it was provided via DHCPv6 PD and not SLAAC), it is possible for 472 the host to assign IPv6 addresses from this prefix to an internal 473 interface such as a loopback interface. This obviates the need to 474 perform Neighbor Discovery and Duplicate Address Detection on the 475 network interface for these addresses, reducing network traffic. 477 Thus, assigning a dedicated /64 prefix per host is operationally 478 prudent. Clearly, however, it requires more IPv6 address space than 479 using shared links, so the benefits provided must be weighed with the 480 operational overhead of address space management. 482 10. Acknowledgements 484 The authors thank Tore Anderson, Brian Carpenter, David Farmer, 485 Wesley George, Geoff Huston, Erik Kline, Victor Kuarsingh, Shucheng 486 (Will) Liu, Dieter Siegmund, Mark Smith, Sander Steffann, Fred 487 Templin and James Woodyatt for their input and contributions. 489 11. IANA Considerations 491 This memo includes no request to IANA. 493 12. Security Considerations 495 As mentioned in section 9.3, on shared networks using SLAAC it is 496 possible for hosts to attempt to exhaust network resources and 497 possibly deny service to other hosts by creating unreasonable numbers 498 (e.g., hundreds or thousands) of addresses. Networks that provide 499 access to untrusted hosts can mitigate this threat by providing a 500 dedicated /64 prefix per host. It is also possible to mitigate the 501 threat by limiting the number of ND cache entries that can be created 502 for a particular host, but care must be taken to ensure that the 503 network does not restrict the IP addresses available to non-malicious 504 hosts. 506 Security issues related to host tracking are discussed in section 507 9.1. 509 13. References 511 13.1. Normative References 513 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 514 Requirement Levels", BCP 14, RFC 2119, 515 DOI 10.17487/RFC2119, March 1997, 516 . 518 13.2. Informative References 520 [I-D.herbert-nvo3-ila] 521 Herbert, T., "Identifier-locator addressing for network 522 virtualization", draft-herbert-nvo3-ila-02 (work in 523 progress), March 2016. 525 [I-D.tsvwg-quic-protocol] 526 Hamilton, R., Iyengar, J., Swett, I., and A. Wilk, "QUIC: 527 A UDP-Based Secure and Reliable Transport for HTTP/2", 528 draft-tsvwg-quic-protocol-02 (work in progress), January 529 2016. 531 [RFC1918] Rekhter, Y., Moskowitz, B., Karrenberg, D., de Groot, G., 532 and E. Lear, "Address Allocation for Private Internets", 533 BCP 5, RFC 1918, DOI 10.17487/RFC1918, February 1996, 534 . 536 [RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6 537 (IPv6) Specification", RFC 2460, DOI 10.17487/RFC2460, 538 December 1998, . 540 [RFC2993] Hain, T., "Architectural Implications of NAT", RFC 2993, 541 DOI 10.17487/RFC2993, November 2000, 542 . 544 [RFC3315] Droms, R., Ed., Bound, J., Volz, B., Lemon, T., Perkins, 545 C., and M. Carney, "Dynamic Host Configuration Protocol 546 for IPv6 (DHCPv6)", RFC 3315, DOI 10.17487/RFC3315, July 547 2003, . 549 [RFC3633] Troan, O. and R. Droms, "IPv6 Prefix Options for Dynamic 550 Host Configuration Protocol (DHCP) version 6", RFC 3633, 551 DOI 10.17487/RFC3633, December 2003, 552 . 554 [RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing 555 Architecture", RFC 4291, DOI 10.17487/RFC4291, February 556 2006, . 558 [RFC4389] Thaler, D., Talwar, M., and C. Patel, "Neighbor Discovery 559 Proxies (ND Proxy)", RFC 4389, DOI 10.17487/RFC4389, April 560 2006, . 562 [RFC4862] Thomson, S., Narten, T., and T. Jinmei, "IPv6 Stateless 563 Address Autoconfiguration", RFC 4862, 564 DOI 10.17487/RFC4862, September 2007, 565 . 567 [RFC4941] Narten, T., Draves, R., and S. Krishnan, "Privacy 568 Extensions for Stateless Address Autoconfiguration in 569 IPv6", RFC 4941, DOI 10.17487/RFC4941, September 2007, 570 . 572 [RFC5902] Thaler, D., Zhang, L., and G. Lebovitz, "IAB Thoughts on 573 IPv6 Network Address Translation", RFC 5902, 574 DOI 10.17487/RFC5902, July 2010, 575 . 577 [RFC6434] Jankiewicz, E., Loughney, J., and T. Narten, "IPv6 Node 578 Requirements", RFC 6434, DOI 10.17487/RFC6434, December 579 2011, . 581 [RFC6459] Korhonen, J., Ed., Soininen, J., Patil, B., Savolainen, 582 T., Bajko, G., and K. Iisakkila, "IPv6 in 3rd Generation 583 Partnership Project (3GPP) Evolved Packet System (EPS)", 584 RFC 6459, DOI 10.17487/RFC6459, January 2012, 585 . 587 [RFC6877] Mawatari, M., Kawashima, M., and C. Byrne, "464XLAT: 588 Combination of Stateful and Stateless Translation", 589 RFC 6877, DOI 10.17487/RFC6877, April 2013, 590 . 592 [RFC7039] Wu, J., Bi, J., Bagnulo, M., Baker, F., and C. Vogt, Ed., 593 "Source Address Validation Improvement (SAVI) Framework", 594 RFC 7039, DOI 10.17487/RFC7039, October 2013, 595 . 597 [RFC7217] Gont, F., "A Method for Generating Semantically Opaque 598 Interface Identifiers with IPv6 Stateless Address 599 Autoconfiguration (SLAAC)", RFC 7217, 600 DOI 10.17487/RFC7217, April 2014, 601 . 603 [RFC7278] Byrne, C., Drown, D., and A. Vizdal, "Extending an IPv6 604 /64 Prefix from a Third Generation Partnership Project 605 (3GPP) Mobile Interface to a LAN Link", RFC 7278, 606 DOI 10.17487/RFC7278, June 2014, 607 . 609 [RFC7421] Carpenter, B., Ed., Chown, T., Gont, F., Jiang, S., 610 Petrescu, A., and A. Yourtchenko, "Analysis of the 64-bit 611 Boundary in IPv6 Addressing", RFC 7421, 612 DOI 10.17487/RFC7421, January 2015, 613 . 615 [RFC7844] Huitema, C., Mrugalski, T., and S. Krishnan, "Anonymity 616 Profiles for DHCP Clients", RFC 7844, 617 DOI 10.17487/RFC7844, May 2016, 618 . 620 [TARP] Gleitz, PM. and SM. Bellovin, "Transient Addressing for 621 Related Processes: Improved Firewalling by Using IPv6 and 622 Multiple Addresses per Host", August 2001. 624 [TS.24327] 625 3GPP, "Mobility between 3GPP Wireless Local Area Network 626 (WLAN) interworking (I-WLAN) and 3GPP systems; General 627 Packet Radio System (GPRS) and 3GPP I-WLAN aspects; Stage 628 3", June 2011. 630 Authors' Addresses 632 Lorenzo Colitti 633 Google 634 Roppongi 6-10-1 635 Minato, Tokyo 106-6126 636 JP 638 Email: lorenzo@google.com 640 Vint Cerf 641 Google 642 1875 Explorer St 643 10th Floor 644 Reston, VA 20190 645 US 647 Email: vint@google.com 649 Stuart Cheshire 650 Apple Inc. 651 1 Infinite Loop 652 Cupertino, CA 95014 653 US 655 Email: cheshire@apple.com 657 David Schinazi 658 Apple Inc. 659 1 Infinite Loop 660 Cupertino, CA 95014 661 US 663 Email: dschinazi@apple.com