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

["Hemant Singh (shemant)" <[e-mail]>]

Jouni,

Good to hear from you - thanks much for the review.  Humble apologies for the delay - both WesB and I were busy.  We discussed your comments.    Please see in line below between <hs> and </hs>.

-----Original Message-----
From: ipv6 [mailto:[e-mail]] On Behalf Of Jouni Korhonen
Sent: Monday, February 10, 2014 11:05 AM
To: [e-mail]; IPv6 IPv6 List
Subject: comments on draft-ietf-6man-enhanced-dad-04

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.

<hs> The reason is because the top-left of the document says "Update: 4862, 4861".   Would you like the Abstract to also mention the same fact?  WE will also add that this document also updates the SEND RFC.
</hs>

** 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?

<hs> I meant to say, the failure covers both a tentative and an optimistic address where the tentative address is defined in RFC 4862 and the optimistic address is defined in RFC 4429.   Either address type can be the TargetAddress of the DAD probe .  Either address type can also fail DAD due to a looped back DAD and both protocols use the same failure mechanism defined in RFC 4861. 

 New text:

[Duplication Address Detection failure as specified in [RFC4862].    Note even  Optimistic DAD as specified in [RFC4429] can fail due to a looped back DAD probe.   This document covers looped back detection for Optimistic DAD as well. ]

</hs>
      
** 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.

<hs> Perfect suggestion and thanks for the text.  We will take the text.  </hs>

** 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.
<hs> ok. </hs>

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.

<hs> Agreed.  Most of the second paragraph will be deleted and we will reference section 4.2 in the second paragraph.  </hs>

** 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?

<hs> Yes.  New text below:

   The MAX_MULTICAST_SOLICIT number of NS(DAD) messages sequence continues until the stop condition is
   Reached or manual intervention is undertaken.

</hs>


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

<hs>OK - will do.  Note one reviewer (in private email)  wanted the address to move to assigned state whether a looped back DAD was received within the RetransTimer milliseconds interval or not.  But I replied, what good is an assigned address until I the interface detects the loopback has stopped because unless the loopback stops, the assigned address can be used to only to send traffic that is looped right back.   
</hs>

** 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?

<hs>Will take your suggestion and propose text in our next revision.  </hs>

** 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.

<hs>Ok, will do. </hs>

** 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.

<hs>Ok, will do. </hs>

** 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.

<hs>Agreed.  Will take your suggestion.  </hs>

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

<hs> will do </hs>

Thanks much,

Hemant