Which destination MAC does Ethernet use for IPv4 broadcast, IPv4 multicast and IPv6 multicast packets, and why can several groups share one MAC?

## Group traffic needs no lookup For a unicast packet a host normally discovers the next hop's MAC address with a resolution protocol. For broadcast and multicast it does not: the destination MAC is **computed** from the destination IP address. The result is always a **group address**, one whose first octet has its lowest bit (the I/G or group bit) set, so a frame for it can reach many interfaces at once. | Packet | Destination MAC | Rule | |---|---|---| | IPv4 broadcast | `ff-ff-ff-ff-ff-ff` | all ones (RFC 894) | | IPv4 multicast | `01-00-5E` + low 23 bits of the group | RFC 1112 | | IPv6 multicast | `33-33` + last 32 bits of the group | RFC 2464 | | IPv6 broadcast | none | IPv6 has no broadcast (RFC 4291) | ## IPv4 broadcast RFC 894 says the IPv4 broadcast address, "the address on that network with a host part of all binary ones", is mapped to the Ethernet broadcast address of all ones. The limited broadcast 255.255.255.255 uses the same frame address. Every station on the segment accepts the frame and hands it to its IP layer. ## IPv4 multicast: 01-00-5E plus 23 bits IANA holds OUI `00-00-5E`; setting the group bit gives `01-00-5E`. RFC 9542's table allots only the lower half of that range, `01-00-5E-00-00-00` to `01-00-5E-7F-FF-FF` (2 to the 23rd addresses), to IPv4 multicast, so the 24th bit is always 0 and only 23 bits are left for the group. A worked example with the documentation group 233.252.0.1: 1. Write the group in hex: 233.252.0.1 is `E9.FC.00.01`. 2. Drop everything above the low 23 bits: the first octet goes entirely, and the top bit of the second octet goes too, so `FC` becomes `7C`. 3. Place the remainder under the prefix: `01-00-5E-7C-00-01`. IPv4 multicast addresses are 224.0.0.0/4, so a group address has **28 significant bits**. Only 23 survive, which means 2 to the 5th, **32 groups**, share each MAC. 224.252.0.1 and 239.124.0.1 both produce `01-00-5E-7C-00-01` as well: their second octets, `FC` and `7C`, differ only in the dropped top bit. RFC 1112 states it directly: "more than one host group address may map to the same Ethernet multicast address." ## IPv6 multicast: 33-33 plus 32 bits RFC 2464 sends an IPv6 multicast packet to an Ethernet address whose first two octets are `33-33` and whose last four octets are the last four octets of the group address. - `ff02::1`, all nodes on the link, becomes `33-33-00-00-00-01`. - `ff02::2`, all routers, becomes `33-33-00-00-00-02`. - The groups Neighbor Discovery uses for address resolution follow the same rule, which is why their frames start `33-33-ff`. The first octet `0x33` has both the group bit and the local bit set; RFC 9542 notes this and says these addresses fall in the locally administered space. Only 32 of the 128 bits survive, so here too many groups share each MAC. ## Who filters the extra frames Because the mapping is lossy, filtering happens in two stages: - The **network interface** accepts frames whose destination is its own unicast address, broadcast, or a group MAC the host has asked it to listen to. Some interfaces use a coarse hardware filter and accept even more, an implementation choice. - The **IP layer** checks the full destination address against the groups the host has joined and silently discards datagrams for any other group that happened to share the MAC. The cost of a collision is work, not wrong delivery: a host that joined 239.124.0.1 also receives every frame for 224.252.0.1 and throws those datagrams away in software. On a segment carrying heavy multicast streams, picking group addresses whose low 23 bits differ keeps that waste off every listener's CPU, which is why a multicast address plan checks the mapped MACs and not just the IP groups. Whether a switch sends a multicast frame out of every port or only towards listeners is a switching question, not part of the address format. ## Mistakes interviewers listen for - Sending IPv6 "broadcast" to `ff-ff-ff-ff-ff-ff`; IPv6 uses multicast groups instead. - Copying the whole IPv4 group into the MAC, or keeping 24 bits instead of 23. - Assuming one MAC means one group, so the IP layer need not check. - Thinking a multicast destination needs an ARP lookup first.