Whic one of these, is locally assigned unicast MAC address, when talking about output format CSCO uses? 4000.0000.0000 (Local IXPs choice) 0200.0000.0000 (My money is here) http://standards.ieee.org/regauth/oui/oui.txt 02-07-01 (hex) RACAL-DATACOM A0-6A-00 (hex) Verilink Corporation In either case two of the lowest or highest bits of 1st octet seems to be happily used to assign addresses. What am I missing here? -- ++ytti
Whic one of these, is locally assigned unicast MAC address, when talking about output format CSCO uses?
4000.0000.0000 (Local IXPs choice) 0200.0000.0000 (My money is here)
the second one. most significant byte is on the left, but within the byte, most significant bits are on the right. so U/L bit is the second one counting from the left.
http://standards.ieee.org/regauth/oui/oui.txt 02-07-01 (hex) RACAL-DATACOM
good point, dunno.
http://standards.ieee.org/regauth/oui/oui.txt 02-07-01 (hex) RACAL-DATACOM A0-6A-00 (hex) Verilink Corporation
In either case two of the lowest or highest bits of 1st octet seems to be happily used to assign addresses. What am I missing here?
After enabling DECnet routing, the interface MAC address turns to something like this: GigabitEthernet0/2 is up, line protocol is up Hardware is BCM1250 Internal MAC, address is aa00.0400.0a04 (bia 000b.bffd.fc1a) And you'll find AA-00-04 (hex) DIGITAL EQUIPMENT CORPORATION in the list. I don't know what 02-07-01 is, but I guess that could be something similar: The OUI belongs to a company, but they don't use the addresses to burn them into interface cards. Andras
On (2009-02-28 22:38 +0100), JAKO Andras wrote: Hey,
http://standards.ieee.org/regauth/oui/oui.txt 02-07-01 (hex) RACAL-DATACOM
After enabling DECnet routing, the interface MAC address turns to something like this: Hardware is BCM1250 Internal MAC, address is aa00.0400.0a04 (bia 000b.bffd.fc1a) AA-00-04 (hex) DIGITAL EQUIPMENT CORPORATION
in the list. I don't know what 02-07-01 is, but I guess that could be something similar: The OUI belongs to a company, but they don't use the addresses to burn them into interface cards.
I guess you shouldn't be able to assign 02 (or AA) to a company for ethernet number, much in the same way you shouldn't be able to assign RFC1918. However you are right, it seems that these are unexplained exceptions to rules: http://www.iana.org/assignments/ethernet-numbers 'some of the known addresses do not follow the scheme (e.g., AA0003; 02xxxx)' Would be interesting to see what are the historical reasons.Perhaps they simply predate the scheme or some might not even co-exist in ethernet network to begin with, in which case they might be better documented elsewhere. In any case, to avoid collision with history, better start with 06 which seems cruft free, instead of 02, when choosing local MAC address prefix. As a side note, the 40 prefix used as local MAC in IXP here, seems to be just mistake in assuming ethernet follows tokenring in numbering scheme. -- ++ytti
Date: Sun, 1 Mar 2009 00:40:00 +0200 From: Saku Ytti <saku+nanog@ytti.fi>
On (2009-02-28 22:38 +0100), JAKO Andras wrote:
Hey,
http://standards.ieee.org/regauth/oui/oui.txt 02-07-01 (hex) RACAL-DATACOM
After enabling DECnet routing, the interface MAC address turns to something like this: Hardware is BCM1250 Internal MAC, address is aa00.0400.0a04 (bia 000b.bffd.fc1a) AA-00-04 (hex) DIGITAL EQUIPMENT CORPORATION
in the list. I don't know what 02-07-01 is, but I guess that could be something similar: The OUI belongs to a company, but they don't use the addresses to burn them into interface cards.
I guess you shouldn't be able to assign 02 (or AA) to a company for ethernet number, much in the same way you shouldn't be able to assign RFC1918. However you are right, it seems that these are unexplained exceptions to rules:
http://www.iana.org/assignments/ethernet-numbers 'some of the known addresses do not follow the scheme (e.g., AA0003; 02xxxx)'
Would be interesting to see what are the historical reasons.Perhaps they simply predate the scheme or some might not even co-exist in ethernet network to begin with, in which case they might be better documented elsewhere. In any case, to avoid collision with history, better start with 06 which seems cruft free, instead of 02, when choosing local MAC address prefix.
As a side note, the 40 prefix used as local MAC in IXP here, seems to be just mistake in assuming ethernet follows tokenring in numbering scheme.
OK. Time for a history lesson. In the olden days, Xerox, the company that made the first Ethernet and, in a consortium with Digital and Intel, developed the first public standard for Ethernet. (This was referred to as the Blue Book or the DIX Ethernet.) At the time, the Ethernet networking schemes all assumed that the MAC address would be changes to embed the network address. This would allow hosts to know the MAC address of any other system running the same protocol. XNS and DECnet both did this and registered the locally assigned prefix that they would be using. This seemed quite reasonable at the time. Several companies registered the OID they were going to use for their networking systems as well as the hardware ones. This assured that no two hosts would have locally assigned address. Then along came IP over Ethernet and ARP. IP won the protocol battle (pretty easily) and the concept of dong MAC to host mapping via a protocol like ARP or NDP became the norm. But the OIDs for several protocols were already in the registry when it was turned over to the IEEE after 802.3 was ratified. IEEE agreed to retain existing registrations and they have remained there. The scheme was actually not a bad one, just one that never really caught on for modern networking. -- R. Kevin Oberman, Network Engineer Energy Sciences Network (ESnet) Ernest O. Lawrence Berkeley National Laboratory (Berkeley Lab) E-mail: oberman@es.net Phone: +1 510 486-8634 Key fingerprint:059B 2DDF 031C 9BA3 14A4 EADA 927D EBB3 987B 3751
On (2009-03-02 17:31 -0800), Kevin Oberman wrote:
http://standards.ieee.org/regauth/oui/oui.txt 02-07-01 (hex) RACAL-DATACOM
Would be interesting to see what are the historical reasons.Perhaps they simply predate the scheme or some might not even co-exist in ethernet network to begin with, in which case they might be better documented elsewhere.
IEEE after 802.3 was ratified. IEEE agreed to retain existing registrations and they have remained there.
So where does this leave the current local scape addresses being globally assigned? Is it possible that we will run into legit 02 MAC addresses in the wild? -- ++ytti
Date: Tue, 3 Mar 2009 08:42:16 +0200 From: Saku Ytti <saku+nanog@ytti.fi>
On (2009-03-02 17:31 -0800), Kevin Oberman wrote:
http://standards.ieee.org/regauth/oui/oui.txt 02-07-01 (hex) RACAL-DATACOM
Would be interesting to see what are the historical reasons.Perhaps they simply predate the scheme or some might not even co-exist in ethernet network to begin with, in which case they might be better documented elsewhere.
IEEE after 802.3 was ratified. IEEE agreed to retain existing registrations and they have remained there.
So where does this leave the current local scape addresses being globally assigned? Is it possible that we will run into legit 02 MAC addresses in the wild?
Thee are properly "locally assigned",not "local scope" addresses, but the effect is the same. This is only a problem if you have multiple systems running DECnet (or some other protocol using this) with the same layer 3 address. That should never happen, so there should be no duplication. The only real issue I see is with IPv6 EUI-64 addresses and even in that case, there would have to be two systems getting their address space from the same router interface before there is a conflict. -- R. Kevin Oberman, Network Engineer Energy Sciences Network (ESnet) Ernest O. Lawrence Berkeley National Laboratory (Berkeley Lab) E-mail: oberman@es.net Phone: +1 510 486-8634 Key fingerprint:059B 2DDF 031C 9BA3 14A4 EADA 927D EBB3 987B 3751
On (2009-03-03 13:50 -0800), Kevin Oberman wrote:
This is only a problem if you have multiple systems running DECnet (or some other protocol using this) with the same layer 3 address. That should never happen, so there should be no duplication.
Why would they need to have same L3 address? The way I see it, only thing that matters is, if or not, the addresses might speak ethernetII. If your ethernetII switch sees your local 02 address and one of the addresses below and they collide, the switch will keep relearning the address behind two ports. Unless of course it is guaranteed, that none of these addresses will ever appear as BIA in ethernetII capable NIC. 02-07-01 (hex) RACAL-DATACOM 02-1C-7C (hex) PERQ SYSTEMS CORPORATION 02-60-86 (hex) LOGIC REPLACEMENT TECH. LTD. 02-60-8C (hex) 3COM CORPORATION 02-70-01 (hex) RACAL-DATACOM 02-70-B0 (hex) M/A-COM INC. COMPANIES 02-70-B3 (hex) DATA RECALL LTD 02-9D-8E (hex) CARDIAC RECORDERS INC. 02-AA-3C (hex) OLIVETTI TELECOMM SPA (OLTECO) 02-BB-01 (hex) OCTOTHORPE CORP. 02-C0-8C (hex) 3COM CORPORATION 02-CF-1C (hex) COMMUNICATION MACHINERY CORP. 02-E6-D3 (hex) NIXDORF COMPUTER CORPORATION -- ++ytti
participants (4)
-
Grzegorz Banasiak -
JAKO Andras -
Kevin Oberman -
Saku Ytti