draft-ietf-v6ops-host-addr-availability-06.txt   draft-ietf-v6ops-host-addr-availability-07.txt 
IPv6 Operations L. Colitti IPv6 Operations L. Colitti
Internet-Draft V. Cerf Internet-Draft V. Cerf
Intended status: Best Current Practice Google Intended status: Best Current Practice Google
Expires: September 10, 2016 S. Cheshire Expires: November 26, 2016 S. Cheshire
D. Schinazi D. Schinazi
Apple Inc. Apple Inc.
March 9, 2016 May 25, 2016
Host address availability recommendations Host address availability recommendations
draft-ietf-v6ops-host-addr-availability-06 draft-ietf-v6ops-host-addr-availability-07
Abstract Abstract
This document recommends that networks provide general-purpose end This document recommends that networks provide general-purpose end
hosts with multiple global IPv6 addresses when they attach, and hosts with multiple global IPv6 addresses when they attach, and
describes the benefits of and the options for doing so. describes the benefits of and the options for doing so.
Status of This Memo Status of This Memo
This Internet-Draft is submitted in full conformance with the This Internet-Draft is submitted in full conformance with the
skipping to change at page 1, line 35 skipping to change at page 1, line 35
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." 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 Notice
Copyright (c) 2016 IETF Trust and the persons identified as the Copyright (c) 2016 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
skipping to change at page 3, line 48 skipping to change at page 3, line 48
Today, there are many host functions that require more than one IP Today, there are many host functions that require more than one IP
address to be available to the host, including: address to be available to the host, including:
o Privacy addressing to prevent tracking by off-network hosts o Privacy addressing to prevent tracking by off-network hosts
[RFC4941]. [RFC4941].
o Multiple processors inside the same device. For example, in many o Multiple processors inside the same device. For example, in many
mobile devices both the application processor and baseband mobile devices both the application processor and baseband
processor need to communicate with the network, particularly for 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 Extending the network (e.g., "tethering").
o Running virtual machines on hosts. o Running virtual machines on hosts.
o Translation-based transition technologies such as 464XLAT o Translation-based transition technologies such as 464XLAT
[RFC6877] that provide IPv4 over IPv6. Some of these technologies [RFC6877] that provide IPv4 over IPv6. Some of these technologies
require the availability of a dedicated IPv6 address in order to require the availability of a dedicated IPv6 address in order to
determine whether inbound packets are translated or native determine whether inbound packets are translated or native
([RFC6877] section 6.3). ([RFC6877] section 6.3).
skipping to change at page 4, line 36 skipping to change at page 4, line 36
by a different network, without the knowledge or cooperation of by a different network, without the knowledge or cooperation of
the residential ISP (e.g., the IPv6v4 Exchange Service the residential ISP (e.g., the IPv6v4 Exchange Service
<http://www.jpix.ad.jp/en/service/ipv6v4.html>). This type of <http://www.jpix.ad.jp/en/service/ipv6v4.html>). This type of
deployment is only possible because those residential ISPs provide deployment is only possible because those residential ISPs provide
multiple IP addresses to their users, and thus those users can multiple IP addresses to their users, and thus those users can
freely obtain the extra IPv6 address required to run 464XLAT. freely obtain the extra IPv6 address required to run 464XLAT.
o /64 sharing [RFC7278]. When the topology supports it, this is a o /64 sharing [RFC7278]. When the topology supports it, this is a
way to provide IPv6 tethering without needing to wait for network way to provide IPv6 tethering without needing to wait for network
operators to deploy DHCPv6 PD, which is only available in 3GPP 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 4. Problems with restricting the number of addresses per host
Providing 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 functions that require multiple addresses will either be unavailable
(e.g., if the network provides only one IPv6 address per host, or if (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), the host has reached the limit of the number of addresses available),
or that the functions will only be available after an explicit or that the functions will only be available after an explicit
request to the network is granted. The necessity of explicit request to the network is granted. The necessity of explicit
requests has the following drawbacks: requests has the following drawbacks:
o Increased latency, because a provisioning operation, and possibly o Increased latency, because a provisioning operation, and possibly
human intervention with an update to the service level agreement, human intervention with an update to the service level agreement,
must complete before the functionality is available. must complete before the functionality is available.
o Uncertainty, because it is not known in advance if a particular o Uncertainty, because it is not known if a particular operation
operation function will be available. function will be available until the provisioning operation
succeeds or fails.
o Complexity, because implementations need to deal with failures and o Complexity, because implementations need to deal with failures and
somehow present them to the user. Failures may manifest as somehow present them to the user. Failures may manifest as
timeouts, which may be slow and frustrating to users. timeouts, which may be slow and frustrating to users.
o Increased load on the network's provisioning servers. o Increased load on the network's provisioning servers.
Some operators may desire to configure their networks to limit the Some operators may desire to configure their networks to limit the
number of IPv6 addresses per host. Reasons might include hardware number of IPv6 addresses per host. Reasons might include hardware
limitations (e.g., TCAM or neighbor cache table size constraints), limitations (e.g., TCAM or neighbor cache table size constraints),
skipping to change at page 7, line 18 skipping to change at page 7, line 18
to request and be delegated a prefix, from which it can to request and be delegated a prefix, from which it can
autonomously form other addresses. If the prefix is shorter than autonomously form other addresses. If the prefix is shorter than
/64, it can be divided into multiple subnets which can be further /64, it can be divided into multiple subnets which can be further
delegated to downstream clients. If the prefix is a /64, it can delegated to downstream clients. If the prefix is a /64, it can
be extended via L2 bridging, ND proxying [RFC4389] or /64 sharing be extended via L2 bridging, ND proxying [RFC4389] or /64 sharing
[RFC7278], but it cannot be further subdivided, as a prefix longer [RFC7278], but it cannot be further subdivided, as a prefix longer
than /64 is outside the current IPv6 specifications [RFC7421]. than /64 is outside the current IPv6 specifications [RFC7421].
While [RFC3633] assumes that the DHCPv6 client is a router, DHCPv6 While [RFC3633] assumes that the DHCPv6 client is a router, DHCPv6
PD itself does not require that the client forward IPv6 packets PD itself does not require that the client forward IPv6 packets
not addressed to itself, and thus does not require that the client 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 | | | SLAAC | DHCPv6 | DHCPv6 | DHCPv4 |
| | | IA_NA / | PD | | | | | IA_NA / | PD | |
| | | IA_TA | | | | | | IA_TA | | |
+--------------------------+-------+-------------+--------+---------+ +--------------------------+-------+-------------+--------+---------+
| Can extend network | No+ | No | Yes | Yes | | Can extend network | No+ | No | Yes | Yes |
| | | | | (NAT44) | | | | | | (NAT44) |
| Can number "unlimited" | Yes* | Yes* | No | No | | Can number "unlimited" | Yes* | Yes* | No | No |
| endpoints | | | | | | endpoints | | | | |
skipping to change at page 7, line 49 skipping to change at page 8, line 4
Table 1: Comparison of multiple address assignment options Table 1: Comparison of multiple address assignment options
7. Number of addresses required 7. Number of addresses required
If we itemize the use cases from section Section 3, we can estimate If we itemize the use cases from section Section 3, we can estimate
the number of addresses currently used in normal operations. In the number of addresses currently used in normal operations. In
typical implementations, privacy addresses use up to 8 addresses - typical implementations, privacy addresses use up to 8 addresses -
one per day ([RFC4941] section 3.5). Current mobile devices may one per day ([RFC4941] section 3.5). Current mobile devices may
typically support 8 clients, with each one requiring one or more typically support 8 clients, with each one requiring one or more
addresses. A client might choose to run several virtual machines. addresses. A client might choose to run several virtual machines.
Current implementations of 464XLAT require use of a separate address. Current implementations of 464XLAT require use of a separate address.
Some devices require another address for their baseband chip. Even a Some devices require another address for their baseband chip. Even a
host performing just a few of these functions simultaneously might host performing just a few of these functions simultaneously might
need on the order of 20 addresses at the same time. Future need on the order of 20 addresses at the same time. Future
applications designed to use an address per application or even per applications designed to use an address per application or even per
resource will require many more. These will not function on networks resource will require many more. These will not function on networks
that enforce a hard limit on the number of addresses provided to 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 8. Recommendations
In order to avoid the problems described above, and preserve the In order to avoid the problems described above, and preserve the
Internet's ability to support new applications that use more than one Internet's ability to support new applications that use more than one
IPv6 address, it is RECOMMENDED that IPv6 network deployments provide IPv6 address, it is RECOMMENDED that IPv6 network deployments provide
multiple IPv6 addresses from each prefix to general-purpose hosts. 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. 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 Particularly, it is NOT RECOMMENDED to limit a host to only one IPv6
address per prefix. address per prefix.
Due to the drawbacks imposed by requiring explicit requests for Due to the drawbacks imposed by requiring explicit requests for
address space (see section Section 4), it is RECOMMENDED that the address space (see section Section 4), it is RECOMMENDED that the
network give the host the ability to use new addresses without network give the host the ability to use new addresses without
requiring explicit requests. This can be achieved either by allowing requiring explicit requests. This can be achieved either by allowing
the host to form new addresses autonomously (e.g., via SLAAC), or by 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 providing the host with a dedicated /64 prefix. The prefix MAY be
skipping to change at page 8, line 46 skipping to change at page 8, line 51
9. Operational considerations 9. Operational considerations
9.1. Host tracking 9.1. Host tracking
Some network operators - often operators of networks that provide Some network operators - often operators of networks that provide
services to third parties such as university campus networks - are services to third parties such as university campus networks - are
required to track which IP addresses are assigned to which hosts on required to track which IP addresses are assigned to which hosts on
their network. Maintaining persistent logs that map user IP their network. Maintaining persistent logs that map user IP
addresses and timestamps to hardware identifiers such as MAC addresses and timestamps to hardware identifiers such as MAC
addresses may be used to avoid liability for copyright infringement addresses may be used to attribute liability for copyright
or other illegal activity. infringement or other illegal activity.
It is worth noting that this requirement can be met without using It is worth noting that this requirement can be met without using
DHCPv6 address assignment. For example, it is possible to maintain DHCPv6 address assignment. For example, it is possible to maintain
these mappings by monitoring IPv6 neighbor table: routers typically these mappings by monitoring IPv6 neighbor table: routers typically
allow periodic dumps of the neighbor cache via SNMP or other means, 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. and many can be configured to log every change to the neighbor cache.
Using SLAAC with a dedicated /64 prefix simplifies tracking, as it Using SLAAC with a dedicated /64 prefix simplifies tracking, as it
does not require logging each address formed by the host, but only does not require logging each address formed by the host, but only
the prefix assigned to the host when it attaches to the network. the prefix assigned to the host when it attaches to the network.
Similarly, providing address space using DHCPv6 PD has the same Similarly, providing address space using DHCPv6 PD has the same
skipping to change at page 9, line 33 skipping to change at page 9, line 37
are able to choose their own addresses regardless of what address are able to choose their own addresses regardless of what address
provisioning methodology is in use. The only way to restrict the provisioning methodology is in use. The only way to restrict the
addresses used by hosts is to use layer 2 security mechanisms that addresses used by hosts is to use layer 2 security mechanisms that
enforce that particular IPv6 addresses are used by particular link- enforce that particular IPv6 addresses are used by particular link-
layer addresses (for example, SAVI [RFC7039]). If those mechanisms layer addresses (for example, SAVI [RFC7039]). If those mechanisms
are available, it is possible to use them to provide tracking; this are available, it is possible to use them to provide tracking; this
form of tracking is more secure and reliable than server logs because form of tracking is more secure and reliable than server logs because
it operates independently of how addresses are allocated. Finally, it operates independently of how addresses are allocated. Finally,
tracking address information via DHCPv6 server logs is likely to tracking address information via DHCPv6 server logs is likely to
become decreasingly viable due to ongoing efforts to improve the 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 9.2. Address space management
In IPv4, all but the world's largest networks can be addressed using In IPv4, all but the world's largest networks can be addressed using
private space [RFC1918], with each host receiving one IPv4 address. 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 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 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 hosts receiving a /64 prefix. Under current RIR policies, a /48 is
easy to obtain for an enterprise network. Networks that need a 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 bigger block of private space use 10.0.0.0/8, which has roughly 16
skipping to change at page 11, line 45 skipping to change at page 11, line 47
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997, DOI 10.17487/RFC2119, March 1997,
<http://www.rfc-editor.org/info/rfc2119>. <http://www.rfc-editor.org/info/rfc2119>.
13.2. Informative References 13.2. Informative References
[I-D.herbert-nvo3-ila] [I-D.herbert-nvo3-ila]
Herbert, T., "Identifier-locator addressing for network Herbert, T., "Identifier-locator addressing for network
virtualization", draft-herbert-nvo3-ila-01 (work in virtualization", draft-herbert-nvo3-ila-02 (work in
progress), October 2015. progress), March 2016.
[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.
[I-D.tsvwg-quic-protocol] [I-D.tsvwg-quic-protocol]
Hamilton, R., Iyengar, J., Swett, I., and A. Wilk, "QUIC: Hamilton, R., Iyengar, J., Swett, I., and A. Wilk, "QUIC:
A UDP-Based Secure and Reliable Transport for HTTP/2", A UDP-Based Secure and Reliable Transport for HTTP/2",
draft-tsvwg-quic-protocol-02 (work in progress), January draft-tsvwg-quic-protocol-02 (work in progress), January
2016. 2016.
[RFC1918] Rekhter, Y., Moskowitz, B., Karrenberg, D., de Groot, G., [RFC1918] Rekhter, Y., Moskowitz, B., Karrenberg, D., de Groot, G.,
and E. Lear, "Address Allocation for Private Internets", and E. Lear, "Address Allocation for Private Internets",
BCP 5, RFC 1918, DOI 10.17487/RFC1918, February 1996, BCP 5, RFC 1918, DOI 10.17487/RFC1918, February 1996,
skipping to change at page 13, line 48 skipping to change at page 13, line 48
(3GPP) Mobile Interface to a LAN Link", RFC 7278, (3GPP) Mobile Interface to a LAN Link", RFC 7278,
DOI 10.17487/RFC7278, June 2014, DOI 10.17487/RFC7278, June 2014,
<http://www.rfc-editor.org/info/rfc7278>. <http://www.rfc-editor.org/info/rfc7278>.
[RFC7421] Carpenter, B., Ed., Chown, T., Gont, F., Jiang, S., [RFC7421] Carpenter, B., Ed., Chown, T., Gont, F., Jiang, S.,
Petrescu, A., and A. Yourtchenko, "Analysis of the 64-bit Petrescu, A., and A. Yourtchenko, "Analysis of the 64-bit
Boundary in IPv6 Addressing", RFC 7421, Boundary in IPv6 Addressing", RFC 7421,
DOI 10.17487/RFC7421, January 2015, DOI 10.17487/RFC7421, January 2015,
<http://www.rfc-editor.org/info/rfc7421>. <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 SM. Bellovin, "Transient Addressing for [TARP] Gleitz, PM. and SM. Bellovin, "Transient Addressing for
Related Processes: Improved Firewalling by Using IPv6 and Related Processes: Improved Firewalling by Using IPv6 and
Multiple Addresses per Host", August 2001. 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 Authors' Addresses
Lorenzo Colitti Lorenzo Colitti
Google Google
Roppongi 6-10-1 Roppongi 6-10-1
Minato, Tokyo 106-6126 Minato, Tokyo 106-6126
JP JP
Email: lorenzo@google.com Email: lorenzo@google.com
 End of changes. 16 change blocks. 
21 lines changed or deleted 34 lines changed or added

This html diff was produced by rfcdiff 1.45. The latest version is available from http://tools.ietf.org/tools/rfcdiff/