摘要

  • draft-ietf-pim-ipv6-zeroconf-assignment-12 规定：若应用没有收到地址已被使用的迹象，就可以假定地址可用；因此 mDNS 过滤、反射器缺口或网络分区都可能把不可见误写成不存在。
  • 持久化的组 ID 只减少变动，不能跳过探测、宣告、持续查询和防御。分区修复后，冲突的失败方必须停止流、重新选 ID 并覆盖保存值，而低带宽 mDNS 可能需要相当长时间才发现矛盾。

第 12 版发布于 2026 年 9 月 22 日。冻结的 Datatracker 记录显示，它是 PIM 工作组的活跃 Internet-Draft，已提交 IESG，并处于截至 10 月 6 日的 IETF Last Call，目标状态为 Proposed Standard。它还不是 RFC，也不是已完成的 IANA 分配、互操作测试或部署报告。

草案要解决的是一个具体而狭窄的问题：应用如何在不依赖中央分配器的情况下，为 IPv6 组播流选择在链路层也不冲突的地址。首次发送，或在冲突后重选时，应用从拟议区间 0x90000000–0x9FFFFFFF 随机选一个组 ID。它把这个值与源接口标识符组合成链路范围的源特定 IPv6 组播地址，再按以太网映射规则得到目的 MAC 地址。

随后，应用把以太网地址的十六进制半字节倒序，放到 .eth-addr.arpa 下面。草案示例中的组 ID 9abc:def0 对应以太网地址 33:33:9A:BC:DE:F0，再形成 0.f.e.d.c.b.a.9.3.3.3.eth-addr.arpa。应用为它构造 PTR 记录，按照 mDNS 规则探测、宣告、响应查询、持续查询并防御记录。

真正决定风险的不是随机空间有多大，而是第 12 版新增的定义：协议采用“隐式可用性”。应用没有收到地址在用的迹象，就假定地址可用。紧接着的警告也很明确：主机或网络若过滤 mDNS，应用之间就无法协调，结果可能是地址冲突。

因此，“无人回应”不是全网事实，而是一张带边界的收据。它最多说明：在某段时间内，经由某些接口、某些链路和某些反射路径，没有观察到冲突 PTR。它不能说明被过滤的报文后面没有另一台发送者，也不能说明分区另一侧没有做出相同选择。

草案给出的随机碰撞概率是 n / 2^28，其中 n 为网络中的应用数。这个公式描述选择空间，不描述某次探测的覆盖质量。概率很低和证据完整是两件不同的事；运维系统不能用前者替代后者。

网络分区把这个差别放大。设想一台交换机故障，把同一网络切成两部分。左侧应用从存储中恢复旧组 ID，右侧新应用恰好选择相同 ID。两侧都发出探测，也都听不到反对，因为冲突信息无法穿过断点。各自看来，分配完全成功。

网络修复时，两个本地真相碰到一起。草案要求应用启动持续 PTR 查询，正是为了在分区修复后发现冲突。一旦按 mDNS 规则判定胜负，失败方必须停止发送该组播流，回到组 ID 选择，保存新值并覆盖旧值。

但发现不会必然立即发生。草案承认 mDNS 为低带宽设计，分区修复后识别资源记录冲突可能需要相当长时间，而且没有给出统一上限。若组播流可以随时建立，而不只是在分区前固定完成，问题尤其突出。补充检测机制可以考虑，但具体方案不在草案范围内。

这段延迟才是领导层需要计价的风险。系统可能同时显示两个“探测成功”的发送者；同一个以太网组播目的地址下，可能出现不同的 IPv6 组播目的地址；而只显示“PTR 已注册”的控制台仍然保持绿色。稳定的是记录外观，不一定是运行中的流。

第 12 版给主机栈增加了一种可选观测：如果发现报文使用同一个目的组播 MAC，却携带不同的目的 IPv6 组播地址，应用必须停止该流并重选组 ID。只需一方让步即可，但两方也可能同时让步。草案不规定跨主机协商谁退出，这意味着恢复行为仍需要部署侧定义和观测。

网络基础设施还有一把更强的否决权。无法自行消解冲突的组件可发布 veto PTR。它在应用标识的首个 DNS 标签后追加 -veto，使记录在字典序冲突规则中总是更晚、因而总是获胜。基础设施无需先探测就可发布；应用必须像处理普通冲突一样停止并迁移。

veto 并非永久封禁。导致冲突的 PTR 消失或过期后，发布者先查询五秒；若没有收到包含该 PTR 的响应，再随机等待 20 至 120 毫秒，发送 goodbye 使 veto 失效。应用已经保存替代 ID，所以不必把 veto 永久保存。

这种确定性优先级同时形成攻击面。草案安全章节指出，恶意参与者可以伪造探测冲突响应，让应用一直找不到可用地址；也可对已分配地址不断发布 veto，迫使应用反复迁移并停止流。能够过滤 mDNS 的攻击者还可直接消除冲突预防能力。协议依赖合作参与者，而不是通过协议创造合作。

持久化同样容易被误读。应用必须保存组 ID，并在同一流下次发送时复用。这有助于网络尽快收敛，也降低未变化网络中的未来碰撞概率。但第 12 版特意删掉了“永不再碰撞”的绝对表述，并明确说保存值不允许跳过前面的任何步骤。离线期间拓扑可能改变，所以旧 ID 仍要重新探测、宣告、持续查询并防御。

这正符合 Running-Code Primacy 的检查方式：可信的是可执行序列，不是数据库里静止的“已分配”标签。选择、派生、探测、宣告、查询、防御、停止、替换，每一步都有不同权力。持久化记录只能证明以前用过，不能证明当前观察域仍然相同。

地址协调也不等于服务发现。草案用一个 PTR 协调地址，却不规定如何把组播流地址告诉接收者。DNS-SD 的 _udp 服务加 TXT 记录只是一个自然选项，不属于地址分配证明。即便发现成功，也不能证明接收者加入了组、转发状态已建立、数据包到达，或应用真正消费了内容。

跨子网时，证据链更长。PTR 需要在子网间分发，例如借助 mDNS 反射器；草案把这种分发称为仍在研究和改进的领域。转发到其他子网的流必须改用基于单播前缀的 IPv6 组播地址，而不能继续依赖链路范围地址。由于协议假定主机合作，草案明确认为它不适用于全球互联网。

因此，共同层必须保持克制。它可以在相互可听见的参与者之间协调本地唯一性，但不能扩张为发现、成员关系、转发、交付或业务结果的权威。后面每个结论都需要自己的收据。

一份合格的运行账本至少要记录：组 ID、源接口、派生的 IPv6 与以太网地址、流标识、保存时间代；探测和持续查询覆盖的接口与子网；过滤策略、反射器可达性和分区时间代；冲突或 veto 的来源；哪一方何时停止；替代 ID 及重新探测结果。接收者加入、转发表项、包计数和应用结果必须另列。

真正的问题从来不是“mDNS 是否在运行”，而是“谁本来能够回答”。只有把时间、接口、链路、反射路径和过滤条件写进收据，沉默才有边界。否则，昨天的不可见会在今天网络修复时，以冲突的形式回来。

来源