摘要

  • RIPE 地址政策工作组主席代表在 2026 年 9 月 24 日的邮件中明确宣布，编号 2024-01 的 IPv6 PI 修订提案已经撤回，将被归档，任何人仍可按政策程序重新提出议题。公告没有解释撤回原因，也没有宣布草案某个条款获得通过。
  • 9 月 27 日直接核查时，第 3 版提案页仍显示审议阶段“开放讨论”。较晚发布的工作组公告是本次处置的明确证据；页面状态滞后则是公众查证时遇到的记录矛盾，不能据此推断有人故意隐瞒，或草案仍能走向实施。
  • 申请仍应看现行 RIPE-738及RIPE NCC 的 PI 申请说明：PI 最小为 /48，更大规模须说明需求；不能因旧草案曾讨论同一地点内向外部实体分配前缀，就把该做法当成现行许可。
  • 撤回不是废止已生效的规则，因为 2024-01 从未成为规则；也不是对所有技术争点的终局裁决。RIPE 政策制定程序允许议题重新进入公开讨论，但未来文本、进度与结果都不能从旧提案编号直接继承。

一份申请面前，站着两份不同性质的文件

设想一个网络经营者需要比现有 /48 更大的 PI 空间。它可能有多个站点、独立路由需求，还希望保留向相邻地址扩展的余地。2024-01 第 3 版给出了按四位边界发放地址块的设想，提到连续空间预留，也讨论在不能直接扩展时取得新块、迁移并交还旧块。对规划工程师来说，这些不是抽象口号：它们会进入地址方案、工期、设备配置，甚至写进与客户的承诺。然而，出现在草案里与今天可以据此申请，是两个完全不同的事实。

9 月 24 日的工作组邮件给出了清楚而有限的处置：提案已撤回，随后会归档；任何人仍可重新提出相关议题。邮件没有说是哪位作者基于何种考虑退出，也没有公布表决结果、共识失败认定或董事会否决。RIPE NCC 此前对草案提出过严厉的实施评估，不等于我们可以倒推它就是撤回的原因。把一项处置说得比证据更多，会把程序记录写成小说。

三天后的提案页面仍把第 3 版标在审议阶段，状态为“开放讨论”；所检索的归档索引尚未显示 2024-01。网页更新有先后，这种延迟可以解释记录不一致的可能方式，但不能被当作已证实的内部原因。申请人可以确认的是：工作组较晚的明确公告和较早的页面标签不一致。不能确认的是后台何时更新、谁延迟了更新、是否存在蓄意操作。把可见的矛盾和不可见的动机分开，才不会使一篇本来用于校准政策状态的文章也成为新的误导。

因此，判断顺序应当简单：用有日期的工作组消息确认这份提案的去向；用正式公布的现行政策确认申请规则；用 RIPE NCC 当前申请指南确认如何提供材料；把已撤回草案及其影响分析留作公共讨论史。BGP 上正在通告的前缀、注册簿里的持有人、客户网络的配置，又各有自己的操作状态。政策网页的标题不能替这些状态自动改写任何一项。

为什么原来的大包裹值得认真读

撤回的第 3 版并非只想把 /48 换成 /44。它同时修改拟议中的第 2.6 节用途和转分配边界、第 5.4 节从分配池划拨给终端用户的描述，以及第 7.1 节下 PI 大小、四位边界、扩展和无法扩展时的迁网安排。现场由谁运营、地址给谁用、能否为增长预留连续空间、既有地址怎么退出，原本就相互牵连。支持把它们放在同一份文本中的最佳理由，正是可以让工作组同时看见这些相互作用，而不让一条看似轻松的规模调整把风险转嫁给另一条未讨论的规则。

在这一点上，RIPE NCC 随提案发布的影响分析有实质价值。它认为如获通过，软件、流程、文档与培训改动都较大；若新要求难以核查，注册数据准确性与责任归属也可能受影响。它指出，允许新发放的块立即或部分转移，可能把按四位边界保留的增长空间割裂掉。它还列出此前持有 PI 的机构如何过渡、六个月迁网未完成怎么办、24 个月计划未完全兑现时怎样处理等难题。RIPE NCC 董事会建议修订草案。

这说明为什么把一揽子规则投入实施绝非只改几个表单字段；却不能说明 9 月 24 日公告没有写出的因果结论。影响分析是在问“如果通过，代价和冲突是什么”，不是在宣读撤回理由；董事会对草案的修订建议，也不能被改写成董事会代替工作组作出政策否决。RIPE 的 PDP把公开讨论、审议、最后征询和秘书处提供材料的职责分开。值得维护的，正是讨论证据与处置权限之间的界线。

草案退出后，仍然在场的规则

RIPE-738是目前已公布的 IPv6 地址分配与指派政策。它规定 PI 指派最小为 /48；超过这一规模的需求，要按现行标准说明地址使用或不同路由需要。PI 不能再以子前缀转分配给其他机构；LIR 持有 PI 的情形也围绕自身基础设施，而非客户末端站点。RIPE NCC 的申请指南则把申请材料说得更具体：要更大的地址块，应提供相关依据；向外部方分出前缀，即使是 /64 或 /96，也不能仅凭 PI 指派去做。单个地址与前缀在这条边界上不是一回事。

现行规则并不意味着任何人都绝不可能取得大于 /48 的空间。把撤回写成一项新的绝对禁令，同样错误。正确的问题是：这家机构按目前的规则，能证明怎样的地址需要或独立路由要求？其服务对象是不是另一个机构的独立站点？向对方交付的是个别地址、上游地址空间，还是 PI 前缀？这些事实需要在正式申请中说明，而不是从已经退出政策流程的 2024-01 设想中借一个答案。

既有持有人也不应把“撤回”误解为“收回”。它不自动注销任何 PI 资源，不命令已运行的网络迁址，不改变 RPKI 对象，也不从全球路由表撤下一条通告。草案未获实施，就谈不上因为撤回而回滚其实施。若未来某项正式政策真要改变这些结果，必须另有文本、程序、执行范围和对应的操作记录。这种谨慎不是替机构争取不受监督的空间，而是防止制度标签越过网络实际控制与持有人责任。

可以重新讨论，不能继承一份未取得的授权

工作组主席说任何人可以再次提出这个议题。这为 PI 规则的改善保留了道路，却没有宣布第 3 版会复活，更没有预定它会赢得共识。后来的提案可以更窄地处理同一地点的用途、较大 PI 的证明、连续空间预留与转移的关系，或既有持有人的过渡。但每条道路都要提交文字、面对反对意见、经过相应阶段。旧提案中已花费的讨论时间，不能替新文本领取政策效力。

提案网页及时标明撤回，并把公告、各版本与影响分析串起来，会降低读者核实成本。但不必把这个普通的记录维护问题拔高为阴谋，也不必等网站的每处链接都整齐后才处理正在进行的资源申请。运营者需要一条当下能核对的线：提案的状态已改变，正式政策没有因此改变，网络设计仍须回答正式政策的条件。公共记录若能清楚表达这三句话，就不会让一份停止的草案继续替活着的规则发号施令。

资料来源