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

From: Ole Troan <[email-masked]>
Date: Thu, 9 Oct 2014 09:02:09 +0200

This document has just passed last call in 6MAN. While it is a short document and a simple mechanism, Bob and I have some concerns about readability and if it isn't open to misunderstandings.

Before advancing the document to the IESG, can we request a couple of people from the directorate to review and provide comments?

http://tools.ietf.org/html/draft-ietf-6man-enhanced-dad-06

Best regards,
Ole

---

From: 神明達哉 <[email-masked]>
Date: Thu, 9 Oct 2014 15:14:15 -0700

At Thu, 9 Oct 2014 09:02:09 +0200,
> http://tools.ietf.org/html/draft-ietf-6man-enhanced-dad-06

I responded to the 6man WGLS on this document with a not-so-useful
comment: http://www.ietf.org/mail-archive/web/ipv6/current/msg20847.html

And, if the point of the additional review is about readability, I
guess first-time readers may be in a better position to take on the
review.  If you still think another round of review of mine is useful,
I'm willing to do that, so please let me know.

--
JINMEI, Tatuya

---

From: "Bernie Volz (volz)" <[email-masked]>
Date: Sun, 12 Oct 2014 02:49:11 +0000

Hi Ole:

In general, I agree with Jinmei's comment that it seems useful and I didn't have much difficulty in reading it. As I haven't implemented DAD, but have done ARP implementations, I think I could implement this 'enhanced DAD'.

There are a few nits with the document:
- There are several mentions of "hundred thousand" (and sometimes "hundred thousands" and sometimes just hundreds or thousands), I'm not sure that this is really that significant and just saying "lots" might be sufficient (I don't see how the problem changes just because there are so many - yes, the probability of a conflict may go up and the impact if not handled properly is also much more significant). Anyway, if left the way it is, I am sure the RFC editor will fix the "hundred thousands". Again, this is minor but it just seems better to remove these numeric quantities.
- In section 4, 2nd paragraph, the sentence "Six bytes of random nonce is sufficiently large for collisions" needs to be fixed. I think they meant "is sufficiently large to minimize collisions"? It is a bit ironic that 48-bits would be chosen when this is also the size of the mac-address, but mac-addresses don't really use all 48-bits. (Though the next logical size given the limitations of the ND option sizes would be 6+8 = 14 bytes, which is unnecessarily large.)
-  In section 6, isn't this missing that there is no DoS protection against a rogue node, on receiving a NS(DAD) to generate one which would appear to be a looped backed packet (i.e., result in retransmitted probe and not allowing the target address to move to assigned state - see section 4.2)?
- There are places where "the" in missing. This will be handled by RFC editor.

(If an 07 were to be published, there appear to be several native English co-authors, and perhaps one of them can go through the document.)

Thus in the end the document is understandable and seems useful and implementable.

- Bernie

-----Original Message-----
From: Int-dir [mailto:[email-masked]] On Behalf Of ????
Sent: Thursday, October 09, 2014 6:14 PM
To: Ole Troan
Cc: 6man Chairs; <[email-masked]>
Subject: Re: [Int-dir] Internet Directorate review of draft-ietf-6man-enhanced-dad-06

And, if the point of the additional review is about readability, I guess first-time readers may be in a better position to take on the review.  If you still think another round of review of mine is useful, I'm willing to do that, so please let me know.

--
JINMEI, Tatuya

_______________________________________________
Int-dir mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/int-dir

---

From: "Carlos Pignataro (cpignata)" <[email-masked]>
Date: Sun, 12 Oct 2014 11:27:03 +0000

Bernie,

Thank you very much for a thorough and useful review! (As a co-author,) I agree with all of these, and fixing them would improve the doc.

Please find just one small followup inline. 

Ole,

Please note that the (other) authors have not seen this review. These editorials can be batched along with other IETF LC comments, or as part a revision -07. 

Thumb typed by Carlos Pignataro.
Excuze typofraphicak errows

> On Oct 11, 2014, at 10:49 PM, Bernie Volz (volz) <[email-masked]> wrote:
> 
> Hi Ole:
> 

Since we are discussing some nits, I hope you don't mind me commenting with a nit, for completeness: I have known very many native English speakers who had terrible writing skills in general, and worst grammar in particular. I've also met many non-native English speakers with enviable proficiency and accuracy in the arts of writing. Being (or not) native English speaker (or native English writer) does not determine ability to play copy editor. Just one of my pet peeves. 

Thanks again for a great review!

Carlos.

---

From: Ole Troan <[email-masked]>
Date: Mon, 13 Oct 2014 14:19:50 +0200

Carlos,

> Please note that the (other) authors have not seen this review. These editorials can be batched along with other IETF LC comments, or as part a revision -07. 

