Free lesson · Computer Networking
Multicast And Broadcast
One Sender, Many Receivers
Most network communication is unicast - one specific sender, one specific receiver, one copy of the data traversing the network between them. When you request a web page, the server sends one response to your browser. When you send an email, the mail server delivers one copy to the recipient. Unicast is simple, well-understood, and accounts for the vast majority of internet traffic.
But some applications need to deliver the same data to many receivers simultaneously. A live TV broadcast going to millions of concurrent viewers. A stock market data feed going to thousands of trading terminals. A software update going to every device on a corporate network. A network management system discovering all devices on a subnet. If these applications used unicast, the sender would need to transmit a separate copy of the data to each receiver - consuming bandwidth proportional to the number of receivers and quickly overwhelming the sender's network connection.
Multicast elegantly solves this problem by allowing the sender to transmit data once, with the network infrastructure itself replicating the data and delivering it to all interested receivers. The sender sends one copy, and routers along the path duplicate the packets only where needed - at branch points where receivers exist on different network segments.
The Four Addressing Modes
IP supports four distinct addressing modes, each serving a different delivery pattern:
Unicast (One-to-One)
A unicast address identifies a single interface. A packet sent to a unicast address is delivered to exactly one destination. This is the default mode for virtually all internet communication - HTTP, SSH, database queries, email, and most other protocols use unicast.
Broadcast (One-to-All on a Network)
A broadcast address delivers the packet to every device on the local network segment. In IPv4, the broadcast address for a subnet is the last address in the range - for 192.168.1.0/24, the broadcast address is 192.168.1.255. The special address 255.255.255.255 is the limited broadcast address, used when the sender does not know its subnet (common in DHCP discovery).
Broadcast has a fundamental limitation: it affects every device on the network, regardless of whether the device is interested in the data. Every device must receive and process the broadcast frame, consuming CPU cycles even if the data is irrelevant. For this reason, broadcast does not scale beyond the local subnet - routers do not forward broadcast traffic to other subnets by default.
IPv6 eliminated broadcast entirely, replacing it with multicast. This is a deliberate design improvement - multicast is more efficient because only interested devices process the traffic.
Multicast (One-to-Many Interested Receivers)
A multicast address identifies a group of interested receivers. Any device can join the group by signaling its interest to the network. Packets sent to the multicast address are delivered to all group members but not to non-members. The network infrastructure (multicast-aware routers) handles replication and delivery.
IPv4 multicast addresses use the range 224.0.0.0 to 239.255.255.255 (the Class D range). Some well-known multicast addresses:
| Address | Purpose |
|---|---|
224.0.0.1 |
All hosts on the local network |
224.0.0.2 |
All multicast-capable routers |
224.0.0.5 |
All OSPF routers |
224.0.0.9 |
All RIPv2 routers |
224.0.0.251 |
mDNS (Multicast DNS) |
239.0.0.0/8 |
Administratively scoped (private use) |
IPv6 multicast addresses use the prefix ff00::/8. IPv6 relies heavily on multicast for essential functions: neighbor discovery (replacing ARP), router discovery, and address autoconfiguration all use multicast.
Anycast (One-to-Nearest)
An anycast address is assigned to multiple devices (typically in different locations), and a packet sent to the anycast address is routed to the nearest device (in terms of routing distance). Anycast is implemented through BGP - multiple locations announce the same IP prefix, and BGP naturally routes each sender to the closest announcement.
Anycast is used extensively by CDNs (Cloudflare, Google, AWS CloudFront) to route users to the nearest edge server, and by DNS root servers (13 logical root servers are served by hundreds of physical servers worldwide using anycast). Anycast is particularly well-suited for stateless or short-lived protocols like DNS (where a single request-response pair completes the interaction) - for stateful protocols like TCP, connection migration after a routing change can cause disruption, though careful engineering can mitigate this.
graph TD
subgraph Modes["IP Addressing Modes"]
direction TB
UNI["Unicast<br/>One sender → One receiver<br/>Most internet traffic"]
BROAD["Broadcast<br/>One sender → All devices<br/>on local network<br/>(IPv4 only)"]
MULTI["Multicast<br/>One sender → Interested<br/>group members<br/>Network replicates"]
ANY["Anycast<br/>One sender → Nearest<br/>of multiple destinations<br/>BGP-based routing"]
end
style UNI fill:#4f46e5,stroke:#4338ca,color:#fff
style BROAD fill:#7c3aed,stroke:#6d28d9,color:#fff
style MULTI fill:#8b5cf6,stroke:#7c3aed,color:#fff
style ANY fill:#a78bfa,stroke:#8b5cf6,color:#fff
This diagram shows the four IP addressing modes. Unicast delivers from one sender to one receiver and handles most internet traffic. Broadcast delivers from one sender to all devices on the local network, available only in IPv4. Multicast delivers from one sender to all interested group members, with the network replicating packets as needed. Anycast delivers from one sender to the nearest of multiple destinations, using BGP routing to find the closest server.
IGMP - Managing Multicast Group Membership
IGMP (Internet Group Management Protocol) is the protocol that hosts use to signal their interest in receiving multicast traffic. When a device wants to receive traffic for multicast group 239.1.1.1, it sends an IGMP Join message. The local router adds the device's interface to the multicast forwarding table for that group. When the device is no longer interested, it sends an IGMP Leave message.
IGMP operates between hosts and their directly connected router:
IGMP Membership Report (Join): "I want to receive traffic for group X." The router starts forwarding group X traffic to the network segment where the requesting host resides.
IGMP Leave Group: "I am no longer interested in group X." If no other hosts on the segment are members of group X, the router stops forwarding that traffic, conserving bandwidth.
IGMP Membership Query: Periodically, the router sends a query asking "is anyone still interested in group X?" If no host responds, the router prunes the group from its forwarding table. This garbage collection ensures that groups are cleaned up when all members leave without explicitly sending Leave messages (e.g., if a device is unplugged or powered off).
IGMP has three versions: IGMPv1 (basic join/query), IGMPv2 (added leave messages for faster pruning), and IGMPv3 (added source filtering - "I want to receive group X traffic but only from source Y"). IGMPv3 is the basis for Source-Specific Multicast (SSM), which restricts multicast traffic to a specific sender - significantly improving security by preventing unauthorized sources from injecting traffic into a group.
Multicast at Layer 2 - Ethernet and IGMP Snooping
When a multicast IP packet reaches an Ethernet network, it must be mapped to a multicast MAC address. IPv4 multicast addresses are mapped to Ethernet MAC addresses using the pattern 01:00:5E:xx:xx:xx, where the lower 23 bits of the IP multicast address are placed in the lower 23 bits of the MAC address. Because IPv4 multicast addresses have 28 variable bits but only 23 bits are mapped to the MAC address, there is a 32:1 overlap - 32 different multicast IP groups may map to the same MAC address. This ambiguity is handled at the IP layer.
Without special handling, Ethernet switches treat multicast frames like broadcast - flooding them to all ports. This defeats the efficiency advantage of multicast. IGMP snooping solves this: the switch inspects IGMP Join and Leave messages passing through it and builds a table mapping multicast groups to specific ports. When a multicast frame arrives, the switch forwards it only to ports where interested receivers are connected, rather than flooding it everywhere.
IGMP snooping is enabled by default on most enterprise switches and is essential for any network carrying multicast traffic. Without it, a single multicast stream consumes bandwidth on every port - even ports connected to devices that have no interest in the stream. On networks with heavy multicast traffic (IPTV, financial data feeds), the difference between IGMP snooping enabled and disabled can be the difference between a functioning network and a saturated one.
Multicast Routing
Within a local subnet, multicast is straightforward - the switch forwards multicast frames to all ports where interested hosts reside (managed via IGMP snooping on the switch). Across subnets and routers, multicast routing protocols build distribution trees that determine how multicast traffic is replicated through the network:
PIM (Protocol Independent Multicast) is the dominant multicast routing protocol. PIM operates in two modes:
PIM-SM (Sparse Mode): Used when group members are sparsely distributed. Traffic is forwarded only to routers that have explicitly requested it (via join messages). A central Rendezvous Point (RP) serves as the root of the initial distribution tree. Receivers join the tree by sending join messages toward the RP, and the RP connects to the source. Once traffic is flowing, the network can optimize to a source-based shortest-path tree, bypassing the RP for efficiency.
PIM-DM (Dense Mode): Used when group members are densely distributed (most subnets have at least one member). Traffic is initially flooded everywhere, and routers that have no interested members send prune messages to stop receiving. Dense mode is simpler but wastes bandwidth during the initial flood - it is rarely used in practice.
Multicast Use Cases
IPTV and Live Streaming (Within ISP Networks)
IPTV (Internet Protocol Television) is the primary use case for multicast at scale. An ISP delivering 200 TV channels to millions of subscribers uses multicast to send each channel's video stream once from the headend to the network, with routers replicating the stream to each subscriber's set-top box. Without multicast, the ISP would need to send a separate unicast stream to each subscriber - 200 channels × 1 million subscribers = 200 million streams. With multicast, the ISP sends 200 streams regardless of subscriber count.
Financial Market Data
Stock exchanges (NYSE, NASDAQ, CME) distribute real-time market data (price quotes, trade executions) via multicast within their data center networks and to co-located trading firms. Multicast ensures that every subscriber receives the same data at the same time - critical for fairness in financial markets. The UDP multicast delivery is supplemented by application-level gap detection and retransmission for reliability.
Network Management and Discovery
Protocols like mDNS (multicast DNS, used by Apple Bonjour and Avahi for local service discovery), SSDP (Simple Service Discovery Protocol, used by UPnP), and OSPF/RIPv2 (routing protocols) use multicast for local network communication. These protocols need to reach all interested devices without knowing their individual IP addresses - exactly the problem multicast solves.
Software Distribution
Some corporate networks use multicast to distribute software updates and OS images to hundreds or thousands of workstations simultaneously. Multicast reduces the load on the distribution server from N unicast streams to a single multicast stream, significantly accelerating large-scale deployments.
Why Multicast Is Rare on the Public Internet
Despite its efficiency, multicast is almost entirely absent from the public internet. You cannot send a multicast packet from your home to a device across the internet. This is because:
ISP routers do not forward multicast. Enabling multicast routing on ISP backbone routers adds significant complexity (state per multicast group, PIM protocol overhead, security concerns) with limited revenue benefit. Most ISPs disable inter-domain multicast forwarding.
No inter-domain multicast standard has achieved adoption. Protocols like MSDP (Multicast Source Discovery Protocol) and MBGP (Multicast BGP) exist for inter-domain multicast but have seen minimal deployment. The operational complexity and security risks have prevented adoption.
CDNs replaced the need. The original motivation for internet multicast was efficient one-to-many content delivery. CDNs (Cloudflare, Akamai, AWS CloudFront) solve the same problem using unicast: they replicate content to edge servers near users, and each user streams from their nearest edge via unicast HTTP. CDNs are operationally simpler and work with existing internet infrastructure.
Security concerns. Multicast groups are open by default - any device can join any group. This creates amplification attack opportunities and makes access control difficult. Source-specific multicast (SSM, IGMPv3) partially addresses this by limiting traffic to known sources, but adoption has been slow.
The result: multicast thrives within networks (ISP IPTV networks, enterprise LANs, financial data centers) but is absent between networks. The public internet uses unicast for everything, with CDNs providing the scalability that multicast would offer.
graph TD
subgraph MulticastVsUnicast["Multicast vs Unicast for 1,000 Receivers"]
direction TB
subgraph Unicast["Unicast Approach"]
SRC1["Source<br/>sends 1,000<br/>individual streams"]
end
subgraph Multicast["Multicast Approach"]
SRC2["Source<br/>sends 1 stream"] --> R1["Router<br/>replicates as needed"]
R1 --> R2["Router"]
R1 --> R3["Router"]
end
end
style SRC1 fill:#ef4444,stroke:#dc2626,color:#fff
style SRC2 fill:#22c55e,stroke:#16a34a,color:#fff
style R1 fill:#7c3aed,stroke:#6d28d9,color:#fff
style R2 fill:#8b5cf6,stroke:#7c3aed,color:#fff
style R3 fill:#8b5cf6,stroke:#7c3aed,color:#fff
This diagram contrasts unicast and multicast for delivering data to 1,000 receivers. With unicast, the source must send 1,000 individual streams, consuming 1,000 times the bandwidth at the source. With multicast, the source sends a single stream, and routers in the network replicate the data only at branch points where it needs to reach different segments. The source's bandwidth usage is constant regardless of the number of receivers.
Interview: Multicast and anycast appear in specific System Design contexts:
"How does a CDN route users to the nearest edge?" - Anycast. The CDN announces the same IP prefix from every edge location via BGP. Each user's traffic is routed to the nearest announcement by normal BGP path selection. If an edge fails, its BGP announcement is withdrawn and traffic shifts to the next nearest edge.
"Could you use multicast for a live streaming platform?" - Not on the public internet - ISPs do not forward multicast. You would use a CDN with unicast HTTP (HLS/DASH) to distribute the stream to edge servers worldwide. Within a single data center or ISP network, multicast is viable - IPTV systems use it extensively.
"What is the difference between multicast and broadcast?" - Broadcast reaches every device on the network, regardless of interest. Multicast reaches only devices that have joined the group. Multicast is more efficient because non-members do not process the traffic. IPv6 eliminated broadcast entirely in favor of multicast.
What Comes Next
The final topic provides a comprehensive comparison of transport protocols - TCP, UDP, QUIC, and SCTP - with a decision matrix for protocol selection across different system design scenarios.
Exercise: Starter: Check if your device uses multicast for local network discovery. On Mac/Linux, run
netstat -gnorip maddr showto see which multicast groups your interfaces have joined. You will likely see224.0.0.1(all hosts) and possibly224.0.0.251(mDNS) if Bonjour/Avahi is running.Intermediate: Research IGMP snooping on Ethernet switches. Without IGMP snooping, a switch treats multicast like broadcast - flooding it to all ports. With IGMP snooping, the switch listens to IGMP Join/Leave messages and forwards multicast only to ports with interested hosts. Why is IGMP snooping essential for networks with multicast traffic? What happens when IGMP snooping is disabled on a switch with heavy multicast traffic?
Advanced: Research Source-Specific Multicast (SSM, RFC 4607). How does SSM differ from Any-Source Multicast (ASM)? Why is SSM easier to deploy securely? How does IGMPv3's source filtering enable SSM? Research how large financial exchanges (CME, NASDAQ) use SSM for market data distribution within their data centers.