draft-ietf-6man-enhanced-dad-02.txt		draft-ietf-6man-enhanced-dad-03.txt
	Network Working Group R. Asati		Network Working Group R. Asati
	Internet-Draft H. Singh		Internet-Draft H. Singh
	Updates: 4862 (if approved) W. Beebee		Updates: 4862, 4861 (if approved) W. Beebee
	Intended status: Standards Track Cisco Systems, Inc.		Intended status: Standards Track Cisco Systems, Inc.
	Expires: August 9, 2013 E. Dart		Expires: November 25, 2013 E. Dart
	Lawrence Berkeley National		Lawrence Berkeley National Laboratory
	Laboratory
	W. George		W. George
	Time Warner Cable		Time Warner Cable
	C. Pignataro		C. Pignataro
	Cisco Systems, Inc.		Cisco Systems, Inc.
	February 5, 2013		May 24, 2013
	Enhanced Duplicate Address Detection		Enhanced Duplicate Address Detection
	draft-ietf-6man-enhanced-dad-02		draft-ietf-6man-enhanced-dad-03
	Abstract		Abstract
	Appendix A of the IPv6 Duplicate Address Detection (DAD) document in		Appendix A of the IPv6 Duplicate Address Detection (DAD) document in
	RFC 4862 discusses Loopback Suppression and DAD. However, RFC 4862		RFC 4862 discusses Loopback Suppression and DAD. However, RFC 4862
	does not settle on one specific automated means to detect loopback of		does not settle on one specific automated means to detect loopback of
	Neighbor Discovery (ND of RFC 4861) messages used by DAD. Several		Neighbor Discovery (ND of RFC 4861) messages used by DAD. Several
	service provider communities have expressed a need for automated		service provider communities have expressed a need for automated
	detection of looped backed ND messages used by DAD. This document		detection of looped backed ND messages used by DAD. This document
	includes mitigation techniques and then outlines the Enhanced DAD		includes mitigation techniques and then outlines the Enhanced DAD
	algorithm to automate detection of looped back IPv6 ND messages used		algorithm to automate detection of looped back IPv6 ND messages used
	by DAD. For network loopback tests, the Enhanced DAD algorithm		by DAD. For network loopback tests, the Enhanced DAD algorithm
	allows IPv6 to self-heal after a loopback is placed and removed.		allows IPv6 to self-heal after a loopback is placed and removed.
	Further, for certain access networks the document automates resolving		Further, for certain access networks the document automates resolving
	a specific duplicate address conflict.		a specific duplicate address conflict.
	Status of this Memo		Status of This Memo
	This Internet-Draft is submitted in full conformance with the		This Internet-Draft is submitted in full conformance with the
	provisions of BCP 78 and BCP 79.		provisions of BCP 78 and BCP 79.
	Internet-Drafts are working documents of the Internet Engineering		Internet-Drafts are working documents of the Internet Engineering
	Task Force (IETF). Note that other groups may also distribute		Task Force (IETF). Note that other groups may also distribute
	working documents as Internet-Drafts. The list of current Internet-		working documents as Internet-Drafts. The list of current Internet-
	Drafts is at http://datatracker.ietf.org/drafts/current/.		Drafts is at http://datatracker.ietf.org/drafts/current/.
	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."
	This Internet-Draft will expire on August 9, 2013.		This Internet-Draft will expire on November 25, 2013.
	Copyright Notice		Copyright Notice
	Copyright (c) 2013 IETF Trust and the persons identified as the		Copyright (c) 2013 IETF Trust and the persons identified as the
	document authors. All rights reserved.		document authors. All rights reserved.
	This document is subject to BCP 78 and the IETF Trust's Legal		This document is subject to BCP 78 and the IETF Trust's Legal
	Provisions Relating to IETF Documents		Provisions Relating to IETF Documents
	(http://trustee.ietf.org/license-info) in effect on the date of		(http://trustee.ietf.org/license-info) in effect on the date of
	publication of this document. Please review these documents		publication of this document. Please review these documents
	carefully, as they describe your rights and restrictions with respect		carefully, as they describe your rights and restrictions with respect
	to this document. Code Components extracted from this document must		to this document. Code Components extracted from this document must
	include Simplified BSD License text as described in Section 4.e of		include Simplified BSD License text as described in Section 4.e of
	the Trust Legal Provisions and are provided without warranty as		the Trust Legal Provisions and are provided without warranty as
	described in the Simplified BSD License.		described in the Simplified BSD License.
	Table of Contents		Table of Contents
	1. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3		1. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 2
	2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3		2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
	3. Operational Mitigation Options . . . . . . . . . . . . . . . . 4		3. Operational Mitigation Options . . . . . . . . . . . . . . . 4
	3.1. Disable DAD on Interface . . . . . . . . . . . . . . . . . 5		3.1. Disable DAD on Interface . . . . . . . . . . . . . . . . 4
	3.2. Dynamic Disable/Enable of DAD Using Layer 2 Protocol . . . 5		3.2. Dynamic Disable/Enable of DAD Using Layer 2 Protocol . . 5
	3.3. Operational Considerations . . . . . . . . . . . . . . . . 6		3.3. Operational Considerations . . . . . . . . . . . . . . . 5
	4. The Enhanced DAD Algorithm . . . . . . . . . . . . . . . . . . 6		4. The Enhanced DAD Algorithm . . . . . . . . . . . . . . . . . 6
	4.1. General Rules . . . . . . . . . . . . . . . . . . . . . . 7		4.1. General Rules . . . . . . . . . . . . . . . . . . . . . . 7
	4.2. Processing Rules for Senders . . . . . . . . . . . . . . . 7		4.2. Processing Rules for Senders . . . . . . . . . . . . . . 7
	4.3. Processing Rules for Receivers . . . . . . . . . . . . . . 8		4.3. Processing Rules for Receivers . . . . . . . . . . . . . 7
	4.4. Impact on SEND . . . . . . . . . . . . . . . . . . . . . . 8		4.4. Impact on SEND . . . . . . . . . . . . . . . . . . . . . 8
	4.5. Changes to RFC 4862 . . . . . . . . . . . . . . . . . . . 8		4.5. Changes to RFC 4862 . . . . . . . . . . . . . . . . . . . 8
	5. Actions to Perform on Detecting a Genuine Duplicate . . . . . 9		4.6. Changes to RFC 4861 . . . . . . . . . . . . . . . . . . . 8
	6. Security Considerations . . . . . . . . . . . . . . . . . . . 9		5. Actions to Perform on Detecting a Genuine Duplicate . . . . . 9
	7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9		6. Security Considerations . . . . . . . . . . . . . . . . . . . 9
	8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 9		7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9
	9. Normative References . . . . . . . . . . . . . . . . . . . . . 10		8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 9
	Appendix A. Changes from the -01 version . . . . . . . . . . . . 10		9. Normative References . . . . . . . . . . . . . . . . . . . . 10
	Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 11		Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 10
	1. Terminology		1. Terminology
	o DAD-failed state - Duplication Address Detection failure as		o DAD-failed state - Duplication Address Detection failure as
	specified in [RFC4862]. Failure also includes if the Target		specified in [RFC4862]. Failure also includes if the Target
	Address is optimistic. Optimistic DAD is specified in [RFC4429].		Address is optimistic. Optimistic DAD is specified in [RFC4429].
	o Looped back message - also referred to as a reflected message.		o Looped back message - also referred to as a reflected message.
	The message sent by the sender is received by the sender due to		The message sent by the sender is received by the sender due to
	the network or a Upper Layer Protocol on the sender looping the		the network or a Upper Layer Protocol on the sender looping the
	skipping to change at page 3, line 27		skipping to change at page 3, line 16
	circuit to which the router's interface is connected) is looped		circuit to which the router's interface is connected) is looped
	back or connected to itself. Loopback causes packets sent by the		back or connected to itself. Loopback causes packets sent by the
	interface to be received by the interface, and results in		interface to be received by the interface, and results in
	interface unavailability for regular data traffic forwarding. See		interface unavailability for regular data traffic forwarding. See
	more details in section 9.1 of [RFC1247]. The Loopback function		more details in section 9.1 of [RFC1247]. The Loopback function
	is commonly used in an interface context to gain information on		is commonly used in an interface context to gain information on
	the quality of the interface, by employing mechanisms such as		the quality of the interface, by employing mechanisms such as
	ICMPv6 pings, bit-error tests, etc. In a circuit context, it is		ICMPv6 pings, bit-error tests, etc. In a circuit context, it is
	used in wide area environments including optical dense wave		used in wide area environments including optical dense wave
	division multiplexing (DWDM) and SONET/SDH for fault isolation		division multiplexing (DWDM) and SONET/SDH for fault isolation
	(e.g. by placing a loopback at different geographic locations		(e.g. by placing a loopback at different geographic locations
	along the path of a wide area circuit to help locate a circuit		along the path of a wide area circuit to help locate a circuit
	fault). The Loopback function may be employed locally or		fault). The Loopback function may be employed locally or
	remotely.		remotely.
	o NS(DAD) - shorthand notation to denote an NS with unspecified IPv6		o NS(DAD) - shorthand notation to denote an Neighbor Solicitation
	source-address issued during DAD.		(NS) with unspecified IPv6 source-address issued during DAD.
	2. Introduction		2. Introduction
	Appendix A of [RFC4862] discusses Loopback Suppression and Duplicate		Appendix A of [RFC4862] discusses Loopback Suppression and Duplicate
	Address Detection (DAD). However, [RFC4862] does not settle on one		Address Detection (DAD). However, [RFC4862] does not settle on one
	specific automated means to detect loopback of ND messages used by		specific automated means to detect loopback of ND messages used by
	DAD. One specific DAD message is a Neighbor Solicitation (NS),		DAD. One specific DAD message is a Neighbor Solicitation (NS),
	specified in [RFC4861]. The NS is issued by the network interface of		specified in [RFC4861]. The NS is issued by the network interface of
	an IPv6 node for DAD. Another message involved in DAD is a Neighbor		an IPv6 node for DAD. Another message involved in DAD is a Neighbor
	Advertisement (NA). The Enhanced DAD algorithm proposed in this		Advertisement (NA). The Enhanced DAD algorithm proposed in this
	skipping to change at page 6, line 11		skipping to change at page 5, line 43
	interfaces that may be in loopback for long periods of time (such		interfaces that may be in loopback for long periods of time (such
	as while awaiting turn-up or during long-duration intrusive bit		as while awaiting turn-up or during long-duration intrusive bit
	error rate tests).		error rate tests).
	3.3. Operational Considerations		3.3. Operational Considerations
	The mitigation options discussed in the document do not require the		The mitigation options discussed in the document do not require the
	devices on both ends of the circuit to support the mitigation		devices on both ends of the circuit to support the mitigation
	functionality simultaneously, and do not propose any capability		functionality simultaneously, and do not propose any capability
	negotiation. The mitigation options discussed in this document are		negotiation. The mitigation options discussed in this document are
	effective for unidirectional circuit or interface loopback (i.e. the		effective for unidirectional circuit or interface loopback (i.e. the
	the loopback is placed in one direction on the circuit, rendering the		the loopback is placed in one direction on the circuit, rendering the
	other direction non-operational).		other direction non-operational).
	The mitigation options may not be effective for the bidirectional		The mitigation options may not be effective for the bidirectional
	loopback (i.e. the loopback is placed in both directions of the		loopback (i.e. the loopback is placed in both directions of the
	circuit interface, so as to identify the faulty segment) if only one		circuit interface, so as to identify the faulty segment) if only one
	device followed a mitigation option specified in this document, since		device followed a mitigation option specified in this document, since
	the other device would follow current behavior and disable IPv6 on		the other device would follow current behavior and disable IPv6 on
	that interface due to DAD until manual intervention restores it.		that interface due to DAD until manual intervention restores it.
	This is nothing different from what happens today (without the		This is nothing different from what happens today (without the
	solutions proposed by this document) in case of unidirectional		solutions proposed by this document) in case of unidirectional
	loopback. Hence, it is expected that an operator would resort to		loopback. Hence, it is expected that an operator would resort to
	manual intervention for the devices not compliant with this document,		manual intervention for the devices not compliant with this document,
	as usual.		as usual.
	skipping to change at page 6, line 40		skipping to change at page 6, line 23
	The Enhanced DAD algorithm covers detection of a looped back NS(DAD)		The Enhanced DAD algorithm covers detection of a looped back NS(DAD)
	message. The document proposes use of the Nonce Option specified in		message. The document proposes use of the Nonce Option specified in
	the SEND document of [RFC3971]. The nonce is a random number as		the SEND document of [RFC3971]. The nonce is a random number as
	specified in [RFC3971]. If SEND is enabled on the router and the		specified in [RFC3971]. If SEND is enabled on the router and the
	router also supports the Enhanced DAD algorithm (specified in this		router also supports the Enhanced DAD algorithm (specified in this
	document), there is integration with the Enhanced DAD algorithm and		document), there is integration with the Enhanced DAD algorithm and
	SEND. See more details in the Impact on SEND section. Since a nonce		SEND. See more details in the Impact on SEND section. Since a nonce
	is used only once, DAD for each IPv6 address of an interface uses a		is used only once, DAD for each IPv6 address of an interface uses a
	different nonce.		different nonce.
	When the IPv6 network interface issues a NS(DAD) message, the		The interface follows [RFC4862] behavior by issuing
	interface includes the Nonce Option in the NS(DAD) message and saves		DupAddrDetectTransmits (see [RFC4862]) probes spaced RetransTimer
	the nonce in local store. Subsequently if the interface receives an		(see [RFC4861]) apart. When the IPv6 network interface issues a
	identical NS(DAD) message, the interface logs a system management		NS(DAD) message, the interface includes the Nonce Option in the
	message, updates any statistics counter, and drops the looped back		NS(DAD) message and saves the nonce in local store. Subsequently if
	NS(DAD). Additionally the interface continues to issue subsequent		the interface receives an identical NS(DAD) message, the interface
	probes until a termination condition (to be defined) is detected.		logs a system management message, updates any statistics counter,
	The DupAddrDetectTransmits value is ignored by the algorithm on		drops the looped back NS(DAD), and moves the Target Address to
	detection of a looped back NS(DAD). Note [RFC4861] already		assigned state. If any probe is looped back within RetransTimer
	randomizes issuing the first probe and issues up to three probes;		milliseconds after having sent DupAddrDetectTransmits NS(DAD)
	note [I-D.ietf-6man-impatient-nud] has intentions to change probe		messages, the interface continues with another MAX_MULTICAST_SOLICIT
	behavior of [RFC4861]. Additionally, certain networks take a few		number of NS(DAD) messages spaced RetransTimer apart. If no probe is
	minutes to loop back a packet to a sender. Hence a variable is		looped back within RetransTimer milliseconds after
	needed to help the interface decide how long to wait for the DAD		MAX_MULTICAST_SOLICIT NS(DAD) messages are sent, the probing stops
	process to complete. For example, [RFC4862] waits for two seconds to		else a new MAX_MULTICAST_SOLICIT number of NS(DAD) messages sequence
	see if any message is received to signal a DAD failure, and if not,		is initiated. The MAX_MULTICAST_SOLICIT number of NS(DAD) messages
	DAD is completed. This document defines a new variable in		sequence continues until the stop condition is reached. The
	WAIT_TIME_LOOPBACK. For example, WAIT_TIME_LOOPBACK is two seconds		RetransTimer may be overidden by a link-specific document if a node
	for [RFC4862] behavior and five minutes for another network. The		supports the Enhanced DAD algorithm. Note
	interface also uses an exponentially backoff algorithm (pick one of		[I-D.ietf-6man-impatient-nud] has intentions to change probe behavior
	several available) to issue probes.		of [RFC4861]. The RetransTimer value may be overridden by a link-
			type specific document.
	If the interface receives a NS(DAD) message with a different nonce		If the interface receives a NS(DAD) message with a different nonce
	but TargetAddress matches a tentative or optimistic address on the		but the Target Address matches a tentative or optimistic address on
	interface, the interface logs a DAD-failed system management message,		the interface, the interface logs a DAD-failed system management
	updates any statistics, and behaves identical to the behavior		message, updates any statistics, and behaves identical to the
	specified in [RFC4862] for DAD failure.		behavior specified in [RFC4862] for DAD failure.
	Six bytes of random nonce is sufficiently large for nonce collisions.		Six bytes of random nonce is sufficiently large for nonce collisions.
	However if there is a collision because two nodes generated the same		However if there is a collision because two nodes generated the same
	random nonce (that are using the same Target address in their		random nonce (that are using the same Target Address in their
	NS(DAD)), then the algorithm will incorrectly detect a looped back		NS(DAD)), then the algorithm will incorrectly detect a looped back
	NS(DAD) when the NS(DAD) was issued to signal a genuine duplicate.		NS(DAD) when the NS(DAD) was issued to signal a genuine duplicate.
	Since each looped back NS(DAD) event is logged to system management,		Since each looped back NS(DAD) event is logged to system management,
	the administrator of the network will have to intervene manually.		the administrator of the network will have to intervene manually.
	The algorithm is capable of detecting any ND solicitation (NS and		The algorithm is capable of detecting any ND solicitation (NS and
	Router Solicitation) or advertisement (NA and Router Advertisement)		Router Solicitation) or advertisement (NA and Router Advertisement)
	that is looped back. However, saving a nonce and nonce related data		that is looped back. However, saving a nonce and nonce related data
	for all ND messages has impact on memory of the node and also adds		for all ND messages has impact on memory of the node and also adds
	the algorithm state to a substantially larger number of ND messages.		the algorithm state to a substantially larger number of ND messages.
	skipping to change at page 7, line 48		skipping to change at page 7, line 33
	If an IPv6 node implements the Enhanced DAD algorithm, the node MUST		If an IPv6 node implements the Enhanced DAD algorithm, the node MUST
	implement detection of looped back NS(DAD) messages during DAD for an		implement detection of looped back NS(DAD) messages during DAD for an
	interface address.		interface address.
	4.2. Processing Rules for Senders		4.2. Processing Rules for Senders
	If a node has been configured to use the Enhanced DAD algorithm, when		If a node has been configured to use the Enhanced DAD algorithm, when
	sending a NS(DAD) for a tentative or optimistic interface address the		sending a NS(DAD) for a tentative or optimistic interface address the
	sender MUST generate a random nonce associated with the interface		sender MUST generate a random nonce associated with the interface
	address, MUST save the nonce, and MUST include the nonce in the Nonce		address, MUST save the nonce, and MUST include the nonce in the Nonce
	Option included in the NS(DAD). If a looped back NS(DAD) is detected		Option included in the NS(DAD). If any probe is looped back within
	by the interface, the interface ignores the DupAddrDetectTransmits		RetransTimer milliseconds after having sent DupAddrDetectTransmits
	and issues subsequent probes forever in an exponential backoff		NS(DAD) messages, the interface continues with another
	transmission until a termination condition is detected.		MAX_MULTICAST_SOLICIT number of NS(DAD) messages spaced RetransTimer
			apart. If no probe is looped back within RetransTimer milliseconds
			after MAX_MULTICAST_SOLICIT NS(DAD) messages are sent, the probing
			stops else a new MAX_MULTICAST_SOLICIT number of NS(DAD) messages
			sequence is initiated. The MAX_MULTICAST_SOLICIT number of NS(DAD)
			messages sequence continues until the stop condition is reached.
	4.3. Processing Rules for Receivers		4.3. Processing Rules for Receivers
	If the node has been configured to use the Enhanced DAD algorithm and		If the node has been configured to use the Enhanced DAD algorithm and
	an interface on the node receives any NS(DAD) message where the		an interface on the node receives any NS(DAD) message where the
	target address matches the interface address (in tentative or		Target Address matches the interface address (in tentative or
	optimistic state), the receiver compares the nonce, if any, is		optimistic state), the receiver compares the nonce, if any, is
	included in the message with any saved nonce on the receiving		included in the message with any saved nonce on the receiving
	interface. If a match is found, the node SHOULD log a system		interface. If a match is found, the node SHOULD log a system
	management message, SHOULD update any statistics counter, and MUST		management message, SHOULD update any statistics counter, MUST drop
	drop the received message. If the received NS(DAD) message includes		the received message, and move the Target Address to assigned state.
	a nonce and no match is found with any saved nonce, the node SHOULD
	log a system management message for DAD-failed and SHOULD update any		If the received NS(DAD) message includes a nonce and no match is
	statistics counter. TODO: Define termination condition.		found with any saved nonce, the node SHOULD log a system management
			message for DAD-failed and SHOULD update any statistics counter.
	4.4. Impact on SEND		4.4. Impact on SEND
	The SEND document uses the Nonce Option in the context of matching an		The SEND document uses the Nonce Option in the context of matching an
	NA with an NS. However, no text in SEND has an explicit mention of		NA with an NS. However, no text in SEND has an explicit mention of
	detecting looped back ND messages. If this document updates		detecting looped back ND messages. If this document updates
	[RFC4862], SEND should be updated to integrate with the Enhanced DAD		[RFC4862], SEND should be updated to integrate with the Enhanced DAD
	algorithm. A minor update to SEND would be to explicitly mention		algorithm. A minor update to SEND would be to explicitly mention
	that the nonce in SEND is also used by SEND to detect looped back NS		that the nonce in SEND is also used by SEND to detect looped back NS
	messages during DAD operations by the node. In a mixed SEND		messages during DAD operations by the node. In a mixed SEND
	skipping to change at page 9, line 5		skipping to change at page 8, line 44
	address and if the DAD probe is reflected back to the interface, the		address and if the DAD probe is reflected back to the interface, the
	interface is stuck in DAD failed state and IPv6 services to the 100		interface is stuck in DAD failed state and IPv6 services to the 100
	thousand clients is denied. Disabling DAD for such an IPv6 interface		thousand clients is denied. Disabling DAD for such an IPv6 interface
	on an access concentrator is not an option because the network also		on an access concentrator is not an option because the network also
	needs to detect genuine duplicates in the interface downstream		needs to detect genuine duplicates in the interface downstream
	network. The Enhanced DAD algorithm also facilitates detecting a		network. The Enhanced DAD algorithm also facilitates detecting a
	genuine duplicate for the interface on the access concentrator. See		genuine duplicate for the interface on the access concentrator. See
	the Actions to Perform on Detecting a Genuine Duplicate section of		the Actions to Perform on Detecting a Genuine Duplicate section of
	the Enhanced DAD document.		the Enhanced DAD document.
			4.6. Changes to RFC 4861
			1. The RetransTimer may be overridden by a link-specific document if
			a node supports the Enhanced DAD algorithm.
			2. If a node has been configured to use the Enhanced DAD algorithm,
			an NS with an unspecified source address adds the Nonce option to
			the message and implements the state machine of the Enhanced DAD
			algorithm.
	5. Actions to Perform on Detecting a Genuine Duplicate		5. Actions to Perform on Detecting a Genuine Duplicate
	As described in paragraphs above the nonce can also serve to detect		As described in paragraphs above the nonce can also serve to detect
	genuine duplicates even when the network has potential for looping		genuine duplicates even when the network has potential for looping
	back ND messages. When a genuine duplicate is detected, the node		back ND messages. When a genuine duplicate is detected, the node
	follows the manual intervention specified in section 5.4.5 of		follows the manual intervention specified in section 5.4.5 of
	[RFC4862]. However, in certain networks such as an access network if		[RFC4862]. However, in certain networks such as an access network if
	the genuine duplicate matches the tentative or optimistic IPv6		the genuine duplicate matches the tentative or optimistic IPv6
	address of a network interface of the access concentrator, automated		address of a network interface of the access concentrator, automated
	actions are proposed.		actions are proposed.
	skipping to change at page 10, line 4		skipping to change at page 9, line 50
	security issue before a remote node on the link can issue reflected		security issue before a remote node on the link can issue reflected
	NS(DAD) messages. Again, SEND is recommended for this exploit.		NS(DAD) messages. Again, SEND is recommended for this exploit.
	7. IANA Considerations		7. IANA Considerations
	None.		None.
	8. Acknowledgements		8. Acknowledgements
	Thanks (in alphabetical order by first name) to Dmitry Anipko, Eric		Thanks (in alphabetical order by first name) to Dmitry Anipko, Eric
	Levy-Abegnoli, Erik Nordmark, Fred Templin, Michael Sinatra, Ray		Levy-Abegnoli, Erik Nordmark, Fred Templin, Michael Sinatra, Ole
	Hunter, Suresh Krishnan, and Tassos Chatzithomaoglou for their		Troan, Ray Hunter, Suresh Krishnan, and Tassos Chatzithomaoglou for
	guidance and review of the document. Thanks to Thomas Narten for		their guidance and review of the document. Thanks to Thomas Narten
	encouraging this work. Thanks to Steinar Haug and Scott Beuker for		for encouraging this work. Thanks to Steinar Haug and Scott Beuker
	describing the use cases.		for describing the use cases.
	9. Normative References		9. Normative References
	[I-D.ietf-6man-impatient-nud]		[I-D.ietf-6man-impatient-nud]
	Nordmark, E. and I. Gashinsky, "Neighbor Unreachability		Nordmark, E. and I. Gashinsky, "Neighbor Unreachability
	Detection is too impatient",		Detection is too impatient", draft-ietf-6man-impatient-
	draft-ietf-6man-impatient-nud-05 (work in progress),		nud-06 (work in progress), April 2013.
	October 2012.
	[RFC1247] Moy, J., "OSPF Version 2", RFC 1247, July 1991.		[RFC1247] Moy, J., "OSPF Version 2", RFC 1247, July 1991.
	[RFC1661] Simpson, W., "The Point-to-Point Protocol (PPP)", STD 51,		[RFC1661] Simpson, W., "The Point-to-Point Protocol (PPP)", STD 51,
	RFC 1661, July 1994.		RFC 1661, July 1994.
	[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate		[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
	Requirement Levels", BCP 14, RFC 2119, March 1997.		Requirement Levels", BCP 14, RFC 2119, March 1997.
	[RFC3971] Arkko, J., Kempf, J., Zill, B., and P. Nikander, "SEcure		[RFC3971] Arkko, J., Kempf, J., Zill, B., and P. Nikander, "SEcure
	skipping to change at page 10, line 39		skipping to change at page 10, line 35
	[RFC4429] Moore, N., "Optimistic Duplicate Address Detection (DAD)		[RFC4429] Moore, N., "Optimistic Duplicate Address Detection (DAD)
	for IPv6", RFC 4429, April 2006.		for IPv6", RFC 4429, April 2006.
	[RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman,		[RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman,
	"Neighbor Discovery for IP version 6 (IPv6)", RFC 4861,		"Neighbor Discovery for IP version 6 (IPv6)", RFC 4861,
	September 2007.		September 2007.
	[RFC4862] Thomson, S., Narten, T., and T. Jinmei, "IPv6 Stateless		[RFC4862] Thomson, S., Narten, T., and T. Jinmei, "IPv6 Stateless
	Address Autoconfiguration", RFC 4862, September 2007.		Address Autoconfiguration", RFC 4862, September 2007.
	Appendix A. Changes from the -01 version
	1. Changed the algorithm in section 4 and other sections to not
	suppress subsequent probes and instead probe forever subject to a
	termination condition.
	2. Minor edits were made for more clarified text.
	Authors' Addresses		Authors' Addresses
	Rajiv Asati		Rajiv Asati
	Cisco Systems, Inc.		Cisco Systems, Inc.
	7025 Kit Creek road		7025 Kit Creek road
	Research Triangle Park, NC 27709-4987		Research Triangle Park, NC 27709-4987
	USA		USA
	Email: rajiva@cisco.com		Email: rajiva@cisco.com
	URI: http://www.cisco.com/		URI: http://www.cisco.com/
End of changes. 21 change blocks.
	84 lines changed or deleted		91 lines changed or added
This html diff was produced by rfcdiff 1.41. The latest version is available from http://tools.ietf.org/tools/rfcdiff/