From: "Hemant Singh (shemant)" <shemant@cisco.com>
To: Jouni Korhonen <jouni.nospam@gmail.com>,
 "draft-ietf-6man-enhanced-dad@tools.ietf.org"
 <draft-ietf-6man-enhanced-dad@tools.ietf.org>, IPv6 IPv6 List <ipv6@ietf.org>
Subject: RE: comments on draft-ietf-6man-enhanced-dad-04
Thread-Topic: comments on draft-ietf-6man-enhanced-dad-04
Thread-Index: AQHPJnnvIN69lWyYR0GTaz9EzyMcQ5q7yQGA
Date: Wed, 19 Feb 2014 01:11:43 +0000
Message-ID: <75B6FA9F576969419E42BECB86CB1B89115F5DD1@xmb-rcd-x06.cisco.com>
References: <78AE6729-1A26-48EA-BD31-FBBDE85C829E@gmail.com>
In-Reply-To: <78AE6729-1A26-48EA-BD31-FBBDE85C829E@gmail.com>
Accept-Language: en-US
Content-Language: en-US
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Archived-At: http://mailarchive.ietf.org/arch/msg/ipv6/Q4zduJwdhqukJc_xOXZHp5Lhi5w
Precedence: list

Jouni,

Good to hear from you - thanks much for the review.  Humble apologies for t=
he delay - both WesB and I were busy.  We discussed your comments.    Pleas=
e see in line below between <hs> and </hs>.

-----Original Message-----
From: ipv6 [mailto:ipv6-bounces@ietf.org] On Behalf Of Jouni Korhonen
Sent: Monday, February 10, 2014 11:05 AM
To: draft-ietf-6man-enhanced-dad@tools.ietf.org; 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 comment=
s 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 wi=
ll 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 optimist=
ic address is defined in RFC 4429.   Either address type can be the TargetA=
ddress of the DAD probe .  Either address type can also fail DAD due to a l=
ooped back DAD and both protocols use the same failure mechanism defined in=
 RFC 4861.=20

 New text:

[Duplication Address Detection failure as specified in [RFC4862].    Note e=
ven  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>
     =20
** 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 refe=
rence 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 th=
e RetransTimer milliseconds interval or not.  But I replied, what good is a=
n assigned address until I the interface detects the loopback has stopped b=
ecause unless the loopback stops, the assigned address can be used to only =
to send traffic that is looped right back.  =20
</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 recomme=
nded
  to circumvent this exploit.

<hs>Agreed.  Will take your suggestion.  </hs>

** Section 9

o Obsolete normative reference to RFC1247 (obsoleted by RFC1583) o No refer=
ence to RFC2119 (also there is no typical RFC2119 boilerplate text) o draft=
-ietf-6man-impatient-nud -> RFC7048

<hs> will do </hs>

Thanks much,

Hemant