draft-ietf-v6ops-host-addr-availability-07.txt   rfc7934.txt 
IPv6 Operations L. Colitti Internet Engineering Task Force (IETF) L. Colitti
Internet-Draft V. Cerf Request for Comments: 7934 V. Cerf
Intended status: Best Current Practice Google BCP: 204 Google
Expires: November 26, 2016 S. Cheshire Category: Best Current Practice S. Cheshire
D. Schinazi ISSN: 2070-1721 D. Schinazi
Apple Inc. Apple Inc.
May 25, 2016 July 2016
Host address availability recommendations Host Address Availability Recommendations
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 it
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 memo documents an Internet Best Current Practice.
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 This document is a product of the Internet Engineering Task Force
and may be updated, replaced, or obsoleted by other documents at any (IETF). It represents the consensus of the IETF community. It has
time. It is inappropriate to use Internet-Drafts as reference received public review and has been approved for publication by the
material or to cite them other than as "work in progress." Internet Engineering Steering Group (IESG). Further information on
BCPs is available in Section 2 of RFC 7841.
This Internet-Draft will expire on November 26, 2016. Information about the current status of this document, any errata,
and how to provide feedback on it may be obtained at
http://www.rfc-editor.org/info/rfc7934.
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
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 providing multiple addresses . . . . . . . . . . 3 3. Benefits of Providing Multiple Addresses . . . . . . . . . . 3
4. Problems with restricting the number of addresses per host . 4 4. Problems with Restricting the Number of Addresses per Host . 4
5. Overcoming limits using Network Address Translation . . . . . 5 5. Overcoming Limits Using Network Address Translation . . . . . 5
6. Options for providing 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 . . . . . . . . . . . . . . . . 8
8. Recommendations . . . . . . . . . . . . . . . . . . . . . . . 8 8. Recommendations . . . . . . . . . . . . . . . . . . . . . . . 8
9. Operational considerations . . . . . . . . . . . . . . . . . 8 9. Operational Considerations . . . . . . . . . . . . . . . . . 9
9.1. Host tracking . . . . . . . . . . . . . . . . . . . . . . 8 9.1. Host Tracking . . . . . . . . . . . . . . . . . . . . . . 9
9.2. Address space management . . . . . . . . . . . . . . . . 9 9.2. Address Space Management . . . . . . . . . . . . . . . . 10
9.3. Addressing link layer scalability issues via IP routing . 10 9.3. Addressing Link-Layer Scalability Issues via IP Routing . 10
10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 11 10. Security Considerations . . . . . . . . . . . . . . . . . . . 11
11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 11
12. Security Considerations . . . . . . . . . . . . . . . . . . . 11 11.1. Normative References . . . . . . . . . . . . . . . . . . 11
13. References . . . . . . . . . . . . . . . . . . . . . . . . . 11 11.2. Informative References . . . . . . . . . . . . . . . . . 11
13.1. Normative References . . . . . . . . . . . . . . . . . . 11 Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 14
13.2. Informative References . . . . . . . . . . . . . . . . . 11 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 15
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 14
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 design and operation of dual-stack networks. However, in some design and
operational areas it can lead to carrying over IPv4 practices that operational areas, it can lead to carrying over IPv4 practices that
are limiting or not appropriate in IPv6 due to differences between are limiting or not appropriate in IPv6 due to differences between
the protocols. 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, a single link provides addresses are not a scarce resource. In IPv6, a single link provides
over four billion times more address space than the whole IPv4 over four billion times more address space than the whole IPv4
Internet [RFC7421]. Thus, unlike IPv4, IPv6 networks are not forced Internet [RFC7421]. Thus, unlike IPv4, IPv6 networks are not forced
by address availability considerations to provide only one address by address scarcity concerns to provide only one address per host.
per host. On the other hand, providing multiple addresses has many Furthermore, providing multiple addresses has many benefits,
benefits including application functionality and simplicity, privacy, including application functionality and simplicity, privacy, and
flexibility to accommodate future applications, and the ability to flexibility to accommodate future applications. Another significant
provide Internet access without the use of NAT. Providing only one benefit is the ability to provide Internet access without the use of
IPv6 address per host negates these benefits. Network Address Translation (NAT). Providing only one IPv6 address
per host negates these benefits.
This document describes the benefits of providing multiple addresses This document details 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. 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 (see Section 2.1 of [RFC4291] and
section 5.9.4). Today, many general-purpose IPv6 hosts are Section 5.9.4 of [RFC6434]). Today, many general-purpose IPv6 hosts
configured with three or more addresses per interface: a link-local are configured with three or more addresses per interface: a link-
address, a stable address (e.g., using EUI-64 or Opaque Interface local address, a stable address (e.g., using 64-bit Extended Unique
Identifiers [RFC7217]), one or more privacy addresses [RFC4941], and Identifiers (EUI-64) or Opaque Interface Identifiers [RFC7217]), one
possibly one or more temporary or non-temporary addresses obtained or more privacy addresses [RFC4941], and possibly one or more
using DHCPv6 [RFC3315]. temporary or non-temporary addresses obtained using the Dynamic Host
Configuration Protocol for IPv6 (DHCPv6) [RFC3315].
In most general-purpose IPv6 networks, including all 3GPP networks In most general-purpose IPv6 networks, hosts have the ability to
([RFC6459] section 5.2) and Ethernet and Wi-Fi networks using SLAAC configure additional IPv6 addresses from the link prefix(es) without
[RFC4862], IPv6 hosts have the ability to configure additional IPv6 explicit requests to the network. Such networks include all 3GPP
addresses from the link prefix(es) without explicit requests to the networks ([RFC6459], Section 5.2), in addition to Ethernet and Wi-Fi
network. networks using Stateless Address Autoconfiguration (SLAAC) [RFC4862].
3. Benefits of providing 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, 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 the baseband
processor need to communicate with the network, particularly for processor need to communicate with the network, particularly for
technologies like I-WLAN [TS.24327] where the two processors share technologies like I-WLAN [TS.24327] where the two processors share
the Wi-Fi network connection. 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 (a
[RFC6877] that provide IPv4 over IPv6. Some of these technologies combination of stateful and stateless translation) [RFC6877] that
translate between IPv4 and 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).
o ILA ("Identifier-locator addressing") [I-D.herbert-nvo3-ila]. o Identifier-locator addressing (ILA) [ILA].
o Future applications (e.g., per-application IPv6 addresses [TARP]). o Future applications (e.g., per-application IPv6 addresses [TARP]).
Examples of how the availability of multiple addresses per host has Two examples of how the availability of multiple addresses per host
already allowed substantial deployment of new applications without has already allowed substantial deployment of new applications
explicit requests to the network are: without explicit requests to the network are:
o 464XLAT. 464XLAT is usually deployed within a particular network, o 464XLAT. 464XLAT is usually deployed within a particular network;
and in this model the operator can ensure that the network is in this model, the operator can ensure that the network is
appropriately configured to provide the CLAT with the additional appropriately configured to provide the customer-side translator
IPv6 address it needs to implement 464XLAT. However, there are (CLAT) with the additional IPv6 address it needs to implement
deployments where the PLAT (i.e., NAT64) is provided as a service 464XLAT. However, there are deployments where the provider-side
by a different network, without the knowledge or cooperation of translator (PLAT) (i.e., NAT64) is provided as a service by a
the residential ISP (e.g., the IPv6v4 Exchange Service different network, without the knowledge or cooperation of the
<http://www.jpix.ad.jp/en/service/ipv6v4.html>). This type of residential ISP (e.g., the IPv6v4 Exchange Service [IPv6v4]).
deployment is only possible because those residential ISPs provide This type of deployment is only possible because those residential
multiple IP addresses to their users, and thus those users can ISPs provide multiple IP addresses to their users, and thus those
freely obtain the extra IPv6 address required to run 464XLAT. users can 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 Prefix Delegation (PD), which is only
release 10 or above ([RFC6459] section 5.3). available in 3GPP 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 either will 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 will only be available after an explicit request to the network is
request to the network is granted. The necessity of explicit granted. Requiring explicit requests to the network has the
requests has the following drawbacks: 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. (SLA), must complete before the functionality is available.
o Uncertainty, because it is not known if a particular operation o Uncertainty, because it is not known if a particular application
function will be available until the provisioning operation function will be available until the provisioning operation
succeeds or fails. 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 that their networks be configured to limit
number of IPv6 addresses per host. Reasons might include hardware the number of IPv6 addresses per host. Reasons might include
limitations (e.g., TCAM or neighbor cache table size constraints), hardware limitations (e.g., Ternary Content-Addressable Memory (TCAM)
business models (e.g., a desire to charge the network's users on a size or size constraints of the Neighbor Cache table), business
per-device basis), or operational consistency with IPv4 (e.g., an IP models (e.g., a desire to charge the network's users on a per-device
address management system that only supports one address per host). basis), or operational consistency with IPv4 (e.g., an IP address
However, hardware limitations are expected to ease over time, and an management system that only supports one address per host). However,
attempt to generate additional revenue by charging per device may hardware limitations are expected to ease over time, and an attempt
prove counterproductive if customers respond (as they did with IPv4) to generate additional revenue by charging per device may prove
by using NAT, which results in no additional revenue, but leads to counterproductive if customers respond (as they did with IPv4) by
more operational problems and higher support costs. using NAT, which results in no additional revenue, but leads to more
operational problems and higher support costs.
5. Overcoming limits using Network Address Translation 5. Overcoming Limits Using Network Address Translation
These limits can mostly be overcome by end hosts by using NAT, and When the network limits the number of addresses available to a host,
indeed in IPv4 most of these functions are provided by using NAT on this can mostly be overcome by end hosts by using NAT, and indeed in
the host. Thus, the limits could be overcome in IPv6 as well by IPv4 the scarcity of addresses is often mitigated by using NAT on the
host. Thus, the limits could be overcome in IPv6 as well by
implementing NAT66 on the host. implementing NAT66 on the host.
Unfortunately NAT has well-known drawbacks. For example, it causes Unfortunately, NAT has well-known drawbacks. For example, it causes
application complexity due to the need to implement NAT traversal. application complexity due to the need to implement NAT traversal.
It hinders development of new applications. On mobile devices, it It hinders development of new applications. On mobile devices, it
reduces battery life due to the necessity of frequent keepalives, reduces battery life due to the necessity of frequent keepalives,
particularly for UDP. Applications using UDP that need to work on particularly for UDP. Applications using UDP that need to work on
most of the Internet are forced to send keepalives at least every 30 most of the Internet are forced to send keepalives at least every 30
seconds <http://www.ietf.org/proceedings/88/slides/slides-88-tsvarea- seconds [KA]. For example, the QUIC protocol uses a 15-second
10.pdf>. For example, the QUIC protocol uses a 15-second keepalive keepalive [QUIC]. Other drawbacks of NAT are well-known and
[I-D.tsvwg-quic-protocol]. Other drawbacks of NAT are well known and
documented [RFC2993]. While IPv4 NAT is inevitable due to the documented [RFC2993]. While IPv4 NAT is inevitable due to the
limited amount of IPv4 space available, that argument does not apply 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 to IPv6. Guidance from the Internet Architecture Board (IAB) is that
desirable [RFC5902]. deployment of IPv6 NAT is not desirable [RFC5902].
The desire to overcome the problems listed in Section 4 without The desire to overcome the problems listed in Section 4 without
disabling any features has resulted in developers implementing IPv6 disabling any features has resulted in developers implementing IPv6
NAT. There are fully-stateful address+port NAT66 implementations in NAT. There are fully stateful address+port NAT66 implementations in
client operating systems today: for example, Linux has supported client operating systems today: for example, Linux has supported
NAT66 since late 2012 <http://kernelnewbies.org/Linux_3.7#head- NAT66 since 2012 [L66]. At least one popular software hypervisor
103e14959eeb974bbd4e862df8afe7c118ba2beb>. A popular software also implemented NAT66 to work around these issues [V66]. Wide
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 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 provide 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
skipping to change at page 6, line 28 skipping to change at page 6, line 27
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 providing more than one address 6. Options for Providing More Than One Address
Multiple IPv6 addresses can be provided 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 (SLAAC) [RFC4862].
hosts to create global IPv6 addresses on demand by simply forming SLAAC allows hosts to create global IPv6 addresses on demand by
new addresses from the global prefix(es) assigned to the link. simply forming new addresses from the global prefix(es) assigned
Typically, SLAAC is used on shared links, but it is also possible to the link. Typically, SLAAC is used on shared links, but it is
to use SLAAC while providing a dedicated /64 prefix to each host. also possible to use SLAAC while providing a dedicated /64 prefix
This is the case, for example, if the host is connected via a to each host. This is the case, for example, if the host is
point-to-point link such as in 3GPP networks, on a network where connected via a point-to-point link such as in 3GPP networks, on a
each host has its own dedicated VLAN, or on a wireless network network where each host has its own dedicated VLAN, or on a
where every MAC address is placed in its own broadcast domain. wireless network where every Media Access Control (MAC) address is
placed in its own broadcast domain.
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 provide temporary addresses, and the server could choose to provide
multiple addresses. It is also technically possible for a client multiple addresses. It is also technically possible for a client
to request additional addresses using a different DUID, though the to request additional addresses using a different DHCP Unique
DHCPv6 specification implies that this is not expected behavior Identifier (DUID), though the DHCPv6 specification implies that
([RFC3315] section 9). The DHCPv6 server will decide whether to this is not expected behavior ([RFC3315], Section 9). The DHCPv6
grant or reject the request based on information about the client, server will decide whether to grant or reject the request based on
including its DUID, MAC address, and so on. The maximum number of information about the client, including its DUID, MAC address, and
IPv6 addresses that can be provided in a single DHCPv6 packet, more. The maximum number of IPv6 addresses that can be provided
given a typical MTU of 1500 bytes or smaller, is approximately 30. in a single DHCPv6 packet, given a typical MTU of 1500 bytes or
smaller, is approximately 30.
o DHCPv6 prefix delegation [RFC3633]. DHCPv6 PD allows the client o DHCPv6 Prefix Delegation (PD) [RFC3633]. DHCPv6 PD allows the
to request and be delegated a prefix, from which it can client 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 that 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, Neighbor Discovery (ND) proxying
[RFC7278], but it cannot be further subdivided, as a prefix longer [RFC4389], or /64 sharing [RFC7278], but it cannot be further
than /64 is outside the current IPv6 specifications [RFC7421]. subdivided, as a prefix longer than /64 is outside the current
While [RFC3633] assumes that the DHCPv6 client is a router, DHCPv6 IPv6 specifications [RFC7421]. While the DHCPv6 Prefix Delegation
PD itself does not require that the client forward IPv6 packets specification [RFC3633] assumes that the DHCPv6 client is a
not addressed to itself, and thus does not require that the client router, DHCPv6 PD itself does not require that the client forward
be an IPv6 router as defined in [RFC2460]. Also, in many cases IPv6 packets not addressed to itself, and thus does not require
(such as tethering, or hosting virtual machines), hosts are that the client be an IPv6 router as defined in the IPv6
already forwarding IPv6 packets and thus operating as IPv6 routers specification [RFC2460]. Also, in many cases (such as tethering,
as defined in [RFC2460]. or hosting virtual machines), hosts are already forwarding IPv6
packets and thus operating as IPv6 routers as defined in the IPv6
specification [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 | | | | |
| Uses stateful, request- | No | Yes | Yes | Yes | | Uses stateful, request- | No | Yes | Yes | Yes |
| based assignment | | | | | | based assignment | | | | |
| Is immune to layer 3 on- | No | Yes | Yes | Yes | | Is immune to Layer 3 on- | No | Yes | Yes | Yes |
| link resource exhaustion | | | | | | link resource exhaustion | | | | |
| attacks | | | | | | attacks | | | | |
+--------------------------+-------+-------------+--------+---------+ +--------------------------+-------+-------------+--------+---------+
[*] Subject to network limitations, e.g., ND cache entry size limits. [*] Subject to network limitations, e.g., ND cache entry size limits.
[+] Except on certain networks, e.g., [RFC7278]. [+] Except on certain networks, e.g., /64 sharing [RFC7278].
Table 1: Comparison of multiple address assignment options
7. Number of addresses required Table 1: Comparison of Multiple Address Assignment Options
If we itemize the use cases from section Section 3, we can estimate 7. Number of Addresses Required
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. If we itemize the use cases from Section 3, we can estimate the
Some devices require another address for their baseband chip. Even a number of addresses currently used in normal operations. In typical
host performing just a few of these functions simultaneously might implementations, privacy addresses use up to 7 addresses -- one per
need on the order of 20 addresses at the same time. Future day ([RFC4941], Section 3.5). Current mobile devices sharing an
applications designed to use an address per application or even per uplink connection may typically support 8 downstream client devices,
resource will require many more. These will not function on networks with each one requiring one or more addresses. A client might choose
that enforce a hard limit on the number of addresses provided to to run several virtual machines. Current implementations of 464XLAT
hosts. Thus, in general is is not possible to estimate in advance require the use of a separate address. Some devices require another
how many addresses are required. 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. Thus, in general it 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 NOT RECOMMENDED to 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 4), it is RECOMMENDED that the network
network give the host the ability to use new addresses without give the host the ability to use new addresses without requiring
requiring explicit requests. This can be achieved either by allowing explicit requests. This can be achieved either by allowing the host
the host to form new addresses autonomously (e.g., via SLAAC), or by to form new addresses autonomously (e.g., via SLAAC) or by providing
providing the host with a dedicated /64 prefix. The prefix MAY be the host with a dedicated /64 prefix. The prefix MAY be provided
provided using DHCPv6 PD, SLAAC with per-device VLANs, or any other using DHCPv6 PD, SLAAC with per-device VLANs, or any other means.
means.
Using stateful address assignment (DHCPv6 IA_NA or IA_TA) to provide Using stateful address assignment (DHCPv6 IA_NA or IA_TA) to provide
multiple addresses when the host connects (e.g. the approximately 30 multiple addresses when the host connects (e.g., the approximately 30
addresses that can fit into a single packet) would accommodate addresses that can fit into a single packet) would accommodate
current clients, but sets a limit on the number of addresses current clients, but it sets a limit on the number of addresses
available to hosts when they attach and would limit the development available to hosts when they attach and therefore limits the
of future applications. development of future applications.
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 attribute liability for copyright addresses may be used to attribute liability for copyright
infringement 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 the IPv6 neighbor table: routers
allow periodic dumps of the neighbor cache via SNMP or other means, typically allow periodic dumps of the Neighbor Cache via the Simple
and many can be configured to log every change to the neighbor cache. Network Management Protocol (SNMP) or other means, and many can be
Using SLAAC with a dedicated /64 prefix simplifies tracking, as it configured to log every change to the Neighbor Cache. Using SLAAC
does not require logging each address formed by the host, but only with a dedicated /64 prefix for each host simplifies tracking, as it
does not require logging every 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
tracking properties as DHCPv6 address assignment, but allows the tracking properties as DHCPv6 address assignment, but allows the
network to provide unrestricted address space. network to provide unrestricted address space.
Many large enterprise networks are fully dual-stack and implement Many large enterprise networks are fully dual stack and implement
address monitoring without using or supporting DHCPv6. The authors address monitoring without using or supporting DHCPv6. The authors
are directly aware of several networks that operate in this way, are directly aware of several networks that operate in this way,
including the Universities of Loughborough, Minnesota, Reading, including the Universities of Loughborough, Minnesota, Reading,
Southampton, Wisconsin and Imperial College London, in addition to Southampton, and Wisconsin, and Imperial College London, in addition
the enterprise networks of the authors' employers. to the enterprise networks of the authors' employers.
It should also be noted that using DHCPv6 address assignment does not It should also be noted that using DHCPv6 address assignment does not
ensure that the network can reliably track the IPv6 addresses used by ensure that the network can reliably track the IPv6 addresses used by
hosts. On any shared network without L2 edge port security, hosts hosts. On any shared network without Layer 2 (L2) edge port
are able to choose their own addresses regardless of what address security, hosts are able to choose their own addresses regardless of
provisioning methodology is in use. The only way to restrict the what address provisioning methodology the network operator believes
addresses used by hosts is to use layer 2 security mechanisms that is in use. The only way to restrict the addresses used by hosts is
enforce that particular IPv6 addresses are used by particular link- to use L2 security mechanisms that enforce that particular IPv6
layer addresses (for example, SAVI [RFC7039]). If those mechanisms addresses are used by particular link-layer addresses (for example,
are available, it is possible to use them to provide tracking; this Source Address Validation Improvement (SAVI) [RFC7039]). If those
form of tracking is more secure and reliable than server logs because mechanisms are available, it is possible to use them to provide
it operates independently of how addresses are allocated. Finally, tracking; this form of tracking is more secure and reliable than
tracking address information via DHCPv6 server logs is likely to server logs because it operates independently of how addresses are
become decreasingly viable due to ongoing efforts to improve the allocated. Finally, tracking address information via DHCPv6 server
privacy of DHCPv6 and MAC address randomization [RFC7844]. logs is likely to become decreasingly viable due to ongoing efforts
to improve the 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 65
addresses. In IPv6, that is equivalent to a /48, with each of 64k thousand addresses. In IPv6, that is equivalent to a /48, with each
hosts receiving a /64 prefix. Under current RIR policies, a /48 is host receiving a /64 prefix. Under current Regional Internet
easy to obtain for an enterprise network. Networks that need a Registry (RIR) policies, a /48 is easy to obtain for an enterprise
bigger block of private space use 10.0.0.0/8, which has roughly 16 network. Networks that need a bigger block of private space use
million addresses. In IPv6, that is equivalent to a /40, with each 10.0.0.0/8, which has roughly 16 million addresses. In IPv6, that is
host receiving /64 prefix. Enterprises of such size can easily equivalent to a /40, with each host receiving a /64 prefix.
obtain a /40 under current RIR policies. Enterprises of such size can easily obtain a /40 under current RIR
policies.
In the above cases, aggregation and routing can be equivalent to In the above cases, aggregation and routing can be equivalent to
IPv4: if a network aggregates per-host IPv4 addresses into prefixes IPv4: if a network aggregates per-host IPv4 addresses into prefixes
of length /32 - n, it can aggregate per-host /64 prefixes into the of length /32 - n, it can aggregate per-host /64 prefixes into the
same number of prefixes of length /64 - n. same number of prefixes of length /64 - n.
Currently, residential users typically receive one IPv4 address and a Currently, residential users typically receive one IPv4 address and a
/48, /56 or /60 IPv6 prefix. While such networks do not provide /48, /56, or /60 IPv6 prefix. While such networks do not provide
enough space to assign a /64 per host, such networks almost enough space to assign a /64 per host, such networks almost
universally use SLAAC, and thus do not pose any particular limit to universally use SLAAC, and thus do not pose any particular limit to
the number of addresses hosts can use. the number of addresses hosts can use.
Unlike IPv4 where addresses came at a premium, in all these networks, Unlike IPv4 where addresses came at a premium, in all of these
there is enough IPv6 address space to supply clients with multiple networks there is enough IPv6 address space to supply clients with
IPv6 addresses. multiple IPv6 addresses.
9.3. Addressing link layer scalability issues via IP routing 9.3. Addressing Link-Layer Scalability Issues via IP Routing
The number of IPv6 addresses on a link has direct impact for The number of IPv6 addresses on a link has a direct impact on
networking infrastructure nodes (routers, switches) and other nodes networking infrastructure nodes (routers, switches) and other nodes
on the link. Setting aside exhaustion attacks via Layer 2 address on the link. Setting aside exhaustion attacks via L2 address
spoofing, every (Layer 2, IP) address pair impacts networking spoofing, every (L2, IP) address pair impacts networking hardware
hardware requirements in terms of memory, MLD snooping, solicited requirements in terms of memory, Multicast Listener Discovery (MLD)
node multicast groups, etc. Many of these costs are incurred by snooping, solicited node multicast groups, etc. Many of these costs
neighboring hosts. are incurred by 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. of-service protection mechanisms.
We expect these scaling limitations to change over time as hardware We expect these scaling limitations to change over time as hardware
and applications evolve. However, switching to a dedicated /64 and applications evolve. However, switching to a dedicated /64
prefix per host can resolve these scaling limitations. If the prefix 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 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 link-layer address (e.g., if the link layer uniquely identifies or
authenticates hosts based on MAC addresses), then there will be only authenticates hosts based on MAC addresses), then there will be only
one routing entry and one ND cache entry per host on the network. 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., 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 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 the host to assign IPv6 addresses from this prefix to an internal
interface such as a loopback interface. This obviates the need to virtual interface such as a loopback interface. This obviates the
perform Neighbor Discovery and Duplicate Address Detection on the need to perform Neighbor Discovery and Duplicate Address Detection on
network interface for these addresses, reducing network traffic. the network interface for these addresses, reducing network traffic.
Thus, assigning a dedicated /64 prefix per host is operationally Thus, assigning a dedicated /64 prefix per host is operationally
prudent. Clearly, however, it requires more IPv6 address space than prudent. Clearly, however, it requires more IPv6 address space than
using shared links, so the benefits provided must be weighed with the using shared links, so the benefits provided must be weighed with the
operational overhead of address space management. operational overhead of address space management.
10. Acknowledgements 10. Security Considerations
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.
11. IANA Considerations
This memo includes no request to IANA.
12. Security Considerations
As mentioned in section 9.3, on shared networks using SLAAC it is As mentioned in Section 9.3, on shared networks using SLAAC, it is
possible for hosts to attempt to exhaust network resources and possible for hosts to attempt to exhaust network resources and
possibly deny service to other hosts by creating unreasonable numbers possibly deny service to other hosts by creating unreasonable numbers
(e.g., hundreds or thousands) of addresses. Networks that provide (e.g., hundreds or thousands) of addresses. Networks that provide
access to untrusted hosts can mitigate this threat by providing a access to untrusted hosts can mitigate this threat by providing a
dedicated /64 prefix per host. It is also possible to mitigate the 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 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 for a particular host, but care must be taken to ensure that the
network does not restrict the IP addresses available to non-malicious network does not prevent the legitimate use of multiple IP addresses
hosts. by non-malicious hosts.
Security issues related to host tracking are discussed in section Security issues related to host tracking are discussed in
9.1. Section 9.1.
13. References 11. References
13.1. Normative References 11.1. Normative References
[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 11.2. Informative References
[I-D.herbert-nvo3-ila] [ILA] Herbert, T., "Identifier-locator addressing for network
Herbert, T., "Identifier-locator addressing for network virtualization", Work in Progress, draft-herbert-nvo3-
virtualization", draft-herbert-nvo3-ila-02 (work in ila-02, March 2016.
progress), March 2016.
[I-D.tsvwg-quic-protocol] [IPv6v4] Japan Internet Exchange, "IPv6v4 Exchange Service", April
Hamilton, R., Iyengar, J., Swett, I., and A. Wilk, "QUIC: 2013, <http://www.jpix.ad.jp/en/service/ipv6v4.html>.
[KA] Roskind, J., "Quick UDP Internet Connections", November
2013, <http://www.ietf.org/proceedings/88/slides/
slides-88-tsvarea-10.pdf>.
[L66] McHardy, P., "netfilter: ipv6: add IPv6 NAT support",
Linux commit 58a317f1061c894d2344c0b6a18ab4a64b69b815,
August 2012, <https://git.kernel.org/cgit/linux/kernel/
git/torvalds/linux.git/commit/
?id=58a317f1061c894d2344c0b6a18ab4a64b69b815>.
[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 Work in Progress, draft-tsvwg-quic-protocol-02, 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,
<http://www.rfc-editor.org/info/rfc1918>. <http://www.rfc-editor.org/info/rfc1918>.
[RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6 [RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6
(IPv6) Specification", RFC 2460, DOI 10.17487/RFC2460, (IPv6) Specification", RFC 2460, DOI 10.17487/RFC2460,
December 1998, <http://www.rfc-editor.org/info/rfc2460>. December 1998, <http://www.rfc-editor.org/info/rfc2460>.
skipping to change at page 14, line 5 skipping to change at page 14, line 16
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 [RFC7844] Huitema, C., Mrugalski, T., and S. Krishnan, "Anonymity
Profiles for DHCP Clients", RFC 7844, Profiles for DHCP Clients", RFC 7844,
DOI 10.17487/RFC7844, May 2016, DOI 10.17487/RFC7844, May 2016,
<http://www.rfc-editor.org/info/rfc7844>. <http://www.rfc-editor.org/info/rfc7844>.
[TARP] Gleitz, PM. and SM. Bellovin, "Transient Addressing for [TARP] Gleitz, PM. and SB. 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", In Proceedings of the
Eleventh Usenix Security Symposium, August 2001,
<https://www.usenix.org/legacy/events/sec01/gleitz.html>.
[TS.24327] [TS.24327] 3GPP, "Mobility between 3GPP Wireless Local Area Network
3GPP, "Mobility between 3GPP Wireless Local Area Network
(WLAN) interworking (I-WLAN) and 3GPP systems; General (WLAN) interworking (I-WLAN) and 3GPP systems; General
Packet Radio System (GPRS) and 3GPP I-WLAN aspects; Stage Packet Radio System (GPRS) and 3GPP I-WLAN aspects; Stage
3", June 2011. 3", 3GPP TS 24.327, June 2011,
<http://www.3gpp.org/DynaReport/24327.htm>.
[V66] Oracle, "What's New in VirtualBox 4.3?", October 2013,
<https://blogs.oracle.com/fatbloke/entry/
what_s_new_in_virtualbox>.
Acknowledgements
The authors thank Tore Anderson, Brian Carpenter, David Farmer,
Wesley George, Geoff Huston, Erik Kline, Victor Kuarsingh, Shucheng
(Will) Liu, Shin Miyakawa, Dieter Siegmund, Mark Smith, Sander
Steffann, Fred Templin, and James Woodyatt for their input and
contributions.
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 Japan
Email: lorenzo@google.com Email: lorenzo@google.com
Vint Cerf Vint Cerf
Google Google
1875 Explorer St 1875 Explorer Street
10th Floor 10th Floor
Reston, VA 20190 Reston, VA 20190
US United States of America
Email: vint@google.com Email: vint@google.com
Stuart Cheshire Stuart Cheshire
Apple Inc. Apple Inc.
1 Infinite Loop 1 Infinite Loop
Cupertino, CA 95014 Cupertino, CA 95014
US United States of America
Email: cheshire@apple.com Email: cheshire@apple.com
David Schinazi David Schinazi
Apple Inc. Apple Inc.
1 Infinite Loop 1 Infinite Loop
Cupertino, CA 95014 Cupertino, CA 95014
US United States of America
Email: dschinazi@apple.com Email: dschinazi@apple.com
 End of changes. 86 change blocks. 
264 lines changed or deleted 282 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/