摘要

  • ARIN 现行 Reg-RWS 文档允许在 WhoWas NET 报告请求中填写 IPv6 地址，WhoWas ReadMe 也把 Net Range 定义为 IPv4 或 IPv6 范围；这两点都不能单独证明附件里实际交付了怎样的 IPv6 历史。
  • 2025 年 5 月和 2026 年 4 月的两次 ACSP 建议都要求补上 IPv6 历史，ARIN 将其转入内部优先级与实施规划后关闭，但没有给出发布日期或把建议绑定到某个版本。
  • 最小而有用的改进不是一句“已经支持”，而是一张不含客户隐私的能力验收单：版本、受控测试地址、请求与工单结果、最早留存事件、对象类别、已知缺口和纠正日期。

假设一名网络工程师在 ARIN 的 Reg-RWS 里提交了一个 IPv6 地址。格式合法，系统没有把它当成句柄，也没有因为写成前缀而拒绝；请求进入工单流程。这个结果很重要，却只回答了第一个问题：输入语法能不能过门。

它没有回答第二个问题：随后生成的附件里有没有这段地址的历史。更没有回答第三个问题：如果附件是空的，究竟是该地址从未发生公开登记变化，还是留存起点较晚、旧关系没有迁移、某类事件没有进入报表，或者这项 IPv6 能力尚未完整上线。

ARIN 目前公开的几份材料，很容易让读者把这三个问题压成一个。现行 Reg-RWS 方法页明确写着，WhoWas NET 请求里的地址必须是 IPv4 或 IPv6，并分别给出示例。现行 WhoWas ReadMe 把 Net Range 描述为由 IPv4 或 IPv6 地址构成的范围。服务介绍则说，经授权的用户能够查询某个 IP 地址或 ASN 的历史登记信息，并将报告称为该资源“完整的公开历史”。

但另两份同样来自 ARIN 的记录讲述了另一条时间线。2025 年和 2026 年，社区成员两次要求 WhoWas 提供 IPv6 历史。ARIN 两次都认可用途，将建议转入内部优先级和实施规划，然后把建议状态改为关闭。公开材料没有给出一个共同的版本号，说明当前接口、当前报表格式与那两次建议何时汇合。

这不等于 WhoWas 没有 IPv6 历史。也不等于建议页面必然过时。可能是功能在第二次回复之后上线，文档先行更新而建议记录没有补链；可能是接口接受 IPv6、格式也能表示 IPv6，但后端历史覆盖仍有边界；也可能只有部分年代或对象类别已经可用。本文没有获准进入 WhoWas，也没有提交真实请求，因此不会替运行系统作答。可以确认的只是：公开证据缺少一张把三层能力串起来的验收单。

两次建议说的是业务事故，不是抽象协议

2025 年 5 月 9 日提交的 ACSP Suggestion 2025.4 有一个具体场景。提交者说，某个下游实体的 IPv6 资源不再被正确分配，运营人员想找回此前的登记详情；按其描述，当时 WhoWas 只支持 IPv4 前缀查询。他提出 IPv4 与 IPv6 应当具备同等能力。

这段陈述属于用户对服务的观察，不是 BTW 对运行环境的测试。但场景揭示了历史数据为何与当前 Whois 或 RDAP 不同。当前记录只能告诉调查者“现在登记给谁”。当问题是资源曾经属于哪个网络、何时更换组织、何时撤销或移除登记时，当前状态无法替代时间序列。

5 月 21 日，ARIN 回复说，把 IPv6 信息加入 WhoWas 是有用的改进，会放入待确定优先级的建议清单，并转交内部流程进行优先级评估和实施规划。随后建议被标为关闭。这里的“关闭”必须按回复本身理解：公开建议环节结束，事项进入另一个内部流程。它不是上线证明。回复没有承诺日期，没有项目编号，也没有验收标准。

十个月后，2026 年 3 月 31 日又有人提交 Suggestion 2026.5。新的用途仍然与资源状态变化有关：用户遇到 IPv6 空间被撤销的实体，希望像查询 IPv4 和 ASN 那样查看 IPv6 范围的历史。4 月 2 日，ARIN 明确指出这是 2025 年建议的重复请求，并说重复出现会在安排开发优先级时被考虑；随后再次转入内部流程并关闭。

