摘要

  • V6OPS 当前草案把 IPv6-Only 定义为某个明确范围里的实际原生使用状态，而不是设备装了哪些协议，更不是整张网络拥有一个统一终态。
  • IPv4 仍可能借助 IPv4aaS、NAT64、DNS64、CLAT 或 SIIT-DC 穿越 IPv6，也可能继续存在于上游、控制面、管理路径或遗留终端之中。
  • 一项可问责的迁移记录必须把标签与对象、观测方法、剩余依赖、例外、责任人和升级条件绑定，不能让一个局部事实冒充退役证书。

一个“仅”字掩盖了多少系统

“我们已经是纯 IPv6 网络。”这句话很适合演示文稿：短、明确，而且像一个已经跨过的终点。可是在运营现场，网络并不会作为一个整体同时切换。居民接入可能不再原生承载 IPv4，客户局域网仍是双栈；数据中心的计算节点可能只有 IPv6 地址，边界中继仍替它们接收 IPv4 客户端；手机的分组数据上下文可能仅用 IPv6，应用看到的却是 CLAT 与 NAT64 提供的双栈体验。

V6OPS 工作组的 《IPv6-Only and IPv6-Mostly Terminology Definitions》试图把这些被一句话压扁的差异重新展开。02 版发布于 2026 年 9 月 11 日，Internet-Draft 公告确认它是 V6OPS 的工作项目。Datatracker 当前把它列为工作组最后征求意见阶段。这不是 IESG 批准，也不是最终 RFC；版本历史与 01 到 02 的差异说明其文字仍可被修订。

02 版文本最重要的约束不是“只允许 IPv6”，而是“先说清范围”。草案关注某个范围里真正使用的原生功能，而非节点安装的协议能力。设备可能同时支持 IPv4 与 IPv6，但它连接的某条链路只为 IPv6 做原生配置与转发。IPv4 仍可封装或翻译后穿过这条链路。因此，可证实的命题是“这里的原生协议只有 IPv6”，而不是“这个组织已不再依赖 IPv4”。

两句话之间隔着一整套权责。链路运营者可以为链路配置负责，却未必能代表所有应用、供应商、外部目的地、客户设备和灾难恢复路径作出声明。当“接入链路”“数据面”或“某个 VLAN”在层层汇报中被删掉，原本有责任边界的技术事实，就会扩张成无人能够完整证明的机构承诺。

不原生，不等于不存在

草案把 IPv6-Only 定义为：在声明的范围内，只有 IPv6 是原生协议；IPv4 不在那里配置或管理，但可以在 IPv6 之上运输。更强的 IPv6-Only-Strict 则要求在同一范围内连翻译、封装或运输的 IPv4 也不存在。

“Strict”并非文字游戏。它把两个不同决定分开：先从一层网络移除原生 IPv4，再决定是否连 IPv4 所承担的兼容功能也一并结束。第一步可以节省地址、减少状态、简化接入；第二步要求应用、合作方、管理工具与外部资源都不再需要那座桥。把第一步称为进展完全合理，把它当成第二步的证明则越过了证据边界。

几项既有 RFC 展示了依赖被移到哪里。RFC 6877规定 464XLAT，通过有状态与无状态翻译的组合，让 IPv4 应用或网络在仅 IPv6 的接入上继续工作。RFC 6146定义从 IPv6 客户端到 IPv4 服务器的有状态 NAT64，RFC 6147定义 DNS64 合成。RFC 8585则规定客户边缘路由器为 IPv4-as-a-Service 过渡机制提供的能力。

这些机制不是“迁移失败”的同义词。它们把兼容性从每条链路集中到特定服务，也随之改变了控制面：翻译器容量、DNS 合成、日志边界、应用兼容、供应商责任与故障定位变得更关键。只报告“IPv6 占比”或“IPv4 地址减少”无法说明谁承接了这部分风险。

数据中心尤其能说明问题。RFC 7755描述 SIIT-DC，让内部仅使用 IPv6 的节点通过边界中继服务 IPv4 客户端。把内部 LAN 称为“仅 IPv6”是准确的；由此推断入站 IPv4 需求、地址映射和中继责任已消失则不准确。依赖从内部主机迁到了边界，甚至可能因此更集中。

范围不是备注，而是事实本身

草案列出接入链路、网段、主机、服务、API、数据面、控制面和管理路径，因为它们可以处于不同状态。一家企业可同时拥有双栈 VLAN、仅 IPv6 VLAN 和 IPv6-mostly VLAN；一个运营商可让用户设备的承载仅用 IPv6，同时让应用和热点共享呈现双栈；一个云环境可让部分子网仅用 IPv6，另一些子网仍使用私有 IPv4 与 NAT44。