I'd like to see a new revision now, updated with the comments from the Internet Directorate.

Best regards,
Ole

---

From: "Carlos Pignataro (cpignata)" <[email-masked]>
Date: Mon, 13 Oct 2014 12:27:53 +0000

> I'd like to see a new revision now, updated with the comments from the Internet Directorate.

Sounds good -- thanks!

Carlos.

---

From: "Carlos Pignataro (cpignata)" <[email-masked]>
Date: Fri, 24 Oct 2014 00:44:25 +0000

On Oct 13, 2014, at 8:19 AM, Ole Troan <[email-masked]<mailto:[email-masked]>> wrote:

Carlos,

Ole,

New version posted — thanks Bernie for the review!

Name: draft-ietf-6man-enhanced-dad
Revision: 07
Title: Enhanced Duplicate Address Detection
Document date: 2014-10-23
Group: 6man
Pages: 12
URL:            http://www.ietf.org/internet-drafts/draft-ietf-6man-enhanced-dad-07.txt
Status:         https://datatracker.ietf.org/doc/draft-ietf-6man-enhanced-dad/
Htmlized:       http://tools.ietf.org/html/draft-ietf-6man-enhanced-dad-07
Diff:           http://www.ietf.org/rfcdiff?url2=draft-ietf-6man-enhanced-dad-07

Best,

Carlos.

Best regards,
Ole

On Oct 11, 2014, at 10:49 PM, Bernie Volz (volz) <[email-masked]<mailto:[email-masked]>> wrote:

Hi Ole:

Carlos.

- Bernie

-----Original Message-----
From: Int-dir [mailto:[email-masked]] On Behalf Of ????
Sent: Thursday, October 09, 2014 6:14 PM
To: Ole Troan
Cc: 6man Chairs; <[email-masked]<mailto:[email-masked]>>
Subject: Re: [Int-dir] Internet Directorate review of draft-ietf-6man-enhanced-dad-06

At Thu, 9 Oct 2014 09:02:09 +0200,
Ole Troan <[email-masked]<mailto:[email-masked]>> wrote:

--
JINMEI, Tatuya

_______________________________________________
Int-dir mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/int-dir

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Tue, 28 Oct 2014 18:17:32 +0000

Hi Ole:

Please find my review below:

"Two broadband modems" -> this sentence introduces the case after some discussion. I'd have read better something like
"In this scenario, two broadband modems ..."

"PPP uses magic number" -> " the Point-to-Point Protocol (PPP) uses a magic number"

" 
   The mitigation options may not be effective for the bidirectional
   loopback (i.e. the loopback is placed in both directions of the
   circuit interface, so as to identify the faulty segment) if only one
   device followed a mitigation option specified in this document, since
   the other device would follow current behavior and disable IPv6 on
   that interface due to DAD until manual intervention restores it.
"
I think I understand; still I suggest to split and reword a bit this sentence

" because two nodes that are" -> " because two nodes "

" However, saving a nonce and nonce related data
   for all ND messages has impact on memory requirements of the node and
   also adds the algorithm state to a substantially larger number of ND
   messages.  "
 -> needs rephrasing. Also, saving is not appropriate.

"   If an IPv6 node implements the Enhanced DAD algorithm, the node MUST
   implement detection of looped back NS(DAD) messages during DAD for an
   interface address. "
-> This rules seems to imply that if the code supports this RFC then it always has the nonce option. 
Shouldn't that be a deployment choice, where this is the default but can be turned off?
The next sentence indicates a configuration which makes more sense to me:
" If a node has been configured to use the Enhanced DAD algorithm"

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

" 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.
" 
millseconds->milliseconds
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).
"

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

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.

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.
 " A network interface of an IPv6 node SHOULD implement the Enhanced DAD
   algorithm.
"

 " One access network is a cable broadband"
  -> unsure what you mean? Is it "an access" or "one case of access" or else?

6. security
I'd say 1) that this spec does not improve or reduce the security posture of RFC 4862 and 2) that SEND and SAVI are ways to protect against various attacks by onlink rogues.

I hope this helps...

Cheers,

Pascal

> From: Int-dir [mailto:[email-masked]] On Behalf Of Ole Troan
> Sent: jeudi 9 octobre 2014 09:02
> To: [email-masked]
> Cc: 6man Chairs
> Subject: [Int-dir] Internet Directorate review of draft-ietf-6man-enhanced-
> dad-06
> 
> This document has just passed last call in 6MAN. While it is a short
> document and a simple mechanism, Bob and I have some concerns about
> readability and if it isn't open to misunderstandings.
> 
> Before advancing the document to the IESG, can we request a couple of
> people from the directorate to review and provide comments?
>