摘要

  • RFC 5211 提出准备期、过渡期和 2012 年 1 月开始的过渡后阶段，目标是让互联网以 IPv6 连接为主；它同时明确，这只是一个可能的纯信息性方案，不给任何一方创设义务。
  • 日期、RFC 编号与大写 MUST 能让计划更清楚，却不能证明 IPv6 可订购、已开通、可往返、被实际选择、承载了主要流量或让应用成功运行。

跨过的首先是时间边界

2008 年 7 月发布的 RFC 5211 面对一个真实协调难题：高度分散的服务商、终端组织与设备供应商如何在不破坏普遍连通性的前提下推进 IPv6。它把计划分成三个阶段：2009 年底前准备，2010 至 2011 年过渡，2012 年起进入过渡后。

规范没有掩饰自身权限。正文称它为“一个可能的方案”，其他方案同样可能；文件不对任何参与者产生义务；RFC 2119 的强制词只是为了把所提方案说清楚。IESG 说明更进一步：RFC 5211 不是任何级别互联网标准的候选，也没有经过通常意义上的 IETF 共识技术审查。

这些限定不是脚注，而是权威边界。计划可以对齐讨论、暴露依赖、催生预算，却不能替运营者上架产品、给设备下配置、验证路由，更不能替用户完成交易。到了 2012 年，唯一自动成立的是“日期已经到达”。

“提供服务”至少有十几层

TRANS1 与 POST1 要求服务商提供 IPv6 互联网服务。汇报表里只需一个勾，现实里却要逐层作答：产品目录是否存在，哪些地区和接入类型适用，订单是否能通过资格校验，前缀是否下发，客户侧设备是否接收配置，正向和返回路由是否成立，DNS、监控和客服是否按生产服务处理。

这些状态由不同系统掌握。产品经理可以发布套餐，而开通系统仍拒绝地址；线路可以完成配置，而返回路径缺失；路由可以存在，而地址选择让绝大部分连接继续走 IPv4；探针可以成功，而身份、支付、日志或第三方 API 仍只支持 IPv4。

终端组织也一样。发布 AAAA 记录只证明 DNS 中有一条记录，不证明解析器选中它、连接建立、完整交易结束或服务持续稳定。一次成功只能代表一个观察点、一个时间和一次交易。若不说明地理、接入、应用与分母，“已经可用”就只是无法反驳的口号。

大写单词没有生成执法者

RFC 5211 有意使用 MUST、SHOULD 与 MAY。这些词使所提步骤没有歧义，但文件同时否认它们会创设义务。方案没有规定统一审计人、被测总体、测试窗口或处罚机制。

常见的治理错误，是让强动词脱离主语旅行。“服务商 MUST 提供”进入采购表后，可能被压缩成“互联网已经完成过渡”。中间消失了哪家服务商、哪个产品、什么地区、哪类客户、谁来验证以及何时观察。排版强度悄悄借用了制度权威。

修复方法不是把所有动词改弱，而是给每个动词绑定范围与回执。提供对应产品与订单；开通对应配置与路由；生产对应交易、告警和支持；“占主导”必须带测量口径、分母与时间窗；IPv4 退出必须带依赖清单、例外和回滚演练。

POST4 从未承诺一刀切

RFC 5211 的“过渡后”阶段并不要求 IPv4 消失。POST4 明确允许服务商继续提供 IPv4，也允许组织继续使用。目标状态本来就是不对称共存：IPv6 承担不断扩大的角色，IPv4 可以保留。

这也是后来文档分别讨论双栈、翻译、客户边缘设备、内容迁移、企业部署、安全和 IPv4-as-a-Service 的原因。一个系统可以同时拥有 IPv6-only 核心、按需提供的 IPv4、双栈公开站点以及无法立即替换的 IPv4 应用。一个全局布尔值无法表达这种组合。

共存不是逃避决定。过早关闭 IPv4 会切断未发现的依赖；无限期保留则延续成本、攻击面与组织惰性。两者都不能由日历替管理层作答。

后续规范不是历史部署日志

RFC 6144 在 2011 年指出，IPv4 地址耗尽很可能早于显著的 IPv6 采用，并把共存作为持续问题。RFC 6180 预期过渡尾部很长。RFC 6540 后来把 IP 能力节点支持 IPv6 提升为最佳当前实践。RFC 6589、RFC 7084 与 RFC 7381 又分别细化内容、客户边缘设备和企业部署。

这些文件证明问题被进一步拆开，不证明某个产品完成实现、某家网络已经启用或某位用户的应用成功。规范地位、代码支持、启用配置、实际路径与业务结果是五种证据。

这种区分也避免把过渡进度简单归罪于协议。目标日期过去而目标状态没有证据，只能说明日程没有自动生成状态。采购周期、激励、遗留依赖、产品成熟度、运维风险与本地排序都需要独立调查。

把计划拆成可以核验的回执链

可靠记录应从计划、负责人和预算开始，继续保留产品上架、订单受理、线路开通、地址分配、DNS 发布、双向路由、路径选择、流量观测、应用结果、连续性、例外与退网决定。每条回执都必须说明时间、对象、范围、责任方与来源。

这不要求建立一个全知中心。公共结构只需定义证据类型、范围、时间、参与者、对象、结果和来源；各网络仍能保留自己的门槛与决定。最小共同规范让跨组织主张可检验，同时不吞并本地权力。

日期因此仍然有用：它应该触发复核。若证据与计划分离，就修订计划，而不是把未知运行状态改名为“完成”。

来源

  1. RFC 5211 信息页
  2. RFC 5211 HTML
  3. RFC 5211 文本
  4. IETF Datatracker：RFC 5211
  5. RFC 5211 历史
  6. RFC 5211 引用关系
  7. RFC 5211 勘误
  8. RFC 3932：独立投稿
  9. RFC 2119：要求级别关键词
  10. RFC 8174：BCP 14 更新
  11. RFC 6144：IPv4/IPv6 翻译框架
  12. RFC 6180：IPv6 过渡机制指南
  13. RFC 6540：IP 节点应支持 IPv6
  14. RFC 6589：内容向 IPv6 过渡
  15. RFC 7084：IPv6 客户边缘设备要求
  16. RFC 7381：企业 IPv6 部署指南
  17. RFC 8170：IPv6 部署场景
  18. RFC 9099：IPv6 运维安全
  19. RFC 9313：IPv4-as-a-Service 过渡技术
  20. Heng Lu：现实层与符号权力
  21. Heng Lu：最小初始规范
  22. Heng Lu：运行代码优先