Comment 18 for bug 153727

Scott James Remnant is correct: "The kernel need not pick a *RANDOM* MAC address, it could use one that's at least predictable"

This is an old problem that has bee solved. The Network Working Group documented the issue in 1998 and provided the correct solution: reverse the bit order of the LAN adapter to restore it to canonical form. See RFC 2469, http://tools.ietf.org/html/rfc2469.

If the kernel reads an apparently invalid MAC address, it should first try reversing the bit-order. If the reversed-bit-order is a canonically valid address, use the so-reversed MAC, per RFC 2469.

There is the remote possibility that reversing the bit order would not yield a canonically correct address. Consequently, if both the reported address and the reverse-bit-order address are *both* invalid, replace the Organizationally Unique Identifier of original MAC with a predetermined, specified OUI or Individual Address Block (IAB). (See http://standards.ieee.org/regauth/faqs.html). Ideally, the IEEE would assign a specific OUI or IAB for use by the Internet community in such cases. (It's not all that expensive and requests are processed within 7 days.) Such an approach would reuse the device-specific numbering already assigned by the vendor to the interface, and would likely result in fewer duplicates on the same LAN (although it would still be statistically possible).

Here's a summary of the logic I propose:

read address reported by hardware
is address valid?
     If yes, set MAC equal to address as reported.
     If no, set MAC (1) = reverse bit order of address reported
             is MAC (1) valid?
             if Yes, set MAC = MAC (1)
             if No, replace OUI of MAC with specific, predetermined OUI, and set MAC to the new value.
exit

Happy Trails,

Loye Young
Isaac & Young Computer Company
Laredo, Texas
http://www.iycc.net