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

From: Jouni Korhonen <[email-masked]>
Date: Mon, 10 Feb 2014 18:05:21 +0200

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

---

From: "Hemant Singh (shemant)" <[email-masked]>
Date: Wed, 19 Feb 2014 01:11:43 +0000

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:[email-masked]] On Behalf Of Jouni Korhonen
Sent: Monday, February 10, 2014 11:05 AM
To: [email-masked]; 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

<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

<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

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

** Section 4

<hs> ok. </hs>

<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

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

<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

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

** Section 4.5

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

** Section 4.6

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

** Section 6

<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

---

From: Jouni Korhonen <[email-masked]>
Date: Mon, 24 Feb 2014 12:04:55 +0200

Hi Hemant,

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

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

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!

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

Looks good to me now.

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

Ack.

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

Thanks.

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

Good. Thanks.

>   Reached or manual intervention is undertaken.

Ack.

> <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.  B…

Ok. Thanks.

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

Ok. Thanks.

> o The added text should probably have a reference to this document.

Ack.

> o The added text should probably have a reference to this document.

Ack.

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

Ack.

> 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

Ack.

> Thanks much,

You are welcome!

- Jouni