摘要

  • RFC 2004 不增加完整第二层 IPv4 首部，而是改写原首部的 Protocol、目的地址及按条件改写源地址，再用 8/12 字节 Minimal Forwarding Header 保存恢复信息。
  • S=0 之所以能省掉原源地址，是因为封装器本来就是原始源；这是依赖规范执行的相等条件，不是身份认证。
  • 最小头校验和只覆盖最小头。出口成功恢复字段，只证明重建规则完成，不能证明入口前所有首部字节、隧道授权、路径完整性或应用交付。

入口没有留下完整内层首部

RFC 2004 的出发点是减少传统 IP-in-IP 的重复字段。普通无选项 IPv4 首部至少 20 字节；最小封装只插入 8 或 12 字节，因此分别少付 12 或 8 字节。但这不是把同一信封做薄，而是改变了保留记录的方式。

入口保留原 payload，却直接修改原 IP header：Protocol 改为 55，Destination Address 改为隧道出口；若封装器并非原始发送者，Source Address 也改成封装器地址。Total Length 增加最小头长度，IP Header Checksum 随之重算。与已发布的 RFC 2003 完整外层信封不同，这里没有一套原首部完整躺在里面等待拆封。隧道可见首部，就是被临时改派任务的原首部。

S 位把“省略”变成一个条件分支

Minimal Forwarding Header 总是保存原 Protocol 和 Original Destination Address。Original Source Address 只有在 S=1 时出现，此时最小头长 12 字节；S=0 时只有 8 字节。

这个差异不是任意压缩。若入口正在转发别人的包，它会把 IP Source 换成自己的地址，必须保存原源地址才能在出口恢复。若入口本身就是原始源，IP Source 没有被换掉，于是原源地址仍在当前首部中，无需再抄一遍。

所以，S=0 是一项关于相等关系的声明：当前 Source 也应当是原 Source。它没有签名，也不证明这个地址获准使用。观察者若只有隧道途中的包，可以按 S 位正确解析长度，却没有第二份源地址副本来独立比较。节省四字节的代价，是把正确性押在入口条件和后续关联证据上。

两个校验和各自只回答窄问题

最小头内有 16 位反码校验和，计算范围只含 8/12 字节的最小头，计算时 checksum 字段置零。修改后的 IP header 和其后的 payload 明确不在该范围。它能发现最小头中保存字段的部分传输错误，却不是对整包的认证。

外面的 IPv4 首部另有自己的 Header Checksum。入口因协议、地址和长度变化重算一次；出口把原 Protocol、目的地址及可能的源地址放回去，删掉最小头、缩短 Total Length 后又要重算。两个正确校验和说明两个字段域在各自观察点可被接受，不说明谁授权了隧道，也不说明 payload 到达应用。

“恢复”不是把时间倒回入口

出口恢复的是规范列出的字段，而非入口首部的逐字节快照。原 IP checksum 没有保存在最小头里，出口得到的是对当前重建结果的新 checksum。TTL 更能说明区别：RFC 2004 不像 RFC 2003 那样另造一只外层时钟。原 TTL 留在同一首部，普通转发照常递减，因此隧道 hops 对 traceroute 可见。出口不会把 TTL 还原成入口前的旧值。

成功解封装当然是有意义的运行证据：最小头被解析，字段恢复，数据报能继续按 IPv4 处理。但它只证明这一步。它不证明真实发送者、入口策略授权、中间路径未受干预、出口后的下一跳接受，或应用收到数据。

最短格式先拒绝已经分片的输入

RFC 2004 禁止对封装前已经分片的原始数据报使用最小封装，因为最小头没有空间保存原分片信息。这一入口前提不能与“封装后绝不分片”混为一谈。修改后的数据报仍可使用普通 IP 选项，并可在 DF 未设置时按 IPv4 分片；RFC 1191 的路径 MTU 语义仍然存在。

路由循环防范、隧道 ICMP 和 soft state，RFC 2004 直接指向 RFC 2003；安全章节则坦率地说本文不处理安全，只称其大体类似 RFC 2003。它与 RFC 2002 同期并可服务 Mobile IP，但注册绑定与数据报封装仍是两份记录。RFC Editor 与 Datatracker 能证明文档身份和 Proposed Standard 状态，不能证明部署。

这正是 Lu Heng 的运行代码优先所要求的次序：规范说明共同语法，运行证据才说明系统是否真的执行。他的最小初始规范与现实层次进一步提醒我们，不要让一个局部可验证字段替代它从未承诺的身份、授权和结果。

来源