Multicast routing

This chapter assumes you know how group addresses fit into the IPv4 and IPv6 address space, which IP addresses on networks.jelia.nyc covers, and what a broadcast domain is, which Ethernet on networks.jelia.nyc covers. Here we go past the address ranges and into the routers.

There are four ways to get one stream to many receivers. Replicated unicast is what most of the internet does: the sender opens one connection per viewer and sends a separate copy to each. It is simple and works everywhere, but the sender's link carries N copies, and so does every link that several of those copies share. Broadcast sends one copy to every host on a link, wanted or not, and stops at the first router. Multicast sends one copy addressed to a group; routers forward it only toward links where someone has asked to receive that group, and copy it only where the tree branches. Anycast, which route selection touches on, is the opposite case: one of many servers answers one client.

The saving is easy to state. Under replicated unicast, every link carries one copy for each receiver whose path crosses it. Under multicast, every link on the tree carries exactly one copy.

Worked example. A 5 Mb/s video channel goes to 2,000 set-top boxes behind one headend router. Replicated unicast puts 2,000 × 5 = 10,000 Mb/s, ten gigabits a second, on the headend's uplink. Multicast puts 5 Mb/s on it, plus one copy on each downstream link that has at least one viewer. That ratio is why every IPTV operator runs multicast inside its own network, even though the public internet does not.

RFC 1112, published in August 1989, set out the model that still holds. A multicast address does not name a machine; it names a host group, a set of zero or more receivers that can change at any time. Anyone may send to a group without joining it. Receivers join and leave on their own, and the sender never learns who they are. In IPv4 the groups live in 224.0.0.0/4, the old "class D", from 224.0.0.0 to 239.255.255.255. IANA divides it further.

IPv6 builds scope into the address itself. Every multicast address starts with FF, then a flags nibble and a scope nibble. FF02::1 is all nodes on this link; FF05::2 is all routers in this site; FF0E:: addresses are global. RFC 4291 defines the scopes, and RFC 4607 sets aside FF3x::/32 for source-specific use. A router never forwards a packet beyond the scope its address names, which makes the boundary a property of the address and not of a filter someone has to remember to write.

From group to Ethernet address

On a LAN a multicast IP packet still needs a destination MAC address, and that address has to be computable without ARP, since no single host owns the group. RFC 1112 fixed the rule: take the Ethernet prefix 01:00:5E, set the next bit to zero, and copy the low 23 bits of the group address into the remaining 23 bits. A group has 28 significant bits, so 5 bits are simply thrown away, and 2⁵ = 32 different groups land on every MAC address. A host's network card filters on the MAC, so a host that joined 239.1.1.1 will also hear 224.1.1.1, 225.129.1.1 and 29 others, and its IP stack has to discard the unwanted ones. IPv6 uses 33:33 followed by the low 32 bits of the group, per RFC 2464.

A router does not need to know every receiver. It needs to know, for each of its LAN interfaces, whether at least one host there wants a group. Hosts tell it with IGMP, the Internet Group Management Protocol, in IPv4, and with MLD, Multicast Listener Discovery, in IPv6. The conversation has three moves.

• Report (join). A host that wants a group sends a Membership Report. It does not wait to be asked.
• Query. One router per LAN, the querier (the one with the lowest address), periodically asks everyone on the link which groups they want. Hosts answer after a random delay; in IGMPv2 a host that hears someone else report the same group stays quiet, because one answer is enough.
• Leave. A host that is done sends a Leave (IGMPv2) or a report that changes its state (IGMPv3). The router cannot know whether that was the last listener, so it sends a group-specific query and waits a short time. Silence means nobody is left, and the router stops forwarding.

IGMPv2 lets a host say only "I want group G". IGMPv3, first published as RFC 3376 in 2002 and now specified by RFC 9776 (March 2025), lets it say "I want G, but only from these sources" (INCLUDE mode) or "I want G from anyone except these" (EXCLUDE mode). That source list is what makes source-specific multicast possible. IGMPv3 reports all go to 224.0.0.22, which every IGMPv3 router listens to. MLDv2, RFC 3810 (June 2004), is the same design for IPv6, carried inside ICMPv6.

Membership is soft state: it lasts only as long as hosts keep answering queries. The timers come from RFC 9776.

Between the router and the hosts there is usually a switch, and a plain switch floods multicast frames out of every port, like broadcast. IGMP snooping fixes that: the switch reads the IGMP reports passing through it and forwards each group only to the ports where a report was heard, plus the port toward the router. RFC 4541 describes how switches should do it.

A unicast router forwards a packet out of one interface, chosen by its destination. A multicast router may forward one packet out of many. That is the whole point, and also the danger: in any network with a loop, a router that copies a packet to all its neighbors will soon receive the copies back from them and copy those too. Without a rule, the copies multiply until links saturate.

The rule is the reverse-path forwarding check, or RPF check. For each arriving multicast packet, the router looks up the packet's source address in its ordinary unicast routing table and finds the interface it would use to send a packet back to that source. That is the RPF interface. If the packet arrived on it, the router accepts and forwards it. If the packet arrived on any other interface, the router drops it.

