MAC Vendor Lookup

U/L and I/G, the two bits that change how the address reads

A MAC address has 48 bits, but two of them, the lowest-order bits of the first octet, decide how the rest should be interpreted. The I/G bit (bit 0) separates an individual address from a group address: at 0 the frame targets a single interface, at 1 it is multicast or broadcast. The U/L bit (bit 1) separates a universal address, assigned by the vendor from a block registered with the IEEE, from a locally administered one.

In practice this settles most reading questions. If the I/G bit is set, hunting for a vendor is wasted effort, because the address represents a group and not a piece of equipment. If the U/L bit is set, the prefix was never allocated by the IEEE, so any vendor name found there is a coincidence or a leftover from an old block.

• Even first octet without bit 1 set: universal unicast address, the case where the OUI actually means something.
• Odd first octet: multicast or broadcast.
• First octet ending in 2, 6, A or E: locally administered address.

From the MAC to EUI-64 and the link-local address

Before stable and randomized interface identifiers became the norm, the IPv6 link-local address of an Ethernet interface was derived straight from the MAC. The procedure, described in appendix A of RFC 4291, has two steps: insert FF:FE in the middle of the 48 bits to form 64 bits, and flip the U/L bit of the first octet.

The flip is the step that most often goes wrong by hand, because it is counterintuitive: a universal address (bit 0) yields an identifier with that bit set to 1. The RFC's own example makes it plain, 34-56-78-9A-BC-DE becomes 36-56-78-FF-FE-9A-BC-DE, and the matching link-local address is fe80::3656:78ff:fe9a:bcde. The same address also yields the solicited-node multicast address (ff02::1:ff plus the last 24 bits), used by neighbor discovery, and the 33:33:FF MAC that carries it at the Ethernet layer.

Randomization, virtualization and the vendor that does not exist

Modern phones and laptops generate a random address per wireless network precisely to stop the MAC from working as a persistent identifier. Those addresses have the U/L bit set and belong to no registered block, so the correct answer for them is not unknown vendor but randomized address. Treating one case as the other leads to wrong conclusions in inventory work and in network investigation.

Virtualized environments create the opposite distortion. The VirtualBox 08:00:27 block appears in the IEEE registry under the name of its original allocation rather than VirtualBox, and the QEMU/KVM 52:54:00 prefix is locally administered and simply does not exist in the registry. In both cases the raw IEEE data answers poorly, and what really identifies the address is the range each hypervisor is known to use by convention.

• 00:50:56 and 00:0C:29: VMware.
• 08:00:27: VirtualBox (the IEEE registry shows the original allocation).
• 00:15:5D: Hyper-V.
• 00:16:3E: Xen.
• 52:54:00: QEMU/KVM, unregistered because it is locally administered.