datmt.com

Multicast Concepts: Address Scope, TTL Limits, Bandwidth Efficiency, and Router Requirements

Sun Sep 13 2026

Part 8 of 11 in Mastering Java Network Programming

Multicast is one of those networking primitives that feels obvious in theory but is surprisingly fragile in practice. You send a single packet to a group address and the network replicates it for everyone — elegant, until you try to get it past a router.

This post walks through four practical aspects of multicast with Java examples:

  1. Address scope — which IP ranges stay local and which can be routed
  2. TTL hop limits — how packet lifetime controls reach in practice
  3. Bandwidth efficiency — a concrete unicast-vs-multicast comparison
  4. The Java API and off-subnet infrastructure — how to actually use multicast and what routers need on the path

Each topic gets its own small, focused demo.

Multicast address scope

IPv4 multicast uses addresses in the 224.0.0.0/4 range (224.0.0.0 through 239.255.255.255), but not all of them behave the same way. The IANA has reserved specific blocks for different purposes.

Here’s every IANA-reserved block:

String[][] ranges = {
    { "224.0.0.0/30",   "Base ID (reserved)" },
    { " 224.0.0.x",     "Link-local: never forwarded by router" },
    { " 224.0.0.1",     "All hosts on the subnet" },
    { " 224.0.0.2",     "All routers on the subnet" },
    { " 224.0.0.5",     "OSPF all-routers" },
    { " 224.0.0.9",     "RIPv2" },
    { " 224.0.0.13",    "PDUs for VRRP" },
    { "224.0.1-254",    "Globally assigned (IANA)" },
    { "224.0.255/24",   "Spare / future use" },
    { " 224.0.255.0-31","Base ID for SD-RM multicast" },
    { "239.x.x.x",      "Administratively scoped (private use)" },
};

The critical range is 224.0.0.x — called “link-local” or “local group.” These addresses have an implicit TTL of zero, which means no router will ever forward them beyond the originating subnet. They’re reserved for infrastructure protocols that must hit every device on a local wire without risking accidental propagation:

  • 224.0.0.1: all hosts (used by DHCP)
  • 224.0.0.2: all routers (used by routing protocols)
  • 224.0.0.9: RIPv2
  • 224.0.0.5: OSPF hello packets

Addresses in the 239.x.x.x block are “administratively scoped” — they can be routed within a private deployment, but ISPs treat them as unrouteable by default.

TTL hop limits

A multicast packet’s Time-To-Live field is how far it travels. Each router that forwards the packet decrements TTL by one; when TTL reaches zero, the packet is discarded. But unlike regular IP routing where every hop decrements TTL regardless, multicast forwarding has a second gate: the interface’s configured TTL boundary. A packet only gets forwarded out of an interface if its TTL exceeds that boundary.

Here’s what different TTL values mean in practice:

Object[][] entries = {
    { Integer.valueOf(0),   "Link-local: never leaves the NIC" },
    { Integer.valueOf(1),   "Same-subnet only" },
    { Integer.valueOf(32),  "Site-wide — building or campus" },
    { Integer.valueOf(64),  "Regional ISP scope" },
    { Integer.valueOf(128), "Internet-wide (e.g., SSDP)" },
    { Integer.valueOf(255), "Maximum — potential global reach" },
};

The combination of TTL and boundary enforcement is important. If you set TTL=64 but your ISP uplink has a boundary of 0, the packet is silently dropped at that first hop — no error message, no retry, just gone. Similarly, a datacenter fabric might have boundary=32 on its spine ports, so a TTL of 1 will reach the edge but never cross into the core.

Bandwidth efficiency

This is where multicast earns its keep. With unicast, broadcasting to N recipients means sending N separate datagrams — each carrying its own IP/UDP header, each traversing the routing table independently. Multicast sends one datagram; the network replicates at subtree roots.

The demo below computes packet counts and byte totals for fan-outs from 1 to 100:

int[] FANOUTS = {1, 2, 5, 10, 25, 50, 100};
int PAYLOAD = 1400;
int TOTAL_HDR = 28; // UDP(8) + IPv4(20)

The savings compound quickly. At 10 clients, unicast sends 14,280 bytes while multicast sends just 1,428 — a 90% reduction. At 100 clients the gap is staggering: 142,800 vs 1,428. The saving isn’t in payload size (one datagram’s worth either way) but in eliminating N copies of the IP/UDP headers and the routing computation for each one.

The Java API and off-subnet infrastructure

Java handles multicast via java.net.MulticastSocket — a DatagramSocket subclass with IGMP group management. Here’s the sender skeleton:

InetAddress group = InetAddress.getByName("239.0.0.1");
MulticastSocket socket = new MulticastSocket(5000);
socket.setTimeToLive(1);          // same-subnet only
socket.joinGroup(group);          // subscribe to the group
DatagramPacket pkt = new DatagramPacket(msg, msg.length, group, 5000);
socket.send(pkt);                 // one datagram -> all members
socket.leaveGroup(group);
socket.close();

And the receiver:

MulticastSocket socket = new MulticastSocket(5000);
socket.joinGroup(group);          // NIC joins IGMP group BEFORE sending starts
byte[] buf = new byte[8192];
DatagramPacket pkt = new DatagramPacket(buf, buf.length);
socket.receive(pkt);              // blocks until a packet arrives

Two things that trip people up:

  • joinGroup() order matters for receivers. If you call receive() before joinGroup(), the NIC hasn’t told its router to add your interface to the group’s multicast filter — you’ll miss data. The sender should also call joinGroup() if it wants to receive its own transmitted copies.
  • setTimeToLive() controls reach, not reliability. TTL=1 limits delivery to the local LAN; TTL=32 covers a campus. There’s no automatic repair for dropped packets — multicast is fundamentally UDP with group semantics.

Router requirements for off-subnet delivery

For multicast to cross subnets, every router on the path must:

  1. Support IGMP (v2 or v3) so hosts can tell their local router which groups they want
  2. Run a multicast routing protocol — PIM-SM, PIM-DM, or IGMPv3 — to build forwarding trees
  3. Have TTL boundaries configured per-interface to prevent site-local traffic from leaking

The common failure mode is writing an application that joins 239.x.x.x, sets TTL=64, and expecting the data to reach remote sites. On most networks (cloud providers, consumer ISPs, edge networks) there is no multicast routing between subnets. The packet reaches the local LAN’s NICs and stops at the first hop router.

Takeaway

Multicast works beautifully when you control the full path — a campus network, a datacenter fabric, or a dedicated VPN with PIM enabled. It fails silently on almost everything else because there’s no routing protocol to build the delivery tree, no IGMP to track who wants the traffic, and no way for an application to discover whether its packets crossed a boundary. For local broadcasting it’s unbeatable bandwidth-wise; beyond your control plane, reach for SD-M or just accept the unicast cost.