摘要

  • draft-ietf-v6ops-ipv6-app-testing-03 把应用测试拆成 IPv4-only、双栈、经 NAT64 的 IPv6-only，以及完全没有相关 IPv4 通路的 IPv6-only-strict。双栈环境最终成功，可能只是回退机制成功，不能替严格单栈环境作证。
  • 安装、用户界面、管理监控与更新是彼此独立的生命周期表面。可信的就绪声明必须列出每条重要数据流、适用场景、测试环境如何成立，以及运输层和应用层分别得到什么结果。

绿色徽章隐去了分母

一次完整的用户操作往往只走过系统图的一小部分。网页访问了前端、身份服务与主 API，却未必触发许可证检查、备份、日志转发、远程管理、软件仓库或回滚服务。把这次操作汇总成“IPv6 ready”，等于让已测路径替未测路径发言。

草案定义四类基础连接条件。关键不是给整个产品贴四张标签，而是判断某一条有向数据流在某一生命周期功能下，需要在哪些条件中验证。更准确的证据单元应当包含版本、发起组件、接收组件、中间代理、网络条件、预期结果和实际结果。

复杂云应用尤其不能只看端到端结果。一次请求可能穿过负载均衡器、网关、认证服务、授权服务、数据库与遥测系统。一个组件在这条边上是客户端，在另一条边上又是服务器。终点返回成功，并不说明所有中间边都走了 IPv6，也不说明未触发的边具备同样能力。

这不是要求团队机械执行所有理论组合。受控架构可以排除不适用的场景，但排除本身必须有版本、负责人和可复核理由。没有列入清单的格子是未知，不是通过。

双栈成功可能只是退出路径成功

双栈与 Happy Eyeballs 对用户很有价值，却会改变测试含义。IPv6 连接可以在 TCP 成功后、TLS 完成前失败，客户端随后改走 IPv4，最终页面仍然正常。错误的 AAAA 记录也可能被下一候选地址绕过。RFC 8305 设计的是减少连接延迟，并不证明输掉竞争的地址族也能工作。

同样，经 RFC 6147 的 DNS64、RFC 6052 的嵌入式地址或 RFC 6877 的 464XLAT 抵达 IPv4 服务，可以是预定的迁移测试；若测试声称 IPv6-only-strict，它们就会污染条件。VPN、隐私中继与隧道也可能在测试者不知情时恢复 IPv4 可达性。

因此，回执不能只写“请求成功”。它应保存 DNS 答案、候选地址、实际地址族、每次连接尝试、回退时序、代理或翻译器、运输结果和应用结果。最终成功若抹掉此前失败，测试就失去了最有价值的信息。

反过来，严格环境也可能误伤测试自身。关闭 IPv4 可能让虚拟机管理或企业登录先失效。此时报告的不是产品缺陷，而是失去控制面的测试台。测试环境必须在不恢复被禁止通路的前提下证明自身仍可观测。

生命周期不是主界面的附注

草案把安装、用户界面、管理和更新并列。安装程序可能访问激活服务器、软件包仓库和第三方服务；管理面还可能包括 API、SNMP、syslog、监控与远程支持；更新器可能使用另一套进程、证书、镜像站和回滚通道。

主界面通过不代表安装器通过。日志能发送不代表日志正确保存 IPv6 来源。一次手工升级成功，也不代表无人值守的更新服务能在严格单栈条件下访问仓库。管理者应要求按数据流组织覆盖，而不是按屏幕截图组织覆盖。

代理还增加第三段证据。客户端到代理使用 IPv6，不能说明代理到源站也使用 IPv6。代理可能解析不同的 DNS、转换地址族或继续依赖 IPv4 上游。点对点应用与 TURN 中继又会增加候选路径；RFC 8656 定义中继行为，但不会替某个产品证明它完整测试了所有候选与失败分支。

共享服务使覆盖范围递归变化。一个平台团队为公共服务新增 AAAA 记录，可能让其他产品立刻以 IPv6 到达，而那些产品的白名单、日志或限流逻辑还未准备好。局部正确的改动，可以改变所有使用方的运行合同。

地址也是数据与权限输入

IPv6 不只在网络上传输。应用还会解析、显示、存储、比较并根据地址授权。RFC 4291 规定地址结构，RFC 5952 给出文本表示建议，但业务代码仍可能只接受点分十进制、截断字符串、错误归一化或无法检索等价形式。

白名单是更直接的风险。服务器增加 AAAA 后，具备能力的客户端可能立即改用 IPv6。若授权规则只登记了 IPv4，连接已经建立后仍会被拒绝；Happy Eyeballs 无法修复应用层政策。运输层成功，权限层失败。

可观测性也属于支持范围。系统若能接收 IPv6，却无法在审计、反滥用或客户支持中准确保留来源地址，就不能声称运营表面完整。网络百分比再高，也可能掩盖一条关键管理或恢复路径仍绑定 IPv4。

抓包只能证明它看见的流

当无法真正建立严格单栈环境时，客户端、服务器或网络侧追踪可以缩小结论。日志能显示所选地址族；服务器能显示到达的连接；抓包能显示某一接口和时窗内的流量。

但抓包中没有 IPv4，只能证明给定接口、过滤器、时间与已知流清单内没有看到 IPv4。延迟触发、条件分支、租户特例或下一版本的新依赖仍可能缺席。草案把网络追踪称为最容易出错的替代方案，正因为解释者必须先知道应用的通信图。

合格表述应是：“清单修订 X 中的所有流，在运行 Y 中均观察到 IPv6。”不合格表述是：“产品内部不存在任何隐藏的 IPv4 依赖。”

工作组 Last Call 不是生产回执

本文冻结的版本是 2026 年 9 月 29 日的修订 03，2027 年 4 月 2 日到期。Datatracker 将其列为活跃 V6OPS 工作组文件、I-D Exists，并处于工作组 Last Call。文稿首页写着预期 Best Current Practice，Datatracker 的 intended-status 字段则为空。它目前既不是 RFC，也不是 BCP。

这个界限恰好印证文章主题：文稿能统一问题，不能执行测试。RFC 8504 对 IPv6 节点提出要求，也不能替应用完成特定功能与生命周期验证。RFC 8585 描述企业部署情形，也不会证明某个产品的依赖已经就绪。

Running-Code Primacy 要求顺序保持清楚：指南定义可比较的问题；清单声明分母；测试台建立条件；仪器记录所选路径；应用产生结果；生产运行再证明这些结果能否经受依赖与变化。任何前一层都不能靠宣布创造后一层。

来源