comments on draft-ietf-6man-enhanced-dad-04

[Jouni Korhonen <[e-mail]>]

Authors,

I have a read on this document. I find it good and informative. Few 
comments and questions inline.

** Abstract

o There is no mention that this document updates RFC4861 and RFC4862.


** Section 1

      specified in [RFC4862].  Failure also includes if the Target
      Address is optimistic.  Optimistic DAD is specified in [RFC4429].

o I do not understand the sentence "Failure also includes if the Target
  Address is optimistic." Some word missing there?


** Section 3.2

   This solution requires no protocol changes.  This solution SHOULD be
   enabled by default, and MUST be a configurable option.

o I would clarify here, just to be clear on the context, that the above
  MUST applies only if the layer 2 has an ability to detect looped back
  messages. Proposed text:

   This solution requires no protocol changes.  This solution SHOULD be
   enabled by default, and MUST be a configurable option if the layer 2
   technology provides means for detecting loopback messages on an
   interface circuit.

** Section 4

   SEND.  See more details in the Impact on SEND section.  Since a nonce
                                  ^^^^^^^^^^^^^^^^^^^^^^^

o I would point explicitly to the section number as well.
o The algorithm description in the second paragraph is somewhat hard to
  follow. I had to read it quite many times.. On the other hand, the
  algorithm description in Section 4.2 is far more readable. Consider
  having the algorithm description only in one place.

** Section 4.2

   The MAX_MULTICAST_SOLICIT number of
   NS(DAD) messages sequence continues until the stop condition is
   reached.

o Or manual administrative actions are taken, right?

o The stop condition and ending the probing means the interface moves
  the Target Address to assigned state, right? I would say that 
  explicitly.

** Section 4.4

   detecting looped back ND messages.  If this document updates
   [RFC4862], SEND should be updated to integrate with the Enhanced DAD
   algorithm.  A minor update to SEND would be to explicitly mention

o "If this document updates.." well it does. Propose changing the text to
  something like "Since this document.."
o Why there is no proposal for those "minor" SEND updates?

** Section 4.5

   The following text is added to [RFC4862].

o Added where in RFC4862? Propose an explicit place.
o The added text should probably have a reference to this document.

** Section 4.6

o Changes where exactly in RFC4861? Propose an explicit place.
o The added text should probably have a reference to this document.

** Section 6

   algorithm.  SEND is recommended for this exploit.  For any mitigation

o I would say SEND is not recommend for this exploit rather SEND is recommended
  to circumvent this exploit.

** Section 9

o Obsolete normative reference to RFC1247 (obsoleted by RFC1583)
o No reference to RFC2119 (also there is no typical RFC2119 boilerplate text)
o draft-ietf-6man-impatient-nud -> RFC7048


- Jouni