Summary

  • RFC 3019 exposed MLD interface and membership-cache state through SNMP, but it also made selected rows, timers and proxy settings writable; management could create or delete a cache entry and assert local membership.
  • A cache row, its last-reporter address or a successful SET therefore proved bounded agent state—not a current remote listener, authenticated intent, forwarding, packet delivery or application receipt.

The table looked like an attendance list.

For each IPv6 multicast group on each interface, RFC 3019 supplied a cache row. The row could name the last address that sent a membership report. It could show how long the entry had existed and how long remained before it aged out. A separate interface row exposed the querier, timers, group count and cumulative joins.

Then the specification gave the manager a pen.

The manager could create or delete a cache row. It could set whether the local system itself counted as a member. It could enable or disable Multicast Listener Discovery on an interface, tune query and loss-tolerance parameters and point learned membership at a proxy interface.

That did not make the MIB deceptive. It made it a control surface as well as an observation surface. The mistake would be to read every row as if it had only one possible origin, or to treat a management response as proof of a receiver beyond the managed agent.

Published in January 2001, RFC 3019 defined the IPv6 MIB for the original Multicast Listener Discovery protocol. Its durable lesson lies in the space between a row's grammatical meaning and the operational claim an investigator wants it to support.

Two tables compressed several realities

RFC 3019 defined two conceptual tables. The MLD Interface Table held one row for each interface on which MLD was enabled. The MLD Cache Table held one row for each multicast group and interface for which the implementation represented membership.

Both hosts and routers were meant to implement the tables, although some fields applied only to routers. That mattered because the same column could sit near facts with different owners.

The interface row described protocol administration and current control state. It included the query interval, maximum response delay, MLD version, querier address, cumulative number of joins, current group count, robustness variable, last-listener query interval, proxy interface and two querier timers.

The cache row described a group/interface pair. Its index was the multicast address plus the interface. It included whether the local system was itself a member, the source of the last membership report, row uptime, remaining expiry time and RowStatus.

Those fields did not form one indivisible snapshot. A join counter was cumulative activity over time. A group gauge was current row count. A last-reporter address was a historical source field. An expiry timer was a forecast under the agent's current timer state. A writable status was a management action point.

Reading them together could be useful. Treating them as interchangeable evidence could be disastrous.

“Last reporter” did not mean “current listener”

mldCacheLastReporter had a narrow definition: the IPv6 source address of the last membership report received for the group on the interface. If no report had been received, the value was 0::0.

The object did not claim to enumerate listeners. MLD itself was designed to tell a router whether at least one listener existed on a directly attached link, not to maintain an authenticated roster of applications or people. Listeners could suppress redundant reports after hearing another host answer. Timers could keep group state alive after the last observed report. The local system could also be a member.

The last reporter could therefore be one witness among several, a past witness, or simply the most recent source visible under report suppression. Its address did not prove that it remained subscribed when the manager read the row. It did not prove that it was the only listener, the first listener, the owner of the group or the application that consumed data.

The cache expiry field reinforced the distinction. It exposed the minimum time remaining before the entry would age out. A value of zero could mean the entry existed only because mldCacheSelf was true and would disappear immediately if the router left. The RFC also allowed an implementation to process reports from the local system like reports from other hosts, so zero was not mandatory even in that case.

An investigator needed at least the row, the report history, local-membership state and timer epoch before making a statement about why the row existed. Even then, useful reception remained outside the MIB's claim.

Management could supply the fact it later read

The most important object in the cache was not an address. It was mldCacheStatus.

Its read-create access allowed new entries to be created and existing entries deleted. The base conformance group explicitly said it was designed to permit manager creation and deletion of MLD cache entries. mldCacheSelf, also read-create, indicated whether the local system was a member and defaulted to true.

That combination changed the provenance question. A row might reflect a report learned from the link. It might remain because the managed system itself joined. It might have been created or modified through management. The table alone did not identify which path produced the current state.

This is not an argument against writable management. A manager may legitimately need to install local membership, test behavior, maintain a proxy or remove stale state. The argument is that an administrative fact must not borrow the authority of an independently observed event.

Suppose an automation system created a cache row and then polled the table to confirm it. The returned row could prove that the agent represented the requested state. It could not independently prove that a remote host sent an MLD Report. The reader and writer were operating on the same evidence surface.

The distinction resembles a ledger that permits its operator to enter a planned event and later retrieve it. Retrieval proves persistence in the ledger. It does not prove that the outside event occurred.

Enabling the row could disable the protocol

The interface table had a stronger control. Activating mldInterfaceStatus enabled MLD on the interface; destroying the row disabled MLD.

