AI 公司应当了解的 IP 地址治理

讨论 AI 基础设施时，人们通常先谈算力：GPU、电力、冷却、数据中心、存储和互连。这些投入看得见。支撑它们的网络身份，却更容易被忽视。

面向公众的 AI 服务仍然需要可达的端点。客户可能会将特定地址加入允许列表。服务的路由可能依赖某个自治系统号。其安全系统可能依赖 RPKI、反向 DNS，以及与同一网络身份相伴的历史记录。

由此引出本指南要回答的问题：当地址、服务商或注册机构本身成为风险的一部分时，AI 公司如何保持网络可达？

首先，区分容量与身份

IP 地址最初可能只是一份容量。临时开发环境换一个地址，可能不会造成多大影响。但生产环境中的 API 就不同了：一旦客户、合作伙伴、防火墙、监控系统和合规记录都依赖这个确切地址，情况便发生了变化。

此时，这个地址已经成为公司网络身份的一部分。需要考虑的成本不再是地址的价格，而是修改所有已经信任它的外部系统所付出的代价。

与仅仅追问需要多少地址相比，这一区分为基础设施团队提供了更好的起点。团队应当问：哪些地址可以随时舍弃，哪些支撑生产环境，哪些已经难以替换。

容易混淆的四个层面

将以下四个不同层面区分开来，有助于 AI 团队作出更好的决策：

• 资源。IPv4 和 IPv6 前缀，以及自治系统号，为网络提供全球唯一的标识符。
• 注册记录。注册机构记录由谁持有或控制资源，并帮助整个互联网避免相互冲突的权利主张。
• 运行中的网络。BGP 通告、路由器、上游服务商和应用程序，决定流量是否真正到达服务。
• 安全声明。RPKI 和路由源授权（ROA）帮助其他网络核查某个 ASN 是否获准作为某一前缀的路由起源。

注册记录本身不会转发数据包。但准确的记录依然有价值，因为其他网络在决定认可哪些信息时，会参考记录和安全声明。关键在于准确界定：记录资源是一项协调职能，并不意味着拥有围绕该资源建立的业务。

为何这会成为业务连续性问题

设想一个 AI 平台，其主要 API 前缀已被用于客户允许列表、合作伙伴防火墙、VPN、滥用防控、监控和区域路由。公司可能购买了这项资源，也可能租用了它，或由服务商提供。每种安排都会形成不同的依赖，但当前缀深度嵌入各类系统后，改变任何一种安排都会变得更加昂贵。

服务商中断只是故障的一种。围绕资源提供的管理服务，也可能停止运作、卷入法律纠纷、失去系统访问权限，或作出某项决定，使运行中的网络没有切实可行的办法保留自身身份。

公司的计算集群可能仍然健康，客户可能仍在付费。然而，更换地址的成本可能把一个管理问题变成服务与收入问题。

购买或租赁地址，并不能消除依赖

当 AI 公司需要可预测的长期容量时，购买可能是合理选择。当它需要灵活性或快速扩张时，租赁可能更合适。但这两种交易都无法回答全部连续性问题。

在生产环境依赖某个前缀之前，团队应当清楚：

• 记录中的资源持有人是谁？
• 由哪家注册机构管理这份记录？
• 哪个 ASN 可以作为此前缀的路由起源？
• 谁可以创建或修改 ROA？
• 谁控制反向 DNS 和管理访问权限？
• 如果服务商、经纪商或出租方不复存在，会发生什么？
• 租约到期或注册机构无法提供服务时，会发生什么？

因此，单个地址的价格只是采购衡量指标之一。对于关键前缀，更有用的衡量标准是每个地址的连续性保障。

RPKI 必须跟上网络的实际运行状态

假设一家公司将某个前缀从一个 ASN 迁到另一个 ASN。它的 BGP 配置可能正确，但旧 ROA 可能仍只授权原来的路由起源。执行路由源验证的网络，就可能把新的通告判定为无效。

