ARIN 的 NET 路由列表不包含子网

摘要

误判往往从一个干净结果开始。运营人员用 NET handle 查询路由对象，得到空集合。到了仪表板上，空值很容易变成红色结论：没有路由、没有源 AS，甚至没有正在运行的网络。

但这次请求并没有遍历整个地址树。ARIN 的 REST 指南把边界写得很清楚：/rest/net/NETHANDLE/routes 返回与直接 NET 关联、由前缀和源 AS 识别的路由对象，而且“不提供子网”。它打开的是一个指定登记抽屉，而不是检查该地址块之下的所有登记。

这不是纯粹的接口细节。持有直接分配的网络可以为客户登记下游再分配。子登记有自己的 handle、组织关系，也可能有自己的 IRR 路由对象。父级列表为空，与未查询的下游分支存在对象，可以同时为真。

ARIN 另行提供 /rest/net/NETHANDLE/routes?reassignments=true。它覆盖所选 NET 以及其下游再分配 NET。这个参数不会让单个对象更可靠；它只是改变哪些登记对象有资格出现在结果中。

两种集合还有共同的纳入条件：路由必须在 IRR 系统内“可见且获授权”。这里的“可见”是注册系统用语，不等于全球 BGP 可见、从任何接入网可达，或正在承载流量。“获授权”也不等于法律所有权、实际控制权，或对当前路由起源的密码学验证。

返回字段本身提示了正确边界：entry 类型、组织 handle、源 AS 和前缀。响应里没有 BGP 采集器、AS 路径、观测时间、传播范围、流量或 RPKI 状态。接口不是漏掉这些事实，而是没有声称回答这些问题。

RDAP 用独立 handle 和可选的 parentHandle 描述登记层级。直接分配与下游再分配因此是两个登记对象，即使一个地址范围嵌套在另一个之内。ARIN 的两种列表请求正是沿着这条行政边界工作。

RPSL 提供另一种结构。RFC 2622 把地址前缀与源 AS 的组合定义为 route 对象的键。这种声明可以被网络用于生成过滤策略；同一前缀也可以因源 AS 不同而形成不同对象。但数据库键不会转发数据包，不会配置路由器，也不能证明通告此刻存在。

ROA 又是独立的一层。ARIN 与 RFC 9582 将其描述为密码学签名对象，用来证明某个 AS 获授权起源一个或多个前缀。有效 ROA 能增强“起源授权”的判断，却仍不能证明路由当前正在通告。IRR 列表也不会因为出现相同的前缀与 AS 而变成 BGP 数据源。

可复核的调查会记录准确的 NET handle、端点、参数与抓取时间。直接列表回答直接登记上的合格对象。带再分配参数的列表回答更宽的登记层级问题。Whois 或 RDAP 解释父子登记。RPKI 解释密码学授权。带时间戳的路由采集器才说明特定观察点实际看到了什么。

所以，直接列表为空时，下一问不应是“网络为何不存在”，而应是“请求是否包含下游分支”。扩展列表出现对象时，下一问也不是“谁控制这条路由”，而是“哪个登记与前缀—源 AS 组合被纳入 IRR，哪些独立证据支持其当前用途”。只要边界还留在结论里，列表就是可靠证据。