摘要

  • 版本 2 主动删除了普遍重新评估机制；提案人随后明确，既有持有者只要地址需求不变，就不会受到影响。
  • 地址需求一旦增长，草案转入下一 nibble 边界的扩展路径；连续空间不足时，则可能新发前缀，并在六个月重编号期内归还旧分配。
  • 用十四项增长转换凭证和五个测试向量固定这条边界；拓扑、客户、使用证据和迁移排期仍留在本地或受保护的案卷中。

九个 /48 不等于九项指控

2025 年 3 月，一位参与者在邮件列表中说，自己的网络持有九个不同的 /48 PI 分配，希望把它们合并，而且最好不必重编号。他同时提到数据库对象和 DNS。

这只能当作有明确出处的一方陈述。它不是对当前持有状态的独立核验，也不能用来推算有多少网络处境相同，更不能把九个前缀直接写成浪费、囤积或违规。

但它准确暴露了问题的形状。旧集合不只是九行数据。每个前缀可能已经进入路由、反向解析、访问控制、监控目标和应用配置。后来出现一个聚合前缀，并不会自动携带九条旧身份的迁移历史。

不增长，就不应被新规则叫醒

2025 年 10 月的版本 2 公告明确说了两项删除：早期拟议的 End Site 定义被拿掉，申请新增或更大分配时重新评估地址需求的机制也被拿掉。作者希望文本更短、更容易理解。这不是无意遗漏。

后来，有人追问：已经持有多个 PI、但空间需求没有增长的网络如何过渡？提案人的回答很清楚——需求不变，就没有影响。

这条消极边界有积极价值。规则变化不应为了表面整齐，强迫一个有效且稳定的网络承担迁移风险。注册机构负责资源协调，不应成为每台设备、每条 ACL 和每个 DNS 变更的项目经理。

因此，本文并不主张追溯清理旧持有者。它只要求：当持有者主动跨出“不增长”状态时，系统必须知道是哪一个事件使规则开始适用。

一份增长申请会改变状态

围绕第 7.1.2 节的讨论给出了另一半。已经持有一个或多个 PI 的主体如果需要更多地址，应向下一 nibble 边界扩展；如果现有分配旁边没有足够的连续空间，就可以申请新的分配，并在六个月重编号期内归还此前的分配。有参与者逐段引用这一分支并质疑六个月期限，建议十二或二十四个月，或者允许有理由的延长。

期限长短仍是政策选择。本文不判断六个月必然不够，也没有任何真实案例证明有人已经错过期限。可以确定的是，草案建立了一个事件序列：

旧集合不变 → 新需求提交 → 连续性测试 → 扩展或替代 → 新旧并行 → 旧集合归还。

最后那条新前缀记录无法独自回答：哪次申请触发了转换？适用哪个文本版本？哪些旧分配进入范围？连续空间的判断来自哪个时点？六个月从何时起算？若旧集合写错，如何纠正？

现在仍是设计窗口

2026 年 6 月 15 日，工作组联合主席记录了八名支持者，并宣布拟推进到 Review Phase。邮件还说，提案人会吸收少量编辑修改，随后发布影响分析和政策草案。

这证明“准备推进”，不证明已经进入下一阶段，更不证明达成共识、采纳政策或完成系统实施。本文审阅的独立存档材料不足以支持这些更强结论。

恰恰因为还不是既成事实，转换语义才应现在写清。等到第一起真实迁移发生，再从工单和记忆中拼装规则，成本更高，也更容易让个案做法取代共同文本。

重编号不是数据库里的一次点击

RFC 4192把 IPv6 重编号写成“先建后拆”的过程：先取得并规划新前缀，把新地址加入网络，分阶段修改路由、DNS、DHCP 和静态配置，让新旧前缀并存并接受测试，最后才移除旧前缀。

RFC 5887则说明为什么这件事仍然困难。静态地址散落在设备和配置中，有些只有发生故障后才暴露；新旧并行期间，策略和监控必须同时认识两套前缀；不少运营工具对多前缀状态支持并不好。

两份 RFC 都不管辖 RIPE 的提案，也不决定六个月是否合理。它们只证明一个必要区分：注册机构作出的资源转换，与持有者在网络中完成的迁移，是相连但不同的两层。共同凭证应该连接两层，而不是让一层控制另一层。

