How can you recognise a randomised MAC address from its bits, and what breaks when a network treats MAC addresses as stable device identities?
answer
- privacy against tracking
- the bit beside the group bit
- second hex digit
- the same device, a new address
basics
~20 sA randomised MAC sets the local (U/L) bit and clears the group bit, so its second hex digit is 2, 6, A or E. Anything keyed to a stable MAC breaks: address leases, allow-lists, portal sessions and device inventories.
solid answer
~50 sDevices randomise their MAC address because a fixed global address lets anyone on the link track them across networks; RFC 9542's security considerations make that point. A random address must be **unicast** and must not claim an IEEE prefix, so the device clears the **group bit** (`0x01`) and sets the **local bit** (`0x02`) of the first octet: the second hex digit is **2, 6, A or E**. The bit shows the address is locally administered, not that it is random; virtual interfaces and operator-assigned addresses look the same. When a device uses a different address per network, or rotates it, systems that assumed one MAC per device break: leases pile up, allow-lists and portal sessions stop matching, inventories double count. RFC 9542 already warns that MACs can be spoofed and that known devices can return with a new address, so durable identity has to come from authentication, not the MAC.
go deeper
Recall why devices hide their real MAC address, to avoid being tracked, and that a random one sets the local bit of the first octet.
Read the bits: group bit clear, local bit set, second hex digit 2, 6, A or E. Explain why the local bit alone does not prove the address is random.
Walk through what breaks when MACs change: leases, allow-lists, portal sessions, inventories. Argue for treating the MAC as a hint and authenticating devices for anything that matters.
Balance user privacy against network control: which systems may keep relying on MACs, which must move to device authentication, and how to report devices honestly once one device can show many addresses.
## Why devices randomise A global MAC address is a stable, unique identifier the device sends in clear in every frame. Anyone who can see frames, on a shared wired segment or over the air on wireless, can recognise the same device at a café, an office and an airport. RFC 9542's security considerations say MAC addresses "can be used for tracking the device with that interface" and point to IETF work on address randomisation as a partial mitigation. Many phone and laptop operating systems therefore present a **randomised** address instead of the global one, an implementation feature rather than a protocol. Two common policies: - **Per network**: a different random address for each network, kept each time the device returns to the same one. - **Rotating**: a new random address after a period of time or on each new connection. Which one is the default, and how often rotation happens, is the implementation's choice. ## Recognising a locally administered unicast address A random address must not pretend to come from an IEEE-assigned block, and it must be an individual address. So the device sets two bits of the first octet (RFC 9542 section 2.1.1): - **group bit** (`0x01`) = 0: unicast; - **local bit** (`0x02`) = 1: locally administered, outside any OUI. The other bits are random. Reading the **second hex digit** of the first octet is enough: | Second hex digit | Group bit | Local bit | Could be a random client address? | |---|---|---|---| | 0, 4, 8, C | 0 | 0 | No: global unicast from an IEEE block | | 1, 5, 9, D | 1 | 0 | No: group address | | **2, 6, A, E** | 0 | 1 | **Yes**: locally administered unicast | | 3, 7, B, F | 1 | 1 | No: locally administered group address | RFC 9542 also describes an optional plan that splits the local space into four quadrants using the next two bits; random assignment belongs in the "Administratively Assigned" quadrant, whose second hex digit is 2. Devices that randomise do not all follow that plan, so 6, A and E also occur. ## What the bit does not prove A set local bit means "not from the IEEE registry", nothing more: - Operators assign local addresses on purpose, for example to give a service a fixed address it can move between machines. - Software creates local addresses for virtual interfaces; Linux, for one, gives many virtual devices a random locally administered address when none is set. - IPv6 multicast addresses beginning `33-33` have the local bit set too (RFC 9542), though they are group addresses and never a source. And the reverse holds: an address with the local bit clear can still be forged, because software chooses what source address to send. ## What changes for the network | Consumer of the MAC | What it assumed | What happens with randomisation | |---|---|---| | Address leases and reservations | one client, one hardware address | a returning device looks new; rotating devices consume extra leases | | MAC allow-lists and MAC-based admission | the address identifies a known device | the device no longer matches its entry | | Captive-portal sessions | the address marks a device that has signed in | the user is asked to sign in again | | Inventory and analytics | one MAC per device | devices are counted several times | | OUI lookups | the prefix names the maker | a local address names no maker | IPv6 interface identifiers used to be built from the MAC; RFC 8064 now recommends against embedding link-layer addresses and points to RFC 7217's stable, privacy-preserving identifiers instead. ## Designing around it - Treat a MAC address as a **session-scoped hint**, useful for troubleshooting on one link and not as an identity. - Where a device must be recognised, **authenticate** it with credentials or certificates instead of trusting the address it sends. - Count a local unicast address as "possibly random" in reports, not as a new device. - Do not block local addresses outright: that breaks virtual interfaces and legitimate operator assignments along with the privacy feature.
- Does per-network randomisation stop all tracking?No. It stops a single address from linking a device across different networks, but on one network the per-network address is stable by design, so that network still recognises the device on each visit. Other signals, such as names a device announces or the pattern of its traffic, can also identify it. Randomisation narrows one tracking channel; it does not anonymise the device.
- Why is blocking every locally administered address a poor fix?The local bit marks any address not taken from an IEEE block, so a blanket block also catches virtual interfaces, bridges and addresses operators assign on purpose, as well as privacy-conscious clients. It also protects nothing: an attacker can forge a global-looking address just as easily. Authenticate devices instead.
saying these in an interview costs you the question
- A randomised MAC address can be told apart from a real one only by asking the device.
- Any MAC with the local bit set must come from a privacy feature.
- A random MAC address may have the group bit set.
- A MAC address with the local bit clear cannot be forged.
- The OUI of a randomised address still names the device's maker.
- MAC address randomisation is a protocol that switches must support.