Subject: RE: 6MAN WGLC: draft-ietf-6man-enhanced-dad

From: "Hemant Singh (shemant)" <[email-masked]>
Date: Thu, 19 Jun 2014 19:38:52 +0000

Eric,

Appreciate the review.  I and Wes Beebee discussed the comments and I am replying.  Please see in line below between "<hs>... </hs>".

-----Original Message-----
From: ipv6 [mailto:[email-masked]] On Behalf Of Eric Vyncke (evyncke)
Sent: Thursday, June 19, 2014 10:27 AM
To: Ole Troan; 6man WG
Cc: <[email-masked]>
Subject: Re: 6MAN WGLC: draft-ietf-6man-enhanced-dad

>So let's go for it...
>
>Minor comment, why is Carlos not in the same block of Cisco authors?

<hs> No specific reason.  I can make the change. </hs>

>I would prefer to have section 1 (terminology) after section 2 (introduction).

<hs>Agreed.  Will make the change. </hs>

>Section 1:
>- first bullet s/Note even Optimistic/Note: even Optimistic/

<hs>Ok, will make the change. </hs>

>- loopback does not always loop between the same physical interface...
>Think about a layer-3 switch with two different layer-2 interface for the same layer-3 interface, looping the layer-2 interfaces will also introduce a loop

<hs>Will add "layer-3" to the third bullet in the Terminology section where the first instance of "interface" exists. <hs>

> - NS(DAD) should we add the destination at layer-2 and layer-3 being a mcast?

<hs> We can stick to the RFC 4861 definition for the NS and then nothing else needs to be articulated.   I will change the text of the last bullet from 

o  NS(DAD) - shorthand notation to denote an Neighbor Solicitation
      (NS) with unspecified IPv6 source-address issued during DAD.

To

o  NS(DAD) - shorthand notation to denote an Neighbor Solicitation
      (NS) (as specified in RFC 4861) with unspecified IPv6 source-address issued during DAD.

</hs>

>Section 2 should be a real introduction, i.e., more the 'problem description' in a new section ;-)
>- "The interface issues a NS for the IPv6 link-local address DAD" why restricting to LLA only? GUA/ULA have the same problem

<hs> Will remove the link-local address.  I was articulating the original problem verbatim in that the link-local address failed DAD and it is the link-local that gets created first during an interface coming up. </hs>

>- the last paragraph would benefit if rewritten, not really easy to understand and ASCII art would help, also state that the cable-modem are in bridge mode

<hs> I will add ascii art and also rewrite.  A diagram was presented for this use case at the Taipei IETF in the slides presented.  Please see slide 5 titled "Cable Broadband Problem" in the slides at the URL below. 

http://www.ietf.org/proceedings/82/slides/6man-2.pdf

</hs>

>- s/one layer 3 interface/one layer-3 interface/

<hs> Will make the change. </hs>

- s/100 thousand/hundred thousands/

<hs> Will make the change. </hs>

>Section 3.1
>- this I-D would benefit of a better punctuation, such as s/simplest the mitigation/simplest; the mitigation/

<hs>Will replace the ";" with a comma.  New text is below. 
[While this mitigation may be the simplest,  it has three drawbacks.]
</hs>

>- not sure whether a core router 'SHOULD' support disabling DAD...
>Consequences could be catastrophic for a core router

<hs>The WG could not agree to a MUST because an interface on any IPv6 node would end up supporting the new Enhanced DAD algorithm.  However, some legacy nodes may never be upgraded to the new algorithm and thus the use of SHOULD </hs>

>Section 3.2:
>- s/layer 2 protocols/layer-2 protocols/ (to be applied multiple times)

<hs>Will do. </hs>

>- add using the source MAC address as differentiator example?

<hs>What happens if the network has a genuine duplicate mac-address?  If the network is a PPP network then there is no chance of a genuine duplicate. </hs>

>Section 4:
>- should we add 'mitigation 'to the section title to be similar to section 3?
>- s/sufficiently large for nonce collisions/sufficiently large for avoiding nonce collisions/

<hs> No.  Section 4 is the solution and that is why this section does not need any mitigation keyword in section title. </hs>

>Section 4.2:
>- split the paragraph in two pieces: one for the sheer sending and one for repeating the sending of the probes

<hs> Will do. </hs>

>- not sure why enhanced DAD should be optional... Why not making it mandatory?

<hs>Please see above. </hs>

>Section 4.3:
>- s/compares the nonce, if any, is included in the message/compares the nonce included in the message, if any,/

<hs>Will make the change. </hs>

>- not sure why the last sentence is there as it is relevant to section 4.2

<hs>In each section in 4.2 and 4.3 other reviewers wanted  an explicit mention of moving the Target Address to assigned state. </hs>

>Section 6:
>- should we add that the nonce does not protect against the DoS caused by a rogue node replying by fake NA to all DAD probes?

<hs>Sure.  Then I will add text saying "SEND is recommended to circumvent this exploit.".   Section 9.2.3 of the SEND RFC covers this attack. </hs>

>Hope this helps

<hs>Helps greatly - thanks much! </hs>

Hemant

-éric

On 3/06/14 17:09, "Ole Troan" <[email-masked]> wrote:

>All,
>
>This message starts a two week 6MAN Working Group Last Call on 
>draft-ietf-6man-enhanced-dad
>
>	Title           : Enhanced Duplicate Address Detection
>	Author(s)   : R. Asati, H. Singh, W. Beebee, E. Dart, W. George, C.
>Pignataro
>	Filename   : draft-ietf-6man-enhanced-dad-05
>	Pages        : 11
>	Date           : 2014-05-02
>    http://tools.ietf.org/html/draft-ietf-6man-enhanced-dad
>
>as a Proposed Standards document. Substantive comments and statements 
>of support for advancing this document should be directed to the 
>mailing list. Editorial suggestions can be sent to the authors.  This 
>last call will end on June 17, 2014.
>
>We need volunteers to do a detailed review of the document. We would 
>also encourage volunteers to act as document shepherds. Please contact 
>the chairs directly.
>
>Regards,
>
>Bob Hinden & Ole Trøan

--------------------------------------------------------------------
IETF IPv6 working group mailing list
[email-masked]
Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------