4.1 Multicast addresses and group membership

Broadcast disturbs everyone; multicast delivers only to hosts that joined a group. IPv4 class D: 224.0.0.0 – 239.255.255.255 — a multicast address names a group, not a host.

Address mapping (exam favourite): IPv4 group → Ethernet MAC 01:00:5e + low 23 bits of the group address. 28 significant bits squeezed into 23 ⟹ 32 groups share each MAC address — the NIC filter is imperfect, so IP must re-check the destination group. IPv6 maps 33:33 + low 32 bits.

On a LAN, joining means the NIC starts accepting that MAC; across routers, IGMP (IPv4) / MLD (IPv6) tells routers "a member lives here", and multicast routing builds the delivery tree. Unlike broadcast, multicast is WAN-capable: datagrams cross routers wherever members exist — that difference is the whole point of §4 of the syllabus ("on a LAN" vs "on a WAN").

4.2 The multicast socket options

struct ip_mreq mreq;
inet_pton(AF_INET, "239.255.1.1", &mreq.imr_multiaddr);
mreq.imr_interface.s_addr = htonl(INADDR_ANY);
setsockopt(sockfd, IPPROTO_IP, IP_ADD_MEMBERSHIP, &mreq, sizeof(mreq));

Receiving recipe: socket → SO_REUSEADDR (several receivers per host share the port) → bind the group/port → join. Sending needs no join at all — just sendto the group (set TTL thoughtfully).

mcast_join and friends: Stevens' protocol-independent wrappers — mcast_join(fd, sa, salen, ifname, ifindex), mcast_leave, mcast_set_if, mcast_set_ttl, mcast_set_loop — hide the IPv4/IPv6 option differences behind one API; with them, dg_cli works unchanged for multicast: the same UDP echo client, pointed at a group address, after the broadcast lesson's select-timeout treatment of multiple replies.

4.3 The MBone and session announcements

The MBone (multicast backbone) was the 1990s overlay carrying live audio/video (IETF meetings, shuttle launches) across the unicast Internet through tunnels. Its session discovery machinery is the syllabus item "receiving MBone session announcements":

• Well-known group 224.2.127.254 / port 9875 carries SAP (Session Announcement Protocol) datagrams;
• each announcement contains an SDP description: media types, addresses, ports, times;
• a receiver (the classic sdr tool) just joins that group and listens — discovery itself uses multicast: join one group, learn about all the others. Writing a tiny SAP listener (join + recvfrom + print) is a beloved lab/exam exercise.

4.4 SNTP — a complete multicast application

NTP is the full clock-sync protocol (stratum hierarchy, smooth slewing). SNTP (Simple NTP) is the lightweight client subset — and the textbook's closing example because it ties the whole unit together: a UDP program that binds port 123, joins the NTP multicast group (224.0.1.1) on every interface, and corrects the clock from received timestamps.

The 48-byte packet (know the four timestamps):

LI VN Mode | Stratum | Poll | Precision | root delay/dispersion | refid
Reference Timestamp   — when clock last set
Originate Timestamp   — T1: client sent request
Receive   Timestamp   — T2: server got request
Transmit  Timestamp   — T3: server sent reply        (client notes T4 = arrival)

NTP timestamps: 64 bits — 32 bit seconds since 1 Jan 1900 + 32-bit fraction. The two famous formulas:

offset = ((T2 − T1) + (T3 − T4)) / 2        round-trip delay = (T4 − T1) − (T3 − T2)

(assuming symmetric paths — the stated SNTP approximation). Broadcast/multicast mode skips the exchange: servers periodically multicast their time; clients passively correct — exactly the one-to-many pattern this unit exists to teach.

4.5 Worked example: mapping a group address to its Ethernet MAC

The 23-bit mapping is best learned by doing one. Map 224.192.16.1:

224 . 192  . 16   . 1
      1100 0000 . 0001 0000 . 0000 0001      (low three octets in binary)
       ↑ drop the TOP 5 bits of the 28 significant bits —
         keep only the LOW 23:
      _100 0000 . 0001 0000 . 0000 0001  →  0x40 0x10 0x01