把边界写成可复核对象

设 P0 为某一时点有序的旧 PI 集合，N0 为此前记录的需求，q 为新增或扩大申请，H 为适用文本及版本。C(q, P0) 表示保留空间和连续性判断，T 表示扩展或替代路径，P1 表示结果资源，D 表示并行、归还和完成证据。

于是可审计的转换是：

E = G(P0, N0, q, H, C, T, P1, D)。

这是 Theo March 的分析模型，不是 RIPE NCC 已发布的数据结构。它说明：在 q 以前，P0 可以合法静止；在 q 以后，旧集合、新资源和转换证据必须保持关联，否则任何人都只能事后讲故事。

十四项增长转换凭证

  1. 凭证身份。 稳定 ID 和凭证结构版本。
  2. 适用规则。 提案或政策编号、文本版本、权威摘要、状态和生效日期。
  3. 旧状态切点。 旧分配集合的精确观察时间与时区。
  4. 持有者与申请。 公开安全的持有者引用、案件 ID 和认证提交时间，不含私人联系方式。
  5. 触发类型。 无变化咨询、新增空间、更大分配或纠正，并说明第 7.1.2 节为何适用或不适用。
  6. 旧 PI 集合。 有序的分配/对象身份、前缀长度、状态和记录摘要。
  7. 需求评估。 批准、拒绝或待定，政策单位下的目标量与有限公开理由码；原始拓扑可以受保护。
  8. Nibble 目标。 申请边界、评估边界以及两者不一致的理由。
  9. 连续性证据。 保留空间快照身份、被测试的相邻范围、时间和确定性结果，不泄露无关持有。
  10. 所选路径。 扩展、替代、维持、拒绝或补充证据。
  11. 结果资源。 新增或扩展后的分配身份、前缀、对象版本和激活时间。
  12. 并行时钟。 新旧并行起点、归还截止时间、时区，以及规则允许的暂停或延长身份。
  13. 归还与结案。 应归还旧分配清单、逐项状态、完成证据和未解决例外。
  14. 纠正链。 决策权属、复核/纠正路径、被替代凭证和最终状态。

这些字段证明“谁在何时依据何规则作了什么判断”。它们不会因为申请有签名，就自动证明所有需求陈述都是真实的。

五个测试先于实施

  1. 多个旧分配、没有增长。 预期：trigger=no_change，不启动归还时钟。
  2. 存在连续空间。 合理增长可在下一 nibble 边界扩展；旧集合、保留空间判断和扩展对象保持关联。
  3. 不存在连续空间。 新发分配，明确列出归还集合，并记录新旧并行的起止时钟。
  4. 激活前撤回申请。 预期：案件以撤回结束，不启动归还期限。
  5. 旧集合或起算时间出错。 预期：追加一份替代凭证，保留原历史，不静默覆盖。

测试向量约束的是输出语义，不是工具。不同实现可以保留，但相同事实必须得到相同的转换分类。

共同层应当足够小

HENG.LU Note 64要求只把唯一性、互操作和共同安全所必需的内容写进共同层。这里需要携带的是旧/新资源身份、规则版本、触发、连续性结果、所选路径、时钟、结案和纠正。

应留在本地或受保护范围内的，是拓扑、流量、客户、使用材料、设备清单、商业理由以及具体迁移顺序。社群制定政策，RIPE NCC 评估并记录自己的决定，持有者提交事实并控制网络，独立观察者验证凭证但无权分配、路由、重编号或宣告资源无效。

这也保留了“不行动”的自由。需求未变的合法持有者无需为了新格式而合并。只有真实的权威转换被评估或记录时，共同凭证才进入场景。

来源

证据边界

已核实：版本 2 删除普遍重新评估；提案人明确需求不变不受影响；讨论文本存在增长触发的扩展/替代分支和六个月期限；联合主席拟推进下一阶段；IPv6 重编号包含新旧并行状态。

推论：单独的新前缀记录不足以重建触发、连续性、归还集合和时钟，不透明边界可能促使持有者推迟申请。

建议：实施前公布十四项凭证和五个测试向量。

未知：Review 文本、影响分析、最终期限、起算事件、例外/延长、内部案件结构、受影响持有者数量和任何生产实施。