Yesterday, i tried to estimate what is the probability of generating a random interface identifier that looks like a EUI-64 IID without using the 'u' bit at all calculating the worst of the cases.
Let's take the worst of the cases, that all the EUI-64 based IPv6 current devices are in the same room. - Today there are 5692 company_id assigned by IEEE - Let's imagine that all of them are Ethernet devices - Let's imagine that the 5692*(2^24) IPv6 devices are in the same place running stalessadress autoconfiguration The probability of generating a random IID that "looks like a EUI-64" is P=1-[2^48-(5692*2^24)/2^48]=0.00034 I beleive that EUI-64 based, Random, Manual, DHCPv6 ... should not carry a bit "claiming" how they were generated to provide a "claim" of uniqueness. Is the porpouse of DaD to detect only the duplicate random interface identifiers then? There is a quantitative and qualitative difference in reserving one bit for RR or CryptoIID to enhance mobile security and even handover performance or to reserve one bit (u) to "CLAIM" uniqueness. PD. I funny plot of the distribution of the IEEE OUI is available at: http://www.it.kth.se/~aep/ieee-oui.ps /aep > So, let's just end this pretence that u==1 has any special meaning, and > revert to the earlier situation, where we no natural EUI-64 is going to > have (the inverted) u==0, so we define things like randomly generated > addresses to always set u==0, so that there's no chance that someone's > randomly generated address is going to be occupying your EUI-64 address > space on your link (the chance is tiny anyway, this removes it completely, > and makes it reasonable for a system using autoconf of EUI-64 based addresses > to simply give up and cry if its DAD fails, rather than requiring a recovery > mechanism). > > Finally - if there were to be any kind of reasonable way to test an ID for > uniqueness, then we'd be using EIDs now. Getting unique EIDs was the major > problem that inhibited us from choosing a protocol that used them (8+8 > being one of the contenders - the nearest to IPv6). And that was a problem > when the EID would have been completely under our control, and so could > have had any properties we desired, unlike EUI-64's, that we're just stuck > with. > > kre > -- -------------------------------------------------------------------------- That you are not paranoid, it doesn't mean that they are not watching you! http://www.it.kth.se/~aep -------------------------------------------------------------------- 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] --------------------------------------------------------------------
