diff options
Diffstat (limited to 'doc/rfc/rfc7934.txt')
| -rw-r--r-- | doc/rfc/rfc7934.txt | 843 |
1 files changed, 843 insertions, 0 deletions
diff --git a/doc/rfc/rfc7934.txt b/doc/rfc/rfc7934.txt new file mode 100644 index 0000000..de714c1 --- /dev/null +++ b/doc/rfc/rfc7934.txt @@ -0,0 +1,843 @@ + + + + + + +Internet Engineering Task Force (IETF) L. Colitti +Request for Comments: 7934 V. Cerf +BCP: 204 Google +Category: Best Current Practice S. Cheshire +ISSN: 2070-1721 D. Schinazi + Apple Inc. + July 2016 + + + Host Address Availability Recommendations + +Abstract + + This document recommends that networks provide general-purpose end + hosts with multiple global IPv6 addresses when they attach, and it + describes the benefits of and the options for doing so. + +Status of This Memo + + This memo documents an Internet Best Current Practice. + + This document is a product of the Internet Engineering Task Force + (IETF). It represents the consensus of the IETF community. It has + received public review and has been approved for publication by the + Internet Engineering Steering Group (IESG). Further information on + BCPs is available in Section 2 of RFC 7841. + + Information about the current status of this document, any errata, + and how to provide feedback on it may be obtained at + http://www.rfc-editor.org/info/rfc7934. + +Copyright Notice + + Copyright (c) 2016 IETF Trust and the persons identified as the + document authors. All rights reserved. + + This document is subject to BCP 78 and the IETF Trust's Legal + Provisions Relating to IETF Documents + (http://trustee.ietf.org/license-info) in effect on the date of + publication of this document. Please review these documents + carefully, as they describe your rights and restrictions with respect + to this document. Code Components extracted from this document must + include Simplified BSD License text as described in Section 4.e of + the Trust Legal Provisions and are provided without warranty as + described in the Simplified BSD License. + + + + + + +Colitti, et al. Best Current Practice [Page 1] + +RFC 7934 Host Address Availability Recommendations July 2016 + + +Table of Contents + + 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 + 1.1. Requirements Language . . . . . . . . . . . . . . . . . . 3 + 2. Common IPv6 Deployment Model . . . . . . . . . . . . . . . . 3 + 3. Benefits of Providing Multiple Addresses . . . . . . . . . . 3 + 4. Problems with Restricting the Number of Addresses per Host . 4 + 5. Overcoming Limits Using Network Address Translation . . . . . 5 + 6. Options for Providing More Than One Address . . . . . . . . . 6 + 7. Number of Addresses Required . . . . . . . . . . . . . . . . 8 + 8. Recommendations . . . . . . . . . . . . . . . . . . . . . . . 8 + 9. Operational Considerations . . . . . . . . . . . . . . . . . 9 + 9.1. Host Tracking . . . . . . . . . . . . . . . . . . . . . . 9 + 9.2. Address Space Management . . . . . . . . . . . . . . . . 10 + 9.3. Addressing Link-Layer Scalability Issues via IP Routing . 10 + 10. Security Considerations . . . . . . . . . . . . . . . . . . . 11 + 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 11 + 11.1. Normative References . . . . . . . . . . . . . . . . . . 11 + 11.2. Informative References . . . . . . . . . . . . . . . . . 11 + Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 14 + Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 15 + +1. Introduction + + In most aspects, the IPv6 protocol is very similar to IPv4. This + similarity can create a tendency to think of IPv6 as 128-bit IPv4, + and thus lead network designers and operators to apply identical + configurations and operational practices to both. This is generally + a good thing because it eases the transition to IPv6 and the + operation of dual-stack networks. However, in some design and + operational areas, it can lead to carrying over IPv4 practices that + are limiting or not appropriate in IPv6 due to differences between + the protocols. + + One such area is IP addressing, particularly IP addressing of hosts. + This is substantially different because unlike IPv4 addresses, IPv6 + addresses are not a scarce resource. In IPv6, a single link provides + over four billion times more address space than the whole IPv4 + Internet [RFC7421]. Thus, unlike IPv4, IPv6 networks are not forced + by address scarcity concerns to provide only one address per host. + Furthermore, providing multiple addresses has many benefits, + including application functionality and simplicity, privacy, and + flexibility to accommodate future applications. Another significant + benefit is the ability to provide Internet access without the use of + Network Address Translation (NAT). Providing only one IPv6 address + per host negates these benefits. + + + + + +Colitti, et al. Best Current Practice [Page 2] + +RFC 7934 Host Address Availability Recommendations July 2016 + + + This document details the benefits of providing multiple addresses + per host, and the problems with not doing so. It recommends that + networks provide general-purpose end hosts with multiple global + addresses when they attach and lists current options for doing so. + It does not specify any changes to protocols or host behavior. + +1.1. Requirements Language + + The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", + "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and + "OPTIONAL" in this document are to be interpreted as described in + "Key words for use in RFCs to Indicate Requirement Levels" [RFC2119]. + +2. Common IPv6 Deployment Model + + IPv6 is designed to support multiple addresses, including multiple + global addresses, per interface (see Section 2.1 of [RFC4291] and + Section 5.9.4 of [RFC6434]). Today, many general-purpose IPv6 hosts + are configured with three or more addresses per interface: a link- + local address, a stable address (e.g., using 64-bit Extended Unique + Identifiers (EUI-64) or Opaque Interface Identifiers [RFC7217]), one + or more privacy addresses [RFC4941], and possibly one or more + temporary or non-temporary addresses obtained using the Dynamic Host + Configuration Protocol for IPv6 (DHCPv6) [RFC3315]. + + In most general-purpose IPv6 networks, hosts have the ability to + configure additional IPv6 addresses from the link prefix(es) without + explicit requests to the network. Such networks include all 3GPP + networks ([RFC6459], Section 5.2), in addition to Ethernet and Wi-Fi + networks using Stateless Address Autoconfiguration (SLAAC) [RFC4862]. + +3. Benefits of Providing Multiple Addresses + + Today, there are many host functions that require more than one IP + address to be available to the host, including: + + o Privacy addressing to prevent tracking by off-network hosts + [RFC4941]. + + o Multiple processors inside the same device. For example, in many + mobile devices, both the application processor and the baseband + processor need to communicate with the network, particularly for + technologies like I-WLAN [TS.24327] where the two processors share + the Wi-Fi network connection. + + o Extending the network (e.g., "tethering"). + + o Running virtual machines on hosts. + + + +Colitti, et al. Best Current Practice [Page 3] + +RFC 7934 Host Address Availability Recommendations July 2016 + + + o Translation-based transition technologies such as 464XLAT (a + combination of stateful and stateless translation) [RFC6877] that + translate between IPv4 and IPv6. Some of these technologies + require the availability of a dedicated IPv6 address in order to + determine whether inbound packets are translated or native + ([RFC6877], Section 6.3). + + o Identifier-locator addressing (ILA) [ILA]. + + o Future applications (e.g., per-application IPv6 addresses [TARP]). + + Two examples of how the availability of multiple addresses per host + has already allowed substantial deployment of new applications + without explicit requests to the network are: + + o 464XLAT. 464XLAT is usually deployed within a particular network; + in this model, the operator can ensure that the network is + appropriately configured to provide the customer-side translator + (CLAT) with the additional IPv6 address it needs to implement + 464XLAT. However, there are deployments where the provider-side + translator (PLAT) (i.e., NAT64) is provided as a service by a + different network, without the knowledge or cooperation of the + residential ISP (e.g., the IPv6v4 Exchange Service [IPv6v4]). + This type of deployment is only possible because those residential + ISPs provide multiple IP addresses to their users, and thus those + users can freely obtain the extra IPv6 address required to run + 464XLAT. + + o /64 sharing [RFC7278]. When the topology supports it, this is a + way to provide IPv6 tethering without needing to wait for network + operators to deploy DHCPv6 Prefix Delegation (PD), which is only + available in 3GPP release 10 or above ([RFC6459], Section 5.3). + +4. Problems with Restricting the Number of Addresses per Host + + Providing a restricted number of addresses per host implies that + functions that require multiple addresses either will be unavailable + (e.g., if the network provides only one IPv6 address per host, or if + the host has reached the limit of the number of addresses available) + or will only be available after an explicit request to the network is + granted. Requiring explicit requests to the network has the + following drawbacks: + + o Increased latency, because a provisioning operation, and possibly + human intervention with an update to the Service Level Agreement + (SLA), must complete before the functionality is available. + + + + + +Colitti, et al. Best Current Practice [Page 4] + +RFC 7934 Host Address Availability Recommendations July 2016 + + + o Uncertainty, because it is not known if a particular application + function will be available until the provisioning operation + succeeds or fails. + + o Complexity, because implementations need to deal with failures and + somehow present them to the user. Failures may manifest as + timeouts, which may be slow and frustrating to users. + + o Increased load on the network's provisioning servers. + + Some operators may desire that their networks be configured to limit + the number of IPv6 addresses per host. Reasons might include + hardware limitations (e.g., Ternary Content-Addressable Memory (TCAM) + size or size constraints of the Neighbor Cache table), business + models (e.g., a desire to charge the network's users on a per-device + basis), or operational consistency with IPv4 (e.g., an IP address + management system that only supports one address per host). However, + hardware limitations are expected to ease over time, and an attempt + to generate additional revenue by charging per device may prove + counterproductive if customers respond (as they did with IPv4) by + using NAT, which results in no additional revenue, but leads to more + operational problems and higher support costs. + +5. Overcoming Limits Using Network Address Translation + + When the network limits the number of addresses available to a host, + this can mostly be overcome by end hosts by using NAT, and indeed in + IPv4 the scarcity of addresses is often mitigated by using NAT on the + host. Thus, the limits could be overcome in IPv6 as well by + implementing NAT66 on the host. + + Unfortunately, NAT has well-known drawbacks. For example, it causes + application complexity due to the need to implement NAT traversal. + It hinders development of new applications. On mobile devices, it + reduces battery life due to the necessity of frequent keepalives, + particularly for UDP. Applications using UDP that need to work on + most of the Internet are forced to send keepalives at least every 30 + seconds [KA]. For example, the QUIC protocol uses a 15-second + keepalive [QUIC]. Other drawbacks of NAT are well-known and + documented [RFC2993]. While IPv4 NAT is inevitable due to the + limited amount of IPv4 space available, that argument does not apply + to IPv6. Guidance from the Internet Architecture Board (IAB) is that + deployment of IPv6 NAT is not desirable [RFC5902]. + + The desire to overcome the problems listed in Section 4 without + disabling any features has resulted in developers implementing IPv6 + NAT. There are fully stateful address+port NAT66 implementations in + client operating systems today: for example, Linux has supported + + + +Colitti, et al. Best Current Practice [Page 5] + +RFC 7934 Host Address Availability Recommendations July 2016 + + + NAT66 since 2012 [L66]. At least one popular software hypervisor + also implemented NAT66 to work around these issues [V66]. Wide + deployment of networks that provide a restricted number of addresses + will cause proliferation of NAT66 implementations. + + This is not a desirable outcome. It is not desirable for users + because they may experience application brittleness. It is likely + not desirable for network operators either, as they may suffer higher + support costs, and even when the decision to provide only one IPv6 + address per device is dictated by the network's business model, there + may be little in the way of incremental revenue, because devices can + share their IPv6 address with other devices. Finally, it is not + desirable for operating system manufacturers and application + developers, who will have to build more complexity, lengthening + development time and/or reducing the time spent on other features. + + Indeed, it could be argued that the main reason for deploying IPv6, + instead of continuing to scale the Internet using only IPv4 and + large-scale NAT44, is because doing so can provide all the hosts on + the planet with end-to-end connectivity that is constrained not by + accidental technical limitations, but only by intentional security + policies. + +6. Options for Providing More Than One Address + + Multiple IPv6 addresses can be provided in the following ways: + + o Using Stateless Address Autoconfiguration (SLAAC) [RFC4862]. + SLAAC allows hosts to create global IPv6 addresses on demand by + simply forming new addresses from the global prefix(es) assigned + to the link. Typically, SLAAC is used on shared links, but it is + also possible to use SLAAC while providing a dedicated /64 prefix + to each host. This is the case, for example, if the host is + connected via a point-to-point link such as in 3GPP networks, on a + network where each host has its own dedicated VLAN, or on a + wireless network where every Media Access Control (MAC) address is + placed in its own broadcast domain. + + o Using stateful DHCPv6 address assignment [RFC3315]. Most DHCPv6 + clients only ask for one non-temporary address, but the protocol + allows requesting multiple temporary and even multiple non- + temporary addresses, and the server could choose to provide + multiple addresses. It is also technically possible for a client + to request additional addresses using a different DHCP Unique + Identifier (DUID), though the DHCPv6 specification implies that + this is not expected behavior ([RFC3315], Section 9). The DHCPv6 + server will decide whether to grant or reject the request based on + information about the client, including its DUID, MAC address, and + + + +Colitti, et al. Best Current Practice [Page 6] + +RFC 7934 Host Address Availability Recommendations July 2016 + + + more. The maximum number of IPv6 addresses that can be provided + in a single DHCPv6 packet, given a typical MTU of 1500 bytes or + smaller, is approximately 30. + + o DHCPv6 Prefix Delegation (PD) [RFC3633]. DHCPv6 PD allows the + client to request and be delegated a prefix, from which it can + autonomously form other addresses. If the prefix is shorter than + /64, it can be divided into multiple subnets that can be further + delegated to downstream clients. If the prefix is a /64, it can + be extended via L2 bridging, Neighbor Discovery (ND) proxying + [RFC4389], or /64 sharing [RFC7278], but it cannot be further + subdivided, as a prefix longer than /64 is outside the current + IPv6 specifications [RFC7421]. While the DHCPv6 Prefix Delegation + specification [RFC3633] assumes that the DHCPv6 client is a + router, DHCPv6 PD itself does not require that the client forward + IPv6 packets not addressed to itself, and thus does not require + that the client be an IPv6 router as defined in the IPv6 + specification [RFC2460]. Also, in many cases (such as tethering, + or hosting virtual machines), hosts are already forwarding IPv6 + packets and thus operating as IPv6 routers as defined in the IPv6 + specification [RFC2460]. + + +--------------------------+-------+-------------+--------+---------+ + | | SLAAC | DHCPv6 | DHCPv6 | DHCPv4 | + | | | IA_NA / | PD | | + | | | IA_TA | | | + +--------------------------+-------+-------------+--------+---------+ + | Can extend network | No+ | No | Yes | Yes | + | | | | | (NAT44) | + | Can number "unlimited" | Yes* | Yes* | No | No | + | endpoints | | | | | + | Uses stateful, request- | No | Yes | Yes | Yes | + | based assignment | | | | | + | Is immune to Layer 3 on- | No | Yes | Yes | Yes | + | link resource exhaustion | | | | | + | attacks | | | | | + +--------------------------+-------+-------------+--------+---------+ + + [*] Subject to network limitations, e.g., ND cache entry size limits. + [+] Except on certain networks, e.g., /64 sharing [RFC7278]. + + Table 1: Comparison of Multiple Address Assignment Options + + + + + + + + + +Colitti, et al. Best Current Practice [Page 7] + +RFC 7934 Host Address Availability Recommendations July 2016 + + +7. Number of Addresses Required + + If we itemize the use cases from Section 3, we can estimate the + number of addresses currently used in normal operations. In typical + implementations, privacy addresses use up to 7 addresses -- one per + day ([RFC4941], Section 3.5). Current mobile devices sharing an + uplink connection may typically support 8 downstream client devices, + with each one requiring one or more addresses. A client might choose + to run several virtual machines. Current implementations of 464XLAT + require the use of a separate address. Some devices require another + address for their baseband chip. Even a host performing just a few + of these functions simultaneously might need on the order of 20 + addresses at the same time. Future applications designed to use an + address per application or even per resource will require many more. + These will not function on networks that enforce a hard limit on the + number of addresses provided to hosts. Thus, in general it is not + possible to estimate in advance how many addresses are required. + +8. Recommendations + + In order to avoid the problems described above and preserve the + Internet's ability to support new applications that use more than one + IPv6 address, it is RECOMMENDED that IPv6 network deployments provide + multiple IPv6 addresses from each prefix to general-purpose hosts. + To support future use cases, it is NOT RECOMMENDED to impose a hard + limit on the size of the address pool assigned to a host. + Particularly, it is NOT RECOMMENDED to limit a host to only one IPv6 + address per prefix. + + Due to the drawbacks imposed by requiring explicit requests for + address space (see Section 4), it is RECOMMENDED that the network + give the host the ability to use new addresses without requiring + explicit requests. This can be achieved either by allowing the host + to form new addresses autonomously (e.g., via SLAAC) or by providing + the host with a dedicated /64 prefix. The prefix MAY be provided + using DHCPv6 PD, SLAAC with per-device VLANs, or any other means. + + Using stateful address assignment (DHCPv6 IA_NA or IA_TA) to provide + multiple addresses when the host connects (e.g., the approximately 30 + addresses that can fit into a single packet) would accommodate + current clients, but it sets a limit on the number of addresses + available to hosts when they attach and therefore limits the + development of future applications. + + + + + + + + +Colitti, et al. Best Current Practice [Page 8] + +RFC 7934 Host Address Availability Recommendations July 2016 + + +9. Operational Considerations + +9.1. Host Tracking + + Some network operators -- often operators of networks that provide + services to third parties such as university campus networks -- are + required to track which IP addresses are assigned to which hosts on + their network. Maintaining persistent logs that map user IP + addresses and timestamps to hardware identifiers such as MAC + addresses may be used to attribute liability for copyright + infringement or other illegal activity. + + It is worth noting that this requirement can be met without using + DHCPv6 address assignment. For example, it is possible to maintain + these mappings by monitoring the IPv6 neighbor table: routers + typically allow periodic dumps of the Neighbor Cache via the Simple + Network Management Protocol (SNMP) or other means, and many can be + configured to log every change to the Neighbor Cache. Using SLAAC + with a dedicated /64 prefix for each host simplifies tracking, as it + does not require logging every address formed by the host, but only + the prefix assigned to the host when it attaches to the network. + Similarly, providing address space using DHCPv6 PD has the same + tracking properties as DHCPv6 address assignment, but allows the + network to provide unrestricted address space. + + Many large enterprise networks are fully dual stack and implement + address monitoring without using or supporting DHCPv6. The authors + are directly aware of several networks that operate in this way, + including the Universities of Loughborough, Minnesota, Reading, + Southampton, and Wisconsin, and Imperial College London, in addition + to the enterprise networks of the authors' employers. + + It should also be noted that using DHCPv6 address assignment does not + ensure that the network can reliably track the IPv6 addresses used by + hosts. On any shared network without Layer 2 (L2) edge port + security, hosts are able to choose their own addresses regardless of + what address provisioning methodology the network operator believes + is in use. The only way to restrict the addresses used by hosts is + to use L2 security mechanisms that enforce that particular IPv6 + addresses are used by particular link-layer addresses (for example, + Source Address Validation Improvement (SAVI) [RFC7039]). If those + mechanisms are available, it is possible to use them to provide + tracking; this form of tracking is more secure and reliable than + server logs because it operates independently of how addresses are + allocated. Finally, tracking address information via DHCPv6 server + logs is likely to become decreasingly viable due to ongoing efforts + to improve the privacy of DHCPv6 and MAC address randomization + [RFC7844]. + + + +Colitti, et al. Best Current Practice [Page 9] + +RFC 7934 Host Address Availability Recommendations July 2016 + + +9.2. Address Space Management + + In IPv4, all but the world's largest networks can be addressed using + private space [RFC1918], with each host receiving one IPv4 address. + Many networks can be numbered in 192.168.0.0/16, which has roughly 65 + thousand addresses. In IPv6, that is equivalent to a /48, with each + host receiving a /64 prefix. Under current Regional Internet + Registry (RIR) policies, a /48 is easy to obtain for an enterprise + network. Networks that need a bigger block of private space use + 10.0.0.0/8, which has roughly 16 million addresses. In IPv6, that is + equivalent to a /40, with each host receiving a /64 prefix. + Enterprises of such size can easily obtain a /40 under current RIR + policies. + + In the above cases, aggregation and routing can be equivalent to + IPv4: if a network aggregates per-host IPv4 addresses into prefixes + of length /32 - n, it can aggregate per-host /64 prefixes into the + same number of prefixes of length /64 - n. + + Currently, residential users typically receive one IPv4 address and a + /48, /56, or /60 IPv6 prefix. While such networks do not provide + enough space to assign a /64 per host, such networks almost + universally use SLAAC, and thus do not pose any particular limit to + the number of addresses hosts can use. + + Unlike IPv4 where addresses came at a premium, in all of these + networks there is enough IPv6 address space to supply clients with + multiple IPv6 addresses. + +9.3. Addressing Link-Layer Scalability Issues via IP Routing + + The number of IPv6 addresses on a link has a direct impact on + networking infrastructure nodes (routers, switches) and other nodes + on the link. Setting aside exhaustion attacks via L2 address + spoofing, every (L2, IP) address pair impacts networking hardware + requirements in terms of memory, Multicast Listener Discovery (MLD) + snooping, solicited node multicast groups, etc. Many of these costs + are incurred by neighboring hosts. + + Hosts on such networks that create unreasonable numbers of addresses + risk impairing network connectivity for themselves and other hosts on + the network, and in extreme cases (e.g., hundreds or thousands of + addresses) may even find their network access restricted by denial- + of-service protection mechanisms. + + We expect these scaling limitations to change over time as hardware + and applications evolve. However, switching to a dedicated /64 + prefix per host can resolve these scaling limitations. If the prefix + + + +Colitti, et al. Best Current Practice [Page 10] + +RFC 7934 Host Address Availability Recommendations July 2016 + + + is provided via DHCPv6 PD, or if the prefix can be used by only one + link-layer address (e.g., if the link layer uniquely identifies or + authenticates hosts based on MAC addresses), then there will be only + one routing entry and one ND cache entry per host on the network. + Furthermore, if the host is aware that the prefix is dedicated (e.g., + if it was provided via DHCPv6 PD and not SLAAC), it is possible for + the host to assign IPv6 addresses from this prefix to an internal + virtual interface such as a loopback interface. This obviates the + need to perform Neighbor Discovery and Duplicate Address Detection on + the network interface for these addresses, reducing network traffic. + + Thus, assigning a dedicated /64 prefix per host is operationally + prudent. Clearly, however, it requires more IPv6 address space than + using shared links, so the benefits provided must be weighed with the + operational overhead of address space management. + +10. Security Considerations + + As mentioned in Section 9.3, on shared networks using SLAAC, it is + possible for hosts to attempt to exhaust network resources and + possibly deny service to other hosts by creating unreasonable numbers + (e.g., hundreds or thousands) of addresses. Networks that provide + access to untrusted hosts can mitigate this threat by providing a + dedicated /64 prefix per host. It is also possible to mitigate the + threat by limiting the number of ND cache entries that can be created + for a particular host, but care must be taken to ensure that the + network does not prevent the legitimate use of multiple IP addresses + by non-malicious hosts. + + Security issues related to host tracking are discussed in + Section 9.1. + +11. References + +11.1. Normative References + + [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate + Requirement Levels", BCP 14, RFC 2119, + DOI 10.17487/RFC2119, March 1997, + <http://www.rfc-editor.org/info/rfc2119>. + +11.2. Informative References + + [ILA] Herbert, T., "Identifier-locator addressing for network + virtualization", Work in Progress, draft-herbert-nvo3- + ila-02, March 2016. + + + + + +Colitti, et al. Best Current Practice [Page 11] + +RFC 7934 Host Address Availability Recommendations July 2016 + + + [IPv6v4] Japan Internet Exchange, "IPv6v4 Exchange Service", April + 2013, <http://www.jpix.ad.jp/en/service/ipv6v4.html>. + + [KA] Roskind, J., "Quick UDP Internet Connections", November + 2013, <http://www.ietf.org/proceedings/88/slides/ + slides-88-tsvarea-10.pdf>. + + [L66] McHardy, P., "netfilter: ipv6: add IPv6 NAT support", + Linux commit 58a317f1061c894d2344c0b6a18ab4a64b69b815, + August 2012, <https://git.kernel.org/cgit/linux/kernel/ + git/torvalds/linux.git/commit/ + ?id=58a317f1061c894d2344c0b6a18ab4a64b69b815>. + + [QUIC] Hamilton, R., Iyengar, J., Swett, I., and A. Wilk, "QUIC: + A UDP-Based Secure and Reliable Transport for HTTP/2", + Work in Progress, draft-tsvwg-quic-protocol-02, January + 2016. + + [RFC1918] Rekhter, Y., Moskowitz, B., Karrenberg, D., de Groot, G., + and E. Lear, "Address Allocation for Private Internets", + BCP 5, RFC 1918, DOI 10.17487/RFC1918, February 1996, + <http://www.rfc-editor.org/info/rfc1918>. + + [RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6 + (IPv6) Specification", RFC 2460, DOI 10.17487/RFC2460, + December 1998, <http://www.rfc-editor.org/info/rfc2460>. + + [RFC2993] Hain, T., "Architectural Implications of NAT", RFC 2993, + DOI 10.17487/RFC2993, November 2000, + <http://www.rfc-editor.org/info/rfc2993>. + + [RFC3315] Droms, R., Ed., Bound, J., Volz, B., Lemon, T., Perkins, + C., and M. Carney, "Dynamic Host Configuration Protocol + for IPv6 (DHCPv6)", RFC 3315, DOI 10.17487/RFC3315, July + 2003, <http://www.rfc-editor.org/info/rfc3315>. + + [RFC3633] Troan, O. and R. Droms, "IPv6 Prefix Options for Dynamic + Host Configuration Protocol (DHCP) version 6", RFC 3633, + DOI 10.17487/RFC3633, December 2003, + <http://www.rfc-editor.org/info/rfc3633>. + + [RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing + Architecture", RFC 4291, DOI 10.17487/RFC4291, February + 2006, <http://www.rfc-editor.org/info/rfc4291>. + + [RFC4389] Thaler, D., Talwar, M., and C. Patel, "Neighbor Discovery + Proxies (ND Proxy)", RFC 4389, DOI 10.17487/RFC4389, April + 2006, <http://www.rfc-editor.org/info/rfc4389>. + + + +Colitti, et al. Best Current Practice [Page 12] + +RFC 7934 Host Address Availability Recommendations July 2016 + + + [RFC4862] Thomson, S., Narten, T., and T. Jinmei, "IPv6 Stateless + Address Autoconfiguration", RFC 4862, + DOI 10.17487/RFC4862, September 2007, + <http://www.rfc-editor.org/info/rfc4862>. + + [RFC4941] Narten, T., Draves, R., and S. Krishnan, "Privacy + Extensions for Stateless Address Autoconfiguration in + IPv6", RFC 4941, DOI 10.17487/RFC4941, September 2007, + <http://www.rfc-editor.org/info/rfc4941>. + + [RFC5902] Thaler, D., Zhang, L., and G. Lebovitz, "IAB Thoughts on + IPv6 Network Address Translation", RFC 5902, + DOI 10.17487/RFC5902, July 2010, + <http://www.rfc-editor.org/info/rfc5902>. + + [RFC6434] Jankiewicz, E., Loughney, J., and T. Narten, "IPv6 Node + Requirements", RFC 6434, DOI 10.17487/RFC6434, December + 2011, <http://www.rfc-editor.org/info/rfc6434>. + + [RFC6459] Korhonen, J., Ed., Soininen, J., Patil, B., Savolainen, + T., Bajko, G., and K. Iisakkila, "IPv6 in 3rd Generation + Partnership Project (3GPP) Evolved Packet System (EPS)", + RFC 6459, DOI 10.17487/RFC6459, January 2012, + <http://www.rfc-editor.org/info/rfc6459>. + + [RFC6877] Mawatari, M., Kawashima, M., and C. Byrne, "464XLAT: + Combination of Stateful and Stateless Translation", + RFC 6877, DOI 10.17487/RFC6877, April 2013, + <http://www.rfc-editor.org/info/rfc6877>. + + [RFC7039] Wu, J., Bi, J., Bagnulo, M., Baker, F., and C. Vogt, Ed., + "Source Address Validation Improvement (SAVI) Framework", + RFC 7039, DOI 10.17487/RFC7039, October 2013, + <http://www.rfc-editor.org/info/rfc7039>. + + [RFC7217] Gont, F., "A Method for Generating Semantically Opaque + Interface Identifiers with IPv6 Stateless Address + Autoconfiguration (SLAAC)", RFC 7217, + DOI 10.17487/RFC7217, April 2014, + <http://www.rfc-editor.org/info/rfc7217>. + + [RFC7278] Byrne, C., Drown, D., and A. Vizdal, "Extending an IPv6 + /64 Prefix from a Third Generation Partnership Project + (3GPP) Mobile Interface to a LAN Link", RFC 7278, + DOI 10.17487/RFC7278, June 2014, + <http://www.rfc-editor.org/info/rfc7278>. + + + + + +Colitti, et al. Best Current Practice [Page 13] + +RFC 7934 Host Address Availability Recommendations July 2016 + + + [RFC7421] Carpenter, B., Ed., Chown, T., Gont, F., Jiang, S., + Petrescu, A., and A. Yourtchenko, "Analysis of the 64-bit + Boundary in IPv6 Addressing", RFC 7421, + DOI 10.17487/RFC7421, January 2015, + <http://www.rfc-editor.org/info/rfc7421>. + + [RFC7844] Huitema, C., Mrugalski, T., and S. Krishnan, "Anonymity + Profiles for DHCP Clients", RFC 7844, + DOI 10.17487/RFC7844, May 2016, + <http://www.rfc-editor.org/info/rfc7844>. + + [TARP] Gleitz, PM. and SB. Bellovin, "Transient Addressing for + Related Processes: Improved Firewalling by Using IPv6 and + Multiple Addresses per Host", In Proceedings of the + Eleventh Usenix Security Symposium, August 2001, + <https://www.usenix.org/legacy/events/sec01/gleitz.html>. + + [TS.24327] 3GPP, "Mobility between 3GPP Wireless Local Area Network + (WLAN) interworking (I-WLAN) and 3GPP systems; General + Packet Radio System (GPRS) and 3GPP I-WLAN aspects; Stage + 3", 3GPP TS 24.327, June 2011, + <http://www.3gpp.org/DynaReport/24327.htm>. + + [V66] Oracle, "What's New in VirtualBox 4.3?", October 2013, + <https://blogs.oracle.com/fatbloke/entry/ + what_s_new_in_virtualbox>. + +Acknowledgements + + The authors thank Tore Anderson, Brian Carpenter, David Farmer, + Wesley George, Geoff Huston, Erik Kline, Victor Kuarsingh, Shucheng + (Will) Liu, Shin Miyakawa, Dieter Siegmund, Mark Smith, Sander + Steffann, Fred Templin, and James Woodyatt for their input and + contributions. + + + + + + + + + + + + + + + + + +Colitti, et al. Best Current Practice [Page 14] + +RFC 7934 Host Address Availability Recommendations July 2016 + + +Authors' Addresses + + Lorenzo Colitti + Google + Roppongi 6-10-1 + Minato, Tokyo 106-6126 + Japan + + Email: lorenzo@google.com + + + Vint Cerf + Google + 1875 Explorer Street + 10th Floor + Reston, VA 20190 + United States of America + + Email: vint@google.com + + + Stuart Cheshire + Apple Inc. + 1 Infinite Loop + Cupertino, CA 95014 + United States of America + + Email: cheshire@apple.com + + + David Schinazi + Apple Inc. + 1 Infinite Loop + Cupertino, CA 95014 + United States of America + + Email: dschinazi@apple.com + + + + + + + + + + + + + + +Colitti, et al. Best Current Practice [Page 15] + |