摘要

  • RFC 1326 描述了相互封装：X 在一处装进 Y，尚未解封又在另一处装进 X。每一步都能符合本地链路要求，整个循环却没有共同上限。
  • 若新外层没有继承旧层跳数，真正经历多轮循环的内包会一次次获得新的外层寿命。包头增长触及 MTU 后，分片把“变大”改造成“变多”。
  • 传递跳数、窥视内层和禁止某些嵌套都只能覆盖部分场景。关键不在于相信哪台网关，而在于所有边界是否共同消耗一个不可重置的预算。

被藏起来的计数器

普通路由环路有一个朴素的终点：数据包每经过一跳，计数减少，归零后被丢弃。RFC 1326 讨论的危险条件不是没有计数器，而是连续封装没有保存上一层包头里的跳数信息。

旧数值可能完好地留在包中，但它已经成为新包的载荷。外部网络只读取最新包头。若每次封装都填写一份新的外层跳数，正在起作用的计数器便反复从头开始。内层记录的是旧旅程，外层决定的是下一步；两者不再是一条单调减少的证据链。

因此，一个非零的外层跳数只能说明当前封套还可走多远。它不能说明原始数据包已经进入多少个隧道，也不能证明它正在接近出口。把可见字段当作整个对象的履历，就是把信封状态误认成信件命运。

两座各自正确的桥

封装本来解决异构互联。协议 X 的包要穿过只理解 Y 的骨干网，入口路由器加上 Y 包头，把它送往出口；出口去掉 Y，原来的 X 包继续前进。中间网络无需理解内层协议。

RFC 1326 关心的是关系反过来也成立的环境：某处运行 X over Y，另一处运行 Y over X。文中举出 IP over AppleTalk 与 AppleTalk over IP，并预期 IP、CLNP、IPX、DECNET 和私有协议之间会出现更多组合。

一段暂时错误的路由即可把两种桥接串成循环。X 先成为 Y<X>。它没有到达预期出口，却来到需要穿过 X 网络的另一入口，于是又成为 X<Y<X>>。回到第一类边界后，它变成 Y<X<Y<X>>>。

每台设备都可能诚实地说：下一段链路不理解载荷，所以我添加了它能理解的包头。但这份记录只证明封装动作发生，不证明前进、解封或到达。系统错误恰恰生长在多项局部事实之间。

MTU 把增长变成繁殖

每一圈先增加的是长度。包头逐层累积，直到封装后的对象无法装进链路的 Maximum Transmission Unit。随后产生的不是一个更大的包，而是多个分片。每个分片仍处在同一套路由关系里，可以继续绕行、继续加包头，再次触及尺寸边界。

RFC 1326 所说的指数式“packet explosion”描述的是这种递推机制，并不是爆炸现场，也不是已记录的网络攻击。一个对象产生多个后代，后代重复相同转换，数量便可能快于包头层数增长。

更棘手的是容量竞争。循环分片可能填满链路，使路由更新或管理报文被丢弃。错误数据流不只消耗资源，还会压制本可让控制系统发现并修正环路的反馈。此时故障开始削弱自身的自动恢复条件。

原文也说，环路一旦打破，残余包会很快排空。这是一项机理判断，不是对某个真实网络的修复记录。改变路由、流量消退与用户确认恢复，仍是三类证据。

“看得更深”仍然有边界

第一种修复思路是把跳数传进新包头。若两种协议都有兼容字段，共同预算便可继续减少。但 RFC 1326 指出，X.25 和 SMDS 等包头没有跳数；不同协议的取值范围也不同。AppleTalk 最多 16 跳，IP 可表达至 256。为了适配较小范围而压低数值，可能终止环路，也可能制造一条超过 16 跳的正常 IP 路径黑洞。

第二种办法是检查内层。在给 Y<X> 再套 X 之前，设备可发现里面已有 X 并丢弃。然而未知包头会中断解析，加密会遮住内层，网络协议还可能装在传输层协议之上。更重要的是，同一种包头出现两次也可能是合法嵌套。重复是线索，不是判决。

第三种回应是组合多项约束：避免相互封装、禁止嵌套的相互封装、适当保存跳数，并在可行处检查包头。它没有伪装成普适算法。RFC 1326 的状态是 Informational，而且明确表示未讨论安全问题；后来的文章不能凭空把架构风险改写成攻击事实。

后来的协议把两种寿命分开

RFC 2003 后来规范 IP-in-IP。隧道属于转发动作时，封装器先把内层 TTL 减一；TTL 为零的报文不得再封装。若源地址等于封装器自身或隧道目的，也要拒绝特定循环情形。这些是定义清楚的 IP 规则，不是所有混合协议拓扑的安全证明。

RFC 2473 在 IPv6 隧道里显式区分两种量。原始 hop limit 计算原包转发；Tunnel Encapsulation Limit 计算还允许增加多少层嵌套。其值为零时，包在离开当前隧道前不得再进入另一个隧道。

重要的不是多了一个更大的数字，而是数字绑定到了正确事件。转发一跳与新增一层不是同一动作，不能用同一份局部观察替代。RFC 2473 还保留了分片警告：已分片的隧道包再次分片，会使分片数翻倍。后来的标准没有抹去 1992 年的发现，而是为它补上可验证的独立预算。

来源

这些来源证明文档状态、所述机制与后续协议响应；不证明 1992 年真实发生过此类爆发，也不证明当前隧道、恶意行为者、厂商缺陷、部署比例、实际损害或修复成功。