摘要

  • RFC 1475 为每个数据报设置 64 位前向路由标识，但标识只对签发它的下一台路由器有意义，上游只负责原样带回。
  • 零值、无效值、路由汇总、路由变化、流状态与协议转换都会触发重新判断；标识连续不等于路径连续。
  • Experimental、CATNIP 与后来的 Historic 状态说明的是文档与选择过程，不能替代实现、部署或实际转发证据。

一个字段，三次换义

把 X 和 Y 两台主机放在链路两端，中间依次是 A、B、C 三台路由器。现在只盯着数据报中的一个 64 位字段：X 发出时是零；A 转发后成为一个数；B 转发后又变成另一个数；C 最后清零。若把这个字段直接叫作“路径”，日志看起来像路径被反复篡改。可在 RFC 1475 的设计里，这恰恰是正常动作。

这份 1993 年 6 月发布的实验性 RFC 描述 TP/IX，也称 Internet Protocol version 7。它尝试扩大地址、调整传输层字段，并用 forward route identifier 缩短逐包查表过程。关键并非所有设备共享一套编号，而是每台路由器可以把自己的私有引用交给上游邻居。引用甚至可以是表项索引或实际内存地址。邻居不需要理解，只要在把流量送回来时把值放进报文。

于是，同一个字段名掩盖了不同的所有者。A 写入的是 B 先前给 A 的标识；B 收到后能在自己的状态中解释它。B 随后覆盖字段，写入 C 给 B 的标识；到了 C，解释权又归 C。目的主机 Y 看到自己的目的地址后，根本不必理会这个字段。

字段的位是真实的，跨设备的统一含义却不存在。若抓包系统只保存数值而不保存签发设备、状态代际和生效时间，它保存的就像是一串没有锁的钥匙齿形。

零不是“没有路”

X 发出的第一个数据报把字段置零，不是宣布目的地不可达，而是表示当前没有可用的借入标识。A 仍按目的地址查询自己的路由表，选中经 B 的路由，再把 B 的私有标识写入报文。零值要求做一次普通决策，而不是给出失败结论。

无效值也一样。RFC 1475 意识到直接把内部引用带到报文里有风险，尤其当引用类似内存地址时。路由器应当检查范围、对齐方式，并很可能确认所指路由与数据报目的地相符。如果检查不通过，就悄悄忽略标识，回到普通目的地址查找。

这把性能与正确性分开了。标识命中可以少做一次查找，但本地路由表和目的地址仍是恢复权威。收到一个格式合法的非零数，只能说明报文带着一个候选引用；它不能独自证明引用仍有效、出口已选定、下一跳已收到，更不能证明最终交付。

同样的数值还可能在两台设备中指向无关对象，不同数值也可能把报文送上同一条物理链路。缺少签发者与上下文，数字无法自行说明“去了哪里”。

汇总边界迫使路由器重新选择

路由汇总最能暴露标识的作用域。一个标识也许只定位到汇总路由。当报文抵达子路由开始分叉的设备时，粗粒度引用已经不够。设备必须检查更具体的目的前缀，选出具体路由，再为下游写入新的标识。

所以，快速路径会在借来的知识过于粗糙之处结束。字段并没有预先携带所有分支决定，而是把上一次足够精确的状态带到下一个决策点。汇总不是异常；它是设计承认“全局路线图并不存在”的地方。

路由变化又增加了一层时间问题。RFC 1475 说，当数据报飞行期间路由发生改变，某台路由器必须决定如何把每个数据报重新“上轨”。旧标识可能忠实记录早先的状态，却已不适用于此刻。报文里的值不会冻结控制平面，状态变化反而要求设备重新夺回选择权。

这也是历史研究中容易越界的一步：规范中存在一个字段，不等于部署中存在同样的状态；抓到一个字段，不等于知道路由器怎样解释；知道路由器接受了它，也不等于掌握端到端经过的所有节点。

流标识没有越过同一条边界

TP/IX 还允许用流标识替代路由标识。每台路由器可以保存私有流对象，让它指向建立该流时使用的路由。数据报可以进入或退出流，主机或附近的协作路由器可以把报文插入流中。

但“流”并未让字段变成发端可读的合同。路由器可用私有方法区分自己的路由 ID 与流 ID，上游发端无需知道分类规则。一个非零值因此不能独自证明资源已经预留、容量得到保障或服务结果已经兑现。还需查询签发设备的对象类型、状态代际、关联路由、使用时刻与实际出口。

RFC 1475 也明确没有讨论安全问题。范围、对齐和目的地一致性检查属于本地有效性验证，不是身份认证、授权或完整性保护。把私有句柄当作安全凭证，会给字段赋予规范从未提供的权力。

RAP 的承诺只对一个时刻成立

配套的 RFC 1476 描述 RAP 路由访问协议。它要求 Add Route 提供的路由在发布当时确实已经装入发送方的转发表，接收方随后把提供的 64 位标识放进发往该对等方的数据报。

这是有操作含义的陈述，但仍带时间边界。“发布时已装入”不等于永远存在。RAP 因而设计 Purge Route：接收者要删除路由，并向曾接收该路由的对等方撤销。文档倾向于先发送 purge、再本地删除，却承认不能强制这一顺序。

本地删除、purge 发出、撤销传播与在途数据报之间存在多个时钟。某个标识可以作为先前 Add Route 的真实证据，同时已无法代表当前转发状态。RFC 1476 的信息页 能确认文档身份和状态，不能替我们补齐每台设备的时间线。

转换点选择了清零

TP/IX 希望 IPv4 与 IPv7 节点可以任意顺序升级，因此包含转换机制。“Don't Convert”选项约束线上的路由器转换，却也显出边界：协议能规定线上比特，主机仍可能在内部处理过程中转换。不同路径上的分片如果到达不同转换器，可能无法重组。拥有混合 IPv7 地址，也不能证明系统是原生 IPv7 实现。

IPv4 转 IPv7 时，前向路由标识被设为零。转换器没有把无法解释的私有句柄复制到新体系，制造虚假的连续性；它明确要求下一段重新做决定。地址版本、转换动作、分片命运、路由标识和最后交付必须分别留证。

文档最终归档，不等于实验现场被抹去

RFC Editor 信息页 如今把 RFC 1475 标记为 Historic。RFC 1752 记录 TP/IX 后来演变为 CATNIP，评估认为 CATNIP 不够完整，并推荐以 128 位 SIPP 为 IPng 基础。RFC 6814 在清理过时 IPv4 选项时正式废止 RFC 1475，而 RFC 791 仍是 IPv4 的基础文本。

这条材料链可以支持三类结论：当时提出了什么，后来如何比较，最终文档状态怎样。它不能证明没有人试做过组件，也不能证明任何一台生产路由器曾执行该机制。反过来，RFC 正式发布和“下一代互联网”的标题也不能证明部署已经发生。

规范、建议、代码、设备状态、报文观测与结果回执处在不同现实层。严谨的互联网史不把它们压成一个“采用/未采用”标签，而是保留每一层自己的证据与边界。

来源