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

[Jouni Korhonen <[e-mail]>]

Hi Hemant,

Sorry for a slow reply.. been reading other lists lately ;-) Comments inline.

On Feb 19, 2014, at 3:11 AM, Hemant Singh (shemant) <[e-mail]> wrote:

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

It is just the IDnits complains if the abstract does not state
that "updates RFC xyz etc". That's why I prefer those being there.

Listing update to SeND RFC is good as well!

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

Looks good to me now.


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

Ack.

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

Thanks.

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

Good. Thanks.


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

Ack.


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

Ok. Thanks.


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

Ok. Thanks.


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

Ack.

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

Ack.

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

Ack.

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

Ack.


> 
> Thanks much,

You are welcome!

- Jouni


> 
> Hemant
>