Juan Carlos,
Dan, Paul,
As Mathieu reported today, when randomizing only 24 bits of the MAC
a collision is basically assured. We can calculate the probability of a
collision out of a pool of c when there are n people by:
p(n; c) = 1 - ((c-1)/c)^(n*(n-1)/2)
If we are only randomizing 24 bits of MAC we end up with numbers
p(5000, 2^24) = 0.525 <-- worse than a coin flip
Even with only 500 people it's basically assured that there will be a
collision after a while. Whereas if we randomize 46 bits of MAC we end
up with numbers like this:
p(500, 2^46) = 0.0000000018
p(1000, 2^46) = 0.0000000071
p(5000, 2^46) = 0.0000001776
p(10000, 2^46) = 0.0000007105
p(30000, 2^46) = 0.00000639
The record for most simultaneous associations in a wi-fi network is
30,0000+ and even in that situation, assuming everyone is randomizing
MAC addresses it's still around 1:156000. Never say never but we can say
Whereas if we only randomize 24 bits we can safely say "definitely assured".
I do not think this study group wants to come up with recommendations on
how to most assuredly screw up a network.
The critical issue is not whether someone temporarily sets his MAC address
to that "owned" by someone somewhere (and I am still not convinced that
purchasers of OUIs get them with the "local" bit set), the critical issue is
whether there will be collisions on the switched network. We do not need to
assure that a randomly chosen MAC address is unique in the world, we just
need to make it as unlikely as possible that that address is already used on the
same switched network. We can't make that assurance with only 24 bits
Please, let's abandon the idea of following 802.1's recommendations for
their small, local LAN randomized MAC scheme. It won't work in wireless
It’s not appropriate to hijack a global OUI and create random MAC addresses and as Dan points out potentially increases the likelihood of collisions.
Using a OUI with local bit is unnecessary and again increases collisions.
[JCZ] I want to clarify that what 802.1 is considering is the use the CID for this purpose, as –already- specified by the IEEE RAC:
http://standards.ieee.org/develop/regauth/cid/ .
Strictly speaking, these are not OUIs (i.e. used to generate globally unique MAC addresses), but for our purpose they could be seen as such, since they consume
24 bits. Also we need to keep in mind that the numbers assume addresses sharing the same CID, which means potentially from the same manufacturer and in reality is less likely.
Right, it's assuming the same CID. But imagine a stadium with 30,000+ users associating to
the same SSID. How many of a single manufacturer do you think there might be? 1000? 5000?
If that manufacturer just came out with a new wiz-bang product I think it might even be higher.
So the possibility of collision does not go away. Using this CID model there would be little islands
of address allocation that are basically assured of collision and that assures that there would
be collision in the whole network of 30,000+ MACs.
In looking at the guidelines off the link you provided above, it doesn't look like there is really
any assumption that a CID from the local address space that is assigned to someone cannot
be used as a local address by someone else. It says, "Local addresses are not globally unique,
but a network administrator is responsible for assuring that any local addresses assigned are
unique within the span of use. (Uniqueness of local addresses typically does not need to extend
beyond a router.)"
I think the key here is that we are proposing to use those 24 bits (well, actually 22 since
the M and X bits are fixed) for address applications, not to identify any one company. Table
1 specifically says that the number of 48 bit addresses possible from a CID are zero. So there
should be no expectation by a company identified by a CID that some device somewhere
would never use a bit-string in the high-order 24 bits of its random MAC address that matched
its CID. Such an assumption would be unreasonable given the purpose of the CID and the fact
that the assignee gets a total of zero addresses out of the assignment. If the assignee of a
CID uses it to generate addresses (of any kind of scope) it is misusing the CID and it should
get an OUI instead.
We're using the bits for addressing not for company identification. The company is using
those bits for company identification not addressing. I see no conflict and therefore no
reason to treat CIDs as if they are OUIs. We have 46 bits, we need to use them all.
Dan.
Having said that, I see and share your concerns about the probability of collisions in a WLAN environment. Hence, any proposal put forward from this group should
be well founded and supported with as many numbers and facts as we can.
Finally – real local addresses can be readily identified for potential special processing in the future. Special could mean shorter DHCP time-outs, etc.
[JCZ] This is a good point, since any numbers we have used so far assumed “permanent” MAC addresses. Now we need to consider simultaneous MAC
addresses, which potentially will change in time and in an asynchronous manner.
Perhaps these are new metrics that we can also derive from the trial/experiment at the IETF network…
Regards,
Juan Carlos