重复出现证明需求没有消失，却不能自动证明功能没有变化。用户可能不知道一项静默发布；不同入口的功能也可能不同；权限申请失败会让可用能力看起来不存在。ARIN 的回复比用户猜测更有分量，但回复仍没有界定“待开发改进”究竟指输入、报表、历史数据迁移还是覆盖完整性。严谨的结论不是判定成败，而是指出公开时间线没有被版本身份连接。

入口、格式和数据是三项不同能力

第一层是入口。Reg-RWS 的 “Request WhoWas NET Report” 方法要求 IPADDRESS 使用单个 IPv4 或 IPv6 地址，不能填资源句柄，也不能直接填 CIDR 前缀。请求成功时返回 Ticket Payload，用户之后查询工单状态并取得附件。由此可以验证解析器、授权入口和异步流程，但此时“成功”的对象是请求，不是历史内容。

第二层是格式。WhoWas ReadMe 中的 Net Range 能表达 IPv4 或 IPv6 地址范围，动作字段则能记录创建、修改和登记移除。一个格式拥有这些字段，说明它具备装载 IPv6 历史的结构能力。可它并不会告诉我们旧数据是否已经装入、从哪个日期开始、哪些组织和 POC 关系能够重建。表格有一列，不等于每一行都有值。

第三层是数据。WhoWas 服务页说报告包含某个 IP 地址或 ASN 的完整公开历史。这个承诺比“格式兼容”更强，却没有附带按地址族拆分的覆盖矩阵。页面没有给出一个已知发生过登记变化的受控 IPv6 地址，也没有说明最早留存年份、历史网络与组织关系的对象类别、迁移缺口或空报告的原因码。

把三层混为一谈会产生两种相反错误。看到接口接受 2001:DB8:: 就宣布 IPv6 历史完整，是把语法当成档案。看到 2026 年的建议仍说“Enable V6”就宣布系统不支持，是把流程记录当成实时探针。前者过度信任文档，后者过度信任状态标签。正确的做法是用与主张同层级的证据：解析能力用请求测试，格式能力用结构测试，历史覆盖用已知过去的受控结果测试。

空白最需要分类

历史查询最危险的结果不是错误，而是没有解释的空白。一个 IPv6 地址没有返回旧事件，可能因为它确实从未发生公开登记变化；也可能因为查询点落在后来改变边界的父网段里；可能因为历史留存起点晚于相关事件；可能因为旧系统只迁移了网络对象，没有完整迁移组织或联系人关系；还可能因为调用者没有取得正确权限。

这些原因的政策含义完全不同。滥用调查人员需要知道事件发生时谁对地址负责。转移顾问要分清当前持有人与此前登记主体。运营商在客户资源被撤销或回收后，需要理解控制链在哪里断开。法律团队关注记录能否说明某个日期的登记状态。研究人员也可能使用历史信息观察资源流动，不过 ARIN 明确限制 WhoWas 作为高频查询工具。

如果报表只给出空白而没有分类，使用者会被迫在自己的组织里建立经验规则：某个年份以前不要信、某类 IPv6 关系通常缺失、遇到空表先找支持。这种口耳相传不能成为跨机构证据。它既可能让人错过已有信息，也可能让人对一个技术上完整的系统产生不必要怀疑。

“完整的公开历史”因而需要三个边界。公开意味着受隐私和使用条款限制，不是所有内部材料。历史需要一个留存或迁移起点。完整应当理解为“所有已留存且可公开的事件”，而不是现实世界里有关资源控制的一切事实。把边界写出来不会削弱承诺，反而让承诺可验证。

计划页与发布页只能证明它们写了什么

ARIN 当前 Planned Functionality 页面明确称其清单只是整体概览。2026 年项目包括高可用、技术债和政策/费用调整、网站改进、SOC 2 Type 2 以及路由安全产品，没有单列 WhoWas 的 IPv6 历史。Software Releases 页面记录了 2012 年 3 月推出 WhoWas、同年 5 月通过 Reg-RWS 提供 WhoWas 等报告；其 2025 年和 2026 年可见条目没有明确点名 IPv6 历史。

