MAC Address Structure and How a NIC Filters Group Traffic

Every station on an Ethernet segment decides, for each arriving frame, whether the frame belongs to it. That decision is made in hardware, before the driver is interrupted, and it is made by comparing a 48-bit number against a small table plus a few flags. The address format is arranged so that the comparison can be done with a mask rather than a table lookup in the common case, and the arrangement of bits is dictated by the order in which bytes travel on the wire.

Byte order versus bit order

A MAC address is six bytes. Written in the conventional form 02:42:ac:11:00:02, the leftmost byte is the first one transmitted, and within each byte the least significant bit is transmitted first. This is the reverse of the bit order used by most other protocols on the same wire, and it is why code that parses these addresses has to handle bit order explicitly.

Two bits inside the first transmitted byte carry structural meaning:

• Bit 0 of the first byte is the individual/group bit. Zero means the address identifies a single station; one means it identifies a group.
• Bit 1 of the first byte is the universal/local bit. Zero means the address was assigned by the IEEE registration authority; one means the address is locally administered.

Because these bits live in the first byte, a reader can classify any address from its first octet alone. 02:42:... has first octet 0x02, whose low two bits are 10: bit 0 clear means individual, bit 1 set means locally administered, so the address is a unicast address assigned by whoever configured the interface rather than by a manufacturer. 01:00:5e:... has 0x01, low bits 01: group, universally administered, the combination used by the registered IPv4 multicast block. 00:1a:2b:... has 0x00: unicast, universally administered.

The universal/local bit is not decorative. It lets a network operator assign addresses on a segment without purchasing a block, and it tells a reader that the address will not collide with a manufacturer-assigned one. Virtual machines and containers commonly receive locally administered addresses precisely for this reason.

The 24-bit prefix and what it does not guarantee

A universally administered address is split into a 24-bit organizationally unique identifier and a 24-bit extension. The OUI is assigned by the IEEE registration authority to an organization, and that organization is responsible for keeping the extension unique within its prefix. The practical consequence is that the first three bytes identify a vendor with reasonable reliability, which is why tools that map addresses to hardware vendors work at all.

Uniqueness is not a guarantee at the level of a protocol. Duplicate addresses do occur: cloned virtual machines, misconfigured embedded devices, and reused addresses across administrative domains all produce them. Ethernet has no duplicate address detection. On a shared segment both stations receive frames addressed to the duplicated address; on a switched segment the bridge’s forwarding entry points at whichever station transmitted most recently, so traffic goes to one of them and moves when the other transmits. Nothing in the link layer reports the conflict. ARP has an optional probe mechanism, described in ARP and neighbour cache behaviour, but it only covers the case where a station actively checks before claiming an address.

The broadcast address is the all-ones address, ff:ff:ff:ff:ff:ff, which is the group bit set with every other bit set. It reaches every station on the broadcast domain, which is every port of every switch in the same VLAN, and it is not forwarded by routers. The size of that domain is what makes broadcast a scaling concern rather than a convenience.

Group addresses and the mapping problem

A station that wants to receive multicast traffic must be told which group addresses matter to it. The mechanism is a filter table: the NIC holds a list of accepted group addresses, and an arriving frame whose destination is not in the list is dropped without the host ever knowing it existed. The list is small, historically as few as a handful of entries, because the comparison is done in the receive path at wire speed.

The small table creates a problem. A host that joins many multicast groups, as a router or a monitoring appliance does, cannot fit them all. The standard solution is a hash filter: the NIC computes a hash of the destination address, uses a few bits of it as an index into a bitmask, and accepts the frame if that bit is set. The hash collisions mean the host receives frames for groups it never joined, and the driver must discard them in software after inspecting the address. This is why a host in hash-filter mode can see a noticeable rate of frames that no socket asked for. The exact hash function is vendor-specific; the behaviour, that false positives are expected and must be filtered above the NIC, is not.

Two group addresses deserve special handling. 01:80:c2:00:00:00 through 01:80:c2:00:00:0f are reserved link-local addresses for protocols that must not be forwarded by bridges, including spanning tree BPDUs. 33:33:... addresses are the IPv6 multicast mapping: the low 32 bits of the IPv6 group address are placed in the low 32 bits of the MAC address, with 33:33 as the prefix. IPv4 uses 01:00:5e followed by 23 bits taken from the low 23 bits of the group address, which discards 5 bits of the IPv4 address and therefore maps 32 distinct IPv4 groups onto each MAC group. A host that joins one IPv4 group may therefore receive traffic for up to 31 others, and must filter by the IP destination.

Receive filter modes in order of increasing cost

A NIC’s receive path can be in one of several modes, and the mode determines what reaches the host:

Mode	Accepts
Unicast only	Frames matching the station’s own address, plus broadcast if enabled
Multicast filter	The above plus addresses in the group table or hash
All-multicast	Every frame whose group bit is set
Promiscuous	Every frame on the segment, regardless of destination

Promiscuous mode is what a packet capture tool needs, and it is also what a software bridge needs: a bridge port that must forward frames for arbitrary destinations cannot filter by destination address, because the decision depends on a table the NIC does not have. The cost is that every frame on the link crosses the bus into host memory, which is why a busy capture host drops frames and why capture tools report a drop count separately from a capture count.

A related mode exists on some hardware for the opposite reason: a filter that accepts only frames whose destination matches a list of addresses, used to steer traffic for several virtual machines or several VLANs to separate receive queues. The receive side scaling machinery behind this is described in the network interface receive path.

Addresses as identifiers for more than delivery

Because the address is stable for the lifetime of the interface, it is used as an identifier in places where the protocol only needs a name. DHCP keys leases on it. Switches learn forwarding tables from it. Hypervisors derive virtual interface identity from it. The reuse is convenient and it is also the reason a changed address breaks more than delivery: a station that changes its MAC address loses its DHCP lease binding, its switch table entry, and any firewall rule written against the old value.

The address is not a secret and it is not authenticated. It appears in every frame a station sends, so anyone on the segment can observe it. Modern privacy practice therefore separates the stable identifier from the transmitted address: IPv6 temporary addresses and randomized addresses for wireless clients both exist because a fixed 48-bit value transmitted continuously is a tracking handle. That is a property of the address’s role as an identifier, not of its role in delivery, and it is why randomization is applied at the point where the address is assigned rather than in the frame format.

Delivery itself rests on the comparison the NIC performs, and that comparison assumes the frame arrived intact. The check that a frame was not corrupted in transit is the trailer’s checksum, which is covered in the frame check sequence, and the way a switch builds forwarding state from observed source addresses is covered in MAC learning and bridge forwarding tables.