--- 1/draft-ietf-v6ops-host-addr-availability-06.txt 2016-05-25 21:15:59.582944251 -0700 +++ 2/draft-ietf-v6ops-host-addr-availability-07.txt 2016-05-25 21:15:59.618945146 -0700 @@ -1,21 +1,21 @@ IPv6 Operations L. Colitti Internet-Draft V. Cerf Intended status: Best Current Practice Google -Expires: September 10, 2016 S. Cheshire +Expires: November 26, 2016 S. Cheshire D. Schinazi Apple Inc. - March 9, 2016 + May 25, 2016 Host address availability recommendations - draft-ietf-v6ops-host-addr-availability-06 + draft-ietf-v6ops-host-addr-availability-07 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 September 10, 2016. + This Internet-Draft will expire on November 26, 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 @@ -129,21 +129,22 @@ 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 baseband processor need to communicate with the network, particularly for - recent technologies like ePDG. + 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. o Translation-based transition technologies such as 464XLAT [RFC6877] that provide IPv4 over 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). @@ -164,38 +165,39 @@ by a different network, without the knowledge or cooperation of the residential ISP (e.g., the IPv6v4 Exchange Service ). 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). + 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 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. - o Uncertainty, because it is not known in advance if a particular - operation function will be available. + o Uncertainty, because it is not known if a particular operation + 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 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), @@ -289,21 +291,24 @@ 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]. + be an IPv6 router as defined in [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 [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 | | | | | @@ -320,36 +325,38 @@ Table 1: Comparison of multiple address assignment options 7. Number of addresses required 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. + hosts. Thus, in general is 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 RECOMMENDED to not impose a hard + 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 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 @@ -365,22 +372,22 @@ 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 avoid liability for copyright infringement - or other illegal activity. + 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 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 @@ -400,21 +407,21 @@ 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]. + privacy of DHCPv6 and MAC address randomization [RFC7844]. 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 @@ -505,27 +512,22 @@ [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, . 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-08 (work in progress), February 2016. + virtualization", draft-herbert-nvo3-ila-02 (work in + progress), March 2016. [I-D.tsvwg-quic-protocol] 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, @@ -603,24 +605,35 @@ (3GPP) Mobile Interface to a LAN Link", RFC 7278, DOI 10.17487/RFC7278, June 2014, . [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, . + [RFC7844] Huitema, C., Mrugalski, T., and S. Krishnan, "Anonymity + Profiles for DHCP Clients", RFC 7844, + DOI 10.17487/RFC7844, May 2016, + . + [TARP] Gleitz, PM. and SM. Bellovin, "Transient Addressing for Related Processes: Improved Firewalling by Using IPv6 and Multiple Addresses per Host", August 2001. + [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", June 2011. + Authors' Addresses Lorenzo Colitti Google Roppongi 6-10-1 Minato, Tokyo 106-6126 JP Email: lorenzo@google.com