Subject: Re: FW: New Version Notification for, draft-hsingh-6man-enhanced-dad-01.txt

From: Ray Hunter <[email-masked]>
Date: Mon, 17 Oct 2011 18:32:37 +0200

>
> I think 20 bits should be already be more than enough. For simplicity, I would
> just go for 64 bits.
>
> Assuming hosts generate sufficiently strong pseudo-random numbers, 20 bits
> means that once every one million cases of a genuine duplicate address,
> both hosts may mistakenly assume there is a loopback problem.
>
> Given that duplicate addresses should be exceedingly rare already, one
> millionth of that is something that essential doesn't happen.
>
>    
Brian Carpenter and Ole Troan are both correct.

The birthday paradox of a pair of nodes colliding applies here, so you 
should consider approx half the hash length as the practical effective 
length of the hash (Applied Cryptography: Bruce Schneier p166), reducing 
the probability of a collision to around one in 2^10 for a 20 bit nonce, 
or about one in a thousand.

RFC 3971 defines the nonce option (including option length and type) as 
being a multiple of 8 octets including one octet for type field and one 
octet for the length field.

Would therefore humbly suggest a minimum/ default / recommendation of an 
8 octet nonce option (minus the existing 16 pre-assigned bits) meaning 
48 bits available for the nonce field, with the option of using longer 
16 or 24 octet nonce options if an implementer feels there is higher 
likelihood of encountering more than 2^24 nodes on the link (giving 
respectively 16*8-16 = 112 bit nonce & 24*8-16 = 176 bit nonce)

You may think this is far fetched for an upper bound on the number of 
nodes on a single link, but you never know what will happen in the 
future, and standards writers been caught out often enough in the past 
when making statements like "16/24/32/56 bits will be enough."  By 
definition a longer (e.g. 16) octet nonce option is never going to 
collide with a node using a shorter (e.g. 8) octet nonce option in the 
case of DAD, so not everyone has to use the same nonce length IMHO.

Regards,
RayH

---

From: "Hemant Singh (shemant)" <[email-masked]>
Date: Mon, 17 Oct 2011 12:23:07 -0500

-----Original Message-----
From: Ray Hunter [mailto:[email-masked]] 
Sent: Monday, October 17, 2011 12:33 PM
To: Philip Homburg; Hemant Singh (shemant); Ole Troan; Brian E Carpenter
Cc: IPv6 WG Mailing List
Subject: Re: FW: New Version Notification for,
draft-hsingh-6man-enhanced-dad-01.txt 

>respectively 16*8-16 = 112 bit nonce & 24*8-16 = 176 bit nonce)

First humble apologies for suggesting the 62 bits because combined with
16 bits of the Type and Length of the Nonce Option, the option won't
align on an octet boundary.  As for a minimum default with an option to
use 16 or 24 octets in future, sounds fine to myself and Wes. Since the
number of bits for the nonce was an open question for the -01 document,
we will add text in a -02 version reflecting the closure.  So then it
should be OK to specify the default to be 48 bits and let an
implementation use higher length if the implementation wants to.

Also, could folks please see section 4 of the document and see this
recommendation.

[In a mixed SEND environment with SEND and unsecured nodes, the lengths
of the nonce used by SEND and unsecured nodes MUST be identical.]

The text above is suggested in case there are sloppy implementations
that may overrun a buffer parsing the nonce when working in a mixed SEND
environment. 

Thanks,

Hemant

---

From: "Hemant Singh (shemant)" <[email-masked]>
Date: Mon, 17 Oct 2011 13:00:55 -0500

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of
Hemant Singh (shemant)
Sent: Monday, October 17, 2011 1:23 PM
To: Ray Hunter; Philip Homburg; Ole Troan; Brian E Carpenter
Cc: IPv6 WG Mailing List
Subject: RE: FW: New Version Notification
for,draft-hsingh-6man-enhanced-dad-01.txt 

>Since the number of bits for the nonce was an open question for the -01
document, we will add text in a -02 version reflecting the closure.  So
then it

Actually, since we accepted Ray's idea, the idea matches the Nonce
Option in RFC 3971 which also uses a minimum of 48 bits for the nonce
and allows for a longer nonce.  Since our document does not say anything
else beyond RFC 3971, we don't have to add/change any text in this
regard.  This is the text we have in our document below.  I raised the
question today in case there was anyone who wanted one fixed length of
the nonce in the reflected-DAD algorithm.

[The document proposes use of the Nonce Option (specified in [RFC3971]).
The nonce is a random number as specified in [RFC3971].]

In the -02 version, we will incorporate editorial comments from Tassos.

Regards,

Hemant

---

From: Erik Nordmark <[email-masked]>
Date: Mon, 31 Oct 2011 18:36:56 -0700

> case of DAD, so not everyone has to use the same nonce length IMHO.

My understanding is that we only need to worry about the case with two 
hosts which have duplicate IPv6 addresses *and* send DAD probes in the 
same 1 second window, thus the probability might be a lot lower.

I guess if there was a building-wide power failure and everything PC 
powers back on at the same time, then many could send DAD probes in the 
same one second window. But even in that case they wouldn't all do it in 
the same one second interval. And with more and more laptops and other 
battery powered devices, the large-scale coordinated power-on seems an 
unlikely case.

Thus I think 48 bits of nonce is plenty; 2^24 nodes doing DAD probes in 
the same one second interval means you have other problems (such as 
packet loss).

Regards,
    Erik