draft-ietf-6man-enhanced-dad-05.txt		draft-ietf-6man-enhanced-dad-06.txt
	Network Working Group R. Asati		Network Working Group R. Asati
	Internet-Draft H. Singh		Internet-Draft H. Singh
	Updates: 4862, 4861, 3971 (if approved) W. Beebee		Updates: 4862, 4861, 3971 (if approved) W. Beebee
	Intended status: Standards Track Cisco Systems, Inc.		Intended status: Standards Track C. Pignataro
	Expires: November 3, 2014 E. Dart		Expires: January 22, 2015 Cisco Systems, Inc.
			E. Dart
	Lawrence Berkeley National Laboratory		Lawrence Berkeley National Laboratory
	W. George		W. George
	Time Warner Cable		Time Warner Cable
	C. Pignataro		July 21, 2014
	Cisco Systems, Inc.
	May 2, 2014
	Enhanced Duplicate Address Detection		Enhanced Duplicate Address Detection
	draft-ietf-6man-enhanced-dad-05		draft-ietf-6man-enhanced-dad-06
	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
	skipping to change at page 1, line 48		skipping to change at page 1, line 47
	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 November 3, 2014.		This Internet-Draft will expire on January 22, 2015.
	Copyright Notice		Copyright Notice
	Copyright (c) 2014 IETF Trust and the persons identified as the		Copyright (c) 2014 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 . . . . . . . . . . . . . . . . . . . . . . . . . 2		1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
	1.1. Requirements Language . . . . . . . . . . . . . . . . . . 3		1.1. Two Deployment Problems . . . . . . . . . . . . . . . . . 3
	2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3		2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4
	3. Operational Mitigation Options . . . . . . . . . . . . . . . 4		2.1. Requirements Language . . . . . . . . . . . . . . . . . . 4
			3. Operational Mitigation Options . . . . . . . . . . . . . . . 5
	3.1. Disable DAD on Interface . . . . . . . . . . . . . . . . 5		3.1. Disable DAD on Interface . . . . . . . . . . . . . . . . 5
	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 . . . . . . . . . . . . . . . 6
	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 . . . . . . . . . . . . . 7		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
	4.6. Changes to RFC 4861 . . . . . . . . . . . . . . . . . . . 9		4.6. Changes to RFC 4861 . . . . . . . . . . . . . . . . . . . 9
	4.7. Changes to RFC 3971 . . . . . . . . . . . . . . . . . . . 9		4.7. Changes to RFC 3971 . . . . . . . . . . . . . . . . . . . 9
	5. Actions to Perform on Detecting a Genuine Duplicate . . . . . 9		5. Actions to Perform on Detecting a Genuine Duplicate . . . . . 9
	6. Security Considerations . . . . . . . . . . . . . . . . . . . 10		6. Security Considerations . . . . . . . . . . . . . . . . . . . 10
	7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10		7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10
	8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 10		8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 10
	9. Normative References . . . . . . . . . . . . . . . . . . . . 10		9. Normative References . . . . . . . . . . . . . . . . . . . . 10
	Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 11		Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 11
	1. Terminology		1. Introduction
	o DAD-failed state - Duplication Address Detection failure as
	specified in [RFC4862]. Note even Optimistic DAD as specified in
	[RFC4429] can fail due to a looped back DAD probe. This document
	covers looped back detection for Optimistic DAD as well.
	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 network or a Upper Layer Protocol on the sender looping the
	message back.
	o Loopback - A function in which the router's interface (or the
	circuit to which the router's interface is connected) is looped
	back or connected to itself. Loopback causes packets sent by the
	interface to be received by the interface, and results in
	interface unavailability for regular data traffic forwarding. See
	more details in section 9.1 of [RFC1583]. The Loopback function
	is commonly used in an interface context to gain information on
	the quality of the interface, by employing mechanisms such as
	ICMPv6 pings, bit-error tests, etc. In a circuit context, it is
	used in wide area environments including optical dense wave
	division multiplexing (DWDM) and SONET/SDH for fault isolation
	(e.g. by placing a loopback at different geographic locations
	along the path of a wide area circuit to help locate a circuit
	fault). The Loopback function may be employed locally or
	remotely.
	o NS(DAD) - shorthand notation to denote an Neighbor Solicitation
	(NS) with unspecified IPv6 source-address issued during DAD.
	1.1. Requirements Language
	The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
	"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
	document are to be interpreted as described in RFC 2119 [RFC2119].
	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
	document focuses on detecting an NS looped back to the transmitting		document focuses on detecting an NS looped back to the transmitting
	interface during the DAD operation. Detecting a looped back NA is of		interface during the DAD operation. Detecting a looped back NA is of
	no use because no problems with DAD will occur if a node receives a		no use because no problems with DAD will occur if a node receives a
	looped back NA. Detection of any other looped back ND messages		looped back NA. Detection of any other looped back ND messages
	outside of the DAD operation is not critical and thus this document		outside of the DAD operation is not critical and thus this document
	does not cover such detection. The document also includes a		does not cover such detection. The document also includes a
	Mitigation section that discusses means already available to mitigate		Mitigation section that discusses means already available to mitigate
	the loopback problem.		the loopback problem.
			1.1. Two Deployment Problems
			In each problem articulated below, the IPv6 link-local address DAD
			operation fails due to a looped back DAD probe. However, the looped
			back DAD probe exists for any IPv6 address type including global
			addresses.
	Recently, service providers have reported a problem with DAD that is		Recently, service providers have reported a problem with DAD that is
	caused by looped back NS messages. The following is a description of		caused by looped back NS messages. The following is a description of
	the circumstances under which the problem arises. Loopback testing		the circumstances under which the problem arises. Loopback testing
	for troubleshooting purposes is underway on a circuit connected to an		for troubleshooting purposes is underway on a circuit connected to an
	interface on a router. The interface on the router is enabled for		interface on a router. The interface on the router is enabled for
	IPv6. The interface issues a NS for the IPv6 link-local address DAD.		IPv6. The interface issues a NS for the IPv6 link-local address DAD.
	The NS is reflected back to the router interface due to the loopback		The NS is reflected back to the router interface due to the loopback
	condition of the circuit, and the router interface enters a DAD-		condition of the circuit, and the router interface enters a DAD-
	failed state. After the circuit troubleshooting has concluded and		failed state. After the circuit troubleshooting has concluded and
	the loopback condition is removed, IPv4 will return to operation		the loopback condition is removed, IPv4 will return to operation
	without further manual intervention. However, IPv6 will remain in		without further manual intervention. However, IPv6 will remain in
	DAD-failed state until manual intervention on the router restores		DAD-failed state until manual intervention on the router restores
	IPv6 to operation.		IPv6 to operation.
	There are other conditions which will also trigger similar problems		There are other conditions which will also trigger similar problems
	with DAD Loopback. While the following example is not a common		with DAD Loopback. While the following example is not a common
	configuration, it has occurred in a large service provider network.		configuration, it has occurred in a large service provider network.
	It is necessary to address it in the proposed solution because the		It is necessary to address it in the proposed solution because the
	trigger scenario has the potential to cause significant IPv6 service		trigger scenario has the potential to cause significant IPv6 service
	outages when it does occur. Two broadband modems in the same		outages when it does occur. Two broadband modems in the same home
	location are served by the same service provider and both modems are		are served by the same service provider and both modems are served by
	served by one access concentrator and one layer 3 interface on the		one access concentrator and one layer-3 interface on the access
	access concentrator. The two modems have the Ethernet ports of each		concentrator. The two modems have the Ethernet ports of each modem
	modem connected to a network hub. The access concentrator serving		connected to a network hub. The access concentrator serving the
	the modems is the first-hop IPv6 router for the modems. The access		modems is the first-hop IPv6 router for the modems. The network
	concentrator also supports proxying of DAD messages. Each modem is		interface of the access concentrator serving the two broadband modems
	enabled for at least data services. The network interface of the		is enabled for IPv6 and the interface issues a NS(DAD) message for
	access concentrator serving the two broadband modems is enabled for		the IPv6 link-local address. The NS message reaches one modem first
	IPv6 and the interface issues a NS(DAD) message for the IPv6 link-		and this modem sends the message to the network hub which sends the
	local address. The NS message reaches one modem first and this modem		message to the second modem which forwards the message back to the
	sends the message to the network hub which sends the message to the		access concentrator. The looped back NS message causes the network
	second modem which forwards the message back to the access
	concentrator. The looped back NS message causes the network
	interface on the access concentrator to be in a DAD-failed state.		interface on the access concentrator to be in a DAD-failed state.
	Such a network interface typically serves up to 100 thousand		Such a network interface typically serves up to hundred thousands
	broadband modems causing all the modems (and hosts behind the modems)		broadband modems causing all the modems (and hosts behind the modems)
	to fail to get IPv6 online on the access network. Additionally, it		to fail to get IPv6 online on the access network. Additionally, it
	may be tedious for the access concentrator to find out which of the		may be tedious for the access concentrator to find out which of the
	six thousand or more homes looped back the DAD message. Clearly		hundred thousand or more homes looped back the DAD message. Clearly
	there is a need for automated detection of looped back NS messages		there is a need for automated detection of looped back NS messages
	during DAD operations by a node.		during DAD operations by a node.
			2. Terminology
			o DAD-failed state - Duplication Address Detection failure as
			specified in [RFC4862]. Note even Optimistic DAD as specified in
			[RFC4429] can fail due to a looped back DAD probe. This document
			covers looped back detection for Optimistic DAD as well.
			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 network or a Upper Layer Protocol on the sender looping the
			message back.
			o Loopback - A function in which the router's layer-3 interface (or
			the circuit to which the router's interface is connected) is
			looped back or connected to itself. Loopback causes packets sent
			by the interface to be received by the interface, and results in
			interface unavailability for regular data traffic forwarding. See
			more details in section 9.1 of [RFC1583]. The Loopback function
			is commonly used in an interface context to gain information on
			the quality of the interface, by employing mechanisms such as
			ICMPv6 pings, bit-error tests, etc. In a circuit context, it is
			used in wide area environments including optical dense wave
			division multiplexing (DWDM) and SONET/SDH for fault isolation
			(e.g. by placing a loopback at different geographic locations
			along the path of a wide area circuit to help locate a circuit
			fault). The Loopback function may be employed locally or
			remotely.
			o NS(DAD) - shorthand notation to denote an Neighbor Solicitation
			(NS) (as specified in [RFC4861]) with unspecified IPv6 source-
			address issued during DAD.
			2.1. Requirements Language
			The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
			"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
			document are to be interpreted as described in [RFC2119].
	3. Operational Mitigation Options		3. Operational Mitigation Options
	Two mitigation options are described below. The mechanisms do not		Two mitigation options are described below. The mechanisms do not
	require any change to existing implementations.		require any change to existing implementations.
	3.1. Disable DAD on Interface		3.1. Disable DAD on Interface
	One can disable DAD on an interface and then there is no NS(DAD)		One can disable DAD on an interface and then there is no NS(DAD)
	issued to be looped back. DAD is disabled by setting the interface's		issued to be looped back. DAD is disabled by setting the interface's
	DupAddrDetectTransmits variable to zero. While this mitigation may		DupAddrDetectTransmits variable to zero. While this mitigation may
	be the simplest the mitigation has three drawbacks.		be the simplest the mitigation has three drawbacks.
	It would likely require careful analysis of configuration on such		It would likely require careful analysis of configuration on such
	point-to-point interfaces, a one-time manual configuration on each of		point-to-point interfaces, a one-time manual configuration on each of
	such interfaces, and more importantly, genuine duplicates in the link		such interfaces, and more importantly, genuine duplicates in the link
	will not be detected.		will not be detected.
	A Service Provider router such as an access concentrator or network		A Service Provider router such as an access concentrator or network
	core router SHOULD support this mitigation strategy.		core router SHOULD support this mitigation strategy.
	3.2. Dynamic Disable/Enable of DAD Using Layer 2 Protocol		3.2. Dynamic Disable/Enable of DAD Using Layer-2 Protocol
	It is possible that one or more layer 2 protocols include provisions		It is possible that one or more layer-2 protocols include provisions
	to detect the existence of a loopback on an interface circuit,		to detect the existence of a loopback on an interface circuit,
	usually by comparing protocol data sent and received. For example,		usually by comparing protocol data sent and received. For example,
	PPP uses magic number (section 6.4 of [RFC1661]) to detect a loopback		PPP uses magic number (section 6.4 of [RFC1661]) to detect a loopback
	on an interface.		on an interface.
	When a layer 2 protocol detects that a loopback is present on an		When a layer-2 protocol detects that a loopback is present on an
	interface circuit, the device MUST temporarily disable DAD on the		interface circuit, the device MUST temporarily disable DAD on the
	interface, and when the protocol detects that a loopback is no longer		interface, and when the protocol detects that a loopback is no longer
	present (or the interface state has changed), the device MUST		present (or the interface state has changed), the device MUST
	(re-)enable DAD on that interface.		(re-)enable DAD on that interface.
	This solution requires no protocol changes. This solution SHOULD be		This solution requires no protocol changes. This solution SHOULD be
	enabled by default, and MUST be a configurable option if the layer 2		enabled by default, and MUST be a configurable option if the layer-2
	technology provides means for detecting loopback messages on an		technology provides means for detecting loopback messages on an
	interface circuit.		interface circuit.
	This mitigation has several benefits. They are		This mitigation has several benefits. They are
	1. It leverages layer 2 protocol's built-in loopback detection		1. It leverages layer-2 protocol's built-in loopback detection
	capability, if available.		capability, if available.
	2. It scales better since it relies on an event-driven model which		2. It scales better since it relies on an event-driven model which
	requires no additional state or timer. This may be a significant		requires no additional state or timer. This may be a significant
	scaling consideration on devices with hundreds or thousands of		scaling consideration on devices with hundreds or thousands of
	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
	skipping to change at page 6, line 41		skipping to change at page 6, line 43
	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 in section 4.4.		SEND. See more details in the Impact on SEND section in section 4.4.
	Since a nonce is used only once, DAD for each IPv6 address of an		Since a nonce is used only once, DAD for each IPv6 address of an
	interface uses a different nonce. Additional details of the		interface uses a different nonce. Additional details of the
	algorithm are included in section 4.2.		algorithm are included in section 4.2.
	Six bytes of random nonce is sufficiently large for nonce collisions.		Six bytes of random nonce is sufficiently large for collisions.
	However if there is a collision because two nodes that are using the		However if there is a collision because two nodes that are using the
	same Target Address in their NS(DAD) generated the same random nonce,		same Target Address in their NS(DAD) generated the same random nonce,
	then the algorithm will incorrectly detect a looped back NS(DAD) when		then the algorithm will incorrectly detect a looped back NS(DAD) when
	a genuine address collision has occurred. Since each looped back		a genuine address collision has occurred. Since each looped back
	NS(DAD) event is logged to system management, the administrator of		NS(DAD) event is logged to system management, the administrator of
	the network will have access to the information necessary to		the network will have access to the information necessary to
	intervene manually. Also, because the nodes will have detected what		intervene manually. Also, because the nodes will have detected what
	appear to be looped back NS(DAD) messages, they will continue to		appear to be looped back NS(DAD) messages, they will continue to
	probe and it is unlikely that they will choose the same nonce the		probe and it is unlikely that they will choose the same nonce the
	second time (assuming quality random number generators).		second time (assuming quality random number generators).
	skipping to change at page 7, line 26		skipping to change at page 7, line 28
	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 the interface does not receive		Option included in the NS(DAD). If the interface does not receive
	any DAD failure indications within RetransTimer milliseconds after		any DAD failure indications within RetransTimer milliseconds (see
	having sent DupAddrDetectTransmits Neighbor Solicitations, the		[RFC4861]) after having sent DupAddrDetectTransmits Neighbor
	interface moves the Target Address to assigned state. If any probe		Solicitations, the interface moves the Target Address to assigned
	is looped back within RetransTimer milliseconds after having sent		state.
	DupAddrDetectTransmits NS(DAD) messages, the interface continues with
	another MAX_MULTICAST_SOLICIT number of NS(DAD) messages spaced		If any probe is looped back within RetransTimer milliseconds after
	RetransTimer apart. If no probe is looped back within RetransTimer		having sent DupAddrDetectTransmits NS(DAD) messages, the interface
	milliseconds after MAX_MULTICAST_SOLICIT NS(DAD) messages are sent,		continues with another MAX_MULTICAST_SOLICIT number of NS(DAD)
	the probing stops else a new MAX_MULTICAST_SOLICIT number of NS(DAD)		messages transmitted RetransTimer millseconds apart. If no probe is
	messages sequence is initiated. The MAX_MULTICAST_SOLICIT number of		looped back within RetransTimer milliseconds after
	NS(DAD) messages sequence continues until the stop condition is		MAX_MULTICAST_SOLICIT NS(DAD) messages are sent, the probing stops.
	reached or manual intervention is undertaken. The interface moves		The probing MAY be stopped via manual intervention. When probing is
	the Target Address to assigned state.		stopped, the interface moves the Target Address to assigned state.
	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 included in the
	included in the message with any saved nonce on the receiving		message, if any, with any saved nonce on the receiving interface. If
	interface. If a match is found, the node SHOULD log a system		a match is found, the node SHOULD log a system management message,
	management message, SHOULD update any statistics counter, MUST drop		SHOULD update any statistics counter, MUST drop the received message.
	the received message. If the received NS(DAD) message includes a		If the received NS(DAD) message includes a nonce and no match is
	nonce and no match is found with any saved nonce, the node SHOULD log		found with any saved nonce, the node SHOULD log a system management
	a system management message for DAD-failed and SHOULD update any		message for DAD-failed and SHOULD update any statistics counter. If
	statistics counter. If the interface does not receive any DAD		the interface does not receive any DAD failure indications within
	failure indications within RetransTimer milliseconds after having		RetransTimer milliseconds after having sent DupAddrDetectTransmits
	sent DupAddrDetectTransmits Neighbor Solicitations, the interface		Neighbor Solicitations, the interface moves the Target Address to
	moves the Target Address to assigned state.		assigned state.
	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 8, line 32		skipping to change at page 8, line 35
	The following text is added to the end of the Introduction section of		The following text is added to the end of the Introduction section of
	[RFC4862].		[RFC4862].
	A network interface of an IPv6 node SHOULD implement the Enhanced DAD		A network interface of an IPv6 node SHOULD implement the Enhanced DAD
	algorithm. For example, if the interface on an IPv6 node is		algorithm. For example, if the interface on an IPv6 node is
	connected to a circuit that supports loopback testing, then the node		connected to a circuit that supports loopback testing, then the node
	should implement the Enhanced DAD algorithm that allows the IPv6		should implement the Enhanced DAD algorithm that allows the IPv6
	interface to self-heal after loopback testing is ended on the		interface to self-heal after loopback testing is ended on the
	circuit. Another example is when the IPv6 interface resides on an		circuit. Another example is when the IPv6 interface resides on an
	access concentrator running DAD Proxy. The interface supports up to		access concentrator running DAD Proxy. The interface supports up to
	100 thousand IPv6 clients (broadband modems) connected to the		hundred thousands IPv6 clients (broadband modems) connected to the
	interface. If the interface performs DAD for its IPv6 link-local		interface. If the interface performs DAD for its IPv6 link-local
	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
	thousand clients is denied. Disabling DAD for such an IPv6 interface		hundred thousands clients is denied. Disabling DAD for such an IPv6
	on an access concentrator is not an option because the network also		interface on an access concentrator is less desirable than
	needs to detect genuine duplicates in the interface downstream		implementing the algorithm because the network also needs to detect
	network. The Enhanced DAD algorithm also facilitates detecting a		genuine duplicates in the interface downstream network. The Enhanced
	genuine duplicate for the interface on the access concentrator. See		DAD algorithm also facilitates detecting a genuine duplicate for the
	the Actions to Perform on Detecting a Genuine Duplicate section of		interface on the access concentrator. See the Actions to Perform on
	the Enhanced DAD document.		Detecting a Genuine Duplicate section of the Enhanced DAD document.
	The following text is added to the end of Appendix A of [RFC4862].		The following text is added to the end of Appendix A of [RFC4862].
	The Enhanced DAD algorithm from TBD RFC is designed to detect looped		The Enhanced DAD algorithm from draft-ietf-6man-enhanced-dad is
	back DAD probes. A network interface of an IPv6 node SHOULD		designed to detect looped back DAD probes. A network interface of an
	implement the Enhanced DAD algorithm.		IPv6 node SHOULD implement the Enhanced DAD algorithm.
	4.6. Changes to RFC 4861		4.6. Changes to RFC 4861
	The following text is appended to the RetransTimer variable		The following text is appended to the RetransTimer variable
	description in section 6.3.2 of [RFC4861].		description in section 6.3.2 of [RFC4861].
	The RetransTimer may be overridden by a link-specific document if a		The RetransTimer may be overridden by a link-specific document if a
	node supports the Enhanced DAD algorithm.		node supports the Enhanced DAD algorithm.
	The following text is appended to the Source Address definition in		The following text is appended to the Source Address definition in
	skipping to change at page 9, line 34		skipping to change at page 9, line 34
	The purpose of the Nonce option is to make sure that an advertisement		The purpose of the Nonce option is to make sure that an advertisement
	is a fresh response to a solicitation sent earlier by the node.		is a fresh response to a solicitation sent earlier by the node.
	New text is included below.		New text is included below.
	The purpose of the Nonce option is to make sure that an advertisement		The purpose of the Nonce option is to make sure that an advertisement
	is a fresh response to a solicitation sent earlier by the node. The		is a fresh response to a solicitation sent earlier by the node. The
	nonce is also used to detect looped back NS messages when the network		nonce is also used to detect looped back NS messages when the network
	interface performs DAD [RFC4862]. Detecting looped back DAD messages		interface performs DAD [RFC4862]. Detecting looped back DAD messages
	is covered by the Enhanced DAD algorithm as specified in TBD RFC. In		is covered by the Enhanced DAD algorithm as specified in draft-ietf-
	a mixed SEND environment with SEND and unsecured nodes, the lengths		6man-enhanced-dad. In a mixed SEND environment with SEND and
	of the nonce used by SEND and unsecured nodes MUST be identical.		unsecured nodes, the lengths of the nonce used by SEND and unsecured
			nodes MUST be identical.
	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
	skipping to change at page 9, line 52		skipping to change at page 10, line 4
	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.
	One access network is a cable broadband deployment where the access		One access network is a cable broadband deployment where the access
	concentrator is the first-hop IPv6 router to several thousand		concentrator is the first-hop IPv6 router to several thousand
	broadband modems. The router also supports proxying of DAD messages.		broadband modems. The router also supports proxying of DAD messages.
	The network interface on the access concentrator initiates DAD for an		The network interface on the access concentrator initiates DAD for an
	IPv6 address and detects a genuine duplicate due to receiving an		IPv6 address and detects a genuine duplicate due to receiving an
	NS(DAD) or an NA message. On detecting such a duplicate the access		NS(DAD) or an NA message. On detecting such a duplicate the access
	concentrator logs a system management message, drops the received ND		concentrator logs a system management message, drops the received ND
	message, and blocks the modem on whose layer 2 service identifier the		message, and blocks the modem on whose layer-2 service identifier the
	NS(DAD) or NA message was received on.		NS(DAD) or NA message was received on.
	The network described above follows a trust model where a trusted		The network described above follows a trust model where a trusted
	router serves un-trusted IPv6 host nodes. Operators of such networks		router serves un-trusted IPv6 host nodes. Operators of such networks
	have a desire to take automated action if a network interface of the		have a desire to take automated action if a network interface of the
	trusted router has a tentative or optimistic address duplicate with a		trusted router has a tentative or optimistic address duplicate with a
	host served by trusted router interface. Any other network that		host served by trusted router interface. Any other network that
	follows the same trust model MAY use the automated actions proposed		follows the same trust model MAY use the automated actions proposed
	in this section.		in this section.
	6. Security Considerations		6. Security Considerations
	The nonce can be exploited by a rogue deliberately changing the nonce		The nonce can be exploited by a rogue deliberately changing the nonce
	to fail the looped back detection specified by the Enhanced DAD		to fail the looped back detection specified by the Enhanced DAD
	algorithm. SEND is recommended to circumvent this exploit. For any		algorithm. SEND is recommended to circumvent this exploit.
	mitigation suggested in the document such as disabling DAD has an		Additionally, the nonce does not protect against the DoS caused by a
	obvious security issue before a remote node on the link can issue		rogue node replying by fake NA to all DAD probes. SEND is
	reflected NS(DAD) messages. Again, SEND is recommended for this		recommended to circumvent this exploit. For any mitigation suggested
	exploit.		in the document such as disabling DAD has an obvious security issue
			before a remote node on the link can issue reflected 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, Jouni Korhonen, Michael		Levy-Abegnoli, Eric Vyncke, Erik Nordmark, Fred Templin, Jouni
	Sinatra, Ole Troan, Ray Hunter, Suresh Krishnan, and Tassos		Korhonen, Michael Sinatra, Ole Troan, Ray Hunter, Suresh Krishnan,
	Chatzithomaoglou for their guidance and review of the document.		and Tassos Chatzithomaoglou for their guidance and review of the
	Thanks to Thomas Narten for encouraging this work. Thanks to Steinar		document. Thanks to Thomas Narten for encouraging this work. Thanks
	Haug and Scott Beuker for describing the use cases.		to Steinar Haug and Scott Beuker for describing the use cases.
	9. Normative References		9. Normative References
	[RFC1583] Moy, J., "OSPF Version 2", RFC 1583, March 1994.		[RFC1583] Moy, J., "OSPF Version 2", RFC 1583, March 1994.
	[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.
	skipping to change at page 12, line 4		skipping to change at page 12, line 4
	Wes Beebee		Wes Beebee
	Cisco Systems, Inc.		Cisco Systems, Inc.
	1414 Massachusetts Ave.		1414 Massachusetts Ave.
	Boxborough, MA 01719		Boxborough, MA 01719
	USA		USA
	Phone: +1 978 936 2030		Phone: +1 978 936 2030
	Email: wbeebee@cisco.com		Email: wbeebee@cisco.com
	URI: http://www.cisco.com/		URI: http://www.cisco.com/
			Carlos Pignataro
			Cisco Systems, Inc.
			7200-12 Kit Creek Road
			Research Triangle Park, NC 27709
			USA
			Email: cpignata@cisco.com
			URI: http://www.cisco.com/
	Eli Dart		Eli Dart
	Lawrence Berkeley National Laboratory		Lawrence Berkeley National Laboratory
	1 Cyclotron Road, Berkeley, CA 94720		1 Cyclotron Road, Berkeley, CA 94720
	USA		USA
	Email: dart@es.net		Email: dart@es.net
	URI: http://www.es.net/		URI: http://www.es.net/
	Wes George		Wes George
	Time Warner Cable		Time Warner Cable
	13820 Sunrise Valley Drive		13820 Sunrise Valley Drive
	Herndon, VA 20171		Herndon, VA 20171
	USA		USA
	Email: wesley.george@twcable.com		Email: wesley.george@twcable.com
	Carlos Pignataro
	Cisco Systems, Inc.
	7200-12 Kit Creek Road
	Research Triangle Park, NC 27709
	USA
	Email: cpignata@cisco.com
	URI: http://www.cisco.com/
End of changes. 30 change blocks.
	122 lines changed or deleted		141 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/