摘要

  • 2001 年，6to4 让一个站点可以从全球唯一的 IPv4 地址生成 2002::/16 下的 IPv6 前缀，并在无需逐一协商隧道的情况下穿越 IPv4 网络。
  • anycast 随后让中继看起来像是自动选择的，但去程和回程可能依赖互不负责的不同运营者。过滤、错误路由和默认开启的软件，使便利变成反复发生的故障。
  • RFC 7526 在 2015 年弃用了 anycast 中继机制，却没有弃用基础的单播 6to4，也没有撤销 2002::/16。今天阅读注册表时，这条边界仍然重要。

先有地址，后谈协作

6to4 最令人记住的部分是一道地址运算：取一个全球唯一 IPv4 地址的 32 位，把它放到 2002 之后，站点就得到一个 /48。RFC 3056 把结果写作 2002:V4ADDR::/48。尚未接入原生 IPv6 的网络可以在内部从这个前缀分配地址；边界上的 6to4 路由器则用 IPv4 协议号 41 直接封装 IPv6 数据包。

RFC 3056 发布于 2001 年 2 月，称它是一种可选的过渡机制，而不是 IPv6 的永久架构。它的吸引力更具体：站点可以借助既有 IPv4 互联网通信，不必为每个对端预先配置一条隧道，也不必先为这个用途申请普通 IPv6 前缀。IPv4 地址同时充当了原料和定位信息。

便利从一开始就有条件。私有 IPv4 地址无法生成具有全球意义的 6to4 前缀；IPv4 地址一旦变化，派生出的 IPv6 前缀也随之变化。更重要的是，6to4 世界与原生 IPv6 世界之间仍需有人转发数据包。被自动化的是地址生成，不是普遍可达性。

从视野中消失的中继

两个 6to4 站点通信时，前缀中嵌入的 IPv4 地址可以告诉对方把隧道送到哪里。但 6to4 站点要访问原生 IPv6 目的地，就必须经过同时理解两边协议的中继。

RFC 3068 给出了一种极其简洁的方案：让中继路由器共享 IPv4 anycast 地址 192.88.99.1。6to4 路由器把流量发往这个地址，普通 IPv4 路由就会选择一个正在宣告该路由、通常较近的中继。用户无需再发现或配置某个特定网关。原本需要运营安排的过渡机制，看上去成了一个开关。

这个开关隐藏了不对称性。去程选中的中继不必承担回程。原生 IPv6 网络向 2002::/16 发送数据时，可能选择另一个运营者管理、由另一套路由策略抵达的中继。两端中继甚至不需要知道对方存在。往返成功依赖多家组织提供彼此兼容的服务，机制本身却没有建立一份共同契约，也没有指定整个往返路径的单一负责人。

这些问题不会显示在地址格式里。一个完全按文档生成的有效 6to4 地址，仍可能撞上丢弃协议 41 的防火墙、缺失的中继路由宣告、位置糟糕的中继，或通向黑洞的回程。前缀没有错，用户体验依然可以失败。

回退机制如何掩盖成本

2004 年发布的 RFC 3964 重点讨论安全。中继需要检查隧道的 IPv4 源地址，是否与 6to4 源地址中嵌入的 IPv4 相符。缺乏过滤时，伪造流量可能被反射、借过渡系统“漂白”，或变得更难归因。文件并不是说每个中继都有恶意，而是在指出：自动封装跨越了仅靠地址本身无法约束的信任边界。

到 2011 年，RFC 6343 已能汇总更广泛的运营记录：过滤协议 41、缺失或不可达的中继，以及只能单向工作的路径。它引用了当时若干实验，其中 6to4 连接失败率大约落在 9% 至 20% 之间。这不是全球、全时期的普查结果，却足以让一种过渡辅助机制成为可感知的可靠性问题。

成本往往只是被遮住，而非被消除。双栈应用可能先尝试 IPv6，等 6to4 路径失败后再退回 IPv4。用户看到的或许只是页面变慢。软件厂商自然会优先选择可靠的原生路径，并让不同方案并发竞速，后来的 Happy Eyeballs 就体现了这类思路。每一层都能减轻自己暴露出的症状，却没有补上中继系统缺失的责任主体。

默认开启让这个模式延续得更久。用户从未主动要求 6to4，却可能从操作系统或边缘设备获得派生地址和一条看似可用的 IPv6 路由。RFC 6343 把这种做法称为不良实践，并建议默认禁用 6to4。变化耐人寻味：当初因为几乎不需协调而有吸引力的功能，后来需要由知情用户明确决定才能开启。

弃用捷径，而不是改写历史

2015 年 5 月，RFC 7526 正式确认了退场路径。它弃用 anycast 6to4 机制，把 RFC 3068 及相关的 RFC 6732 转为 Historic 状态，并要求停止 anycast 路由宣告和 192.88.99.1 中继服务。实现应默认关闭 6to4。这条公共捷径不再被视为推荐的过渡基础设施。

这项决定的范围很容易被说错。RFC 7526 明确表示，它没有弃用 RFC 3056 中的基础单播机制，也没有弃用 2002::/16 前缀。IANA 当前的 IPv6 特殊用途地址注册表仍把该地址块列为 6to4。注册记录说明的是一项架构分配，不承诺公共中继路径仍可用或值得部署。

正因如此，这段历史不是以删除结束。标准流程可以撤回一项运营建议，同时保留识别旧地址、受管部署和遗留系统所需的术语。今天看到 2002::/16，应把它当作该机制存在的证据，而不是 anycast 服务经受住审查的证据。