摘要

  • RFC 2043 在 PPP 上定义了两套分别协商的 SNA 网络控制协议：0x804B 控制以 0x004B 承载的 LLC 802.2 路径，0x804D 控制以 0x004D 承载的 HPR NLP 路径。
  • Opened 只说明 PPP 获准承载相应封装。SNACP 没有配置选项，RFC 2043 也没有讨论安全；这一状态不证明另一种封装、错误恢复结果、身份、授权、交付、部署或 SNA 业务会话成功。

“SNA 已经打开”听起来像一个完整结论。RFC 2043 实际给出的结论更窄：某一套 SNA 网络控制协议已经走到允许 PPP 承载某一种 SNA 包的状态。

这段差别才是 RFC 2043 值得保留的历史对象。1996 年 10 月发布的这份文档，并没有讲一部 PPP 或 IBM 企业网络的兴衰史。它处理的是一条点对点链路上的两种封装如何不被混为一谈。两者共用物理链路，却有不同的协议号、控制状态和包结构。协议没有给它们一个可以笼统汇总的“SNA 成功”开关。

先有链路，后有逐协议放行

PPP 本来就不是一次握手包办所有事情。RFC 1661 把生命周期拆成物理层可用、LCP 建立并配置数据链路、可选的认证与链路质量判断，以及后续的网络层协议阶段。只有到了最后一个阶段，各网络层协议才分别运行自己的 NCP。

因此，载波存在与网络层可用是两类证据。LCP 进入 Opened，说明共享 PPP 链路完成了自己的控制交换；它不替 IP、SNA 或其他承载协议宣布就绪。RFC 1661 允许每套 NCP 随时独立打开或关闭。某个受支持的网络层协议如果在对应 NCP 尚未 Opened 时到达，就必须被静默丢弃。

RFC 2043 继承这套结构，又在 SNA 内部再切一刀。它明确说，实际上存在两套 SNA NCP：一套用于 SNA over LLC 802.2，另一套用于不带 LLC 802.2 的 SNA。两套协议分别、独立协商。共用一条线，只说明它们共享承载条件，不说明它们共享状态。

四个编号组成两对控制与数据

协议号把这道分界写在包头里。PPP 将包含 0x004B、0x004D 的低位范围用于网络层协议包，将包含 0x804B、0x804D 的 0x8*** 范围用于相应的 NCP。RFC 1700 在 RFC 2043 发布前已记录四个值；今天的 IANA PPP registry 仍然列出它们，并将引用指向 RFC 2043。

第一对是带 LLC 的路径。SNA over LLC 802.2 的控制包使用 0x804B。对应 NCP 打开后，0x004B 的 PPP Information field 承载恰好一个带 LLC 802.2 的 SNA XID 或 FID2 路径信息单元。包内依次保留目的服务访问点、源服务访问点、控制字段和 LLC 信息字段。

第二对是直接的 HPR 路径。控制包使用 0x804D，数据包使用 0x004D，承载恰好一个 High Performance Routing 网络层包，由网络头、传输头与数据组成。这个封装没有前一条路径中的 LLC 字段。

这两对不是同一种许可的两种写法。看到 0x804B 的 NCP 进入 Opened，只能得出 PPP 可以承载 0x004B 封装。它不会顺便打开 0x804D；反过来也一样。监控系统若只留下“SNACP 已打开”，就主动丢掉了最有价值的区分信息。

错误恢复被放在一条路径上，但仍不是结果证明

RFC 2043 给 LLC 包装层安排了一项具体职责。LLC(2) 被包含进来用于链路级错误恢复，恢复工作由 PPP 链路两端的路由器执行。这说明责任落点不在抽象的物理线缆，也不在更远处的业务应用。

责任位置却不等于执行结果。观察到 0x004B，可以证明一个带 LLC 的 SNA 单元以该结构被提交。它不能证明发生过重传、恢复最终成功、远端路由器接受了 PIU，更不能证明某个 half-session 已处理其中的 BIU。

HPR 的结构让对比更清楚。0x004D 直接装入 NLP，不带 LLC。RFC 2043 同时保留了一个架构可能：若实现包含可选的 HPR 链路级错误恢复 tower，也可以把 HPR NLP 放到 LLC over PPP 的 0x004B 路径。那是实现选择，并不会合并两套 NCP，更不会让一套 Opened 替另一套状态作证。

没有配置选项的协商，只能作出很窄的承诺

SNACP 沿用 LCP 的交换机制，但只使用七种代码：Configure-Request、Configure-Ack、Configure-Nak、Configure-Reject、Terminate-Request、Terminate-Ack 与 Code-Reject。紧接着，RFC 2043 明确写道：SNA 和 SNA over LLC 802.2 都没有 Configuration Options。

这是全文最容易被忽略、也最有解释力的限制。协商可以就固定的协议族是否启用达成状态，却没有任何选项用来协商 SNA 身份、应用 profile、恢复目标、安全属性、路由、事务保证或业务准备度。请求里从未携带的信息，Configure-Ack 不可能替它确认。

所以，Opened 必须与它所属的状态机一起阅读。它表示两端控制交换到达允许相应网络层协议包通过的状态；它不表示运维看板或业务负责人所说的“SNA 已经工作”。

安全与身份不在这份文档的证明范围内

RFC 2043 的 Security Considerations 只有一句：本文不讨论安全问题。这不是隐藏的安全保证，而是一条明示边界。

PPP 可以在进入网络层协议阶段前执行认证，但 RFC 1661 规定默认并不强制认证。即使另有认证交换成功，证据仍需指明认证方法、对端和结果。一套 SNA NCP 的 Opened 不能代替这些记录，也不能证明 SNA 内部授权、链路机密性、端到端完整性或应用端点身份。

包长也体现同样的克制。RFC 2043 把 SNA 包最大长度绑定到 PPP Information field；RFC 1661 把这个上限称为 MRU，默认 1500 字节，也可另行协商。它证明承载容器能装多大，不说明接收者如何处理其中内容。

小协议留下的大型证据教训

RFC 2200 在 1997 年把 PPP-SNACP 列为 Elective。RFC 3790 后来指出 RFC 2043 没有 IPv4 依赖。当前 IANA registry 仍保存四项分配。它们分别支持历史状态、与 IP 版本的架构关系和当下编号身份，却都不是部署普查。

这些记录不能推导出任何具名实现、互操作测试、流量规模或业务结果。RFC Editor 当前没有 RFC 2043 的 errata，也只说明勘误库的现状，不证明协议完美或被广泛使用。

借用 Heng Lu 对规范、运行代码和现实结果的分层，RFC 2043 展示了一份很薄的公共规则：辨认封装，运行相应控制交换，在 NCP 打开前拒收该协议包。实现、恢复、安全与采用仍在别处。文档描述了一种兼容可能，只有实现、观察和依赖关系才能证明运行现实。

因此，严谨的历史记录应分开四句话：PPP 链路到达网络层协议阶段；某个具名 SNACP 到达 Opened；带匹配数据协议号的包被承载；独立证据说明之后发生了什么。缺少任何一句，记录都会变弱。把四句压成“会话已上线”，记录就会变成错误。

来源