draft-ietf-ipv6-host-load-sharing-00.txt		draft-ietf-ipv6-host-load-sharing-01.txt
	INTERNET-DRAFT R. Hinden/Nokia		IPv6 Working Group R. Hinden
	January 4, 2002		INTERNET-DRAFT Nokia
			January 26, 2004 D. Thaler
			Expires July 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-00.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.
	Internet-Drafts are draft documents valid for a maximum of six months		Internet-Drafts are draft documents valid for a maximum of six
	and may be updated, replaced, or obsoleted by other documents at any		months and may be updated, replaced, or obsoleted by other
	time. It is inappropriate to use Internet-Drafts as reference		documents at any time. It is inappropriate to use Internet-
	material or to cite them other than as "work in progress."		Drafts as reference material or to cite them other than as "work
			in progress."
	To view the list Internet-Draft Shadow Directories, see		The list of current Internet-Drafts can be accessed at
			http://www.ietf.org/ietf/1id-abstracts.txt
			The list of Internet-Draft Shadow Directories can be accessed at
	http://www.ietf.org/shadow.html.		http://www.ietf.org/shadow.html.
	This internet draft expires on July 4, 2002.		Copyright Notice
	Abstract		Copyright (C) The Internet Society (2004). All Rights Reserved.
	This document defines a change to IPv6 Neighbor Discovery that IPv6		Draft IPv6 Host to Router Load Sharing January 2004
	hosts can use to load share their outgoing traffic between multiple
	default routers.
	1. Introduction		Abstract
	IPv6 hosts on a LAN will usually learn about default routers by		The original IPv6 conceptual sending algorithm does not require
	receiving Router Advertisements sent using the IPv6 Neighbor		load-sharing among equivalent IPv6 routers, and suggests schemes
	Discovery protocol [ND]. If there are multiple routers the hosts		which can be problematic in practice. This document updates the
	will automatically learn about them and have multiple default routers		conceptual sending algorithm so that traffic to different
	to send off link traffic.		destinations is distributed among routers in an efficient fashion.
	IPv6 Neighbor Discovery protocol does not require any specific		1. Introduction
	procedure for hosts to divide (i.e., load share) outgoing traffic
	between these routers. This document defines procedures that IPv6
	hosts can use to load share their outgoing traffic between multiple
	default routers.
	The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",		In the conceptual sending algorithm in [ND] and in the optional
	"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this		extension in [ROUTERSEL], a next hop is chosen when no destination
	document are to be interpreted as described in [RFC 2119].		cache entry exists for an off-link destination or when
			communication through an existing router is failing. Normally a
			router is selected the first time traffic is sent to a specific
			destination IP address. Subsequent traffic to the same
			destination address continues to use the same router unless there
			is some reason to change to a different router (e.g., a redirect
			message is received, or a router is found to be unreachable).
	2. Background		In both the base algorithm and in the optional extension,
			sometimes a host has a choice of multiple equivalent routers for a
			destination. That is, all other factors are equal and a host must
			break a tie via some implementation-specific means.
	RFC2461 "Neighbor Discovery for IPv6" [ND] defines in section 6.3.6		It is desirable when there is more than one equivalent router that
	an algorithm for selecting default routers. This algorithm is		hosts distribute their outgoing traffic among these routers. This
	invoked during next hop determination when no destination cache entry		shares the load among multiple routers and provides better
	exists for an off-link destination or when communication through an		performance for the host's traffic.
	existing router is failing. Normally a router would be selected the
	first time traffic is sent to a specific destination. Subsequent
	traffic to the same destination would continue to use this router
	unless there was some other reason to change to a different router
	(e.g., redirect message received, etc.).
	ND further specifies that when there are multiple reachable default		[ND] does not require any particular behavior in this respect. It
	routers, an implementation may always return the same router (e.g.,		specifies that an implementation may always choose the same router
	the first in the list) or may cycle through the list of reachable		(e.g., the first in the list) or may cycle through the routers in
	default routers in a round robin manner. It does not require any		a round-robin manner. Both of these suggestions are problematic.
	specific behavior in the case of multiple default routers.
	It is desirable when there is more than one default router that the		Clearly, always choosing the same router does not provide load
	hosts distribute their outgoing traffic among these routers. This		sharing. Some problems with naive tie-breaking techniques such as
	document changes the ND behavior to require that an implementation		round-robin and random are discussed in [MULTIPATH]. While the
	cycle through the list of default routers in a random order.		destination cache provides some stability since the determination
			is not per-packet, cache evictions or timeouts can still result in
			unstable or unpredictable paths over time, lowering the
			performance and making it harder to diagnose problems. Round-
			robin selection may also result in synchronization issues among
			hosts, where in the worst case the load is concentrated on one
	3. Load Sharing		Draft IPv6 Host to Router Load Sharing January 2004
	The load sharing algorithm changes the currently specified default		router at a time.
	router selection algorithm to cycle through the list of reachable
	default routers in random order. This should have the effect of
	distributing outgoing traffic for new destinations among the default
	routers. Random selection, versus round robin, is used to avoid
	synchronization in the hosts selection of a default router.
	Bullet 1) in section 6.3.6 "Default Router Selection" [ND] is		In the remainder of this document, the key words "MUST", "MUST
	replaced with the following:		NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT",
			"RECOMMENDED", "MAY", and "OPTIONAL" are to be interpreted as
			described in [RFC2119].
	1) Routers that are reachable or probably reachable (i.e., in any		2. Load Sharing
	state other than INCOMPLETE) SHOULD be preferred over routers
	whose reachability is unknown or suspect (i.e., in the
	INCOMPLETE state, or for which no Neighbor Cache entry exists).
	An implementation SHOULD pick routers from the default router
	list in random order while making sure it always returns a
	reachable or a probably reachable router when one is available.
	4. Acknowledgments		When a host chooses from multiple equivalent routers, it MUST
			choose using some method which distributes load for different
			destinations among the equivalent routers. That is, a host MUST
			NOT always choose the same router (e.g., the first in the list).
			A host SHOULD use a hash-based scheme, such as those described in
			[MULTIPATH], which takes the destination IP address into account.
	The author of this document would like to thank Erik Nordmark, Brian		Note that traffic for a given destination address will use the
	Haberman, Steve Deering, Aron Silverton, and Christian Huitema for		same router as long as the Destination Cache Entry for the
	their helpful suggestions.		destination address is not deleted. With a hash-based scheme,
			traffic for a given destination address will use the same router
			over time even if the Destination Cache Entry is deleted, as long
			as the list of equivalent routers remains the same.
	5. Security Considerations		3. Acknowledgments
	This document requires an node to cycle through a the list of default		The authors of this document would like to thank Erik Nordmark,
	routers. There are no known security issues with this change to IPv6		Brian Haberman, Steve Deering, Aron Silverton, and Christian
	Neighbor Discovery.		Huitema for their helpful suggestions.
	6. References		4. Security Considerations
	[ADD-ARH] Hinden, R., S. Deering, "IP Version 6 Addressing		As mentioned in [MULTIPATH], when next-hop selection is
	Architecture", RFC2373, July 1988.		predictable, an application can synthesize traffic that will all
			hash the same, making it possible to launch a denial-of-service
			attack against the load sharing algorithm, and overload a
			particular router. A special case of this is when the same
			(single) next-hop is always selected, such as in the algorithm
			allowed by [ND]. Introducing hashing can make such an attack more
			difficult; the more unpredictable the hash is, the harder it
			becomes to conduct a denial-of-service attack against any single
			router.
	[ICMPv6] Conta, A., S. Deering, "Internet Control Message Protocol		Draft IPv6 Host to Router Load Sharing January 2004
	(ICMPv6) for the Internet Protocol Version 6 (IPv6)",
	RFC2463, December 1998.
	[IPv6] Deering, S., R. Hinden, "Internet Protocol, Version 6		5. Normative References
	(IPv6) Specification", RFC2460, December 1998.
	[ND] Narten, T., E. Nordmark, W. Simpson, "Neighbor Discovery		[ND] Narten, T., Nordmark, E. and W. Simpson, "Neighbor Discovery
	for IP Version 6 (IPv6)", RFC2461, December 1998.		for IP Version 6 (IPv6)", RFC2461, December 1998.
	[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate		[RFC2119]
			Bradner, S., "Key words for use in RFCs to Indicate
	Requirement Levels", RFC2119, BCP0014, March 1997.		Requirement Levels", RFC2119, BCP0014, March 1997.
	7. Author's Address		6. Informative References
			[MULTIPATH]
			Thaler, D. and C. Hopps, "Multipath Issues in Unicast and
			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.
			7. Authors' Addresses
	Robert Hinden		Robert Hinden
	Nokia		Nokia
	313 Fairchild Drive		313 Fairchild Drive
	Mountain View, CA 94043		Mountain View, CA 94043
	US
	Phone: +1 650 625-2004		Phone: +1 650 625-2004
	Email: hinden@iprg.nokia.com		Email: bob.hinden@nokia.com
			Dave Thaler
			Microsoft Corporation
			One Microsoft Way
			Redmond, WA 98052
			Phone: +1 425 703 8835
			EMail: dthaler@microsoft.com
			8. Revision History
			(This section to be removed before publication as an RFC)
			Changes from draft-ietf-ipv6-router-selection-02.txt:
			Draft IPv6 Host to Router Load Sharing January 2004
			o Split load sharing back into its own document.
			o Made hash-based, rather than random, the rule.
			9. Full Copyright Statement
			Copyright (C) The Internet Society (2004). All Rights Reserved.
			This document and translations of it may be copied and furnished
			to others, and derivative works that comment on or otherwise
			explain it or assist in its implmentation may be prepared, copied,
			published and distributed, in whole or in part, without
			restriction of any kind, provided that the above copyright notice
			and this paragraph are included on all such copies and derivative
			works. However, this document itself may not be modified in any
			way, such as by removing the copyright notice or references to the
			Internet Society or other Internet organizations, except as needed
			for the purpose of developing Internet standards in which case the
			procedures for copyrights defined in the Internet Standards
			process must be followed, or as required to translate it into
			languages other than English.
			The limited permissions granted above are perpetual and will not
			be revoked by the Internet Society or its successors or assigns.
			This document and the information contained herein is provided on
			an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET
			ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR
			IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
			THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
			WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
End of changes.
This html diff was produced by rfcdiff 1.23, available from http://www.levkowetz.com/ietf/tools/rfcdiff/