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
--------------------------------------------------------------------