draft-ietf-6man-enhanced-dad-12.txt   draft-ietf-6man-enhanced-dad-13.txt 
Network Working Group R. Asati Network Working Group R. Asati
Internet-Draft H. Singh Internet-Draft H. Singh
Updates: 4862, 4861, 4429 (if approved) W. Beebee Updates: 4862, 4861, 4429 (if approved) W. Beebee
Intended status: Standards Track C. Pignataro Intended status: Standards Track C. Pignataro
Expires: July 18, 2015 Cisco Systems, Inc. Expires: August 10, 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
January 14, 2015 February 6, 2015
Enhanced Duplicate Address Detection Enhanced Duplicate Address Detection
draft-ietf-6man-enhanced-dad-12 draft-ietf-6man-enhanced-dad-13
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 back Neighbor expressed a need for automated detection of looped back 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 49 skipping to change at page 1, line 49
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 July 18, 2015. This Internet-Draft will expire on August 10, 2015.
Copyright Notice Copyright Notice
Copyright (c) 2015 IETF Trust and the persons identified as the Copyright (c) 2015 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 34 skipping to change at page 2, line 34
1.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3 1.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3
2. Problem Statement . . . . . . . . . . . . . . . . . . . . . . 4 2. Problem Statement . . . . . . . . . . . . . . . . . . . . . . 4
3. Operational Mitigation Options . . . . . . . . . . . . . . . 4 3. Operational Mitigation Options . . . . . . . . . . . . . . . 4
3.1. Disable DAD on an Interface . . . . . . . . . . . . . . . 4 3.1. Disable DAD on an Interface . . . . . . . . . . . . . . . 4
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 . . . . . . . . . . . . . . . 5
4. The Enhanced DAD Algorithm . . . . . . . . . . . . . . . . . 6 4. The Enhanced DAD Algorithm . . . . . . . . . . . . . . . . . 6
4.1. Processing Rules for Senders . . . . . . . . . . . . . . 6 4.1. Processing Rules for Senders . . . . . . . . . . . . . . 6
4.2. Processing Rules for Receivers . . . . . . . . . . . . . 7 4.2. Processing Rules for Receivers . . . . . . . . . . . . . 7
4.3. Changes to RFC 4861 . . . . . . . . . . . . . . . . . . . 7 4.3. Changes to RFC 4861 . . . . . . . . . . . . . . . . . . . 7
5. Actions to Perform on Detecting a Genuine Duplicate . . . . . 7 5. Action to Perform on Detecting a Genuine Duplicate . . . . . 7
6. Security Considerations . . . . . . . . . . . . . . . . . . . 8 6. Security Considerations . . . . . . . . . . . . . . . . . . . 8
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8
8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 8 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 8
9. Normative References . . . . . . . . . . . . . . . . . . . . 8 9. Normative References . . . . . . . . . . . . . . . . . . . . 8
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 9 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 9
1. Introduction 1. Introduction
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
skipping to change at page 6, line 16 skipping to change at page 6, line 16
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 a random number in the Nonce message. The document proposes use of a random number in the Nonce
Option specified in SEND [RFC3971]. Note [RFC3971] does not provide Option specified in SEND [RFC3971]. Note [RFC3971] does not provide
a recommendation for pseudo-random functions. Pseudo-random a recommendation for pseudo-random functions. Pseudo-random
functions are covered in [RFC4086]. Since a nonce is used only once, functions are covered in [RFC4086]. Since a nonce is used only once,
the NS(DAD) for each IPv6 address of an interface uses a different the NS(DAD) for each IPv6 address of an interface uses a different
nonce. Additional details of the algorithm are included in section nonce. Additional details of the algorithm are included in section
4.2. 4.2.
If there is a collision because two nodes using the same Target If there is a collision because two nodes used the same Target
Address in their NS(DAD) and generated the same random nonce, then Address in their NS(DAD) and generated the same random nonce, then
the algorithm will incorrectly detect a looped back NS(DAD) when a the algorithm will incorrectly detect a looped back NS(DAD) when a
genuine address collision has occurred. Since each looped back 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 39 skipping to change at page 7, line 39
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.
5. Actions to Perform on Detecting a Genuine Duplicate 5. Action to Perform on Detecting a Genuine Duplicate
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 cases, if the genuine duplicate [RFC4862]. However, in certain cases, if the genuine duplicate
matches the tentative or optimistic IPv6 address of a network matches the tentative or optimistic IPv6 address of a network
interface of the access concentrator, additional automated actions interface of the access concentrator, additional automated action is
are recommended. recommended.
Some networks follow a trust model where a trusted router serves un- Some networks follow a trust model where a trusted router serves un-
trusted IPv6 host nodes. Operators of such networks have a desire to trusted IPv6 host nodes. Operators of such networks have a desire to
take automated action if a network interface of the trusted router take automated action if a network interface of the trusted router
has a tentative or optimistic address duplicated by a host. One has a tentative or optimistic address duplicated by a host. One
example of a type of access network is cable broadband deployment example of a type of access network is cable broadband deployment
where the access concentrator is the first-hop IPv6 router to where the access concentrator is the first-hop IPv6 router to
multiple broadband modems and supports proxying of DAD messages. The multiple broadband modems and supports proxying of DAD messages. The
network interface on the access concentrator initiates DAD for an 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 SHOULD log a system management message, drop the concentrator SHOULD log a system management message, drop the
received ND message, and block the modem on whose layer-2 service received ND message, and block the modem on whose layer-2 service
identifier the duplicate NS(DAD) or NA message was received on. Any identifier the duplicate NS(DAD) or NA message was received on. Any
other network that follows the same trust model MAY use the automated other network that follows the same trust model MAY use the automated
actions proposed in this section. action proposed in this section.
6. Security Considerations 6. Security Considerations
This document does not improve nor reduce the security posture of This document does not improve nor reduce the security posture of
[RFC4862]. The nonce can be exploited by a rogue deliberately [RFC4862]. The nonce can be exploited by a rogue deliberately
changing the nonce to fail the looped back detection specified by the changing the nonce to fail the looped back detection specified by the
Enhanced DAD algorithm. SEND is recommended to circumvent this Enhanced DAD algorithm. SEND is recommended to circumvent this
exploit. Additionally, the nonce does not protect against the DoS exploit. Additionally, the nonce does not protect against the DoS
caused by a rogue node replying by a fake NA to all DAD probes. SEND 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 is recommended to circumvent this exploit also. Disabling DAD has an
skipping to change at page 8, line 40 skipping to change at page 8, line 40
protects against various attacks by on-link rogues. 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, Brian Thanks (in alphabetical order by first name) to Bernie Volz, Brian
Haberman, Dmitry Anipko, Eric Levy-Abegnoli, Eric Vyncke, Erik Haberman, Dmitry Anipko, Eric Levy-Abegnoli, Eric Vyncke, Erik
Nordmark, Fred Templin, Jouni Korhonen, Michael Sinatra, Ole Troan, Nordmark, Fred Templin, Hilarie Orman, Jouni Korhonen, Michael
Pascal Thubert, Ray Hunter, Suresh Krishnan, and Tassos Sinatra, Ole Troan, Pascal Thubert, Ray Hunter, Suresh Krishnan, and
Chatzithomaoglou for their guidance and review of the document. 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
[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.
[RFC2328] Moy, J., "OSPF Version 2", STD 54, RFC 2328, April 1998. [RFC2328] Moy, J., "OSPF Version 2", STD 54, RFC 2328, April 1998.
 End of changes. 10 change blocks. 
15 lines changed or deleted 15 lines changed or added

This html diff was produced by rfcdiff 1.42. The latest version is available from http://tools.ietf.org/tools/rfcdiff/