



Network Working Group                                           A. Pelov
Internet-Draft                                            IMT Atlantique
Intended status: Standards Track                               Q. Lampin
Expires: 16 July 2026                                           M. Dumay
                                                                  Orange
                                                         12 January 2026


              SCHClet - Modular Use of the SCHC Framework
                  draft-pelov-schclet-architecture-02

Abstract

   This document introduces the concept of a SCHClet: a modular sub-
   function within the SCHC (Static Context Header Compression)
   framework.  Inspired by chiplet architectures in hardware design, a
   SCHClet encapsulates a specific SCHC function—such as compression,
   fragmentation, or acknowledgments—as a self-contained unit.  This
   modularization enables tailored implementations that avoid the
   overhead of deploying a full SCHC stack.

   By decomposing SCHC functionality into SCHClets, the framework
   becomes more adaptable, extensible, and suitable for a wider range of
   network environments—including, but not limited to, constrained
   networks.  A system using SCHClets remains compliant with the SCHC
   framework and can interoperate with a full SCHC implementation,
   provided compatible configuration parameters are used.

   Each SCHClet is defined by the SCHC Profiles and configuration
   parameters necessary for interoperability.  It operates within a
   single Stratum and a single SCHC Instance.  For example, a device may
   implement only the NoAck fragmentation mode as a standalone SCHClet,
   potentially with fixed parameters.  This modular approach simplifies
   development, reduces resource demands, and provides a framework for
   future extensibility of the SCHC architecture.

Status of This Memo

   This Internet-Draft is submitted in full conformance with the
   provisions of BCP 78 and BCP 79.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF).  Note that other groups may also distribute
   working documents as Internet-Drafts.  The list of current Internet-
   Drafts is at https://datatracker.ietf.org/drafts/current/.






Pelov, et al.             Expires 16 July 2026                  [Page 1]

Internet-Draft  SCHClet - Modular Use of the SCHC Framew    January 2026


   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   This Internet-Draft will expire on 16 July 2026.

Copyright Notice

   Copyright (c) 2026 IETF Trust and the persons identified as the
   document authors.  All rights reserved.

   This document is subject to BCP 78 and the IETF Trust's Legal
   Provisions Relating to IETF Documents (https://trustee.ietf.org/
   license-info) in effect on the date of publication of this document.
   Please review these documents carefully, as they describe your rights
   and restrictions with respect to this document.  Code Components
   extracted from this document must include Revised BSD License text as
   described in Section 4.e of the Trust Legal Provisions and are
   provided without warranty as described in the Revised BSD License.

Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   2
   2.  Terminology . . . . . . . . . . . . . . . . . . . . . . . . .   4
   3.  Background and Motivation . . . . . . . . . . . . . . . . . .   4
     3.1.  Simplifications Enabled by SCHClets . . . . . . . . . . .   5
   4.  Formal SCHClet definition and validation  . . . . . . . . . .   5
     4.1.  SCHC Stratum Header, SCHC Instance, Discriminator . . . .   6
   5.  Use Cases and Examples  . . . . . . . . . . . . . . . . . . .   6
     5.1.  IPsec Compression SCHClet . . . . . . . . . . . . . . . .   6
     5.2.  Fragmentation SCHClets  . . . . . . . . . . . . . . . . .   7
     5.3.  Example: Minimal Fixed-Field Compression SCHClet  . . . .   7
       5.3.1.  Functionality . . . . . . . . . . . . . . . . . . . .   7
       5.3.2.  Implementation  . . . . . . . . . . . . . . . . . . .  10
   6.  Security Considerations . . . . . . . . . . . . . . . . . . .  12
   7.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .  12
   8.  Normative References  . . . . . . . . . . . . . . . . . . . .  12
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  12

1.  Introduction

   The SCHC framework, as defined in RFC8724 and related documents, was
   originally designed to address the needs of constrained networks by
   providing efficient header compression and fragmentation.  Over time,
   the addition of new functionalities—such as Compound Acknowledgement
   and various fragmentation modes—has revealed both the strengths and
   limitations of a monolithic SCHC implementation.



Pelov, et al.             Expires 16 July 2026                  [Page 2]

