MAC Addresses Explained: Format, OUI, and Generating Safe Test MACs

Every network frame on an Ethernet or Wi-Fi link carries a source and destination MAC address: a 48-bit number that names the interface, not the host. Developers building network tooling, QA teams seeding device inventories, and engineers writing packet tests all need to produce MAC values that look real but cannot impersonate a shipped product. This guide breaks down the format defined in IEEE 802, explains the two bits that change everything, and shows how to mint test addresses that never collide with a real vendor.

What is a MAC address and what is it used for?

A MAC address is a 48-bit identifier assigned to a network interface controller for use as a link-layer address. It is structured as six octets, usually written in hexadecimal such as 00:1A:2B:3C:4D:5E. Switches use it to forward frames; ARP maps it to IP addresses; and Wi-Fi uses it to associate stations with access points ^[ieee-802].

MAC stands for Media Access Control, the lower sublayer of the data link layer in the IEEE 802 reference model. The address operates at Layer 2, meaning it is only meaningful within a single broadcast domain. Routers rewrite the source and destination MAC at every hop, while the IP addresses stay constant end to end. This is why a captured MAC tells you about the adapter on the local segment, not the original sender across the internet.

What is the MAC address format and octet structure?

A MAC address is six octets totaling 48 bits, split into two halves. The first three octets (24 bits) form the OUI, identifying the manufacturer. The last three octets (24 bits) form the device-specific portion assigned by that manufacturer. The full 48-bit space holds roughly 281 trillion (2^48) addresses; because the I/G and U/L bits in the first octet are reserved, about 70 trillion (2^46) of those are available as globally-unique unicast addresses ^[ieee-tut].

Notation varies by platform. Linux and most documentation use colon-separated lowercase (00:1a:2b:3c:4d:5e); Windows uses hyphens (00-1A-2B-3C-4D-5E); Cisco devices use dot-separated triplets (001a.2b3c.4d5e). All three encode the identical 48 bits. When parsing user input, accept all separators and normalize before comparison.

What is the OUI and how does OUI lookup work?

The OUI (Organizationally Unique Identifier) is the first 24 bits of a MAC, assigned to an organization by the IEEE Registration Authority. OUI lookup resolves that prefix to the registered company by querying the public IEEE registry, distributed as a downloadable CSV of every assignment ^{[ieee-oui-listing]}. Large vendors register many blocks, while small-block holders share a prefix range ^[ieee-ra].

The IEEE actually sells three registry sizes. The classic MA-L (large) block grants a full 24-bit OUI and 16.7 million device addresses. Smaller assignments, MA-M and MA-S, hand out more OUI bits to the IEEE and fewer device bits to the buyer, which is why a 24-bit prefix alone no longer guarantees a single owner.

An OUI is a 24-bit globally unique assigned number referenced by various standards. OUI is used in the family of 802 LAN standards, e.g. Ethernet, and is encoded into MAC addresses.

What do the U/L and I/G bits in a MAC address mean?

Two flag bits live in the least-significant positions of the first octet. The I/G (Individual/Group) bit is bit 0: 0 means a unicast address for one interface, 1 means a multicast or broadcast group. The U/L (Universal/Local) bit is bit 1: 0 means a globally-administered IEEE-assigned address, 1 means a locally-administered address set by software or an admin ^[ieee-802].

These bits are read in transmission order, where the least-significant bit of each octet goes on the wire first. In the human-readable hexadecimal of the first octet, that places I/G as the rightmost bit and U/L as the second-from-right bit. The broadcast address FF:FF:FF:FF:FF:FF has both bits set because it is a group address that is also locally meaningful.

How do you generate a safe random MAC address for testing?

To generate a safe test MAC, produce six random octets, then force the first octet so its U/L bit is 1 and its I/G bit is 0. In practice: take the random first octet, clear bit 0, set bit 1 (the operation byte0 = (byte0 AND 0xFC) OR 0x02). The result is a locally-administered unicast address that the IEEE will never assign to a vendor, so it is collision-safe against real hardware ^{[ietf-rfc7042]}.

1. Generate 6 random bytes from a cryptographic or seeded source.
2. Take the first byte and apply byte0 = (byte0 & 0xFC) | 0x02 to set U/L=1 and I/G=0.
3. Keep the remaining 5 bytes as-is for the device portion.
4. Format the six octets with your target separator (colon, hyphen, or Cisco dot).
5. Track issued values per network so two test devices on the same link never repeat.

The four low nibble values that signal a locally-administered second hex digit in the first octet are 2, 6, A, and E (binary x010, x110, x1010, x1110). If your generated address starts with any of those in the second position and ends the octet on an even number, it is in the locally-administered unicast range. Our generator at / emits MACs that already carry the U/L bit, so the output is safe to drop into device fixtures, DHCP test pools, or network simulation without auditing each value by hand.

Where do real devices use locally-administered MACs?

MAC randomization is now the default privacy behavior on consumer devices. Apple shipped private Wi-Fi addresses in iOS 14 (released September 2020), Android 10 enabled randomized MACs per network by default (2019), and Windows 10 added the option in 2015. Every one of these features sets the locally-administered bit, which is the same range you should target for test data so your fixtures match production traffic patterns ^{[ietf-rfc7042]}.

How do MAC addresses relate to other identifiers in test data?

A MAC names the Layer 2 interface; an IP address names the Layer 3 host; a User-Agent string names the client software. A realistic device fixture often needs all three together. When you build network test scenarios, pair a locally-administered MAC with a reserved test IP range and a synthetic browser identifier so the whole record stays clearly fictional end to end.

• For Layer 3 addresses, see our guide on generating fake IP addresses for testing, which covers RFC 5737 documentation ranges (192.0.2.0/24, 198.51.100.0/24, 203.0.113.0/24) that never route on the public internet ^{[ietf-rfc5737]}.
• For client identifiers, see our User-Agent string explainer to pair device MACs with matching browser strings.
• For the MAC values themselves, the identity generator emits locally-administered EUI-48 addresses ready for fixtures.

Keeping each identifier inside its documented test range is the single rule that keeps a dataset safe. Reserved IP blocks, locally-administered MAC space, and clearly-fictional names all share the property that they cannot collide with a real production asset, which is what makes them appropriate for repeatable QA. When auditors later inspect captured test traffic, a MAC with the U/L bit set signals at a glance that the frame originated from a synthetic device rather than physical hardware, which keeps test artifacts separable from production logs.

One caution for IPv6 work: the EUI-64 derivation used in stateless address autoconfiguration historically inverted the U/L bit when expanding a 48-bit MAC into a 64-bit interface identifier. A locally-administered source MAC therefore maps to a different interface ID than a globally-administered one, so verify the inversion rule in RFC 7042 when you build IPv6 fixtures from generated MAC values ^{[ietf-rfc7042]}. For most Layer 2 testing the 48-bit address alone is all you need.