Multicast

Reading time: 6 minute Word count: 2562

Network Multicast IP IGMP MLD Routing IPv6

When the same data has to go to many receivers, there are usually only two extremes: send a separate copy to each one, or broadcast it to the whole network. The first is simple, but once the number of receivers grows, the sender and the network get buried under duplicate traffic. The second looks convenient, but it also disturbs devices that should never have received that data in the first place. Live video, market data distribution, service discovery, routing neighbor announcements, and many local-link control messages all need something different from either extreme.

Multicast solves exactly this kind of problem. It is not a stronger version of broadcast, and it is not the sender secretly cloning one unicast stream many times. Instead, it makes “who wants to receive this traffic” visible to the network, then lets replication happen only at the right branches.

The core of multicast is not “one packet sent to many people.”
It is that receivers first declare membership in a group, and the network then replicates traffic only where the actual group distribution requires it.

Why It Appeared

Without multicast, one-to-many delivery usually falls into one of two patterns:

The sender makes a unicast copy for each receiver
The sender broadcasts on the local link or over a wider scope

Both approaches have clear limits.

The problem with unicast replication is:

The more receivers there are, the more packets the sender must transmit
The front half of the path carries the same content over and over again
A path that could have been shared gets duplicated many times for no reason

The problem with broadcast is:

It defaults to disturbing the entire broadcast domain
Devices that do not care about the data still have to receive it before discarding it
Its boundary is naturally limited to the local link and cannot serve as a universal cross-network delivery model

The real engineering need is usually not “everyone must receive it,” but “only the receivers subscribed to this kind of content should get it.” That is where multicast matters: it tries to make the network distribute content only to receivers that actually exist, instead of forcing the sender and the whole network to pay for blind fan-out.

Who Built It, and in What Context

Multicast comes from the Internet protocol stack’s long response to the one-to-many delivery problem. It is not about point-to-point communication. It addresses a different and always-present reality:

Some traffic is the same content sent to multiple receivers
The receiver set changes over time, so hand-maintaining a full list is impractical
The network wants to carry only one copy on shared paths, then replicate at the branches

That gives multicast a very different feel from unicast:

An address can represent a group, not just a host
The sender does not need to know all receivers in advance
The network cannot rely on ordinary destination-only forwarding; it also needs group membership and distribution tree state
“Who wants to receive” and “where to replicate traffic” become explicit protocol concerns

So multicast looks like IP gained another address type, but in practice it also brings membership discovery, forwarding replication, and scope boundaries into the model.

The Main Model

To understand multicast, keep four things in mind:

One group address represents a set of potential receivers, not one host
Receivers must first declare, “I want this group”
The network only sends traffic down branches that actually have members
Replication usually happens at network branch points, not by having the source duplicate everything from the start

The main path looks like this:

Receiver joins the group
  -> The local network learns that someone here wants this group
  -> The router builds an upstream receiving branch for this group
  -> Sender transmits to the group address
  -> The network replicates traffic at the necessary branch points according to the group distribution tree
  -> Only branches with members continue to receive the traffic

Once this path is clear, IGMP, MLD, group addresses, forwarding trees, and routing protocols become much easier to place.

The Most Common Main Path

A typical reception and distribution flow looks like this:

sequenceDiagram participant R1 as Receiver 1 participant R2 as Receiver 2 participant ER as Access Router participant CR as Upstream Router participant S as Sender R1->>ER: Join Group G R2->>ER: Join Group G ER->>CR: Build upstream receiving branch for Group G S->>CR: Send Packet(dst=Group G) CR->>ER: Forward one copy for Group G ER->>R1: Deliver ER->>R2: Deliver

The key point is not “the packet eventually reached two receivers.” The important part is where replication happened:

The sender did not make one copy per receiver
The shared upstream path carried only one copy
Replication happened only where the path had to branch
Branches with no members did not keep receiving the traffic

That is the main source of multicast’s benefit over unicast replication.

Why It Is Not Broadcast

Multicast is often misunderstood as “just a more advanced broadcast.” That leads the rest of the model astray.

The difference is not that both can reach many receivers. The difference is the default delivery boundary:

Broadcast targets the entire broadcast domain by default
Multicast targets only receivers that have declared membership in the group

Broadcast asks:

“Everyone in this scope receives it first, and only the interested ones keep it”

Multicast asks:

“Where are the receivers for this group right now, and only send there”

So they do not solve the same problem. Broadcast is a coarse local-link flooding mechanism. Multicast is content distribution based on receiver membership.

Why a Group Address Changes the Meaning of Addressing

The intuition for a unicast address is simple: the destination address roughly identifies one endpoint. A multicast address is different. It does not say “where this host is.” It says “who should receive this content as part of the group.”

That changes a lot of engineering decisions:

The sender does not necessarily know which receivers exist individually
Receivers can join or leave the same group at any time
Group membership across subnets can change
The network must continuously know where this group currently has members

That is why a normal routing table is not enough to support full multicast behavior. The network also needs membership information and group-oriented forwarding state.

Why Receiver Join Cannot Be Skipped

The most important prerequisite for multicast is not sending. It is the receiver declaring which group it wants. Without that step, the network cannot tell whether:

Someone on this link really wants the traffic
Or someone is merely sending it, while nobody cares

