--- 1/draft-ietf-6man-enhanced-dad-11.txt	2015-01-14 16:14:34.282210595 -0800
+++ 2/draft-ietf-6man-enhanced-dad-12.txt	2015-01-14 16:14:34.306211178 -0800
@@ -4,38 +4,38 @@
 Updates: 4862, 4861, 4429 (if approved)                        W. Beebee
 Intended status: Standards Track                            C. Pignataro
 Expires: July 18, 2015                               Cisco Systems, Inc.
                                                                  E. Dart
                                    Lawrence Berkeley National Laboratory
                                                                W. George
                                                        Time Warner Cable
                                                         January 14, 2015
 
                   Enhanced Duplicate Address Detection
-                    draft-ietf-6man-enhanced-dad-11
+                    draft-ietf-6man-enhanced-dad-12
 
 Abstract
 
    IPv6 Loopback Suppression and Duplicate Address Detection (DAD) are
    discussed in Appendix A of RFC4862.  That specification mentions a
    hardware-assisted mechanism to detect looped back DAD messages.  If
    hardware cannot suppress looped back DAD messages, a software
    solution is required.  Several service provider communities have
    expressed a need for automated detection of looped back Neighbor
    Discovery (ND) messages used by DAD.  This document includes
    mitigation techniques and outlines the Enhanced DAD algorithm to
    automate the detection of looped back IPv6 ND messages used by DAD.
    For network loopback tests, the Enhanced DAD algorithm allows IPv6 to
    self-heal after a loopback is placed and removed.  Further, for
    certain access networks the document automates resolving a specific
    duplicate address conflict.  This document updates RFC4861, RFC4862,
-   and RFC3971.
+   and RFC4429.
 
 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/.
@@ -94,21 +94,21 @@
    network interface of an IPv6 node for DAD.  Another message involved
    in DAD is the Neighbor Advertisement (NA).  The Enhanced DAD
    algorithm specified in this document focuses on detecting an NS
    looped back to the transmitting interface during the DAD operation.
 
    Detecting a looped back NA does not solve the looped back DAD
    problem.  Detection of any other looped back ND messages during the
    DAD operation is outside the scope of this document.  This document
    also includes a section on Mitigation that discusses means already
    available to mitigate the DAD loopback problem.  This document
-   updates RFC4861, RFC4862, and RFC3971.
+   updates RFC4861, RFC4862, and RFC4429.
 
 1.1.  Requirements Language
 
    The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
    "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
    document are to be interpreted as described in [RFC2119].
 
 1.2.  Terminology
 
    o  DAD-failed state - Duplication Address Detection failure as
@@ -358,27 +358,27 @@
    reflected NS(DAD) messages.  Again, SEND is recommended for this
    exploit.  Source Address Validation Improvement (SAVI) [RFC6620] also
    protects against various attacks by on-link rogues.
 
 7.  IANA Considerations
 
    None.
 
 8.  Acknowledgements
 
-   Thanks (in alphabetical order by first name) to Bernie Volz, Dmitry
-   Anipko, Eric Levy-Abegnoli, Eric Vyncke, Erik Nordmark, Fred Templin,
-   Jouni Korhonen, Michael Sinatra, Ole Troan, Pascal Thubert, 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.
+   Thanks (in alphabetical order by first name) to Bernie Volz, Brian
+   Haberman, Dmitry Anipko, Eric Levy-Abegnoli, Eric Vyncke, Erik
+   Nordmark, Fred Templin, Jouni Korhonen, Michael Sinatra, Ole Troan,
+   Pascal Thubert, 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
 
    [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.
 
    [RFC2328]  Moy, J., "OSPF Version 2", STD 54, RFC 2328, April 1998.