draft-ietf-ipv6-host-load-sharing-01.txt		draft-ietf-ipv6-host-load-sharing-02.txt
	IPv6 Working Group R. Hinden		IPv6 Working Group R. Hinden
	INTERNET-DRAFT Nokia		INTERNET-DRAFT Nokia
	January 26, 2004 D. Thaler		May 4, 2004 D. Thaler
	Expires July 2004 Microsoft		Expires November 2004 Microsoft
	IPv6 Host to Router Load Sharing		IPv6 Host to Router Load Sharing
	<draft-ietf-ipv6-host-load-sharing-01.txt>		<draft-ietf-ipv6-host-load-sharing-02.txt>
	Status of this Memo		Status of this Memo
	This document is an Internet-Draft and is in full conformance with		This document is an Internet-Draft and is in full conformance with
	all provisions of Section 10 of RFC2026.		all provisions of Section 10 of RFC2026.
	Internet-Drafts are working documents of the Internet Engineering		Internet-Drafts are working documents of the Internet Engineering
	Task Force (IETF), its areas, and its working groups. Note that		Task Force (IETF), its areas, and its working groups. Note that
	other groups may also distribute working documents as Internet-		other groups may also distribute working documents as Internet-
	Drafts.		Drafts.
	skipping to change at page 2, line 5		skipping to change at page 2, line 5
	The list of current Internet-Drafts can be accessed at		The list of current Internet-Drafts can be accessed at
	http://www.ietf.org/ietf/1id-abstracts.txt		http://www.ietf.org/ietf/1id-abstracts.txt
	The list of Internet-Draft Shadow Directories can be accessed at		The list of Internet-Draft Shadow Directories can be accessed at
	http://www.ietf.org/shadow.html.		http://www.ietf.org/shadow.html.
	Copyright Notice		Copyright Notice
	Copyright (C) The Internet Society (2004). All Rights Reserved.		Copyright (C) The Internet Society (2004). All Rights Reserved.
	Draft IPv6 Host to Router Load Sharing January 2004		Draft IPv6 Host to Router Load Sharing May 2004
	Abstract		Abstract
	The original IPv6 conceptual sending algorithm does not require		The original IPv6 conceptual sending algorithm does not do load-
	load-sharing among equivalent IPv6 routers, and suggests schemes		sharing among equivalent IPv6 routers, and suggests schemes which
	which can be problematic in practice. This document updates the		can be problematic in practice. This document updates the
	conceptual sending algorithm so that traffic to different		conceptual sending algorithm so that traffic to different
	destinations is distributed among routers in an efficient fashion.		destinations can be distributed among routers in an efficient
			fashion.
	1. Introduction		1. Introduction
	In the conceptual sending algorithm in [ND] and in the optional		In the conceptual sending algorithm in [ND] and in the optional
	extension in [ROUTERSEL], a next hop is chosen when no destination		extension in [ROUTERSEL], a next hop is chosen when no destination
	cache entry exists for an off-link destination or when		cache entry exists for an off-link destination or when
	communication through an existing router is failing. Normally a		communication through an existing router is failing. Normally a
	router is selected the first time traffic is sent to a specific		router is selected the first time traffic is sent to a specific
	destination IP address. Subsequent traffic to the same		destination IP address. Subsequent traffic to the same
	destination address continues to use the same router unless there		destination address continues to use the same router unless there
	is some reason to change to a different router (e.g., a redirect		is some reason to change to a different router (e.g., a redirect
	message is received, or a router is found to be unreachable).		message is received, or the router is found to be unreachable).
	In both the base algorithm and in the optional extension,		In both the base algorithm and in the optional extension,
	sometimes a host has a choice of multiple equivalent routers for a		sometimes a host has a choice of multiple equivalent routers for a
	destination. That is, all other factors are equal and a host must		destination. That is, all other factors are equal and a host must
	break a tie via some implementation-specific means.		break a tie via some implementation-specific means.
	It is desirable when there is more than one equivalent router that		It is typically desirable when there is more than one equivalent
	hosts distribute their outgoing traffic among these routers. This		router that hosts distribute their outgoing traffic among these
	shares the load among multiple routers and provides better		routers. This shares the load among multiple routers and provides
	performance for the host's traffic.		better performance for the host's traffic.
	[ND] does not require any particular behavior in this respect. It		[ND] does not require any particular behavior in this respect. It
	specifies that an implementation may always choose the same router		specifies that an implementation may always choose the same router
	(e.g., the first in the list) or may cycle through the routers in		(e.g., the first in the list) or may cycle through the routers in
	a round-robin manner. Both of these suggestions are problematic.		a round-robin manner. Both of these suggestions are problematic.
	Clearly, always choosing the same router does not provide load		Clearly, always choosing the same router does not provide load
	sharing. Some problems with naive tie-breaking techniques such as		sharing. Some problems with load sharing using naive tie-breaking
	round-robin and random are discussed in [MULTIPATH]. While the		techniques such as round-robin and random are discussed in
	destination cache provides some stability since the determination		[MULTIPATH]. While the destination cache provides some stability
	is not per-packet, cache evictions or timeouts can still result in		since the determination is not per-packet, cache evictions or
	unstable or unpredictable paths over time, lowering the		timeouts can still result in unstable or unpredictable paths over
	performance and making it harder to diagnose problems. Round-		time, lowering the performance and making it harder to diagnose
	robin selection may also result in synchronization issues among		problems. Round-robin selection may also result in
	hosts, where in the worst case the load is concentrated on one
	Draft IPv6 Host to Router Load Sharing January 2004		Draft IPv6 Host to Router Load Sharing May 2004
	router at a time.		synchronization issues among hosts, where in the worst case the
			load is concentrated on one router at a time.
	In the remainder of this document, the key words "MUST", "MUST		In the remainder of this document, the key words "MUST", "MUST
	NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT",		NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT",
	"RECOMMENDED", "MAY", and "OPTIONAL" are to be interpreted as		"RECOMMENDED", "MAY", and "OPTIONAL" are to be interpreted as
	described in [RFC2119].		described in [RFC2119].
	2. Load Sharing		2. Load Sharing
	When a host chooses from multiple equivalent routers, it MUST		When a host chooses from multiple equivalent routers, it SHOULD
	choose using some method which distributes load for different		support choosing using some method which distributes load for
	destinations among the equivalent routers. That is, a host MUST		different destinations among the equivalent routers rather than
	NOT always choose the same router (e.g., the first in the list).		always choosing the same router (e.g., the first in the list).
	A host SHOULD use a hash-based scheme, such as those described in		Furthermore, a host that does attempt to distribute load among
			routers SHOULD use a hash-based scheme, such as those described in
	[MULTIPATH], which takes the destination IP address into account.		[MULTIPATH], which takes the destination IP address into account.
	Note that traffic for a given destination address will use the		Note that traffic for a given destination address will use the
	same router as long as the Destination Cache Entry for the		same router as long as the Destination Cache Entry for the
	destination address is not deleted. With a hash-based scheme,		destination address is not deleted. With a hash-based scheme,
	traffic for a given destination address will use the same router		traffic for a given destination address will use the same router
	over time even if the Destination Cache Entry is deleted, as long		over time even if the Destination Cache Entry is deleted, as long
	as the list of equivalent routers remains the same.		as the list of equivalent routers remains the same.
	3. Acknowledgments		3. Acknowledgments
	The authors of this document would like to thank Erik Nordmark,		The authors of this document would like to thank Erik Nordmark,
	Brian Haberman, Steve Deering, Aron Silverton, and Christian		Brian Haberman, Steve Deering, Aron Silverton, and Christian
	Huitema for their helpful suggestions.		Huitema.
	4. Security Considerations		4. Security Considerations
	As mentioned in [MULTIPATH], when next-hop selection is		As mentioned in [MULTIPATH], when next-hop selection is
	predictable, an application can synthesize traffic that will all		predictable, an application can synthesize traffic that will all
	hash the same, making it possible to launch a denial-of-service		hash the same, making it possible to launch a denial-of-service
	attack against the load sharing algorithm, and overload a		attack against the load sharing algorithm, and overload a
	particular router. A special case of this is when the same		particular router. This can even be done by a remote application
	(single) next-hop is always selected, such as in the algorithm		that can cause a host to respond to a given destination address.
	allowed by [ND]. Introducing hashing can make such an attack more		A special case of this is when the same (single) next-hop is
	difficult; the more unpredictable the hash is, the harder it		always selected, such as in the algorithm allowed by [ND].
	becomes to conduct a denial-of-service attack against any single		Introducing hashing can make such an attack more difficult; the
	router.
	Draft IPv6 Host to Router Load Sharing January 2004		Draft IPv6 Host to Router Load Sharing May 2004
			more unpredictable the hash is, the harder it becomes to conduct a
			denial-of-service attack against any single router.
	5. Normative References		5. Normative References
	[ND] Narten, T., Nordmark, E. and W. Simpson, "Neighbor Discovery		[ND] Narten, T., Nordmark, E. and W. Simpson, "Neighbor Discovery
	for IP Version 6 (IPv6)", RFC 2461, December 1998.		for IP Version 6 (IPv6)", RFC 2461, December 1998.
	[RFC2119]		[RFC2119]
	Bradner, S., "Key words for use in RFCs to Indicate		Bradner, S., "Key words for use in RFCs to Indicate
	Requirement Levels", RFC 2119, BCP0014, March 1997.		Requirement Levels", RFC 2119, BCP0014, March 1997.
	skipping to change at page 4, line 43		skipping to change at page 5, line 5
	Phone: +1 650 625-2004		Phone: +1 650 625-2004
	Email: bob.hinden@nokia.com		Email: bob.hinden@nokia.com
	Dave Thaler		Dave Thaler
	Microsoft Corporation		Microsoft Corporation
	One Microsoft Way		One Microsoft Way
	Redmond, WA 98052		Redmond, WA 98052
	Phone: +1 425 703 8835		Phone: +1 425 703 8835
	EMail: dthaler@microsoft.com		EMail: dthaler@microsoft.com
			Draft IPv6 Host to Router Load Sharing May 2004
	8. Revision History		8. Revision History
	(This section to be removed before publication as an RFC)		(This section to be removed before publication as an RFC)
	Changes from draft-ietf-ipv6-router-selection-02.txt:		Changes from draft-ietf-ipv6-load-sharing-01.txt:
	Draft IPv6 Host to Router Load Sharing January 2004		o Changed load sharing from a MUST to a SHOULD.
			o Added standard IETF intellectual property notice.
			Changes from draft-ietf-ipv6-router-selection-02.txt:
	o Split load sharing back into its own document.		o Split load sharing back into its own document.
	o Made hash-based, rather than random, the rule.		o Made hash-based, rather than random, the rule.
	9. Full Copyright Statement		9. Full Copyright Statement
	Copyright (C) The Internet Society (2004). All Rights Reserved.		Copyright (C) The Internet Society (2004). All Rights Reserved.
	This document and translations of it may be copied and furnished		This document and translations of it may be copied and furnished
	skipping to change at line 204		skipping to change at page 6, line 4
	The limited permissions granted above are perpetual and will not		The limited permissions granted above are perpetual and will not
	be revoked by the Internet Society or its successors or assigns.		be revoked by the Internet Society or its successors or assigns.
	This document and the information contained herein is provided on		This document and the information contained herein is provided on
	an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET		an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET
	ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR		ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR
	IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF		IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
	THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED		THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
	WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.		WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
			Draft IPv6 Host to Router Load Sharing May 2004
			10. Intellectual Property
			The IETF takes no position regarding the validity or scope of any
			Intellectual Property Rights or other rights that might be claimed
			to pertain to the implementation or use of the technology
			described in this document or the extent to which any license
			under such rights might or might not be available; nor does it
			represent that it has made any independent effort to identify any
			such rights. Information on the procedures with respect to rights
			in RFC documents can be found in BCP 78 and BCP 79.
			Copies of IPR disclosures made to the IETF Secretariat and any
			assurances of licenses to be made available, or the result of an
			attempt made to obtain a general license or permission for the use
			of such proprietary rights by implementers or users of this
			specification can be obtained from the IETF on-line IPR repository
			at http://www.ietf.org/ipr.
			The IETF invites any interested party to bring to its attention
			any copyrights, patents or patent applications, or other
			proprietary rights that may cover technology that may be required
			to implement this standard. Please address the information to the
			IETF at ietf-ipr@ietf.org.
End of changes.
This html diff was produced by rfcdiff 1.23, available from http://www.levkowetz.com/ietf/tools/rfcdiff/