摘要

  • RFC 3307 把 0x80000000-0xFFFFFFFF 同时交给服务器动态分配和主机动态分配，其中最高一段还与 Solicited-Node 组播重叠。两个遵守规则的分配器也可能选中同一个组标识符。
  • RFC 10028 建立六段式 IANA 注册表，把 MADCAP、未分配空间、SSM 主机分配、私用、实验和 Solicited-Node 分开。它消除的是分配区间重叠，不是所有网络层、链路层或硬件碰撞。
  • Mike McBride 与 Nate Karstens、Dino Farinacci 共同撰写该 RFC。注册表负责保持公共命名空间互斥；实现版本、SSM 条件、转发结果、来源与听众权限仍须由运行证据回答。

这次修复没有从抓包里找到第一个坏字节。它先在规范的表格里发现了一块被重复出租的土地。

RFC 3307 为动态 IPv6 组播组标识符规定了两条路。服务器可以分配，MADCAP 就是一套客户端向服务器申请组播地址的协议；主机也可以自行选择，为无配置环境留下空间。问题在于，两条路都拿到了完整的 0x80000000-0xFFFFFFFF。最高的 0xFF000000-0xFFFFFFFF 又已经承载 Solicited-Node 地址。

于是服务器和主机不需要犯错。它们各自照章办事，就有机会产出同一个低32位值。这类故障比“某个实现不合规”更值得警惕，因为错误位于公共规则：规范没有让不同的选择权彼此互斥。

2026年8月发布的标准轨 RFC 10028 修改了这项安排。作者是 Nate Karstens、Dino Farinacci 和 Mike McBride。本文以 McBride 为人物入口，不把集体工作改写成个人发明，也不把他写成 IANA 或任何网络的决策者。

截至2026年8月31日保存的 IETF 档案显示，McBride 担任 PIM 主席，是 MBONED 与 ANIMA 的代表、路由领域审阅者，并参与九份 RFC；RFC 10028 将其单位列为 Futurewei。Open Networking Foundation 的2017年文章提供了带日期的职业自述。这些资料确认人物与专业背景，不证明他个人控制注册表、厂商代码或运营网络。

同一个号码为何会落到链路层

IPv6 组播地址不只有组标识符，但 RFC 3307 把低32位定义为 group ID。以太网上，这些位会直接映射到链路层组播地址。因此，重复值不只是数据库里有两条相同记录；网卡与交换机可能需要把本应不同的流量放到同一链路目的地址下处理。

MADCAP 的控制模型是“向服务器申请”。未来的 zeroconf 主机协议则希望摆脱服务器，让节点自行选择。两者都可以合理存在，却不能把“我从公共大区间里挑一个随机值”当成共存合同。随机只能调低概率，不能取消两个机制对同一空间的合法主张。

RFC 10019 从无配置环境进一步解释风险。它要求解决方案允许多应用、多个分配机制共存，并在网络层与链路层检测、处理碰撞。网络临时分区时，两边还可能独立选择；重新连接后，冲突才显现。规范若先让服务器和主机共享全区间，后续算法就背上了本可避免的负担。

Solicited-Node 的重叠更直接。Neighbor Discovery 会从单播或任播地址派生相应组播地址。它不是某个动态分配器临时发明的用途，却被旧动态范围整个包了进去。RFC 10028 先把这块建筑用途在地图上标出来。

六段注册表说了什么

IANA 的 Dynamic Multicast Group IDs 注册表初始包含：

  • 0x80000000-0x8FFFFFFF：MADCAP；
  • 0x90000000-0xEFFFFFFF：未分配；
  • 0xF0000000-0xFCFFFFFF：SSM 组地址的主机分配；
  • 0xFD000000-0xFDFFFFFF：私用；
  • 0xFE000000-0xFEFFFFFF：实验用途；
  • 0xFF000000-0xFFFFFFFF：Solicited-Node 组播地址。

普通未分配空间未来要经 Standards Action 才能划出。每项只有区间、描述和参考文件。注册表不保存使用者名单，不宣布某个产品已经升级，不决定应用如何找到来源，也不回答一条流是否抵达听众。

