draft-ietf-6man-enhanced-dad-04.txt   draft-ietf-6man-enhanced-dad-05.txt 
Network Working Group R. Asati Network Working Group R. Asati
Internet-Draft H. Singh Internet-Draft H. Singh
Updates: 4862, 4861 (if approved) W. Beebee Updates: 4862, 4861, 3971 (if approved) W. Beebee
Intended status: Standards Track Cisco Systems, Inc. Intended status: Standards Track Cisco Systems, Inc.
Expires: May 08, 2014 E. Dart Expires: November 3, 2014 E. Dart
Lawrence Berkeley National Laboratory Lawrence Berkeley National Laboratory
W. George W. George
Time Warner Cable Time Warner Cable
C. Pignataro C. Pignataro
Cisco Systems, Inc. Cisco Systems, Inc.
November 04, 2013 May 2, 2014
Enhanced Duplicate Address Detection Enhanced Duplicate Address Detection
draft-ietf-6man-enhanced-dad-04 draft-ietf-6man-enhanced-dad-05
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 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 May 08, 2014. This Internet-Draft will expire on November 3, 2014.
Copyright Notice Copyright Notice
Copyright (c) 2013 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. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 2
1.1. Requirements Language . . . . . . . . . . . . . . . . . . 3
2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
3. Operational Mitigation Options . . . . . . . . . . . . . . . 4 3. Operational Mitigation Options . . . . . . . . . . . . . . . 4
3.1. Disable DAD on Interface . . . . . . . . . . . . . . . . 4 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 . . . . . . . . . . . . . . . 5 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 . . . . . . . . . . . . . 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
4.6. Changes to RFC 4861 . . . . . . . . . . . . . . . . . . . 9 4.6. Changes to RFC 4861 . . . . . . . . . . . . . . . . . . . 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. 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]. Note even Optimistic DAD as specified in
Address is optimistic. Optimistic DAD is specified in [RFC4429]. [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. 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
message back. message back.
o Loopback - A function in which the router's interface (or the o Loopback - A function in which the router's interface (or the
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 [RFC1583]. 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 Neighbor Solicitation o NS(DAD) - shorthand notation to denote an Neighbor Solicitation
(NS) with unspecified IPv6 source-address issued during DAD. (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 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
skipping to change at page 5, line 23 skipping to change at page 5, line 35
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. enabled by default, and MUST be a configurable option if the layer 2
technology provides means for detecting loopback messages on an
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
skipping to change at page 6, line 19 skipping to change at page 6, line 36
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. Since a nonce SEND. See more details in the Impact on SEND section in section 4.4.
is used only once, DAD for each IPv6 address of an interface uses a Since a nonce is used only once, DAD for each IPv6 address of an
different nonce. interface uses a different nonce. Additional details of the
algorithm are included in section 4.2.
The interface follows [RFC4862] behavior by issuing
DupAddrDetectTransmits (see [RFC4862]) probes spaced RetransTimer
(see [RFC4861]) apart. When the IPv6 network interface issues a
NS(DAD) message, the interface includes the Nonce Option in the
NS(DAD) message and saves the nonce in local store. Subsequently if
the interface receives an identical NS(DAD) message, the interface
logs a system management message, updates any statistics counter,
drops the looped back NS(DAD). If any probe is looped back within
RetransTimer milliseconds after having sent DupAddrDetectTransmits
NS(DAD) messages, the interface continues with another
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. The
RetransTimer may be overidden by a link-specific document if a node
supports the Enhanced DAD algorithm. Note
[I-D.ietf-6man-impatient-nud] has intentions to change probe behavior
of [RFC4861].
If the interface receives a NS(DAD) message with a different nonce
but the Target Address matches a tentative or optimistic address on
the interface, the interface logs a DAD-failed system management
message, updates any statistics, and behaves identical to the
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 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
skipping to change at page 7, line 45 skipping to change at page 7, line 37
having sent DupAddrDetectTransmits Neighbor Solicitations, the having sent DupAddrDetectTransmits Neighbor Solicitations, the
interface moves the Target Address to assigned state. If any probe interface moves the Target Address to assigned state. If any probe
is looped back within RetransTimer milliseconds after having sent is looped back within RetransTimer milliseconds after having sent
DupAddrDetectTransmits NS(DAD) messages, the interface continues with DupAddrDetectTransmits NS(DAD) messages, the interface continues with
another MAX_MULTICAST_SOLICIT number of NS(DAD) messages spaced another MAX_MULTICAST_SOLICIT number of NS(DAD) messages spaced
RetransTimer apart. If no probe is looped back within RetransTimer RetransTimer apart. If no probe is looped back within RetransTimer
milliseconds after MAX_MULTICAST_SOLICIT NS(DAD) messages are sent, milliseconds after MAX_MULTICAST_SOLICIT NS(DAD) messages are sent,
the probing stops else a new MAX_MULTICAST_SOLICIT number of NS(DAD) the probing stops else a new MAX_MULTICAST_SOLICIT number of NS(DAD)
messages sequence is initiated. The MAX_MULTICAST_SOLICIT number of messages sequence is initiated. The MAX_MULTICAST_SOLICIT number of
NS(DAD) messages sequence continues until the stop condition is NS(DAD) messages sequence continues until the stop condition is
reached. reached or manual intervention is undertaken. 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, 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, MUST drop management message, SHOULD update any statistics counter, MUST drop
skipping to change at page 8, line 36 skipping to change at page 8, line 22
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
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.5. Changes to RFC 4862
The following text is added to [RFC4862]. The following text is added to the end of the Introduction section of
[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 100 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 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.
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
back DAD probes. A network interface of an IPv6 node SHOULD
implement the Enhanced DAD algorithm.
4.6. Changes to RFC 4861 4.6. Changes to RFC 4861
1. The RetransTimer may be overridden by a link-specific document if The following text is appended to the RetransTimer variable
a node supports the Enhanced DAD algorithm. description in section 6.3.2 of [RFC4861].
2. If a node has been configured to use the Enhanced DAD algorithm, The RetransTimer may be overridden by a link-specific document if a
an NS with an unspecified source address adds the Nonce option to node supports the Enhanced DAD algorithm.
the message and implements the state machine of the Enhanced DAD
algorithm. The following text is appended to the Source Address definition in
section 4.3 of [RFC4861].
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.
4.7. Changes to RFC 3971
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
is a fresh response to a solicitation sent earlier by the node.
New text is included below.
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
nonce is also used to detect looped back NS messages when the network
interface performs DAD [RFC4862]. Detecting looped back DAD messages
is covered by the Enhanced DAD algorithm as specified in TBD RFC. In
a mixed SEND environment with SEND and 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 10, line 9 skipping to change at page 10, line 22
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 for this exploit. For any mitigation algorithm. SEND is recommended to circumvent this exploit. For any
suggested in the document such as disabling DAD has an obvious mitigation suggested in the document such as disabling DAD has an
security issue before a remote node on the link can issue reflected obvious security issue before a remote node on the link can issue
NS(DAD) messages. Again, SEND is recommended for this exploit. 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, Michael Sinatra, Ole Levy-Abegnoli, Erik Nordmark, Fred Templin, Jouni Korhonen, Michael
Troan, Ray Hunter, Suresh Krishnan, and Tassos Chatzithomaoglou for Sinatra, Ole Troan, Ray Hunter, Suresh Krishnan, and Tassos
their guidance and review of the document. Thanks to Thomas Narten Chatzithomaoglou for their guidance and review of the document.
for encouraging this work. Thanks to Steinar Haug and Scott Beuker Thanks to Thomas Narten for encouraging this work. Thanks to Steinar
for describing the use cases. Haug and Scott Beuker for describing the use cases.
9. Normative References 9. Normative References
[I-D.ietf-6man-impatient-nud] [RFC1583] Moy, J., "OSPF Version 2", RFC 1583, March 1994.
Nordmark, E. and I. Gashinsky, "Neighbor Unreachability
Detection is too impatient", draft-ietf-6man-impatient-
nud-07 (work in progress), October 2013.
[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
Neighbor Discovery (SEND)", RFC 3971, March 2005. Neighbor Discovery (SEND)", RFC 3971, March 2005.
 End of changes. 24 change blocks. 
66 lines changed or deleted 78 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/