In your letter dated Mon, 17 Oct 2011 09:14:21 -0500 you wrote: >-----Original Message----- >From: Brian E Carpenter [mailto:[email protected]] >Sent: Saturday, October 15, 2011 3:18 PM >To: Hemant Singh (shemant) >Cc: Tassos Chatzithomaoglou; IPv6 WG Mailing List >Subject: Re: FW: New Version Notification for draft-hsingh-6man-enhanced-dad-0 >1.txt > >>However, I agree that 20 bits is small for a nonce. > >Note SEND in RFC 3971 has left the length of the Nonce Option to be 6 bytes or > higher. I personally would like any reflected-DAD algorithm to settle on one > fixed length for the nonce. Thus a question to the mailer. Which of 48 or 6 >2 bits do folks prefer as length of the nonce for the reflected-DAD algorithm? > I hope folks do not want to go any higher than 62 bits. Note the Nonce Opti >on has specified that the option end on an 8-byte boundary and since the optio >n is in TLV format, 16 bits are already taken by the Type and Length fields of > the option.
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. There is however one thing to worry about: small devices without persistent state. If those devices end up with the same MAC address, then there is good chance that they will generate the same random number as well. -------------------------------------------------------------------- IETF IPv6 working group mailing list [email protected] Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 --------------------------------------------------------------------
