draft-ietf-v6ops-host-addr-availability-03.txt   draft-ietf-v6ops-host-addr-availability-04.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: June 12, 2016 S. Cheshire Expires: July 6, 2016 S. Cheshire
D. Schinazi D. Schinazi
Apple Inc. Apple Inc.
December 10, 2015 January 3, 2016
Host address availability recommendations Host address availability recommendations
draft-ietf-v6ops-host-addr-availability-03 draft-ietf-v6ops-host-addr-availability-04
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 June 12, 2016. This Internet-Draft will expire on July 6, 2016.
Copyright Notice 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. 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
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
1.1. Requirements Language . . . . . . . . . . . . . . . . . . 3 1.1. Requirements Language . . . . . . . . . . . . . . . . . . 3
2. Common IPv6 deployment model . . . . . . . . . . . . . . . . 3 2. Common IPv6 deployment model . . . . . . . . . . . . . . . . 3
3. Benefits of multiple addresses . . . . . . . . . . . . . . . 3 3. Benefits of providing multiple addresses . . . . . . . . . . 3
4. Problems with assigning a restricted number of addresses per 4. Problems with restricting the number of addresses per host . 4
host . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
5. Overcoming limits using Network Address Translation . . . . . 5 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 7. Number of addresses required . . . . . . . . . . . . . . . . 7
8. Recommendations . . . . . . . . . . . . . . . . . . . . . . . 7 8. Recommendations . . . . . . . . . . . . . . . . . . . . . . . 7
9. Operational considerations . . . . . . . . . . . . . . . . . 8 9. Operational considerations . . . . . . . . . . . . . . . . . 8
9.1. Stateful addressing and host tracking . . . . . . . . . . 8 9.1. Stateful addressing and host tracking . . . . . . . . . . 8
9.2. Address space management . . . . . . . . . . . . . . . . 9 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 . 9
10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 10 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 10
11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10
12. Security Considerations . . . . . . . . . . . . . . . . . . . 10 12. Security Considerations . . . . . . . . . . . . . . . . . . . 10
13. References . . . . . . . . . . . . . . . . . . . . . . . . . 10 13. References . . . . . . . . . . . . . . . . . . . . . . . . . 10
13.1. Normative References . . . . . . . . . . . . . . . . . . 10 13.1. Normative References . . . . . . . . . . . . . . . . . . 10
13.2. Informative References . . . . . . . . . . . . . . . . . 10 13.2. Informative References . . . . . . . . . . . . . . . . . 10
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 12 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 13
1. Introduction 1. Introduction
In most aspects, the IPv6 protocol is very similar to IPv4. This 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, similarity can create a tendency to think of IPv6 as 128-bit IPv4,
and thus lead network designers and operators to apply identical and thus lead network designers and operators to apply identical
configurations and operational practices to both. This is generally configurations and operational practices to both. This is generally
a good thing because it eases the transition to IPv6 and the a good thing because it eases the transition to IPv6 and the
operation of dual-stack networks. However, in some areas it can lead 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 carrying over IPv4 practices that are not appropriate in IPv6 due
to significant differences between the protocols. to significant differences between the protocols.
One such area is IP addressing, particularly IP addressing of hosts. One such area is IP addressing, particularly IP addressing of hosts.
This is substantially different because unlike IPv4 addresses, IPv6 This is substantially different because unlike IPv4 addresses, IPv6
addresses are not a scarce resource. In IPv6, each link has a addresses are not a scarce resource. In IPv6, each link has a
virtually unlimited amount of address space [RFC7421]. Thus, unlike virtually unlimited amount of address space [RFC7421]. Thus, unlike
IPv4, IPv6 networks are not forced by address availability IPv4, IPv6 networks are not forced by address availability
considerations to assign only one address per host. On the other considerations to provide only one address per host. On the other
hand, assigning multiple addresses has many benefits including hand, providing multiple addresses has many benefits including
application functionality and simplicity, privacy, future application functionality and simplicity, privacy, future
applications, and the ability to deploy the Internet without the use 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. 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 per host and the problems with not doing so. It recommends that
networks provide general-purpose end hosts with multiple global networks provide general-purpose end hosts with multiple global
addresses when they attach, and lists current options for doing so. 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 1.1. Requirements Language
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described in "OPTIONAL" in this document are to be interpreted as described in
"Key words for use in RFCs to Indicate Requirement Levels" [RFC2119]. "Key words for use in RFCs to Indicate Requirement Levels" [RFC2119].
2. Common IPv6 deployment model 2. Common IPv6 deployment model
IPv6 is designed to support multiple addresses, including multiple IPv6 is designed to support multiple addresses, including multiple
global addresses, per interface ([RFC4291] section 2.1, [RFC6434] global addresses, per interface ([RFC4291] section 2.1, [RFC6434]
section 5.9.4). Today, many general-purpose IPv6 hosts are section 5.9.4). Today, many general-purpose IPv6 hosts are
configured with three or more addresses per interface: a link-local configured with three or more addresses per interface: a link-local
address, a stable address (e.g., using EUI-64 or Opaque Interface address, a stable address (e.g., using EUI-64 or Opaque Interface
Identifiers [RFC7217]), one or more privacy addresses [RFC4941], and 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]. using DHCPv6 [RFC3315].
In most general-purpose IPv6 networks, including all 3GPP networks In most general-purpose IPv6 networks, including all 3GPP networks
([RFC6459] section 5.2) and Ethernet and Wi-Fi networks using SLAAC ([RFC6459] section 5.2) and Ethernet and Wi-Fi networks using SLAAC
[RFC4862], IPv6 hosts have the ability to configure additional IPv6 [RFC4862], IPv6 hosts have the ability to configure additional IPv6
addresses from the link prefix(es) without explicit requests to the addresses from the link prefix(es) without explicit requests to the
network. network.
3. Benefits of multiple addresses 3. Benefits of providing multiple addresses
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: address to be available to the host:
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
skipping to change at page 4, line 36 skipping to change at page 4, line 36
<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 ([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 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.
skipping to change at page 6, line 10 skipping to change at page 6, line 10
NAT66 since late 2012 <http://kernelnewbies.org/Linux_3.7#head- NAT66 since late 2012 <http://kernelnewbies.org/Linux_3.7#head-
103e14959eeb974bbd4e862df8afe7c118ba2beb>. A popular software 103e14959eeb974bbd4e862df8afe7c118ba2beb>. A popular software
hypervisor also recently implemented NAT66 to work around these hypervisor also recently implemented NAT66 to work around these
issues <https://communities.vmware.com/docs/DOC-29954>. Wide issues <https://communities.vmware.com/docs/DOC-29954>. Wide
deployment of networks that provide a restricted number of addresses deployment of networks that provide a restricted number of addresses
will cause proliferation of NAT66 implementations. will cause proliferation of NAT66 implementations.
This is not a desirable outcome. It is not desirable for users This is not a desirable outcome. It is not desirable for users
because they may experience application brittleness. It is likely because they may experience application brittleness. It is likely
not desirable for network operators either, as they may suffer higher 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 address per device is dictated by the network's business model, there
may be little in the way of incremental revenue, because devices can may be little in the way of incremental revenue, because devices can
share their IPv6 address with other devices. Finally, it is not share their IPv6 address with other devices. Finally, it is not
desirable for operating system manufacturers and application desirable for operating system manufacturers and application
developers, who will have to build more complexity, lengthening developers, who will have to build more complexity, lengthening
development time and/or reducing the time spent on other features. development time and/or reducing the time spent on other features.
Indeed, it could be argued that the main reason for deploying IPv6, Indeed, it could be argued that the main reason for deploying IPv6,
instead of continuing to scale the Internet using only IPv4 and instead of continuing to scale the Internet using only IPv4 and
large-scale NAT44, is because doing so can provide all the hosts on 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 the planet with end-to-end connectivity that is constrained not by
accidental technical limitations, but only by intentional security accidental technical limitations, but only by intentional security
policies. 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 o Using Stateless Address Autoconfiguration [RFC4862]. SLAAC allows
hosts to create global IPv6 addresses on demand by simply forming 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 assigned to the link.
o Using stateful DHCPv6 address assignment [RFC3315]. Most DHCPv6 o Using stateful DHCPv6 address assignment [RFC3315]. Most DHCPv6
clients only ask for one non-temporary address, but the protocol clients only ask for one non-temporary address, but the protocol
allows requesting multiple temporary and even multiple non- allows requesting multiple temporary and even multiple non-
temporary addresses, and the server could choose to assign the temporary addresses, and the server could choose to provide
client multiple addresses. It is also technically possible for a multiple addresses. It is also technically possible for a client
client to request additional addresses using a different DUID, to request additional addresses using a different DUID, though the
though the DHCPv6 specification implies that this is not expected DHCPv6 specification implies that this is not expected behavior
behavior ([RFC3315] section 9). The DHCPv6 server will decide ([RFC3315] section 9). The DHCPv6 server will decide whether to
whether to grant or reject the request based on information about grant or reject the request based on information about the client,
the client, including its DUID, MAC address, and so on. including its DUID, MAC address, and so on.
o DHCPv6 prefix delegation [RFC3633]. DHCPv6 PD allows the client o DHCPv6 prefix delegation [RFC3633]. DHCPv6 PD allows the client
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
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 | | | SLAAC | DHCPv6 | DHCPv6 | DHCPv4 |
| | | IA_NA / | PD | | | | | IA_NA / | PD | |
| | | IA_TA | | | | | | IA_TA | | |
+--------------------------+-------+-------------+--------+---------+ +--------------------------+-------+-------------+--------+---------+
| Extend network | Yes | No | Yes | Yes | | Extend network | Yes | No | Yes | Yes |
| | | | | (NAT44) | | | | | | (NAT44) |
| "Unlimited" endpoints | Yes* | Yes* | No | No | | "Unlimited" endpoints | Yes* | Yes* | No | No |
| Stateful, request-based | No | Yes | Yes | Yes | | Stateful, request-based | No | Yes | Yes | Yes |
| Immune to layer 3 on- | No | Yes | Yes | Yes | | Immune to layer 3 on- | No | Yes | Yes | Yes |
skipping to change at page 9, line 45 skipping to change at page 9, line 50
hardware requirements in terms of memory, MLD snooping, solicited hardware requirements in terms of memory, MLD snooping, solicited
node multicast groups, etc. Many of these costs are incurred by node multicast groups, etc. Many of these costs are incurred by
neighboring hosts. neighboring hosts.
Hosts on such networks that create unreasonable numbers of addresses Hosts on such networks that create unreasonable numbers of addresses
risk impairing network connectivity for themselves and other hosts on risk impairing network connectivity for themselves and other hosts on
the network, and in extreme cases (e.g., hundreds or thousands of the network, and in extreme cases (e.g., hundreds or thousands of
addresses) may even find their network access restricted by denial- addresses) may even find their network access restricted by denial-
of-service protection mechanisms. We expect these scaling of-service protection mechanisms. We expect these scaling
limitations to change over time as hardware and applications evolve. limitations to change over time as hardware and applications evolve.
However, switching to a DHCPv6 PD model with one /64 prefix per host However, switching to a DHCPv6 PD model providing a dedicated /64
resolves these scaling limitations, with only one routing entry and prefix per host resolves these scaling limitations, with only one
one ND cache entry per device on the network. 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 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 possible for the host to assign IPv6 addresses from this prefix to an
its physical network interface, but instead to assign them to an
internal interface such as a loopback interface. This obviates the internal interface such as a loopback interface. This obviates the
need to perform Neighbour Discovery and Duplicate Address Detection need to perform Neighbor Discovery and Duplicate Address Detection on
for anything other than the link-local address on its physical the network interface for these addresses, reducing network traffic.
network interface, reducing network traffic.
10. Acknowledgements 10. Acknowledgements
The authors thank Tore Anderson, Brian Carpenter, David Farmer, The authors thank Tore Anderson, Brian Carpenter, David Farmer,
Wesley George, Erik Kline, Shucheng (Will) Liu, Dieter Siegmund, Mark Wesley George, Erik Kline, Shucheng (Will) Liu, Dieter Siegmund, Mark
Smith, Sander Steffann and James Woodyatt for their input and Smith, Sander Steffann and James Woodyatt for their input and
contributions. contributions.
11. IANA Considerations 11. IANA Considerations
skipping to change at page 11, line 10 skipping to change at page 11, line 15
[I-D.tsvwg-quic-protocol] [I-D.tsvwg-quic-protocol]
Iyengar, J. and I. Swett, "QUIC: A UDP-Based Secure and Iyengar, J. and I. Swett, "QUIC: A UDP-Based Secure and
Reliable Transport for HTTP/2", draft-tsvwg-quic- Reliable Transport for HTTP/2", draft-tsvwg-quic-
protocol-01 (work in progress), July 2015. protocol-01 (work in progress), July 2015.
[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,
<http://www.rfc-editor.org/info/rfc1918>. <http://www.rfc-editor.org/info/rfc1918>.
[RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6
(IPv6) Specification", RFC 2460, DOI 10.17487/RFC2460,
December 1998, <http://www.rfc-editor.org/info/rfc2460>.
[RFC2993] Hain, T., "Architectural Implications of NAT", RFC 2993, [RFC2993] Hain, T., "Architectural Implications of NAT", RFC 2993,
DOI 10.17487/RFC2993, November 2000, DOI 10.17487/RFC2993, November 2000,
<http://www.rfc-editor.org/info/rfc2993>. <http://www.rfc-editor.org/info/rfc2993>.
[RFC3315] Droms, R., Ed., Bound, J., Volz, B., Lemon, T., Perkins, [RFC3315] Droms, R., Ed., Bound, J., Volz, B., Lemon, T., Perkins,
C., and M. Carney, "Dynamic Host Configuration Protocol C., and M. Carney, "Dynamic Host Configuration Protocol
for IPv6 (DHCPv6)", RFC 3315, DOI 10.17487/RFC3315, July for IPv6 (DHCPv6)", RFC 3315, DOI 10.17487/RFC3315, July
2003, <http://www.rfc-editor.org/info/rfc3315>. 2003, <http://www.rfc-editor.org/info/rfc3315>.
[RFC3633] Troan, O. and R. Droms, "IPv6 Prefix Options for Dynamic [RFC3633] Troan, O. and R. Droms, "IPv6 Prefix Options for Dynamic
 End of changes. 25 change blocks. 
36 lines changed or deleted 43 lines changed or added

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