draft-ietf-v6ops-host-addr-availability-02.txt   draft-ietf-v6ops-host-addr-availability-03.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: May 4, 2016 S. Cheshire Expires: June 12, 2016 S. Cheshire
D. Schinazi D. Schinazi
Apple Inc. Apple Inc.
November 1, 2015 December 10, 2015
Host address availability recommendations Host address availability recommendations
draft-ietf-v6ops-host-addr-availability-02 draft-ietf-v6ops-host-addr-availability-03
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 May 4, 2016. This Internet-Draft will expire on June 12, 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 23 skipping to change at page 2, line 23
4. Problems with assigning a restricted 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 . . . . . . . . . . . . . . . . . 8 9. Operational considerations . . . . . . . . . . . . . . . . . 8
9.1. Stateful addressing and host tracking . . . . . . . . . . 8 9.1. Stateful addressing and 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 . 9 9.3. Addressing link layer scalability issues via IP routing . 9
10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 9 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 10
11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10
12. Security Considerations . . . . . . . . . . . . . . . . . . . 10 12. Security Considerations . . . . . . . . . . . . . . . . . . . 10
13. References . . . . . . . . . . . . . . . . . . . . . . . . . 10 13. References . . . . . . . . . . . . . . . . . . . . . . . . . 10
13.1. Normative References . . . . . . . . . . . . . . . . . . 10 13.1. Normative References . . . . . . . . . . . . . . . . . . 10
13.2. Informative References . . . . . . . . . . . . . . . . . 10 13.2. Informative References . . . . . . . . . . . . . . . . . 10
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 12 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,
skipping to change at page 9, line 37 skipping to change at page 9, line 37
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.
only forwarding decisions, with only one routing entry and one ND
cache entry per device on the network. Hosts on such networks that create unreasonable numbers of addresses
risk impairing network connectivity for themselves and other hosts on
the network, and in extreme cases (e.g., hundreds or thousands of
addresses) may even find their network access restricted by denial-
of-service protection mechanisms. We expect these scaling
limitations to change over time as hardware and applications evolve.
However, switching to a DHCPv6 PD model with one /64 prefix per host
resolves these scaling limitations, with only one routing entry and
one ND cache entry per device on the network.
Also, a DHCPv6 PD model with a dedicated /64 per host makes it
possible for the host not to assign global IPv6 addresses directly to
its physical network interface, but instead to assign them to an
internal interface such as a loopback interface. This obviates the
need to perform Neighbour Discovery and Duplicate Address Detection
for anything other than the link-local address on its physical
network interface, reducing network traffic.
10. Acknowledgements 10. Acknowledgements
The authors thank Tore Anderson, Brian Carpenter, Wesley George, Erik The authors thank Tore Anderson, Brian Carpenter, David Farmer,
Kline, Shucheng (Will) Liu, Dieter Siegmund, Mark Smith, Sander Wesley George, Erik Kline, Shucheng (Will) Liu, Dieter Siegmund, Mark
Steffann and James Woodyatt for their input and contributions. 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, DOI 10.17487/ Requirement Levels", BCP 14, RFC 2119,
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-04 (work in progress), October 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 Iyengar, 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>.
[RFC2993] Hain, T., "Architectural Implications of NAT", RFC 2993, [RFC2993] Hain, T., "Architectural Implications of NAT", RFC 2993,
DOI 10.17487/RFC2993, November 2000, DOI 10.17487/RFC2993, November 2000,
skipping to change at page 11, line 14 skipping to change at page 11, line 33
[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, DOI 10.17487/ Address Autoconfiguration", RFC 4862,
RFC4862, September 2007, DOI 10.17487/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, DOI 10.17487/ IPv6 Network Address Translation", RFC 5902,
RFC5902, July 2010, DOI 10.17487/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", RFC Combination of Stateful and Stateless Translation",
6877, DOI 10.17487/RFC6877, April 2013, RFC 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, DOI 10.17487/ Autoconfiguration (SLAAC)", RFC 7217,
RFC7217, April 2014, DOI 10.17487/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, DOI (3GPP) Mobile Interface to a LAN Link", RFC 7278,
10.17487/RFC7278, June 2014, DOI 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, DOI 10.17487/ Boundary in IPv6 Addressing", RFC 7421,
RFC7421, January 2015, DOI 10.17487/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. 15 change blocks. 
27 lines changed or deleted 44 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/