Summary

  • The active SCHClet Internet-Draft proposes small, self-contained SCHC functions that may omit rule management and headers when they serve one Stratum and one Instance.
  • The omitted machinery does not vanish. Its meaning moves into the SCHClet Configuration, the provisioning or negotiation process that aligns two peers, and the evidence that reconstructed traffic still produces the intended service outcome.

Four bytes disappear from an IPv6 packet. In their place sits an eight-bit RuleID. The exchange looks economical because the version, traffic class and flow label are already known at both ends: 6, 0 and 0. Those values are not encoded by magic. They live in a configuration that the packet does not carry and an observer cannot recover from the RuleID alone.

That is the most important operational fact in revision 01 of the SCHClet draft. The document, dated 29 September 2026, is an active SCHC Working Group Internet-Draft intended for the Standards Track. It is not yet an RFC, an implementation report or proof of deployment. Its proposal is nevertheless precise: package one SCHC sub-function or subset as a self-contained component, limited to one Stratum and one SCHC Instance. A SCHClet may implement compression, one fragmentation mode, a reduced set of operators or fixed parameters. It may omit rule management, or expose rules as read-only.

This can be an excellent engineering trade. A device need not carry a general framework when it performs one stable task. The draft identifies potential reductions in code, memory, processing and energy, and the deliberately simple compression example spends a full byte on each RuleID to avoid more complicated parsing. The example is intentionally wasteful in bits so that the implementation can be economical in logic. No benchmark in the draft proves the amount saved; the design argument is about the shape of the implementation.

But every removed degree of freedom reappears as a boundary condition. Under the emerging SCHC architecture, a full stack can distinguish Strata, Instances and Discriminators. A SCHClet serving one known context may fully elide that header. The wire becomes smaller because the receiving side already knows which omitted context applies. If that knowledge diverges, there may be no on-wire field left to announce the disagreement.

The draft therefore requires a specification of the supported SCHClet Configuration. It also says that a full SCHC implementation must interoperate when it has the corresponding configuration. “Full” is not a universal compatibility receipt. The qualifying phrase is the control surface. RuleID width, rule set, target values, matching operators, compression actions, fragmentation mode, timers and treatment of unsupported inputs all belong to the compatibility set.

The minimal example makes the point unusually visible. RuleIDs 0x60 and 0xFF select two rules. The example excludes a future all-ones pattern and observes that the omission may be harmless if the function receives only IPv6. That last condition is not a property of the byte sequence; it is a claim about the admissible input domain. An input matching no supported rule must be rejected safely or passed through according to the configuration. “Pass through” is not an automatic safe harbour: the next component must actually expect and distinguish the uncompressed packet.

RFC 8724 already makes SCHC compression a context-based operation. RFC 9011 shows how a profile can freeze choices for a particular environment, while RFC 9441 illustrates that optional functions can continue to evolve. The SCHClet proposal sharpens the governance issue by making a narrow function portable. The smaller the runtime surface, the more consequential the exact configuration that gives it meaning.

The necessary receipt chain is therefore longer than “the RuleID matched.” It begins with the exact draft or profile revision and the local build. It records the frozen configuration and its owner, then proves how both peers received or negotiated the same compatibility set. It observes the selected rule or unmatched-input path, the compressed or fragmented result, the peer’s interpretation, equality of the reconstructed packet within the promised scope, and the higher-layer parse, security check and application outcome. Each step answers a different question.

This is not an argument that every SCHClet needs a central controller or dynamic negotiation. Factory provisioning may be entirely appropriate for a pair of devices whose parameters are deliberately immutable. Bilateral operational procedure may be enough for a bounded deployment. The claim is narrower: whatever method supplies agreement becomes part of the protocol in practice, even when its bytes are absent from the protocol data unit.

As Lu Heng argues about minimum specifications, a common layer should be only as large as interoperability requires. SCHClets take that principle seriously. They also expose its price. A minimal common layer does not abolish the remainder; it localises it. Running code proves the bargain only when another implementation accepts the same configuration and the resulting service behaves as intended.

Sources