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/