Network Working Group H. Singh Internet-Draft W. Beebee Updates: 4862 (if approved) Cisco Systems, Inc. Intended status: Standards Track October 11, 2011 Expires: April 13, 2012 Enhanced Duplicate Address Detection draft-hsingh-6man-enhanced-dad-00.txt Abstract Appendix A of [RFC4862] discusses Loopback Suppression and Duplicate Address Detection (DAD). However, [RFC4862] does not settle on one specific automated means to detect Loopback of Neighbor Discovery (ND) [RFC4861] 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 outlines an algorithm to automate detection of looped back IPv6 ND messages. Further, for certain access networks the document automates resolving a specific duplicate address conflict. Status of this Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. 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 April 13, 2012. Copyright Notice Copyright (c) 2011 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 Singh & Beebee Expires April 13, 2012 [Page 1]
Internet-Draft Enhanced DAD October 2011 carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Table of Contents 1. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 3. Algorithm to Detect Looped Back ND message . . . . . . . . . . 4 3.1. General Rules . . . . . . . . . . . . . . . . . . . . . . . 4 3.2. Processing Rules for Senders . . . . . . . . . . . . . . . 4 3.3. Processing Rules for Receivers . . . . . . . . . . . . . . 5 4. Impact on SEND . . . . . . . . . . . . . . . . . . . . . . . . 5 5. Integration with Optimistic DAD . . . . . . . . . . . . . . . . 5 6. Changes to RFC 4862 . . . . . . . . . . . . . . . . . . . . . . 5 7. Actions to Perform on Detecting a Genuine Duplicate . . . . . . 6 8. Security Considerations . . . . . . . . . . . . . . . . . . . . 6 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 6 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 6 11. Normative References . . . . . . . . . . . . . . . . . . . . . 7 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 7 Singh & Beebee Expires April 13, 2012 [Page 2]
Internet-Draft Enhanced DAD October 2011 1. Terminology o DAD-failed state - Duplication Address Detection failure as specified in [RFC4862]. 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. 2. Introduction Appendix A of [RFC4862] discusses Loopback Suppression and Duplicate Address Detection (DAD). However, [RFC4862] does not settle on one specific automated means to detect Loopback of ND messages used by DAD. One specific DAD message is a Neighbor Solicitation (NS), 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 Advertisement (NA). The algorithm proposed in this document focuses on detecting any of NS or NA looped back to the transmitting interface during the DAD operation. The algorithm is also applicable to detecting any looped back ND message. Recently service providers have reported a DAD loopback problem. IPv6 Loopback testing is underway on a router. A network interface of the router is enabled for IPv6. The interfaces issues an NS for the IPv6 link-local address DAD. The NS is reflected back to the interface due to the Loopback test and the interface is stuck in a DAD-failed state requiring manual intervention. In another service provider network, two broadband modems in a home have the Ethernet ports of each modem connected to a network hub. The access concentrator serving the modems is the first-hop IPv6 router for the modems. The access concentator also supports proxying of DAD messages. Each modem is IPv4 online. The network interface of the access concentrator serving the two broadband modems is enabled for IPv6 and the interface issues a NS message to perform DAD for the IPv6 link-local address. The NS message reaches one modem first and this modem sends the message to the hub which sends the message to the 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. Such a network interface typically serves over six thousand broadband modems causing all the modems (and hosts behind the modems) 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 six thousand or more homes looped back the DAD message. Clearly there is a need for automated detection of looped back ND messages, especially Singh & Beebee Expires April 13, 2012 [Page 3]
Internet-Draft Enhanced DAD October 2011 during the DAD operation on the node. 3. Algorithm to Detect Looped Back ND message The document proposes use of the Nonce Option (specified in [RFC3971]). The nonce is a random number as specified in [RFC3971]. If SEND is enabled on the router and the router also supports the new automated ND Loopback detection (specified in this document), there is integration with the algorithm of this document and SEND. See more details in the Impact on SEND section. When the IPv6 network interface issues a NS message to perform DAD, the interface includes the Nonce Option in the NS message and saves the nonce in local store. Subsequently if the interface receives an identical NS message, the interface logs a system management message, updates any statistics counter, and drops the looped back NS. If the DupAddrDetectTransmits variable for the interface is greater than one, subsequent NS messages for the same Target Address should be suppressed. If the interface receives a NS message with a different nonce, the interface logs a DAD-failed system management message, updates any statistics, and behaves identical to the behavior specified in [RFC4862] for DAD failure. Also, see the section titled Integration with Optimistic DAD. The algorithm is also applicable to a node that supports DNA as specified in [RFC6059]. The algorithm also applies to detect any ND solicitation (NS and Router Solicitation) or advertisement (NA and Router Advertisement) that is looped back. Saving a nonce and nonce related data for all ND messages has impact on memory of the node. Thus this algorithm recommends at least detecting looped back ND messages during DAD. Detecting any other looped back ND messages when the node is not involved in DAD is optional. 3.1. General Rules A node MUST implement detection of looped back NS and NA messages during DAD. The node MAY support detection of other ND messages looped back at all other times. 3.2. Processing Rules for Senders If a node has been configured to use the algorithm of this document, all ND messages MUST include the Nonce Option in the ND message. When sending the message, the node MUST store the nonce internally so that the node can match any looped back ND message. If the DupAddrDetectTransmits variable for the interface is greater than one, subsequent NS message for the same Target Address SHOULD be Singh & Beebee Expires April 13, 2012 [Page 4]
Internet-Draft Enhanced DAD October 2011 suppressed. 3.3. Processing Rules for Receivers The node has been configured to use the algorithm of this document. If the node receives any ND message with a nonce that matches an existing nonce saved on the node, the node logs a system management message, updates any statistics counter, and MUST drop the received message. If the received ND message includes a nonce and no match is found with a saved nonce on the node, the node logs a system management message for DAD-failed and updates any statistics counter. 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 algorithm of this document. A minor update to SEND would be to explicitly mention that the nonce in SEND is also used by SEND to detect looped back ND messages. In a mixed SEND environment with SEND and unsecured nodes, SEND nodes MUST accept an unsecured NA in response to a NS issed for DAD where the NA includes a new nonce. Such a case signals a DAD failure to the receiver of the NA. In a mixed environment, the lengths of the nonce used by SEND and unsecured nodes MUST be identical. 5. Integration with Optimistic DAD The algorithm of this document also supports Optimistic DAD as specified in [RFC4429]. On receiving an NA with a nonce that does not match any nonce on the ON, the ON (see [RFC4429]) immediately stops using the address and deconfigures the address. 6. Changes to RFC 4862 The following text is added to [RFC4862] at a yet to be determined location in [RFC4862]. A router that supports IPv6 ND MUST implement the detection of looped back ND messages as specified in this document. A network interface on any other IPv6 node that is not a router SHOULD implement the detection of looped back ND messages as specified in this document. Singh & Beebee Expires April 13, 2012 [Page 5]
Internet-Draft Enhanced DAD October 2011 7. Actions to Perform on Detecting a Genuine Duplicate The nonce can also serve to detect genuine duplicates even when the network has potential for looping back ND messages. When a genuine duplicate is detected, the node follows the manual intervention specified in section 5.4.5 of [RFC4862]. However, in certain networks such as an access network if the genuine duplicate matches the IPv6 tentative address of a network interface of the access concentrator, automated actions are proposed. One access network is a cable broadband deployment where the access concetrator is the first-hop IPv6 router. The router also supports proxying of DAD messages. If the network interface on the access concentrator initiates DAD for an IPv6 address and an NS or an NA message with a new nonce is received, a genuine duplicate has been detected. On detecting such a duplicate the access concentrator, logs a system management DAD-failed message and blocks the modem on whose layer 2 service identifier (id) the NS or NA message was received on. The network described above follows a trust model where a trusted router serves untrusted IPv6 host nodes. Operators of such networks have a desire to take automated action if a network interface of the trusted router has a tentative address duplicate with a host the trusted router interface serves. Note that the access concentator broadband deployment has over three hundred million subscribers worldwide. Any other network that follows the same trust model MAY use the automated actions proposed in this section. 8. Security Considerations The nonce can be exploited by a rogue deliberately changing the nonce to fail the looped back detection algorithm. SEND is recommended for this exploit. 9. IANA Considerations None. 10. Acknowledgements Thanks to Eric Levy-Abegnoli for his guidance and review of an earlier version of the document. Singh & Beebee Expires April 13, 2012 [Page 6]
Internet-Draft Enhanced DAD October 2011 11. Normative References [RFC3971] Arkko, J., Kempf, J., Zill, B., and P. Nikander, "SEcure Neighbor Discovery (SEND)", RFC 3971, March 2005. [RFC4429] Moore, N., "Optimistic Duplicate Address Detection (DAD) for IPv6", RFC 4429, April 2006. [RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman, "Neighbor Discovery for IP version 6 (IPv6)", RFC 4861, September 2007. [RFC4862] Thomson, S., Narten, T., and T. Jinmei, "IPv6 Stateless Address Autoconfiguration", RFC 4862, September 2007. [RFC5942] Singh, H., Beebee, W., and E. Nordmark, "IPv6 Subnet Model: The Relationship between Links and Subnet Prefixes", RFC 5942, July 2010. [RFC6059] Krishnan, S. and G. Daley, "Simple Procedures for Detecting Network Attachment in IPv6", RFC 6059, November 2010. Authors' Addresses Hemant Singh Cisco Systems, Inc. 1414 Massachusetts Ave. Boxborough, MA 01719 USA Phone: +1 978 936 1622 Email: shemant@cisco.com URI: http://www.cisco.com/ Wes Beebee Cisco Systems, Inc. 1414 Massachusetts Ave. Boxborough, MA 01719 USA Phone: +1 978 936 2030 Email: shemant@cisco.com URI: http://www.cisco.com/ Singh & Beebee Expires April 13, 2012 [Page 7]