摘要

  • RFC 1613 要求每条 X.25 虚电路使用一条独立 TCP 连接。XOT 中的逻辑信道号可以是任意值，不能区分从不同流抵达的同号呼叫。
  • XOT 层必须把流身份交给 X.25 引擎，后者再为出站本地接口写入适用的信道号。电路身份存在于跨接口映射中，而不在某一个可复制的字段里。
  • 显式流控参数、不能越过隧道的本地控制包，以及 PVC 的另行配置核对，都遵循同一原则：只传递能够跨越边界的状态，在实际执行处验证本地兼容性。

两个合法的“同号”

设想设备 A 与设备 B 同时通过 XOT 呼叫设备 C。两份 X.25 包头里的 Logical Channel Number 完全相同。若 C 只用这个数字索引呼叫状态，两条独立电路就会相撞：一个包可能进入另一条电路的状态机，一次清除可能关闭错误对象。

问题不在数字违法。A 与 B 都可能在自己的接口内正确使用了它。错误发生在 C 把两个本地命名空间压成一个全局命名空间的瞬间。

RFC 1613 正面写出了这个 A、B、C 例子。其标题为 cisco Systems X.25 over TCP (XOT)；RFC Editor 记录显示它发表于 1994 年 5 月，类别是 Informational。状态声明也很清楚：它向 Internet 社群提供信息，并不规定任何 Internet 标准。这里能确认的是一套公开方法，而不是普遍部署或强制采用。

该方法要求每条 X.25 虚电路分别建立 TCP 连接。XOT 连接中的 LCN 没有决定性意义，可以是任意值。C 的 X.25 引擎必须知道两个包来自不同的 XOT 逻辑接口；LCN 本身无法提供这项事实，因此 XOT 层要把流身份传上去。

这不是“字段位数不够”的故事。它揭示的是作用域：本地标识符的意义来自解释它的接口和运行状态。复制比特，不等于把这套上下文一起复制过去。

TCP 流补上了缺失的命名空间

RFC 1613 规定先建立 TCP 连接，再建立 X.25 虚电路；连接使用 TCP 端口 1998，而且不得在 SYN 中夹带 XOT 数据。今天的 IANA 服务名与端口号登记表把 x25-svc-port 的 1998 行列在 TCP 与 UDP 下。登记行只是在协调数字，不证明任何主机正在监听；RFC 1613 描述的 XOT 仍然是 TCP 方法。

一条虚电路一条 TCP 连接，使“这条活着的流”成为查找键的一部分。TCP 端点与连接生命周期能把相同 LCN 的流量分开，但它们并不自动证明对端身份、呼叫权限或应用结果。流提供传输和命名空间，不能替代上层决定。

历史上的 RFC 793把 TCP 描述为有序八位组流，并不保留 X.25 包边界。RFC 1613 因此加上四字节 XOT 头：16 位 Version 与 16 位 X.25 包 Length。Version 必须为零；非零版本或非法长度都要求关闭 TCP。

这段分帧只是必要前提，不是本文的新主题。RFC 1006早已用另一种四字节头在 TCP 上恢复 TPDU 边界，BTW 也已经单独报道。RFC 1613 更值得追问的是：即使一个包被完整切出，只要实现丢失了流与接口上下文，它仍会被归到错误电路。

出站接口重新写下自己的号码

XOT 从 TCP 收到 X.25 包并转向本地接口时，RFC 1613 要求把 LCN 设成该出站接口使用的号码。这条规则直接否定了“字段就是身份”的直觉：号码可以在交接处改变，意图中的虚电路仍然延续。

一份可审计记录至少要把四项事实连起来：哪条 TCP 连接交付了完整包、它被绑定到哪个 XOT 逻辑接口、入站包头出现什么 LCN、出站本地接口最终选了什么 LCN。只记内层号码，得到的是精确外观下的歧义；只记 TCP 端点，又看不到本地 X.25 分配。

这正是 Heng Lu 的 Running-Code Primacy可以落到实处的地方。标准给出最小互操作规则，运行中的配置、状态迁移和包观测证明某一次映射。可成立的结论应当是：“这个实现此刻把来自这条流和这个逻辑接口的完整包，映射到这条本地信道状态。”再强的身份或结果，需要别的证据。

隐含默认值无法跨越多个网络

传统 X.25 网络可能拥有默认包大小和窗口大小。RFC 1613 的作者认为，经由 TCP/IP 把不同站点连起来后，很难维持同一套网络默认值，所以每个 Call 都必须显式携带 Packet Size 与 Window Size facility。

缺少其中一项的呼叫是否接受，仍由本地决定；一旦接受，Call Confirm 必须返回实际采用的值。共同层严格规定必须交换什么，本地系统保留是否承受该值的决定。这比假装默认值全球一致更诚实。

流控也可以端到端完成，或在各本地接口分别完成。后一种实现可能拆分、合并数据包，并在两端维护不同的包序号。若支持 modulo 128 与 modulo 8 混接，实现必须翻译状态；对 modulo 8 一侧过大的窗口必须降低或拒绝。一个方向发送的 RNR，也不能被假设为会阻止另一个方向的数据。

因此，“TCP 可靠”绝不等于 X.25 窗口已协商、包序号已正确翻译、接收方已准备好，更不等于业务完成。每一项都是不同层拥有的状态。

能穿越的控制，与必须止步的控制

Interrupt 与 Reset 具有端到端意义，RFC 1613 让它们及确认包穿过 TCP。Restart、DTE Reject、Diagnostic 与 Registration 只在本地 DTE/DCE 接口上有意义，不得穿过 XOT；若从 TCP 收到，就静默丢弃。

封装没有让所有内层含义突然变得可移植。实现必须知道哪些状态能越界，哪些状态应当在边界终止。“透明隧道”从来不是无条件透明。

永久虚电路进一步暴露了这个问题。X.25 的 PVC 原本由网络提供者预先配置，没有 Call/Clear 交换。要让它通过 XOT，双方必须在 TCP 建立后使用一种非标准 PVC setup，交换接口名、本地 LCN 与流控值，并验证配置相容。

状态码会区分接口不存在或未启动、目标不是 X.25、PVC 不存在、配置不匹配、流控不兼容与 setup 协议错误。成功状态为零，随后两边本地接口都执行 Reset；关闭 TCP 就表示 XOT PVC 断开。若同时发起导致两条 TCP 连接，流量不得同时走两条，必须选定其一或随机等待后重试。

这些状态适合运维，却不能被升级成社会身份或业务完成证明。“Connected”只描述一台实现的某个 setup 状态。

证据边界

RFC 1613 的安全章节只说：本文不讨论安全问题。沉默不是保障。资料没有证明对端认证、加密、授权、暴露策略，也没有证明能抵抗注入或错误绑定。端口号、合法版本、正确长度、匹配的 LCN 或 PVC 成功码，都不能代替这些属性。

本文没有测试任何 XOT 实现、Cisco 版本、运营商网络或抓包。RFC 关于当时“现有实现”采用端到端流控的说法，只是 1994 年文档内的时期陈述。IANA 行不证明服务在线。现有来源也不能建立当前部署量、普及率、事故史、应用完成或对现代隧道的直接谱系。

能确定的结论更小，也更可靠：字段可以完全合法，却仍没有足够作用域标识运维对象。RFC 1613 把共识层限制在必要规则，让实现传递流身份，再让每个本地接口写入自己能兑现的号码。电路之所以没有被“同号”吞没，是因为系统保留了字段装不下的边界。

来源