运维原则很简单：路由变更及其安全声明应纳入同一个变更流程。RPKI 应当回答它原本被设计用来回答的那个范围明确的技术问题：哪个 ASN 获准作为这个前缀的路由起源？

它不应成为针对无关商业纠纷或机构分歧的通用惩罚机制。安全机制应保障运行中的网络，而不应在公司业务之上再设置一个无法接受审查的控制关口。

技术背景可参阅 RPKI 架构和 IANA 的号码资源参考资料。

解决之道是精简协调，并提供真正的退出路径

AI 公司确实需要协调。地址必须保持唯一，记录必须准确，路由安全必须可验证，转移和控制权变更必须可审计。

这些职能并不要求某个管理方变得不可替代。更稳健的设计，应允许资源持有人证明控制权，将可独立验证的记录带到另一项服务中，并在某个管理方失效时维持网络运行。

这就是可迁移性的实际含义。它不是搬迁办公室或加入另一家会员组织的能力，而是在现有管理安排必须改变时，保留资源记录、控制权证明、安全声明和运行连续性的能力。

如果公司依然无法离开，只是给守门者换个名字，并不能解决结构性问题。替换路径必须预先成为系统的一部分，而不是等危机到来、不得不更换时才去建立。《唯一性协调权利法案》和《注册机构连续性谬误》进一步展开了这一论点。

AI 基础设施团队的实用资源清单

在扩大面向公众的 AI 服务规模之前，应维护一份保持最新的统一清单，回答以下问题：

• 哪些 IPv4 和 IPv6 前缀支撑生产环境？
• 使用了哪些 ASN？每个前缀分别由哪个 ASN 发起路由通告？
• 谁控制注册机构账户、反向 DNS 和 RPKI 密钥？
• 哪些资源是租用的、由服务商分配的，或直接持有的？
• 哪些客户和合作伙伴已将这些地址加入允许列表？
• 每个关键前缀若要更换地址，成本是多少？
• 如果服务商或注册机构失效，有什么替换路径？

将盘点结果分为可随时舍弃的容量、生产容量，以及对业务至关重要的身份。对于最后一类，应当采用与电力、存储、转接服务和云服务商相同的故障切换思路。

为什么要在故障发生之前开始这项工作

IPv6 可以缓解 IPv4 的压力，公司应在适合自身客户和系统的地方采用它。但它无法一夜之间消除所有 IPv4 依赖。许多企业网络、允许列表和外部服务，仍然依赖稳定的 IPv4 身份。

等到服务商或注册机构已经出现故障，就没有足够时间测试记录、比较替代方案，以及与客户协调。这种紧迫性来自运维现实，而非危言耸听：识别并信任同一身份的系统越多，非计划变更就越昂贵。

AI 公司正在建设寿命长、外部依赖庞大的基础设施。它们应像对待算力和电力一样，严谨地对待号码资源：消除不必要的单点故障，记录依赖关系，并在需要替换之前就让替换成为可能。

董事会层面应当追问什么

高管不需要亲自配置 BGP。但他们需要问：公司最重要的网络身份，能否经受服务商更换、过时的安全声明或机构失效？

该问的不只是“我们的 IP 地址够不够？”，还包括：

• 谁能更改这些地址？
• 谁能为它们提供路由？
• 谁能修改安全声明？
• 哪些客户依赖这些地址？
• 如果管理方无法继续运作，公司能否保留这些地址？

这就是基础设施规模下的 IP 地址治理：保护唯一性、准确性、正当的安全声明和运行中的网络，同时确保管理方可以被替换。

继续阅读背后的论述

本指南解释了运维层面的问题。更广泛的论述见 Lu Heng 的《札记》：网络身份与客户连续性、运行代码优先，以及关于唯一性协调权利的提案。

关于资源获取问题，可阅读《i.LEASE 为何存在》。贯穿这些文章的道理很简单：交易可以让公司获得资源使用机会，但只有连续性设计，才能让这种使用得以持久。