摘要

  • SCHClet 工作组草案提出只实现一个 SCHC Stratum、一个 Instance 和一项有限功能的小型组件；它可以不带规则管理，也可以完整省略用于标识上下文的头部。
  • 被省略的语义转移到了 SCHClet Configuration。真正的互操作凭证必须覆盖双方配置一致、未匹配输入的处置、报文重建以及上层服务结果，而不能止于 RuleID 可被解析。

头部被完整省略以后，配置就成了报文无法自行携带的语义。发送端知道这是哪个 Stratum、哪个 Instance、哪套规则；接收端必须独立知道同一件事。字节减少了，双方保持同一解释的责任却更加集中。

这正是 2026 年 9 月 29 日发布的 SCHClet 草案第 01 版 最值得关注的地方。它是 SCHC 工作组正在推进、拟进入标准轨道的 Internet-Draft，不是 RFC，也不是部署、性能或互操作测试报告。草案把 SCHC 的一项子功能或一个功能子集封装为独立组件，并限定它只服务于一个 Stratum 和一个 SCHC Instance。

这种取舍很有吸引力。设备可以只做压缩、某一种分片模式或少量匹配与变换动作；参数可以固定，规则管理可以被删除，或者只保留只读规则。草案预期这会减少代码、内存、处理量和能耗。但这些是设计目标，草案没有提供足以量化所有实现收益的基准结果。

最小压缩示例把交易条件写得很清楚。它假设 IPv6 的 Version、Traffic Class 和 Flow Label 分别固定为 6、0、0。原来的四个字节可以由一个八位 RuleID 代替。示例采用 0x60 和 0xFF 两个标识，并明确承认八位标识在链路上并不节省到极致；这样做是为了让代码简单。也就是说，它愿意多花几个传输位，换取更小、更确定的实现。

问题在于，6、0、0 并没有从现实中消失。它们存放在双方共享的配置中。正在形成的 SCHC 架构草案 用 Stratum、Instance 和 Discriminator 区分处理上下文。单一上下文的 SCHClet 可以把相关头部视为全部省略，因为上下文已由部署预先确定。一旦两端的预先知识发生偏差，短报文本身未必还留下足够的自我描述来定位错误。

因此，SCHClet 草案要求每项规范定义其支持的 SCHClet Configuration。它还规定：完整 SCHC 实现只有在具备“相应配置”时，才必须与该 SCHClet 互操作。这里的限定语比“完整实现”更重要。RuleID 宽度、规则集合、目标值、匹配算子、压缩或分片动作、计时器以及不支持输入的处理方式，共同构成了有限的兼容集合。

示例没有处理一种未来可能出现的全一比特模式，并指出如果输入只可能是 IPv6，这种遗漏或许无关紧要。“输入只可能是 IPv6”不是代码局部就能证明的事实，而是部署环境对输入域的承诺。任何未命中规则的输入，都必须按照配置安全拒绝或原样传递。原样传递也不是天然安全：下一个组件必须能够识别这种路径，且不会把它误当成已压缩报文。

RFC 8724 早已把 SCHC 建立在共享上下文和规则之上；RFC 9011 展示了特定环境如何固定一组选择；RFC 9441 则说明可选功能仍会继续演进。SCHClet 的新意不在于取消上下文，而在于把一个狭窄、可复用的运行单元从完整框架中切出来。运行面越小，赋予它意义的配置身份就越不能含糊。

所以，证据链不能在“RuleID 命中”处结束。它首先标识确切的草案或配置版本与本地构建；随后冻结配置、哈希和责任主体，证明两端如何得到或协商了同一兼容集合；再观察匹配到的规则或未匹配路径、压缩或分片结果、对端解释与重建报文；最后还要核验上层解析、安全校验和应用结果。每一层回答的是不同问题，任何一层都不能代表下一层已经成立。

这并不意味着所有 SCHClet 都要依赖中央控制器或动态协商。对于真正不变的一对设备，出厂配置完全可能是合理答案；边界明确的系统也可以依靠双边运维流程。关键在于：无论选择哪一种方式，它都在事实上承担了协议职责，因为它维持着报文已经不再携带的一致性。

Lu Heng 关于“最小初始规范”的论述指出，共同层只应包含互操作所必需的部分，以保留本地演进空间。SCHClet 把这个原则推向了具体实现。但最小共同层并不等于其余部分不存在；它只是把其余部分本地化。只有当运行代码遇到持有同一配置的对端，并产生了可观察的正确服务结果，互操作主张才真正落地。

来源