draft-ietf-6man-enhanced-dad-07.txt		draft-ietf-6man-enhanced-dad-08.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 C. Pignataro		Intended status: Standards Track C. Pignataro
	Expires: April 26, 2015 Cisco Systems, Inc.		Expires: May 14, 2015 Cisco Systems, Inc.
	E. Dart		E. Dart
	Lawrence Berkeley National Laboratory		Lawrence Berkeley National Laboratory
	W. George		W. George
	Time Warner Cable		Time Warner Cable
	October 23, 2014		November 10, 2014
	Enhanced Duplicate Address Detection		Enhanced Duplicate Address Detection
	draft-ietf-6man-enhanced-dad-07		draft-ietf-6man-enhanced-dad-08
	Abstract		Abstract
	IPv6 Loopback Suppression and Duplicate Address Detection (DAD) are		IPv6 Loopback Suppression and Duplicate Address Detection (DAD) are
	discussed in Appendix A of [RFC4862]. That specification mentions a		discussed in Appendix A of [RFC4862]. That specification mentions a
	hardware-assisted mechanism to detect looped back DAD messages. If		hardware-assisted mechanism to detect looped back DAD messages. If
	hardware cannot suppress looped back DAD messages, a software		hardware cannot suppress looped back DAD messages, a software
	solution is required. Several service provider communities have		solution is required. Several service provider communities have
	expressed a need for automated detection of looped backed Neighbor		expressed a need for automated detection of looped backed Neighbor
	Discovery (ND) messages used by DAD. This document includes		Discovery (ND) messages used by DAD. This document includes
	skipping to change at page 1, line 48		skipping to change at page 1, line 48
	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 April 26, 2015.		This Internet-Draft will expire on May 14, 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
	skipping to change at page 2, line 31		skipping to change at page 2, line 31
	1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2		1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
	1.1. Two Deployment Problems . . . . . . . . . . . . . . . . . 3		1.1. Two Deployment Problems . . . . . . . . . . . . . . . . . 3
	2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4		2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4
	2.1. Requirements Language . . . . . . . . . . . . . . . . . . 4		2.1. Requirements Language . . . . . . . . . . . . . . . . . . 4
	3. Operational Mitigation Options . . . . . . . . . . . . . . . 5		3. Operational Mitigation Options . . . . . . . . . . . . . . . 5
	3.1. Disable DAD on an Interface . . . . . . . . . . . . . . . 5		3.1. Disable DAD on an 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. Processing Rules for Senders . . . . . . . . . . . . . . 7
	4.2. Processing Rules for Senders . . . . . . . . . . . . . . 7		4.2. Processing Rules for Receivers . . . . . . . . . . . . . 7
	4.3. Processing Rules for Receivers . . . . . . . . . . . . . 7		4.3. Impact on SEND . . . . . . . . . . . . . . . . . . . . . 8
	4.4. Impact on SEND . . . . . . . . . . . . . . . . . . . . . 8		4.4. Changes to RFC 4862 . . . . . . . . . . . . . . . . . . . 8
	4.5. Changes to RFC 4862 . . . . . . . . . . . . . . . . . . . 8		4.5. Changes to RFC 4861 . . . . . . . . . . . . . . . . . . . 8
	4.6. Changes to RFC 4861 . . . . . . . . . . . . . . . . . . . 9		4.6. 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. Introduction		1. Introduction
	IPv6 Loopback Suppression and Duplicate Address Detection (DAD) are		IPv6 Loopback Suppression and Duplicate Address Detection (DAD) are
	skipping to change at page 3, line 40		skipping to change at page 3, line 39
	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 home		outages when it does occur. In this scenario, two broadband modems
	are served by the same service provider and both modems are served by		in the same home are served by the same service provider and both
	one access concentrator and one layer-3 interface on the access		modems are served by one access concentrator and one layer-3
	concentrator. The two modems have the Ethernet ports of each modem		interface on the access concentrator. The two modems have the
	connected to a network hub. The access concentrator serving the		Ethernet ports of each modem connected to a network hub. The access
	modems is the first-hop IPv6 router for the modems. The network		concentrator serving the modems is the first-hop IPv6 router for the
	interface of the access concentrator serving the two broadband modems		modems. The network interface of the access concentrator serving the
	is enabled for IPv6 and the interface issues a NS(DAD) message for		two broadband modems is enabled for IPv6 and the interface issues a
	the IPv6 link-local address. The NS message reaches one modem first		NS(DAD) message for the IPv6 link-local address. The NS message
	and this modem sends the message to the network hub which sends the		reaches one modem first and this modem sends the message to the
	message to the second modem which forwards the message back to the		network hub which sends the message to the second modem which
	access concentrator. The looped back NS message causes the network		forwards the message back to the access concentrator. The looped
	interface on the access concentrator to be in a DAD-failed state.		back NS message causes the network interface on the access
	Such a network interface typically serves up to a hundred thousand		concentrator to be in a DAD-failed state. Such a network interface
	broadband modems causing all the modems (and hosts behind the modems)		typically serves up to a hundred thousand broadband modems causing
	to fail to get IPv6 online on the access network. Additionally, it		all the modems (and hosts behind the modems) to fail to get IPv6
	may be tedious for the access concentrator to find out which of the		online on the access network. Additionally, it may be tedious for
	hundred thousand or more homes looped back the DAD message. Clearly		the access concentrator to find out which of the hundred thousand or
	there is a need for automated detection of looped back NS messages		more homes looped back the DAD message. Clearly there is a need for
	during DAD operations by a node.		automated detection of looped back NS messages during DAD operations
			by a node.
	2. Terminology		2. Terminology
	o DAD-failed state - Duplication Address Detection failure as		o DAD-failed state - Duplication Address Detection failure as
	specified in [RFC4862]. Note even Optimistic DAD as specified in		specified in [RFC4862]. Note even Optimistic DAD as specified in
	[RFC4429] can fail due to a looped back DAD probe. This document		[RFC4429] can fail due to a looped back DAD probe. This document
	covers looped back detection for Optimistic DAD as well.		covers looped back detection for Optimistic DAD as well.
	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
	skipping to change at page 5, line 29		skipping to change at page 5, line 29
	configuration on each of such interfaces, and more importantly,		configuration on each of such interfaces, and more importantly,
	genuine duplicates in the link will not be detected.		genuine duplicates in the link 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
	One or more layer-2 protocols MAY include provisions to detect the		One or more layer-2 protocols MAY include provisions to detect the
	existence of a loopback on an interface circuit, usually by comparing		existence of a loopback on an interface circuit, usually by comparing
	protocol data sent and received. For example, PPP uses magic number		protocol data sent and received. For example, the Point-to-Point
	(section 6.4 of [RFC1661]) to detect a loopback on an interface.		Protocol (PPP) uses a magic number (section 6.4 of [RFC1661]) to
			detect a loopback 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. When the protocol detects that a loopback is no longer		interface. 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
	skipping to change at page 6, line 38		skipping to change at page 6, line 38
	as usual.		as usual.
	4. The Enhanced DAD Algorithm		4. The Enhanced DAD Algorithm
	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 section 4.4.)		SEND. (See more details in the Impact on SEND section 4.3.) Since a
	Since a nonce is used only once, The NS(DAD) for each IPv6 address of		nonce is used only once, The NS(DAD) for each IPv6 address of an
	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 to minimize		Six bytes of random nonce is sufficiently large to minimize
	collisions. However, if there is a collision because two nodes that		collisions. However, if there is a collision because two nodes using
	are using the same Target Address in their NS(DAD) and generated the		the same Target Address in their NS(DAD) and generated the same
	same random nonce, then the algorithm will incorrectly detect a		random nonce, then the algorithm will incorrectly detect a looped
	looped back NS(DAD) when a genuine address collision has occurred.		back NS(DAD) when a genuine address collision has occurred. Since
	Since each looped back NS(DAD) event is logged to system management,		each looped back NS(DAD) event is logged to system management, the
	the administrator of the network will have access to the information		administrator of the network will have access to the information
	necessary to intervene manually. Also, because the nodes will have		necessary to intervene manually. Also, because the nodes will have
	detected what appear to be looped back NS(DAD) messages, they will		detected what appear to be looped back NS(DAD) messages, they will
	continue to probe, and it is unlikely that they will choose the same		continue to probe, and it is unlikely that they will choose the same
	nonce the second time (assuming quality random number generators).		nonce the second time (assuming quality random number generators).
	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, for a sender to store a nonce and
	for all ND messages has impact on memory requirements of the node and		nonce related state for all ND messages has impact on memory and
	also adds the algorithm state to a substantially larger number of ND		causes more complexity for the sender node. Therefore, this document
	messages. Therefore, this document does not recommend using the		does not recommend using the algorithm outside of the DAD operation
	algorithm outside of the DAD operation by an interface on a node.		by an interface on a node.
	4.1. General Rules
	If an IPv6 node implements the Enhanced DAD algorithm, the node MUST
	implement detection of looped back NS(DAD) messages during DAD for an
	interface address.
	4.2. Processing Rules for Senders		4.1. 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 an NS(DAD) for a tentative or optimistic interface address		sending an NS(DAD) for a tentative or optimistic interface address
	the sender MUST generate a random nonce associated with the interface		the 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 store the nonce internally, and MUST include the nonce
	Option included in the NS(DAD). If the interface does not receive		in the Nonce Option included in the NS(DAD). If the interface does
	any DAD failure indications within RetransTimer milliseconds (see		not receive any DAD failure indications within RetransTimer
	[RFC4861]) after having sent DupAddrDetectTransmits Neighbor		milliseconds (see [RFC4861]) after having sent DupAddrDetectTransmits
	Solicitations, the interface moves the Target Address to the assigned		Neighbor Solicitations, the interface moves the Target Address to the
	state.		assigned state.
	If any probe is looped back within RetransTimer milliseconds after		If any probe is looped back within RetransTimer milliseconds after
	having sent DupAddrDetectTransmits NS(DAD) messages, the interface		having sent DupAddrDetectTransmits NS(DAD) messages, the interface
	continues with another MAX_MULTICAST_SOLICIT number of NS(DAD)		continues with another MAX_MULTICAST_SOLICIT number of NS(DAD)
	messages transmitted RetransTimer millseconds apart. If no probe is		messages transmitted RetransTimer milliseconds apart. Section 2 of
	looped back within RetransTimer milliseconds after		[RFC3971] defines a single-use nonce, so each Enhanced DAD probe uses
	MAX_MULTICAST_SOLICIT NS(DAD) messages are sent, the probing stops.		a different nonce. If no probe is looped back within RetransTimer
	The probing MAY be stopped via manual intervention. When probing is		milliseconds after MAX_MULTICAST_SOLICIT NS(DAD) messages are sent,
	stopped, the interface moves the Target Address to the assigned		the probing stops. The probing MAY be stopped via manual
	state.		intervention. When probing is stopped, the interface moves the
			Target Address to the assigned state.
	4.3. Processing Rules for Receivers		4.2. 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 included in the		optimistic state), the receiver compares the nonce included in the
	message, with any saved nonce on the receiving interface. If a match		message, with any stored nonce on the receiving interface. If a
	is found, the node SHOULD log a system management message, SHOULD		match is found, the node SHOULD log a system management message,
	update any statistics counter, and MUST drop the received message.		SHOULD update any statistics counter, and MUST drop the received
			message. If the received NS(DAD) message includes a nonce and no
	If the received NS(DAD) message includes a nonce and no match is		match is found with any stored nonce, the node SHOULD log a system
	found with any saved nonce, the node SHOULD log a system management		management message for a DAD-failed state, and SHOULD update any
	message for a DAD-failed state, and SHOULD update any statistics		statistics counter.
	counter. If the interface does not receive any DAD failure
	indications within RetransTimer milliseconds after having sent
	DupAddrDetectTransmits Neighbor Solicitations, the interface moves
	the Target Address to the assigned state.
	4.4. Impact on SEND		4.3. 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. As this document updates		detecting looped back ND messages. As 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		that the nonce in SEND is also used by SEND to detect looped back
	NS(DAD) messages during DAD operations by the node. In a mixed SEND		NS(DAD) messages during DAD operations by the node. In a mixed SEND
	environment with SEND and unsecured nodes, the lengths of the nonce		environment with SEND and unsecured nodes, the lengths of the nonce
	used by SEND and unsecured nodes MUST be identical.		used by SEND and unsecured nodes MUST be identical.
	4.5. Changes to RFC 4862		4.4. Changes to RFC 4862
	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
	a hundred thousand IPv6 clients (broadband modems) connected to the		a hundred thousand 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 the DAD probe is reflected back to the interface, the		address and the DAD probe is reflected back to the interface, the
	interface is stuck in DAD-failed state and IPv6 services to the		interface is stuck in DAD-failed state and IPv6 services to the
	hundred thousand clients is denied. Disabling DAD for such an IPv6		hundred thousand clients is denied. Disabling DAD for such an IPv6
	interface on an access concentrator is less desirable than		interface on an access concentrator is less desirable than
	implementing the algorithm because the network also needs to detect		implementing the algorithm because the network also needs to detect
	skipping to change at page 9, line 9		skipping to change at page 8, line 47
	DAD algorithm also facilitates detecting a genuine duplicate for the		DAD algorithm also facilitates detecting a genuine duplicate for the
	interface on the access concentrator. (See the Actions to Perform on		interface on the access concentrator. (See the Actions to Perform on
	Detecting a Genuine Duplicate section of 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 draft-ietf-6man-enhanced-dad is		The Enhanced DAD algorithm from draft-ietf-6man-enhanced-dad is
	designed to detect looped back DAD probes. A network interface of an		designed to detect looped back DAD probes. A network interface of an
	IPv6 node SHOULD implement the Enhanced DAD algorithm.		IPv6 node SHOULD implement the Enhanced DAD algorithm.
	4.6. Changes to RFC 4861		4.5. 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
	section 4.3 of [RFC4861]:		section 4.3 of [RFC4861]:
	If a node has been configured to use the Enhanced DAD algorithm, an		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		NS with an unspecified source address adds the Nonce option to the
	message and implements the state machine of the Enhanced DAD		message and implements the state machine of the Enhanced DAD
	algorithm.		algorithm.
	4.7. Changes to RFC 3971		4.6. Changes to RFC 3971
	The following text is changed in section 5.3.2 of [RFC3971]:		The following text is changed in section 5.3.2 of [RFC3971]:
	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.
	The new text is included below:		The 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
	skipping to change at page 10, line 5		skipping to change at page 9, line 45
	As described in the paragraphs above, the nonce can also serve to		As described in the paragraphs above, the nonce can also serve to
	detect genuine duplicates even when the network has potential for		detect genuine duplicates even when the network has potential for
	looping back ND messages. When a genuine duplicate is detected, the		looping back ND messages. When a genuine duplicate is detected, the
	node follows the manual intervention specified in section 5.4.5 of		node follows the manual intervention specified in section 5.4.5 of
	[RFC4862]. However, in certain networks such as an access network,		[RFC4862]. However, in certain networks such as an access network,
	if the genuine duplicate matches the tentative or optimistic IPv6		if 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 recommended.		actions are recommended.
	One access network is a cable broadband deployment where the access		One example of a type of access network is cable broadband deployment
	concentrator is the first-hop IPv6 router to several hundred thousand		where the access concentrator is the first-hop IPv6 router to several
	broadband modems. The router also supports proxying of DAD messages.		hundred thousand broadband modems. The router also supports proxying
	The network interface on the access concentrator initiates DAD for an		of DAD messages. The network interface on the access concentrator
	IPv6 address and detects a genuine duplicate due to receiving an		initiates DAD for an IPv6 address and detects a genuine duplicate due
	NS(DAD) or an NA message. On detecting such a duplicate, the access		to receiving an NS(DAD) or an NA message. On detecting such a
	concentrator logs a system management message, drops the received ND		duplicate, the access concentrator logs a system management message,
	message, and blocks the modem on whose layer-2 service identifier the		drops the received ND message, and blocks the modem on whose layer-2
	NS(DAD) or NA message was received on.		service identifier the 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 duplicated by a		trusted router has a tentative or optimistic address duplicated by a
	host. Any other network that follows the same trust model MAY use		host. Any other network that follows the same trust model MAY use
	the automated actions proposed in this section.		the automated actions proposed in this section.
	6. Security Considerations		6. Security Considerations
	The nonce can be exploited by a rogue deliberately changing the nonce		This document does not improve nor reduce the security posture of
	to fail the looped back detection specified by the Enhanced DAD		[RFC4862]. The nonce can be exploited by a rogue deliberately
	algorithm. SEND is recommended to circumvent this exploit.		changing the nonce to fail the looped back detection specified by the
	Additionally, the nonce does not protect against the DoS caused by a		Enhanced DAD algorithm. SEND is recommended to circumvent this
	rogue node replying by a fake NA to all DAD probes. SEND is		exploit. Additionally, the nonce does not protect against the DoS
	recommended to circumvent this exploit also. Disabling DAD has an		caused by a rogue node replying by a fake NA to all DAD probes. SEND
			is recommended to circumvent this exploit also. Disabling DAD has an
	obvious security issue before a remote node on the link can issue		obvious security issue before a remote node on the link can issue
	reflected NS(DAD) messages. Again, SEND is recommended for this		reflected NS(DAD) messages. Again, SEND is recommended for this
	exploit.		exploit. Source Address Validation Improvement (SAVI) [RFC6620] also
			protects against various attacks by on-link rogues.
	7. IANA Considerations		7. IANA Considerations
	None.		None.
	8. Acknowledgements		8. Acknowledgements
	Thanks (in alphabetical order by first name) to Bernie Volz, Dmitry		Thanks (in alphabetical order by first name) to Bernie Volz, Dmitry
	Anipko, Eric Levy-Abegnoli, Eric Vyncke, Erik Nordmark, Fred Templin,		Anipko, Eric Levy-Abegnoli, Eric Vyncke, Erik Nordmark, Fred Templin,
	Jouni Korhonen, Michael Sinatra, Ole Troan, Ray Hunter, Suresh		Jouni Korhonen, Michael Sinatra, Ole Troan, Pascal Thubert, Ray
	Krishnan, and Tassos Chatzithomaoglou for their guidance and review		Hunter, Suresh Krishnan, and Tassos Chatzithomaoglou for their
	of the document. Thanks to Thomas Narten for encouraging this work.		guidance and review of the document. Thanks to Thomas Narten for
	Thanks to Steinar Haug and Scott Beuker for describing the use cases.		encouraging this work. Thanks 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 11, line 21		skipping to change at page 11, line 18
	[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.
			[RFC6620] Nordmark, E., Bagnulo, M., and E. Levy-Abegnoli, "FCFS
			SAVI: First-Come, First-Served Source Address Validation
			Improvement for Locally Assigned IPv6 Addresses", RFC
			6620, May 2012.
	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. 26 change blocks.
	104 lines changed or deleted		104 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/