IP Multicast

Why multicast matters

Imagine a live channel with one million simultaneous viewers. With unicast, the source opens one million independent flows and pushes one million identical copies of every packet into the network — its uplink must carry a million times the stream bitrate, and it melts. With broadcast, you would blast every host on a subnet, including the ones who do not care, and it would not even cross a router. Multicast is the escape hatch: the source emits one copy addressed to a group, and the network itself performs the fan-out, duplicating a packet at a router only at the exact point where two downstream paths split.

The payoff is that source cost is O(1) in the number of receivers. Adding the millionth receiver adds zero load at the source and adds one copy on exactly the last link that receiver hangs off. This is why the model is a natural fit for anything that is genuinely one-to-many with identical content: broadcast TV over IP (IPTV), stock-exchange market-data feeds where every trading firm needs the same tick stream with minimal skew, software and OS image distribution, and low-level LAN service discovery (mDNS, SSDP, OSPF/EIGRP hellos).

How multicast works, step by step

Multicast splits cleanly into two problems: who wants the data (membership, solved at the last hop by IGMP) and how the data gets there (routing, solved between routers by PIM). A group is named purely by its address — there is no list of members anywhere; membership is soft state discovered hop by hop.

1. A receiver joins. An application on a host asks to receive group G (e.g. 239.1.1.7). The host's stack sends an IGMP Membership Report to its first-hop router: "I want G."
2. The last-hop router signals upstream. The router now has a member, so it sends a PIM Join toward the source (or toward the Rendezvous Point in Sparse Mode). Each router along the way installs forwarding state for (S, G) or (*, G) and, if it did not already have the group, forwards its own Join one hop closer.
3. A distribution tree forms. These Joins graft new branches onto a tree rooted at the source (or RP). The tree is loop-free by construction because each router only accepts the group from its upstream neighbor on the shortest reverse path.
4. Packets flow down and replicate. The source sends one packet to G. At every router it hits the RPF check: did this arrive on the interface I would use to reach the source? If yes, it is copied out every interface in the outgoing interface list (OIL) — one copy per downstream branch, and only where branches diverge.
5. Receivers leave; branches prune. When the last member on a subnet leaves (IGMP Leave, confirmed by a Group-Specific Query), the last-hop router sends a PIM Prune upstream. Routers that lose their last downstream branch prune themselves in turn, so the tree contracts to exactly the live receivers.

Reverse-Path Forwarding: why the tree can't loop

The single most important invariant in multicast forwarding is RPF. Naively forwarding a packet "out every interface except the one it came in on" would create broadcast storms — copies would circle back and multiply. RPF fixes this with one rule: a router accepts a multicast packet only if it arrived on the interface that the unicast routing table would use to send a packet back toward the source. That interface is the RPF interface; the neighbor on it is the RPF neighbor.

Because a packet is accepted from exactly one direction — the shortest reverse path to the source — any duplicate that loops around and re-arrives on a different interface fails the check and is dropped. The union of all accepted paths is therefore a tree (loop-free) that mirrors the shortest-path tree the unicast routing already computed. This is also why PIM is protocol independent: it never computes routes itself; it borrows whatever the unicast table (OSPF, IS-IS, BGP) already contains for the RPF lookup.

Multicast vs unicast vs broadcast vs anycast

	Unicast	Broadcast	Multicast	Anycast
Receivers	Exactly one specific host	Every host on the subnet	All hosts that joined the group	Nearest one of several sharing an address
Source cost for N receivers	O(N) streams	O(1), but subnet-local	O(1) streams	O(1) — one receiver
Crosses routers?	Yes	No (subnet only)	Yes (with PIM)	Yes (routed)
Address type	Host address	255.255.255.255 / subnet bcast	224.0.0.0/4 group	Ordinary unicast address, advertised from many places
Membership	N/A	Implicit (everyone)	Explicit (IGMP join)	N/A (routing picks)
Typical transport	TCP or UDP	UDP	UDP only (no per-receiver ACK)	TCP or UDP
Canonical use	Web, SSH, most traffic	ARP, DHCP discovery	IPTV, market data, discovery	DNS root servers, CDN edges

Note the transport row: multicast is essentially always carried over UDP. There is no per-receiver acknowledgement, because a source has no idea who — or how many — are listening; reliability, if needed, is layered on top (NACK-based schemes like PGM/NORM, or FEC). See UDP and anycast for the contrasting models.

Group addressing: the 224.0.0.0/4 map

Every IPv4 multicast address begins with the four bits 1110, which is why the block is 224.0.0.0/4. Within it, scope matters more than the number:

• 224.0.0.0/24 — link-local. Never forwarded by routers (TTL is irrelevant; routers simply do not forward this range). Reserved for control: 224.0.0.1 all systems, 224.0.0.2 all routers, 224.0.0.5/.6 OSPF, 224.0.0.13 all PIM routers.
• 224.0.1.0 – 238.255.255.255 — globally scoped. Routable across the internet in principle; includes IANA-assigned blocks like 224.0.1.1 (NTP).
• 239.0.0.0/8 — administratively scoped. The multicast analogue of RFC 1918 private addresses — reused freely inside an organization and filtered at its border. Almost every enterprise/IPTV deployment lives here.

On the wire at layer 2, an IPv4 group maps to a MAC address with the fixed prefix 01:00:5e plus the low 23 bits of the IP address. Since a group has 28 significant bits but only 23 fit, five bits are dropped — so 32 distinct IP groups alias onto one MAC address, a subtle source of unwanted traffic that switches mitigate with IGMP snooping.

