On 10/17/11 9:32 AM, Ray Hunter wrote:
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.
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
--------------------------------------------------------------------
IETF IPv6 working group mailing list
[email protected]
Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------
