draft-ietf-v6ops-host-addr-availability-05.txt   draft-ietf-v6ops-host-addr-availability-06.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: August 15, 2016 S. Cheshire Expires: September 10, 2016 S. Cheshire
D. Schinazi D. Schinazi
Apple Inc. Apple Inc.
February 12, 2016 March 9, 2016
Host address availability recommendations Host address availability recommendations
draft-ietf-v6ops-host-addr-availability-05 draft-ietf-v6ops-host-addr-availability-06
Abstract Abstract
This document recommends that networks provide general-purpose end This document recommends that networks provide general-purpose end
hosts with multiple global IPv6 addresses when they attach, and hosts with multiple global IPv6 addresses when they attach, and
describes the benefits of and the options for doing so. describes the benefits of and the options for doing so.
Status of This Memo Status of This Memo
This Internet-Draft is submitted in full conformance with the This Internet-Draft is submitted in full conformance with the
skipping to change at page 1, line 35 skipping to change at page 1, line 35
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on August 15, 2016. This Internet-Draft will expire on September 10, 2016.
Copyright Notice Copyright Notice
Copyright (c) 2016 IETF Trust and the persons identified as the Copyright (c) 2016 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
skipping to change at page 2, line 19 skipping to change at page 2, line 19
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 . . . . . . . . . . . . . . . . 7
8. Recommendations . . . . . . . . . . . . . . . . . . . . . . . 8 8. Recommendations . . . . . . . . . . . . . . . . . . . . . . . 8
9. Operational considerations . . . . . . . . . . . . . . . . . 8 9. Operational considerations . . . . . . . . . . . . . . . . . 8
9.1. Stateful addressing and host tracking . . . . . . . . . . 8 9.1. Host tracking . . . . . . . . . . . . . . . . . . . . . . 8
9.2. Address space management . . . . . . . . . . . . . . . . 9 9.2. Address space management . . . . . . . . . . . . . . . . 9
9.3. Addressing link layer scalability issues via IP routing . 10 9.3. Addressing link layer scalability issues via IP routing . 10
10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 10 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 11
11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11
12. Security Considerations . . . . . . . . . . . . . . . . . . . 10 12. Security Considerations . . . . . . . . . . . . . . . . . . . 11
13. References . . . . . . . . . . . . . . . . . . . . . . . . . 11 13. References . . . . . . . . . . . . . . . . . . . . . . . . . 11
13.1. Normative References . . . . . . . . . . . . . . . . . . 11 13.1. Normative References . . . . . . . . . . . . . . . . . . 11
13.2. Informative References . . . . . . . . . . . . . . . . . 11 13.2. Informative References . . . . . . . . . . . . . . . . . 11
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 13 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 areas it can lead operation of dual-stack networks. However, in some design and
to carrying over IPv4 practices that are not appropriate in IPv6 due operational areas it can lead to carrying over IPv4 practices that
to significant differences between the protocols. are limiting or not appropriate in IPv6 due to differences between
the protocols.
One such area is IP addressing, particularly IP addressing of hosts. One such area is IP addressing, particularly IP addressing of hosts.
This is substantially different because unlike IPv4 addresses, IPv6 This is substantially different because unlike IPv4 addresses, IPv6
addresses are not a scarce resource. In IPv6, each link has a addresses are not a scarce resource. In IPv6, a single link provides
virtually unlimited amount of address space [RFC7421]. Thus, unlike over four billion times more address space than the whole IPv4
IPv4, IPv6 networks are not forced by address availability Internet [RFC7421]. Thus, unlike IPv4, IPv6 networks are not forced
considerations to provide only one address per host. On the other by address availability considerations to provide only one address
hand, providing multiple addresses has many benefits including per host. On the other hand, providing multiple addresses has many
application functionality and simplicity, privacy, future benefits including application functionality and simplicity, privacy,
applications, and the ability to deploy the Internet without the use flexibility to accommodate future applications, and the ability to
of NAT. Providing only one IPv6 address per host negates these provide Internet access without the use of NAT. Providing only one
benefits. IPv6 address per host negates these benefits.
This document describes the benefits of providing multiple addresses This document describes the benefits of providing multiple addresses
per host and the problems with not doing so. It recommends that per host and the problems with not doing so. It recommends that
networks provide general-purpose end hosts with multiple global networks provide general-purpose end hosts with multiple global
addresses when they attach, and lists current options for doing so. addresses when they attach, and lists current options for doing so.
It does not specify any changes to protocols or host behavior. 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",
skipping to change at page 3, line 38 skipping to change at page 3, line 40
In most general-purpose IPv6 networks, including all 3GPP networks In most general-purpose IPv6 networks, including all 3GPP networks
([RFC6459] section 5.2) and Ethernet and Wi-Fi networks using SLAAC ([RFC6459] section 5.2) and Ethernet and Wi-Fi networks using SLAAC
[RFC4862], IPv6 hosts have the ability to configure additional IPv6 [RFC4862], IPv6 hosts have the ability to configure additional IPv6
addresses from the link prefix(es) without explicit requests to the addresses from the link prefix(es) without explicit requests to the
network. network.
3. Benefits of 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: address to be available to the host, including:
o Privacy addressing to prevent tracking by off-network hosts o Privacy addressing to prevent tracking by off-network hosts
[RFC4941]. [RFC4941].
o Multiple processors inside the same device. For example, in many o Multiple processors inside the same device. For example, in many
mobile devices both the application processor and baseband mobile devices both the application processor and baseband
processor need to communicate with the network, particularly for processor need to communicate with the network, particularly for
recent technologies like ePDG. 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 o Translation-based transition technologies such as 464XLAT
[RFC6877] that provide IPv4 over IPv6. Some of these require the [RFC6877] that provide IPv4 over IPv6. Some of these technologies
availability of a dedicated IPv6 address in order to determine require the availability of a dedicated IPv6 address in order to
whether inbound packets are translated or native ([RFC6877] determine whether inbound packets are translated or native
section 6.3). ([RFC6877] section 6.3).
o ILA ("Identifier-locator addressing") [I-D.herbert-nvo3-ila]. o ILA ("Identifier-locator addressing") [I-D.herbert-nvo3-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 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. 464XLAT is usually deployed within a particular network, o 464XLAT. 464XLAT is usually deployed within a particular network,
skipping to change at page 6, line 48 skipping to change at page 6, line 50
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 DUID, though the
DHCPv6 specification implies that this is not expected behavior DHCPv6 specification implies that this is not expected behavior
([RFC3315] section 9). The DHCPv6 server will decide whether to ([RFC3315] section 9). The DHCPv6 server will decide whether to
grant or reject the request based on information about the client, grant or reject the request based on information about the client,
including its DUID, MAC address, and so on. The number of IPv6 including its DUID, MAC address, and so on. The maximum number of
addresses that can be provided in a single DHCPv6 packet is IPv6 addresses that can be provided in a single DHCPv6 packet,
approximately 30. 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 [RFC3633]. DHCPv6 PD allows the client
to request and be delegated a prefix, from which it can to request and be delegated a prefix, from which it can
autonomously form other addresses. If the prefix is shorter than autonomously form other addresses. If the prefix is shorter than
/64, it can be divided into multiple subnets which can be further /64, it can be divided into multiple subnets which can be further
delegated to downstream clients. If the prefix is a /64, it can delegated to downstream clients. If the prefix is a /64, it can
be extended via L2 bridging, ND proxying [RFC4389] or /64 sharing be extended via L2 bridging, ND proxying [RFC4389] or /64 sharing
[RFC7278], but it cannot be further subdivided, as a prefix longer [RFC7278], but it cannot be further subdivided, as a prefix longer
than /64 is outside the current IPv6 specifications [RFC7421]. than /64 is outside the current IPv6 specifications [RFC7421].
While [RFC3633] assumes that the DHCPv6 client is a router, DHCPv6 While [RFC3633] assumes that the DHCPv6 client is a router, DHCPv6
PD itself does not require that the client forward IPv6 packets PD itself does not require that the client forward IPv6 packets
not addressed to itself, and thus does not require that the client not addressed to itself, and thus does not require that the client
be an IPv6 router as defined in [RFC2460]. be an IPv6 router as defined in [RFC2460].
+--------------------------+-------+-------------+--------+---------+ +--------------------------+-------+-------------+--------+---------+
| | SLAAC | DHCPv6 | DHCPv6 | DHCPv4 | | | SLAAC | DHCPv6 | DHCPv6 | DHCPv4 |
| | | IA_NA / | PD | | | | | IA_NA / | PD | |
| | | IA_TA | | | | | | IA_TA | | |
+--------------------------+-------+-------------+--------+---------+ +--------------------------+-------+-------------+--------+---------+
| Extend network | Yes | No | Yes | Yes | | Can extend network | No+ | No | Yes | Yes |
| | | | | (NAT44) | | | | | | (NAT44) |
| "Unlimited" endpoints | Yes* | Yes* | No | No | | Can number "unlimited" | Yes* | Yes* | No | No |
| Stateful, request-based | No | Yes | Yes | Yes | | endpoints | | | | |
| Immune to layer 3 on- | No | Yes | Yes | Yes | | Uses stateful, request- | No | Yes | Yes | Yes |
| based assignment | | | | |
| 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].
Table 1: Comparison of multiple address assignment options Table 1: Comparison of multiple address assignment options
7. Number of addresses required 7. Number of addresses required
If we itemize the use cases from section Section 3, we can estimate If we itemize the use cases from section Section 3, we can estimate
the number of addresses currently used in normal operations. In the number of addresses currently used in normal operations. In
typical implementations, privacy addresses use up to 8 addresses - typical implementations, privacy addresses use up to 8 addresses -
one per day ([RFC4941] section 3.5). Current mobile devices may one per day ([RFC4941] section 3.5). Current mobile devices may
typically support 8 clients, with each one requiring one or more typically support 8 clients, with each one requiring one or more
skipping to change at page 8, line 34 skipping to change at page 8, line 39
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 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 would limit the development
of future applications. of future applications.
9. Operational considerations 9. Operational considerations
9.1. Stateful addressing and host tracking 9.1. Host tracking
Some network operators - often operators of networks that provide Some network operators - often operators of networks that provide
services to third parties such as university campus networks - are services to third parties such as university campus networks - are
required to track which IP addresses are assigned to which hosts on required to track which IP addresses are assigned to which hosts on
their network. Maintaining persistent logs that map user IP their network. Maintaining persistent logs that map user IP
addresses and timestamps to hardware identifiers such as MAC addresses and timestamps to hardware identifiers such as MAC
addresses may be used to avoid liability for copyright infringement addresses may be used to avoid liability for copyright infringement
or other illegal activity. 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
skipping to change at page 9, line 7 skipping to change at page 9, line 13
these mappings by monitoring IPv6 neighbor table: routers typically these mappings by monitoring IPv6 neighbor table: routers typically
allow periodic dumps of the neighbor cache via SNMP or other means, allow periodic dumps of the neighbor cache via SNMP or other means,
and many can be configured to log every change to the neighbor cache. and many can be configured to log every change to the neighbor cache.
Using SLAAC with a dedicated /64 prefix simplifies tracking, as it Using SLAAC with a dedicated /64 prefix simplifies tracking, as it
does not require logging each address formed by the host, but only does not require logging each address formed by the host, but only
the prefix assigned to the host when it attaches to the network. the prefix assigned to the host when it attaches to the network.
Similarly, providing address space using DHCPv6 PD has the same Similarly, providing address space using DHCPv6 PD has the same
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, including the enterprise networks of Many large enterprise networks are fully dual-stack and implement
the authors' employers, are fully dual-stack and implement address address monitoring without using or supporting DHCPv6. The authors
monitoring without using or supporting DHCPv6. The authors are are directly aware of several networks that operate in this way,
directly aware of several other networks that operate in this way, including the Universities of Loughborough, Minnesota, Reading,
including Universities of Loughborough, Minnesota, Reading, Southampton, Wisconsin and Imperial College London, in addition to
Southampton, Wisconsin and Imperial College London. 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 L2 edge port security, hosts
are able to choose their own addresses regardless of what address are able to choose their own addresses regardless of what address
provisioning methodology is in use. The only way to restrict the provisioning methodology is in use. The only way to restrict the
addresses used by hosts is to use layer 2 security mechanisms that addresses used by hosts is to use layer 2 security mechanisms that
enforce that particular IPv6 addresses are used by particular link- enforce that particular IPv6 addresses are used by particular link-
layer addresses (for example, SAVI [RFC7039]). If those mechanisms layer addresses (for example, SAVI [RFC7039]). If those mechanisms
are available, it is possible to use them to provide tracking; this are available, it is possible to use them to provide tracking; this
skipping to change at page 9, line 36 skipping to change at page 9, line 42
become decreasingly viable due to ongoing efforts to improve the become decreasingly viable due to ongoing efforts to improve the
privacy of DHCPv6 [I-D.ietf-dhc-anonymity-profile]. privacy of DHCPv6 [I-D.ietf-dhc-anonymity-profile].
9.2. Address space management 9.2. Address space management
In IPv4, all but the world's largest networks can be addressed using In IPv4, all but the world's largest networks can be addressed using
private space [RFC1918], with each host receiving one IPv4 address. private space [RFC1918], with each host receiving one IPv4 address.
Many networks can be numbered in 192.168.0.0/16 which has roughly 64k Many networks can be numbered in 192.168.0.0/16 which has roughly 64k
addresses. In IPv6, that is equivalent to a /48, with each of 64k addresses. In IPv6, that is equivalent to a /48, with each of 64k
hosts receiving a /64 prefix. Under current RIR policies, a /48 is hosts receiving a /64 prefix. Under current RIR policies, a /48 is
easy to obtain for an enterprise network. easy to obtain for an enterprise network. Networks that need a
bigger block of private space use 10.0.0.0/8, which has roughly 16
million addresses. In IPv6, that is equivalent to a /40, with each
host receiving /64 prefix. Enterprises of such size can easily
obtain a /40 under current RIR policies.
Networks that need a bigger block of private space use 10.0.0.0/8, In the above cases, aggregation and routing can be equivalent to
which has roughly 16 million addresses. In IPv6, that is equivalent IPv4: if a network aggregates per-host IPv4 addresses into prefixes
to a /40, with each host receiving /64 prefix. Enterprises of such of length /32 - n, it can aggregate per-host /64 prefixes into the
size can easily obtain a /40 under current RIR policies. Aggregation same number of prefixes of length /64 - n.
and routing can be equivalent to IPv4, with /64 prefixes being
aggregated into the as many prefixes of length /64 - n as IPv4
addresses are aggregated into prefixes of length /32 - 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 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.
skipping to change at page 10, line 27 skipping to change at page 10, line 33
neighboring hosts. neighboring hosts.
Hosts on such networks that create unreasonable numbers of addresses Hosts on such networks that create unreasonable numbers of addresses
risk impairing network connectivity for themselves and other hosts on risk impairing network connectivity for themselves and other hosts on
the network, and in extreme cases (e.g., hundreds or thousands of the network, and in extreme cases (e.g., hundreds or thousands of
addresses) may even find their network access restricted by denial- addresses) may even find their network access restricted by denial-
of-service protection mechanisms. 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, with only one prefix per host can resolve these scaling limitations. If the prefix
routing entry and one ND cache entry per host on the network. If the is provided via DHCPv6 PD, or if the prefix can be used by only one
host is aware that the prefix is dedicated (e.g., if it was provided link-layer address (e.g., if the link layer uniquely identifies or
via DHCPv6 PD and not SLAAC), it is possible for the host to assign authenticates hosts based on MAC addresses), then there will be only
IPv6 addresses from this prefix to an internal interface such as a one routing entry and one ND cache entry per host on the network.
loopback interface. This obviates the need to perform Neighbor Furthermore, if the host is aware that the prefix is dedicated (e.g.,
Discovery and Duplicate Address Detection on the network interface if it was provided via DHCPv6 PD and not SLAAC), it is possible for
for these addresses, reducing network traffic. the host to assign IPv6 addresses from this prefix to an internal
interface such as a loopback interface. This obviates the need to
perform Neighbor Discovery and Duplicate Address Detection on the
network interface for these addresses, reducing network traffic.
Thus, assigning a dedicated /64 prefix per host is operationally
prudent. Clearly, however, it requires more IPv6 address space than
using shared links, so the benefits provided must be weighed with the
operational overhead of address space management.
10. Acknowledgements 10. Acknowledgements
The authors thank Tore Anderson, Brian Carpenter, David Farmer, The authors thank Tore Anderson, Brian Carpenter, David Farmer,
Wesley George, Erik Kline, Shucheng (Will) Liu, Dieter Siegmund, Mark Wesley George, Geoff Huston, Erik Kline, Victor Kuarsingh, Shucheng
Smith, Sander Steffann, Fred Templin and James Woodyatt for their (Will) Liu, Dieter Siegmund, Mark Smith, Sander Steffann, Fred
input and contributions. Templin 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. As mentioned in section 9.3, on shared networks using SLAAC it is
possible for hosts to attempt to exhaust network resources and
possibly deny service to other hosts by creating unreasonable numbers
(e.g., hundreds or thousands) of addresses. Networks that provide
access to untrusted hosts can mitigate this threat by providing a
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
for a particular host, but care must be taken to ensure that the
network does not restrict the IP addresses available to non-malicious
hosts.
Security issues related to host tracking are discussed in section
9.1.
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] [I-D.herbert-nvo3-ila]
Herbert, T., "Identifier-locator addressing for network Herbert, T., "Identifier-locator addressing for network
virtualization", draft-herbert-nvo3-ila-01 (work in virtualization", draft-herbert-nvo3-ila-01 (work in
progress), October 2015. progress), October 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-06 (work in progress), January 2016. profile-08 (work in progress), February 2016.
[I-D.tsvwg-quic-protocol] [I-D.tsvwg-quic-protocol]
Hamilton, R., Iyengar, J., Swett, I., and A. Wilk, "QUIC: Hamilton, R., Iyengar, J., Swett, I., and A. Wilk, "QUIC:
A UDP-Based Secure and Reliable Transport for HTTP/2", A UDP-Based Secure and Reliable Transport for HTTP/2",
draft-tsvwg-quic-protocol-02 (work in progress), January draft-tsvwg-quic-protocol-02 (work in progress), January
2016. 2016.
[RFC1918] Rekhter, Y., Moskowitz, B., Karrenberg, D., de Groot, G., [RFC1918] Rekhter, Y., Moskowitz, B., Karrenberg, D., de Groot, G.,
and E. Lear, "Address Allocation for Private Internets", and E. Lear, "Address Allocation for Private Internets",
BCP 5, RFC 1918, DOI 10.17487/RFC1918, February 1996, BCP 5, RFC 1918, DOI 10.17487/RFC1918, February 1996,
 End of changes. 23 change blocks. 
61 lines changed or deleted 86 lines changed or added

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