Hello all, It seems to me we have two distinct problems that are “solved” through the use of local MAC addresses: 1.
Exhaustion of number space caused by large numbers of IoT devices
2.
Privacy issues by publically associating a static address with a device
Yes … both are closely related by the concept that the MAC address is used as a permanent ‘identity’ for a device. This is the concept we must change.
The first (and I’ve not looked at 802c, so I’m speaking in ignorance) appears to be resolved by defining a protocol to allocate
MAC addresses to organizations based on the CID from the local address space. Doing so doubles the number of addresses available, and may go further is the local addresses can be re-used.
I’ve looked, it’s a short sighted attempt to extend static assigned addressing. WE already have 46 bits for local address that are being used in some protocols. There would be some collisions of registered and random MAC addresses. Not sure this hurts, but if random and assigned overlap … we might as well use 47 bits (local and assigned) for local MAC addresses.
A major issue with overlap is not isolating the static from time-varying addresses. Routning tables, DHCP, etc would benefit from having a clear distinction between static and changing addresses.
The second might be resolved by allocating addresses randomly from 46 bits, and perhaps having some protocol to detect and correct
collisions.
Yes, collisions are very rare, but could be readily handled by changing the address on detection of errors. Changing addresses often also could mitigate the collisions, but has other coordination issues. Both cannot be solved simultaneously with the solutions discussed.
I disagree. Exhaustion of number space is not a problem if the numbers are not required to be uniquely assigned. A solution would be to always consider a MAC address to be local and not indicative of the device identity. This is a radical change. MAC addresses are used as long term interface identifiers, used to create IPv6 addresses and used in certificates in 802.1AR. MAC addresses often appear on a device label to facilitate identification and communication to the device.
Using local MAC addresses only implies that there is some other long term identity for a device. I’d suggest a UUID, or UUID-like string. A longer ‘identity’ can be readily created without worry of number space exhaustion. Local MAC addresses could be cryptographically bound to the UUID for authentication.
So I’m wondering if there exists a mechanism that will solve both simultaneously such as: 1.
Dividing connectivity into zones or regions where the knowledge of the existence of a particular MAC address cannot penetrate,
such as segments linked by routers. Within such a zone allow only problem 1 or 2 to be solved. 2.
Subdividing the local MAC address space further so that issue 1 gets 45 bits to play with and likewise issue 2.
Interesting … but then there is only one registry, not a per company allocation.
Paul
Best Regards, Adrian P STEPHENS Tel: +44 (1793) 404825 (office)
Tel: +44 (7920) 084 900 (mobile, UK) Tel: +1 (408) 2397485 (mobile, USA) ----------------------------------------------
Intel Corporation (UK) Limited
Registered No. 1134945 (England)
Registered Office: Pipers Way, Swindon SN3 1RJ
VAT No: 860 2173 47 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
|