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/