draft-ietf-ipv6-2461bis-07.txt		draft-ietf-ipv6-2461bis-08.txt
	INTERNET-DRAFT T. Narten,		INTERNET-DRAFT T. Narten,
	Expires: November 2006 IBM		Expires: November 2006 IBM
	E. Nordmark,		Obsoletes: 2461 (if approved) E. Nordmark,
	Sun Microsystems		Sun Microsystems
	W. Simpson,		W. Simpson,
	Daydreamer		Daydreamer
	H. Soliman,		H. Soliman,
	Flarion		Flarion
	May, 2006		September, 2006
	Neighbor Discovery for IP version 6 (IPv6)		Neighbor Discovery for IP version 6 (IPv6)
	<draft-ietf-ipv6-2461bis-07.txt>		<draft-ietf-ipv6-2461bis-08.txt>
	Status of this memo		Status of this memo
	By submitting this Internet-Draft, each author represents that any		By submitting this Internet-Draft, each author represents that any
	applicable patent or other IPR claims of which he or she is aware		applicable patent or other IPR claims of which he or she is aware
	have been or will be disclosed, and any of which he or she becomes		have been or will be disclosed, and any of which he or she becomes
	aware will be disclosed, in accordance with Section 6 of BCP 79.		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 other		Task Force (IETF), its areas, and its working groups. Note that other
	groups may also distribute working documents as Internet-Drafts.		groups may also distribute working documents as Internet-Drafts.
	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 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/lid-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.
	This document is a submission of the IETF IPv6 WG. Comments should be		Copyright Notice
	directed to the IPv6 WG mailing list, ipv6@ietf.org.
			Copyright (C) The Internet Society (2006).
	Abstract		Abstract
	This document specifies the Neighbor Discovery protocol for IP		This document specifies the Neighbor Discovery protocol for IP
	Version 6. IPv6 nodes on the same link use Neighbor Discovery to		Version 6. IPv6 nodes on the same link use Neighbor Discovery to
	discover each other's presence, to determine each other's link-layer		discover each other's presence, to determine each other's link-layer
	addresses, to find routers and to maintain reachability information		addresses, to find routers and to maintain reachability information
	about the paths to active neighbors.		about the paths to active neighbors.
	Table of Contents		Table of Contents
	skipping to change at page 3, line 49		skipping to change at page 3, line 50
	REFERENCES.........................................................76		REFERENCES.........................................................76
	Authors' Addresses.................................................80		Authors' Addresses.................................................80
	APPENDIX A: MULTIHOMED HOSTS.......................................80		APPENDIX A: MULTIHOMED HOSTS.......................................80
	APPENDIX B: FUTURE EXTENSIONS......................................81		APPENDIX B: FUTURE EXTENSIONS......................................81
	APPENDIX C: STATE MACHINE FOR THE REACHABILITY STATE...............82		APPENDIX C: STATE MACHINE FOR THE REACHABILITY STATE...............82
	APPENDIX D: SUMMARY OF ISROUTER RULES..............................84		APPENDIX D: SUMMARY OF ISROUTER RULES..............................84
	APPENDIX E: IMPLEMENTATION ISSUES..................................85		APPENDIX E: IMPLEMENTATION ISSUES..................................85
	Appendix E.1: Reachability confirmations...........................85		Appendix E.1: Reachability confirmations...........................85
	APPENDIX F: CHANGES FROM RFC 2461..................................86		APPENDIX F: CHANGES FROM RFC 2461..................................87
	1. INTRODUCTION		1. INTRODUCTION
	This specification defines the Neighbor Discovery (ND) protocol for		This specification defines the Neighbor Discovery (ND) protocol for
	Internet Protocol Version 6 (IPv6). Nodes (hosts and routers) use		Internet Protocol Version 6 (IPv6). Nodes (hosts and routers) use
	Neighbor Discovery to determine the link-layer addresses for		Neighbor Discovery to determine the link-layer addresses for
	neighbors known to reside on attached links and to quickly purge		neighbors known to reside on attached links and to quickly purge
	cached values that become invalid. Hosts also use Neighbor Discovery		cached values that become invalid. Hosts also use Neighbor Discovery
	to find neighboring routers that are willing to forward packets on		to find neighboring routers that are willing to forward packets on
	their behalf. Finally, nodes use the protocol to actively keep track		their behalf. Finally, nodes use the protocol to actively keep track
	skipping to change at page 4, line 29		skipping to change at page 4, line 29
	over a particular link type) this document applies to all link types.		over a particular link type) this document applies to all link types.
	However, because ND uses link-layer multicast for some of its		However, because ND uses link-layer multicast for some of its
	services, it is possible that on some link types (e.g., NBMA links)		services, it is possible that on some link types (e.g., NBMA links)
	alternative protocols or mechanisms to implement those services will		alternative protocols or mechanisms to implement those services will
	be specified (in the appropriate document covering the operation of		be specified (in the appropriate document covering the operation of
	IP over a particular link type). The services described in this		IP over a particular link type). The services described in this
	document that are not directly dependent on multicast, such as		document that are not directly dependent on multicast, such as
	Redirects, Next-hop determination, Neighbor Unreachability Detection,		Redirects, Next-hop determination, Neighbor Unreachability Detection,
	etc., are expected to be provided as specified in this document. The		etc., are expected to be provided as specified in this document. The
	details of how one uses ND on NBMA links are addressed in [IPv6-		details of how one uses ND on NBMA links are addressed in [IPv6-
	NBMA]. In addition, [IPv6-3GPP] and [IPv6-CELLULAR] discuss the use		NBMA]. In addition, [IPv6-3GPP] and [IPv6-CELL] discuss the use of
	of this protocol over some cellular links, which are examples of NBMA		this protocol over some cellular links, which are examples of NBMA
	links.		links.
	The authors would like to acknowledge the contributions of the IPv6		The authors would like to acknowledge the contributions of the IPv6
	working group and, in particular, (in alphabetical order) Ran		working group and, in particular, (in alphabetical order) Ran
	Atkinson, Jim Bound, Scott Bradner, Alex Conta, Elwyn Davies, Stephen		Atkinson, Jim Bound, Scott Bradner, Alex Conta, Elwyn Davies, Stephen
	Deering Richard Draves, Francis Dupont, Robert Elz, Robert Gilligan,		Deering Richard Draves, Francis Dupont, Robert Elz, Robert Gilligan,
	Robert Hinden, Tatuya Jinmei, Allison Mankin, Dan McDonald, Charles		Robert Hinden, Tatuya Jinmei, Allison Mankin, Dan McDonald, Charles
	Perkins, Matt Thomas, and Susan Thomson.		Perkins, Matt Thomas, and Susan Thomson.
	2. TERMINOLOGY		2. TERMINOLOGY
	skipping to change at page 9, line 24		skipping to change at page 9, line 25
	all-routers multicast address		all-routers multicast address
	- the link-local scope address to reach all routers,		- the link-local scope address to reach all routers,
	FF02::2.		FF02::2.
	solicited-node multicast address		solicited-node multicast address
	- a link-local scope multicast address that is computed		- a link-local scope multicast address that is computed
	as a function of the solicited target's address. The		as a function of the solicited target's address. The
	function is described in [ADDR-ARCH]. The function is		function is described in [ADDR-ARCH]. The function is
	chosen so that IP addresses which differ only in the		chosen so that IP addresses which differ only in the
	least significant bits, e.g., due to multiple		most significant bits, e.g., due to multiple
	high-order prefixes associated with different		prefixes associated with different providers, will map
	providers, will map to the same solicited-node address		to the same solicited-node address thereby reducing the
	thereby reducing the number of multicast addresses a		number of multicast addresses a node must join.
	node must join.
	link-local address		link-local address
	- a unicast address having link-only scope that can be		- a unicast address having link-only scope that can be
	used to reach neighbors. All interfaces on routers		used to reach neighbors. All interfaces on routers
	MUST have a link-local address. Also, [ADDRCONF]		MUST have a link-local address. Also, [ADDRCONF]
	requires that interfaces on hosts have a link-local		requires that interfaces on hosts have a link-local
	address.		address.
	unspecified address		unspecified address
	- a reserved address value that indicates the lack of an		- a reserved address value that indicates the lack of an
	skipping to change at page 17, line 12		skipping to change at page 17, line 14
	The protocol can presumably be extended in the		The protocol can presumably be extended in the
	future to find viable paths in environments that		future to find viable paths in environments that
	lack reflexive and transitive connectivity.		lack reflexive and transitive connectivity.
	3.3. Securing Neighbor Discovery messages		3.3. Securing Neighbor Discovery messages
	Neighbor Discovery messages are needed for various functions. Several		Neighbor Discovery messages are needed for various functions. Several
	functions are designed to allow hosts to ascertain the ownership of		functions are designed to allow hosts to ascertain the ownership of
	an address or the mapping between link layer and IP layer addresses.		an address or the mapping between link layer and IP layer addresses.
	Having Neighbor Discovery functions on the ICMP layer allows for the
	use of IP layer security mechanisms, which are available
	independently of the availability of security on the link layer.
	Vulnerabilities related to Neighbor Discovery are discussed in		Vulnerabilities related to Neighbor Discovery are discussed in
	section 11.1. A general solution for securing Neighbor Discovery is		section 11.1. A general solution for securing Neighbor Discovery is
	outside the scope of this specification and is discussed in [SEND].		outside the scope of this specification and is discussed in [SEND].
	However, Section 11.2 explains how and under which constraints IPsec		However, Section 11.2 explains how and under which constraints IPsec
	AH or ESP can be used to secure Neighbor Discovery.		AH or ESP can be used to secure Neighbor Discovery.
	4. MESSAGE FORMATS		4. MESSAGE FORMATS
	4.1. Router Solicitation Message Format		4.1. Router Solicitation Message Format
	skipping to change at page 18, line 4		skipping to change at page 17, line 52
	to the sending interface.		to the sending interface.
	Destination Address		Destination Address
	Typically the all-routers multicast address.		Typically the all-routers multicast address.
	Hop Limit 255		Hop Limit 255
	ICMP Fields:		ICMP Fields:
	Type 133		Type 133
	Code 0
			Code 0
	Checksum The ICMP checksum. See [ICMPv6].		Checksum The ICMP checksum. See [ICMPv6].
	Reserved This field is unused. It MUST be initialized to		Reserved This field is unused. It MUST be initialized to
	zero by the sender and MUST be ignored by the		zero by the sender and MUST be ignored by the
	receiver.		receiver.
	Valid Options:		Valid Options:
	Source link-layer address		Source link-layer address
	The link-layer address of the sender, if known.		The link-layer address of the sender, if known.
	MUST NOT be included if the Source Address is the		MUST NOT be included if the Source Address is the
	skipping to change at page 74, line 46		skipping to change at page 74, line 43
	11.2 Securing Neighbor Discovery messages		11.2 Securing Neighbor Discovery messages
	The protocol reduces the exposure to the above threats in the absence		The protocol reduces the exposure to the above threats in the absence
	of authentication by ignoring ND packets received from off-link		of authentication by ignoring ND packets received from off-link
	senders. The Hop Limit field of all received packets is verified to		senders. The Hop Limit field of all received packets is verified to
	contain 255, the maximum legal value. Because routers decrement the		contain 255, the maximum legal value. Because routers decrement the
	Hop Limit on all packets they forward, received packets containing a		Hop Limit on all packets they forward, received packets containing a
	Hop Limit of 255 must have originated from a neighbor.		Hop Limit of 255 must have originated from a neighbor.
	In order to allow for IP layer authentication, a mechanism is		Cryptographic security mechanisms for Neighbor Discovery are outside
	required to allow for dynamic keying between neighbors. The use of		the scope of this document and are defined in [SEND]. Alternatively,
	the Internet Key Exchange [ICMPIKE] is not suited for creating		IPsec can be used for IP layer authentication. The use of the
	dynamic security associations that can be used to secure address		Internet Key Exchange (IKE) is not suited for creating dynamic
	resolution or neighbor solicitation messages as documented in		security associations that can be used to secure address resolution
	[ICMPIKE]. The security of Neighbor Discovery messages through		or neighbor solicitation messages as documented in [ICMPIKE].
	dynamic keying is outside the scope of this document and is addressed
	in [SEND].
	In some cases, it may be acceptable to use statically configured		In some cases, it may be acceptable to use statically configured
	security associations with either [IPv6-AH] or [IPv6-ESP] to secure		security associations with either [IPv6-AUTH] or [IPv6-ESP] to secure
	Neighbor Discovery messages. However, it is important to note that		Neighbor Discovery messages. However, it is important to note that
	statically configured security associations are not scalable		statically configured security associations are not scalable
	(especially when considering multicast links) and are therefore		(especially when considering multicast links) and are therefore
	limited to small networks with known hosts. In any case, if either		limited to small networks with known hosts. In any case, if either
	[IPv6-AH] or [IPv6-ESP] is used, ND packets MUST be verified for the		[IPv6-AUTH] or [IPv6-ESP] is used, ND packets MUST be verified for
	purpose of authentication. Packets that fail authentication checks		the purpose of authentication. Packets that fail authentication
	MUST be silently discarded.		checks MUST be silently discarded.
	12. RENUMBERING CONSIDERATIONS		12. RENUMBERING CONSIDERATIONS
	The Neighbor Discovery protocol together with IPv6 Address		The Neighbor Discovery protocol together with IPv6 Address
	Autoconfiguration [ADDRCONF] provides mechanisms to aid in		Autoconfiguration [ADDRCONF] provides mechanisms to aid in
	renumbering - new prefixes and addresses can be introduced and old		renumbering - new prefixes and addresses can be introduced and old
	ones can be deprecated and removed.		ones can be deprecated and removed.
	The robustness of these mechanisms is based on all the nodes on the		The robustness of these mechanisms is based on all the nodes on the
	link receiving the Router Advertisement messages in a timely manner.		link receiving the Router Advertisement messages in a timely manner.
	skipping to change at page 76, line 31		skipping to change at page 76, line 26
	sending Router Advertisements that contain appropriate (and current)		sending Router Advertisements that contain appropriate (and current)
	prefixes. A host connected to a network that has no functioning		prefixes. A host connected to a network that has no functioning
	routers is likely to have more serious problems than just a lack of a		routers is likely to have more serious problems than just a lack of a
	valid prefix and address.		valid prefix and address.
	The above discussion does not distinguish between the preferred and		The above discussion does not distinguish between the preferred and
	valid lifetimes. For all practical purposes it is probably		valid lifetimes. For all practical purposes it is probably
	sufficient to track the valid lifetime since the preferred lifetime		sufficient to track the valid lifetime since the preferred lifetime
	will not exceed the valid lifetime.		will not exceed the valid lifetime.
			13. IPR Acknowledgements
			By submitting this Internet-Draft, each author represents that any
			applicable patent or other IPR claims of which he or she is aware
			have been or will be disclosed, and any of which he or she becomes
			aware will be disclosed, in accordance with Section 6 of BCP 79.
	REFERENCES		REFERENCES
	NORMATIVE		NORMATIVE
	[ADDR-ARCH] Hinden, R. and S. Deering, "IP Version 6 Addressing		[ADDR-ARCH] Hinden, R. and S. Deering, "IP Version 6 Addressing
	Architecture", RFC 3513, April 2003.		Architecture", RFC 3513, April 2003.
	[ICMPv6] Conta, A. and S. Deering, "Internet Control Message		[ICMPv6] Conta, A. and S. Deering, "Internet Control Message
	Protocol (ICMPv6) for the Internet Protocol Version 6		Protocol (ICMPv6) for the Internet Protocol Version 6
	(IPv6) Specification", RFC 2463, December 1998.		(IPv6) Specification", RFC 2463, December 1998.
	skipping to change at page 77, line 18		skipping to change at page 77, line 20
	[ARP] Plummer, D., "An Ethernet Address Resolution Protocol",		[ARP] Plummer, D., "An Ethernet Address Resolution Protocol",
	STD 37, RFC 826, November 1982.		STD 37, RFC 826, November 1982.
	[ASSIGNED] Reynolds, J., "Assigned Numbers: RFC 1700 is Replaced by		[ASSIGNED] Reynolds, J., "Assigned Numbers: RFC 1700 is Replaced by
	an On-line Database", RFC 3232, January 2002.		an On-line Database", RFC 3232, January 2002.
	[DHCPv6] Droms, R., Ed, "Dynamic Host Configuration Protocol for		[DHCPv6] Droms, R., Ed, "Dynamic Host Configuration Protocol for
	IPv6 (DHCPv6)", RFC 3315, July 2003.		IPv6 (DHCPv6)", RFC 3315, July 2003.
	[DHCPv6lite] Droms, R., "Stateless Dynamic Host Configuration
	Protocol (DHCP)for IPv6", RFC 3736, April 2004.
	[HR-CL] Braden, R., Editor, "Requirements for Internet Hosts --		[HR-CL] Braden, R., Editor, "Requirements for Internet Hosts --
	Communication Layers", STD 3, RFC 1122, October 1989.		Communication Layers", STD 3, RFC 1122, October 1989.
	[ICMPIKE] Arkko, J., "Effects of ICMPv6 on IKE",		[ICMPIKE] Arkko, J., "Effects of ICMPv6 on IKE",
	draft-arkko-icmpv6-ike-effects-02 (work in progress),		draft-arkko-icmpv6-ike-effects-02 (work in progress),
	March 2003.		March 2003.
	[ICMPv4] Postel, J., "Internet Control Message Protocol", STD 5,		[ICMPv4] Postel, J., "Internet Control Message Protocol", STD 5,
	RFC 792, September 1981.		RFC 792, September 1981.
	skipping to change at page 77, line 50		skipping to change at page 77, line 49
	[IPv6-ETHER] Crawford, M., "Transmission of IPv6 Packets over		[IPv6-ETHER] Crawford, M., "Transmission of IPv6 Packets over
	Ethernet Networks", RFC 2464, December 1998.		Ethernet Networks", RFC 2464, December 1998.
	[IPv6-NBMA] Armitage, G., Schulter, P., Jork, M. and G. Harter, "		[IPv6-NBMA] Armitage, G., Schulter, P., Jork, M. and G. Harter, "
	IPv6 over Non-broadcast Multiple Access (NBMA)		IPv6 over Non-broadcast Multiple Access (NBMA)
	networks", RFC 2491, January 1999.		networks", RFC 2491, January 1999.
	[IPv6-SA] Kent, S. and R. Atkinson, "Security Architecture for the		[IPv6-SA] Kent, S. and R. Atkinson, "Security Architecture for the
	Internet Protocol", RFC 2401, November 1998.		Internet Protocol", RFC 2401, November 1998.
	[IPv6-AUTH] Kent, S. and R. Atkinson, "IP Authentication Header",		[IPv6-AUTH] S. Kent, "IP Authentication Header", RFC 4302, December
	RFC 2402, November 1998.		2005.
	[IPv6-ESP] Kent, S. and R. Atkinson, "IP Encapsulating Security		[IPv6-ESP] S. Kent, "IP Encapsulating Security Payload (ESP)", RFC
	Payload (ESP)", RFC 2406, November 1998.		4303, December 2005.
	[LD-SHRE] Hinden, R. and D. Thaler, "IPv6 Host-to-Router Load		[LD-SHRE] Hinden, R. and D. Thaler, "IPv6 Host-to-Router Load
	Sharing", RFC 4311, November 2005.		Sharing", RFC 4311, November 2005.
	[MIPv6] D. Johnson, C. Perkins and J. Arkko, "Mobility Support		[MIPv6] D. Johnson, C. Perkins and J. Arkko, "Mobility Support
	in IPv6", RFC 3775, June 2004.		in IPv6", RFC 3775, June 2004.
	[MLD] Deering, S., Fenner, W, and B. Haberman, "Multicast		[MLD] Deering, S., Fenner, W, and B. Haberman, "Multicast
	Listener Discovery for IPv6", RFC 2710, October 1999.		Listener Discovery for IPv6", RFC 2710, October 1999.
	[MLDv2] Vida, R. and L. Costa, "Multicast Listener Discovery		[MLDv2] Vida, R. and L. Costa, "Multicast Listener Discovery
	Version 2 (MLDv2) for IPv6", RFC 3810, June 2004.		Version 2 (MLDv2) for IPv6", RFC 3810, June 2004.
	[NDMAN] Arkko, J., "Manual Configuration of Security		[NDMAN] Arkko, J., "Manual Configuration of Security
	Associations for IPv6 Neighbor Discovery", draft-arkko-		Associations for IPv6 Neighbor Discovery", draft-arkko-
	manual-icmpv6-sas-02 (work in progress), March 2003.		manual-icmpv6-sas-02 (work in progress), March 2003.
			[PSREQ] Nikander, P., Kempf, J. And E. Nordmark, "IPv6 Neighbor
			Discovery (ND) Trust and Threats", RFC 3756, May 2004.
	[RDISC] Deering, S., "ICMP Router Discovery Messages", RFC 1256,		[RDISC] Deering, S., "ICMP Router Discovery Messages", RFC 1256,
	September 1991.		September 1991.
	[RFC3667] Bradner, S., "IETF Rights in Contributions", RFC 3667,		[RFC3667] Bradner, S., "IETF Rights in Contributions", RFC 3667,
	February 2004.		February 2004.
	[RTSEL] Draves, R. and D. Thaler, "Default Router Preferences		[RTSEL] Draves, R. and D. Thaler, "Default Router Preferences
	and more Specific Routes", draft-ietf-ipv6-router-		and more Specific Routes", draft-ietf-ipv6-router-
	selection-07, (work in progress), January 2005.		selection-07, (work in progress), January 2005.
	[SH-MEDIA] Braden, R., Postel, J. and Y. Rekhter, "Internet		[SH-MEDIA] Braden, R., Postel, J. and Y. Rekhter, "Internet
	Architecture Extensions for Shared Media", RFC 1620, May		Architecture Extensions for Shared Media", RFC 1620, May
	1994.		1994.
	[SEND] Arkko, J., Kempf, J., Sommerfeld, B., Zill, B. and P.		[SEND] Arkko, J., Kempf, J., Sommerfeld, B., Zill, B. and P.
	Nikander, "SEcure Neighbor Discovery (SEND)",		Nikander, "SEcure Neighbor Discovery (SEND)",RFC3971,
	draft-ietf-send-ndopt-04 (work in progress),		March 2005.
	February 2004.
	[SYNC] S. Floyd, V. Jacobson, "The Synchronization of Periodic		[SYNC] S. Floyd, V. Jacobson, "The Synchronization of Periodic
	Routing Messages", IEEE/ACM Transactions on Networking,		Routing Messages", IEEE/ACM Transactions on Networking,
	April 1994. ftp://ftp.ee.lbl.gov/papers/sync_94.ps.Z		April 1994. ftp://ftp.ee.lbl.gov/papers/sync_94.ps.Z
	IANA CONSIDERATIONS		IANA CONSIDERATIONS
	This document does not require any new ICMPv6 types or codes to be		This document does not require any new ICMPv6 types or codes to be
	allocated. However, existing ICMPv6 types should be updated to point		allocated. However, existing ICMPv6 types should be updated to point
	to the document instead of RFC 2461. The procedure for the assignment		to the document instead of RFC 2461. The procedure for the assignment
	skipping to change at page 80, line 37		skipping to change at page 80, line 38
	Daydreamer		Daydreamer
	Computer Systems Consulting Services		Computer Systems Consulting Services
	1384 Fontaine		1384 Fontaine
	Madison Heights, Michigan 48071		Madison Heights, Michigan 48071
	USA		USA
	EMail: Bill.Simpson@um.cc.umich.edu		EMail: Bill.Simpson@um.cc.umich.edu
	bsimpson@MorningStar.com		bsimpson@MorningStar.com
	Hesham Soliman		Hesham Soliman
	Flarion Technologies		Qualcomm-Flarion Technologies
	Phone: +1 908 997 9775		Email: Hesham@Qualcomm.com
	Email: H.Soliman@flarion.com
	APPENDIX A: MULTIHOMED HOSTS		APPENDIX A: MULTIHOMED HOSTS
	There are a number of complicating issues that arise when Neighbor		There are a number of complicating issues that arise when Neighbor
	Discovery is used by hosts that have multiple interfaces. This		Discovery is used by hosts that have multiple interfaces. This
	section does not attempt to define the proper operation of multihomed		section does not attempt to define the proper operation of multihomed
	hosts with regard to Neighbor Discovery. Rather, it identifies		hosts with regard to Neighbor Discovery. Rather, it identifies
	issues that require further study. Implementors are encouraged to		issues that require further study. Implementors are encouraged to
	experiment with various approaches to making Neighbor Discovery work		experiment with various approaches to making Neighbor Discovery work
	on multihomed hosts and to report their experiences. Further work		on multihomed hosts and to report their experiences. Further work
	skipping to change at page 88, line 42		skipping to change at page 88, line 45
	Disclaimer of Validity		Disclaimer of Validity
	This document and the information contained herein are provided on an		This document and the information contained herein are provided on an
	"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS		"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
	OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET		OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
	ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,		ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
	INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE		INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
	INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED		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.
	This Internet-Draft expires November, 2006.		This Internet-Draft expires February, 2007.
End of changes. 24 change blocks.
	46 lines changed or deleted		45 lines changed or added
This html diff was produced by rfcdiff 1.32. The latest version is available from http://www.levkowetz.com/ietf/tools/rfcdiff/