With the increasing use of virtual machines in my environment, I am needing more and more unique mac addresses to assign to the many virtual Ethernet devices I have attached and visible to my non-virtual physical network. The problem of course is that I don't have an IEEE OUI and therefore can't generate guaranteed to be unique addresses, and while the possible address space is quite large, it occurs to me that there should be something - ala rfc 1918 - for this kind of situation. For now however, I just want to know if anyones got something better than 'pick an oui out of the air' or 'pick an old dead manufacturer oui', or worse, 'pick old 10base2 network cards and destroy them, saving the mac'. In the future however, I think there's going to need to be some sort of extension or modification to dhcp to accomodate virtual machines in this regard (of not having a manufacturer assigned addresses for the virtual ethernets).
RFC 2153 describes a method of usings a "pseudo OUI" for certain
purposes when there is no appropriate regular OUI assigned. These are
listed here.
CF0001 Data Comm for Business [McCain]
I remember we had IBM Token-Ring equipment and they suggested
to always use "CF..." and never rely on the programmed MAC for SNA.
On an ethernet network, CF is a multicast destination address, or, as a
source, I'm pretty sure it indicates that the frame contains a source
route for use with translational bridging.
The locally assigned 0x02 bit would be better to use. Be aware that
Microsoft have decided to "reserve" some locally assigned addresses
in the range 02-BF, and 02-01 through 02-20 for use with their load
balancing / high availability product, rather than use one of their
proper OUIs. Apparently you're not supposed to be using these
address ranges because the locally assigned address space is so large,
before you use this Microsoft product, so if you are, too bad. You'll
have to change your previous local assignments, or somehow change
Microsoft's software. Within Wireshark it shows it as used by
Microsoft, which implies official assignment to Microsoft. The
Wireshark people won't change it, so that gives it a level of
legitimacy. I think that's a slippery slope.
(It's a pet hate of mine that certain organisations force their private
address space assignments (RFC1918 or IEEE locally assigned) on
outsiders. It's supposed to be private so outsiders don't see it or
don't have to work around it!)
Realistically, OUI space is pretty large for each L2 domain... Once it hits an L3 domain, you can repeat OUIs all you want... Pick some prefix set of bits that include "locally assigned" that is unique to your organization and you will operationally be fine. Or the last 8 bits of your host server's base MAC (hardware) address -- plenty of entropy there.
Even when two or 10 organizations merge, unless you are merging them into the same tributary L3 domain, its not a problem...
And if it is a problem for more than 1 or 2 virtual machines, I'm sure your organization is big enough to split that into another domain/vlan/what have you.
Yes, its a nice idea to have a BCP that works without conflicts, but
I don't see how this is legitimately going to affect anyone more than theoretically... unless someone's device is really bad at generating OUIs; all of this based on the cheap prevalence of L3 devices at the edge.
OUI...yes, great topic! Now mind me asking but why would you need a "private" OUI if the well-known (registed) list is quite public and everyone has a reserved allocation? (vendors have)
and yes as far as i am aware all can be spoofed...up to the available anti-spoofing rules, plenty of google literature........just to check the theory points of failure .....
Now the question is do mac adresses change w/ IPv6? Is there a relation w/ IPv4/6 format type and OUI format type ?