< draft-ietf-zeroconf-ipv4-linklocal-16.txt		draft-ietf-zeroconf-ipv4-linklocal-17.txt >
	ZEROCONF Working Group Stuart Cheshire		ZEROCONF Working Group Stuart Cheshire
	INTERNET-DRAFT Apple Computer		INTERNET-DRAFT Apple Computer
	Category: Standards Track Bernard Aboba		Category: Standards Track Bernard Aboba
	<draft-ietf-zeroconf-ipv4-linklocal-16.txt> Microsoft Corporation		<draft-ietf-zeroconf-ipv4-linklocal-17.txt> Microsoft Corporation
	1 July 2004 Erik Guttman		8 July 2004 Erik Guttman
	Sun Microsystems		Sun Microsystems
	Dynamic Configuration of IPv4 Link-Local Addresses		Dynamic Configuration of IPv4 Link-Local Addresses
	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,
	and any of which I become aware will be disclosed, in accordance with		and any of which I become aware will be disclosed, in accordance with
	RFC 3668.		RFC 3668.
	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
	groups may also distribute working documents as Internet-Drafts.		other 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 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 http://		The list of current Internet-Drafts can be accessed at
	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.
			This Internet-Draft will expire on January 2, 2005.
	Copyright Notice		Copyright Notice
	Copyright (C) The Internet Society 2004. This document is subject to		Copyright (C) The Internet Society 2004. All rights reserved.
	the rights, licenses and restrictions contained in BCP 78, and except
	as set forth therein, the authors retain all their rights.
	Abstract		Abstract
	To participate in wide-area IP networking, a host needs to be		To participate in wide-area IP networking, a host needs to be
	configured with IP addresses for its interfaces, either manually by		configured with IP addresses for its interfaces, either manually by
	the user or automatically from a source on the network such as a DHCP		the user or automatically from a source on the network such as a DHCP
	server. Unfortunately, such address configuration information may not		server. Unfortunately, such address configuration information may not
	always be available. It is therefore beneficial for a host to be able		always be available. It is therefore beneficial for a host to be able
	to depend on a useful subset of IP networking functions even when no		to depend on a useful subset of IP networking functions even when no
	address configuration is available. This document describes how a		address configuration is available. This document describes how a
	skipping to change at page 2, line 10 ¶		skipping to change at page 2, line 14 ¶
	IPv4 Link-Local addresses are not suitable for communication with		IPv4 Link-Local addresses are not suitable for communication with
	devices not directly connected to the same physical (or logical)		devices not directly connected to the same physical (or logical)
	link, and are only used where stable, routable addresses are not		link, and are only used where stable, routable addresses are not
	available (such as on ad hoc or isolated networks). This document		available (such as on ad hoc or isolated networks). This document
	does not recommend that IPv4 Link-Local addresses and routable		does not recommend that IPv4 Link-Local addresses and routable
	addresses be configured simultaneously on the same interface.		addresses be configured simultaneously on the same interface.
	Table of Contents		Table of Contents
	1. Introduction.............................................. 3		1. Introduction.............................................. 4
	1.1 Requirements ....................................... 3		1.1 Requirements ....................................... 4
	1.2 Terminology ........................................ 3		1.2 Terminology ........................................ 4
	1.3 Applicability....................................... 4		1.3 Applicability....................................... 5
	1.4 Application Layer Protocol Considerations........... 5		1.4 Application Layer Protocol Considerations........... 6
	1.5 Autoconfiguration Issues ........................... 6		1.5 Autoconfiguration Issues ........................... 7
	1.6 Alternate Use Prohibition .......................... 7		1.6 Alternate Use Prohibition .......................... 8
	1.7 Multiple Interfaces ................................ 7		1.7 Multiple Interfaces ................................ 8
	1.8 Communication with Routable Addresses............... 7		1.8 Communication with Routable Addresses............... 8
	1.9 When to configure an IPv4 Link-Local Address ....... 7		1.9 When to configure an IPv4 Link-Local Address ....... 8
	2. Address Selection, Defense and Delivery................... 9		2. Address Selection, Defense and Delivery................... 10
	2.1 Link-Local Address Selection........................ 9		2.1 Link-Local Address Selection........................ 10
	2.2 Claiming a Link-Local Address....................... 10		2.2 Claiming a Link-Local Address....................... 11
	2.3 Shorter Timeouts ................................... 12		2.3 Shorter Timeouts ................................... 13
	2.4 Announcing an Address............................... 12		2.4 Announcing an Address............................... 13
	2.5 Conflict Detection and Defense...................... 12		2.5 Conflict Detection and Defense...................... 13
	2.6 Address Usage and Forwarding Rules.................. 13		2.6 Address Usage and Forwarding Rules.................. 14
	2.7 Link-Local Packets Are Not Forwarded................ 15		2.7 Link-Local Packets Are Not Forwarded................ 16
	2.8 Link-Local Packets are Local........................ 15		2.8 Link-Local Packets are Local........................ 16
	2.9 Higher-Layer Protocol Considerations................ 15		2.9 Higher-Layer Protocol Considerations................ 16
	2.10 Privacy Concerns.................................... 16		2.10 Privacy Concerns.................................... 17
	2.11 Interaction between DHCPv4 and IPv4 Link-Local		2.11 Interaction between DHCPv4 and IPv4 Link-Local
	State Machines ..................................... 16		State Machines ..................................... 17
	3. Considerations for Multiple Interfaces.................... 16		3. Considerations for Multiple Interfaces.................... 17
	3.1 Scoped Addresses.................................... 17		3.1 Scoped Addresses.................................... 18
	3.2 Address Ambiguity................................... 18		3.2 Address Ambiguity................................... 19
	3.3 Interaction with Hosts with Routable Addresses...... 18		3.3 Interaction with Hosts with Routable Addresses...... 19
	3.4 Unintentional Autoimmune Response................... 19		3.4 Unintentional Autoimmune Response................... 20
	4. Healing of Network Partitions ............................ 20		4. Healing of Network Partitions ............................ 21
	5. Security Considerations................................... 21		5. Security Considerations................................... 22
	6. Application Programming Considerations.................... 22		6. Application Programming Considerations.................... 23
	6.1 Address Changes, Failure and Recovery............... 22		6.1 Address Changes, Failure and Recovery............... 23
	6.2 Limited Forwarding of Locators...................... 22		6.2 Limited Forwarding of Locators...................... 23
	6.3 Address Ambiguity................................... 22		6.3 Address Ambiguity................................... 23
	7. Router Considerations..................................... 23		7. Router Considerations..................................... 24
	8. IANA Considerations....................................... 23		8. IANA Considerations....................................... 24
	9. Constants ................................................ 23		9. Constants ................................................ 24
	10. References ............................................... 24		10. References ............................................... 25
	10.1 Normative References ............................... 24		10.1 Normative References ............................... 25
	10.2 Informative References ............................. 24		10.2 Informative References ............................. 25
	Acknowledgments .............................................. 25		Acknowledgments .............................................. 26
	Authors' Addresses ........................................... 25		Authors' Addresses ........................................... 26
	Appendix A - Prior Implementations............................ 26		Appendix A - Prior Implementations............................ 27
	Intellectual Property Statement .............................. 29		Intellectual Property Statement .............................. 30
	Full Copyright Statement ..................................... 30		Disclaimer of Validity ....................................... 31
			Full Copyright Statement ..................................... 31
	1. Introduction		1. Introduction
	As the Internet Protocol continues to grow in popularity, it becomes		As the Internet Protocol continues to grow in popularity, it becomes
	increasingly valuable to be able to use familiar IP tools such as FTP		increasingly valuable to be able to use familiar IP tools such as FTP
	not only for global communication, but for local communication as		not only for global communication, but for local communication as
	well. For example, two people with laptop computers supporting IEEE		well. For example, two people with laptop computers supporting IEEE
	802.11 Wireless LANs [802.11] may meet and wish to exchange files.		802.11 Wireless LANs [802.11] may meet and wish to exchange files.
	It is desirable for these people to be able to use IP application		It is desirable for these people to be able to use IP application
	software without the inconvenience of having to manually configure		software without the inconvenience of having to manually configure
	static IP addresses or set up a DHCP server [RFC2131].		static IP addresses or set up a DHCP server [RFC2131].
	skipping to change at page 5, line 24 ¶		skipping to change at page 6, line 24 ¶
	see PROBE_NUM, PROBE_MIN, PROBE_MAX defined in Section 2.2.1		see PROBE_NUM, PROBE_MIN, PROBE_MAX defined in Section 2.2.1
	(b) the number of, and interval between, ARP announcements,		(b) the number of, and interval between, ARP announcements,
	see ANNOUNCE_NUM and ANNOUNCE_INTERVAL defined in Section 2.4		see ANNOUNCE_NUM and ANNOUNCE_INTERVAL defined in Section 2.4
	(c) the maximum rate at which address claiming may be attempted,		(c) the maximum rate at which address claiming may be attempted,
	see RATE_LIMIT_INTERVAL and MAX_COLLISIONS defined in Section 2.2.1		see RATE_LIMIT_INTERVAL and MAX_COLLISIONS defined in Section 2.2.1
	(d) the time interval between conflicting ARPs below which a host		(d) the time interval between conflicting ARPs below which a host
	MUST reconfigure instead of attempting to defend its address,		MUST reconfigure instead of attempting to defend its address,
	see DEFENSE_WINDOW defined in Section 2.5		see DEFEND_INTERVAL defined in Section 2.5
	Link-layer technologies that do not support ARP may be able to use		Link-layer technologies that do not support ARP may be able to use
	other techniques for determining whether a particular IP address is		other techniques for determining whether a particular IP address is
	currently in use. However, the application of claim-and-defend		currently in use. However, the application of claim-and-defend
	mechanisms to such networks is outside the scope of this document.		mechanisms to such networks is outside the scope of this document.
	This specification is intended for use with small ad-hoc networks - a		This specification is intended for use with small ad-hoc networks - a
	single link containing only a few hosts. Although 65024 IPv4 Link-		single link containing only a few hosts. Although 65024 IPv4 Link-
	Local addresses are available in principle, attempting to use all		Local addresses are available in principle, attempting to use all
	those addresses on a single link would result a high probability of		those addresses on a single link would result a high probability of
	skipping to change at page 12, line 46 ¶		skipping to change at page 13, line 46 ¶
	A host MUST respond to a conflicting ARP packet as described in		A host MUST respond to a conflicting ARP packet as described in
	either (a) or (b) below:		either (a) or (b) below:
	(a) Upon receiving a conflicting ARP packet, a host MAY elect to		(a) Upon receiving a conflicting ARP packet, a host MAY elect to
	immediately configure a new IPv4 Link-Local address as described		immediately configure a new IPv4 Link-Local address as described
	above, or		above, or
	(b) If a host currently has active TCP connections or other reasons		(b) If a host currently has active TCP connections or other reasons
	to prefer to keep the same IPv4 address, and it has not seen any		to prefer to keep the same IPv4 address, and it has not seen any
	other conflicting ARP packets recently, within the last		other conflicting ARP packets recently, within the last
	DEFENSE_WINDOW seconds, then it MAY elect to attempt to defend its		DEFEND_INTERVAL seconds, then it MAY elect to attempt to defend its
	address, by recording the time that the conflicting ARP packet was		address, by recording the time that the conflicting ARP packet was
	received, and then broadcasting one single ARP announcement, giving		received, and then broadcasting one single ARP announcement, giving
	its own IP and hardware addresses as the sender addresses of the ARP.		its own IP and hardware addresses as the sender addresses of the ARP.
	Having done this, the host can then continue to use the address		Having done this, the host can then continue to use the address
	normally without any further special action. However, if this is not		normally without any further special action. However, if this is not
	the first conflicting ARP packet the host has seen, and the time		the first conflicting ARP packet the host has seen, and the time
	recorded for the previous conflicting ARP packet is recent, within		recorded for the previous conflicting ARP packet is recent, within
	DEFENSE_WINDOW, then the host MUST immediately cease using this		DEFEND_INTERVAL, then the host MUST immediately cease using this
	address and configure a new IPv4 Link-Local address as described		address and configure a new IPv4 Link-Local address as described
	above. This is necessary to ensure that two hosts do not get stuck		above. This is necessary to ensure that two hosts do not get stuck
	in an endless loop with both hosts trying to defend the same address.		in an endless loop with both hosts trying to defend the same address.
	A host MUST respond to conflicting ARP packets as described in either		A host MUST respond to conflicting ARP packets as described in either
	(a) or (b) above. A host MUST NOT ignore conflicting ARP packets.		(a) or (b) above. A host MUST NOT ignore conflicting ARP packets.
	Forced address reconfiguration may be disruptive, causing TCP		Forced address reconfiguration may be disruptive, causing TCP
	connections to be broken. However, it is expected that such		connections to be broken. However, it is expected that such
	disruptions will be rare, and if inadvertent address duplication		disruptions will be rare, and if inadvertent address duplication
	skipping to change at page 23, line 33 ¶		skipping to change at page 24, line 33 ¶
	configured or is configured with a different address than the		configured or is configured with a different address than the
	destination of the packet MUST NOT forward the packet. This prevents		destination of the packet MUST NOT forward the packet. This prevents
	forwarding of packets back onto the network segment from which they		forwarding of packets back onto the network segment from which they
	originated, or to any other segment.		originated, or to any other segment.
	8. IANA Considerations		8. IANA Considerations
	The IANA has allocated the prefix 169.254/16 for the use described in		The IANA has allocated the prefix 169.254/16 for the use described in
	this document. The first and last 256 addresses in this range		this document. The first and last 256 addresses in this range
	(169.254.0.x and 169.254.255.x) are allocated by Standards Action, as		(169.254.0.x and 169.254.255.x) are allocated by Standards Action, as
	defined in [RFC2434] BCP 26. No other IANA services are required by		defined in [RFC2434] BCP 26. No other IANA services are required by
	this document.		this document.
	9. Constants		9. Constants
	The following timing constants are used in this protocol; they are		The following timing constants are used in this protocol; they are
	not intended to be user configurable.		not intended to be user configurable.
	PROBE_WAIT 1 second (initial random delay)		PROBE_WAIT 1 second (initial random delay)
	PROBE_MIN 1 second (minimum delay till repeated probe)		PROBE_MIN 1 second (minimum delay till repeated probe)
	PROBE_MAX 2 seconds (maximum delay till repeated probe)		PROBE_MAX 2 seconds (maximum delay till repeated probe)
	PROBE_NUM 3 (number of probe packets)		PROBE_NUM 3 (number of probe packets)
	ANNOUNCE_NUM 2 (number of announcement packets)		ANNOUNCE_NUM 2 (number of announcement packets)
	ANNOUNCE_INTERVAL 2 seconds (time between announcement packets)		ANNOUNCE_INTERVAL 2 seconds (time between announcement packets)
	ANNOUNCE_WAIT 2 seconds (delay before announcing)		ANNOUNCE_WAIT 2 seconds (delay before announcing)
	MAX_COLLISIONS 10 (max collisions before rate limiting)		MAX_COLLISIONS 10 (max collisions before rate limiting)
	RATE_LIMIT_INTERVAL 60 seconds (delay between successive attempts)		RATE_LIMIT_INTERVAL 60 seconds (delay between successive attempts)
	DEFENSE_WINDOW 10 seconds (time to continue to defend your		DEFEND_INTERVAL 10 seconds (minimum interval between defensive
	address, for IEEE 802 networks. For		ARPs).
	other network types this value is
	currently unspecified.)
	10. References		10. References
	10.1. Normative References		10.1. Normative References
	[RFC792] Postel, J., "Internet Control Message Protocol", RFC 792,		[RFC792] Postel, J., "Internet Control Message Protocol", RFC 792,
	September 1981.		September 1981.
	[RFC826] D. Plummer, "An Ethernet Address Resolution Protocol -or-		[RFC826] D. Plummer, "An Ethernet Address Resolution Protocol -or-
	Converting Network Addresses to 48-bit Ethernet Address for		Converting Network Addresses to 48-bit Ethernet Address for
	skipping to change at page 29, line 39 ¶		skipping to change at page 30, line 39 ¶
	respect to address allocation and NATing of Link-Local prefixes.		respect to address allocation and NATing of Link-Local prefixes.
	Intellectual Property Statement		Intellectual Property Statement
	The IETF has been notified of intellectual property rights claimed in		The IETF has been notified of intellectual property rights claimed in
	regard to some or all of the specification contained in this		regard to some or all of the specification contained in this
	document. For more information consult the online list of claimed		document. For more information consult the online list of claimed
	rights.		rights.
	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 or other rights that might be claimed to		Intellectual Property Rights or other rights that might be claimed to
	pertain to the implementation or use of the technology described in		pertain to the implementation or use of the technology described in
	this document or the extent to which any license under such rights		this document or the extent to which any license under such rights
	might or might not be available; neither does it represent that it		might or might not be available; nor does it represent that it has
	has made any effort to identify any such rights. Information on the		made any independent effort to identify any such rights. Information
	IETF's procedures with respect to rights in standards-track and		on the procedures with respect to rights in RFC documents can be
	standards-related documentation can be found in BCP-11. Copies of		found in BCP 78 and BCP 79.
	claims of rights made available for publication and any assurances of
	licenses to be made available, or the result of an attempt made to		Copies of IPR disclosures made to the IETF Secretariat and any
	obtain a general license or permission for the use of such		assurances of licenses to be made available, or the result of an
	proprietary rights by implementers or users of this specification can		attempt made to obtain a general license or permission for the use of
	be obtained from the IETF Secretariat.		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		The IETF invites any interested party to bring to its attention any
	copyrights, patents or patent applications, or other proprietary		copyrights, patents or patent applications, or other proprietary
	rights that may cover technology that may be required to practice		rights that may cover technology that may be required to implement
	this standard. Please address the information to the IETF Executive		this standard. Please address the information to the IETF at ietf-
	Director.		ipr@ietf.org.
	Full Copyright Statement
	Copyright (C) The Internet Society (2004). This document is subject		Disclaimer of Validity
	to the rights, licenses and restrictions contained in BCP 78, and
	except as set forth therein, the authors retain all their rights.
	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.
			Copyright Statement
			Copyright (C) The Internet Society (2004). This document is subject
			to the rights, licenses and restrictions contained in BCP 78, and
			except as set forth therein, the authors retain all their rights.
	Open Issues		Open Issues
	Open issues with this specification are tracked on the following web		Open issues with this specification are tracked on the following web
	site:		site:
	http://www.drizzle.com/~aboba/ZEROCONF/issues.html		http://www.drizzle.com/~aboba/ZEROCONF/issues.html
End of changes. 19 change blocks.
	81 lines changed or deleted		84 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/