摘要

  • RFC 2185 把 IPv4 与 IPv6 可达性视为分别计算的路由系统，即使 IPv6-over-IPv4 隧道在上层只呈现为一跳。
  • 自动隧道让“路由泄漏”成为明确的控制决定：IPv6 路由先定位封装器，之后 IPv4 路由才接手外层报文。
  • 首选端点、备用前缀、成功解封装或单向收包都只证明有限环节，不能替授权、回程对称、应用交付或迁移完成签字。

报文首先要找到“改换协议”的地点

早期 IPv6 隧道最难的部分，不只是给报文再套一层首部，而是决定这件事应在哪里发生。

1997 年 9 月发布的 RFC 2185 描述了一个长期共存期：IPv4 报文依据 IPv4 路由协议学到的路径转发；IPv6 报文，包括当时的 IPv4-compatible IPv6 地址，也依据 IPv6 路由协议学到的路径转发。即使以后能由一个集成进程携带两种地址族，备忘录仍强调，过渡的本质是双 IP 层、两次独立计算。

这使隧道成为两项连续承诺。封装之前，IPv6 路由要把报文送到有能力也有权限封装它的节点；封装之后，IPv4 路由要把外层报文送到正确端点。任意一张表里的绿色状态，都不能替另一张表作证。

RFC Editor 记录与 IETF Datatracker同时说明它是 Informational，而非互联网标准。它给出设计，不证明采用数量、现场性能或迁移完成。

上层的一跳，藏住了下层的一整张网

手工配置的静态隧道会简化 IPv6 视角。两个端点把它当作普通点到点链路，建立邻接并交换路由信息。对 IPv6 来说，对端只有一跳。

外层 IPv4 报文却不接受这套简化。它仍沿当前 IPv4 路由选出的路径穿过中间网络。虚拟邻接只能证明两个端点同意充当邻居，不能证明中间路由器、外层容量、防火墙处理、路径 MTU 或回程同样成立。

当时的过渡规范 RFC 1933 展示了隐藏在“一跳”下面的状态：隧道 MTU、分片、IPv4 路径 MTU，以及如何把外层 ICMP 错误反映给 IPv6。RFC 2003说明通用 IP-in-IP 封装，并要求事先知道出口能够解封装。这些文档解释如何包裹报文；RFC 2185 追问的是，哪条路把报文送到包裹点，以及为什么应由这个节点接手。

自动隧道把路由导出变成了“封装器任命”

主机到主机的自动隧道最直接。若两端都使用 IPv4-compatible IPv6 地址，发送方可以从中提取两个 IPv4 地址，立刻封装，让 IPv4 完成全程。

配置默认隧道改变了证据结构。没有合适本地 IPv6 路由器的主机，可以预先知道一个连接 IPv6 骨干的双栈路由器 IPv4 地址。主机把外层报文送到那里，由该路由器去掉外层首部，再恢复原生 IPv6 转发。这个配置值不只是位置，也决定责任在哪个节点换手。

路由器到主机的自动隧道更清楚地暴露了控制权。封装路由器必须把相应的 IPv4-compatible IPv6 可达性注入 IPv6 区域。其他 IPv6 路由器沿这条泄漏的路由把报文交给发布者；只有到那里，报文才被封装并交给普通 IPv4 路由。

RFC 2185 把 route leaking 定义为跨路由区域发布网络层可达性。在这里，它不是中性复制，而是在说：把这个 IPv6 目的地交给我，因为我承诺能用 IPv4 完成下一段。发布者由此成为封装器，也扩大了自己的操作责任。

规模选择进一步暴露了代价。小型 IPv4 stub 可能只需一个汇总前缀；大型 IPv4-only 骨干与双栈骨干相接时，要么把整张 IPv4 表注入 IPv6，令表规模近乎翻倍，要么人工挑出被认为含有 IPv6 节点的目的地。前者消耗状态，后者消耗持续判断。两者都不是自动真相。

备用可达不等于等价服务

RFC 给配置默认端点设计了漂亮的回退方式。每个双栈路由器既发布自己的端点主机路由，也发布共同地址块的覆盖前缀。首选端点在线时，更具体的主机路由获胜；它消失后，覆盖路由可以把报文交给另一个仍在运行的端点。

这份回执很窄。它证明有一个发布覆盖前缀的路由器收到了外层报文，不证明备用节点具备同样的策略、隧道状态、容量、过滤、路径 MTU 或后续 IPv6 可达性，更不证明反方向会选择同一个节点。

RFC 2185 明确写道，通信需要双向成功，但两个方向可以依据地址形式、本地连接和策略采用不同隧道。一个方向可能主机到主机，另一个方向却是原生 IPv6 加路由器到主机。正向成功不能画成回程地图。

其安全讨论也提醒我们保持边界：隧道可能违反底层路由基础设施的防火墙，除此之外没有讨论其他安全问题。被成功解封装的报文，并不会因此自动获得身份或策略授权。

历史留下的是一条证据阶梯

路由项证明控制进程选择了可达性；泄漏前缀证明一个区域向另一区域发布了主张；配置端点证明本地选择；虚拟邻接证明端点能跨隧道交换控制信息；解封装证明一个外层报文到达了可工作的出口；单向应用响应则只证明该方向、该时段的更多事实。

任何一项都不能单独证明路由导出经过授权、交接无环、策略一致、回程对称、容量持续、应用交付或迁移完成。

相邻文献各有自己的边界。RFC 1955 的 ENCAPS 把中期路由抽象搬到自治域首部、DNS 映射和边界路由器；RFC 2003 负责通用外层信封；后来的 RFC 4213继续把隧道建模为一个 IPv6 hop，同时让外层 IPv4 TTL 独立存在。RFC 2185 的独特贡献，是指出由谁让两层在正确地点相接。

Lu Heng 的运行代码优先可作为一种署名分析视角：发布的路由与文档不等于已经执行且可本地验证的运行结果。最小初始规范要求把共同不变量保持得窄而确定，让后续采用与策略留给运营者。他关于永久双栈成本的文章给两套路由、策略与排障面赋予经济解释，但它不是 RFC 2185 已部署的证据。现实层级则提醒：配置和发布，与实际走过的报文和真正交付的服务属于不同证据层。

RFC 2185 没有证明过渡成功。它留下的更实用：IPv6 路由承诺正确的封装器，IPv4 路由承诺外层终点。只有端到端观察，才能说明两项承诺是否同时兑现。