摘要

  • IESG 于 9 月 22 日就 IPv6 组播地址零配置分配草案第 12 版启动最后征求意见，拟按“提议标准”审议，意见截止 10 月 6 日；目前还不是已批准的 RFC。
  • 应用随机选取组标识符，通过 mDNS 查询 PTR 记录；听不到冲突，就按地址可用处理。主机或网络若过滤相关消息，原本存在的异议可能无法到达。
  • 草案同时指出，多数网络发生碰撞的概率很低。这是有条件的协调风险，并非已经查明的生产事故。

一台设备等了一会儿，没有收到“这个地址已经有人用”的回答。它究竟遇到了空闲地址，还是根本听不见其他设备？这两个场景在本机看来一样，却决定了零配置分配是否可信。9 月进入 IESG 最后征求意见的草案，把这一判断建立在 mDNS 消息能够互通之上。

第 12 版草案让应用在限定范围内随机选择 IPv6 组播组标识符，再计算对应的以太网组播地址。设备在拟设为特殊用途的 9.3.3.3.3.eth-addr.arpa 域下构造 PTR 记录，先探测，随后通告，并持续查询后续冲突。检测到冲突时，落败的一方停止相应组播流并另选标识符。域名保留与标准地位都仍在提案阶段，不能写成既成批准。

草案将“未收到占用提示便推定可用”称为隐含可用性，并直言主机或网络过滤 mDNS 会妨碍各应用协调，可能导致地址碰撞。它没有设置中央分配员，但并未消除控制点：网络运营者如何放行这些消息，会左右设备能看到哪些反证。随机选择降低碰撞机会；被阻断的探测不会因此变成可靠的探测。

这种风险也有边界。安全章节认为，多数网络本来就很少发生碰撞，所以过滤 mDNS 通常不是实用的攻击手段；方案还以参与者合作为前提。网络分区修复后，靠 mDNS 发现冲突可能耗时较久，是另一项有界限制，不等同于本文讨论的消息过滤。本文不据此推断任何现网发生故障。

IESG 的征求意见从 9 月 22 日持续至 10 月 6 日，尚不构成 RFC 批准。准备采用者最值得核对的不是“是否取消了人工配置”，而是共享地址空间内的设备能否相互收到 PTR 探测、通告和冲突回应。

Sources