Résumé

  • Le projet de norme SCHClet décrit une fonction SCHC autonome, limitée à un Stratum et à une Instance, qui peut se passer de gestion de règles et d’en-têtes devenus implicites.
  • La compatibilité dépend alors de la SCHClet Configuration commune aux deux extrémités, de la manière dont elle est fournie et de la preuve que le paquet reconstruit produit bien le résultat applicatif attendu.

Le code devient plus petit au moment précis où le contrat d’exploitation devient plus important. C’est le paradoxe fécond de la révision 01 du projet SCHClet, datée du 29 septembre 2026. Le texte est un Internet-Draft actif du groupe SCHC, destiné à la voie normative. Ce n’est encore ni un RFC, ni un relevé de déploiement, ni une mesure d’interopérabilité.

Le SCHClet proposé isole une sous-fonction SCHC dans un composant autonome. Une seule strate, une seule instance, éventuellement une fonction de compression ou un mode de fragmentation, quelques opérateurs et paramètres fixes : le dispositif n’embarque que ce dont il a besoin. La gestion des règles peut disparaître ou devenir strictement consultative. Pour un équipement contraint, ce choix peut réduire code, mémoire, calcul et énergie. Le projet avance ces avantages sans prétendre les mesurer dans toutes les implémentations.

L’exemple minimal est éclairant. Les champs Version, Traffic Class et Flow Label d’IPv6 sont présumés valoir 6, 0 et 0 aux deux extrémités. Quatre octets peuvent ainsi être remplacés par un RuleID de huit bits. Le texte assume même une dépense volontaire de bits — deux identifiants 0x60 et 0xFF — afin de simplifier la logique de traitement. L’économie se situe dans le programme, pas nécessairement dans chaque bit transmis.

Or les valeurs supprimées n’ont pas cessé d’exister. Elles résident dans la configuration. Selon l’architecture SCHC en cours de définition, une pile complète peut identifier Stratum, Instance et Discriminator. Un SCHClet limité à un seul contexte peut considérer cet en-tête comme entièrement élidé. Le destinataire sait ce que le réseau n’énonce plus. Si les deux savoirs divergent, aucun champ visible ne vient forcément signaler l’erreur.

Le projet impose donc que toute spécification de SCHClet définisse sa SCHClet Configuration. Il indique aussi qu’une implémentation SCHC complète doit interopérer lorsqu’elle dispose de la configuration correspondante. La restriction est décisive. « Complète » ne signifie pas compatible avec toute variante imaginable. La compatibilité porte sur un ensemble concret : largeur du RuleID, règles, valeurs cibles, opérateurs de correspondance, actions, fragmentation, temporisateurs et traitement des entrées non reconnues.

L’exemple écarte un motif futur composé uniquement de bits à un et précise que cela peut ne pas poser problème si l’entrée est exclusivement IPv6. La sécurité de l’hypothèse dépend donc du domaine d’entrée réel. Lorsqu’aucune règle ne correspond, le SCHClet doit rejeter l’entrée de manière sûre ou la transmettre telle quelle selon sa configuration. Une transmission inchangée n’est sûre que si le composant suivant sait la reconnaître et l’accepter.

Le RFC 8724 fonde déjà SCHC sur un contexte partagé. Le RFC 9011 montre qu’un profil peut figer des choix pour un environnement donné. Le RFC 9441 rappelle que des fonctions optionnelles continuent d’évoluer. Le SCHClet rend cette tension plus visible : plus le composant est spécialisé et portable, plus l’identité exacte de sa configuration compte.

Une preuve d’exploitation doit donc traverser plusieurs couches. Elle identifie la révision du profil et la construction locale, fixe la configuration et son propriétaire, puis montre que les deux pairs ont reçu ou négocié le même ensemble. Elle observe la règle choisie ou le chemin de non-correspondance, le résultat de compression ou de fragmentation, l’interprétation distante, l’égalité du paquet reconstruit dans le périmètre promis, enfin l’analyse de couche supérieure, les contrôles de sécurité et l’effet applicatif.

Rien n’oblige pour autant à installer un contrôleur central ou une négociation dynamique partout. Un provisionnement en usine peut convenir à une paire immuable. Une procédure bilatérale peut suffire à un domaine borné. Mais la méthode choisie devient une partie effective du protocole : elle maintient l’accord que les paquets ne transportent plus.

La doctrine de la couche commune minimale formulée par Lu Heng éclaire ici le bon arbitrage. Ne standardiser que le nécessaire préserve l’innovation locale. Encore faut-il nommer la compatibilité locale et prouver son adoption par du code en fonctionnement, un pair réel et un résultat observé. La petitesse du binaire ne dispense pas de ce reçu ; elle le rend plus précieux.

Sources