这不是功能欠缺，而是权限边界。公共层只需要阻止两个机制被正式指向同一段标识符。应用政策、软件选择、网络部署与故障处置，留给能观察并承担后果的主体。

同时，六段并不等于“组播不再碰撞”。两个完整 IPv6 地址可能在低32位相同，从而映射到同一以太网地址；交换机的有限表项或哈希桶可能把更多组挤到一起；分区重连会暴露独立选择；恶意流量也能使用格式正确的地址。RFC 10028 去掉的是“分配机制的区间本来就重叠”这一类原因。RFC 10019 要求的碰撞检测与解决仍然存在。

因此，文章标题里的“只”不是修辞。注册表防止了一种碰撞，没有宣布碰撞问题终结。

SSM 的额外坐标必须真的存在

主机分配段专门写明 SSM。Source-Specific Multicast 用 (S,G) 标识信道：来源加组。RFC 4607 指出，不同来源可以复用相同的 G，因为完整信道仍不相同。相比只看组的 ASM，这减少了为每个组值做跨主机协调的必要。

但来源坐标不会从十六进制区间里自动长出来。应用要知道 S，主机要能表达特定来源加入，通常需要 IGMPv3 或 MLDv2；指定路由器与组播路由域也要保持 SSM 语义。RFC 8815 推荐跨域组播转向 SSM，恰恰也说明应用、操作系统和接入设备的支持是部署条件。

RFC 10028 明说 SSM 并非普遍支持。0xF0000000-0xFCFFFFFF 是给支持 SSM 的环境，不是一张让旧网络立即支持 SSM 的许可证。地址选对了，不等于 MLDv2 已启用、PIM 状态已建立、来源可信或听众获准接收。

在这里，Heng Lu 的“最小初始规范”与“运行代码优先”提供了合适的证据纪律。公共规范只集中互操作所必需的边界；未来选择尽量本地化；变化是否真实，要看自愿采用与运行结果。这不是把 IANA 协议注册表等同于 RIR，而是拒绝让登记声明冒充部署证据。

MADCAP 的旧版地图仍可能留在设备里

RFC 10028 把 MADCAP 的可用区间大幅缩小。文件称，撰写时已知只有一套实现，没有已知的大规模部署。这里的关键词是“已知”。它描述作者的公开证据范围，不是“世界上绝对没有”的普查结论。

旧实现要么改用 0x80000000-0x8FFFFFFF，要么被隔离在没有其他 IPv6 组播地址分配协议的环境中。IANA 页面更新不会改写旧二进制，也不会自动修补无人维护的设备或多年复制的配置。

所以迁移回执必须把号码与生产者连起来：分配器名称和版本、所用机制、有效配置、规则快照、选择时间和实测结果。只记录完整 IPv6 地址而不记录“谁按哪张表选的”，发生冲突后就难以区分旧 MADCAP、合规 SSM 主机、映射压缩或恶意使用。

还有一个容易被忽略的激励偏差。新机制通常更可见、日志更完整。它与旧服务器相撞时，值班人员可能先关闭新机制，因为它是最近的变化；没有来源证据，组织反而保住了违反现行分区的旧代码。

让每一层只证明自己的事实

RFC 记录证明 IETF 做出了标准决定。IANA 页面证明公开注册表当前写了什么。实现测试证明某个分配器是否待在自己的区间。(S,G) 控制与转发测试证明特定路径上的 SSM 行为。来源验证与听众授权又是另外的记录。

这些证据不能互相继承。

注册表行不证明厂商覆盖率；SSM 地址不证明路由路径支持；收到包不证明来源合法；一次未碰撞不覆盖其他 scope、拓扑、分区或硬件压力。

一个足够薄的运营台账应保存：分配器及版本、机制、group ID、完整地址、RFC/IANA 快照、SSM 前提、碰撞检测方法与结果、转发观察、来源验证、听众授权以及回滚负责人。它延续了 RFC 10028 最有价值的品质：每个字段都不越过自己的证据能力。

McBride、Karstens 与 Farinacci 没有许诺一张表就能让组播运行。他们让公共规则不再主动制造一个可避免的重叠。

注册表给出了互不重叠的车道。网络仍须拿出自己已经换道的证据。

资料来源