IPv6 Operations L. Colitti
Internet-Draft V. Cerf
Intended status: Best Current Practice Google
Expires: January 7, 2016 S. Cheshire
Apple
July 6, 2015
Host address availability recommendations
draft-colitti-v6ops-host-addr-availability-00
Abstract
This document recommends that networks provide general-purpose end
hosts with multiple global addresses, and describes options for doing
so.
Status of This Memo
This Internet-Draft is submitted in full conformance with the
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
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
This Internet-Draft will expire on January 7, 2016.
Copyright Notice
Copyright (c) 2015 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License.
Colitti, et al. Expires January 7, 2016 [Page 1]
Internet-Draft Host address availability recommendations July 2015
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
1.1. Requirements Language . . . . . . . . . . . . . . . . . . 2
2. Common IPv6 deployment model . . . . . . . . . . . . . . . . 2
3. Benefits of multiple addresses . . . . . . . . . . . . . . . 3
4. Problems with assigning a limited number of addresses per
host . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
5. Overcoming limits using Network Address Translation . . . . . 4
6. Recommendations . . . . . . . . . . . . . . . . . . . . . . . 5
7. Options for obtaining more than one address . . . . . . . . . 5
8. Operational considerations . . . . . . . . . . . . . . . . . 6
8.1. Stateful addressing and host tracking . . . . . . . . . . 6
8.2. Address space management . . . . . . . . . . . . . . . . 7
8.3. Addressing link layer scalability issues via IP routing . 7
9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 7
10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7
11. Security Considerations . . . . . . . . . . . . . . . . . . . 8
12. References . . . . . . . . . . . . . . . . . . . . . . . . . 8
12.1. Normative References . . . . . . . . . . . . . . . . . . 8
12.2. Informative References . . . . . . . . . . . . . . . . . 8
12.3. URIs . . . . . . . . . . . . . . . . . . . . . . . . . . 9
Appendix A. Additional Stuff . . . . . . . . . . . . . . . . . . 9
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 9
1. Introduction
This document recommends that networks provide general-purpose end
hosts with multiple global addresses, and describes options for doing
so.
1.1. Requirements Language
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC 2119 [RFC2119].
2. Common IPv6 deployment model
IPv6 is designed to support multiple addresses, including multiple
global addresses, per interface ([RFC4291] section 2.1, [RFC6433]
section 5.9.4). Today, many general-purpose IPv6 hosts are
configured with three or more addresses per interface: a link-local
address, a stable address (e.g., using EUI-64 or [RFC7217]), one or
more privacy addresses [RFC4941], and possibly one or more addresses
assigned using DHCPv6 [RFC7217].
Colitti, et al. Expires January 7, 2016 [Page 2]
Internet-Draft Host address availability recommendations July 2015
In most general-purpose IPv6 networks, including all 3GPP networks
(see [RFC6459] section 5.2) and Ethernet and Wi-Fi networks using
SLAAC [RFC4862], IPv6 hosts have the ability to configure additional
IPv6 addresses from the on-link prefix without explicit requests to
the network.
3. Benefits of multiple addresses
Today, there are many host functions that require more than one IP
address to be available to the host:
o Privacy addressing to prevent tracking by off-network hosts (e.g.,
[RFC4941])
o Multiple processors inside the same device. For example, in many
mobile devices both the application processor and baseband
processor need to communicate with the network, particularly for
recent technologies like ePDG.
o Extending network (e.g., tethering)
o Running virtual machines on hosts
o Translation-based transition technologies such as 464xlat that
provide IPv4 over IPv6. These require the availability of a
dedicated IPv6 address in order to determine whether inbound
packets are translated or native.
o ILA ("Identifier-locator addressing"): https://tools.ietf.org/
html/draft-herbert-nvo3-ila
o Future applications (e.g., per-application IPv6 addresses).
Example of how the availability of multiple addresses per host has
already allowed substantial deployment of new applications without
explicit requests to the network are:
o 464xlat [RFC6877]. 464xlat is usually deployed within a particular
network operator's network, but there are deployment models where
the PLAT is provided as a service by a different network [e.g.,
http://www.jpix.ad.jp/en/service/ipv6v4.html]
o /64 sharing [RFC7278]. This was a way to provide IPv6 tethering
without needing to wait for network operators to deploy DHCPv6 PD,
which is only available in 3GPP release 10.
Colitti, et al. Expires January 7, 2016 [Page 3]
Internet-Draft Host address availability recommendations July 2015
4. Problems with assigning a limited number of addresses per host
Assigning a limited number of addresses per host implies that
functions that require multiple addresses will either be unavailable
(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),
or that the functions will only be available after an explicit
request to the network is granted. The necessity of explicit
requests has the following drawbacks:
o Increased latency, because a provisioning operation must complete
before the functionality is available.
o Uncertainty, because it is not known in advance if a particular
operation function will be available.
o Complexity, because implementations need to deal with failures and
somehow present them to the user. Failures may manifest as
timeouts, which may be slow and frustrating to users.
o Increased load on the network's provisioning servers.
Some operators may desire to configure their networks to limit the
number of IPv6 addresses per host. Reasons might include hardware
limitations (e.g., TCAM or neighbour cache table size constraints),
operational consistency with IPv4 (e.g., an IP address management
system that only supports one address per host), or business models
(e.g., a desire to charge the network's users on a per-device basis).
5. Overcoming limits using Network Address Translation
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
the host. Thus, the limits could be overcome in IPv6 as well by
implementing NAT66 on the host.
Unfortunately NAT has well-known drawbacks. For example, it causes
application complexity due to the need to implement NAT traversal.
It hinders development of new applications. On mobile devices, it
reduces battery life due to the necessity of frequent keepalives
(particularly for UDP, applications that need to work on most of the
Internet are forced to send keepalives at least every 30 seconds
[QUIC IETF slides]). While IPv4 NAT is inevitable due to the 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 desirable
[RFC5902].
Colitti, et al. Expires January 7, 2016 [Page 4]
Internet-Draft Host address availability recommendations July 2015
If networks that provide limited amount of addresses become widely
deployed, then the desire to overcome the problems listed in section
without disabling any features may result in operating system
manufacturers implementing IPv6 NAT.
This is not a desirable outcome. It is not desirable for users
because they may experience application brittleness. It is likely
not desirable for network operators either, as they may suffer higher
support costs, and even when the decision to assign only one IPv6
address per device is dictated by the network's business model, there
may be little in the way of incremental revenue, because devices can
share their IPv6 address with other devices. Finally, it is not
desirable for operating system manufacturers and application
developers, who will have to build more complexity, lengthening
development time and/or reducing the time spent on other features.
Indeed, it could be argued that the main reason for deploying IPv6,
instead of continuing to scale the Internet using only IPv4 and
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
technical factors but only by security policies.
6. Recommendations
In order to avoid the problems described above, and preserve the
Internet's ability to support new applications that use more than one
IPv6 address, it is recommended that IPv6 network deployments provide
multiple IPv6 addresses to general purpose hosts.
7. Options for obtaining more than one address
Multiple IPv6 addresses can be obtained in the following ways:
o Using Stateless Address Autoconfiguration [RFC4862]. SLAAC allows
hosts to create global IPv6 addresses on demand by simply forming
new addresses from the global prefix assigned to the link.
o Using stateful DHCPv6 address assignment [RFC3315]. Most DHCPv6
clients only ask for one address, but the protocol allows
requesting multiple addresses, and the server could choose to
assign the client multiple addresses. It is also possible for a
client to request additional addresses using a different DUID.
The DHCPv6 server will decide 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
to request and be delegated a prefix, from which it can
Colitti, et al. Expires January 7, 2016 [Page 5]
Internet-Draft Host address availability recommendations July 2015
autonomously form other addresses. If the prefix is a /64, it can
also reshare that prefix with any downstream clients via [RFC7278]
/64 sharing.
+-------------------------+----------+---------+----------+---------+
| | SLAAC | DHCPv6 | DHCPv6 | DHCPv4 |
| | | IA_NA | PD | |
+-------------------------+----------+---------+----------+---------+
| Autonomously form | Yes (/64 | No | Yes (/64 | Yes |
| addresses | share) | | share) | (NAT44) |
| "Unlimited" addressing | Yes | Yes | No | No |
| Stateful, request-based | No | Yes | Yes | Yes |
| Request-based | No | Yes | Yes | Yes |
| Immune to layer 3 on- | No | Yes | Yes | Yes |
| link resource | | | | |
| exhaustion attacks | | | | |
+-------------------------+----------+---------+----------+---------+
Table 1: Comparison of multiple address assigment options
8. Operational considerations
8.1. Stateful addressing and host tracking
Some network operators - often operators networks that provide
services to third parties such as university campus networks - have
made the argument that the only feasible IPv6 deployment mechanism is
DHCPv6, due to the need to be able to track at all times IPv6
addresses are assigned to which hosts. (Example: [1] ). One reason
frequently cited for this is protection from liability for copyright
infringement or other illegal activity.
It is worth noting that using DHCPv6 does not by itself ensure that
hosts will actually use the addresses assigned to them by the network
as opposed to using any other address on the prefix. Such guarantees
can only be provided by link-layer security mechanisms that enforce
that particular IPv6 addresses are used by particular link-layer
addresses (e.g., SAVI [RFC7039]). If those mechanisms are 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.
Many large enterprise networks, including the enterprise networks of
the authors, are fully dual-stack but do not use or support DHCPv6.
Colitti, et al. Expires January 7, 2016 [Page 6]
Internet-Draft Host address availability recommendations July 2015
8.2. Address space management
In IPv4, all but the world's largest IPv4 networks can be addressed
using RFC 1918 space. The total size of net 10 is roughly 2^24 (16
million) endpoints, with each endpoint receiving one IPv4 address.
In IPv6, that is equivalent to assigning one /64 per host out of a
/40. Under current RIR policies, a /40 is easy to obtain for an
enterprise network. In other words, assigning a single IPv6 /64 per
host is as feasible as assigning a single IPv4 address per host.
Currently, residential users receive one IPv4 address and a /56 or
/60 IPv6 prefix. While such networks do not have enough space to
assign a /64 per device, today such networks almost universally use
SLAAC.
Unlike IPv4 where addresses came at a premium, in all these networks,
there is enough IPv6 address space to supply clients with multiple
IPv6 addresses.
8.3. Addressing link layer scalability issues via IP routing
The number of IPv6 addresses on a link has direct impact for
networking infrastructure nodes (routers, switches) and other nodes
on the link. Setting aside exhaustion attacks via Layer 2 address
spoofing, every (Layer 2, IP) address pair impacts networking
hardware requirements in terms of memory, MLD snooping, solicited
node multicast groups, etc. Many of these same impacts can be felt
by neighboring hosts. Switching to a DHCPv6-PD model means there are
only forwarding decisions, with only one routing entry and one ND
cache entry per device on the network.
9. Acknowledgements
The authors thank Dieter Siegmund and David Schinazi for their input
and contributions.
10. IANA Considerations
This memo includes no request to IANA.
All drafts are required to have an IANA considerations section (see
the update of RFC 2434 [I-D.narten-iana-considerations-rfc2434bis]
for a guide). If the draft does not require IANA to do anything, the
section contains an explicit statement that this is the case (as
above). If there are no requirements for IANA, the section will be
removed during conversion into an RFC by the RFC Editor.
Colitti, et al. Expires January 7, 2016 [Page 7]
Internet-Draft Host address availability recommendations July 2015
11. Security Considerations
All drafts are required to have a security considerations section.
See RFC 3552 [RFC3552] for a guide.
12. References
12.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
12.2. Informative References
[I-D.narten-iana-considerations-rfc2434bis]
Narten, T. and H. Alvestrand, "Guidelines for Writing an
IANA Considerations Section in RFCs", draft-narten-iana-
considerations-rfc2434bis-09 (work in progress), March
2008.
[RFC3315] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C.,
and M. Carney, "Dynamic Host Configuration Protocol for
IPv6 (DHCPv6)", RFC 3315, July 2003.
[RFC3552] Rescorla, E. and B. Korver, "Guidelines for Writing RFC
Text on Security Considerations", BCP 72, RFC 3552, July
2003.
[RFC3633] Troan, O. and R. Droms, "IPv6 Prefix Options for Dynamic
Host Configuration Protocol (DHCP) version 6", RFC 3633,
December 2003.
[RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing
Architecture", RFC 4291, February 2006.
[RFC4862] Thomson, S., Narten, T., and T. Jinmei, "IPv6 Stateless
Address Autoconfiguration", RFC 4862, September 2007.
[RFC4941] Narten, T., Draves, R., and S. Krishnan, "Privacy
Extensions for Stateless Address Autoconfiguration in
IPv6", RFC 4941, September 2007.
[RFC5902] Thaler, D., Zhang, L., and G. Lebovitz, "IAB Thoughts on
IPv6 Network Address Translation", RFC 5902, July 2010.
[RFC6433] Hoffman, P., "Requirements for a Working Group Milestones
Tool", RFC 6433, November 2011.
Colitti, et al. Expires January 7, 2016 [Page 8]
Internet-Draft Host address availability recommendations July 2015
[RFC6459] Korhonen, J., Soininen, J., Patil, B., Savolainen, T.,
Bajko, G., and K. Iisakkila, "IPv6 in 3rd Generation
Partnership Project (3GPP) Evolved Packet System (EPS)",
RFC 6459, January 2012.
[RFC6877] Mawatari, M., Kawashima, M., and C. Byrne, "464XLAT:
Combination of Stateful and Stateless Translation", RFC
6877, April 2013.
[RFC7217] Gont, F., "A Method for Generating Semantically Opaque
Interface Identifiers with IPv6 Stateless Address
Autoconfiguration (SLAAC)", RFC 7217, April 2014.
[RFC7278] Byrne, C., Drown, D., and A. Vizdal, "Extending an IPv6
/64 Prefix from a Third Generation Partnership Project
(3GPP) Mobile Interface to a LAN Link", RFC 7278, June
2014.
12.3. URIs
[1] https://code.google.com/p/android/issues/detail?id=32621#c60
Appendix A. Additional Stuff
This becomes an Appendix.
Authors' Addresses
Lorenzo Colitti
Google
Roppongi 6-10-1
Minato, Tokyo 106-6126
JP
Email: lorenzo@google.com
Vint Cerf
Google
Stuart Cheshire
Apple
Colitti, et al. Expires January 7, 2016 [Page 9]