PIM: building the tree

PIM comes in flavors that differ in how optimistic they are about where receivers live.

• PIM Dense Mode (PIM-DM) assumes members are everywhere: flood-and-prune. It pushes traffic to the entire network, then prunes branches with no members, re-flooding every few minutes. Simple but wasteful — only for small, dense networks.
• PIM Sparse Mode (PIM-SM) assumes members are rare: nothing flows until a router explicitly Joins toward a Rendezvous Point (RP). Receivers first attach to a shared tree (*, G) rooted at the RP; once data flows, last-hop routers switch over to the source-rooted shortest-path tree (S, G) to cut latency. This is what real deployments run.
• PIM Source-Specific Multicast (PIM-SSM) drops the RP entirely: receivers name both source and group (S, G) up front (via IGMPv3 source filtering), so the shortest-path tree is built immediately. SSM lives in 232.0.0.0/8 and is the simplest, most secure model — no RP to attack, no unknown senders.

Worked example: IGMP membership walk-through (Python)

The code below is a compact, runnable-looking model of the last-hop router's IGMP state machine and the RPF check that governs whether a packet is forwarded. It captures the essential logic — report/leave handling, the query-then-timeout that lets a group expire, and the reverse-path lookup — without the wire-format details.

from dataclasses import dataclass, field

@dataclass
class MulticastRouter:
    # Which interface leads back toward each source (from the unicast table)
    rpf_iface: dict          # source_ip -> interface toward that source
    # Per group: set of downstream interfaces with live members (the OIL)
    oil: dict = field(default_factory=dict)   # group -> set(interfaces)

    def igmp_report(self, group, iface):
        """Host on `iface` says 'I want group G' -> graft this branch."""
        self.oil.setdefault(group, set()).add(iface)

    def igmp_leave(self, group, iface):
        """Host leaves. In real IGMPv2 the router first sends a
        Group-Specific Query; if no report returns before the timeout,
        it prunes the interface. Here we prune immediately."""
        members = self.oil.get(group)
        if members:
            members.discard(iface)
            if not members:           # last member gone -> prune upstream
                del self.oil[group]
                self.send_pim_prune(group)

    def forward(self, packet):
        """Apply the RPF check, then replicate down the tree."""
        rpf = self.rpf_iface.get(packet.src)
        if packet.in_iface != rpf:
            return []                 # failed RPF -> drop (loop prevention)
        outs = self.oil.get(packet.group, set())
        # One copy per downstream branch, never back out the RPF interface
        return [(packet, o) for o in outs if o != packet.in_iface]

    def send_pim_prune(self, group):
        pass  # would signal the upstream RPF neighbor to stop sending G


@dataclass
class Packet:
    src: str
    group: str
    in_iface: str

# --- demo ---
r = MulticastRouter(rpf_iface={"10.0.0.1": "eth0"})
r.igmp_report("239.1.1.7", "eth1")
r.igmp_report("239.1.1.7", "eth2")

good = Packet(src="10.0.0.1", group="239.1.1.7", in_iface="eth0")
bad  = Packet(src="10.0.0.1", group="239.1.1.7", in_iface="eth3")

print(sorted(o for _, o in r.forward(good)))  # ['eth1', 'eth2'] — replicated
print(r.forward(bad))                          # [] — wrong interface, RPF drop

The two invariants to notice: a packet is only ever accepted from its RPF interface (the loop guard), and it is never sent back out the interface it arrived on (split-horizon). Everything else — trees, joins, prunes — is bookkeeping to keep the OIL accurate as members come and go.

Common misconceptions and pitfalls

• "Multicast works across the internet like unicast." It does not, in general. Inter-domain multicast needs MSDP and multicast BGP configured and trusted between ISPs; almost all real multicast is confined to a single administrative domain. The public MBone experiment never scaled.
• "IGMP routes multicast." No — IGMP only manages membership on the last hop between hosts and their router. Routing between routers is PIM's job. Conflating them is the classic exam mistake.
• "A switch keeps multicast off ports that didn't ask." Only if it does IGMP snooping. A dumb L2 switch treats a multicast MAC like a broadcast and floods it to every port, defeating the whole point. And even with snooping, the 32:1 IP-to-MAC aliasing can leak the wrong groups.
• "Multicast is reliable because the tree is built carefully." The tree is reliable; the delivery is best-effort UDP with no ACKs. A dropped packet is simply gone unless an application-layer scheme (NORM, PGM, FEC) recovers it.
• "TTL scoping is a security boundary." TTL limits how far packets travel but is trivially spoofed and is not access control. Real scoping uses the administratively-scoped 239.0.0.0/8 range plus border filtering.

A short history

Steve Deering formalized the host group model in his Stanford PhD work and RFC 1112 (1989), which defined class-D addressing and IGMPv1. The 1990s MBone (Multicast Backbone) stitched multicast islands together with GRE tunnels to carry the first internet-wide audio/video — IETF meetings were multicast live. DVMRP and later PIM provided routing; PIM Sparse Mode (RFC 2362, refreshed as RFC 4601/7761) became the workhorse. IGMPv2 (RFC 2236) added fast leaves; IGMPv3 (RFC 3376) added source filtering, enabling Source-Specific Multicast (RFC 4607), the clean model most new deployments prefer. IPv6 folded membership into the ICMPv6-based MLD protocol and reserved ff00::/8. Multicast never conquered the public internet — but it quietly runs the world's IPTV and exchange market-data plumbing.