摘要

  • RFC 2126 为保护 RFC 1006 的既有实现而保留 TPKT version 3，但相同版本号不再证明双方同意 Class 0、Class 2 或任何加速数据选项。
  • 可解析的确认、已协商的第二通道和“正常”断开原因都只是阶段性收据；类接受、跨通道顺序与远端交付仍需分别证明。

RFC 2126 最值得注意的设计不是新增了哪个 bit，而是没有改动 version 3。

1997 年 3 月发布的 RFC 2126 让 ISO Transport 运行在 IPv4 或 IPv6 上的 TCP 之上。它更新 RFC 1006，目标包括扩展适用性、提高性能，以及保护已经依赖 TPKT version 3 的安装基础。若改版本号，那些强制检查 version 3 的旧实现将直接失去互操作机会。

保留旧编号确实保持了外层连续性，也同时削弱了编号的证明力。Class 0 延续并修订 RFC 1006 的服务；Class 2 新增显式 Transport Disconnect 和多种 Expedited Data 行为。两端都看到 version 3，不等于两端具备同一能力。

TCP 已连接，类仍未谈妥

RFC 2126 承认，一些 RFC 1006 实现不会做类协商。发起端可以发送没有备选类的 Class 2 Connect Request，旧端却可能返回 Class 0 Connect Confirm。这个 CC 能正确解析，也经过一条已经打开的 TCP 连接到达，但发起端仍应按 ISO 8073 拒绝它。

这段规则把四件事拆开：version 表示可识别的外壳；CR 记下发起端需要的类；CC 记下响应端选择的类；本地接受或拒绝才说明选择是否满足请求。把四者压成一个绿色“Connected”，恰好会抹掉协议显式暴露的分歧。

TPKT reserved 字段也不能被擅自升级成能力信号。RFC 2126 虽规定了值，却要求接收时不要解释并采取行动，为 RFC 1006 互操作而忽略它。保留位之所以能服务未来，前提正是当前实现不抢先赋予含义。

独立通道不自动带来同步

Class 2 的 Expedited Data 可以继续在 Normal Data TCP 连接内传输，也可以协商 Forward 或 Reverse procedure，建立独立的 TCP 连接。独立通道能避免普通通道繁忙时阻塞加速数据。它必须连接同一对主机，只能属于一条 Transport Connection，并随该 Transport Connection 结束。

这些约束证明归属范围，却不能证明通道何时已经可用。对于 Forward procedure，RFC 没有规定 Expedited TCP 连接必须在何时建立，把时机留给实现。协商成功不是通道已经打开的时间戳。

RFC 2126 还把 independence 与 synchronization 写成两个不同需求。Forward 或 Reverse 提供独立性；Expedited Data Acknowledgement 或 Non-blocking Expedited Data 可以提供同步所需的顺序纪律。只有独立而没有同步，会放宽 ISO Transport Service 的定义，并与 ISO 8072 不一致。

因此，两条健康 TCP 连接最多证明存在两条可用载体。它们并不自动证明跨通道顺序、远端交付，更不证明应用已经处理。

同一个“正常”原因，对应两种交付义务

Class 0 的 Transport Disconnect 依赖底层 TCP 断开，因而是 disruptive。Class 2 通过 DR 与 DC TPDU 提供显式断开，又分成 Disruptive 与 Non-Disruptive 两种。

Disruptive Disconnect 不要求源端尚未发出的 TPDU 在关闭前抵达，DR reason 为正常的十六进制 80。Non-Disruptive Disconnect 要求所有已经交给本地 TS-provider 的 TPDU 在关闭前送达远端 TS-user。它的 reason 同样是 80，但 Additional Information 80 才指出更强的交付契约。

所以，“正常断开”不是完整结论。本地 provider 接受数据，只是开始承担义务；远端 user 收到数据才是另一份收据。若日志只保留 reason code，就无法还原究竟选择了哪种合同。

登记值与安全边界都没有扩大

RFC 2126 为协议保留 TCP port 102，却明确不要求所有连接都用 102。IANA 当前仍登记 iso-tsap port 102 并描述 Class 0。这能证明号码协调，不能证明监听器、Class 2 支持、会话建立或应用结果。

安全章节同样克制：RFC 2126 没有专门解决安全问题，其安全性不多于也不少于 TCP 与 ISO 8073。版本、类、socket 和 port 都不构成组织身份、操作授权、机密性或完整性证明。

卢恒公开的三篇文章提供了一套明示的当代观察角度：运行代码只允许我们声称可观察状态；最小初始规范不应吞并未来决策；符号层的声明不能替代执行层结果。用这套尺度回看 RFC 2126，保留 version 3 不是错误，而是一笔需要逐项记账的兼容性交易。

这笔账至少包含：版本、首选类、响应类、接受决定、第二通道、同步机制、本地接收与远端交付。旧编号可以留下，但它不能再替这八件事签字。

来源