skip to content

What is Multicast Listener Discovery in IPv6, which ICMPv6 messages carry it, and why does a host running no multicast application still send MLD reports?

level: middleimportance: nice to knowfreq 14%

answer

  1. IGMP's IPv6 successor
  2. query, report, done
  3. version 2 report has its own type
  4. hop limit 1, link-local source
  5. solicited-node groups need joining

basics

~10 s

MLD lets IPv6 routers learn which multicast groups have listeners on a link. It uses ICMPv6 types 130-132 (MLDv1) and 143 (MLDv2 report). Hosts also report their solicited-node groups, which Neighbor Discovery uses.

solid answer

~40 s

**Multicast Listener Discovery** is IPv6's counterpart of IGMP: routers use it to learn which multicast addresses have listeners on each attached link. MLDv1 (RFC 2710) defines Multicast Listener Query (`130`), Report (`131`) and Done (`132`); MLDv2 (RFC 3810) keeps the Query, adds the Version 2 Multicast Listener Report (`143`, sent to `FF02::16`) and lets a listener name the sources it wants. All are ICMPv6 messages sent with a link-local source, a Hop Limit of 1 and a Router Alert option. A host with no multicast application still reports because **Neighbor Discovery** depends on multicast: each host joins the **solicited-node** group for each of its addresses, and joining is done with MLD. On links whose switches snoop MLD, those reports decide which ports receive the group's traffic.

go deeper

for a junior

Recall that MLD is IPv6's replacement for IGMP, carried in ICMPv6, and that it tells routers which multicast groups have listeners on a link.

for a middle

Explain the message types (130-132, 143), the query and report cycle, why the messages stay on the link, and why solicited-node groups make every host an MLD speaker.

for a senior

Connect MLD to failures you might debug: snooping switches pruning solicited-node traffic, Duplicate Address Detection misbehaving, filters that drop MLD with the rest of ICMPv6.

for a principal

Weigh MLD as part of the cost of IPv6's multicast-based discovery: it avoids broadcast but makes multicast membership signalling, and switches that snoop it, part of basic reachability.

## What MLD is for A multicast router has to know, for each attached link, whether **at least one node** there wants packets sent to a given multicast address; it does not need to know which nodes. **Multicast Listener Discovery (MLD)** is the protocol that tells it. In IPv4 that job belongs to IGMP, which is its own IP protocol (number 2). RFC 2710 says MLD is derived from IGMPv2, with the important difference that it uses **ICMPv6 message types** instead. There are two versions: - **MLDv1**, RFC 2710. - **MLDv2**, RFC 3810, which updates RFC 2710, is a translation of IGMPv3, and adds **source filtering**: a listener can ask for a group's traffic only from listed sources (INCLUDE mode) or from all but listed sources (EXCLUDE mode). That is what source-specific multicast needs. RFC 8504 requires nodes that need to join multicast groups to support MLDv2. ## The messages | Type | Message | Version | Sent to | |---|---|---|---| | 130 | Multicast Listener Query | v1 and v2 | General Query: all-nodes `FF02::1`; address-specific queries: the group itself | | 131 | Multicast Listener Report | v1 | the multicast address being reported | | 132 | Multicast Listener Done | v1 | all-routers `FF02::2` | | 143 | Version 2 Multicast Listener Report | v2 | all MLDv2-capable routers, `FF02::16` | Every MLD message is built so it cannot leave the link: - the **IPv6 source is link-local** (MLDv2 permits the unspecified address `::` before a link-local address exists); - the **Hop Limit is 1**; - a **Router Alert** option in a Hop-by-Hop Options header makes routers look at the message even though it is addressed to a group they may not belong to. ## How the exchange runs 1. Routers on a link elect a **Querier**: in MLDv1 a router that hears a Query from a numerically lower IPv6 source address stops querying. 2. The Querier periodically sends a **General Query** to `FF02::1`. 3. Each listener answers after a random delay with a **Report** for each address it listens to. In MLDv1 a host that hears another host's report for the same address first suppresses its own, because one listener is enough. 4. When an MLDv1 listener leaves a group, it may send a **Done** to `FF02::2`, and the router checks with an address-specific query whether anyone remains. 5. A host that starts listening to a group sends an unsolicited Report rather than waiting for the next query. RFC 3810 adds one exclusion that matters: no MLD messages are ever sent for the link-scope **all-nodes address `FF02::1`**, which every node always listens to, nor for multicast addresses of scope 0 or 1. ## Why every IPv6 host speaks MLD The question's twist is that MLD is not only for video streams or routing protocols. **Neighbor Discovery** resolves a neighbour's link-layer address by sending a Neighbor Solicitation to that neighbour's **solicited-node multicast address**, a link-scope group derived from the target address. RFC 4861 requires a node to join the solicited-node group of each address on the interface, and says joining is done with MLD. Because those groups have link scope 2 and are not `FF02::1`, they are reported like any other group. On a simple link that floods all multicast, a lost report changes little. On a link whose switches perform **MLD snooping**, building per-port membership from the reports they overhear (RFC 4541, an Informational RFC describing that practice), the reports decide where a group's packets go. RFC 4862 notes that during Duplicate Address Detection the MLD report is required precisely so that snooping switches forward the solicited-node traffic to the host. ## Why this matters for filtering Because MLD messages are ICMPv6, a host or bridge filter that drops all ICMPv6 drops them too. RFC 4890 lists the MLD messages (types 130, 131, 132 and 143) among the traffic that must not be dropped on a firewall's own interfaces. Where switches snoop MLD, dropping them can leave a host unreachable by neighbours that need its solicited-node group, a failure with no IPv4 counterpart, since ARP requests are broadcast and need no membership signalling. ## Slips to avoid - Saying IPv6 uses IGMP. - Saying only multicast applications generate MLD traffic. - Saying hosts report membership of `FF02::1`. - Expecting MLD to cross routers; it is link-local by construction.

  • What does MLDv2 add over MLDv1, and why does RFC 8504 require it on nodes that join multicast groups?
    MLDv2 (RFC 3810) adds source filtering: a listener reports, per group, INCLUDE or EXCLUDE mode with a list of sources, which source-specific multicast needs. Its reports use type 143 and go to FF02::16. RFC 8504 made MLDv2 support a MUST for nodes that join groups because one MLDv1-only node forces every node on the link into version 1 compatibility mode.
  • Why can an MLD message never be forwarded beyond the link it was sent on?
    MLD messages carry a link-local IPv6 source address and a Hop Limit of 1, so a router that receives one cannot forward it to another link. The Router Alert option in the Hop-by-Hop Options header does the opposite job: it makes routers on the same link inspect the message even though it is addressed to a multicast group they have not joined.

saying these in an interview costs you the question

  • IPv6 hosts use IGMP to report multicast group membership.
  • Only hosts running multicast applications ever send MLD reports.
  • Hosts send MLD reports for the all-nodes address FF02::1.
  • MLDv2 reports have the same type as MLDv1 reports, 131.
  • MLD messages are routed so that distant routers learn about listeners.