摘要

  • IETF Datatracker 记录显示，draft-ietf-pim-gaap-23 于 2026 年 9 月 3 日提交，文档进入 AD Followup；它仍是实验性 Internet-Draft，不是已批准的 RFC。
  • 第 23 版规定 IPv4 必须使用 239.0.0.0/10，IPv6 必须使用 RFC 10028 的实验用途 Group ID 范围，使彼此独立的实现从同一个地址空间开始计算。
  • 新文本也明确指出：分区一侧可能为同一组名选择 +1 候选，另一侧选择 +2。两个地址彼此不同，因而不会触发冲突，链路恢复后组仍可能分裂。
  • 零冲突只是否定性观察，不能证明组名、地址和预期成员已经重新会合。
  • 为实验保存一份本地“组名会合凭据”可以补上证据，但这是 Daniel Kade 的分析建议，不是 IETF 或草案要求。

先消除一种配置分歧

GAAP 文档历史把第 23 版的日期记为 9 月 3 日。同一天，文档子状态从 Revised I-D Needed 变为 AD Followup，IANA 审查状态回到 Version Changed - Review Needed。Datatracker 主页显示的仍是一份工作中的草案。这些流程变化说明审查在继续，并不表示 IESG 已经批准，更不表示文档已经成为 RFC。

第 23 版的变更记录称，它处理了 Éric Vyncke 的 IESG DISCUSS 与 COMMENT。真正值得关注的不是状态标签，而是修订版同时划出了两类分歧：一类可以靠统一输入消除；另一类即使输入统一，也可能悄然留下。

GAAP 要解决的是无需中央分配服务的组播组地址选择。应用提供一个组名，协议只允许计算四个 SHA-256 候选：原组名，以及分别附加 +1、+2、+3 的字符串。节点先为第一个候选发送 Claim，再等待大约一个周期，约一分钟。若没有收到“另一组名使用同一网络层地址”的声明，应用便可开始使用该地址；若发生这种冲突，则尝试下一个候选。

这套设计刻意减少共享状态。节点不必缓存别人的全部 Claim，只跟踪本地应用已经分配的组名、地址与周期定时器；重启后再用新的声明重建软状态。去中心化和轻量化由此获得，但有一个前提：不同团队写出的实现至少要使用同一套基础参数。

第 22 版到第 23 版的官方差异正是在补这个前提。此前，应用使用的地址范围由运营方配置。新版认为，这种可配置范围只能与相同配置可靠互通，因为运营方无法控制每个应用最终采用哪一种独立 GAAP 实现。

因此，IPv4 实现必须统一使用 239.0.0.0/10。草案以 RFC 2365 中可供扩展 Organization-Local 作用域的地址块及 RFC 5771 的分配规则为依据。IPv6 则必须使用 0xFE000000–0xFEFFFFFF，即 RFC 10028 为新动态分配协议实验保留的范围。这个 IPv6 范围并不由 GAAP 独占，其他实验也可以使用。

固定范围是一项实质性的互操作决定。它避免两个合规实现还没开始哈希，便进入彼此不相交的地址宇宙。但它只能保证共同的计算场地，不能保证各节点最后为某个组名选中同一个位置。

链路愈合，并不等于状态会合

GAAP 的分区修复首先处理一种可见情况：分区两侧为同一个组名使用了同一个地址。连接恢复后，双方的 Claim 相遇，协议能够比较并处置这一状态。

第 23 版新增说明的情况更安静。假设左侧出现一项无关的本地冲突，使共同组名从基础候选退到 +1；右侧因另一项本地冲突，把同一组名推到 +2。双方都遵守四个候选的封闭列表，在各自分区中也都没有未解决的地址冲突。

链路恢复时，一侧声明地址 A，另一侧声明地址 B。因为地址不同，GAAP 所定义的“同一地址被不同组名占用”并未发生。草案明确写道：此时没有东西发生碰撞，组在愈合后仍保持分裂，如何解决属于实验的开放问题。

Éric Vyncke 早先在 IESG 表决意见中问的正是这一点：两个分区分别使用 +1 与 +2 时，系统是否能检测并让所有人收敛？修订版如今把问题写进规范边界，但尚未给出会合机制。

于是，相同的“零冲突”读数可以对应两种完全不同的事实：

  • 一个组名映射到一个地址，成员成功会合；
  • 一个组名映射到两个地址，成员仍分成两群，只是双方没有争用同一个地址。

冲突是需要排除的负面事件。它没有出现，并不能自动证明会合这一正面属性。若监测系统只保存冲突次数，不保存组名到地址的映射，分区恢复看起来会非常平静，应用参与者却仍无法相遇。

GAAP 引用的 RFC 10019要求零配置组播地址方案能够检测并妥善解决临时分区带来的地址冲突。这个目标仍然成立。第 23 版揭示的是相邻但不同的对象：不是一个地址上的冲突，而是一个名字下的两种答案。因此，“冲突已解决”与“组名已会合”必须成为两项独立结论。

实验必须留下正面结果

草案对成熟度的表述很克制。它说，基于哈希的去中心化组播组地址分配尚未部署；实验需要判断现有冲突检测和修复机制是否适合实际环境，观察不同规模下的冲突率，并测量大量节点周期发送 Claim 时的扩展性。实验的结束条件，是运行经验支持未来进入 Standards Track，或暴露需要修订的根本限制。

静默分裂已经属于这个实验范围。单纯统计“发生多少次地址冲突、修复多少次”永远无法计算同一组名在两个非冲突地址上停留了多少次，因为后者不会进入冲突计数器。真正的观测对象应是分区前后完整的组名—候选—地址关系，以及预期成员是否重新通过同一个组通信。

这份证据无需变成中央地址登记服务。实验方可以在本地保存一份“组名会合凭据”，绑定经过隐私保护的组名标识、分区两侧或测试队列、各自使用的候选序号、最终地址、分区与恢复时间、发现路径、恢复后的成员可达性，以及修复决定和结果。审查者据此只能作出三种诚实判断：已观察到会合、已观察到分歧，或证据不足。

这份凭据是我的编辑分析建议，不属于 GAAP 文本，也不是 IETF、IANA 或 PIM 工作组的要求。它只解决一个治理问题：不能把“未观察到负面事件”包装成“已经验证正面性质”。

Lu Heng 在 Minimum Initial Specification, Localized Future Decision 中区分共同所需的最小初始规范与可在本地演进的未来选择。固定地址范围正是前者；对罕见分裂的发现、存储和修复方式可以继续实验，但结果必须可以比较、可以追溯。

Running Code Primary则确定了证明顺序。文档进入下一状态、IANA 分配号码或 DISCUSS 被解除，都只改变制度记录。只有运行测试能够让两个实现经历不同的本地冲突、形成 +1/+2 分歧、恢复链路，再证明它们最终是否回到同一映射。

第 23 版的价值，恰恰是没有用固定范围掩盖这个未决问题。下一步也不应以流程进展替代结果，而应把“是否会合”本身变成可观察、可复核的实验事实。

来源

  1. GAAP Datatracker 页面
  2. GAAP 文档历史
  3. GAAP 第 23 版
  4. GAAP 第 22 版
  5. 第 22—23 版官方差异
  6. GAAP 的 IESG 表决意见
  7. RFC 10019：零配置组播地址分配问题
  8. RFC 10028：IPv6 动态组播 Group ID
  9. RFC 2365：管理作用域 IP 组播
  10. RFC 5771：IPv4 组播地址的 IANA 指南
  11. Lu Heng — Minimum Initial Specification, Localized Future Decision
  12. Lu Heng — Running Code Primary