Zusammenfassung

  • Der aktive SCHClet-Entwurf beschreibt eigenständige SCHC-Funktionen für genau ein Stratum und eine Instance, die Regelverwaltung und implizit gewordene Header weglassen können.
  • Die Zusage einer vollständigen SCHC-Implementierung bleibt an die korrespondierende SCHClet Configuration gebunden. Ein belastbarer Nachweis umfasst beide Peers, den Pfad für nicht passende Eingaben, die Rekonstruktion und das Ergebnis der höheren Schicht.

„Vollständig“ klingt nach universeller Empfangsfähigkeit. Im SCHClet-Entwurf, Revision 01, steht daneben jedoch die entscheidende Bedingung: Eine vollständige SCHC-Implementierung muss mit einem SCHClet interoperieren, wenn sie die korrespondierende Konfiguration besitzt. Nicht das Etikett schließt den Vertrag, sondern die konkrete gemeinsame Konfiguration.

Der Text vom 29. September 2026 ist ein aktiver Internet-Draft der SCHC-Arbeitsgruppe mit angestrebtem Standards Track. Er ist weder RFC noch Implementierungsbericht, Interoperabilitätstest oder Einsatznachweis. Vorgeschlagen wird eine in sich geschlossene SCHC-Teilfunktion für genau ein Stratum und eine SCHC Instance.

Ein SCHClet kann ausschließlich komprimieren, einen Fragmentierungsmodus anbieten oder nur ausgewählte Operatoren und Aktionen beherrschen. Parameter dürfen fest sein; die Regelverwaltung kann entfallen oder Regeln lediglich lesbar machen. Der Entwurf verbindet damit mögliche Einsparungen bei Code, Speicher, Rechenaufwand und Energie. Er liefert aber keine Messung, aus der sich ein garantierter Gewinn für jedes Gerät ableiten ließe.

Das Minimalbeispiel nimmt für IPv6 Version, Traffic Class und Flow Label die Werte 6, 0 und 0 an. Vier Byte werden durch eine acht Bit breite RuleID ersetzt. Die Kennungen 0x60 und 0xFF sind absichtlich großzügig, um die Verarbeitung einfach zu halten. Der Entwurf optimiert hier nicht jedes Übertragungsbit, sondern die Komplexität des Programms.

Die entfernten Werte werden weiterhin für die Rekonstruktion gebraucht. Sie befinden sich in der geteilten Konfiguration. Der entstehende SCHC-Architekturentwurf unterscheidet Stratum, Instance und Discriminator. Weil ein SCHClet nur einen bekannten Kontext bedient, kann der entsprechende Header vollständig entfallen. Der Empfänger ergänzt seine Bedeutung aus Vorwissen. Weicht dieses Wissen ab, muss das kurze Paket keinen sichtbaren Hinweis auf die Ursache enthalten.

Darum verlangt der Entwurf, dass jede SCHClet-Spezifikation ihre unterstützte SCHClet Configuration definiert. Zu ihrem Kompatibilitätssatz gehören RuleID-Breite, Regeln, Zielwerte, Vergleichsoperatoren, Kompressionsaktionen, Fragmentierungsmodus, Timer und die Behandlung nicht unterstützter Eingaben. Eine vollständige Implementierung, der eine dieser Festlegungen fehlt, ist für diesen konkreten Austausch nicht vollständig informiert.

Das Beispiel behandelt ein mögliches künftiges Bitmuster aus lauter Einsen nicht. Laut Entwurf kann das belanglos sein, wenn nur IPv6 in die Funktion gelangt. Diese Eingangsbedingung ist jedoch eine Eigenschaft des Betriebs, nicht der isolierten Funktion. Passt keine Regel, muss der SCHClet die Eingabe sicher verwerfen oder entsprechend der Konfiguration unverändert weiterreichen. Auch die Weiterleitung ist nur dann sicher, wenn der nächste Baustein diesen Pfad erkennt und akzeptiert.

RFC 8724 gründet SCHC bereits auf gemeinsamem Kontext und Regeln. RFC 9011 zeigt, wie ein Profil Entscheidungen für LoRaWAN festlegt. RFC 9441 belegt, dass optionale Funktionen weiterentwickelt werden. SCHClets beseitigen die Kontextabhängigkeit nicht; sie verpacken sie in einer schmalen, wiederverwendbaren Funktion. Je kleiner deren Laufzeitoberfläche, desto wichtiger ist die genaue Identität der Konfiguration.

Die Beweiskette beginnt deshalb mit der exakten Entwurfs- oder Profilrevision und dem lokalen Build. Danach werden Konfiguration, Hash und Eigentümer festgehalten. Es folgt der Nachweis, wie beide Peers denselben Satz erhielten oder aushandelten, welche Regel oder welcher Nichttrefferpfad gewählt wurde und wie die Gegenseite Kompression oder Fragmentierung deutete. Erst der Vergleich des rekonstruierten Pakets sowie Parsing, Sicherheitsprüfung und Anwendungsergebnis der höheren Schicht schließen die Kette.

Daraus folgt keine Pflicht zu zentraler Steuerung oder dynamischer Aushandlung. Eine Fabrikkonfiguration kann für zwei tatsächlich unveränderliche Endpunkte richtig sein. In einem begrenzten Bereich genügt vielleicht ein bilaterales Verfahren. Aber die gewählte Methode übernimmt faktisch eine Protokollfunktion, weil sie jene Übereinstimmung erhält, die nicht mehr in jedem Paket steht.

Lu Hengs Prinzip einer minimalen gemeinsamen Spezifikation schützt lokale Entscheidungsfreiheit, indem nur das für Interoperabilität Notwendige gemeinsam wird. SCHClets folgen diesem Gedanken. Der lokale Rest braucht dennoch Namen, Verantwortlichkeit und Nachweis. Laufender Code belegt den Anspruch erst mit einem Gegenüber, das dieselbe Konfiguration annimmt und das beabsichtigte Dienstergebnis liefert.

Quellen