摘要

  • 10 月 26 日，NIC.br 的 Sávyo de Morais 在 RIPE 93 介绍早期开放源码工具 V6bench，用于检验应用在 IPv6 环境里能否完成工作。
  • 演示从 OpenAPI 规格生成 DNS 与 API 测试模板；测试计划和变量仍要人工调整，执行后再核对 CSV 结果。目前重点是 API，用例覆盖有限。

网络团队把 IPv6 链路点亮，应用团队便可以剪彩了吗？RIPE 93 的这场报告 给出一个扫兴而实用的问题：用户能不能一路登录、提交、收到回应？如果中途某个验证器只认 IPv4，漂亮的连通性图表就只负责漂亮。

De Morais 的原始幻灯片列出潜在绊脚石：写死的 IPv4 地址、地址格式校验、访问规则、数据库字段、地理定位、认证、日志和监控。这是一张排查清单，并没有宣布某家服务已经摔倒。幻灯片第六页给出的验收口径很直白：拿掉 IPv4 后，依赖服务和完整操作都得继续运转。

V6bench 把抽象口号拉回操作台。先交给它 JSON 或 YAML 格式的 OpenAPI 规格，它会生成 DNS、区域文件与 ScanAPI 测试模板；随后操作者要按真实服务改写计划和变量，选择网络环境、运行并查看 CSV。项目自己的仓库说明工具尚处早期，可能有缺陷，眼下主要面向 API。自动生成的是起点，不是盖章的验收单。

环境的选择也会改变问题。幻灯片把客户端分为仅 IPv4、双栈、仅 IPv6 和 IPv6 加 NAT64；服务器侧还列出 SIIT-DC。双栈上成功的请求，碰上仅 IPv6 的客户路径，可能讲的是两件事。搭建试验环境需要双栈主机、Docker IPv6 bridge、Kathará、Jool 等条件。选了哪条路径，报告里就该写清哪条路径。

IETF 工作组草案也把认证、日志与依赖纳入应用测试视野。NIC.br 这次新闻的锋利处，在于给验收责任一个可见的交接点：工具可以铺桌子，服务负责人得决定摆什么菜。采购方若只收一张“IPv6 可达”的截图，最后端上的可能是无法登录的午餐。

原始来源