draft-ietf-v6ops-host-addr-availability-01.txt   draft-ietf-v6ops-host-addr-availability-02.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: March 6, 2016 S. Cheshire Expires: May 4, 2016 S. Cheshire
D. Schinazi D. Schinazi
Apple Inc. Apple Inc.
September 3, 2015 November 1, 2015
Host address availability recommendations Host address availability recommendations
draft-ietf-v6ops-host-addr-availability-01 draft-ietf-v6ops-host-addr-availability-02
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 IPv6 addresses when they attach, and
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
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
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 March 6, 2016. This Internet-Draft will expire on May 4, 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 6, line 46 skipping to change at page 6, line 46
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 technically possible for a client multiple addresses. It is also technically possible for a
client to request additional addresses using a different DUID, client to request additional addresses using a different DUID,
though the DHCPv6 specification implies that this is not expected though the DHCPv6 specification implies that this is not expected
behavior ([RFC3315] section 9). The DHCPv6 server will decide behavior ([RFC3315] section 9). The DHCPv6 server will decide
whether to grant or reject the request based on information about whether to grant or reject the request based on information about
the client, including its DUID, MAC address, and so on. 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. If the prefix is shorter than
hierarchically delegated to downstream clients, or, if it is a /64, it can be divided into multiple subnets which can be further
/64, it can be reshared with downstream clients via L2 bridging, delegated to downstream clients. If the prefix is a /64, it can
ND proxying [RFC4389] or /64 sharing [RFC7278]. be extended via L2 bridging, ND proxying [RFC4389] or /64 sharing
[RFC7278], but it cannot be further subdivided, as a prefix longer
than /64 is outside the current IPv6 specifications [RFC7421].
+--------------------------+-------+-------------+--------+---------+ +--------------------------+-------+-------------+--------+---------+
| | SLAAC | DHCPv6 | DHCPv6 | DHCPv4 | | | SLAAC | DHCPv6 | DHCPv6 | DHCPv4 |
| | | IA_NA / | PD | | | | | IA_NA / | PD | |
| | | IA_TA | | | | | | IA_TA | | |
+--------------------------+-------+-------------+--------+---------+ +--------------------------+-------+-------------+--------+---------+
| Extend network | Yes | No | Yes | Yes | | Extend network | Yes | No | Yes | Yes |
| | | | | (NAT44) | | | | | | (NAT44) |
| "Unlimited" endpoints | Yes* | Yes* | No | No | | "Unlimited" endpoints | Yes* | Yes* | No | No |
| Stateful, request-based | No | Yes | Yes | Yes | | Stateful, request-based | No | Yes | Yes | Yes |
skipping to change at page 8, line 6 skipping to change at page 8, line 6
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 (e.g., if it requires DHCPv6 to connect), it is for address space (e.g., if it requires DHCPv6 to connect), it is
RECOMMENDED that the network assign a /64 prefix to every host (e.g., RECOMMENDED that the network assign a /64 prefix to every host (e.g.,
via DHCPv6 PD). Using DHCPv6 IA_NA or IA_TA to request a sufficient via DHCPv6 PD). Using DHCPv6 IA_NA or IA_TA to request a sufficient
number of addresses (e.g. 32) would accommodate current clients but number of addresses (e.g. 32) would accommodate current clients but
sets a limit on the number of addresses available to hosts when they sets a limit on the number of addresses available to hosts when they
attach and would limit the development of future applications. attach and would limit the development of future applications.
Assigning prefixes smaller than a /64 will limit the flexibility of Assigning prefixes longer than a /64 will limit the flexibility of
the host to further assign addresses to any internal functions, the host to further assign addresses to any internal functions,
virtual machines, or downstream clients that require address space - virtual machines, or downstream clients that require address space -
for example, by not allowing the use of SLAAC. 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 - are services to third parties such as university campus networks - are
skipping to change at page 8, line 47 skipping to change at page 8, line 47
tracking. This form of tracking is much more secure and reliable tracking. This form of tracking is much more secure and reliable
than DHCP server logs because it operates independently of how than DHCP server logs because it operates independently of how
addresses are allocated. Additionally, attempts to track this sort addresses are allocated. Additionally, attempts to track this sort
of information via DHCPv6 are likely to become decreasingly viable of information via DHCPv6 are likely to become decreasingly viable
due to ongoing efforts to improve the privacy of DHCP due to ongoing efforts to improve the privacy of DHCP
[I-D.ietf-dhc-anonymity-profile]. [I-D.ietf-dhc-anonymity-profile].
Thus, host tracking does not necessarily require the use of stateful Thus, host tracking does not necessarily require the use of stateful
address assignment mechanisms such as DHCPv6. Indeed, many large address assignment mechanisms such as DHCPv6. Indeed, many large
enterprise networks, including the enterprise networks of the enterprise networks, including the enterprise networks of the
authors, are fully dual-stack but do not currently use or support authors' employers, are fully dual-stack but do not currently use or
DHCPv6. Many large universities also successfully use IPv6 neighbor support DHCPv6. The authors are directly aware of several networks
table logs or dumps to ensure host tracking. that operate in this way, including Universities of Loughborough,
Minnesota, Reading, Southampton, Wisconsin and Imperial College
London.
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], with each host receiving one IPv4 address.
address. Many networks can be numbered in 192.168.0.0/16 which has Many networks can be numbered in 192.168.0.0/16 which has roughly 64k
roughly 64k addresses. In IPv6, that is equivalent to assigning one addresses. In IPv6, that is equivalent to a /48, with each of 64k
/64 per host out of a /48. Under current RIR policies, a /48 is easy hosts receiving a /64 prefix. Under current RIR policies, a /48 is
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, Networks that need a bigger block of private space use 10.0.0.0/8,
which is roughly 16 million addresses. In IPv6, that is equivalent which has roughly 16 million addresses. In IPv6, that is equivalent
to assigning a /64 per host out of a /40. Enterprises of such size to a /40, with each host receiving /64 prefix. Enterprises of such
can easily obtain a /40 under current RIR policies. size can easily obtain a /40 under current RIR policies.
Currently, residential users receive one IPv4 address and a /48, /56 Currently, residential users typically receive one IPv4 address and a
or /60 IPv6 prefix. While such networks do not have enough space to /48, /56 or /60 IPv6 prefix. While such networks do not provide
assign a /64 per device, today such networks almost universally use enough space to assign a /64 per host, such networks almost
SLAAC. universally use SLAAC, and thus do not pose any particular limit to
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.
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 costs are incurred by node multicast groups, etc. Many of these costs are incurred 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 Tore Anderson, Wesley George, Shucheng (Will) Liu, The authors thank Tore Anderson, Brian Carpenter, Wesley George, Erik
Dieter Siegmund, Mark Smith, Sander Steffann and James Woodyatt for Kline, Shucheng (Will) Liu, Dieter Siegmund, Mark Smith, Sander
their input and contributions. 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/
DOI 10.17487/RFC2119, March 1997, 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-00 (work in virtualization", draft-herbert-nvo3-ila-01 (work in
progress), January 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-02 (work in progress), August 2015. profile-04 (work in progress), October 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 14 skipping to change at page 11, line 14
[RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing [RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing
Architecture", RFC 4291, DOI 10.17487/RFC4291, February Architecture", RFC 4291, DOI 10.17487/RFC4291, February
2006, <http://www.rfc-editor.org/info/rfc4291>. 2006, <http://www.rfc-editor.org/info/rfc4291>.
[RFC4389] Thaler, D., Talwar, M., and C. Patel, "Neighbor Discovery [RFC4389] Thaler, D., Talwar, M., and C. Patel, "Neighbor Discovery
Proxies (ND Proxy)", RFC 4389, DOI 10.17487/RFC4389, April Proxies (ND Proxy)", RFC 4389, DOI 10.17487/RFC4389, April
2006, <http://www.rfc-editor.org/info/rfc4389>. 2006, <http://www.rfc-editor.org/info/rfc4389>.
[RFC4862] Thomson, S., Narten, T., and T. Jinmei, "IPv6 Stateless [RFC4862] Thomson, S., Narten, T., and T. Jinmei, "IPv6 Stateless
Address Autoconfiguration", RFC 4862, Address Autoconfiguration", RFC 4862, DOI 10.17487/
DOI 10.17487/RFC4862, September 2007, RFC4862, September 2007,
<http://www.rfc-editor.org/info/rfc4862>. <http://www.rfc-editor.org/info/rfc4862>.
[RFC4941] Narten, T., Draves, R., and S. Krishnan, "Privacy [RFC4941] Narten, T., Draves, R., and S. Krishnan, "Privacy
Extensions for Stateless Address Autoconfiguration in Extensions for Stateless Address Autoconfiguration in
IPv6", RFC 4941, DOI 10.17487/RFC4941, September 2007, IPv6", RFC 4941, DOI 10.17487/RFC4941, September 2007,
<http://www.rfc-editor.org/info/rfc4941>. <http://www.rfc-editor.org/info/rfc4941>.
[RFC5902] Thaler, D., Zhang, L., and G. Lebovitz, "IAB Thoughts on [RFC5902] Thaler, D., Zhang, L., and G. Lebovitz, "IAB Thoughts on
IPv6 Network Address Translation", RFC 5902, IPv6 Network Address Translation", RFC 5902, DOI 10.17487/
DOI 10.17487/RFC5902, July 2010, RFC5902, July 2010,
<http://www.rfc-editor.org/info/rfc5902>. <http://www.rfc-editor.org/info/rfc5902>.
[RFC6434] Jankiewicz, E., Loughney, J., and T. Narten, "IPv6 Node [RFC6434] Jankiewicz, E., Loughney, J., and T. Narten, "IPv6 Node
Requirements", RFC 6434, DOI 10.17487/RFC6434, December Requirements", RFC 6434, DOI 10.17487/RFC6434, December
2011, <http://www.rfc-editor.org/info/rfc6434>. 2011, <http://www.rfc-editor.org/info/rfc6434>.
[RFC6459] Korhonen, J., Ed., Soininen, J., Patil, B., Savolainen, [RFC6459] Korhonen, J., Ed., Soininen, J., Patil, B., Savolainen,
T., Bajko, G., and K. Iisakkila, "IPv6 in 3rd Generation T., Bajko, G., and K. Iisakkila, "IPv6 in 3rd Generation
Partnership Project (3GPP) Evolved Packet System (EPS)", Partnership Project (3GPP) Evolved Packet System (EPS)",
RFC 6459, DOI 10.17487/RFC6459, January 2012, RFC 6459, DOI 10.17487/RFC6459, January 2012,
<http://www.rfc-editor.org/info/rfc6459>. <http://www.rfc-editor.org/info/rfc6459>.
[RFC6877] Mawatari, M., Kawashima, M., and C. Byrne, "464XLAT: [RFC6877] Mawatari, M., Kawashima, M., and C. Byrne, "464XLAT:
Combination of Stateful and Stateless Translation", Combination of Stateful and Stateless Translation", RFC
RFC 6877, DOI 10.17487/RFC6877, April 2013, 6877, DOI 10.17487/RFC6877, April 2013,
<http://www.rfc-editor.org/info/rfc6877>. <http://www.rfc-editor.org/info/rfc6877>.
[RFC7039] Wu, J., Bi, J., Bagnulo, M., Baker, F., and C. Vogt, Ed., [RFC7039] Wu, J., Bi, J., Bagnulo, M., Baker, F., and C. Vogt, Ed.,
"Source Address Validation Improvement (SAVI) Framework", "Source Address Validation Improvement (SAVI) Framework",
RFC 7039, DOI 10.17487/RFC7039, October 2013, RFC 7039, DOI 10.17487/RFC7039, October 2013,
<http://www.rfc-editor.org/info/rfc7039>. <http://www.rfc-editor.org/info/rfc7039>.
[RFC7217] Gont, F., "A Method for Generating Semantically Opaque [RFC7217] Gont, F., "A Method for Generating Semantically Opaque
Interface Identifiers with IPv6 Stateless Address Interface Identifiers with IPv6 Stateless Address
Autoconfiguration (SLAAC)", RFC 7217, Autoconfiguration (SLAAC)", RFC 7217, DOI 10.17487/
DOI 10.17487/RFC7217, April 2014, RFC7217, April 2014,
<http://www.rfc-editor.org/info/rfc7217>. <http://www.rfc-editor.org/info/rfc7217>.
[RFC7278] Byrne, C., Drown, D., and A. Vizdal, "Extending an IPv6 [RFC7278] Byrne, C., Drown, D., and A. Vizdal, "Extending an IPv6
/64 Prefix from a Third Generation Partnership Project /64 Prefix from a Third Generation Partnership Project
(3GPP) Mobile Interface to a LAN Link", RFC 7278, (3GPP) Mobile Interface to a LAN Link", RFC 7278, DOI
DOI 10.17487/RFC7278, June 2014, 10.17487/RFC7278, June 2014,
<http://www.rfc-editor.org/info/rfc7278>. <http://www.rfc-editor.org/info/rfc7278>.
[RFC7421] Carpenter, B., Ed., Chown, T., Gont, F., Jiang, S., [RFC7421] Carpenter, B., Ed., Chown, T., Gont, F., Jiang, S.,
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/
DOI 10.17487/RFC7421, January 2015, RFC7421, January 2015,
<http://www.rfc-editor.org/info/rfc7421>. <http://www.rfc-editor.org/info/rfc7421>.
[TARP] Gleitz, PM. and SM. Bellovin, "Transient Addressing for [TARP] Gleitz, PM. and SM. 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", August 2001.
Authors' Addresses Authors' Addresses
Lorenzo Colitti Lorenzo Colitti
Google Google
 End of changes. 21 change blocks. 
46 lines changed or deleted 51 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/