--- 1/draft-ietf-v6ops-host-addr-availability-03.txt 2016-01-03 20:15:11.501462825 -0800 +++ 2/draft-ietf-v6ops-host-addr-availability-04.txt 2016-01-03 20:15:11.533463603 -0800 @@ -1,21 +1,21 @@ IPv6 Operations L. Colitti Internet-Draft V. Cerf Intended status: Best Current Practice Google -Expires: June 12, 2016 S. Cheshire +Expires: July 6, 2016 S. Cheshire D. Schinazi Apple Inc. - December 10, 2015 + January 3, 2016 Host address availability recommendations - draft-ietf-v6ops-host-addr-availability-03 + draft-ietf-v6ops-host-addr-availability-04 Abstract This document recommends that networks provide general-purpose end hosts with multiple global IPv6 addresses when they attach, and describes the benefits of and the options for doing so. Status of This Memo This Internet-Draft is submitted in full conformance with the @@ -24,114 +24,114 @@ Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at http://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." - This Internet-Draft will expire on June 12, 2016. + This Internet-Draft will expire on July 6, 2016. Copyright Notice - Copyright (c) 2015 IETF Trust and the persons identified as the + 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. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 1.1. Requirements Language . . . . . . . . . . . . . . . . . . 3 2. Common IPv6 deployment model . . . . . . . . . . . . . . . . 3 - 3. Benefits of multiple addresses . . . . . . . . . . . . . . . 3 - 4. Problems with assigning a restricted number of addresses per - host . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 + 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 obtaining more than one address . . . . . . . . . 6 + 6. Options for providing more than one address . . . . . . . . . 6 7. Number of addresses required . . . . . . . . . . . . . . . . 7 8. Recommendations . . . . . . . . . . . . . . . . . . . . . . . 7 9. Operational considerations . . . . . . . . . . . . . . . . . 8 9.1. Stateful addressing and host tracking . . . . . . . . . . 8 9.2. Address space management . . . . . . . . . . . . . . . . 9 9.3. Addressing link layer scalability issues via IP routing . 9 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 10 11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 12. Security Considerations . . . . . . . . . . . . . . . . . . . 10 13. References . . . . . . . . . . . . . . . . . . . . . . . . . 10 13.1. Normative References . . . . . . . . . . . . . . . . . . 10 13.2. Informative References . . . . . . . . . . . . . . . . . 10 - Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 12 + Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 13 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 areas it can lead to carrying over IPv4 practices that are not appropriate in IPv6 due to significant 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, each link has a virtually unlimited amount of address space [RFC7421]. Thus, unlike IPv4, IPv6 networks are not forced by address availability - considerations to assign only one address per host. On the other - hand, assigning multiple addresses has many benefits including + considerations to provide only one address per host. On the other + hand, providing multiple addresses has many benefits including application functionality and simplicity, privacy, future applications, and the ability to deploy the Internet without the use - of NAT. Assigning only one IPv6 address per host negates these + of NAT. Providing only one IPv6 address per host negates these benefits. - This document describes the benefits of assigning multiple addresses + This document describes 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 ([RFC4291] section 2.1, [RFC6434] section 5.9.4). 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 EUI-64 or Opaque Interface Identifiers [RFC7217]), one or more privacy addresses [RFC4941], and - possibly one or more temporary or non-temporary addresses assigned + possibly one or more temporary or non-temporary addresses obtained using DHCPv6 [RFC3315]. In most general-purpose IPv6 networks, including all 3GPP networks ([RFC6459] section 5.2) and Ethernet and Wi-Fi networks using SLAAC [RFC4862], IPv6 hosts have the ability to configure additional IPv6 addresses from the link prefix(es) without explicit requests to the network. -3. Benefits of multiple addresses +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: 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 baseband processor need to communicate with the network, particularly for @@ -165,23 +165,23 @@ ). 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 PD, which is only available in 3GPP release 10 ([RFC6459] section 5.3). -4. Problems with assigning a restricted number of addresses per host +4. Problems with restricting the number of addresses per host - Assigning a restricted number of addresses per host implies that + Providing a restricted number of addresses per host implies that functions that require multiple addresses will either 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 that the functions will only be available after an explicit request to the network is granted. The necessity of explicit requests has the following drawbacks: o Increased latency, because a provisioning operation, and possibly human intervention with an update to the service level agreement, must complete before the functionality is available. @@ -235,63 +235,68 @@ NAT66 since late 2012 . A popular software hypervisor also recently implemented NAT66 to work around these issues . 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 assign only one IPv6 + 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 obtaining more than one address +6. Options for providing more than one address - Multiple IPv6 addresses can be obtained in the following ways: + Multiple IPv6 addresses can be provided in the following ways: o Using Stateless Address Autoconfiguration [RFC4862]. SLAAC allows hosts to create global IPv6 addresses on demand by simply forming new addresses from the global prefix assigned to the link. 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 assign the - client multiple addresses. It is also technically possible for a - client to request additional addresses using a different 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 so on. + 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 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 so on. o DHCPv6 prefix delegation [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 which can be further delegated to downstream clients. If the prefix is a /64, it can be extended via L2 bridging, 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 [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 [RFC2460]. + +--------------------------+-------+-------------+--------+---------+ | | SLAAC | DHCPv6 | DHCPv6 | DHCPv4 | | | | IA_NA / | PD | | | | | IA_TA | | | +--------------------------+-------+-------------+--------+---------+ | Extend network | Yes | No | Yes | Yes | | | | | | (NAT44) | | "Unlimited" endpoints | Yes* | Yes* | No | No | | Stateful, request-based | No | Yes | Yes | Yes | | Immune to layer 3 on- | No | Yes | Yes | Yes | @@ -415,31 +420,29 @@ hardware requirements in terms of memory, 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 DHCPv6 PD model with one /64 prefix per host - resolves these scaling limitations, with only one routing entry and - one ND cache entry per device on the network. + However, switching to a DHCPv6 PD model providing a dedicated /64 + prefix per host resolves these scaling limitations, with only one + routing entry and one ND cache entry per host on the network. Also, a DHCPv6 PD model with a dedicated /64 per host makes it - possible for the host not to assign global IPv6 addresses directly to - its physical network interface, but instead to assign them to an + possible for the host to assign IPv6 addresses from this prefix to an internal interface such as a loopback interface. This obviates the - need to perform Neighbour Discovery and Duplicate Address Detection - for anything other than the link-local address on its physical - network interface, reducing network traffic. + need to perform Neighbor Discovery and Duplicate Address Detection on + the network interface for these addresses, reducing network traffic. 10. Acknowledgements The authors thank Tore Anderson, Brian Carpenter, David Farmer, Wesley George, Erik Kline, Shucheng (Will) Liu, Dieter Siegmund, Mark Smith, Sander Steffann and James Woodyatt for their input and contributions. 11. IANA Considerations @@ -473,20 +476,24 @@ [I-D.tsvwg-quic-protocol] Iyengar, J. and I. Swett, "QUIC: A UDP-Based Secure and Reliable Transport for HTTP/2", draft-tsvwg-quic- protocol-01 (work in progress), July 2015. [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, . + [RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6 + (IPv6) Specification", RFC 2460, DOI 10.17487/RFC2460, + December 1998, . + [RFC2993] Hain, T., "Architectural Implications of NAT", RFC 2993, DOI 10.17487/RFC2993, November 2000, . [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, . [RFC3633] Troan, O. and R. Droms, "IPv6 Prefix Options for Dynamic