Internet-Draft  SCHClet - Modular Use of the SCHC Framew    January 2026


   A SCHClet is a self-contained function of SCHC, which may or may not
   include all aspects discussed in RFC8724, or other related SCHC RFCs.
   A SCHClet operates on a single Stratum and on a single SCHC Instance.
   Notions such as SCHC Stratum Header, SCHC Instance and Discriminator
   can therefore be omitted in the specification of a SCHClet.

   One of the goals for definition of a SCHClet is the fact that parts
   of SCHC may be applicable to many use-cases, without the need to
   include the entire SCHC apparatus.  This is done to some extent in
   some of the SCHC RFC technology profiles (e.g.  RFC9011), where there
   is no rule management for example.  There is no rule discovery, etc.
   In that sense, these RFCs use SCHC, built on a specific set of
   SCHClets.

   A full SCHC implementation is supposed to implement all features of
   RFC8724, and possibly all related RFCs.  However, there are more and
   more RFCs that add supplementary functionalities, such as
   CompoundAck.  In this sense, what is considered a full SCHC
   implementation today, may not be exhaustive tomorrow.  In addition,
   the SCHC Architecture introduces the notions of SCHC Stratum Header,
   SCHC Instance and Discriminator, which while useful for a Full SCHC
   Implementation, could be seen as unnecessary for many of the
   applications of SCHClets.

   A generic SCHC Framework implementation which has all SCHClets
   implemented MUST be able to interoperate with any SCHClet, provided
   it has the corresponding configuration.  For example, if one IPsec
   end-point uses a minimal SCHClet implementation, the other end-point
   may use a full SCHC implementation with the corresponding
   configuration.

   A SCHClet is defined by the SCHC Profiles or configuration parameters
   that enable interoperability with a Full SCHC Implementation.  A
   SCHClet operates on a single Stratum, within a single SCHC Instance.

   For example, the IPsec draft, includes only compression, and with
   specific compression rules.  It may be seen as a SCHClet, using only
   SCHC Compression from RFC8724, with only a subset of the MOs/CDAs.

   This document describes the SCHClet architecture.  Each SCHClet
   represents an atomic sub- function of the overall SCHC process.  This
   design enables developers to incorporate only the relevant SCHC
   functionality for a given application, thereby reducing complexity
   and resource requirements while retaining the benefits of the SCHC
   approach.  The SCHClet concept provides a way to describe future
   additions to the SCHC Framework, such as new SCHC Fragmentations,
   aggregation functions, FEC rule formats.




Pelov, et al.             Expires 16 July 2026                  [Page 3]

Internet-Draft  SCHClet - Modular Use of the SCHC Framew    January 2026


2.  Terminology

   *  SCHClet: A self-contained unit within the SCHC framework that
      implements a specific SCHC function or a subset of SCHC
      operations.  A SCHClet may implement aspects defined in RFC8724 or
      other related SCHC RFCs, and MAY be combined with other SCHClets
      or integrated into a full SCHC implementation.

   *  Full SCHC Implementation: An implementation that covers all
      mandatory aspects of SCHC as defined in RFC8724, potentially
      extended by additional functionalities introduced in subsequent/
      related RFCs.

   *  Full SCHC Implementation Configuration (Full Configuration): The
      set of SCHC Profiles/configurations/parameters supported by a Full
      SCHC Implementation.

   *  SCHClet Configuration: A subset of a Full Configuration, which are
      implemented and supported by a given SCHClet.  This may be a
      single SCHC Profile, or a set of such.

3.  Background and Motivation

   SCHC was developed to provide a robust mechanism for header
   compression and fragmentation in networks with strict resource
   constraints.  The original design focused on a comprehensive
   implementation that would cover all aspects of SCHC functionality.
   However, several trends have emerged:

   *  Diverse Use Cases: Different applications may require only a
      subset of SCHC functionalities.  For example, some may only need
      compression while others might focus solely on fragmentation.

   *  Evolving Standards: As new RFCs extend SCHC functionality (e.g.,
      Compound Acknowledgement, advanced fragmentation techniques), a
      monolithic implementation risks becoming overly complex.

   *  Resource Optimization: In constrained environments, it is
      beneficial to deploy only the necessary SCHC functions to optimize
      memory, processing power, and energy usage.

   The SCHClet concept addresses these challenges by providing a modular
   approach that decouples individual SCHC functions from a monolithic
   architecture.







Pelov, et al.             Expires 16 July 2026                  [Page 4]

Internet-Draft  SCHClet - Modular Use of the SCHC Framew    January 2026


