In your previous mail you wrote:
Hi, there's currently a stream of proposals that put random bits on
the Interface ID of an IPv6 address. A background assumption is that
the length of the Interface ID is 64 bits.
=> this is a strong assumption and all past threads about it concluded
this assumption should *not* be done.
Another assumption is that
since those ID's are generated from random sources, then their
uniqueness is guaranteed for practical purposes.
=> if this argument is used in order to avoid (or to perform after) DAD
we have to define "practical". I agree with the probability argument
(i.e. modulo implementation errors, collisions should be almost impossible)
but I'd not like to get this in a life support system.
May I point out the following:
-mathematical uniqueness is not guaranteed, there's already an
acknowledged collision probability.
=> this is why DAD should be always performed. According to my
"please don't play Russion roulette with my network" argument,
the control over to perform or not DAD should be in the hands of
the network manager (not in the hands of the node manager because
an address collision usually does *two* victims).
-to this probability one should add "administrative probability" where
same prefixes are accidentally assigned to two entities.
=> this is like link-layer address collision (for instance two Ethernet
boards with the same MAC address in ROMs), the damage is done
independently/before DAD, i.e. or we consider it can't happen,
or we consider it is the business of someone else...
-add implementation error probabilities, where a widespread
implementation uses a weak algorithm to generate that random numbers,
for example use as input time of day or the birth date, or short
passphrases, etc.
=> this is a real concern (even there is a RFC about randomness).
-add the p in prf.
=> ???
The last three factors are very hard to quantify, and as such the
overall probability of collision events also seems to me very hard to
quantify.
Just a thought, born out of contemplating randomness. What do you
think?
=> if it is not too late (I'm afraid it is), replace DAD by Duplicate
Interface ID Detection. And, of course, perform DAD each time DAD can
be useful (I know only one good exception: PPP, because PPP manages
itself IIDs and guarantees against collisions).
Regards
[EMAIL PROTECTED]
PS: I don't believe in RFC 3041: it doesn't provide privacy when
the first 64 bits can be used to trace you. But it does provide
near 2^63 different IIDs to the bad guy for source address spoofing!
If you don't want to be traced by your IID, use ::1, ::2, ... as your
IID and, of course, perform DAD. RFC 3041 is at the same level as
the associated privacy concern...
--------------------------------------------------------------------
IETF IPng Working Group Mailing List
IPng Home Page: http://playground.sun.com/ipng
FTP archive: ftp://playground.sun.com/pub/ipng
Direct all administrative requests to [EMAIL PROTECTED]
--------------------------------------------------------------------
