摘要

  • 九月草案向 IANA 申请太空用途的 IPv6 地址块，并提出由 NRO 参与分配；它仍是未获背书的个人 Internet-Draft，并非已通过的政策。
  • NRO 明确表示自己不制定号码资源政策。草案没有说明拟议角色如何衔接五个 RIR 社群各自的政策流程，RIPE 也在其中。

关键不是谁来分配，而是谁制定分配规则

申请地址空间乍看像一道工程题：预留地址块、切成可用前缀，并确保路由仍可管理。2026 年 9 月的太空环境 IPv6 地址草案把问题推到了制度层面。它请求 IANA 分配地址块，并写道，Number Resource Organization（NRO）将决定如何为天体及其内部组织、指派和分发资源；另一处又说，注册体系将制定分配政策。

这组表述留下了治理接口，却没有证明任何机构已经行使权力，也没有显示地址已分配或政策已改变。它是一份标注 “I-D Exists” 的个人 Internet-Draft，草案首页写作 “Intended status: Standards Track”，但 Datatracker 元数据中的 RFC stream 和 Intended RFC status 均为 “None”；页面说明个人 I-D 在 IETF 标准流程中没有正式地位。

真正的问题不是跨区域协调有没有用。一个可能覆盖多个地区的地址块当然需要技术协调。问题在于，协调如何接入负责确定谁能取得资源、要满足什么条件、以及如何复核或申诉的政策程序。

协调职责不能替代政策权力

NRO 对自身职责的介绍划出清楚边界：它协调五个区域互联网注册机构，并在 ICANN 中承担 Address Supporting Organization 职能；但它不制定、不批准，也不实施区域或全球互联网号码资源政策。各地区社群自行制定政策，各 RIR 支持本地开放流程。 NRO 常见问题还描述了一条不同的全球政策路径：在 RIR 提供意见的基础上，NRO 审议并提出全球 IP 地址政策建议，再交由 ICANN 董事会批准。这一建议角色并没有说明本草案要走全球规则路径，还是由 NRO 协调五个地区决议。NRO 对注册体系的说明同样把区域注册服务与 RIR 之间的协调区分开来。

九月草案把 NRO 放入拟议的分配链条，却把政策制定归给“注册体系”。这些词并没有指出谁按什么程序作决定。分配是执行 RIR 社群已经同意的规则，向社群提出建议，还是另建一套共同政策工具？文本没有回答。也不能把“注册体系”自动理解成一个统一的政策机关。

2026 年 5 月的一份 TIPTOP 个人草案描述了另一种架构：IANA 将地址委派给现有 RIR，由它们依照常规流程制定政策。这可供比较，但不足以证明九月版本取代了它，更不代表两者有任何一个获采纳。文字变化值得作者解释，却不是存在冲突的证据。

RIPE 的参与方式是政策流程，不是机构背书

RIPE NCC 运营区域注册服务，并支持 RIPE 社群开放的政策制定流程。RIPE-738 等已发布 IPv6 政策构成当前地区基线。若要设立太空专用制度，草案应说明哪些问题由 RIPE 社群决定、哪些可以跨 RIR 协调，以及全球分配规则遇到地区决议时怎么办。

九月文本不是 RIPE 提案，但它提出了跨 RIR 角色和“注册体系”，所以 RIPE 的制度安排不可忽略。已核对的来源没有显示 RIPE NCC 为草案背书、代表社群开启了政策提案，或接受新的分配职责。IETF 126 的 TIPTOP 纪要只记录了一项计划：与 IANA 和 RIR 代表通过临时会议厘清技术需求。计划进行技术讨论，不等于授权分配或管理地址块。

下一版应把接口写成可执行规则

文本可以先明确资格和分配标准由哪个论坛负责、NRO 是协调还是建议或执行、哪个 RIR 管理注册记录，以及如何处理指派决定、异议、更正和申诉。它也要交代资源跨越多个地区或地区规则不同时，制度如何运作。

这些并非格式问题，而是决定技术分配能否一致落地、同时不悄悄转移政策权力的制度条件。如果依靠各地区分别决策，就该解释这些决定如何组合；如果提出共同规则，就该写明由谁采纳、各社群如何参与。在这些问题没有答案之前，“注册体系”不能代替明确的决策主体。

现有材料只支持一个克制的结论：新草案提出 NRO 协调分配，但没有说明其背后的政策交接。RIPE 的政策流程并未因此改变。下一份有意义的证据应是一版说清职责边界的修订稿，让运营者和申请者能判断协调何时结束、政策从何处开始、适用规则是什么。

来源