摘要

  • 一份处于早期阶段的个人互联网草案建议，IANA 为“太空用途”划出 IPv6 地址空间，再经现有 RIR 逐级分配；作者偏好的第一种安排，可能使每颗行星最多对应五个前缀。但草案既没有定义太空用途和地址块大小，也没有解释哪个 RIR 对申请者才算“适当”。
  • 复用现有注册体系的最大好处，是保留全球唯一性、责任主体和公开登记链条；它的最大缺口，则是把地球上的区域边界套在一个会移动、且法律与运行关系分散的对象上，却没有公布选择依据。

五个机构已经就位，服务对象却尚未划定

为太空网络寻找 IPv6 地址，最省事的办法看起来很清楚。IANA 已经通过五个区域互联网注册管理机构分配互联网号码资源。RIR 有接收上级地址块、通过社区制定政策、核验资源持有人和维护登记数据的现成能力。既然制度机器已经运转，为什么还要从零创建第六个注册机构？

这正是 draft-kumari-tiptop-address-space-00 最有说服力的地方。该个人互联网草案请求 IANA 划出一块专供太空使用的 IPv6 地址空间，并把其中的地址交给现有 RIR。各 RIR 再自行制定政策，向网络服务提供商或其他次级注册机构分配资源。作者目前偏好的第一种模式，不是由 IANA 为每个天体直接维护一个前缀，而是让每颗行星最多出现五条分配谱系——大致对应五个 RIR。

这里的“最多五个”不是既成方案，更不是已经获准的地址规划。文件仍是个人提交的互联网草案，其状态页明确说明，它不代表 IETF 共识，也没有标准地位。草案没有提出所需地址块的长度，没有给“太空用途”下定义，也把具体分配政策留给 RIR。IANA 当前 IPv6 地址空间登记表仍显示，普通全球单播分配受 2000::/3 约束；其中没有为太空单列的地址块。RIPE Labs 标题中的 /3 是讨论性的标题，不是 TIPTOP 草案提出的申请规模。

在这些尚待讨论的问题中，有一个比前缀长度更靠前。草案说，个人或组织可向其“适当的 RIR（或其他）注册机构”申请分配，却没有给出决定“适当”的规则。五个柜台已经被写进架构，申请人属于哪个柜台仍被留白。

地球上的“区域”有一条可用的捷径

RIPE NCC 的服务区域页面，说明现有体系如何把“区域”变成可以执行的行政入口。其服务范围覆盖欧洲、中东和中亚等超过 75 个国家。在这些国家提供服务的组织可以成为 RIPE NCC 会员并申请资源；在区域外提供服务的组织，则被建议联系对其所在国家负责的 RIR。

这并不只是一张着色地图。区域规则把申请者、服务地点、会员关系、社区政策和公开数据库连在一起。现行 RIPE IPv6 政策随后才会处理较熟悉的问题：申请者是 LIR 还是终端用户，地址要分配给谁，使用将在哪里发生，需要登记哪些资料。人们可以争论这些答案，但通常不难找到第一个应敲的门。

空间段会使这条捷径失效。设想一艘纯属假设的航天器：资源持有人注册在一个 RIR 区域，发射国处在另一个区域，任务控制和主要网关位于第三个区域，而随轨道变化启用的地面站又横跨多个区域。任务后期，它还可能离开近地轨道前往月球或火星。这不是在影射任何现实任务，也不证明真实申请已经存在；它只是列出可能被拿来决定管辖入口的几类事实。

若按航天器的实时位置选 RIR，规则最直观，也最不稳定。若按资源持有人的法定住所，入口较稳定，却可能鼓励为了政策而选择注册地。若按地面网关，事实比较容易观察，但一次正常的链路切换就可能跨越区域。发射国与长期运营关系有限，客户所在地则可能遍布全球。以目的地为准，一艘在转移轨道上的飞行器又处于哪一“区”？草案里的“适当”，表面上只是形容词，实际上承担了宪制选择。