3.1.  Simplifications Enabled by SCHClets

   By breaking down a SCHC implementation into SCHClets, several
   simplifications can be realized:

   *  Exclusion of Rule Management:
      SCHClets can omit complex rule discovery, installation, and update
      mechanisms.  This results in a leaner protocol that focuses on the
      core function (e.g., compression) without the overhead of managing
      multiple rule sets.

   *  Simplification of Rule Management:
      SCHClets can support only a subset of the Rule Management, e.g.
      read-only access to existing rules.

   *  Simplification of the use of SCHC Framework: The notions of SCHC
      Stratum Header, SCHC Instance, and Discriminator MAY be omitted.

   *  Targeted Functionality: Specific optional functions (such as
      compound acknowledgments or advanced fragmentation modes) can be
      encapsulated in separate SCHClets.  This approach allows
      developers to include only the necessary functions for a given use
      case, simplifying the overall design.

   A full SCHC implementation with the right configuration MUST
   interoperate with a specific SCHClet.  The SCHClet in question may
   not necessarily handle these configurations itself (e.g. it may be a
   fixed implementation with no parametrization possible on its side),
   they can be reinterpreted as a full SCHC implementation would.  For
   example, an implementer of a compression SCHClet may never formally
   use Rule Management, Discriminators, SCHC Header or other notions
   defined in the SCHC Architecture, these can be inferred by the
   knowledgeable SCHC practitioner.  It is of course RECOMMENDED that a
   SCHClet provides a complete picture of its use in the context of a
   full SCHC implementation.

4.  Formal SCHClet definition and validation

   Formally, a SCHClet is a set of SCHC functions, which when
   implemented interoperate with a Full SCHC implementation, within a
   predefined SCHClet Configuration.  A SCHClet is therefore fully
   defined by its corresponding SCHClet Configuration.

   Any document specifying a SCHClet MUST include the definition of the
   supported SCHClet Configuration.






Pelov, et al.             Expires 16 July 2026                  [Page 5]

Internet-Draft  SCHClet - Modular Use of the SCHC Framew    January 2026


   A SCHClet is designed to be interoperable with both minimal and full
   SCHC implementations.  For instance, an endpoint may implement a
   single SCHClet for a specific function (e.g., IPsec compression)
   while the corresponding peer uses a comprehensive SCHC implementation
   that supports multiple SCHClets.  Proper configuration and
   negotiation mechanisms are essential to ensure that both ends
   correctly interpret the SCHC context.

   If a SCHClet is used in a document/specification/implementation, it
   MAY be cited as: "Using a SCHClet of the SCHC Framework, with the
   following supported configuration/parameters/profiles: ...".

4.1.  SCHC Stratum Header, SCHC Instance, Discriminator

   A SCHClet operates on a single Stratum and on a single SCHC Instance.
   As such, there is no need to specify SCHC Stratum Header, which is
   always fully elided.  In addition, there is no need for a
   Discriminator.  Documents specifying the use of a SCHClet MAY omit
   the specification of SCHC Stratum Header, SCHC Instance and/or
   Discriminator considerations.

   It is RECOMMENDED if there are more than one SCHC Instances to use a
   Full SCHC Implementation within the Full SCHC Architecture.  While
   not recommended, a SCHC Stratum Instance MAY be defined as a SCHClet,
   and combined with other SCHClets to achieve the functionality of a
   complete SCHC Stratum implementation.

5.  Use Cases and Examples

5.1.  IPsec Compression SCHClet

   An illustrative example is an IPsec draft that leverages SCHC
   compression:

   *  Functionality: This SCHClet implements only the compression rules
      defined in RFC8724 and a limited set of Context-Dependent
      Attributes (CoDAs).

   *  Deployment: The implementation is tailored for IPsec environments,
      focusing solely on compression without engaging in rule management
      or SCHC Stratum functions.

   *  Interoperability: Although minimal, this SCHClet must be
      configured to operate alongside endpoints that might use full SCHC
      implementations.






Pelov, et al.             Expires 16 July 2026                  [Page 6]

Internet-Draft  SCHClet - Modular Use of the SCHC Framew    January 2026


   As an example, Diet-ESP, as defined in draft-ietf-IPsecme-diet-esp-05
   (https://datatracker.ietf.org/doc/html/draft-ietf-IPsecme-diet-esp-
   05), represents a minimal, streamlined version of the ESP protocol
   designed for constrained environments.  By integrating SCHClets,
   Diet-ESP can leverage SCHC’s compression or fragmentation
   capabilities in a modular manner, without needing to implement a full
   SCHC implementation.

5.2.  Fragmentation SCHClets

   Fragmentation is a core aspect of SCHC, with multiple modes
   available:

   *  NoAck Fragmentation SCHClet: Implements a fragmentation scheme
      without acknowledgement, suitable for low-overhead scenarios.

   *  Ack-On-Err Fragmentation SCHClet: Incorporates error recovery
      mechanisms by acknowledging only when errors occur.

   *  Ack-Always Fragmentation SCHClet: Provides continuous
      acknowledgement for reliable communication, albeit with increased
      overhead.

   Developers may choose to implement one or more of these SCHClets
   based on application requirements and network conditions.

