| IPv6 Operations | L. Colitti |
| Internet-Draft | V. Cerf |
| Intended status: Best Current Practice | |
| Expires: September 10, 2016 | S. Cheshire |
| D. Schinazi | |
| Apple Inc. | |
| March 9, 2016 |
Host address availability recommendations
draft-ietf-v6ops-host-addr-availability-06
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.
This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79.
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 September 10, 2016.
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.
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 availability considerations to provide only one address per host. On the other hand, providing multiple addresses has many benefits including application functionality and simplicity, privacy, flexibility to accommodate future applications, and the ability to provide Internet access without the use of NAT. Providing only one IPv6 address per host negates these benefits.
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.
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].
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 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.
Today, there are many host functions that require more than one IP address to be available to the host, including:
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:
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:
Some operators may desire to configure their networks to limit the number of IPv6 addresses per host. Reasons might include hardware limitations (e.g., TCAM or neighbor cache table size constraints), 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.
These limits can mostly be overcome by end hosts by using NAT, and indeed in IPv4 most of these functions are provided 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 <http://www.ietf.org/proceedings/88/slides/slides-88-tsvarea-10.pdf>. For example, the QUIC protocol uses a 15-second keepalive [I-D.tsvwg-quic-protocol]. 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 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 NAT66 since late 2012 <http://kernelnewbies.org/Linux_3.7#head-103e14959eeb974bbd4e862df8afe7c118ba2beb>. A popular software hypervisor also recently implemented NAT66 to work around these issues <https://communities.vmware.com/docs/DOC-29954>. 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.
Multiple IPv6 addresses can be provided in the following ways:
| SLAAC | DHCPv6 IA_NA / IA_TA | DHCPv6 PD | DHCPv4 | |
|---|---|---|---|---|
| Can extend network | No+ | No | Yes | Yes (NAT44) |
| Can number "unlimited" endpoints | Yes* | Yes* | No | No |
| Uses stateful, request-based assignment | No | Yes | Yes | Yes |
| Is immune to layer 3 on-link resource exhaustion attacks | No | Yes | Yes | Yes |
[*] Subject to network limitations, e.g., ND cache entry size limits. [+] Except on certain networks, e.g., [RFC7278].
If we itemize the use cases from section Section 3, we can estimate the number of addresses currently used in normal operations. In typical implementations, privacy addresses use up to 8 addresses - one per day ([RFC4941] section 3.5). Current mobile devices may typically support 8 clients, with each one requiring one or more addresses. A client might choose to run several virtual machines. Current implementations of 464XLAT require 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.
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 RECOMMENDED to not 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 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 sets a limit on the number of addresses available to hosts when they attach and would limit the development of future applications.
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 avoid 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 IPv6 neighbor table: routers typically allow periodic dumps of the neighbor cache via SNMP or other means, and many can be configured to log every change to the neighbor cache. Using SLAAC with a dedicated /64 prefix simplifies tracking, as it does not require logging each 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, 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 L2 edge port security, hosts are able to choose their own addresses regardless of what address provisioning methodology is in use. The only way to restrict the addresses used by hosts is to use layer 2 security mechanisms that enforce that particular IPv6 addresses are used by particular link-layer addresses (for example, 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 [I-D.ietf-dhc-anonymity-profile].
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 64k addresses. In IPv6, that is equivalent to a /48, with each of 64k hosts receiving a /64 prefix. Under current 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 /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 these networks, there is enough IPv6 address space to supply clients with multiple IPv6 addresses.
The number of IPv6 addresses on a link has direct impact for networking infrastructure nodes (routers, switches) and other nodes on the link. Setting aside exhaustion attacks via Layer 2 address spoofing, every (Layer 2, IP) address pair impacts networking 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 dedicated /64 prefix per host can resolve these scaling limitations. If the prefix 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 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.
The authors thank Tore Anderson, Brian Carpenter, David Farmer, Wesley George, Geoff Huston, Erik Kline, Victor Kuarsingh, Shucheng (Will) Liu, Dieter Siegmund, Mark Smith, Sander Steffann, Fred Templin and James Woodyatt for their input and contributions.
This memo includes no request to IANA.
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 restrict the IP addresses available to non-malicious hosts.
Security issues related to host tracking are discussed in section 9.1.
| [RFC2119] | Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997. |