Summary

  • RFC 9777 records multicast interest on a directly attached IPv6 link; it does not authenticate the listener or certify an end-to-end path.
  • Per-socket intent is merged into per-interface state, then compressed again into router INCLUDE/EXCLUDE state whose truth is bounded by timers and compatibility mode.
  • Leadership needs separate receipts for socket intent, report emission, querier state, router state, compatibility, upstream forwarding, replication and useful receiver delivery.

At 09:00 a monitoring console can show an MLDv2 record for source S and group G. The source timer is positive. The interface is in INCLUDE mode. Every field can be correct—and the application can still receive no useful traffic.

That is not a contradiction in RFC 9777. It is a contradiction in the question the console was asked to answer.

Published in March 2025 as Internet Standard 101, RFC 9777 specifies Multicast Listener Discovery Version 2 for IPv6. It lets routers discover listeners and their source preferences on directly attached links. The result feeds a multicast routing protocol. It is neither the routing protocol itself nor an application-delivery receipt.

Three compressions before the first router record

The first state belongs to an application socket. Conceptually, an upper layer calls IPv6MulticastListen with a socket, interface, multicast address, filter mode and source list. INCLUDE asks for only the listed sources; EXCLUDE asks for all sources except those listed.

A host may have several sockets with different requests for the same group. MLDv2 therefore computes a per-interface projection. If all sockets use INCLUDE, the interface list is their union. If any socket uses EXCLUDE, the interface moves to EXCLUDE and derives a list that respects the combined requests. The interface record is already not a roster of sockets.

The router compresses again. It normally needs to know only whether at least one listener on the link wants a group and source, not which host or process asked. In INCLUDE mode, its source list is a link-wide union. In EXCLUDE mode, it maintains a Requested List and an Exclude List. That state is useful for forwarding decisions, but it cannot identify the surviving application request.

There is a final boundary inside the host. RFC 9777 says that after a packet is accepted by the IP layer, delivery to a particular socket still depends on socket state and perhaps the transport port. It does not require an implementation to enforce source filtering separately for every socket. Frame arrival, IP acceptance and application consumption are therefore different facts.

The timers are not clerical detail

MLDv2 is soft state. Current-State Reports refresh it; State-Change Reports announce a change and are repeated according to the Robustness Variable. The default Robustness Variable is two, so the design aims to tolerate one lost message. Resilience comes with memory.

With the default 125-second Query Interval and ten-second Query Response Interval, the Multicast Address Listening Interval is 2 × 125 + 2 × 10: 270 seconds. That is the default time horizon before a router concludes that a group or source has no listeners. It is not a promise that a production network uses those defaults, and a live timer is not proof that the originating process is still healthy.

The fast-leave path is also deliberately cautious. A state-change asking to stop a source causes the router to lower a source timer and query for other listeners. With the default one-second Last Listener Query Interval and a count of two, the default Last Listener Query Time is two seconds. During that window the MLD component continues suggesting forwarding. Silence must be tested before it becomes absence.

Source timers mean different things in different modes. In INCLUDE, expiry removes a source from the allowed list. In EXCLUDE, expiry can move a source from the Requested List to the Exclude List. When the group Filter Timer expires, the router can switch from EXCLUDE to INCLUDE using the Requested List. An operator who records only “timer expired” loses the transition that determines what should happen next.

Compatibility can erase source precision for minutes

MLDv2 interoperates with MLDv1, but compatibility is not semantically free. When a host receives an MLDv1 General Query, it enters MLDv1 compatibility on that interface and resets an Older-Version-Querier-Present Timer. With default variables, that interval is 2 × 125 + 10: 260 seconds. The host then uses only MLDv1 and cancels pending responses and retransmissions when the mode changes.

On the router side, an MLDv1 Report moves that multicast address into MLDv1 compatibility and starts an Older-Version-Host-Present Timer, also 260 seconds under defaults. In this state, BLOCK records are ignored and source lists in transitions to EXCLUDE are ignored. When the timer finally returns the group to MLDv2, source-specific state must be relearned; sources that should be blocked may remain unblocked for up to the listening interval.

RFC 4604 tightens the rule for Source-Specific Multicast. An older-version, non-source-specific report in the SSM range should not establish forwarding state. Hosts and routers must agree on the SSM range and version behavior. “Backward compatible” is therefore a policy choice with a timer and a loss of precision, not a universal safety label.

The distribution tree starts beyond MLD

RFC 9777 is explicit: MLD suggestions do not override multicast routing information. A local INCLUDE record can be correct while the upstream join is missing, the reverse-path choice points elsewhere, or tree state has not converged.

For SSM, RFC 4607 says successful establishment of an (S,G) path depends on hop-by-hop propagation of the explicit join toward the source over a loop-free path. RFC 7761 shows the additional states for PIM-SM: joins toward a rendezvous point, source-tree construction, replication at branches, temporary duplicate arrival and pruning during tree changes. Listener discovery is the trigger for some of this work. It is not proof that the work finished.

The last link adds another independent decision. RFC 4541 describes switches that snoop MLD control messages to restrict multicast flooding. Their multicast-router ports, topology response and address-based forwarding determine which ports see reports and data. A router record does not certify the switch's replication table.

Nor does a packet from S certify its sender. RFC 9777 carries no cryptographic authentication; link-local source, Hop Limit 1 and Router Alert checks constrain messages to the link but do not defeat an on-link forger. Replayed reports can retain state. A forged MLDv1 report can force compatibility and allow unwanted sources for a bounded interval.

Eight receipts instead of one joined flag

A useful operating record keeps eight claims separate.

The socket-intent receipt names the process, interface, group, source set, filter mode, authorization context and time. The report-emission receipt proves that the expected Current-State or State-Change record actually left the interface. The querier receipt captures the elected querier, version, QRV, QQI and derived timers. The router-state receipt records the exact filter mode, lists and remaining source/filter timers.

The compatibility receipt explains any downgrade, its cause and expiry, plus whether SSM semantics remain valid. The upstream receipt follows the routing-protocol join and reverse-path decision toward the source. The replication receipt uses counters or captures to show that packets entered and left every intended branch. The receiver receipt closes the chain with socket and application observations: sequence continuity, loss, latency, decode and useful consumption.

Each receipt needs an observer and a timestamp. A report captured at 09:00 cannot certify a socket at 09:04, and a router entry on the receiver LAN cannot certify an upstream branch in another domain. The purpose is not to create paperwork. It is to stop one precise control-plane fact from impersonating seven unobserved outcomes.

Sources

  1. RFC 9777 — Multicast Listener Discovery Version 2 (MLDv2) for IPv6
  2. RFC 3810 — the obsoleted MLDv2 specification
  3. RFC 2710 — Multicast Listener Discovery for IPv6
  4. RFC 4604 — Using IGMPv3 and MLDv2 for Source-Specific Multicast
  5. RFC 4607 — Source-Specific Multicast for IP
  6. RFC 7761 — Protocol Independent Multicast, Sparse Mode
  7. RFC 4541 — IGMP and MLD Snooping Switches Considerations