摘要

  • IPv4 的 7 号选项预留有限个四字节槽位，让愿意配合的转发系统写入地址，却不让发送者决定实际路径。
  • 这份记录容量有限、没有认证，还会暴露拓扑；路由器规范中的“默认处理”后来因此转向安全建议中的“默认丢弃”。

指针每次向前四格

Record Route 的结构并不复杂：类型、长度、指针，后面是一片路由数据区。源主机必须在出发前决定整块空间有多大，并把数据区清零。指针指向下一个地址的起始位置，最小合法值是 4；每写入一个 32 位互联网地址，指针就增加 4。

RFC 791 要求处理该选项的互联网模块写入自己在下一段转发环境中的地址。RFC 1812 又把路由器的选择说得更具体：使用逻辑出接口的 IP 地址；若接口未编号，则写入稳定的 router-id。记录中的地址因此更像一次转发所采用的“出面身份”，未必等同于整台物理设备的唯一名称。

这本地址簿不能在途中加页。指针超过长度时，数据区已满，数据包仍会继续转发，只是不再新增地址。若只剩一至三个字节，看似有空位却放不下完整地址，RFC 791 将原数据包判为错误并丢弃，同时允许发送 ICMP Parameter Problem。该选项最多出现一次，分片后只留在第一个分片中。

常见的“最多九个地址”也是首部尺寸算出来的。IPv4 首部最长 60 字节，固定部分占 20 字节；若几乎全部剩余空间都给 Record Route，40 字节扣除类型、长度和指针后余 37 字节，只够九个完整地址。这只是理想上限，不保证九跳都响应，也不保证路径只有九跳。

记录路径，却不指定路径

名字容易让人把它与 Loose Source and Record Route、Strict Source and Record Route 混在一起。后两者携带发送者指定的中间地址，会影响下一步往哪里转发。7 号选项没有这种权力：普通路由先决定路怎么走，它只是请实际经过的参与者留下观察。

因此，地址列表的证明力有限。格式里没有签名，没有稳定设备身份，也没有任何字段证明所有中间路由器都参加了。一段空白可能只是预留过多，也可能来自过滤、透传不写、没有实现、分片，或实际路径与预期不同。已有地址能说明某个系统在那次行程中配合过；缺少地址却不能说明中间没有设备。

RFC 1122 将主机生成和处理 Record Route 都列为可选。不过，它建议 ICMP Echo Reply 更新请求中携带的该选项，并原样带回，从而形成往返记录。诊断意图很清楚，但每一个管理边界都保留拒绝配合的权力。

默认值的逆转

1995 年的 RFC 1812 要求路由器支持对转发数据包中的 Record Route 进行处理。设备可以提供一个“保持不变”的开关，但默认应允许记录。文件已经承认拓扑泄露的担忧，却仍把协作视为正常状态。

到 2014 年，RFC 7126 给出的运维起点相反。该选项可用于摸清网络拓扑，虽然有限的首部空间会限制它；屏蔽它会破坏明确使用 RR 的 ping 等诊断，但不会影响普通 ping。更关键的是，广泛丢弃已经让这类跨网诊断几乎无法使用。因此，新建议要求提供针对该选项的丢弃、忽略或正常处理三种策略，并把有文档说明的默认值设为“丢弃”。

来源