5.3.  Example: Minimal Fixed-Field Compression SCHClet

   The goal of this example is to show how a SCHClet may be a single,
   constant-time function, of extreme simplicity - but still
   interoperable with a Full SCHC Implementation.

   The example is one that compresses only constant fields in an IPv6
   header, under the assumption that specific values are fixed and known
   a priori at both endpoints.  This SCHClet is fully stateless, does
   not require (nor support) rule management, and can be applied
   directly at the byte level.

   This example is deliberately minimal, to demonstrate how a fully
   standards-compliant SCHClet can be implemented with only a few lines
   of code when the deployment assumptions are strongly constrained.

5.3.1.  Functionality

   This SCHClet targets the first four bytes of the IPv6 header, which
   correspond to:

   *  Version (4 bits): 6



Pelov, et al.             Expires 16 July 2026                  [Page 7]

Internet-Draft  SCHClet - Modular Use of the SCHC Framew    January 2026


   *  Traffic Class (8 bits): 0

   *  Flow Label (20 bits): 0

   When these fields are known to be constant, they may be fully elided.
   The SCHClet performs a prefix match against the fixed 4-byte sequence
   0x60 00 00 00, and if matched, removes it during compression and
   restores it during decompression.

   This fixed-function approach is applicable in many constrained
   deployments, particularly when all traffic is known to conform to a
   common baseline IPv6 configuration.

   To simplify the example, we use a RuleID of length 8 bits, with two
   rules:

   *  RuleID 01100000 (0x60) - "pass-through", which elides the first
      byte (which is 0x60), but then adds the ruleID (which is 0x60),
      effectively making the compression operation a no-operation.

   *  RuleID 11111111 (0xFF) - "compression", which elides the first 4
      bytes

   Note that the choice of RuleIDs is wasteful, in the sense that only
   one bit would be sufficient.  This is done to illustrate the
   simplicity of the implementation, e.g. the code below doesn't require
   bit-shifting operations.  Also note, that in the code we "change" the
   buffer with the packet to be compressed, which is done also for the
   sake of simplicity, but is not a recommended design pattern.

   Also note, that this artificial example doesn't handle the case where
   a protocol version 1111 with following bits as 1111 is provided to
   the compressor/decompressor.  That may, or may not be a problem, e.g.
   if it is known that there is only IPv6 traffic processed through this
   SCHClet, this is not an issue.

   Here is the SCHC Context, which enables interoperability between this
   SCHClet and a Full SCHC Implementation:

   {
     "schc": {
       "rule": [
         {
           "rule-id-value": 0x60,
           "rule-id-length": 8,
           "nature-compression": {
             "field": [
               {



Pelov, et al.             Expires 16 July 2026                  [Page 8]

Internet-Draft  SCHClet - Modular Use of the SCHC Framew    January 2026


                 "field-id": "fid-ipv6-version",
                 "field-position": 1,
                 "direction": "bi",
                 "target-value": {
                     "index": 0,
                     "value": 6
                 },
                 "matching-operator": "mo-equal",
                 "comp-decomp-action": "cda-not-sent"
               },
               {
                 "field-id": "fid-ipv6-trafficclass",
                 "field-position": 1,
                 "direction": "bi",
                 "target-value": {
                     "index": 0,
                     "value": 0
                 },
                 "matching-operator": "mo-msb",
                 "matching-operator-value":
                 {
                     "index": 0,
                     "value": 4
                 },
                 "comp-decomp-action": "cda-lsb",
                 "comp-decomp-action-value":
                 {
                     "index": 0,
                     "value": 4
                 }
               },
               {
                 "field-id": "fid-ipv6-flowlabel",
                 "field-position": 1,
                 "direction": "bi",
                 "target-value": {
                     "index": 0,
                     "value": 0
                 },
                 "matching-operator": "mo-equal",
                 "comp-decomp-action": "cda-value-sent"
               }
             ]
           }
         },
         {
           "rule-id-value": 0xFF,
           "rule-id-length": 8,



Pelov, et al.             Expires 16 July 2026                  [Page 9]

Internet-Draft  SCHClet - Modular Use of the SCHC Framew    January 2026


           "nature-compression": {
             "field": [
               {
                 "field-id": "fid-ipv6-version",
                 "field-position": 1,
                 "direction": "bi",
                 "target-value": {
                     "index": 0,
                     "value": 6
                 },
                 "matching-operator": "mo-equal",
                 "comp-decomp-action": "cda-not-sent"
               },
               {
                 "field-id": "fid-ipv6-trafficclass",
                 "field-position": 1,
                 "direction": "bi",
                 "target-value": {
                     "index": 0,
                     "value": 0
                 },
                 "matching-operator": "mo-equal",
                 "comp-decomp-action": "cda-not-sent"
               },
               {
                 "field-id": "fid-ipv6-flowlabel",
                 "field-position": 1,
                 "direction": "bi",
                 "target-value": {
                     "index": 0,
                     "value": 0
                 },
                 "matching-operator": "mo-equal",
                 "comp-decomp-action": "cda-not-sent"
               }
             ]
           }
         }
       ]
     }
   }

