摘要

  • RFC 9778 将 IGMP Type 与 Code 的分配改为 Standards Action，并为查询与报告扩展标志建立同一政策的登记表；这提高了审议与可见度，不会自动证明现场解析器支持。
  • 文档明确指出两种相反的安全失效：分析器拒绝不认识的新值，会造成连接中断；未经有效检查便放行，又可能形成攻击通道。
  • 上线前应分别保存标准授权、IANA 发布、实现版本、分析器判定、分阶段互通、流量影响和回退能力的凭据，不能把七件事压成一个“兼容”标记。

一行 IANA 记录很容易给人完成感。编号、名称、引用文件都已齐全，看上去只剩启用开关。然而，对组播控制报文而言，每增加一个字段取值，也是在防火墙、入侵检测、交换芯片与排障解码器里增加一条尚未验证的分支。

RFC 9778 于 2025 年 3 月发布，属于 BCP 57，并取代 RFC 3228。它把 IGMP Type 登记政策改为 Standards Action；IGMP Code 也使用 Standards Action，而定义新 Type 的文件必须同时说明该 Type 的 Code 如何分配。文档还为 RFC 9279 的扩展机制建立两张登记表：Query flags 中第 0 位为 E，第 1 至 3 位未分配；Report flags 中第 0 位为 E，第 1 至 15 位未分配。两张表同样需要 Standards Action。

MLD 的边界并未因此被抹平。MLD 的 Type 与 Code 仍属于 ICMPv6 Parameters 登记体系，适用 IETF Review。这里的精度很重要：标准记录的是每一个命名空间由谁决定，而不是给所有相似字段套上同一权威。

高门槛解决的是“谁能分配”

RFC 8126 对 Standards Action 的定义，使新值必须出现在经 IESG 批准的 Standards Track RFC 或 BCP 中。它带来的好处是真实的：提案更早暴露给协议作者、安全审阅者和实现者，语义有稳定引用，随意占号的空间变小。

但它只回答一个有限问题：该值是否经过规定的共同决策程序。它没有观察某个现场固件，也没有执行某条防火墙规则；不会证明 IDS 能显示正确名称，更不会证明故障时能在目标时限内撤回。

RFC 9778 自己点出了运行层风险。安全分析器依赖字段含义清晰。遇见未知新值时，有的设备可能拒绝，于是合法成员关系报文消失、组播连通性受损；另一些设备可能继续转发，却没有对新增语义进行有效检查，于是表面畅通，安全可见性反而下降。这两种结果方向相反，却都不能从登记表推断。

RFC 6709 给出了更广的扩展教训：曾经要求为零的位、未知扩展、部分实现和静默丢弃，都可能制造互通或安全退化。RFC 9279 则提供了邻近机制的例子：不支持但格式正确的扩展 TLV 应被忽略，格式错误的结构要经过明确校验。只有实际解析器和策略引擎能证明这一区分是否真正存在。

不要用一个收据证明七个事实

稳健的上线档案至少要拆成七份。

第一份是授权凭据：哪份标准、哪种程序批准了取值。第二份是发布凭据：IANA 表在什么时间呈现什么状态。第三份是实现凭据：具体软件、固件、解码库或规则版本声称支持哪些字段。第四份是分析凭据：面对已知、未知、畸形和混合版本样本时，设备实际给出什么判定。第五份是互通凭据：新旧发送端、接收端和中间控制在隔离环境中的组合结果。第六份是影响凭据：加入、离开、丢包、时延、告警、CPU 与误报如何变化。第七份是回退凭据：能否只撤销新增发射或规则，不牵连无关流量。

这些凭据不能互相继承权威。IANA 已发布时，实现仍可能不存在；语法解析通过时，策略仍可能落入旧的默认分支；实验室两端互通时，中间设备仍可能拒绝；包已经穿过防火墙时，也可能只是未判定放行。Heng Lu 所强调的运行代码优先与现实层次，在这里并非否定登记制度，而是要求每份记录只对自己观察到的层次负责。

一个可以安全失败的试验

以下是示范性的验证设计，不代表任何真实厂商或网络已经测试。

先盘点所有会读取 IGMP 或 MLD 的环节：主机协议栈、交换芯片、路由进程、防火墙、入侵检测、报文代理、采集器和排障工具，并保存运行版本与相关配置摘要。用旧报文建立基线，再依次加入拟上线的 Type、Code 或 flag，同时加入未分配值、格式正确但不支持的扩展、长度或校验和错误，以及新旧对端混用。

每一跳都要记录具体动作：识别并命名、按明确规则忽略、拒绝、告警，还是未形成语义判定就放行。把这些动作与成员状态及数据面结果对齐。防火墙之后还能抓到包，只能证明包通过，不能证明它接受过有效检查。

最后在有流量预算的有限区域做金丝雀验证。事先写明停止条件：拒绝率异常、报告缺失、分析器回落、资源压力、状态分叉或无法解释的组播丢失。保留旧发送行为和旧策略为两根独立的回退杠杆，并实测恢复时间与旁路影响。

来源

  1. RFC 9778 — IGMP/MLD 的 IANA 考量
  2. RFC 3228 — IPv4 IGMP 的 IANA 考量
  3. RFC 8126 — RFC 中 IANA 考量章节的编写指南
  4. RFC 6709 — 协议扩展的设计考量
  5. RFC 9279 — IGMPv3 与 MLDv2 扩展
  6. RFC 9776 — IGMPv3
  7. RFC 9777 — MLDv2
  8. RFC 4443 — ICMPv6
  9. IANA — IGMP Type Numbers
  10. IANA — ICMPv6 Parameters
  11. Heng Lu — 运行代码优先
  12. Heng Lu — 最小初始规范与本地化未来决策
  13. Heng Lu — 现实层次与符号权力