Other writable objects changed the protocol's timing and tolerance. The manager could set the general query interval, maximum response delay, robustness variable and last-listener query interval. A lower last-listener interval reduced the time needed to detect loss of the last member. A higher robustness value tolerated more packet loss at the cost of additional state or control work.

mldInterfaceProxyIfIndex connected two surfaces. Membership learned on one interface could cause Reports to be sent on another. The usual value was zero, meaning no proxying. A nonzero value meant a cache event on one side could create protocol behavior elsewhere.

One successful management request could therefore affect whether discovery ran, how quickly state expired and where membership was represented upstream. That power made the MIB operationally important. It also made an SNMP reply an incomplete outcome receipt.

A successful SET could show that the agent accepted a requested value. It did not prove that the scheduler applied the new interval at the intended moment, that the next Query left the interface, that another device received it, that forwarding state changed or that an application saw traffic.

read-create was a ceiling, not a deployment census

The module declared several objects read-create. It would be easy to infer that any conforming RFC 3019 agent had to expose the full write surface.

The compliance statements prevented that inference. For hosts and routers, mldInterfaceStatus could have minimum access of read-only. Write access was not required. More broadly, MIB conformance describes what an implementation may or must expose under a named group; it does not establish that a particular device implements the group, that its SNMP view grants the caller write authority or that a SET succeeded.

There are three separate questions:

  1. Did the schema define an object as writable?
  2. Did this agent implement writable access to it?
  3. Did this authenticated and authorized principal successfully change it at this time?

The object declaration answers only the first. A conformance claim, capability record and access-control policy are needed for the others, followed by an observed effect if the operational result matters.

The security section treated observation and control differently

RFC 3019's security section named two risk classes.

Readable objects could disclose information about multicast sessions. In particular, mldCacheSelf and mldCacheLastReporter could help identify machines listening to a group address. The RFC called unauthorized reads relatively innocuous, a judgement that belongs to its time and context rather than a universal privacy conclusion.

Writable objects presented a sharper danger. Unauthorized changes could cause denial of service. The document warned that supporting SET in an insecure environment without protection could damage network operations.

It also stated that SNMPv1 by itself was such an insecure environment. Network-layer protection alone did not decide which party on that network had permission to read or change the MIB. The RFC recommended the SNMPv3 User-based Security Model and View-based Access Control Model, placing the final configuration duty on the operator.

That sequence separates transport protection, authenticated principal, authorized MIB view and observed operational effect. Encrypting the path does not select the permitted objects. Naming a user does not authorize every SET. An allowed SET does not prove that multicast data reached a receiver.

The protocol underneath still used soft state

RFC 3019 did not redefine MLD. RFC 2710 remained the protocol source for listener reports, queries, Done messages, querier election and timers.

MLD deliberately asked a limited question: is there at least one listener for this address on this link? It suppressed redundant reports and used time to age state. A Done message triggered verification rather than serving as direct proof that the last listener had departed.

Those mechanics explain why the MIB was a projection, not an oracle. The cache compressed report traffic, local membership and timer decisions into a manageable row. That row helped operators inspect and control the system. Compression necessarily discarded part of the causal record.

The existing history of report suppression belongs to the protocol. RFC 3019's distinct contribution was to turn the resulting state into managed objects and, for some objects, writable policy. It added a new possible cause to the row: management itself.

The successor changed the model without changing the past

RFC 5519 obsoleted RFC 3019 in 2009. It combined the separate IGMP and MLD MIBs into a generic Multicast Group Membership Discovery MIB, split host and router tables and added source-filter state for IGMPv3 and MLDv2.

The later module made distinctions that the earlier two-table model could not express as fully. It also retained management and security concerns around writable interface, cache and proxy objects.

Obsolescence does not erase RFC 3019's historical boundary. Nor does the successor prove that the original module was deployed. The sources establish a standards lineage and changing schema. They do not establish a vendor implementation, operational prevalence, successful migration or incident.

That restraint matters because a MIB can look like a census. It is actually a vocabulary and contract for a management surface. Only running agents, authorized sessions and independent observation can show what existed in a particular network.

Lu Heng's Running-Code Primacy helps keep declaration and implementation separate. Reality Layers separates the schema, SET request, returned row, MLD protocol state, forwarding state and receiver outcome. Minimum Initial Specification explains why the 2001 module could be useful before the later generic and source-aware model existed, while forbidding a reader from smuggling the successor's semantics backward.

These are disclosed analytical lenses. Lu Heng did not author or endorse RFC 3019.

The cache row could be correct. The question was always: correct about which layer, produced by whom, and sufficient for what decision?

Sources