MAC Addresses: Identity for One Hop
A MAC address is a 48-bit link-layer identifier meant to be unique on a segment: it names an interface for the switches and neighbours on that segment, is rewritten at every router, is trivially changeable, and is now randomised per network by phones and laptops — which is why "the MAC identifies the machine" is wrong in every direction that matters.
The problem
48 bits, half vendor, half serial
A MAC (media access control) address is 48 bits, written as six hex bytes: 3c:22:fb:4a:91:07. The first 24 bits are an OUI (organisationally unique identifier) that the IEEE sells to manufacturers — 3c:22:fb is Apple, 00:50:56 is VMware, 52:54:00 is QEMU/KVM’s default range — and the last 24 bits are assigned by the manufacturer, in principle uniquely per interface. That is what "burned-in address" means: a factory-set number that lets a NIC work on any network with zero configuration.
Two bits of the first byte carry flags. The lowest bit (I/G) is 1 for group addresses — multicast, including the all-ones broadcast ff:ff:ff:ff:ff:ff — and 0 for a single interface. The second-lowest bit (U/L) is 1 for locally administered: an address set by software rather than a factory, which is what virtual machines, containers, bonded interfaces and randomised Wi-Fi addresses use. A MAC whose second hex digit is 2, 6, A or E is locally administered; 02:42:ac:11:00:02 is Docker’s signature.
3c:22:fb:4a:91:07
└──┬───┘ └──┬───┘
OUI vendor-assigned (24 bits)
(Apple)
first byte 0x3c = 0011 1100
│└─ I/G bit = 0 → unicast (1 = multicast/broadcast)
└── U/L bit = 0 → globally administered (1 = local, e.g. 02:..., 06:..., 0a:..., 0e:...)
ff:ff:ff:ff:ff:ff broadcast: every interface on the segment
01:00:5e:xx:xx:xx IPv4 multicast (low 23 bits of the group address)
33:33:xx:xx:xx:xx IPv6 multicast (low 32 bits of the group address)
02:42:ac:11:00:02 Docker container (locally administered)Scope: one segment, one hop
Here is the fact that everything else follows from: a MAC address only means something on the local segment. It is written into a frame by the sender on this link and read by the switches and the receiving interface on this link. When the frame reaches a router, the router strips the whole Ethernet header, forwards the IP packet, and builds a new frame with its *own* MAC as source and the next hop’s MAC as destination. The server at the other end of the internet sees the MAC of the last router before it — it has no way of learning yours, and no reason to.
This is why the claim "a MAC address uniquely identifies a machine on the internet" is wrong, not merely imprecise. It is not carried across the internet at all. It does not identify a machine (a laptop has several — Ethernet, Wi-Fi, Bluetooth, a VM bridge, each with its own). It is not even guaranteed unique: vendors have shipped duplicates, VMs are cloned, and any user can set one. What the MAC *is* good for is exactly its job: telling the neighbours and switches on this cable which interface should pick up this frame. ARP and Neighbor Discovery exist to map an IP to that one-hop identifier; see ARP and Neighbor Discovery: From an IP to a Local MAC.
The consequences are practical. A firewall rule "block this MAC" only works on the same segment. A DHCP reservation keyed by MAC only works until the device randomises. An "allowed MACs" list on a Wi-Fi network stops nobody who can type ip link set dev wlan0 address …. And any log that claims to show the "client MAC" of a remote user is showing a router.
- Carried: one hop. Rewritten: at every router. Visible to the server: never (unless it is on your segment).
- Not routable: no router forwards on MAC. Not authenticated: any host can claim any MAC. Not one per machine: one per interface.
Randomised and locally administered addresses
Because a stable burned-in address makes a device trackable across every network it joins — coffee shop, airport, office — iOS (since 14), Android (since 10), Windows 10+ and macOS now use randomised MAC addresses on Wi-Fi by default: a locally administered address generated per network (per SSID), sometimes rotated over time. Your phone presents a different MAC to your home network than to the office, and it is not the one printed under Settings → About. This is deliberate and it breaks every assumption built on MAC stability: DHCP reservations, captive-portal "remember this device", parental-control filters and MAC-based network access control.
Software-set addresses are everywhere else too. Every Docker container gets 02:42:…; every KVM virtual machine 52:54:00:…; a bonded pair of NICs shares one; a VRRP virtual router advertises 00:00:5e:00:01:xx that moves between physical routers on failover. In each case the address is chosen to be unique *on that segment*, which is all the link layer needs. "Locally administered" is not a corner case; on a modern network it may be most of the table.
What can go wrong with a link-layer identity
Spoofing is a one-line command: set the interface’s MAC to another host’s, and switches will learn the new port and deliver that host’s frames to you (until the real host sends and flips the table back — the flapping itself is the symptom). Combined with ARP spoofing it is the classic on-segment interception. Duplicates — two interfaces with the same MAC on one segment, from a cloned VM image or a manufacturing error — produce exactly this flapping with no attacker: both hosts get intermittent connectivity and the switch logs "MAC moved".
The design intent was never security. It was: give every interface a name that is unique enough on a cable that frames go to the right place, with no configuration. Everything that needs identity across networks — authentication, sessions, device management — has to live above the link layer, and the link layer is not going to help.
Key points
- A MAC is 48 bits: a 24-bit vendor OUI and a 24-bit serial, with two flag bits for multicast and locally administered.
- It identifies an *interface* on *one segment* for *one hop*. Every router strips it and writes a new one; the remote server never sees yours.
- It is not globally unique in practice, not routable, not authenticated, and not one per machine.
- Phones and laptops randomise their Wi-Fi MAC per network by default; VMs, containers and virtual routers use software-assigned addresses. Locally administered is normal.
- MAC-based access control, reservations and "remember this device" break by design; identity across networks belongs above the link layer.
Why does this exist?
Mechanisms are answers to constraints. Open each question before reading the answer.
▸Why a factory-assigned address when IP addresses are assigned anyway?
Something has to work before any assignment happens: the DHCP request that gets you an IP is itself a frame that needs a source address. A burned-in unique-enough address bootstraps everything else with zero configuration.
▸Why 48 bits?
Large enough (2^47 unicast addresses) that a vendor block scheme could hand out uniqueness without coordination per device, small enough for 1980s hardware to match at line rate. It has held up.
▸Why do phones randomise it?
A stable identifier broadcast in cleartext to every network you join is a tracking beacon. Randomising per network keeps the link layer working (unique on this segment) while denying cross-network correlation.
How it fails
What the failure looks like from inside real software.
- DHCP reservation stops matching after a phone OS update: the device now presents a randomised MAC; the reservation targets the burned-in one.
- Two VMs cloned from one image share a MAC: both get intermittent connectivity, the switch logs address flapping, ARP entries point at the wrong host.
- A "block by MAC" rule at the office firewall does nothing for a device on a different subnet — the firewall sees the router’s MAC.
- Wi-Fi MAC allowlisting as security: bypassed by one
ip link set … addressafter sniffing one legitimate frame. - A log analysis that groups "client MACs" from a remote server: every entry is the same upstream router.