摘要

  • RFC 9812 将 IETF 保留 IPv6 空间的未来非例行用途，从 IESG Approval 改为 IETF Review；改变的是下一次决定所需的公开审议链。
  • 它要求 IANA 更新注册程序，却没有选择前缀、批准用途、向 RIR 下发资源、允许路由或证明部署。
  • 应以“保留到使用”的收据分开记录常设政策、后续申请、IETF 决定、注册表变更、下发和运行观察；这是 Daniel Kade 的编辑建议，并非 RFC 字段。

注册表的一行文字很容易被写成一个并不存在的资源事件。当前 IANA IPv6 Address Space 表引用 RFC 9812，并把大量区间列为 Reserved by IETF。如果报道只抓住“审议升级”和“绝大多数地址空间”，读者可能以为 IETF 刚刚开放了新的 IPv6 区段。

RFC 9812 没有这样做。它是一份 Best Current Practice，调整的是未来决定的入口。此前的 IESG Approval 可由 IESG 逐案批准，不一定需要 RFC；新的 IETF Review 要求 IETF stream 的 RFC、IETF Last Call，以及 IESG 对 IETF 共识的确认。证明权力来源的链条更长、更公开，但门后的具体对象尚未出现。

保留状态不是可用状态

RFC 9812 先区分现行全局单播池与保留空间。2000::/3 是当前用于全球单播分配的范围，相关 IANA 分配在另一张 global-unicast 表中登记。其余大量顶层空间由 IETF 保留，以备当前 125 位单播空间将来“不足或不适用”时再作决定。

“保留”不是短缺预测，也不是开放申请、私有所有权、RIR 下发、可路由性或部署承诺。IANA 表还显示，一些顶层保留范围内已经存在部分特殊用途或历史用途。这个标签说明谁有权改变状态，不说明某个运营者已经取得了什么。

大数字会放大误读。RFC 9812 用大约七分之七描述保留部分，但把庞大资源放进更严格的程序，并不等于资源已经离开保留状态。门槛和流量是两种事实。

两种批准政策对应不同证据

RFC 8126 对两者作了清楚定义。IESG Approval 是罕见的后备机制，可在没有 RFC 的情况下逐案使用；它并非绕过本可进行的公共审议。IESG 可以要求材料或征询意见，但这不是该政策的固有完整链条。

IETF Review 则要求申请写入 IETF stream RFC，由工作组或 AD-sponsor 路径经 IESG shepherd，接受 IETF Last Call，并由 IESG 确认其代表 IETF 共识。它不一定是 Standards Track。RFC 9812 特意保留这一点，因为开放地址范围可能需要充分的共同体审议，却未必定义新的协议标准。

因此，变严的是最低授权证明。未来重大分配不能只靠特殊的 IESG 决定完成，但新政策也不是一个预先批准的空白支票。届时仍需一份写明前缀、用途和 IANA 行动的具体文件。

5f00::/16 是先例，不是本次分配

RFC 9812 引用 RFC 9602。后者把 5f00::/16 用于 SRv6 Segment Identifiers，并将其列入 IPv6 Special-Purpose Address Registry。它走过工作组程序，因此被用来说明重大分配可以满足 IETF Review 的要求。

时间顺序不能丢。RFC 9602 发布于 2024 年 10 月；RFC 9812 发布于 2025 年 10 月。后者没有再次分配 5f00::/16，也没有把 SRv6 的用途、块大小或目标注册表变成未来申请的模板。它只是用一个已经完成的决定解释常设程序应如何加强。

所以该前缀应标为先例证据。把它写成 RFC 9812 的产物，会同时篡改事件日期与权力链。

政策行不是执行日志

IANA 注册表同时呈现现行处置、参考文件、日期与未来变更政策。它们互相关联，却不是同一个事件。

RFC 9812 的直接 IANA 行动，是把 IPv6 Address Space 注册程序改成 IETF Review。完成这项编辑后，注册表证明下一次合格申请采用什么标准；它不证明已有申请。如果未来某份 IETF RFC 批准了具体前缀，那份 RFC 证明指令；之后更新的注册表证明 IANA 已执行。若再发生 IANA 到 RIR 的下发、BGP 宣告和可达性观察，每一步还需要自己的记录。

一句“ IETF 已分配地址空间”会把整个链条压扁。它既抹去 RFC 9812 试图强化的公共审议，也会制造错误的运行信心。注册表引用不能证明过滤器接受该范围、设备支持用途、路由广泛传播或服务已经可用。

文档状态纠正也是警告

RFC 9812 还纠正 RFC 1881 的归类。1995 年的 RFC 1881 由 IAB 与 IESG 联合发布，并经过 IETF Last Call；它曾在 RFC 索引中误列为 Legacy，而根据后来的 RFC series 框架应属于 IETF Stream。

这不是重新作出 1995 年的决定，也不会重演此后三十年的地址管理。它修复元数据，使后来者能够正确判断授权来源。程序历史与显示标签可能漂移，纠正标签仍须与原始决定分开。

新政策同样需要这种克制：说明哪张表、哪个字段、由哪份 RFC、在何时发生变化；不要从程序标签推导资源已经移动。

建立“保留到使用”收据

本文提出一份 reservation-to-use receipt。它是编辑与运营控制，不是 RFC 9812 字段，也不是给 IANA 增加的新指令。

第一层保存常设状态：精确注册表、保留范围、适用政策、控制性参考和观察时间。第二层在未来申请出现时保存：申请前缀、用途、文件、stream、sponsor、工作组状态，以及预计改变的来源与目标注册表。

决定层分别保存 Last Call、实质修订、共识结论、IESG 批准和最终 RFC。执行层逐项记录 IANA 变更：旧行、新行、参考、日期，以及该行动是创建、移动、拆分还是重新分类。RFC 发布不能自动关闭注册表执行状态。

运行层再次独立。若涉及 RIR，下发记录单独连接；若涉及特殊用途，则将路由、过滤、软件支持与部署声明连接到各自来源和日期。approved but not registered、registered but not delegated、announced but not broadly reachable 都是有效状态，不应被二元化为成功或失败。

这样，公共表述才能使用精确动词：政策已经改变；申请进入审议；文件获得批准；IANA 更新一行；运营者开始使用。每个动词只由自己的证据关闭。

问责存在于各行之间

RFC 9812 说这一变更没有直接安全影响，但经过审慎审议的分配机制对运行地址问责是必要的。它没有承诺公共审议一定带来正确结果，而是说明无法还原授权与用途的分配会造成长期成本。

更严格的程序让未来决定更可检查，却不会消除夸大结果的动机。文件作者可能把政策进展写成部署进展；运营者可能把分配当成全球可用；机构可能引用共识而不展示执行；仪表盘可能只显示当前行而不保存生效时间和来源。

答案不是再讲一次 IPv6 充裕或稀缺，而是保存可归责的状态转换。RFC 9812 完成了链条中的第一件事：改变重大决定的规则。之后每一步的完整性，仍须单独取得。

来源