Every multicast design decision starts with an address. Which range you pick determines whether routers forward the traffic at all, whether you need an RP, whether it can leave your organization, and even how it collides at layer 2. This article maps the entire 224.0.0.0/4 space, explains the IP-to-MAC mapping (and the 32:1 overlap it creates), and covers scoping. It is part of the IP multicast guide.
Class D: The 224.0.0.0/4 Space
Multicast owns 224.0.0.0 through 239.255.255.255: the old class D, or 224.0.0.0/4 in modern notation. The first four bits of the first octet are fixed at 1110, leaving 28 bits of group space, roughly 268 million possible groups. Group addresses appear only as destinations. If you ever see one as a source address in a capture, something is forging packets.
Within that /4, specific ranges carry very different rules:
The Well-Known Addresses Worth Memorizing
The local control block is where you meet multicast daily, even in unicast-only networks. These are the ones that show up in captures and exams:
IP-to-MAC Mapping: 01:00:5e and the Missing Bit
Ethernet needs a destination MAC, but no host owns a multicast group, so the MAC is derived from the group address. The rule: start with the fixed OUI prefix 01:00:5e, force the next bit to 0, then copy the low 23 bits of the IP group address into the low 23 bits of the MAC.
Work through 239.1.1.10. The low 23 bits cover the last two octets fully (1.10) and the low 7 bits of the second octet (1). Result: 01:00:5e:01:01:0a. You can see the real thing on the lab's Debian receiver after it joined the group:
j@llmbits:~$ ip maddr show ens224
3: ens224
link 01:00:5e:01:01:0a users 2
inet 239.1.1.10
inet 232.1.1.10Notice users 2: both 239.1.1.10 and 232.1.1.10 map to the same MAC, because their low 23 bits are identical. That is the design flaw in action.
The 32:1 Overlap Problem
An IPv4 group has 28 significant bits; the MAC mapping preserves only 23. Five bits are simply lost, which means exactly 32 different group addresses share every multicast MAC. 224.1.1.10, 225.1.1.10, 239.1.1.10, and 29 others all become 01:00:5e:01:01:0a.
The practical consequence: a switch (or a host NIC filtering in hardware) cannot distinguish those 32 groups. A host subscribed to 239.1.1.10 will also receive frames for 224.129.1.10 at layer 2 and must discard them in software. On busy networks this matters for both performance and isolation, and the fix is planning: keep the low 23 bits unique across the groups you deploy, and avoid x.0.0.y and x.128.0.y groups entirely since they collide with the 224.0.0.0/24 control block MACs that switches flood.
Why only 23 bits? History: when the mapping was defined, buying 16 OUI blocks to cover all 28 bits cost more money than the designers had. Half an OUI was available, so the standard shipped with 23 bits and the overlap became permanent trivia.
Scoping: Keeping Groups Where They Belong
Two mechanisms constrain how far multicast travels. TTL scoping is the legacy approach: senders set a small TTL and packets die at distance. It is fragile (TTL also decrements per hop for normal reasons) and has been superseded by administrative scoping: dedicated ranges with configured boundaries.
Within 239/8, convention splits the space further: 239.255.0.0/16 for site-local groups, 239.192.0.0/14 for organization-local. The enforcement tool on IOS XE is a multicast boundary ACL on the edge interface:
ip access-list standard MCAST-SCOPE
deny 239.0.0.0 0.255.255.255
permit 224.0.0.0 15.255.255.255
!
interface GigabitEthernet0/0/1
ip multicast boundary MCAST-SCOPEThat drops organization-local groups in both directions at the border while letting legitimately routable ranges through. Every edge interface facing a partner, provider, or the internet should carry one.
Working the Mapping Both Directions
Interviews and exams love the reverse question: given MAC 01:00:5e:01:01:0a, what groups could have produced it? Take the low 23 bits: 01:01:0a with the top bit of the first of those octets already 0, so the group ends in x.1.1.10 where x has its low 7 bits free in the second octet. The candidates are every combination of the 4 lost class D prefix bits and the 1 lost high bit of the second octet: 224.1.1.10, 224.129.1.10, 225.1.1.10, 225.129.1.10, up through 239.129.1.10. Thirty-two possibilities, and nothing at layer 2 can tell them apart.
Going forward is mechanical once you internalize which bits survive: the second octet contributes only its low 7 bits (so 0-127 and 128-255 alias in pairs), and the third and fourth octets copy through whole. 239.130.44.7 therefore becomes 01:00:5e:02:2c:07 (130 minus 128 = 2), colliding with 239.2.44.7. If you allocate groups by keeping octets two through four unique below 128, the overlap problem disappears from your network entirely.
IPv6 Multicast: The Same Ideas, Cleaner
IPv6 fixes most of this by design, and the contrast is instructive (the full story is in the IPv6 guide). All IPv6 multicast lives under ff00::/8, and the second octet encodes flags and an explicit scope nibble: ff02:: is link-local, ff05:: site-local, ff0e:: global. Scoping is part of the address instead of a boundary ACL convention, so a link-scoped group physically cannot be routed off-segment. The well-known groups mirror IPv4's: ff02::1 is all nodes (224.0.0.1), ff02::2 all routers, ff02::5 and ff02::6 OSPFv3, ff02::d PIM, and ff02::1:ff00:0/104 hosts the solicited-node groups that replace ARP broadcasts entirely.
The MAC mapping also loses its overlap problem in practice: IPv6 maps the low 32 bits of the group into 33:33:xx:xx:xx:xx, and since group IDs are conventionally allocated within those 32 bits, collisions are rare rather than structural. There is no broadcast in IPv6 at all; multicast does that job, which is why understanding these ranges stopped being optional the day you enabled dual stack. MLD replaces IGMP as the membership protocol (MLDv2 corresponds to IGMPv3, source filters included), and PIM carries over unchanged.
Choosing Addresses for a New Deployment
A simple decision path covers nearly every enterprise case. Internal-only application: allocate from 239/8, document the assignment, and keep low-23-bit uniqueness. One-to-many stream where receivers can learn the source (IPTV, market data): use 232/8 with SSM and skip RP design entirely. Public interdomain multicast (rare): GLOP from 233/8 or unicast-prefix-based from 234/8. And never invent groups inside 224.0.0.0/24 or 224.0.1.0/24; those belong to protocols.
Key Takeaways
- Multicast lives in 224.0.0.0/4. The subranges carry the rules: 224.0.0.0/24 never routes, 232/8 is SSM, 239/8 is private and must be filtered at borders.
- 224.0.0.5, .6, .10, .13, .18, .22, and .251 are the well-known addresses you will see in real captures; recognize them instantly.
- The MAC mapping is 01:00:5e plus the low 23 bits of the group. Five IP bits are lost, so 32 groups share each MAC and hosts filter the excess in software.
- Plan group assignments for low-23-bit uniqueness and avoid anything colliding with the control block MACs.
- Scope with
ip multicast boundaryand administrative ranges, not TTL tricks.
Continue with IGMP explained: v2 vs v3, or return to the complete multicast guide for the full cluster.
