摘要

  • RFC 2003 在完整 IPv4 数据报前再加一个 IPv4 首部：外层地址属于隧道入口与出口，内层地址仍属于原始通信端点。
  • 作为转发动作封装时，入口先递减内层 TTL；外层 TTL 则独立服务于到出口的路径。
  • DF、隧道 MTU、外层分片、出口重组和 ICMP 回译分别由不同节点负责。Protocol 4 只声明下一层是 IPv4，不是身份、安全或交付证明。

一个 DF 位，先问是谁作的决定

在 RFC 2003 中，内层 DF 为 1 时，外层 DF 必须为 1；内层 DF 为 0 时，外层 DF 仍然可以为 1。前一种情况延续原始发送者“不允许分片”的选择，后一种情况则可能来自封装器为隧道执行路径 MTU 探测的策略。只记录外层 DF，不能还原决策来源。

责任差异会改变错误去向。隧道内部路由器处理的是外层数据报，遇到超过下一跳 MTU 的 DF 包，依据 RFC 1191 把 Datagram Too Big 发给外层源地址，也就是封装器。它并不知道内层发送者是否请求了这条反馈链。

如果内层 DF 原本为 1，封装器可以把隧道 MTU 减去外层首部长度，再把有意义的 MTU 报告给原始发送者。若内层 DF 为 0、只是封装器自行设置外层 DF，RFC 2003 直言：封装器可能没有合理办法把这次错误解释给原始发送者。它可以在试探更大 MTU 时保留数据报副本，以便收到错误后分片重发；也可以为某类流量不设置外层 DF。

这不是一个字段格式问题，而是错误责任问题。发送者、封装器、隧道内部路由器和解封装器看到的是同一数据报链上的不同对象。

外层地址先把包送到中间目的地

RFC 2003 的操作很朴素：在原有 IPv4 首部前插入新的 IPv4 首部。外层源地址是封装器，外层目的地址是解封装器；内层源、目的地址仍是原始发送者和最终接收者。到隧道出口之前，路由依据外层目的地址；拆掉外层后，内层目的地址重新决定后续转发。

RFC 1853指出，普通 IP-in-IP 在两个 IP 首部之间不需要专门的胶水首部。没有中间首部时，外层 Protocol 字段为 4，意思只是“后面是 IPv4”。它不证明外层源真实可信，不证明内层源获准使用这个地址，也不证明出口接受、转发或交付了内层包。

因此，外层抓包能证明某个观察点看到了一次封装格式和外层地址对。若要证明原始通信，需要入口处把内层指纹与外层包绑定；若要证明出口动作，需要重组与解封日志；若要证明交付，还要有出口后的转发证据与应用回执。

两套 TTL 不能合并成一条时间线

当封装是普通转发的一部分，封装器必须先把内层 TTL 减 1。若结果为 0，数据报应被丢弃并向原始发送者返回 Time Exceeded；TTL 为 0 的包绝不能再被封装。如果数据报由封装节点自己发起，则单纯加外层首部不需要递减内层 TTL。

外层 TTL 由封装器另行选择，只需适合把封装包送到隧道出口。解封动作本身不减内层 TTL；出口若继续执行普通 IP 转发，才会再次递减。一个仍有较大外层 TTL 的包，可能装着寿命已经很短的内层包。外层 TTL 证明的是当前信封还能在隧道中走多远，不是原始数据报的完整路径长度。

本篇聚焦普通 RFC 2003 隧道里的责任：分别记录入口前后内层 TTL、外层初始 TTL、观察值和出口后的转发动作，而不是把它们压成一项寿命指标。

外层分片把缓存和计时器搬到出口

封装增加了至少一个 IPv4 首部。原本能通过入口链路的数据报，进入隧道后可能超过 MTU。如果外层数据报被分片，解封装器必须先收齐并重组外层分片，才能找到完整内层数据报。重组缓存、片段标识、乱序等待和超时都落在隧道出口。

RFC 2003 倾向通过隧道 PMTU 软状态避免这种代价。若允许，封装器可以先把原始 IPv4 数据报分片，再分别封装；这样外层不需在途中分片，最终接收端负责内层片段重组。后来的 RFC 4459进一步说明，隧道端点的外层分片与重组在高速和丢片条件下会产生显著缓存与处理压力。这里引用它只是确认责任边界，不把文章扩写为通用 PMTU 史。

外层 Identification 也不能被当作永远唯一的流水号。RFC 6864更新了 RFC 2003：IPv4 ID 的强唯一性要求只在可能或已经分片的数据报上有意义。把不分片外层包的 ID 当作跨点关联凭据，会超出当前规范保证。

ICMP 返回时，入口必须重新解释

RFC 2003 为不同 ICMP 类型分配了不同处理方式。Protocol Unreachable 不能原样交给内层发送者，因为它从未发送 Protocol 4；入口应改为 Network 或 Host Unreachable。Port Unreachable 不应转发，因为外层 IP 首部没有端口。Datagram Too Big 必须回译。Redirect 和 Source Route Failed 留给封装器处理。隧道内 Time Exceeded 对内层发送者表现为 Host Unreachable。Parameter Problem 只有在指向从内层复制的字段时才可能回传。

RFC 792当时只要求错误消息携带原始 IP 首部和后续 8 个字节。对于 IP-in-IP，这不足以包含完整内层 IPv4 首部。封装器可能收到真实外层错误，却无法从引文中识别是哪一个内层包触发。

RFC 2003 因此要求维护隧道 MTU、路径长度和出口可达性等软状态。后来的包若与软状态冲突，入口可以向其原始发送者发 ICMP，同时仍把包封装转发。规范明确说，这些通知不一定与隧道内部错误一一对应。软状态是最近路径条件的模型，不是单包审计凭证。

1996 年的字段表还受后来规范约束

原文写外层 TOS 从内层复制。RFC 3168后来为 ECN 规定两种隧道模式：有限模式不在外层启用 ECN；完整模式需要把拥塞语义带入外层，并在出口把外层 CE 反映到内层。若出口一律丢弃外层拥塞标记，端点就收不到隧道内部的信号。

Datatracker 的 RFC 2003 记录把文件列为 Proposed Standard，并明确列出 RFC 3168 和 RFC 6864 的更新。标准状态证明文件进入了哪条规范轨迹，不证明某台设备实现了这些更新，更不证明某条线上隧道持续运行。

能拆包，不等于能信任包

RFC 2003 的安全章节警告：封装后，原始源、目的、协议与传输端口不在边界过滤器习惯的位置。外层来源可信与内层来源经过认证是两个判断。仅凭 Protocol 4、校验和正确或出口成功拆包，不能证明内层身份、路由授权或接纳策略。

RFC 791提供 IPv4 首部、TTL 与分片的基础语义。RFC Editor 记录证明文档身份。Lu Heng 的运行代码优先阻止我们把发布当部署；最小初始规范说明共同格式不必吞下所有后续运营选择；现实层次则要求把规范、配置、发出的信封、出口动作和服务结果分别保存。

Protocol 4 能告诉监控系统下一层该按什么格式解析。只有跨入口、隧道内部、出口和最终端点的相关证据，才能说明那封信后来发生了什么。

来源