“仅 IPv6 数据面”没有回答控制协议怎样运行。“仅 IPv6 服务器”没有回答 IPv4 客户如何抵达。“仅 IPv6 接入”没有回答客户局域网。“仅 IPv6 云”若没有子网或接口范围，更可能把多种状态混成一个品牌标签。

所以，范围不是附加元数据，而是命题的一部分。删掉它，命题就发生了变化，而且通常变得更强。看板若保留范围、管理报告却不保留，问题不在措辞精简，而在证据与结论已经脱节。

这一原则还保护公平比较。甲运营商把居民接入改为仅原生 IPv6，并统一提供 NAT64；乙机构在实验网段里完全禁止任何 IPv4 运输。两者都可能正确使用“仅 IPv6”，但目标与剩余风险显然不同。把它们排进一个单轴成熟度榜单，会同时扭曲二者。范围化记录允许各自以本地选择的边界评估进展。

V6OPS 工作组章程强调在服务提供商、企业、数据中心等具体环境中总结部署经验。共同术语的作用是让经验可交流，并非强迫所有网络走一条路线。这与 Heng Lu 在《Minimum Initial Specification, Localized Future Decision, Voluntary Adoption》里的判断相呼应：共享层只规定必要的最小部分，未来决定及其修订应留给承担后果的本地行动者。

“大部分 IPv6”也不是流量百分比

IPv6-Mostly 容易被理解成“IPv6 流量过半”，草案却给出的是功能性定义：一个双栈范围拥有 NAT64 和 DHCPv4 选项 108，可选择部署 DNS64，让 IPv4-only、双栈与仅 IPv6 客户在同一网段共存。IPv4 由默认供给变为按需供给。

RFC 8925规定具体协商。具备能力的 DHCPv4 客户端请求选项 108；网络返回有效值后，客户端可以放弃 IPv4 地址，在指定时长内或下一次网络连接事件之前停止 DHCPv4。能力按接口判断，同一设备换一条链路后可以重新决定。

因此，IPv4 租约下降能说明地址分配改变，却不能证明所有 IPv4 目的地消失。IPv6 原生包比例说明传输状况，却不能列出翻译器。NAT64 清单说明基础设施，却不保证关键应用可用。端到端测试说明结果，却不自动覆盖带外恢复。每个指标只能回答一个有限问题，除非有人把它们错误地合并成“已经退役”。

建立范围—依赖登记簿

可信证据不要求公开拓扑、客户身份、地址或安全配置。它只需防止标签脱离其对象。每次使用迁移标签时，可以保存以下字段：

  1. 被描述的精确对象：服务、接口类别、链路、VLAN、应用群、数据面、控制面、管理路径或整网；
  2. 使用的术语与版本，是 IPv6-Only、IPv6-Mostly、双栈还是 IPv6-Only-Strict；
  3. 原生转发状态及其观测方法；
  4. 观测适用的时间窗口或配置版本；
  5. 仍存在的 IPv4 运输、翻译、封装、地址或外部可达性依赖；
  6. NAT64、DNS64、CLAT、SIIT-DC、反向代理或 CDN 等兼容功能；
  7. 遗留终端、应用、控制系统、厂商工具和应急恢复等例外；
  8. 各项依赖的运营责任人，以及有权改变标签的角色；
  9. 预期故障与回退路径；
  10. 进入下一状态需要的证据、决定日期与替换本记录的权威。

它应叫“登记簿”，而不是“证书”。证书容易诱导读者相信一个普遍终态；登记簿保存的是一连串有范围、可追溯、可纠正的决定。它既能承认进展，也能容纳分歧：网络团队看到简化，安全团队看到集中风险，财务团队看到地址成本下降，产品团队看到遗留用户保障。治理无需强行统一判断，只需让各方从同一事实边界出发。

Heng Lu 在《The Policy Mirror》中强调，政策必须映照真实运行的系统与激励，而不是用声明替代现实。IPv6 迁移里最值得警惕的，正是“终点”带来的象征性收益压过剩余依赖。标签越成功，越需要它保留谦逊：只描述它真的能够证明的那一层。

证据没有证明什么

公开材料没有证明任何具名运营商误导用户，也没有给出过渡机制的采用率、性能或成本。当前草案仍处于工作组阶段，即使未来成为 Informational RFC，也不会替任何部署签发符合性证明。

本文同样不主张马上拆除所有 IPv4 兼容桥。翻译可能正是本地网络敢于推进 IPv6 的条件。需要问责的是：桥在哪里、谁拥有它、它维持什么结果、失效时影响什么，以及桥还存在时可以诚实地作出哪一种声明。

一条仅 IPv6 的接入链路可以是实质成就，但它仍只是一条链路。让这两个事实同时留在记录里，迁移才不会从工程进展变成制度幻觉。

来源