draft-ietf-6man-enhanced-dad-11.txt   draft-ietf-6man-enhanced-dad-12.txt 
skipping to change at page 1, line 15 skipping to change at page 1, line 15
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: July 18, 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 January 14, 2015
Enhanced Duplicate Address Detection Enhanced Duplicate Address Detection
draft-ietf-6man-enhanced-dad-11 draft-ietf-6man-enhanced-dad-12
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
mitigation techniques and outlines the Enhanced DAD algorithm to mitigation techniques and outlines the Enhanced DAD algorithm to
automate the detection of looped back IPv6 ND messages used by DAD. automate the detection of looped back IPv6 ND messages used by DAD.
For network loopback tests, the Enhanced DAD algorithm allows IPv6 to For network loopback tests, the Enhanced DAD algorithm allows IPv6 to
self-heal after a loopback is placed and removed. Further, for self-heal after a loopback is placed and removed. Further, for
certain access networks the document automates resolving a specific certain access networks the document automates resolving a specific
duplicate address conflict. This document updates RFC4861, RFC4862, duplicate address conflict. This document updates RFC4861, RFC4862,
and RFC3971. and RFC4429.
Status of This Memo Status of This Memo
This Internet-Draft is submitted in full conformance with the This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
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/.
skipping to change at page 3, line 10 skipping to change at page 3, line 10
network interface of an IPv6 node for DAD. Another message involved network interface of an IPv6 node for DAD. Another message involved
in DAD is the Neighbor Advertisement (NA). The Enhanced DAD in DAD is the Neighbor Advertisement (NA). The Enhanced DAD
algorithm specified in this document focuses on detecting an NS algorithm specified in this document focuses on detecting an NS
looped back to the transmitting interface during the DAD operation. looped back to the transmitting interface during the DAD operation.
Detecting a looped back NA does not solve the looped back DAD Detecting a looped back NA does not solve the looped back DAD
problem. Detection of any other looped back ND messages during the problem. Detection of any other looped back ND messages during the
DAD operation is outside the scope of this document. This document DAD operation is outside the scope of this document. This document
also includes a section on Mitigation that discusses means already also includes a section on Mitigation that discusses means already
available to mitigate the DAD loopback problem. This document available to mitigate the DAD loopback problem. This document
updates RFC4861, RFC4862, and RFC3971. updates RFC4861, RFC4862, and RFC4429.
1.1. Requirements Language 1.1. Requirements Language
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [RFC2119]. document are to be interpreted as described in [RFC2119].
1.2. Terminology 1.2. Terminology
o DAD-failed state - Duplication Address Detection failure as o DAD-failed state - Duplication Address Detection failure as
skipping to change at page 8, line 38 skipping to change at page 8, line 38
reflected NS(DAD) messages. Again, SEND is recommended for this reflected NS(DAD) messages. Again, SEND is recommended for this
exploit. Source Address Validation Improvement (SAVI) [RFC6620] also exploit. Source Address Validation Improvement (SAVI) [RFC6620] also
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, Dmitry Thanks (in alphabetical order by first name) to Bernie Volz, Brian
Anipko, Eric Levy-Abegnoli, Eric Vyncke, Erik Nordmark, Fred Templin, Haberman, Dmitry Anipko, Eric Levy-Abegnoli, Eric Vyncke, Erik
Jouni Korhonen, Michael Sinatra, Ole Troan, Pascal Thubert, Ray Nordmark, Fred Templin, Jouni Korhonen, Michael Sinatra, Ole Troan,
Hunter, Suresh Krishnan, and Tassos Chatzithomaoglou for their Pascal Thubert, Ray Hunter, Suresh Krishnan, and Tassos
guidance and review of the document. Thanks to Thomas Narten for Chatzithomaoglou for their guidance and review of the document.
encouraging this work. Thanks to Steinar Haug and Scott Beuker for Thanks to Thomas Narten for encouraging this work. Thanks to Steinar
describing the use cases. 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. 4 change blocks. 
10 lines changed or deleted 10 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/