MAC address formats

Six bytes, twelve hex digits

An Ethernet MAC address is 48 bits: six octets, written as twelve hexadecimal digits. That is the whole of it. Every format below is the same 48 bits with different punctuation, and any tool that tells you two of them are different addresses is wrong.

Globally unique 48-bit MAC identifiers are EUI-48 identifiers assigned under IEEE rules. You will also see MAC-48, an obsolete IEEE term that still turns up in older documentation; locally administered MAC addresses are not globally unique EUI-48 identifiers.

The four notations

Colon-separated 00:00:5e:00:53:01

Common in Linux and other Unix-like tooling. Lowercase is common but not required. This is the form most people picture when they think of a MAC address.

Hyphen-separated 00-00-5E-00-53-01

Common in IEEE documents and Windows tools such as getmac, arp -a, and ipconfig /all. Case varies and carries no meaning.

Dotted triplets 0000.5e00.5301

Four hex digits at a time, separated by dots. Cisco's house style, across IOS, IOS XE, and NX-OS. The grouping is purely visual. Each dot falls cleanly between two octets, but the traditional 24-bit vendor boundary falls inside the middle group, so this notation hides the one division that carries meaning.

Bare 00005e005301

No separators at all. Shows up in DHCP logs, RADIUS accounting, and some HPE and Aruba output.

Variants you will also meet

Beyond the four, a handful of real formats turn up often enough to recognize on sight. The same address in each:

The client-ID is not merely another MAC notation: its leading 01 is ARP hardware type 1, Ethernet, followed by the six-byte MAC address. Strip that first byte before parsing the address.

The split-halves separator coincides with the 24-bit MA-L/OUI boundary, but it does not mark the assignment boundary for MA-M or MA-S addresses.

Case is never significant

00:00:5e:00:53:01 and 00:00:5E:00:53:01 are the same address. Hexadecimal case carries no information here and never has.

It matters anyway, in one narrow place: string comparison. If you diff a Cisco inventory against a Windows export, or use a MAC as a dictionary key, or write a firewall rule generator that string-matches, the case difference will cost you an afternoon. Normalize before you compare, not after.

Leading zeros get dropped, and it breaks things

Some ARP implementations, notably macOS, the BSDs, and older Solaris, print each octet without its leading zero:

? (192.168.1.5) at 0:0:5e:0:53:1 on en0 ifscope [ethernet]

That is 00:00:5e:00:53:01. It is six octets, not a truncated address, and a regular expression expecting pairs of hex digits will not see it at all. This is one of the most common reasons a MAC address in real captured output goes unparsed.

The first octet carries two flag bits

The two least significant bits of the first octet are the individual/group bit and the universal/local bit. They do not by themselves determine whether the remaining bits have a registry assignment.

The least significant bit is the individual/group bit. When it is 0, the address identifies one destination, normally called unicast. When it is 1, it identifies a group, normally called multicast. The all-ones broadcast address, ff:ff:ff:ff:ff:ff, is the special case of a group address delivered to every station on the segment.

The next bit up is the universal/local bit. When it is 0, the address claims to be universally administered, which means its prefix is worth looking up. It does not promise the lookup will land: plenty of prefixes have never been assigned to anyone. When it is 1, the address is locally administered. For individual addresses, this commonly indicates random or manual assignment, so an apparent vendor-prefix match is not authoritative. Local group space also contains standardized mappings such as 33:33 IPv6 multicast. A CID can identify an organization in local address space, but a matching CID alone does not establish who generated a particular address.

That gives four combinations. The bits below are written most significant first, so 10 means the universal/local bit is set and the individual/group bit is clear. Because both live in the first octet, the second hex digit of the address tells you which row you are in at a glance. IEEE 802c divides the locally administered unicast combination into four Structured Local Address Plan (SLAP) quadrants, so those four second-nibble patterns are shown separately:

So de:ad:be:ef:00:01 is not a vendor address. DE is 1101 1110: the universal/local bit is set and the individual/group bit is clear, which is the SAI row. IEEE P802.1CQ proposed assignment protocols for SAI but expired without becoming a standard, so the pattern does not identify an assigning protocol or organization.

That nibble explains many "unknown vendor" results. Randomized client addresses and many manually configured, virtual-interface, and container-bridge addresses use locally administered unicast space, but virtual or manually assigned addresses are not required to do so.

Where the vendor part ends is not always 24 bits

The habit of calling the first three octets "the OUI" is a useful approximation and an increasingly wrong one. The IEEE offers MAC address block assignments at three sizes, and the smaller two put many assignees inside one set of leading octets:

IAB assignments were retired in 2014 but remain in use, and MA-S is their replacement. A lookup keyed only on the first six hex digits cannot distinguish MA-M, MA-S, or IAB assignments; it may return an unrelated assignee, a generic IEEE entry, or no match. The registries guide covers how the sizes interact, where CID assignments fit, and why some addresses legitimately have no owner at all.

Bit order, and the one place it bites

Ethernet transmits each address octet least significant bit first, so the individual/group bit is the first address bit transmitted. Canonical notation still writes octet values normally.

Token Ring and some FDDI tooling historically exposed addresses in non-canonical, bit-reversed byte order. Reversing the bits within each octet converts between the two representations:

Spanning Tree's reserved address, canonically 01:80:C2:00:00:00, appears in non-canonical form as 80:01:43:00:00:00.

These technologies are obsolete in most deployments, but non-canonical addresses can still appear in legacy captures, Token Ring ARP fields, and old documentation. Bit-reverse only when the medium or producing tool is known to use non-canonical ordering; an implausible prefix alone is not evidence.

Modified EUI-64 and the IPv6 form

One legacy way to derive a 64-bit IPv6 interface identifier from a 48-bit IEEE 802 address is to insert ff:fe between the third and fourth octets and invert the universal/local bit. This creates a modified EUI-64 interface identifier; stateless address autoconfiguration itself does not require this method.

The 02 is the inverted universal/local bit, and ff:fe is characteristic, but not proof, of this construction. RFC 8064 recommends opaque stable interface identifiers instead of embedding stable link-layer addresses; systems may also use temporary privacy addresses.

macs4days reads IPv6 addresses as context sitting beside a MAC, and deliberately does not treat hex inside an IPv6 address as an address of its own, since almost none of them carry one. Reverse this procedure only when the identifier is known to use this construction, and treat the result as the source 48-bit address, not necessarily the device's current hardware address.

What macs4days does with all of this

The parser accepts the colon-separated, hyphen-separated, dotted, bare, hyphenated-quad, split-half, DHCP-client-ID, and supported device-name forms above in mixed case, including dropped leading zeros. Space-separated octets are accepted only when the entire input line is the address. It normalizes each form for lookup and display.

It also reads the flag bits before it reads the registry. Every locally administered unicast address gets a [special] badge and its SLAP quadrant classification. Only an xA ELI address is checked against the exact 24-bit prefixes proven to come from the CID registry. A match appears separately as a CID prefix registrant, not as the device's hardware vendor, because a randomized address can land on a registered prefix by chance. Multicast and the other local quadrants are classified without an organization lookup.