摘要

  • RFC 9812 要求大规模、非例行地释放 IETF 保留 IPv6 空间时，必须形成 IETF 流 RFC，经历 IETF Last Call，并由 IESG 确认共识。
  • 该程序授权的是顶层注册表变更，不是给运营商分配地址，更不证明路由可达、产品支持或 IETF 对所有用户拥有普遍政治授权。

“保留”常被误听成“已经留给某人”。在 RFC 8126 的注册表语义中，它恰恰表示尚未分配、不能分配，只为未来特殊用途或命名空间扩展而持有。保留区没有当然受益人，也没有可直接启用的网络权利。

RFC 4291 定义了 IPv6 地址架构。当前全球单播分配集中在 2000::/3；RFC 7249 则指出，完整 IPv6 空间约八分之七由 IETF 保留。今天的 IANA IPv6 Address Space 注册表 仍清楚展示这一区别：2000::/3 是 Global Unicast，许多其他顶层块为 Reserved by IETF。

巨大储备对应的释放规则却一度不够坚固。RFC 1881 早在 1995 年把 IPv6 地址管理委托给 IANA，却没有写明以后怎样开放保留空间。IANA 页面后来采用 IESG approval。这不是无效程序，但它原本是例外通道。

RFC 8126 说明，IESG Approval 无须必然发表 RFC。IESG 可以索取材料，也可以在其他程序无法及时使用或有迫切理由时批准；该机制不应规避公开审议。问题因此不在于某次批准是否错误，而在于一个无需永久 RFC 的执行层裁量，竟成了大部分备用空间的默认门槛。

RFC 9812 将门槛改为 IETF Review。申请必须进入 IETF 流，由工作组或领域主任发起，经过 IETF Last Call，再由 IESG 判断是否形成 IETF 共识。互操作影响、协议扩张和潜在伤害由相关工作组、directorate 与专家公开检查。

这不是一次抽象的“社区表态”，而是一串可核验凭据：精确前缀、用途、草案版本、发起者、Last Call 时段、异议、修改、IESG 结论、最终 RFC、IANA 指令与注册表更新时间。文件不再是批准者可选择留下的附件，而成为授权本身的一部分。

RFC 9812 没有采用看似更强的 Standards Action。后者只允许 Standards Track 或 BCP RFC；IETF Review 通常还允许 Informational、Experimental、Historic 等 IETF 流 RFC。原因是开放一个地址范围未必定义新的协议标准。强行贴上标准标签，可能把协调决定伪装成互操作规范。

三种程序解决不同问题。IESG Approval 保留应急裁量；IETF Review 强制公开 RFC 和群体技术检查；Standards Action 进一步限定文件类别。制度强度不能只看名称，必须与行动的语义相配。

5f00::/16 提供了实例。RFC 9602 为 SRv6 SID 申请该块，经过 6MAN 工作组和 IETF 流程，IANA 随后在 IPv6 Special-Purpose Address Registry 中记录。RFC 9812 将其视为新规则可行的先例。

先例不等于部署证据。RFC 9602 把该块标为非全球可达，并要求后续形成使用约定。注册表不能证明厂商实现、网络放行、BGP 接收或数据包交付。更具体的 /16 也不会自动释放仍标为保留的父级空间；前缀长度就是治理边界。

IANA IPv6 Global Unicast Address Space 与特殊用途表分开，因为二者声明不同。顶层状态、子块用途、区域分配、ROA、路由对象和 BGP 可见性不能互相替代。

RFC 7020 描述了编号系统的层级：IANA 管理顶层，RIR 面向各区域进行后续分配并形成各自政策。RFC 7249 也把非保留全球单播地址的分配放在该体系中。RFC 9812 只约束更早一步——如何让一个重大非例行块离开顶层保留状态，并未接管 RIR 日常政策。

RFC 2860 说明 IANA 按 IETF 政策执行技术参数登记。因此 IANA 行是政策执行凭据，不是 IETF 对地址的财产权，更不是运营商同意或网络运行证明。

Heng Lu 在多利益相关方幻象中提醒，参与者不是当然委托人。这里必须作范围限定：IETF Review 的正当性来自共同协议命名空间的互操作依赖。它让技术异议进入公开记录，却不是全球用户的民主授权，也不能被外推为对资产、合同或在网业务的统治权。

最小初始规范提供了合适尺度：共同层只规定释放顶层保留空间必须接受什么审议；本地网络仍自行决定实现、过滤和采用，责任人不会消失在“社区”二字里。

现实层要求逐层记账：草案不是共识，共识不是 RFC，RFC 不是 IANA 更新，IANA 更新不是下游分配，分配不是路由，路由不是交付。运行代码优先则把最后一步交给实现和数据包。

RFC 9812 还纠正了一项来源分类：RFC 1881 曾被索引为 Legacy，尽管它在 IETF Last Call 后由 IAB 与 IESG 联合发布，属于 IETF 流。RFC 8729给出流分类框架。修正索引没有重写历史委托，只恢复了正确出处。

安全部分也保持克制：本文件没有直接安全影响，但谨慎审查分配机制有助于地址问责。它没有替未来每个用途背书。用途、实现、过滤和运行结果仍需要自己的证据。

RFC 9812 的价值因此不是“更多程序”。它把程序与风险匹配：重大储备释放不能只靠可选文件的执行批准；未定义新协议的分配又不必假装成标准。IETF Review 填补中间位置，而其权力也应止于这个位置。

来源