< draft-ietf-ipv6-router-selection-06.txt		draft-ietf-ipv6-router-selection-07.txt >
	IPng Working Group R. Draves		IPng Working Group R. Draves
	Internet Draft D. Thaler		Internet Draft D. Thaler
	Document: draft-ietf-ipv6-router-selection-06.txt Microsoft		Document: draft-ietf-ipv6-router-selection-07.txt Microsoft
	October 11, 2004		January 17, 2005
	Default Router Preferences and More-Specific Routes		Default Router Preferences and More-Specific Routes
	Status of this Memo		Status of this Memo
	By submitting this Internet-Draft, I certify that any applicable		By submitting this Internet-Draft, I certify that any applicable
	patent or other IPR claims of which I am aware have been disclosed,		patent or other IPR claims of which I am aware have been disclosed,
	or will be disclosed, and any of which I become aware will be		or will be disclosed, and any of which I become aware will be
	disclosed, in accordance with RFC 3668.		disclosed, in accordance with RFC 3668.
	skipping to change at line 34 ¶		skipping to change at line 34 ¶
	material or to cite them other than as "work in progress."		material or to cite them other than as "work in 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
	Copyright (C) The Internet Society (2004). All Rights Reserved.		Copyright (C) The Internet Society (2005). All Rights Reserved.
	Abstract		Abstract
	This document describes an optional extension to Router		This document describes an optional extension to Router
	Advertisement messages for communicating default router preferences		Advertisement messages for communicating default router preferences
	and more-specific routes from routers to hosts. This improves the		and more-specific routes from routers to hosts. This improves the
	ability of hosts to pick an appropriate router, especially when the		ability of hosts to pick an appropriate router, especially when the
	host is multi-homed and the routers are on different links. The		host is multi-homed and the routers are on different links. The
	preference values and specific routes advertised to hosts require		preference values and specific routes advertised to hosts require
	administrative configuration; they are not automatically derived		administrative configuration; they are not automatically derived
	skipping to change at line 110 ¶		skipping to change at line 110 ¶
	standard, stable protocol for router-to-host communication.		standard, stable protocol for router-to-host communication.
	Piggybacking this information on existing message traffic from		Piggybacking this information on existing message traffic from
	routers to hosts reduces network overhead. Neighbor Discovery shares		routers to hosts reduces network overhead. Neighbor Discovery shares
	with Multicast Listener Discovery the property that they both define		with Multicast Listener Discovery the property that they both define
	host-to-router interactions, while shielding the host from having to		host-to-router interactions, while shielding the host from having to
	participate in more general router-to-router interactions. In		participate in more general router-to-router interactions. In
	addition, RIP is unsuitable because it does not carry route		addition, RIP is unsuitable because it does not carry route
	lifetimes so it requires frequent message traffic with greater		lifetimes so it requires frequent message traffic with greater
	processing overheads.		processing overheads.
	In addition, this document addresses the problem of tracking
	reachability of a hostÆs routers so that it does not try to use
	routers which it believes are unreachable. Using end-to-end
	information is required to solve cases where the router advertises
	itself to hosts, but the path to the desired destination is broken
	at some other point. This problem is outside the scope of this
	document and is left for future work.
	The mechanisms specified here are backwards-compatible, so that		The mechanisms specified here are backwards-compatible, so that
	hosts that do not implement them continue to function as well as		hosts that do not implement them continue to function as well as
	they did previously.		they did previously.
	1.1. Conventions used in this document		1.1. Conventions used in this document
	The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",		The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
	"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in		"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in
	this document are to be interpreted as described in [RFC2119].		this document are to be interpreted as described in [RFC2119].
	skipping to change at line 356 ¶		skipping to change at line 346 ¶
	values. If the host has no information about the router's		values. If the host has no information about the router's
	reachability then the host assumes the router is reachable.		reachability then the host assumes the router is reachable.
	When a type C host does next-hop determination and consults its		When a type C host does next-hop determination and consults its
	Routing Table for an off-link destination, it searches its routing		Routing Table for an off-link destination, it searches its routing
	table to find the route with the longest prefix that matches the		table to find the route with the longest prefix that matches the
	destination, using route preference values as a tie-breaker if		destination, using route preference values as a tie-breaker if
	multiple matching routes have the same prefix length. If the best		multiple matching routes have the same prefix length. If the best
	route points to a non-reachable router, this router is remembered		route points to a non-reachable router, this router is remembered
	for the algorithm described in section 3.5 below, and the next best		for the algorithm described in section 3.5 below, and the next best
	route is consulted. This check is repeated until a route is found		route is consulted. This check is repeated until a matching route
	that points to a reachable router, or no matching routes remain.		is found that points to a reachable router, or no matching routes
	Again, if the host has no information about the router's		remain. Again, if the host has no information about the router's
	reachability then the host assumes the router is reachable.		reachability then the host assumes the router is reachable.
	If there are no routes matching the destination (i.e., no default		If there are no routes matching the destination (i.e., no default
	routes and no more-specific routes), then a type C host SHOULD		routes and no more-specific routes), then a type C host SHOULD
	discard the packet and report a Destination Unreachable / No Route		discard the packet and report a Destination Unreachable / No Route
	To Destination error to the upper layer.		To Destination error to the upper layer.
	3.3. Destination Cache Management		3.3. Destination Cache Management
	When a type C host processes a Router Advertisement and updates its		When a type C host processes a Router Advertisement and updates its
	skipping to change at line 429 ¶		skipping to change at line 419 ¶
	reachable, then the host should use Y while probing the reachability		reachable, then the host should use Y while probing the reachability
	of W and Z. Router X will never be chosen because its prefix does		of W and Z. Router X will never be chosen because its prefix does
	not match the destination.		not match the destination.
	4. Router Configuration		4. Router Configuration
	Routers SHOULD NOT advertise preferences or routes by default. In		Routers SHOULD NOT advertise preferences or routes by default. In
	particular, they SHOULD NOT "dump out" their entire routing table to		particular, they SHOULD NOT "dump out" their entire routing table to
	hosts.		hosts.
			Routers MAY have a configuration mode where announcement of a
			specific prefix is dependent on a specific condition, such as
			operational status of a link or presence of the same or another
			prefix in the routing table installed by another source, such as a
			dynamic routing protocol. If done, router implementations SHOULD
			make sure that announcement of prefixes to hosts is decoupled from
			the routing table dynamics to prevent excessive load on hosts during
			periods of routing instability. In particular, unstable routes
			SHOULD NOT be announced to hosts until their stability has improved.
	Routers SHOULD NOT send more than 17 Route Information Options in		Routers SHOULD NOT send more than 17 Route Information Options in
	Router Advertisements per link. This arbitrary bound is meant to		Router Advertisements per link. This arbitrary bound is meant to
	reinforce that relatively few and carefully selected routes should		reinforce that relatively few and carefully selected routes should
	be advertised to hosts.		be advertised to hosts.
	The preference values (both Default Router Preferences and Route		The preference values (both Default Router Preferences and Route
	Preferences) SHOULD NOT be routing metrics or automatically derived		Preferences) SHOULD NOT be routing metrics or automatically derived
	from metrics: the preference values SHOULD be configured.		from metrics: the preference values SHOULD be configured.
	The information contained in Router Advertisements may change		The information contained in Router Advertisements may change
	skipping to change at line 597 ¶		skipping to change at line 597 ¶
	work in progress in the SEND WG on securing router discovery		work in progress in the SEND WG on securing router discovery
	messages that will address these problems.		messages that will address these problems.
	7. IANA Considerations		7. IANA Considerations
	Section 2.3 defines a new Neighbor Discovery [RFC2461] option, the		Section 2.3 defines a new Neighbor Discovery [RFC2461] option, the
	Route Information Option, which has been assigned the value TBD		Route Information Option, which has been assigned the value TBD
	within the numbering space for IPv6 Neighbor Discovery Option		within the numbering space for IPv6 Neighbor Discovery Option
	Formats.		Formats.
	RFC EDITORÆs NOTE (to be removed prior to publication): the IANA is		RFC EDITOR's NOTE (to be removed prior to publication): the IANA is
	requested to assign a value for "TBD" in the IPv6 Neighbor Discovery		requested to assign a value for "TBD" in the IPv6 Neighbor Discovery
	Option Formats. When the assignment has been made, the RFC Editor		Option Formats. When the assignment has been made, the RFC Editor
	is asked to replace "TBD" (above in this section, and in section		is asked to replace "TBD" (above in this section, and in section
	2.3) with the assigned value and to remove this note.		2.3) with the assigned value and to remove this note.
	8. Acknowledgments		8. Acknowledgments
	The authors would like to acknowledge the contributions of Balash		The authors would like to acknowledge the contributions of Balash
	Akbari, Steve Deering, Robert Elz, Tony Hain, Bob Hinden, Christian		Akbari, Steve Deering, Robert Elz, Tony Hain, Bob Hinden, Christian
	Huitema, JINMEI Tatuya, Erik Nordmark, Pekka Savola, Kresimir		Huitema, JINMEI Tatuya, Erik Nordmark, Pekka Savola, Kresimir
	Segaric, and Brian Zill. The packet diagrams are derived from		Segaric, and Brian Zill. The packet diagrams are derived from
	Neighbor Discovery [RFC2461].		Neighbor Discovery [RFC2461].
	9. Normative References		9. Normative References
			[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
			Requirement Levels", BCP 14, RFC 2119, March 1997.
	[RFC2461] Narten, T., Nordmark, E. and W. Simpson, "Neighbor		[RFC2461] Narten, T., Nordmark, E. and W. Simpson, "Neighbor
	Discovery for IP Version 6 (IPv6)", RFC 2461, December		Discovery for IP Version 6 (IPv6)", RFC 2461, December
	1998.		1998.
	[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
	Requirement Levels", BCP 14, RFC 2119, March 1997.
	[RFC3775] Johnson, D., Perkins, C. and J. Arkko, "Mobility Support		[RFC3775] Johnson, D., Perkins, C. and J. Arkko, "Mobility Support
	in IPv6", RFC 3775, June 2004.		in IPv6", RFC 3775, June 2004.
	10. Informative References		10. Informative References
	[RFC3056] Carpenter, B. and K. Moore, "Connection of IPv6 Domains		[RFC2080] Malkin, G. and R. Minnear, "RIPng for IPv6", RFC 2080,
	via IPv4 Clouds", RFC 3056, February 2001.		January 1997.
	[RFC2983] Gilligan, R. and E. Nordmark, "Transition Mechanisms for		[RFC2893] Gilligan, R. and E. Nordmark, "Transition Mechanisms for
	IPv6 Hosts and Routers", RFC 2893, August 2000.		IPv6 Hosts and Routers", RFC 2893, August 2000.
	[RFC2080] Malkin, G. and R. Minnear, "RIPng for IPv6", RFC 2080,		[RFC3056] Carpenter, B. and K. Moore, "Connection of IPv6 Domains
	January 1997.		via IPv4 Clouds", RFC 3056, February 2001.
	[RFC3756] Nikander, P., Ed., Kempf, J. and E. Nordmark, "IPv6		[RFC3756] Nikander, P., Ed., Kempf, J. and E. Nordmark, "IPv6
	Neighbor Discovery (ND) Trust Models and Threats", RFC		Neighbor Discovery (ND) Trust Models and Threats", RFC
	3756, May 2004.		3756, May 2004.
	Authors' Addresses		Authors' Addresses
	Richard Draves		Richard Draves
	Microsoft Research		Microsoft Research
	One Microsoft Way		One Microsoft Way
	skipping to change at line 655 ¶		skipping to change at line 655 ¶
	Email: richdr@microsoft.com		Email: richdr@microsoft.com
	Dave Thaler		Dave Thaler
	Microsoft		Microsoft
	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
	Full Copyright Statement		Full Copyright Statement
	Copyright (C) The Internet Society (2004). This document is subject		Copyright (C) The Internet Society (2005). This document is subject
	to the rights, licenses and restrictions contained in BCP 78, and		to the rights, licenses and restrictions contained in BCP 78, and
	except as set forth therein, the authors retain all their rights.		except as set forth therein, the authors retain all their 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 THE		REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE
	INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR		INTERNET ENGINEERING TASK FORCE DISCLAIM 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.
End of changes. 12 change blocks.
	26 lines changed or deleted		28 lines changed or added
This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/