摘要

  • RFC 3019 用接口表和缓存表呈现 MLD 状态，但其中多项也是控制入口：管理者可以启停 MLD、创建或删除缓存行、声明本机成员、调整查询计时器和指定代理接口。
  • 因而，一行缓存、最后报告者地址或一次成功 SET，只能证明代理表示了某种状态；它们不能单独证明远端听众、授权意图、转发、报文送达或应用接收。

排障屏幕上出现一行组播地址时，人很容易把它读成一句完整的话：这个组有人听。

RFC 3019 的原话看起来也支持这种直觉。它把 MLD Cache Table 描述为“列出特定接口上有成员的 IPv6 组播组”。表中还能给出最后一次成员报告的来源地址、表项存活时间和到期时间。

但同一份规范又允许管理者创建这行、删除这行，并把“本机是否为成员”设为真。接口表还允许管理者启停 MLD、修改时间参数、设定代理接口。

因此，真正的问题不是这行是真是假，而是它在哪一层为真、由谁产生，又足以支撑什么决定。

两张表压缩了不同时间的事实

RFC 3019 定义了 MLD Interface Table 和 MLD Cache Table。前者每个启用 MLD 的接口一行，后者每个“组播地址—接口”组合一行。主机与路由器都可以实现它们，一些对象只适用于路由器。

接口行同时容纳配置和观测：查询周期、最大响应延迟、MLD 版本、Querier 地址、累计 join 次数、当前组数、Robustness Variable、最后听众查询间隔、代理接口以及 Querier 相关计时器。

这些值不是同一种收据。累计 join 讲的是过去发生过多少次表项加入；当前组数讲的是此刻代理有多少缓存行；Querier 剩余时间讲的是在没有新消息的条件下将发生什么；可写间隔则表达管理策略。

缓存行也一样。mldCacheSelf 是本机成员状态，mldCacheLastReporter 是最近收到的报告来源，uptime 与 expiry 描述生命周期，mldCacheStatus 则是行的管理入口。

把它们显示在一个面板上有用，把它们合并成一个更强的结论则危险。

“最后报告者”不是当前听众名单

mldCacheLastReporter 的定义很窄：在这个接口上，为这个组最近收到的 Membership Report 的 IPv6 源地址。如果从未收到，值为 0::0。

“最近”只描述观测顺序。它不等于“仍在监听”，也不等于“唯一成员”。

RFC 2710 的 MLD 只需要让路由器知道链路上是否至少有一个听众。主机听到其他主机为同一组报告后，可以取消自己的待发报告。于是一个地址可能代表多台主机共同抑制后的最后一次可见发言。该地址随后离开，另一个成员仍可能维持状态；本机成员也可能单独维持它。

mldCacheExpiryTime 同样不是活跃证明。它表示表项老化前至少还剩多少时间。零可能表示表项只因 mldCacheSelf 为真而存在，本机一离组便立即老化。规范还允许实现把本机报告与其他主机报告同样处理，所以这种情况下也不要求一定显示零。

要声称“某个远端听众仍在”，至少要保留报告时间、计时器 epoch、本机成员状态和代理连续性。要声称“应用收到数据”，还要有转发与接收侧的独立证据。

管理面可以写入随后读出的事实

mldCacheStatus 的访问级别是 read-create。管理者可以创建新行，也可以删除已有行。基础合规组更明确地说，这组对象就是为了允许 manager 创建和删除 MLD 缓存项。

mldCacheSelf 也是 read-create，默认值为 true。

因此，一行缓存至少有三种来源：链路上的 Membership Report、本机加入、管理操作。它还可能因计时器尚未到期而继续存在。当前表项本身未必保留这条因果链。

假设自动化系统为了测量而创建一行，然后重新 GET 这张表。读回成功可以证明代理接受并保存了请求的表示。它不能独立证明远端主机发过 Report，因为写入与验证发生在同一证据面。

这不是反对可写 MIB。问题在于，控制记录不能冒充外部事件的独立见证。

一行接口状态足以关掉 MLD

mldInterfaceStatus 不只是描述行是否存在。激活该行会在接口上启用 MLD，销毁该行会禁用 MLD。

其他可写对象可以改变 Query 频率、最大响应窗口、丢包容忍度和最后成员离开时的验证速度。缩短最后听众查询间隔会更快移除状态，也会缩短回应保留状态的窗口。

mldInterfaceProxyIfIndex 又把一个接口的学习结果传到另一个接口：在下游学到的成员关系，可以让设备在指定上游接口发送 Report。零表示不做代理，非零则把本地表项变成远端协议动作的原因。

所以，一次 SET 可能改变发现、过期和上游表示。SET 响应只能说明代理处理了请求。它不证明下一次 Query 确实发出、邻居确实收到、组播转发表确实改变，或者应用确实收到有效数据。

read-create 不是实现能力普查

看到 MIB 中的 read-create，还不能断定所有合规设备都开放写入。

RFC 3019 的主机与路由器合规声明允许 mldInterfaceStatus 的最低访问级别为只读，并明确说不要求写访问。对象声明给出了模块允许的上限；具体合规组、实现能力、VACM 视图与当次授权仍是另外的问题。

需要分别证明：规范把对象设计成可写；此代理实现了写入；这个主体被授权；这次请求成功；运行中的 MLD 与数据面产生了预期变化。

RFC 2579 的 RowStatus 定义了通用行生命周期，但 active 只说明管理行状态。它不证明重启后持久化、协议同步，更不证明数据面结果。

安全部分把暴露和破坏分开处理

RFC 3019 指出，可读对象可能泄露组播会话信息。mldCacheSelf 和 mldCacheLastReporter 能帮助识别与某组地址相关的机器。文档把未授权读取称为“相对无害”；这是当时文本的判断，不应被扩展成普遍隐私结论。

未授权写入则可能造成拒绝服务。在没有适当保护的环境中支持 SET，会对网络运行产生负面影响。

规范明确说 SNMPv1 本身属于这种不安全环境。即使网络层用了 IPsec，也仍然没有回答网络中的谁被允许访问和修改对象。因此它推荐 RFC 2574 的 SNMPv3 用户安全模型和 RFC 2575 的基于视图访问控制。

通道保护、主体认证、视图授权、SET 接受、协议生效、转发变化和应用接收，是七张不同的收据。上一张不能替下一张签字。

后继规范扩大模型，却不能改写旧行

RFC 5519 在 2009 年取代 RFC 3019 与 IGMP MIB。它用一个通用 MGMD MIB 同时覆盖 IGMP 和 MLD，分开主机与路由器表，并为 IGMPv3/MLDv2 加入 source filtering 状态。

后继的扩展说明早期两表模型表达能力有限。它不能让 2001 年的旧行自动拥有后来的源列表与角色分离。它也不能证明某个产品实现、部署或迁移过任何一版。

这些 RFC 证明的是设计谱系，不是生产事实。

本文明确借用 Lu Heng 的分析框架。Running-Code Primacy 把模块声明与运行代理分开；Reality Layers 把表行、报告、策略、转发与接收分开；Minimum Initial Specification 说明小而有限的早期接口为何仍有价值，也禁止读者把后继能力倒灌回来。

Lu Heng 并非 RFC 3019 的作者，也没有为它背书。

缓存行可以完全正确。它正确表达的是代理当前承认的状态，而不是整个网络已经发生的全部事实。

Sources