摘要

  • RFC 10019 是一份信息性问题陈述与需求文件：它约束未来机制应如何被检验，而不是替网络选择一个现成地址。
  • 地址选择、链路层唯一性、碰撞恢复、报文转发和接收结果各自需要不同证据，不能由同一份 RFC 互相代替。

“自动分配”在采购说明和产品演示里很容易变成一个完成时态的词：仿佛没有人配置、没有中心服务器，就等于地址已经安全地被分配、流量已经正确送达。RFC 10019 不允许这种跳跃。它在 2026 年 7 月以 Informational RFC 发布，并非 Internet Standards Track 文档；它没有 IANA 动作，也没有规定一个完成的分配协议。

文件先解释为什么问题值得被拆开处理。不同的 IP 组播组可能映射成相同的链路层地址。网络接口无法区分它们时，可能把本不需要的流量交给软件过滤，增加 CPU 成本。能力有限的 snooping 交换机可能把高带宽流送入未请求它的链路；有限的转发表或哈希桶也可能造成新的压力。这些是设计约束，不是某一艘船、工厂、音视频系统或传感器网络已经发生故障的证据。

Farinacci 在这里是三位共同作者之一，而不是某项网络部署的负责人。RFC 对未来方案提出的第一项硬要求，是在网络层和链路层都实现唯一地址。随后还要求尽量避免单点故障、无需用户或管理员配置、可与手工和既有动态分配方式共存、能在单一子网运行、不依赖外部连通性，并允许同一主机的多个应用独立分配。第八项要求尤其关键：机制必须能够检测并解决两个层次的地址碰撞。

这是一把量尺，不是一张合格证。某程序展示它选到了一个组地址，不能证明其链路层映射没有冲突；一份源代码或版本公告，不能证明该代码已在某网络启用；一次孤立子网的测试，也不能证明临时分区后两个部分各自选中同一地址时会如何恢复。RFC 明确要求网络重新连通后应检测和化解这类冲突，却没有声称任何实际系统已经完成这种恢复。

它还保留了另一条很重要的边界：地址分配之后如何使用该组地址，不在本文档范围内。分配器不能授权发送者，不能替运营者配置转发，不能证明监听者存在，更不能保证接收端处理了内容。安全章节同样未指定具体安全机制。即使地址唯一，一个服务依然可能不可达、被误用或没有人接收。

这也是衡量零配置声明的工作方法。先问证据到达哪一层：RFC 能证明共同体确认了一组未来设计条件；特定版本的实现材料能说明开发者试图满足它；受控测试能说明某个拓扑中的行为；抓包、接口计数和交换机记录才可能说明某个时间点的观察。任何一层都不能悄悄借用下一层的权威。

Lu Heng 的“最小初始规范”和“运行代码优先”可作为这里的证据纪律，而不是把局部组播问题拔高成治理主张：共同部分只写到互操作确有需要之处，剩余选择留给运行网络的人，再用实际运行和可复核观测评价结果。RFC 10019 做的是第一步；后面的实现和运营责任仍然在网络里。

来源