MAC = 01:00:5e : 40:10:01

The prefix 01:00:5e is fixed (its low bit of the first octet = 1 marks it a group MAC); the next bit after the prefix is always 0; the remaining 23 bits come from the group. Now verify the collision claim: 239.64.16.1 has the same low 23 bits (the dropped bits differ) → same MAC 01:00:5e:40:10:01. In general the 5 dropped bits give $2^5 = 32$ IPv4 groups per MAC — hence "the NIC filter is imperfect; IP re-checks". Being able to compute one mapping and exhibit one collision is the difference between reciting and understanding.

4.6 IGMP — how routers learn where members live

One paragraph of mechanism makes the "on a WAN" half concrete:

• Join: when the first process on a host joins a group, the host sends an unsolicited IGMP membership report to that group; the local router adds (interface, group) to its table and grafts the interface onto the delivery tree.
• Maintenance: the router periodically sends membership queries (to 224.0.0.1); one member per group answers (each host starts a random timer and suppresses its report if it hears another — the elegant scaling trick: one report suffices no matter how many members).
• Leave: IGMPv2 added explicit leave messages so the router can prune quickly instead of waiting for queries to go unanswered.

Key conceptual sentence: routers track "is there at least one member on this link?", never which hosts — delivery on the final link is the NIC-level multicast from §4.1. IPv6 folds the same machinery into ICMPv6 as MLD.

4.7 Broadcast vs multicast — the closing comparison table

The IPv6 row is a high-value detail: IPv6 has no broadcast at all — even address resolution (ARP's replacement, Neighbour Discovery) uses solicited-node multicast groups, so only one or a few hosts wake per query. That single design change is the strongest possible answer to "why is multicast superior to broadcast?".

4.8 Reading an SNTP exchange — a worked offset calculation

Client sends at its clock 10:00:00.000 (T1). Server stamps receipt T2 = 10:00:05.020 and transmit T3 = 10:00:05.030. Reply lands at client T4 = 10:00:00.050.

$$\text{offset} = \frac{(T2 - T1) + (T3 - T4)}{2} = \frac{5.020 + 4.980}{2} = 5.000 \text{ s}$$

$$\text{delay} = (T4 - T1) - (T3 - T2) = 0.050 - 0.010 = 0.040 \text{ s}$$

Interpretation: the client is 5 s slow; the network ate 40 ms round trip (the server's 10 ms of processing is subtracted out — that's what the $(T3 - T2)$ term is for). Note how the two one-way trips' asymmetry would corrupt the offset estimate — the symmetric-path assumption is exactly where SNTP stops and full NTP (with its filtering and statistics) begins.

Exam pointers

• "Explain IPv4-to-Ethernet multicast address mapping" — do the §4.5 computation; state the 32:1 collision ratio and its consequence.
• "Compare broadcasting and multicasting" — §4.7's table; lead with the non-member-cost row, close with the IPv6 row.
• "Write the steps for a multicast receiver" — socket → SO_REUSEADDR → bind(group, port) → IP_ADD_MEMBERSHIP (struct ip_mreq with group + interface); senders need none of this.
• "Explain SNTP and its timestamp calculations" — packet layout, the four T's, both formulas, one worked example like §4.8, the symmetry caveat.

Check yourself

1. Compute the MAC for 224.10.10.10 — and find one other group address that collides with it.
2. Why does a multicast sender never call IP_ADD_MEMBERSHIP? What is joining actually for?
3. Two video streams use 224.1.2.3 and 225.1.2.3. A host joined only the first sometimes receives frames of both at the NIC. Which layer discards the strays, and why must it?
4. What does IP_MULTICAST_TTL = 1 guarantee, and which §4.1 address range enforces the same property by rule?
5. In §4.8's exchange, suppose the outbound path took 35 ms and the return 5 ms. Recompute what offset SNTP reports versus the true offset — what assumption broke?