How Multicast MAC Addresses Are Mapped
For IP multicast to cross Ethernet it has to map onto a layer 2 multicast address, otherwise a switch has no idea what to do with it. The mapping is a fixed algorithm requiring no negotiation, and knowing it explains a lot of odd-looking addresses in captures.
Recognising multicast
If the least significant bit of the first byte is one, the address is multicast. In hex, just check whether the first byte is odd or even. The full meaning of the flag bits is in reading the first byte of a MAC address.
IPv4 mapping: the 01:00:5E range
IPv4 multicast occupies 224.0.0.0/4. The rule is:
- The first 25 bits are fixed as
01:00:5Eplus a zero bit - The remaining 23 bits are copied from the low 23 bits of the IPv4 multicast address
So 224.0.0.1, all hosts, maps to 01:00:5E:00:00:01. 239.255.255.250, used by SSDP, maps to 01:00:5E:7F:FF:FA.
There is a flaw worth knowing about. An IPv4 multicast address has 28 variable bits, but only 23 make it into the MAC address, so five bits of information are discarded. As a result 32 different IPv4 multicast groups share one MAC address. 224.1.1.1 and 225.1.1.1 have identical low 23 bits and therefore identical layer 2 addresses.
In practice an adapter receives multicast frames it never subscribed to, and the kernel filters them out at layer 3. At low volumes this does not matter; on a multicast-heavy network it produces a noticeable load of pointless interrupts.
IPv6 mapping: the 33:33 range
IPv6 multicast addresses start with ff00::/8 and the rule is simpler:
- The first 16 bits are fixed as
33:33 - The remaining 32 bits are copied from the last 32 bits of the IPv6 address
For example ff02::1, all link-local nodes, maps to 33:33:00:00:00:01.
IPv6 preserves 32 bits, so overlap is far less likely than with IPv4, though still not one to one. The 33:33 prefix is generally said to derive from Xerox's street number in Palo Alto.
Common fixed multicast addresses
| MAC address | Purpose |
|---|---|
01:00:5E:00:00:01 | IPv4 all hosts (224.0.0.1) |
01:00:5E:00:00:02 | IPv4 all routers (224.0.0.2) |
33:33:00:00:00:01 | IPv6 all nodes (ff02::1) |
33:33:00:00:00:02 | IPv6 all routers (ff02::2) |
01:80:C2:00:00:00 | Spanning tree BPDUs |
01:80:C2:00:00:0E | LLDP neighbour discovery |
01:1B:19:00:00:00 | PTP precision time protocol |
There is no point looking up a frame starting with 01:80:C2 on the lookup page; that range is reserved by the IEEE for bridging protocols.
Broadcast is a special case of multicast, and the reserved addresses around it are listed in broadcast and other reserved MAC addresses.
IGMP snooping: keeping multicast from becoming broadcast
By default a switch treats multicast frames like broadcast and floods them to every port in the VLAN. On a network carrying IPTV or video surveillance, that makes every port absorb the multicast load.
IGMP snooping lets the switch peek at IGMP join and leave messages and forward only to ports that actually subscribed to the group. It is essential configuration wherever multicast services are deployed, and MLD snooping is the IPv6 equivalent.
One exception is worth remembering: addresses within 224.0.0.0/24, which map to 01:00:5E:00:00:xx, are link-local control traffic. IGMP snooping normally does not constrain them and they are always flooded.