Why does this stop loops? Every router's RPF interface points one step closer to the source along a shortest path, so following RPF interfaces from any router always ends at the source and never goes round in a circle. Together they form a tree rooted at the source: the reverse shortest-path tree. A packet is accepted only when it travels down that tree, and a packet that has gone round a loop is, by definition, not on the tree when it comes back, so it is dropped the first time it arrives somewhere off the tree.

Notice what the check borrows. It never asks a multicast protocol where the source is; it uses whatever unicast table the router already has, filled by OSPF, IS-IS, BGP or static routes. That is the "protocol independent" in Protocol Independent Multicast. It also means a broken unicast table breaks multicast: if the route back to a source points somewhere the multicast traffic does not come from, every packet fails RPF and is silently dropped. "My stream reaches the router but goes no further" is very often an RPF failure.

Flooding with an RPF check delivers everything everywhere exactly once, and that was the first design: PIM dense mode (RFC 3973) floods each new source's traffic to every router, and routers with no interested receivers send a Prune back upstream. Prunes expire after a few minutes, and unless optional State Refresh messages keep them alive, the flood starts again. That is fine when most links have listeners. When listeners are sparse, which is almost always, it wastes bandwidth and fills every router with state for every source.

PIM sparse mode, specified in RFC 7761 (March 2016), turns it around: nothing is sent anywhere until someone asks. Its problem is that receivers know a group but not who is sending to it. The answer is a meeting place, the rendezvous point or RP: one router that every router in the domain agrees is the root for a group. Sparse mode works in three phases.

1. Receivers join the shared tree. When a host reports interest in G, its last-hop router (its designated router) sends a PIM Join for (*,G), read "star comma G", meaning "group G from any source", one hop toward the RP, using the RPF interface toward the RP's address. Each router on the way creates (*,G) state, records the interface the join came in on as an outgoing interface, and passes the join on, unless it already has (*,G) state, in which case the branch has reached the tree and it stops. The result is a tree rooted at the RP: the shared tree or rendezvous-point tree.
2. The source registers. When a source starts sending, its first-hop router knows nothing about receivers. It wraps each packet in a unicast Register message and sends it straight to the RP, which unwraps it and sends it down the shared tree. Encapsulation is slow, so the RP sends an (S,G) Join toward the source, building a native path from S to the RP; once packets arrive that way, it sends the first-hop router a Register-Stop.
3. Receivers switch to the shortest path. The path S → RP → receiver may be much longer than S → receiver. Once traffic from S arrives, a last-hop router may send its own (S,G) Join straight toward S, building the shortest-path tree. When packets arrive on that tree, it sends an (S,G,rpt) Prune up the shared tree, meaning "keep the shared tree for other sources, but stop sending me S on it". If no branch below the RP still wants S that way, the RP prunes its own (S,G) path toward the source.

When to switch is a local policy: RFC 7761 leaves it to the implementation. Many routers switch on the first packet; some can be told never to switch. All this state is soft: PIM routers resend their joins every 60 seconds, and state that is not refreshed expires. Neighbors find each other with Hellos to 224.0.0.13 every 30 seconds, and all PIM messages travel as IP protocol 103.

Most of PIM sparse mode's machinery, the RP, registers, the switchover and the (S,G,rpt) prunes, exists to solve one problem: receivers do not know who the source is. For most real applications they do. A television channel has one encoder, a market-data feed has a known publisher, and a receiver can be told the source address along with the group in the channel guide or configuration.

Source-specific multicast, RFC 4607 (August 2006), uses that. A receiver asks for a channel, the pair (S,G), with an IGMPv3 or MLDv2 INCLUDE report. Its router sends an (S,G) Join straight toward S, building the shortest-path tree from the start. There is no RP, no shared tree, no register and no switchover. Two different sources can use the same group number without colliding, because the channel is the pair. And an outsider cannot inject traffic into a channel by sending to G, because routers forward only what comes from S along the RPF path to S.

SSM uses 232.0.0.0/8 in IPv4 and FF3x::/32 in IPv6. Routers apply SSM rules to those ranges: they never build (*,G) state there. The price is that every receiver's host stack and every last-hop router must speak IGMPv3 or MLDv2.

Multicast thrives inside networks run by one organization that controls every router and has a real one-to-many problem. Telecom operators deliver IPTV channels to set-top boxes with it. Stock exchanges publish market data as multicast feeds, because the alternative, sending each subscriber a separate copy, would put some subscribers microseconds behind others. Financial firms, broadcast studios moving uncompressed video, and data centers distributing operating-system images or keeping cluster software in step use it for the same reason. Routing protocols themselves use link-local groups every second, as the OSPF and PIM addresses above show.

Across the public internet, multicast never became a general service. RFC 5110 (January 2008), an overview of inter-domain multicast, lays out why it is hard. Each network on the path has to run PIM, agree on RPs or share source information between domains, keep per-group and per-source state in its routers, and accept traffic whose volume it cannot easily bill for or control. A network that skips any of this breaks delivery for everyone behind it. Meanwhile replicated unicast from content delivery networks, with caches placed close to viewers, got cheap enough to carry video at internet scale. The experimental global multicast backbone of the 1990s, the MBone, was built as tunnels over networks that did not support multicast, which shows the gap from the start.

In data-center overlays, where one virtual network may need to flood a frame to all its endpoints, the same choice appears again: an underlay running PIM, or replication by the edge device. That trade-off belongs to data-center fabrics.