--- 1/draft-ietf-v6ops-host-addr-availability-04.txt 2016-02-12 10:15:33.591760759 -0800 +++ 2/draft-ietf-v6ops-host-addr-availability-05.txt 2016-02-12 10:15:33.627761653 -0800 @@ -1,21 +1,21 @@ IPv6 Operations L. Colitti Internet-Draft V. Cerf Intended status: Best Current Practice Google -Expires: July 6, 2016 S. Cheshire +Expires: August 15, 2016 S. Cheshire D. Schinazi Apple Inc. - January 3, 2016 + February 12, 2016 Host address availability recommendations - draft-ietf-v6ops-host-addr-availability-04 + draft-ietf-v6ops-host-addr-availability-05 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,21 +24,21 @@ 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 July 6, 2016. + This Internet-Draft will expire on August 15, 2016. 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 @@ -51,31 +51,31 @@ 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 . . . . . . . . . . . . . . . . 7 - 8. Recommendations . . . . . . . . . . . . . . . . . . . . . . . 7 + 8. Recommendations . . . . . . . . . . . . . . . . . . . . . . . 8 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 + 9.3. Addressing link layer scalability issues via IP routing . 10 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 10 11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 12. Security Considerations . . . . . . . . . . . . . . . . . . . 10 - 13. References . . . . . . . . . . . . . . . . . . . . . . . . . 10 - 13.1. Normative References . . . . . . . . . . . . . . . . . . 10 - 13.2. Informative References . . . . . . . . . . . . . . . . . 10 + 13. References . . . . . . . . . . . . . . . . . . . . . . . . . 11 + 13.1. Normative References . . . . . . . . . . . . . . . . . . 11 + 13.2. Informative References . . . . . . . . . . . . . . . . . 11 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 @@ -256,42 +256,49 @@ 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 [RFC4862]. SLAAC allows hosts to create global IPv6 addresses on demand by simply forming - new addresses from the global prefix assigned to the link. + 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 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 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. + including its DUID, MAC address, and so on. The number of IPv6 + addresses that can be provided in a single DHCPv6 packet is + approximately 30. 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 | | | +--------------------------+-------+-------------+--------+---------+ @@ -323,90 +330,104 @@ 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. 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 - when they connect to the network. 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. If the network requires explicit requests - for address space (e.g., if it requires DHCPv6 to connect), it is - RECOMMENDED that the network assign a /64 prefix to every host (e.g., - via DHCPv6 PD). Using DHCPv6 IA_NA or IA_TA to request a sufficient - number of addresses (e.g. 32) 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. - Assigning prefixes longer than a /64 will limit the flexibility of - the host to further assign addresses to any internal functions, - virtual machines, or downstream clients that require address space - - for example, by not allowing the use of SLAAC. + 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. 9. Operational considerations 9.1. Stateful addressing and 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 avoid liability for copyright infringement or other illegal activity. It is worth noting that this requirement can be met without using - stateful addressing mechanisms such as DHCPv6. For example, it is - possible to maintain these mappings by scraping IPv6 neighbor tables, - as 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. + 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. - It is also worth noting that without L2 edge port security, hosts are - still able to choose their own addresses - DHCPv6 does not offer any - enforcement of what addresses a host is allowed to use. Such - guarantees can only be provided by link-layer 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 much more secure and reliable - than DHCP server logs because it operates independently of how - addresses are allocated. Additionally, attempts to track this sort - of information via DHCPv6 are likely to become decreasingly viable - due to ongoing efforts to improve the privacy of DHCP - [I-D.ietf-dhc-anonymity-profile]. + Many large enterprise networks, including the enterprise networks of + the authors' employers, are fully dual-stack and implement address + monitoring without using or supporting DHCPv6. The authors are + directly aware of several other networks that operate in this way, + including Universities of Loughborough, Minnesota, Reading, + Southampton, Wisconsin and Imperial College London. - Thus, host tracking does not necessarily require the use of stateful - address assignment mechanisms such as DHCPv6. Indeed, many large - enterprise networks, including the enterprise networks of the - authors' employers, are fully dual-stack but do not currently use or - support DHCPv6. The authors are directly aware of several networks - that operate in this way, including Universities of Loughborough, - Minnesota, Reading, Southampton, Wisconsin and Imperial College - London. + 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]. 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 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. + size can easily obtain a /40 under current RIR policies. Aggregation + and routing can be equivalent to IPv4, with /64 prefixes being + aggregated into the as many prefixes of length /64 - n as IPv4 + addresses are aggregated into prefixes of length /32 - 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. @@ -418,38 +439,39 @@ 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 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. + of-service protection mechanisms. - Also, a DHCPv6 PD model with a dedicated /64 per host makes it - 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. + 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, with only one + routing entry and one ND cache entry per host on the network. 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. 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. + Smith, Sander Steffann, Fred Templin and James Woodyatt for their + input and contributions. 11. IANA Considerations This memo includes no request to IANA. 12. Security Considerations None so far. 13. References @@ -464,26 +486,27 @@ 13.2. Informative References [I-D.herbert-nvo3-ila] Herbert, T., "Identifier-locator addressing for network virtualization", draft-herbert-nvo3-ila-01 (work in progress), October 2015. [I-D.ietf-dhc-anonymity-profile] Huitema, C., Mrugalski, T., and S. Krishnan, "Anonymity profile for DHCP clients", draft-ietf-dhc-anonymity- - profile-04 (work in progress), October 2015. + profile-06 (work in progress), January 2016. [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. + Hamilton, R., Iyengar, J., Swett, I., and A. Wilk, "QUIC: + A UDP-Based Secure and Reliable Transport for HTTP/2", + draft-tsvwg-quic-protocol-02 (work in progress), 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, . [RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6 (IPv6) Specification", RFC 2460, DOI 10.17487/RFC2460, December 1998, .