--- 1/draft-ietf-6man-enhanced-dad-03.txt 2013-11-04 04:14:29.951270161 -0800 +++ 2/draft-ietf-6man-enhanced-dad-04.txt 2013-11-04 04:14:29.979270853 -0800 @@ -1,25 +1,25 @@ Network Working Group R. Asati Internet-Draft H. Singh Updates: 4862, 4861 (if approved) W. Beebee Intended status: Standards Track Cisco Systems, Inc. -Expires: November 25, 2013 E. Dart +Expires: May 08, 2014 E. Dart Lawrence Berkeley National Laboratory W. George Time Warner Cable C. Pignataro Cisco Systems, Inc. - May 24, 2013 + November 04, 2013 Enhanced Duplicate Address Detection - draft-ietf-6man-enhanced-dad-03 + draft-ietf-6man-enhanced-dad-04 Abstract Appendix A of the IPv6 Duplicate Address Detection (DAD) document in RFC 4862 discusses Loopback Suppression and DAD. However, RFC 4862 does not settle on one specific automated means to detect loopback of Neighbor Discovery (ND of RFC 4861) messages used by DAD. Several service provider communities have expressed a need for automated detection of looped backed ND messages used by DAD. This document includes mitigation techniques and then outlines the Enhanced DAD @@ -37,21 +37,21 @@ Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at http://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." - This Internet-Draft will expire on November 25, 2013. + This Internet-Draft will expire on May 08, 2014. Copyright Notice Copyright (c) 2013 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents @@ -65,30 +65,30 @@ 1. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 2 2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 3. Operational Mitigation Options . . . . . . . . . . . . . . . 4 3.1. Disable DAD on Interface . . . . . . . . . . . . . . . . 4 3.2. Dynamic Disable/Enable of DAD Using Layer 2 Protocol . . 5 3.3. Operational Considerations . . . . . . . . . . . . . . . 5 4. The Enhanced DAD Algorithm . . . . . . . . . . . . . . . . . 6 4.1. General Rules . . . . . . . . . . . . . . . . . . . . . . 7 4.2. Processing Rules for Senders . . . . . . . . . . . . . . 7 - 4.3. Processing Rules for Receivers . . . . . . . . . . . . . 7 + 4.3. Processing Rules for Receivers . . . . . . . . . . . . . 8 4.4. Impact on SEND . . . . . . . . . . . . . . . . . . . . . 8 4.5. Changes to RFC 4862 . . . . . . . . . . . . . . . . . . . 8 - 4.6. Changes to RFC 4861 . . . . . . . . . . . . . . . . . . . 8 + 4.6. Changes to RFC 4861 . . . . . . . . . . . . . . . . . . . 9 5. Actions to Perform on Detecting a Genuine Duplicate . . . . . 9 - 6. Security Considerations . . . . . . . . . . . . . . . . . . . 9 - 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 - 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 9 + 6. Security Considerations . . . . . . . . . . . . . . . . . . . 10 + 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 + 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 10 9. Normative References . . . . . . . . . . . . . . . . . . . . 10 - Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 10 + Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 11 1. Terminology o DAD-failed state - Duplication Address Detection failure as specified in [RFC4862]. Failure also includes if the Target Address is optimistic. Optimistic DAD is specified in [RFC4429]. 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 @@ -257,49 +257,51 @@ is used only once, DAD for each IPv6 address of an interface uses a different nonce. 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), and moves the Target Address to - assigned state. 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 + 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]. The RetransTimer value may be overridden by a link- - type specific document. + 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. - However if there is a collision because two nodes generated the same - random nonce (that are using the same Target Address in their - NS(DAD)), then the algorithm will incorrectly detect a looped back - NS(DAD) when the NS(DAD) was issued to signal a genuine duplicate. - Since each looped back NS(DAD) event is logged to system management, - the administrator of the network will have to intervene manually. + 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, + then the algorithm will incorrectly detect a looped back NS(DAD) when + a genuine address collision has occurred. Since each looped back + NS(DAD) event is logged to system management, the administrator of + the network will have access to the information necessary to + intervene manually. Also, because the nodes will have 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 nonce the + second time (assuming quality random number generators). The algorithm is capable of detecting any ND solicitation (NS and Router Solicitation) or advertisement (NA and Router Advertisement) that is looped back. However, saving a nonce and nonce related data for all ND messages has impact on memory of the node and also adds the algorithm state to a substantially larger number of ND messages. Therefore this document does not recommend using the algorithm outside of the DAD operation by an interface on a node. 4.1. General Rules @@ -307,44 +309,50 @@ 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 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 sender MUST generate a random nonce associated with the interface address, MUST save the nonce, and MUST include the nonce in the Nonce - Option included in the 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. + Option included in the NS(DAD). 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 assigned state. 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. 4.3. Processing Rules for Receivers 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 Target Address matches the interface address (in tentative or optimistic state), the receiver compares the nonce, if any, is included in the message with any saved nonce on the receiving interface. If a match is found, the node SHOULD log a system management message, SHOULD update any statistics counter, MUST drop - the received message, and move the Target Address to assigned state. - - If the received NS(DAD) message includes a nonce and no match is - found with any saved nonce, the node SHOULD log a system management - message for DAD-failed and SHOULD update any statistics counter. + the received message. If the received NS(DAD) message includes a + nonce and no match is found with any saved nonce, the node SHOULD log + a system management message for DAD-failed and SHOULD update any + statistics 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 assigned state. 4.4. Impact on SEND 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 detecting looped back ND messages. If this document updates [RFC4862], SEND should be updated to integrate with the Enhanced DAD 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 messages during DAD operations by the node. In a mixed SEND @@ -433,21 +441,21 @@ Troan, Ray Hunter, Suresh Krishnan, and Tassos Chatzithomaoglou for their guidance and review of the document. Thanks to Thomas Narten for encouraging this work. Thanks to Steinar Haug and Scott Beuker for describing the use cases. 9. Normative References [I-D.ietf-6man-impatient-nud] Nordmark, E. and I. Gashinsky, "Neighbor Unreachability Detection is too impatient", draft-ietf-6man-impatient- - nud-06 (work in progress), April 2013. + 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, RFC 1661, July 1994. [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC3971] Arkko, J., Kempf, J., Zill, B., and P. Nikander, "SEcure