| 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/ | ||||