draft-ietf-ipv6-host-load-sharing-03.txt		draft-ietf-ipv6-host-load-sharing-04.txt
	IPv6 Working Group R. Hinden		IPv6 Working Group R. Hinden
	INTERNET-DRAFT Nokia		INTERNET-DRAFT Nokia
	October 18, 2004 D. Thaler		June 23, 2005 D. Thaler
	Expires April 2005 Microsoft		Expires December 2005 Microsoft
	IPv6 Host to Router Load Sharing		IPv6 Host to Router Load Sharing
	<draft-ietf-ipv6-host-load-sharing-03.txt>		<draft-ietf-ipv6-host-load-sharing-04.txt>
	Status of this Memo		Status of this Memo
	By submitting this Internet-Draft, I certify that any applicable		By submitting this Internet-Draft, each author represents that any
	patent or other IPR claims of which I am aware have been		applicable patent or other IPR claims of which he or she is aware
	disclosed, or will be disclosed, and any of which I become aware		have been or will be disclosed, and any of which he or she becomes
	will be disclosed, in accordance with RFC 3668.		aware will be disclosed, in accordance with Section 6 of BCP 79.
	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.
	Internet-Drafts are draft documents valid for a maximum of six		Internet-Drafts are draft documents valid for a maximum of six
	months and may be updated, replaced, or obsoleted by other		months and may be updated, replaced, or obsoleted by other
	documents at any time. It is inappropriate to use Internet-Drafts		documents at any time. It is inappropriate to use Internet-Drafts
	as reference material or to cite them other than as "work in		as reference material or to cite them other than as "work in
	progress."		progress."
	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
	Draft IPv6 Host to Router Load Sharing October 2004		Draft IPv6 Host to Router Load Sharing June 2005
	Copyright (C) The Internet Society (2004). All Rights Reserved.		Copyright (C) The Internet Society (2005). All Rights Reserved.
	Abstract		Abstract
	The original IPv6 conceptual sending algorithm does not do load-		The original IPv6 conceptual sending algorithm does not do load-
	sharing among equivalent IPv6 routers, and suggests schemes which		sharing among equivalent IPv6 routers, and suggests schemes 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 in RFC 2461 so that traffic to
	destinations can be distributed among routers in an efficient		different destinations can be distributed among routers in an
	fashion.		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
	skipping to change at page 2, line 40		skipping to change at page 2, line 40
	In addition, as described in [ADDRSEL], the choice of next hop may		In addition, as described in [ADDRSEL], the choice of next hop may
	also affect the choice of source address, and hence indirectly		also affect the choice of source address, and hence indirectly
	(and to a lesser extent) may affect the router used for inbound		(and to a lesser extent) may affect the router used for inbound
	traffic as well.		traffic as well.
	In both the base sending algorithm and in the optional extension,		In both the base sending 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 typically desirable when there is more than one equivalent		It is often desirable when there is more than one equivalent
	router that hosts distribute their outgoing traffic among these		router that hosts distribute their outgoing traffic among these
	routers. This shares the load among multiple routers and provides		routers. This shares the load among multiple routers and provides
	better performance for the host's traffic.		better performance for the host's traffic.
	On the other hand, load sharing can be undesirable in situations		On the other hand, load sharing can be undesirable in situations
	where sufficient capacity is available through a single router and		where sufficient capacity is available through a single router and
	the traffic patterns could be more predictable by using a single		the traffic patterns could be more predictable by using a single
	router; in particular, this helps to diagnose connectivity		router; in particular, this helps to diagnose connectivity
	problems beyond the first-hop routers.		problems beyond the first-hop routers.
	Draft IPv6 Host to Router Load Sharing October 2004		Draft IPv6 Host to Router Load Sharing June 2005
	[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 load sharing using naive tie-breaking		sharing. Some problems with load sharing using naive tie-breaking
	techniques such as round-robin and random are discussed in		techniques such as round-robin and random are discussed in
	[MULTIPATH]. While the destination cache provides some stability		[MULTIPATH]. While the destination cache provides some stability
	skipping to change at page 3, line 37		skipping to change at page 3, line 37
	2. Load Sharing		2. Load Sharing
	When a host chooses from multiple equivalent routers, it SHOULD		When a host chooses from multiple equivalent routers, it SHOULD
	support choosing using some method which distributes load for		support choosing using some method which distributes load for
	different destinations among the equivalent routers rather than		different destinations among the equivalent routers rather than
	always choosing the same router (e.g., the first in the list).		always choosing the same router (e.g., the first in the list).
	This memo takes no stance on whether the support for load sharing		This memo takes no stance on whether the support for load sharing
	should be turned on or off by default. Furthermore, a host that		should be turned on or off by default. Furthermore, a host that
	does attempt to distribute load among routers SHOULD use a hash-		does attempt to distribute load among routers SHOULD use a hash-
	based scheme which takes the destination IP address into account,		based scheme which takes (at least) the destination IP address
	such as those described in [MULTIPATH], for choosing a router to		into account, such as those described in [MULTIPATH], for choosing
	use.		a router to use.
	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.
	Draft IPv6 Host to Router Load Sharing October 2004		Draft IPv6 Host to Router Load Sharing June 2005
	3. Security Considerations		3. 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. This can even be done by a remote application		particular router. This can even be done by a remote application
	that can cause a host to respond to a given destination address.		that can cause a host to respond to a given destination address.
	A special case of this is when the same (single) next-hop is		A special case of this is when the same (single) next-hop is
	skipping to change at page 5, line 5		skipping to change at page 5, line 5
	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.
	[ADDRSEL]		[ADDRSEL]
	Draves, R., "Default Address Selection for Internet Protocol		Draves, R., "Default Address Selection for Internet Protocol
	version 6 (IPv6)", RFC 3484, February 2003.		version 6 (IPv6)", RFC 3484, February 2003.
	Draft IPv6 Host to Router Load Sharing October 2004		Draft IPv6 Host to Router Load Sharing June 2005
			[ROUTERSEL]
			Draves, R. and D. Thaler, "Default Router Preferences and
			More-Specific Routes", Work in progress, draft-ietf-
			ipv6-router-selection-07.txt, January 2005.
	7. Informative References		7. Informative References
	[MULTIPATH]		[MULTIPATH]
	Thaler, D. and C. Hopps, "Multipath Issues in Unicast and		Thaler, D. and C. Hopps, "Multipath Issues in Unicast and
	Multicast Next-Hop Selection", RFC 2991, November 2000.		Multicast Next-Hop Selection", RFC 2991, November 2000.
	[ROUTERSEL]
	Draves, R. and D. Thaler, "Default Router Preferences and
	More-Specific Routes", Work in progress, draft-ietf-
	ipv6-router-selection-03.txt, December 2003.
	8. Authors' Addresses		8. Authors' Addresses
	Robert Hinden		Robert Hinden
	Nokia		Nokia
	313 Fairchild Drive		313 Fairchild Drive
	Mountain View, CA 94043		Mountain View, CA 94043
	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
	9. Full Copyright Statement		9. Full Copyright Statement
	Copyright (C) The Internet Society (2004). This document is		Copyright (C) The Internet Society (2005). This document is
	subject to the rights, licenses and restrictions contained in BCP		subject to the rights, licenses and restrictions contained in BCP
	78, and except as set forth therein, the authors retain all their		78, and except as set forth therein, the authors retain all their
	rights.		rights.
	This document and the information contained herein are provided on		This document and the information contained herein are provided on
	an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE		an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE
	REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND		REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND
	THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES,		THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES,
	EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT		EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT
	THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR		THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR
	ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A		ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A
	PARTICULAR PURPOSE.		PARTICULAR PURPOSE.
	Draft IPv6 Host to Router Load Sharing October 2004		Draft IPv6 Host to Router Load Sharing June 2005
	10. Intellectual Property		10. Intellectual Property
	The IETF takes no position regarding the validity or scope of any		The IETF takes no position regarding the validity or scope of any
	Intellectual Property Rights or other rights that might be claimed		Intellectual Property Rights or other rights that might be claimed
	to pertain to the implementation or use of the technology		to pertain to the implementation or use of the technology
	described in this document or the extent to which any license		described in this document or the extent to which any license
	under such rights might or might not be available; nor does it		under such rights might or might not be available; nor does it
	represent that it has made any independent effort to identify any		represent that it has made any independent effort to identify any
	such rights. Information on the procedures with respect to rights		such rights. Information on the procedures with respect to rights
End of changes.
This html diff was produced by rfcdiff 1.24, available from http://www.levkowetz.com/ietf/tools/rfcdiff/