Multicast IP Addresses Explained

A Raspberry Pi could stream the World Cup to a million viewers. Not because it has exceptional hardware, but because with multicast, it only sends the stream once. The network handles the rest.

This is the insight that makes multicast profound: the sender's burden doesn't scale with the audience. Send to ten, send to ten thousand—same work, same bandwidth, same server load. The network itself becomes intelligent, replicating data only where watchers wait.

What Is Multicast?

Multicast is one-to-many communication where a single sender transmits to multiple receivers simultaneously. The sender dispatches one stream to a special multicast group address. Network devices replicate and forward this stream only to segments where interested receivers exist.

Think of it like a radio broadcast: the station transmits once, and anyone tuned to that frequency receives the signal. But unlike radio, multicast receivers must explicitly subscribe by joining the group.

No subscription, no stream. This prevents the network from drowning in unwanted traffic.

Unicast, Broadcast, and Multicast

To understand what multicast solves, compare it to its siblings:

Unicast is a conversation between two parties. One sender, one receiver. This is how you load a web page or send an email. It's efficient for one-on-one communication but wasteful when many recipients need identical data. Streaming a 5 Mbps video to 200 viewers via unicast requires 1,000 Mbps—200 separate streams.

Broadcast transmits to every device on the network segment, whether they want it or not. Useful for discovery protocols ("Who has this IP address?"), but impractical for content delivery. Every device must process the traffic, even if it's irrelevant to them.

Multicast strikes the balance: one stream reaches multiple interested recipients without burdening uninterested devices. That same 5 Mbps video to 200 viewers? Still 5 Mbps. The efficiency isn't linear—it's constant.

The Address Space

IPv4 Multicast

IPv4 reserves 224.0.0.0 through 239.255.255.255 for multicast—the entire "Class D" range. Not all of it is equal:

224.0.0.0 to 224.0.0.255 stays local. Routers never forward these addresses beyond your subnet. This is where you find the fundamental group addresses:

• 224.0.0.1 — All multicast-capable hosts on the local segment
• 224.0.0.2 — All multicast routers on the local segment
• 224.0.0.251 — Multicast DNS for local service discovery

239.0.0.0/8 is for private organizational use, similar to how 10.0.0.0/8 works for unicast. Your company can use these addresses internally without coordination.

IPv6 Multicast

IPv6 takes a cleaner approach: any address starting with ff is multicast. The next nibble encodes scope—how far the multicast should propagate:

• ff01:: — Node-local (stays within a single device)
• ff02:: — Link-local (your network segment)
• ff05:: — Site-local (a campus or building)
• ff08:: — Organization-local
• ff0e:: — Global

So ff02::1 means "all nodes on the local link," while ff0e::1 would mean "all nodes globally." Same group identifier, different reach.

IPv6 also introduces solicited-node addresses—a clever trick where the multicast group is derived from a device's unicast address. This creates groups with very few members (often just one), enabling efficient address resolution without broadcast storms.

How Devices Join Groups: IGMP

Multicast has a chicken-and-egg problem: how does the network know where to send streams if it doesn't know who wants them?

The Internet Group Management Protocol (IGMP) solves this for IPv4. It's how hosts tell routers "I want to receive this group" and how routers discover which groups have interested members.

The dance works like this:

1. A device wants to receive a multicast stream, so it sends a membership report to join the group
2. Routers periodically query the network: "Who's still interested in what?"
3. Hosts respond with reports for the groups they've joined
4. When a device stops caring, it sends a leave message
5. The router checks if anyone else still wants the stream before stopping delivery

Three versions exist, each adding capability:

IGMPv1 introduced the basic query-response model.

IGMPv2 added explicit leave messages, so routers stop delivering unwanted streams faster.

IGMPv3 brought source filtering—hosts can specify not just which group they want, but which sources within that group they'll accept. This matters when multiple servers stream to the same group address.

IPv6 uses Multicast Listener Discovery (MLD) instead of IGMP. Same concept, different protocol, built into ICMPv6.

The Switch Problem: IGMP Snooping

Here's a wrinkle: switches operate at layer 2 (Ethernet frames), while IGMP is a layer 3 (IP) protocol. A switch that doesn't understand IGMP sees multicast traffic and thinks "I don't know who wants this, so I'll send it everywhere." Your carefully optimized multicast becomes a broadcast.

IGMP snooping fixes this. The switch eavesdrops on IGMP messages passing through and builds a table: "Port 5 wants group 239.1.1.1. Port 12 wants group 239.1.1.2." Now it can forward multicast intelligently.

Without snooping, your switch is a broadcast relay. With it, the switch becomes complicit in the efficiency.

Where Multicast Shines

IPTV and live streaming is the canonical use case. Hotels, hospitals, universities, and enterprises deliver television channels via multicast. The source server doesn't care if ten people watch or ten thousand—same load either way.

Financial data feeds use multicast to blast real-time stock prices, order books, and trading data to thousands of terminals simultaneously. When milliseconds matter, multicast's efficiency and consistent delivery order are essential.

Software distribution in large organizations pushes updates to thousands of computers at once. Instead of crushing the server with individual downloads, one stream reaches everyone.

Video conferencing systems use multicast for internal meetings, letting high-quality video reach dozens of participants without multiplying bandwidth.

Gaming servers send game state updates to all players simultaneously, keeping everyone's view of the world synchronized.

The Tradeoffs

Multicast demands simultaneity. Everyone receives the same moment at the same time. You can't pause. You can't rewind. You can't start from the beginning while someone else watches the end. This isn't a bug—it's the fundamental constraint that makes the efficiency possible.

Multicast also requires cooperation from every device in the path. Your home router probably supports it. Your ISP almost certainly doesn't route it across the public Internet—the routing complexity makes it impractical at Internet scale. Most multicast lives within organizational boundaries: corporate networks, campuses, data centers.

For Internet-scale delivery, content delivery networks (CDNs) achieve similar efficiency through caching and geographic distribution, but with the flexibility of on-demand playback. Multicast trades that flexibility for something CDNs can't offer: true simultaneity, where a million viewers share exactly the same moment.