摘要

  • RFC 3964 表明，外层 IPv4 源地址与内层 6to4 前缀一致，只能证明两项机器声明在一个检查点相符，不能证明中继身份、操作者、授权或送达结果。
  • 解封装会把外层头部移出后续 IPv6 处理路径；要保住可追责性，就必须在转换前记录内外层关联、实际中继实例和每一项独立校验结果。

从事故调查的末端回看，常常只能看到一个 IPv6 源地址。目标主机记得它，应用日志也记得它，投诉最终却可能落到一台 6to4 中继上。两者之间少掉的并不是抽象的“更多日志”，而是一段曾经真实存在、后来被正常处理流程删除的 IPv4 外层头部。

RFC 3964 把这个问题写得很具体。一个 6to4 包在解封装之前有四个地址：外层 IPv4 的源与目的，内层 IPv6 的源与目的。接收端去掉 IPv4 封装之后，后续 IPv6 转发通常只剩内层两个地址。文档警告，IPv4 地址会像链路层信息一样丢失，而滥用者正可利用这道证据断点。

一个地址同时承担了配置和路由提示

6to4 的基础来自 RFC 3056。拥有全球可路由 IPv4 地址的站点，可以把它嵌入 2002:V4ADDR::/48。两个 6to4 站点直接通信时，目的前缀里的 V4ADDR 给出协议 41 外层包的 IPv4 目的地；与原生 IPv6 通信时，则由中继在两种路由世界之间接力。

这种设计省去了逐站点协商隧道的手续，地址本身就带着一部分寻路信息。但同一个包也因此承载两种不同的证据。外层头部回答：“哪个 IPv4 端点把这个封装交到了这里？”内层头部回答：“这个 IPv6 包声称来自哪里？”只有在特定方向和地址类型下，两者才有可校验的关系。

RFC 3964 要求：如果内层源地址是 6to4 地址，2002: 前缀中嵌入的 IPv4 值必须与外层 IPv4 源地址相符。不符就丢弃。封装端和解封装端还应拒绝不适合作为全球单播隧道端点的广播、组播、回环、私有或其他特殊用途地址；相关边界既见于路由器要求 RFC 1812，也可从今天的 IANA IPv4 特殊用途地址登记表核对。

这项比对很重要，却不是认证。通过，只能说明两个地址字段在这台设备、这版规则、这个时刻下相互一致。它没有证明谁控制外层端点，地址是否仍由同一主体持有，中继是否得到授权，更没有证明某个人发起了应用操作。

源地址过滤可以再加一道约束。RFC 2827 / BCP 38要求在靠近源头的位置阻止不合理的 IPv4 源地址，RFC 3704 / BCP 84则讨论多宿网络。若攻击者想伪造某个 6to4 前缀，就还要让外层 IPv4 源与之匹配并通过边界过滤。但“通过过滤”依然只证明对某段接入或某套路由状态而言是可接受来源，不等于真实身份。

有些方向根本没有可比的字段

当原生 IPv6 主机向 6to4 站点发送流量时，内层源地址并不以 2002: 开头，无法与中继的外层 IPv4 地址做嵌入值比对。RFC 3964 直言，6to4 路由器不容易区分合法中继与伪装成中继的第三方。它看见协议 41 数据包抵达，却没有收到一张“我有资格担任中继”的凭证。

这个边界与 RFC 3756 对 IPv6 邻居发现信任模型的分析相呼应：有能力在某个链路上发言，不等于有权承担路由器角色。6to4 更把广域 IPv4 网络视为一种伪链路，放大了“可达”和“有权”之间的距离。

因此，RFC 3964 的控制并非一个总开关，而是一组各自回答不同问题的检查：适用时核对外层源与嵌入前缀；拒绝特殊地址；禁止中继把 6to4 流量再次中继到 6to4；只接收发往本站前缀的包；限制路由传播和速率。把这些结果压成一个 valid=true，会掩盖哪些检查通过、哪些失败、哪些从一开始就不适用。

解封装成功，恰好可能是证据消失的时刻

RFC 3964 在讨论面向原生 IPv6 的攻击时指出，中继通常不会记录 IPv4 地址，因为它们被当作链路层地址。攻击若从 IPv4 节点进入，外层 src_v4 便可能在解封装后丢失，内层 IPv6 包却继续向前。

这里需要避免两个相反的误判。第一，不能把外层源地址当成最终归因：它可能被伪造，也可能只指向中继或任播服务。第二，也不能因为它不完美就认为删除没有代价。内层地址不会因为外层被丢弃而变得更可信；调查者只是失去了一个能限定叙事的邻近观察。

合理的证据单位应当是关联记录：进入接口、实际处理实例、外层 IPv4 地址对、内层 IPv6 地址对、时间、协议、路由状态，以及每项检查的独立判定。解封装本身再产生一个转换收据；后续 IPv6 转发、远端接收和应用效果各自另记。这样，一份目的端投诉才有机会回连到隧道边界，而不是把中继地址或内层声明误作责任主体。

RFC 6169 后来把问题推广到各种 IP 隧道：承载网络对外层做的过滤，不会自动覆盖内层地址；不理解隧道的安全设备会失去策略可见性；等价控制只能由隧道端点补上。RFC 3964 提供的是一个早期、具体而尖锐的例子。

任播解决“找一个”，却不解决“是哪一个”

RFC 3068 把 192.88.99.1 设为 6to4 中继任播地址。IPv4 路由可以把包送往较近的中继；实例故障时撤销路由，网络再选另一个。这让使用者无需手工配置具体中继，但 RFC 自己也指出：发往任播地址时，很难识别究竟由哪台中继处理。

所以，一条通往 192.88.99.1 的路由，只证明控制平面选择了某条宣告路径。它不证明接收实例愿意提供服务、有原生 IPv6 出口、正确执行安全检查、具备容量，也不证明回程会经过同一实例甚至同一运营者。

RFC 6343 在 2011 年总结了实际运营问题：去程和回程常走不同中继；有路由却可能遇到不愿转发或已失效的实例；状态防火墙会因外层源不同而拒绝回包；无人管理的中继既制造黑洞，也承受投诉。路由可达性没有自然生成跨运营者的共同收据。

2015 年的 RFC 7526 正式弃用任播 6to4 和 192.88.99.1，但它明确没有弃用 RFC 3056 的基础机制，也没有弃用 2002::/16。必须保留这个窄边界：标准状态发生变化，不代表所有路由、配置、终端和残余流量已经消失。

一条比隧道更长的证明链

RFC 3964 分别讨论拒绝服务、反射、数据包洗白、本地 IPv4 广播、服务盗用和行政滥用。中继可能只是转发者，却因外层地址而被视为攻击源；伪造的内层地址可能把回应引向受害者；目标端日志又可能只留下内层声明。

因此，完整链条至少包括：IPv4 路由选择；具体接口收到协议 41 包；四个地址同时被观察；地址类别、方向、前缀和目的归属分别通过或失败；解封装完成；IPv6 转发作出决定；目的端接收；应用产生结果；另有证据把事件连接到获授权的主体。第五步成功，不能代替第六到第九步。

主要证据包括 RFC 3964 的正文、元数据页和勘误页。两项已验证技术勘误分别纠正一个攻击示例的目的地址和误写的任播前缀，并不证明真实部署事故。历史与后续脉络来自 RFC 3056、3068、2827、3704、6343、7526、6169、1812与 3756。这些材料不支持虚构某个厂商缺陷、受害者、攻击率、中继数量或普遍部署结论。