... ... There is another concept called Locally Administered Addresses. They apply to all IEEE LAN technologies, so they may be a part of 802.1 or 2, not 802.3. An example of their use that I saw a lot was with IBM mainframes. Remote controllers talked to the mainframe using the MAC layer. There was no network of transport layer. So a remote communication controller that was LAN attached would be configured with the MAC address of the NIC in the host. Obviously, if that NIC blew up and you didn't want to spend a few hours of mainframe downtime while you repaired the NIC you would resort to that evil process known derisively here as "board-swapping". This would mean that the host NIC now had a new MAC address and the configurations of all the LAN attached controllers had to be changed. In a geographically dispersed LAN it could be quite expensive to touch every box. So, instead of using the burned in MAC address you would use a Locally Administered address. The LAA bit is the second bit on the wire. Ethernet puts the LSb of each byte on the wire first, so a LAA Ethernet address would be one with the 2 bit on. Token Ring put the MSb on the wire first, so an LAA address typically started with 0x40. DEC might not have supported LAAs in any given environment, of course. But I doubt if the 802.3 spec specifically exempts a VMSCluster. ;) DEC was an early player in this area. After all, DIX Ethernet format refers to DEC, Intel & Xerox. They did all manner of strange things. For example, the first three bytes of a MAC address are the vendor code. DEC used 4, and on a given adapter they might use any of the 4 possible variants of the MAC address using the same low order 3 bytes but varying the high order 3 bytes to any of their 4 vendor codes. This is one reason why Ethernet switches can usually learn at least 4 MAC addresses per port. Gil

arcarlini> Did anything actually do this? It seems very odd. Yes, and I am quite sure that DEC did NOT do anything like that. It would have been a very clear violation of the Ethernet standards we maintained internally, and 802.3 wouldn't be happy about it either. acarlini> I know arcarlini> that gear like the DECnis was assigned a block of arcarlini> addresses, but that was perfectly legal (i.e. the CPU card arcarlini> had an address of, for example, 08-00-2B-00-AA-00 and that arcarlini> covered a range up to (again, for example) arcarlini> 08-00-2B-00-AA-FF (i.e. sixteen addresses). That would be 256, actually... but yes, block assignment like that was standard in multiport devices. The address ROM would actually list the range. paul

Gil> There is another concept called Locally Administered Gil> Addresses. ... Gil> So, instead of using the burned in MAC address you would use a Gil> Locally Administered address. The LAA bit is the second bit on Gil> the wire. Ethernet puts the LSb of each byte on the wire first, Gil> so a LAA Ethernet address would be one with the 2 bit on. Token Gil> Ring put the MSb on the wire first, so an LAA address typically Gil> started with 0x40. Gil> DEC might not have supported LAAs in any given environment, of Gil> course. But I doubt if the 802.3 spec specifically exempts a Gil> VMSCluster. ;) Of course it doesn't. DEC used locally administered addresses all the time -- the DECnet style MAC address is aa-00-04-00-xx-yy so it's locally administered, as indeed it should be given the definition. Gil> DEC was an early player in this area. After all, DIX Ethernet Gil> format refers to DEC, Intel & Xerox. They did all manner of Gil> strange things. For example, the first three bytes of a MAC Gil> address are the vendor code. DEC used 4, and on a given adapter Gil> they might use any of the 4 possible variants of the MAC address Gil> using the same low order 3 bytes but varying the high order 3 Gil> bytes to any of their 4 vendor codes. This is one reason why Gil> Ethernet switches can usually learn at least 4 MAC addresses per Gil> port. That doesn't match any DEC practice I know of, and I was the DEC address administrator at one time so I should know... You may be confused with the DECnet address. DECnet phase IV uses MAC addresses formed from the DECnet node address: aa-00-04-00-xx-yy where xx is the low order and yy the high order of the 16 bit node address. Some NICs were capable of keeping their "real" MAC address alive at the same time, which was good for LAT; others would use this LAA for all traffic, which meant you had to be sure to turn DECnet on before LAT. Before IEEE got into networking, DEC was assigned company codes (later named "OUI) aa-00-01 through aa-00-04. And indeed some early NICs, like the DEUNA, were shipped with MAC addresses like that. In addition, some multicast addresses for DEC protocols are derived from these (they start with AB-00-...). After IEEE started changing Ethernet around, defining the notion of locally administered addresses in the process, DEC obtained OUI 08-00-2B which was then used across the board. I think the earlier assignments were officially grandfathered but even so we stopped using them for new hardware to avoid confusion. DEC also owned OUI 00-00-F8 but I don't know if that was ever used for MAC addresses; it did get used for 802.2 SNAP protocol identifiers for bridging from FDDI to Ethernet, in a very confusing and strange story... paul

Adrian Graham wrote: I have some DE500-something-or-other PCI ethernet cards that use 00-00-F8 so they are definitely pre-Cabletron and pre-HP and (IIRC) pre-COMPAQ. Anyway, the DECservers followed some strange circuitous route that took them to DNPG (and have now drifted off to someone else). They did (I think) briefly live inside Cabletron, but only while they were looking for somewhere to send them :-) Antonio -- Antonio carlini arcarlini at iee.org

arcarlini> Adrian Graham wrote: arcarlini> I have some DE500-something-or-other PCI ethernet cards arcarlini> that use 00-00-F8 so they are definitely pre-Cabletron and arcarlini> pre-HP and (IIRC) pre-COMPAQ. That fits; the 00-00-F8 OUI was issued to DEC when it was still DEC -- maybe around 1992 or so. That was during the time when FDDI development was going fast and furious (i.e., before Fast Ethernet really took hold). I had forgotten about MAC address assignments from that block. But it makes sense; large chunks of the 08-00-2B block had already been issued, and it may have been some specialized assignment. I no longer have the address database file (left that at DEC, it wasn't a public database...) paul