摘要

  • 9 月 2 日个人草案中的 100% 与 50% 分别对应不同的限定对象，不能读成企业安全风险下降一半。
  • 传输网络只运行 IPv6，仍可在端点处理 IPv4；“已经退役”必须说明验收覆盖到哪里。

验收表上写着“IPv6-only”，并不意味着应用系统已告别 IPv4。Charles C. Sun 在当前个人 Internet-Draft中给出的限定，让这两个判断之间的距离变得具体。署名机构为 Alliance for Universal Computing 的作者，在日期为 9 月 2 日的 -01 版本中讨论 IPv4 退役的形式化后果。这不是 IETF 已认可的标准，也不是一次生产迁移的实测报告。

草案的两个百分比不能共用一个分母。100% 指向一类必须依赖被移除的 IPv4 第三层处理路径才能执行的攻击；50% 则把同时暴露的协议栈从两个计为一个。作者明确排除了攻击流量、事故数量、财务损失和组织总风险减半的解释。把这份稿件概括成“IPv6 天生更安全”，不是简化，而是改变了原主张。

边界缩小，依赖未必消失

退役是否成立，取决于所选主机或网络的边界。只要边界内部的翻译器、隧道端点或兼容组件仍保留、重新引入 IPv4 第三层处理，草案的退役前提在那里就不成立。这个条件比宣传材料上的网络标签严格得多。

2021 年的 RFC 9099提供了一个现成例子：464XLAT 可以在主机一侧将 IPv4 转成 IPv6，再在服务提供方转回 IPv4，让仅支持 IPv4 的应用经由纯 IPv6 网络访问仅支持 IPv4 的服务器。中间的传输网络确实可以没有原生 IPv4；包含端点和转换设备的整个系统却不能因此被视为不再处理 IPv4。

这不是对某家运营商现状的指控，而是两份技术文本导出的验收区别。传输团队的测试可以证明其合同范围内完成了迁移，却不能自动替应用团队、端点团队和兼容服务作担保。范围扩大后，需要证明的命题也随之改变。

协议数量没有替损失定价

一个协议栈计一个单位，并不表示两个协议承担相同的故障损失。草案也没有否认实现层共享代码、内存或其他资源；IPv6 自身机制继续工作，不等于所有依赖 IPv4 的目标仍然可达。这些都是作者已经写明的限制，而非本报道揭露的隐瞒。

减少一套处理路径，可能减轻维护负担。但节省多少，是否抵得过兼容成本和迁移代价，需要具体系统的证据。形式化计数提供了描述移除状态的词汇，并没有替管理层完成投资论证。

这种区分沿用 Lu Heng 关于 BTW 应描述现实而非倡议的说明：先看清实际运行结构，再讨论选择。该文是编辑方法的依据，不是网络技术结论的证据。