摘要

  • RFC 1086 允许 TCP/IP 主机请求桥呼叫一个 X.25 地址，或登记一个 X.25 监听子地址，再把来话接到指定的 IP 地址与 TCP 端口。
  • 监听登记依赖原始 TCP 连接持续存在；连接关闭后，桥停止监听并释放有限子地址。这是期限信号，不是身份或权限证明。
  • 一次成功来话仍由 X.25 与 TCP 两条独立网络连接承载。桥转送 TPDU，不保证对端真实、应用接受或用户结果。

桥要解决的首先是“替谁守号”

RFC 1006 已经说明 TP0 怎样运行在 TCP/IP 上，X.25 一侧也有既定的 TP0 承载方式。1988 年的 RFC 1086 没有再造一种传输协议，而是让一个同时接入两种网络的主机把两侧接起来。

作者把范围压得很窄。这不是 DDN 与 ISO 互通的万能方案；两端必须本来就在运行 TP0 及更高层 ISO 协议。桥不理解任意应用，也不把所有 TCP 流量变成 X.25 服务。

真正棘手的是反向来话。X.25 主机需要呼叫桥名下的某个子地址，实际服务却位于 IP 主机。桥的 X.25 地址空间有限，不能让每台偶尔上线的主机永久占一个位置。可如果登记没有可观测的终点，失联主机会留下无法安全回收的空壳。

RFC 1086 选择用一条长期 TCP 连接表示“这项监听仍在继续”。

一个功能字节分开外呼与监听

登记主机先连接桥的 TCP 146 端口，再发送一个功能字节。值 1 表示希望桥呼叫指定 X.25 地址；值 2 表示希望桥在指定 X.25 子地址上监听。零非法，其余值保留。

外呼路径很短：主机交出 X.25 地址，桥尝试建立呼叫。若失败，桥关闭 TCP 连接，并不增加一套网关专有错误体系。

监听路径需要保留状态。主机先给出一个应属于桥自身 X.25 地址的子地址，再给出处理来话的 IPv4 地址和 TCP 端口。桥代表它监听。来话到达时，桥另开一条 TCP 连接去回调登记端；回调失败，X.25 来话便被拒绝。

这条登记只在一台桥、一个运行时期内有效。它表达的是“当前把这个入口接到那个回调”，而不是向全球目录宣告所有权。

所谓心跳，没有心跳报文

规范把原始登记连接称为 heartbeat。它没有定义周期探测、应用请求、健康评分或超时消息。只要 TCP 连接还在，桥就继续保留监听；连接一旦关闭，桥便认为监听结束。

随后发生的是资源回收。桥停止代表主机接听这个子地址，使有限位置能够再次分配。这个设计不必相信远端会发送一条完美的注销消息，桥可以从自己维护的连接状态触发清理。

不过，连接存在只回答时间问题。它不证明远端是谁，也不证明回调程序仍能工作。未经授权的主机可以一直保持连接，占住稀缺位置；短暂链路故障也可能让合法主机失去登记。

“活着”与“有权”是两条证据。“控制连接未关闭”与“应用健康”同样不是一回事。

上层看见 TP0，下层仍是两条连接

建立成功后，桥拥有两条网络连接：一侧是 X.25，另一侧是 TCP。TP0 分别运行在两者之上。数据阶段，桥从一侧读取 TPDU，再写入另一侧；任一网络断开，桥就断开另一侧。

RFC 905 提供 TP0 与 TPDU 的语义背景，RFC 793 是当时 TCP 打开、传输与关闭的依据，RFC 1006 则规定 TCP 流中的 TPDU 承载。RFC 1086 的独特部分是连接建立前后的登记接缝。

因此，一段看起来连续的 TP0 会话下面仍有两个故障域。X.25 呼叫可能成功，TCP 回调却失败；登记连接可能保持，而某次数据连接已经中断；TCP 打开成功也不能证明上层应用认可对端。

桥接的是协议承载，不是把两张网变成一个物理事实。

少说一种错误，代价是运营侧要多记事实

RFC 1086 刻意不引入 TP0 之外的错误报告。可恢复网络错误被忽略，其他问题以断开结束。桥特有动作集中在建立阶段，之后尽量让电路看起来像普通 RFC 1006 实现。

这种透明性降低了端点复杂度，却压缩了公开诊断信息。同一次断开可能来自 X.25 拒绝、TCP 失败、本地策略或桥容量耗尽。协议不暴露细节，不等于细节不存在；运营者必须在桥内留下因果日志。

安全不是格式字段，而是本地决策

规范直接说明：认证与授权由本地处理。它还警告，若桥不限制访问，任何 TCP/IP 主机都能声称占用桥有限 X.25 地址空间的一部分。

这句话划清了登记语法和准入权力。IP 地址用于寻路，不是人的身份；TCP 连接提供有状态通道，不是凭证；一个空闲子地址是待治理容量，不是先到先得的财产。

桥运营者必须补上协议没有携带的判断：请求者以什么主体被识别、可用哪些子地址、能同时占多少、最长多久、冲突如何处理、决策由谁批准以及何时撤回。

功能字节只是请求。允许请求生效，是另一项可问责的动作。

固定格式也不是永久身份

RFC 1086 为 X.25 地址记录规定 68 octets，其中包含 X.121 地址、协议标识、call user data、facilities 以及相应有效长度。TCP/IP 回调记录则包含地址类型、TCP 端口、IPv4 地址和保留填充。

作者自己称这些结构为 ad hoc，并指出它们带有 UNIX 特性，未来可能随经验变化。结构足以让实验互通，却没有因此成为跨系统身份标准。字节可解析，只能证明它符合格式。

今天的 IANA 服务名与端口注册表 仍列出端口 146 的 iso-tp0。IANA 同时明确提醒：端口分配不是对应用的背书，观察到的流量也未必属于登记服务。注册表还有 UDP 行，但 RFC 1086 的登记流程使用 TCP；一行注册信息不能替规范创造 UDP 模式。

五种状态不能压成一个“在线”

可靠记录至少分五层：原始登记请求、本地准入决定、登记连接期限、某次来话的 X.25/TCP 配对状态，以及 TP0 或应用结果。

控制连接打开时，回调仍可能不可达；回调成功时，原始占用仍可能未经授权；TP0 收到响应时，用户要求的工作也可能没有完成。任何一个绿色状态都不足以代表全部。

RFC 1086 留下的历史价值正在这里。它用连接关闭解决了临时资源何时撤销，却没有把撤销机制伪装成身份系统。互通可以在一条明确接缝上成立，治理仍需由真正控制稀缺资源的一方承担。

来源与边界

RFC 1086 是桥机制的直接来源；RFC 1006、RFC 905 与 RFC 793 限定相邻层；IANA 只证明当前登记。它们不能证明现实部署、产品行为、真实地址归属、主体身份、合规、某次呼叫成功或人的最终体验。