draft-ietf-v6ops-host-addr-availability-00.txt   draft-ietf-v6ops-host-addr-availability-01.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: February 1, 2016 S. Cheshire Expires: March 6, 2016 S. Cheshire
D. Schinazi D. Schinazi
Apple Inc. Apple Inc.
July 31, 2015 September 3, 2015
Host address availability recommendations Host address availability recommendations
draft-ietf-v6ops-host-addr-availability-00 draft-ietf-v6ops-host-addr-availability-01
Abstract Abstract
This document recommends that networks provide general-purpose end This document recommends that networks provide general-purpose end
hosts with multiple global addresses when they attach, and describes hosts with multiple global addresses when they attach, and describes
the benefits of and the options for doing so. 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 February 1, 2016. This Internet-Draft will expire on March 6, 2016.
Copyright Notice Copyright Notice
Copyright (c) 2015 IETF Trust and the persons identified as the Copyright (c) 2015 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 2, line 13 skipping to change at page 2, line 13
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 multiple addresses . . . . . . . . . . . . . . . 3
4. Problems with assigning a limited number of addresses per 4. Problems with assigning a restricted 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 obtaining 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 . . . . . . . . . . . . . . . . . 7 9. Operational considerations . . . . . . . . . . . . . . . . . 8
9.1. Stateful addressing and host tracking . . . . . . . . . . 7 9.1. Stateful addressing and host tracking . . . . . . . . . . 8
9.2. Address space management . . . . . . . . . . . . . . . . 8 9.2. Address space management . . . . . . . . . . . . . . . . 9
9.3. Addressing link layer scalability issues via IP routing . 8 9.3. Addressing link layer scalability issues via IP routing . 9
10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 9 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 9
11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9
12. Security Considerations . . . . . . . . . . . . . . . . . . . 9 12. Security Considerations . . . . . . . . . . . . . . . . . . . 10
13. References . . . . . . . . . . . . . . . . . . . . . . . . . 9 13. References . . . . . . . . . . . . . . . . . . . . . . . . . 10
13.1. Normative References . . . . . . . . . . . . . . . . . . 9 13.1. Normative References . . . . . . . . . . . . . . . . . . 10
13.2. Informative References . . . . . . . . . . . . . . . . . 9 13.2. Informative References . . . . . . . . . . . . . . . . . 10
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 11 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 12
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 adressing, 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 assign only one address per host. On the other
hand, assigning multiple addresses has many benefits including hand, assigning 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. Assigning 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 assigning 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.
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", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
document are to be interpreted as described in RFC 2119 [RFC2119]. "OPTIONAL" in this document are to be interpreted as described in
"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 [RFC7217]), one or address, a stable address (e.g., using EUI-64 or Opaque Interface
more privacy addresses [RFC4941], and possibly one or more temporary Identifiers [RFC7217]), one or more privacy addresses [RFC4941], and
or non-temporary addresses assigned using DHCPv6 [RFC3315]. possibly one or more temporary or non-temporary addresses assigned
using DHCPv6 [RFC3315].
In most general-purpose IPv6 networks, including all 3GPP networks In most general-purpose IPv6 networks, including all 3GPP networks
(see [RFC6459] section 5.2) and Ethernet and Wi-Fi networks using ([RFC6459] section 5.2) and Ethernet and Wi-Fi networks using SLAAC
SLAAC [RFC4862], IPv6 hosts have the ability to configure additional [RFC4862], IPv6 hosts have the ability to configure additional IPv6
IPv6 addresses from the link prefix(es) without explicit requests to addresses from the link prefix(es) without explicit requests to the
the network. network.
3. Benefits of multiple addresses 3. Benefits of 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 (e.g., 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. recent technologies like ePDG.
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 that o Translation-based transition technologies such as 464XLAT
provide IPv4 over IPv6. Current implementations require the [RFC6877] that provide IPv4 over IPv6. Some of these require the
availability of a dedicated IPv6 address in order to determine availability of a dedicated IPv6 address in order to determine
whether inbound packets are translated or native. whether inbound packets are translated or native ([RFC6877]
section 6.3).
o ILA ("Identifier-locator addressing"): o ILA ("Identifier-locator addressing") [I-D.herbert-nvo3-ila].
https://tools.ietf.org/html/draft-herbert-nvo3-ila
o Future applications (e.g., per-application IPv6 addresses, such as o Future applications (e.g., per-application IPv6 addresses [TARP]).
described in [TARP]).
Example of how the availability of multiple addresses per host has Examples of how the availability of multiple addresses per host has
already allowed substantial deployment of new applications without already allowed substantial deployment of new applications without
explicit requests to the network are: explicit requests to the network are:
o 464XLAT [RFC6877]. 464XLAT is usually deployed within a particular o 464XLAT. 464XLAT is usually deployed within a particular network,
network operator's network, but there are deployment models where and in this model the operator can ensure that the network is
the PLAT is provided as a service by a different network (e.g., appropriately configured to provide the CLAT with the additional
<http://www.jpix.ad.jp/en/service/ipv6v4.html>) IPv6 address it needs to implement 464XLAT. However, there are
deployments where the PLAT (i.e., NAT64) is provided as a service
by a different network, without the knowledge or cooperation of
the residential ISP (e.g., the IPv6v4 Exchange Service
<http://www.jpix.ad.jp/en/service/ipv6v4.html>). This type of
deployment is only possible because those residential ISPs provide
multiple IP addresses to their users, and thus those users can
freely obtain the extra IPv6 address required to run 464XLAT.
o /64 sharing [RFC7278]. This was a way to provide IPv6 tethering o /64 sharing [RFC7278]. When the topology supports it, this is a
without needing to wait for network operators to deploy DHCPv6 PD, way to provide IPv6 tethering without needing to wait for network
which is only available in 3GPP release 10. operators to deploy DHCPv6 PD, which is only available in 3GPP
release 10 ([RFC6459] section 5.3).
4. Problems with assigning a limited number of addresses per host 4. Problems with assigning a restricted number of addresses per host
Assigning a limited number of addresses per host implies that Assigning 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 5, line 7 skipping to change at page 5, line 13
operation function will be available. operation function will be available.
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 neighbour cache table size constraints), limitations (e.g., TCAM or neighbor cache table size constraints),
operational consistency with IPv4 (e.g., an IP address management business models (e.g., a desire to charge the network's users on a
system that only supports one address per host), or business models per-device basis), or operational consistency with IPv4 (e.g., an IP
(e.g., a desire to charge the network's users on a per-device basis). address management system that only supports one address per host).
However, hardware limitations are expected to ease over time, and an
attempt to generate additional revenue by charging per device may
prove counterproductive if customers respond (as they did with IPv4)
by 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 These limits can mostly be overcome by end hosts by using NAT, and
indeed in IPv4 most of these functions are provided by using NAT on indeed in IPv4 most of these functions are provided by using NAT on
the host. Thus, the limits could be overcome in IPv6 as well by 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 <http://www.ietf.org/proceedings/88/slides/slides-88-tsvarea-
10.pdf>. For example, the QUIC protocol uses a 15-second keepalive 10.pdf>. For example, the QUIC protocol uses a 15-second keepalive
[I-D.tsvwg-quic-protocol]. Other drawbacks are described in [I-D.tsvwg-quic-protocol]. Other drawbacks of NAT are well known and
[RFC2993]. While IPv4 NAT is inevitable due to the limited amount of documented [RFC2993]. While IPv4 NAT is inevitable due to the
IPv4 space available, that argument does not apply to IPv6. Guidance limited amount of IPv4 space available, that argument does not apply
from the IAB is that deployment of IPv6 NAT is not desirable to IPv6. Guidance from the IAB is that deployment of IPv6 NAT is not
[RFC5902]. desirable [RFC5902].
If networks that provide limited amount of addresses become widely The desire to overcome the problems listed in Section 4 without
deployed, then the desire to overcome the problems listed in disabling any features has resulted in developers implementing IPv6
Section 4 without disabling any features may result in operating NAT. There are fully-stateful address+port NAT66 implementations in
system manufacturers implementing IPv6 NAT. client operating systems today: for example, Linux has supported
NAT66 since late 2012 <http://kernelnewbies.org/Linux_3.7#head-
103e14959eeb974bbd4e862df8afe7c118ba2beb>. A popular software
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
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 assign 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 limited not by the planet with end-to-end connectivity that is constrained not by
technical factors but only by security policies. accidental technical limitations, but only by intentional security
policies.
6. Options for obtaining more than one address 6. Options for obtaining more than one address
Multiple IPv6 addresses can be obtained in the following ways: Multiple IPv6 addresses can be obtained 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 assign the
client multiple addresses. It is also possible for a client to client multiple addresses. It is also technically possible for a
request additional addresses using a different DUID. The DHCPv6 client to request additional addresses using a different DUID,
server will decide whether to grant or reject the request based on though the DHCPv6 specification implies that this is not expected
information about the client, including its DUID, MAC address, and behavior ([RFC3315] section 9). The DHCPv6 server will decide
so on. whether to grant or reject the request based on information about
the client, 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. The prefix can also be autonomously form other addresses. The prefix can also be
hierarchically delegated to downstream clients, or, if it is a hierarchically delegated to downstream clients, or, if it is a
/64, it be reshared with downstream clients via ND proxying /64, it can be reshared with downstream clients via L2 bridging,
[RFC4389] or /64 sharing [RFC7278]. ND proxying [RFC4389] or /64 sharing [RFC7278].
+------------------------+---------+------------+---------+---------+ +--------------------------+-------+-------------+--------+---------+
| | SLAAC | DHCPv6 | DHCPv6 | DHCPv4 | | | SLAAC | DHCPv6 | DHCPv6 | DHCPv4 |
| | | IA_NA / | PD | | | | | IA_NA / | PD | |
| | | IA_TA | | | | | | IA_TA | | |
+------------------------+---------+------------+---------+---------+ +--------------------------+-------+-------------+--------+---------+
| Autonomously form | Yes | No | Yes | Yes | | Extend network | Yes | No | Yes | Yes |
| addresses | (/64 | | (/64 | (NAT44) | | | | | | (NAT44) |
| | share) | | share) | | | "Unlimited" endpoints | Yes* | Yes* | No | No |
| "Unlimited" endpoints | Yes* | Yes* | No | No | | Stateful, request-based | No | Yes | Yes | Yes |
| Stateful, request- | No | Yes | Yes | Yes | | Immune to layer 3 on- | No | Yes | Yes | Yes |
| based | | | | | | link resource exhaustion | | | | |
| Immune to layer 3 on- | No | Yes | Yes | Yes | | attacks | | | | |
| link resource | | | | | +--------------------------+-------+-------------+--------+---------+
| exhaustion attacks | | | | |
+------------------------+---------+------------+---------+---------+
[*] Subject to network limitations, e.g., ND cache entry size limits. [*] Subject to network limitations, e.g., ND cache entry size limits.
Table 1: Comparison of multiple address assigment 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 (one typical implementations, privacy addresses use up to 8 addresses -
per day). Current mobile devices may typically support 8 clients, one per day ([RFC4941] section 3.5). Current mobile devices may
with each one requiring one or more addresses. A client might choose typically support 8 clients, with each one requiring one or more
to run several virtual machines. Current implementations of 464XLAT addresses. A client might choose to run several virtual machines.
require use of a separate address. Some devices require another Current implementations of 464XLAT require use of a separate address.
address for their baseband chip. Even a host performing only several Some devices require another address for their baseband chip. Even a
of these functions simultaneously might need on the order of 20 host performing just a few of these functions simultaneously might
addresses at the same time. Future applications designed to use an need on the order of 20 addresses at the same time. Future
address per application or even per resource will require many more. applications designed to use an address per application or even per
These will not function on networks that enforce a hard limit on the resource will require many more. These will not function on networks
number of addresses provided to hosts. that enforce a hard limit on the number of addresses provided to
hosts.
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
when they connect to the network. To support future use cases, it is when they connect to the network. To support future use cases, it is
RECOMMENDED to not impose a hard limit on the size of the address RECOMMENDED to not impose a hard limit on the size of the address
pool assigned to a host. If the network requires explicit requests pool assigned to a host. If the network requires explicit requests
for address space, a /64 prefix is desirable. Using DHCPv6 IA_NA or for address space (e.g., if it requires DHCPv6 to connect), it is
IA_TA to request a sufficient number of addresses (e.g. 32) would RECOMMENDED that the network assign a /64 prefix to every host (e.g.,
accomodate current clients but sets a limit on the number of via DHCPv6 PD). Using DHCPv6 IA_NA or IA_TA to request a sufficient
addresses available to hosts when they attach and would limit the number of addresses (e.g. 32) would accommodate current clients but
development of future applications. sets a limit on the number of addresses available to hosts when they
attach and would limit the development of future applications.
Assigning prefixes smaller than a /64 will limit the flexibility of
the host to further assign addresses to any internal functions,
virtual machines, or downstream clients that require address space -
for example, by not allowing the use of SLAAC.
9. Operational considerations 9. Operational considerations
9.1. Stateful addressing and host tracking 9.1. Stateful addressing and 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 - have services to third parties such as university campus networks - are
made the argument that the only feasible IPv6 deployment mechanism is required to track which IP addresses are assigned to which hosts on
DHCPv6, due to the need to be able to track at all times IPv6 their network. Maintaining persistent logs that map user IP
addresses are assigned to which hosts. (Example: addresses and timestamps to hardware identifiers such as MAC
<https://code.google.com/p/android/issues/detail?id=32621#c60> ). addresses may be used to avoid liability for copyright infringement
One reason frequently cited for this is protection from liability for or other illegal activity.
copyright infringement or other illegal activity by maintaining
persistent logs that map user IP addresses and timestamps to hardware
identifiers such as MAC addresses.
It is worth noting that using DHCPv6 does not by itself ensure that It is worth noting that this requirement can be met without using
hosts will actually use the addresses assigned to them by the network stateful addressing mechanisms such as DHCPv6. For example, it is
as opposed to using any other address on the prefix. Such guarantees possible to maintain these mappings by scraping IPv6 neighbor tables,
can only be provided by link-layer security mechanisms that enforce as routers typically allow periodic dumps of the neighbor cache via
that particular IPv6 addresses are used by particular link-layer SNMP or other means, and many can be configured to log every change
addresses (for example: SAVI [RFC7039]). If those mechanisms are to the neighbor cache.
available, it is possible to use them to provide tracking, instead.
This form of tracking is much more reliable because it operates
independently of how addresses are allocated.
Additionally, attempts to track this sort of information via DHCPv6 It is also worth noting that without L2 edge port security, hosts are
are likely to become decreasingly viable due to ongoing efforts to still able to choose their own addresses - DHCPv6 does not offer any
improve the privacy of DHCP: [I-D.ietf-dhc-anonymity-profile]. enforcement of what addresses a host is allowed to use. Such
guarantees can only be provided by link-layer security mechanisms
that enforce that particular IPv6 addresses are used by particular
link-layer addresses (for example, SAVI [RFC7039]). If those
mechanisms are available, it is possible to use them to provide
tracking. This form of tracking is much more secure and reliable
than DHCP server logs because it operates independently of how
addresses are allocated. Additionally, attempts to track this sort
of information via DHCPv6 are likely to become decreasingly viable
due to ongoing efforts to improve the privacy of DHCP
[I-D.ietf-dhc-anonymity-profile].
Many large enterprise networks, including the enterprise networks of Thus, host tracking does not necessarily require the use of stateful
the authors, are fully dual-stack but do not currently use or support address assignment mechanisms such as DHCPv6. Indeed, many large
DHCPv6. enterprise networks, including the enterprise networks of the
authors, are fully dual-stack but do not currently use or support
DHCPv6. Many large universities also successfully use IPv6 neighbor
table logs or dumps to ensure host tracking.
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], and with each host receiving one IPv4 private space [RFC1918], and with each host receiving one IPv4
address. Many networks can be numbered in 192.168.0.0/16 which has address. Many networks can be numbered in 192.168.0.0/16 which has
roughly 64k addresses. In IPv6, that is equivalent to assigning one roughly 64k addresses. In IPv6, that is equivalent to assigning one
/64 per host out of a /48. Under current RIR policies, a /48 is easy /64 per host out of a /48. Under current RIR policies, a /48 is easy
to obtain for an enterprise network. to obtain for an enterprise network.
Networks that need a bigger block of private space use 10.0.0.0/8, Networks that need a bigger block of private space use 10.0.0.0/8,
which is is roughly 16 million addresses. In IPv6, that is which is roughly 16 million addresses. In IPv6, that is equivalent
equivalent to assigning a /64 per host out of a /40. Enterprises of to assigning a /64 per host out of a /40. Enterprises of such size
such size can easily obtain a /40 under current RIR policies. can easily obtain a /40 under current RIR policies.
Currently, residential users receive one IPv4 address and a /48, /56 Currently, residential users receive one IPv4 address and a /48, /56
or /60 IPv6 prefix. While such networks do not have enough space to or /60 IPv6 prefix. While such networks do not have enough space to
assign a /64 per device, today such networks almost universally use assign a /64 per device, today such networks almost universally use
SLAAC. SLAAC.
Unlike IPv4 where addresses came at a premium, in all these networks, Unlike IPv4 where addresses came at a premium, in all these networks,
there is enough IPv6 address space to supply clients with multiple there is enough IPv6 address space to supply clients with multiple
IPv6 addresses. 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 direct impact for
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 Layer 2 address
spoofing, every (Layer 2, IP) address pair impacts networking spoofing, every (Layer 2, IP) address pair impacts networking
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 same impacts can be felt node multicast groups, etc. Many of these costs are incurred by
by neighboring hosts. Switching to a DHCPv6 PD model means there are neighboring hosts. Switching to a DHCPv6 PD model means there are
only forwarding decisions, with only one routing entry and one ND only forwarding decisions, with only one routing entry and one ND
cache entry per device on the network. cache entry per device on the network.
10. Acknowledgements 10. Acknowledgements
The authors thank Dieter Siegmund, Mark Smith, Sander Steffann, James The authors thank Tore Anderson, Wesley George, Shucheng (Will) Liu,
Woodyatt and Tore Anderson for their input and contributions. Dieter Siegmund, Mark Smith, Sander Steffann and James Woodyatt for
their input and contributions.
11. IANA Considerations 11. IANA Considerations
This memo includes no request to IANA. This memo includes no request to IANA.
12. Security Considerations 12. Security Considerations
None so far. None so far.
13. References 13. References
13.1. Normative References 13.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 13.2. Informative References
[I-D.herbert-nvo3-ila]
Herbert, T., "Identifier-locator addressing for network
virtualization", draft-herbert-nvo3-ila-00 (work in
progress), January 2015.
[I-D.ietf-dhc-anonymity-profile] [I-D.ietf-dhc-anonymity-profile]
Huitema, C., Mrugalski, T., and S. Krishnan, "Anonymity Huitema, C., Mrugalski, T., and S. Krishnan, "Anonymity
profile for DHCP clients", draft-ietf-dhc-anonymity- profile for DHCP clients", draft-ietf-dhc-anonymity-
profile-01 (work in progress), June 2015. profile-02 (work in progress), August 2015.
[I-D.tsvwg-quic-protocol] [I-D.tsvwg-quic-protocol]
Jana, J. and I. Swett, "QUIC: A UDP-Based Secure and Jana, 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>.
skipping to change at page 11, line 44 skipping to change at page 12, line 33
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
Vint Cerf Vint Cerf
Google Google
1600 Amphitheatre Parkway 1875 Explorer St
Mountain View, CA 94043 10th Floor
Reston, VA 20190
US US
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 US
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 US
Email: dschinazi@apple.com Email: dschinazi@apple.com
 End of changes. 44 change blocks. 
133 lines changed or deleted 173 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/