Subject: Re: [Int-dir] Internet Directorate review of draft-ietf-6man-enhanced-dad-06

From: "Hemant Singh (shemant)" <[email-masked]>
Date: Tue, 4 Nov 2014 12:24:50 +0000

Pascal,

Thanks much for the review.  I have made changes to the draft as per your comments.   Some comments need more discussion.  Please see in line below.

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: October 28, 2014 at 2:17:32 PM EDT
To: Ole Troan <[email-masked]>, "[email-masked]" <[email-masked]>
Cc: 6man Chairs <[email-masked]>
Subject: Re: [Int-dir] Internet Directorate review of draft-ietf-6man-enhanced-dad-06
Hi Ole:

>Please find my review below:
>
>
>", the interface moves the Target Address to the assigned
 > state." 
>-> Please add: and discards the nonce.

<hs> The SEND document in RFC 3971 does not use any text such as "discards the nonce" when the SEND RFC also matches the nonce between sent and received control messages.  The SEND RFC, on page 5, also defines the nonce.  The definition says the nonce is used only once.  Thus, I think, it is clear the nonce is discarded when used once. 

>" If any probe is looped back within RetransTimer milliseconds after
>  having sent DupAddrDetectTransmits NS(DAD) messages, the interface
>  continues with another MAX_MULTICAST_SOLICIT number of NS(DAD)
>  messages transmitted RetransTimer millseconds apart.

>I would have expected that the nonce is recomputed for these retries as indicated earlier in 
>"
>                                                             Also, because the nodes will have
>  detected what appear to be looped back NS(DAD) messages, they will
>  continue to probe, and it is unlikely that they will choose the same
>  nonce the second time (assuming quality random number generators).
>"

<hs> Please see the definition of the Nonce on page 5 of RFC 3971 (SEND).  The nonce is used only once.  Thus any subsequent DAD probe uses a new nonce. 

>In 4.3
>"
>If the interface does not receive any DAD failure
>  indications within RetransTimer milliseconds after having sent
>  DupAddrDetectTransmits Neighbor Solicitations, the interface moves
>  the Target Address to the assigned state.
>" -> this text belongs to 4.2, and is already there

<hs>  I will discuss with other authors and see if we can remove the text since it belongs to section 4.2.

>In 4.4:
>I expect that both the CGA and the public key have better properties for uniqueness validation than the nonce, so the send node should probably use that first.

<hs> Note the SEND protocol uses a nonce  to catch solicited ND responses.  When a node supports both the SEND protocol and the Enhanced DAD algorithm the nonce used should be the same.  That is context of section 4.4 of our document.  Use of CGA is an orthogonal issue.   In any case, what if a node does not support SEND but supports the Enhanced DAD algorithm?  Then CGA cannot be used.

>4.5
>- I do not see that the introduction of 4862 is the best place for an RFC 2119 keyword.
>
>"
>For example, if the interface on an IPv6 node is
>  connected to a circuit that supports loopback testing, then the node
>  SHOULD implement the Enhanced DAD algorithm that allows the IPv6
>  interface to self-heal after loopback testing is ended on the
>  circuit.  Another example is when the IPv6 interface resides on an
>  access concentrator running DAD Proxy.  The interface supports up to
>  a hundred thousand IPv6 clients (broadband modems) connected to the
>  interface.  
> "-> please remove the normative text above that is redundant with the first normative sentence below.

<hs> I removed all normative text in the paragraph above.

Thanks,

Hemant