不能从这种缺席推出“没有上线”。概览不是完整待办清单，发布摘要也不是代码提交记录。多次发布还把若干工作合并为“小幅改进和缺陷修复”。一个较小功能可能藏在大项里，也可能在两个公开发布日期之间完成。文档可能先于代码更新，也可能晚于部署。

然而，这些页面同样没有完成公开对账。如果 IPv6 历史已经交付，最廉价的补丁不是重写所有说明，而是在建议页加上版本与发布日期的交叉链接。如果当前文字只说明目标接口，那么服务页应当标出地址族覆盖边界。如果能力是部分可用，就应公布年代、对象类别或迁移批次，而不是把所有差异压成一个“支持/不支持”按钮。

一张合成测试回执胜过一句支持声明

解决办法不需要公开任何真实客户的历史。ARIN 可以维护一个用于文档或测试环境的受控 IPv6 地址，为它预先设计一组可公开的登记变化：网络记录创建、组织关联变更、POC 关系更新、登记被移除或替代。然后在每个重要数据版本上运行端到端测试。

回执只需列出：测试版本、日期、提交的 IPv6 地址、请求是否被接受、工单是否完成、是否生成附件、最早预期事件是否出现、网络/组织/POC/动作类别是否齐全，以及有哪些已知缺口。完整报表可以继续留在受控环境；公开的是检查结果和哈希来源，而不是个人资料。

这里的“哈希”不是为了制造技术仪式。它把同一份测试定义、预期结果和软件版本固定在一起，让后来修改文档或补迁数据时能够说明究竟变了什么。接口 URL 可以多年不变，后端历史世代却会变化。没有版本化来源，今天的成功无法解释昨天的空白。

这也不是服务等级协议。回执不保证每个真实地址都有丰富历史，不证明数据库每一行都正确，也不把 WhoWas 变成批量研究接口。它只证明一个更窄、更可审计的命题：当前文档里的 IPv6 输入、当前报表结构与某一代历史数据曾经在同一次受控测试中相遇。

权限合理，证明责任也因此集中

WhoWas 包含历史登记和联系信息，ARIN 要求用户申请访问、接受条款并由工作人员审批，这种控制有合理性。问题在于，外部研究者不能为了证明功能而随意公开真实报表。能够安全解决公共歧义的主体，正是同时掌握数据、授权和测试环境的 ARIN。

各页面长期分离也有组织上的原因。API 团队维护输入语法，数据团队维护历史生成，文档团队维护字段解释，ACSP 团队在事项转入内部流程后关闭建议，发布说明只选择最显眼的变化。每一处都可能在自己的职责内正确，组合起来却仍缺少端到端事实。

用户面对的恰好是组合系统。一次真实调查不会停在参数验证。它从地址进入工单，再从附件进入判断，最终影响滥用处置、资源转移、客户争议或历史归责。只要这些环节没有共同版本，使用者就无法判断空白属于资源本身，还是属于系统边界。

可以确认的结论很窄，也足够重要

现有证据不能支持“ARIN 的 WhoWas 拒绝 IPv6”。接口文档明确接受 IPv6。证据也不能支持“IPv6 历史已经完整交付”，因为本文没有查看受控输出。两次建议没有承诺期限，因此不存在可以据此宣告的延期。建议被关闭也不是发布证明。

能够确认的是：2025 年和 2026 年的用户都在寻找 IPv6 历史；ARIN 把它称为值得排期的改进；当前接口和格式文档已经允许 IPv6；公开计划、发布与建议页面没有用同一个版本或测试结果解释这些事实如何汇合。

一张能力验收单正好填补这道缝。若功能已经上线，它给出完成证据；若仍在建设，它提供可观察的完成条件，却不擅自添加发布日期。若只是部分覆盖，它让限制可以被运营人员纳入判断。最重要的是，它不再要求一个“请求已接受”的工单承担整座历史档案的证明责任。

来源