BCP for Private OUI / address assignments?
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). Mike-
On Nov 24, 2008, at 11:02 AM, mike wrote:
I am needing more and more unique mac addresses ... it occurs to me that there should be something - ala rfc 1918
You can probably find examples online, but in a nutshell this does exist. Set bit b2 to 1, "locally assigned". Default is 0, "globally unique" (OUI assigned). Cheers, Dale -- Dale W. Carder - Network Engineer University of Wisconsin / WiscNet http://net.doit.wisc.edu/~dwcarder
I also found this one helpful http://www.iana.org/assignments/ethernet-numbers === The CFxxxx Series 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. Kind regards Peter Dale W. Carder wrote:
On Nov 24, 2008, at 11:02 AM, mike wrote:
I am needing more and more unique mac addresses ... it occurs to me that there should be something - ala rfc 1918
You can probably find examples online, but in a nutshell this does exist.
Set bit b2 to 1, "locally assigned". Default is 0, "globally unique" (OUI assigned).
Cheers, Dale
-- Dale W. Carder - Network Engineer University of Wisconsin / WiscNet http://net.doit.wisc.edu/~dwcarder
-- Peter and Karin Dambier Cesidian Root - Radice Cesidiana Rimbacher Strasse 16 D-69509 Moerlenbach-Bonsweiher +49(6209)795-816 (Telekom) +49(6252)750-308 (VoIP: sipgate.de) mail: peter@peter-dambier.de http://www.peter-dambier.de/ http://iason.site.voila.fr/ https://sourceforge.net/projects/iason/
Hi, On Mon, 24 Nov 2008 19:35:07 +0100 Peter Dambier <peter@peter-dambier.de> wrote:
I also found this one helpful
http://www.iana.org/assignments/ethernet-numbers
=== The CFxxxx Series
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!) Regards, Mark. -- "Sheep are slow and tasty, and therefore must remain constantly alert." - Bruce Schneier, "Beyond Fear"
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. Deepak
Someone is basicly "twicking the mail headers" by sending messages like "nanog@85d5b20a518b8f6864949bd940457dc124746ddc.nosense.org"-who is? 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 ? we might have heard of the IPv6 source address spoofing ..... http://www.cuba.ipv6-taskforce.org/pdf/isatap.pdf ...and w/ the translation to the OUI w/ v6 ...... http://tools.ietf.org/html/draft-eastlake-ethernet-iana-considerations-08 --- On Mon, 11/24/08, Mark Smith <nanog@85d5b20a518b8f6864949bd940457dc124746ddc.nosense.org> wrote:
From: Mark Smith <nanog@85d5b20a518b8f6864949bd940457dc124746ddc.nosense.org> Subject: Re: BCP for Private OUI / address assignments? To: peter@peter-dambier.de Cc: nanog@nanog.org Date: Monday, November 24, 2008, 10:01 PM Hi,
On Mon, 24 Nov 2008 19:35:07 +0100 Peter Dambier <peter@peter-dambier.de> wrote:
I also found this one helpful
http://www.iana.org/assignments/ethernet-numbers
=== The CFxxxx Series
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!)
Regards, Mark.
--
"Sheep are slow and tasty, and therefore must remain constantly alert." - Bruce Schneier, "Beyond Fear"
participants (6)
-
Dale W. Carder -
Deepak Jain -
isabel dias -
Mark Smith -
mike -
Peter Dambier