摘要

  • RFC 1473 为 PPP 上的 IP 控制协议分别设置了配置表和运行表。管理端写入 open，只是向 IPCP 状态机注入一个事件，不保证它真的到达 Opened。
  • 压缩偏好要在下一次链路重启时才产生作用。协商完成前，表中返回的压缩方式和槽位值明确处于“未定义”区间；协商完成后，它们也只说明参数，不是 IP 包已抵达的回执。

1993 年 6 月发布的 RFC 1473 很短。它没有把 PPP 管理做成一个包罗万象的仪表盘，而是为 IP Network Control Protocol 留下少量故障与配置管理所必需的对象。仅为调试而设的项目被排除，可以从别处推导的值也不再重复。

这种克制把一个常被界面抹平的时间差写进了规范：想要的状态、已经协商出的状态和线上真实发生的流量，并不是同一件事。

open 是输入，不是结论

配置表中的 pppIpConfigAdminStatus 表示“立即希望达到”的状态。写入 open，会向 IPCP 有限状态机注入管理 Open 事件；写入 close，则注入 Close 事件。

“注入事件”比“打开成功”精确得多。代理接受写入，只能证明请求进入了管理接口。状态机随后还要面对下层链路、对端响应、选项是否可接受以及超时。一次 HTTP 或 SNMP 成功响应，不会替协议替对端作出决定。

后来的 RFC 1661 继续保留这层划分。每种网络层协议由自己的 NCP 配置；它们可以独立 Opened 或 Closed。同一条 PPP 链路上，IPCP 失败并不自动说明其他 NCP 也失败。

新值先进入等待区

另一个可写对象 pppIpConfigCompression 指定本端下一次要尝试协商的方式：不压缩，或 Van Jacobson TCP/IP 首部压缩。RFC 1473 没说它会立刻改变当前会话，而是明确规定，更改要在链路下一次重启时生效。

因此，写入后的新值是一项未来偏好。若要证明它变成了运行事实，至少需要四张收据：代理确实保存了它；发生了哪一次重启；那次重启后的 IPCP 交换提出了什么；最终状态是什么。

RFC 1332 定义了背后的 IPCP 协商。IP-Compression-Protocol 默认不启用压缩，而且双向压缩要求两端分别请求接收能力。一端愿意接收压缩包，不等于另一方向已经获得同样结果。

未定义不是“可能有点旧”

运行表给出 pppIpOperStatus，以及本地到远端、远端到本地两个方向的压缩协议和 Max-Slot-Id。RFC 1473 随后给出限定：这些选项参数必须等到 PPP 选项协商完成、IPCP 到达 Opened 后才可用。

在此之前，内容未定义；具体返回什么，由实现决定。

这不是普通的“数据可能陈旧”。陈旧值至少曾经描述某个过去状态；未定义值甚至不承担这一语义。它可以是零、默认值、残留值或实现者选择的任何占位。类型检查完全通过，也不能把它升级成协商证据。

进入 Opened 后，还要保留方向。local-to-remote 描述本端发送时使用的方式，remote-to-local 描述相反方向。若未使用 VJ 压缩，槽位值应为零；若状态尚未 Opened，零本身又不能证明“已协商为不压缩”。

Opened 仍然不是一个包

RFC 1332 规定，PPP 必须进入网络层协议阶段且 IPCP 必须进入 Opened，IP 包才可以通信。RFC 1661 又规定，对应 NCP 未 Opened 时收到的网络层包必须丢弃。

所以 Opened 是重要门槛，但它仍是状态机事实。它没有指明哪一个包被发送、是否有计数器增长、压缩首部能否正确恢复、路由是否存在，也没有应用层的响应。

RFC 1144 解释了慢速串行链路上压缩 TCP/IP 首部的价值。可协商这种能力，不等于某个包适合压缩；出现压缩包，不等于对端正确重建；正确重建，也不等于业务得到结果。

管理视图应保留这条边界

RFC 1473 把可写配置单独放在一张表里，便于划入不同管理视图。其安全讨论提醒，PPP 配置和控制本身有风险，可通过只读实现、受保护视图或禁止访问来收紧权限。配套的 RFC 1471 管理 LCP，RFC 1472 管理认证配置；这组文档没有假装存在一个能解释一切的绿色灯号。

可靠的变更记录应串起：谁提出压缩变更、代理保存了哪一代配置、它对应哪次重启、两个方向各提出和接受了什么、IPCP 何时进入和离开 Opened，以及随后有哪些包、错误和应用回执。

只保留最后一个数字，会让待重启的偏好看起来已经在线，让未定义读值看起来已经测得，让 Opened 看起来像流量已经送达。

RFC 1473 留下的管理常识是：系统不仅要显示已有事实，也要标清事实尚未成立的区间。

来源