五个前缀是结果，不是第一道决定

每颗行星最多五个前缀，很容易把讨论引向路由表规模。多个聚合前缀在庞大的 IPv6 空间里也许无伤大雅，也可能成为碎片化的第一层。要作判断，至少需要知道分配块大小、路由实践、互联方式、移动性，以及“行星”在拓扑上究竟代表什么。现有草案没有提供这些输入，因此现在断言它可扩展或不可扩展，都会超过证据。

更早的决定是：谁有权在分配树上建立每一条分支。若选择器是法定住所，公司控制权转移可能改变适用政策，而航天器仍在原轨道。若选择器是控制地面站，一次灾备切换会不会触发跨 RIR 转移？若按任务目的地，一项多年任务何时从“地球区域”变成“火星区域”？每一种答案都会产生不同的复审、交接、回收和争议处理问题。

Remco van Mook 9 月 10 日在 RIPE Labs 发表的文章，把时间顺序摆在了台面上：TIPTOP 所设想的层级将把分配政策交给各 RIR 的政策制定程序，可这些社区大多尚未真正讨论相关问题。他参与撰写的另一份个人草案 EXPANSE，则把缺失的登记模式、移动平台、司法边界、聚合风险和 RPKI 连续性逐项列出。EXPANSE 明确不向 IANA 提出任何请求；它是一份问题清单，而不是另一项地址分配决定。

两份草案放在一起看，分工反而清晰。TIPTOP 提供一条制度捷径：不要重造全球号码分配层级。EXPANSE 说明为什么捷径不能被误当成答案。现有注册体系的价值，不只在于五个机构的名字，而在于它把资源唯一性同可追责的决定绑定起来。若复用机构名称，却不定义新的服务对象，就只能在纸面上保留层级，把最关键的边留给临场判断。

先建立选择记录，再启动分配政策

当前不需要一部太阳系条约。更小也更实用的制度对象，是任何未来申请进入分配政策之前生成一份公开的 RIR 选择记录。它至少可以说明：

  1. 法定资源持有人与实际运行控制方；
  2. 本次申请所称“太空用途”的边界；
  3. 被选择的 RIR 或其他注册机构；
  4. 使该机构成为适当入口的公开规则与关键事实；
  5. 相关地面段和服务辖区，但不公开敏感坐标；
  6. 当前任务阶段以及触发复审的条件；
  7. 决定性事实改变时的交接或转移路径；
  8. 资源归还、退役和登记纠错条件。

这张记录本身不必预先裁定法定住所、控制权、网关还是目的地应当优先。它要求有权制定政策的社区公开选择，并让同类案件遵循同一原则。它还使不同 RIR 能在发放地址之前辨认同一申请，避免两边分别从各自分支作出相互不了解的决定。

公开并不等于暴露任务机密。选择记录无需刊登精确轨道、国防任务内容、联络时间表或网络拓扑。它可以只公布适用规则、责任组织、粗粒度任务阶段和决定历史，把敏感技术证据留在有边界的审查程序中。地面注册机构原本就会区分公开登记数据和受保护的尽调材料；空间任务使这项设计更困难，却没有使它变成全新的问题。

目前没有任何太空地址获配

对现有记录最准确的解读，也是最不戏剧化的解读。两位作者提交了一份早期地址空间草案；一名 RIPE 社区作者呼吁各 RIR 社区在架构固化前参与；另一份个人草案整理了第一份文本尚未回答的问题。这里没有 IETF 共识，没有 IANA 分配，没有 RIPE NCC 政策提案，没有申请人，也没有可供审计的路由。

选择规则之所以值得现在讨论，恰恰因为一切还没有发生。地址一旦写进飞行软件、采购合同和路由过滤器，改变其权威归属就不再是文本修订，而会成为迁移工程。早期标准工作的价值，不在于每个想法最终都会落地，而在于代价最大的选择仍能在只是文字时被拒绝或改写。

来源