摘要

  • RFC 2509 沿用的 TCP_SPACE 与 NON_TCP_SPACE 表示上下文标识符的最大值，因此零仍包含 CID 0，也就是一个上下文。
  • RFC 3544 的三字节子选项 3 可以明确指定 TCP 或非 TCP 上下文数为零，从而覆盖旧字段并关闭该类压缩。

误解来自字段名称。TCP_SPACE 和 NON_TCP_SPACE 不是上下文数量，而是标识符的上限。上限为零时，编号空间仍含 CID 0。对最小配置而言，这可能足够；但仅靠这两个字段，无法说出“完全不要压缩这类报文”。

RFC 3544 于 2003 年 7 月作为 Proposed Standard 发布，修订了 RFC 2509 的 PPP 协商选项，却没有改变旧字段的含义。新增的子选项 3 填上表达缺口：类型为 3、长度为 3 字节，最后一个字节是参数。参数 1 表示 TCP 上下文数为零；参数 2 表示非 TCP 上下文数为零。它会覆盖 IP Header Compression 选项中相应的 TCP_SPACE 或 NON_TCP_SPACE 值。如果两个参数都出现，所有报文都不使用压缩。

这是通过明确覆盖来保持兼容，而不是重新解释零。旧字段继续维持既有语义，额外信号承载旧字段装不下的“关闭”意图。若直接改写零的含义，新旧对端便可能对同一组比特做出不同解释。

两套网络控制协议各自协商

PPP 通过网络控制协议协商链路参数。RFC 3544 为 IPv4 的 IPCP 和 IPv6 的 IPV6CP 定义相同的选项格式。每套协商分别配置外层网络首部属于相应版本的报文。因此，IPv4 压缩已协商与 IPv6 压缩已协商，是两个独立的控制面结果，并非一个总开关。

还有一个更细的限制：IPv4 与 IPv6 共用上下文标识符空间，虽然参数是分别协商的。参数不同的时候，压缩引擎必须从公共池分配标识符；解压端则需要检查上下文状态，判断应用哪组参数。TCP 与非 TCP/UDP/RTP 类别并不共用上下文空间。这些是协议规定的运行约束，却不能证明某个对端真的完成了配置或在数据面使用它们。

RFC 3544 还增加了类型 2 的增强 RTP 子选项。它替代旧的 RTP 子选项 1，而不是与之叠加。连同九个 PPP 协议字段值，这些选项让接收端识别帧的类别及可用的协商格式。协议字段承担分用作用；子选项表达配置意图。

协商结果不是数据面收据

选项成功协商后，相关协议标识符可以启用。这并不能说明实现真的发出了压缩帧、远端成功解码、数据报最终送达，或者压缩后长度更短。这些事实发生在链路的不同位置。配置交换证明双方同意一组参数，并不证明流量已传送。

标准还谨慎标注了一处邻近的歧义：RFC 1332 没有说明此选项描述发送方还是接收方的能力。RFC 3544 说，按照当时的实践，它假设 Config-Req 描述发送请求的对端所拥有的解压能力。这是清楚标出的假设，不是对 RFC 1332 的规范性澄清。若把它说得更强，就抹去了原文的保留意见。

数据面还受另一项条件约束。IPHC 对 TCP 和 RTP 使用差分编码，压缩报文依赖双方共享的上下文。PPP 本身不会重排报文，因此默认关闭重排防护机制。如果使用多类 Multi-Link PPP 等可能重排的机制，同一压缩上下文中的报文就不能乱序。协商格式并不会消除传输层的这个前提。

这里的历史经验很具体：协议演进有时需要第二个信号，因为直觉上最简单的值已经有有效含义。RFC 3544 保留旧字段、增加明确覆盖，并把能力、实际发送、解码、交付和性能收益留作彼此独立的待验证事实。

来源