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
--------------------------------------------------------------------
IETF IPv6 working group mailing list
[email protected]
Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------

Reply via email to