In IPv4, hosts usually express group membership to the local router with IGMP. In IPv6, the equivalent is MLD. Their job is not to carry business data. They solve a more basic problem:

Which groups currently have members on this local link

That may look like a control-plane detail, but it decides whether the data plane can converge correctly:

If nobody joined, the traffic should not be pulled onto this link
If someone left, the old branch should not keep carrying useless traffic for long

So the value of IGMP/MLD is not “another packet type.” It is that they make receiver demand explicit.

Why the Hard Part Is Teaching the Network Where to Replicate

A local group join only solves “someone on this link wants it.” The bigger problem is how the upstream network learns which paths should carry the traffic.

At that point, the network no longer maintains ordinary unicast state like “what is the next hop for this destination prefix?” It needs another kind of state:

Which direction the group traffic comes from
Which downstream interfaces have receivers
Where traffic should be replicated at branch points

That naturally grows into a tree-shaped forwarding model:

Shared paths closer to the source carry only one copy whenever possible
Replication happens at branch points for different downstream paths
Branches with no members are pruned away in time

That is also why multicast often appears together with routing mechanisms such as PIM. Without that control plane, the network has a hard time turning “somewhere in the network there are receivers for this group” into stable data-plane behavior.

Why the Ideal Path and the Field Path Can Be Very Different

The model looks elegant:

Receivers join first
The network builds a tree
The sender emits one copy
The network replicates according to membership branches

But in real networks, multicast is much more fragile than the model suggests. Common failures come from several places:

Whether layer-2 switches correctly learn and constrain multicast flooding
Whether the access router correctly maintains IGMP/MLD membership state
Whether upstream routing for the group is actually enabled and converged
Whether intermediate devices rate-limit, filter, or default-disable multicast

So the protocol path and the field path have to be read separately:

A protocol can be valid even if the default network equipment refuses to forward it
Seeing group-address traffic on the local link does not mean cross-subnet multicast works
A host joining the group does not mean the upstream tree has already been built correctly

Multicast is not a “configure the group address and you are done” feature. It asks a lot more from switches, routers, and boundary policies.

Why It Usually Does Not Promise Reliability or Ordering

Multicast is about efficient one-to-many delivery, not end-to-end reliable transport. Many multicast applications sit directly on UDP because the first goal is simply:

Deliver one copy of the same content efficiently to many receivers

not:

Maintain per-receiver acknowledgments, retransmissions, and strict ordering

Once you add independent acknowledgment and retransmission for each receiver, multicast’s shared-path advantage disappears quickly:

Who missed it needs a repair
Should the repair still use multicast
Will receiver differences drag the sender back into per-recipient state management

That is why real systems often do this:

Use multicast for real-time content distribution where “deliver efficiently” is the main goal
Handle reliability, error correction, retransmission, or补 data in another layer

That is not a flaw. It is a narrow responsibility boundary.

Why IPv6 Makes It Feel Closer to a Built-In Capability

In IPv4, multicast often feels like an advanced feature used only for special workloads. In IPv6, that intuition becomes less accurate, because IPv6 builds much of its local control and discovery behavior around multicast itself.

That changes at least two judgments:

Multicast is no longer just a phrase for audio/video distribution
It is also a common way the protocol stack organizes its control plane

For example, IPv6 neighbor discovery and a number of control messages clearly depend more on multicast than on broadcast. That is why understanding multicast is not just about large-scale distribution workloads. It is also about understanding how modern networks reduce blind flooding in their control messages.

What to Look at in a Capture

When you capture multicast traffic, do not start by diving into every group address and control packet detail. A more useful order is usually the following.

First check whether this is really the kind of traffic you think it is

Separate these questions:

Is this layer-2 multicast or layer-3 IP multicast
Is this business data or membership control traffic such as IGMP/MLD
Is this a local-link behavior or a cross-router multicast forwarding problem

If you answer that first, you can then tell whether you are debugging member declaration, switch flooding, or an upstream tree that never formed.

Then check whether receivers actually joined the group

Many “I sent it but did not receive it” cases should not start by suspecting the sender. First confirm:

Did the receiving host send a join request for the group
Did the access router see and maintain that membership state

If that does not hold, there is usually little point in discussing cross-network forwarding.

Finally see whether the traffic stopped locally, upstream, or because of bad flooding

Common symptoms usually fall into these buckets:

Nobody joined locally, so the traffic was never pulled down
The host joined, but the access device did not forward it correctly to the local port
The local link is fine, but the upstream network never built forwarding state for the group
The device cannot constrain multicast precisely, so it degrades into near-flooding

The hard part of multicast is often not a single field. It is first deciding which layer boundary the problem belongs to.

What Engineers Should Actually Think About Multicast

Do not treat multicast as a synonym for broadcast. Its prerequisite is that receivers first declare group membership
Do not treat a group address as “another kind of host address.” It represents a receiving set, not a single endpoint
Do not only watch whether the sender transmitted. First check whether the receiver joined and whether the local router learned the membership state
Do not assume that receiving multicast on the local link means it will also work across subnets. The real hard part is the network-wide forwarding tree and device coordination
Do not assume multicast includes reliability, ordering, and retransmission by default. Those are usually still the responsibility of upper layers
Do not underestimate the engineering cost. Many networks do not avoid multicast because it is impossible in theory, but because default settings, device capability, and debugging complexity keep it from being the common default