5.3.2.  Implementation

   The following C implementation demonstrates this SCHClet in practice:






Pelov, et al.             Expires 16 July 2026                 [Page 10]

Internet-Draft  SCHClet - Modular Use of the SCHC Framew    January 2026


   #include <stdint.h>
   #include <stdio.h>
   #include <string.h>

   #define RULE_ID_PASSTHROUGH 0x60  // 01100000
   #define RULE_ID_COMPRESSED  0xFF  // 11111111

   // Compress packet in-place or pass through, based on content.
   // Returns pointer to compressed packet and sets output length.
   const uint8_t* compress_ipv6(uint8_t *packet, size_t in_len, size_t *out_len) {
       // Match compressible pattern (Version, TC, FL = 0)
       if (in_len >= 4 && packet[0] == 0x60 && packet[1] == 0x00 &&
           packet[2] == 0x00 && packet[3] == 0x00) {

           // We "compress" by replacing the 4th byte with RuleID
           packet[3] = RULE_ID_COMPRESSED;
           *out_len = in_len - 3;
           return &packet[3];
       }

       // Pass-through: return original packet, unchanged
       *out_len = in_len;
       return packet;
   }

   size_t decompress_ipv6(const uint8_t *compressed, size_t comp_len, uint8_t *out_buf, size_t out_max) {
       if (comp_len == 0 || out_max < comp_len + 3) return 0;

       if (compressed[0] == RULE_ID_COMPRESSED) {
           // Insert fixed prefix before compressed payload
           out_buf[0] = 0x60;
           out_buf[1] = 0x00;
           out_buf[2] = 0x00;
           out_buf[3] = 0x00;
           memcpy(out_buf + 4, compressed + 1, comp_len - 1);
           return comp_len - 1 + 4;
       }

       // Rule ID is not compressed — assume passthrough
       memcpy(out_buf, compressed, comp_len);
       return comp_len;
   }

   int main() {
       uint8_t packet[40] = {
           0x60, 0x00, 0x00, 0x00,  // Compressible prefix
           0x3A, 0x40               // Next header, hop limit...
       };



Pelov, et al.             Expires 16 July 2026                 [Page 11]

Internet-Draft  SCHClet - Modular Use of the SCHC Framew    January 2026


       size_t in_len = 40;
       size_t comp_len;

       const uint8_t *compressed = compress_ipv6(packet, in_len, &comp_len);
       if (!compressed) {
           printf("Compression failed.\n");
           return 1;
       }

       printf("Compressed length: %zu\n", comp_len);
       printf("Compressed first byte: 0x%02X\n", compressed[0]);

       uint8_t restored[64];
       size_t restored_len = decompress_ipv6(compressed, comp_len, restored, sizeof(restored));

       printf("Decompressed first 4 bytes: %02X %02X %02X %02X\n",
              restored[0], restored[1], restored[2], restored[3]);

       return 0;
   }

6.  Security Considerations

   TBD.

7.  IANA Considerations

   This document does not require any immediate IANA actions.

8.  Normative References

   [RFC8724]  Minaburo, A., Toutain, L., Gomez, C., Barthel, D., and JC.
              Zuniga, "SCHC: Generic Framework for Static Context Header
              Compression and Fragmentation", RFC 8724,
              DOI 10.17487/RFC8724, April 2020,
              <https://www.rfc-editor.org/info/rfc8724>.

Authors' Addresses

   Alexander Pelov
   IMT Atlantique
   2bis rue de la Chataigneraie
   35536 Cesson-Sévigné
   France
   Email: alexander.pelov@imt-atlantique.fr






Pelov, et al.             Expires 16 July 2026                 [Page 12]

Internet-Draft  SCHClet - Modular Use of the SCHC Framew    January 2026


   Quentin Lampin
   Orange
   France
   Email: quentin.lampin@orange.com


   Marion Dumay
   Orange
   France
   Email: marion.dumay@orange.com









































Pelov, et al.             Expires 16 July 2026                 [Page 13]
