摘要

  • 9 月 29 日的 draft-ietf-v6ops-ipv6-app-testing-03 在第 3.7 节明确：内部数据流通常可以视为独立，条件是协议内没有传递端点信息。第 -02 版尚未写出这一限定。
  • 第 3.6 节把应用的正常操作纳入用户界面功能测试；第 3.1 节还说明，场景表没有把纯 IPv4 网络按有无 NAT 拆开。草案仍处于工作组最后征询意见阶段，并非已获批准的 RFC。

把应用贴上“支持 IPv6”的标签，常常从一条连接成功开始，却可能在第二条连接上失去依据。设想一个前端先连上服务，随后在返回消息中收到另一个组件的地址，再按该地址发起新连接。两条连接各自通过测试，并不能自动证明两条连接连在一起时也能按预期运行。这里是说明测试边界的假设场景，不是已查实的产品故障。

V6OPS 的《Testing Applications for IPv6 Readiness》原本主张把复杂应用拆成内部数据流，分别检查，而不是把每种网络环境与每条流机械地做全排列。这个方法能控制测试成本。第 -03 版并未推翻它，而是在第 3.7 节加上关键条件：只有协议内部不传递端点时，数据流通常才可按独立来处理。如果第一条流承载的是第二条流要使用的地址或目的地，独立性就不能靠拓扑图推定。草案也没有因此要求对所有应用执行完整笛卡尔积；需要核对的是具体架构里哪些流相互依赖。

另一处变化落在日常使用，而不是网络层。第 3.6 节现把应用的正常操作写进用户界面功能，随后再谈非 Web 界面的特殊通信。只测首页打开、登录成功或者一次 API 调用，不等于测过用户真正要完成的操作。安装、管理和日志、升级也可能分别访问不同目的地。新版文字提醒测试者把应用生命周期作为验收对象，但没有声称这些环节在某个已部署系统中失败。

第 3.1 节澄清了场景表的另一个边界。表格不区分“纯 IPv4 且有 NAT”和“纯 IPv4 但没有 NAT”；有些应用假定 NAT 存在，在它缺席时出问题，草案称所列 IPv6 场景同样能暴露这类问题。对于 464XLAT 和 IPv6-Mostly 的 MTU 问题，文本指向第 3.4 节。这不是说一个 IPv6 试验覆盖了全部 NAT 或 MTU 变体。记录测试时，应写明实际拓扑与路径，避免把作者未单列的一行误读成已经验证的一行。

因此，负责发布的团队需要的未必是庞大的新平台，而是一份可以复核的小型清单：每条流由什么动作触发，目的地从配置、发现机制还是另一条协议消息取得，在哪个网络场景和软件版本上测过。如果端点作为数据跨流传递，应安排有针对性的联动测试；没有这种依赖时，逐流测试的节省仍然成立。这是本文提出的验收做法，不是 IETF 强制格式，也不是测得的互通率。

程序状态同样不能被写成结论。Datatracker 显示该工作组互联网草案处于 WG Last Call。原征询期为 9 月 4 日至 18 日，工作组主席随后在作者处理意见期间宣布延长一周。延长期和新修订都不等于正式标准获批，更不能据此断言最后征询已结束。此次新闻的核心，是“逐流测试”的可用条件被写清，以及正常操作从容易被忽视的位置进入测试范围。

资料来源