Zusammenfassung

  • RFC 8928 zeigte das EARO-C-Flag an Bit 3, ohne die Position bei der IANA zu registrieren; RFC 9685 registrierte später das zweibittige P-Feld an den Positionen 2 und 3.
  • RFC 9927 verschiebt C auf Bit 1 und bezeichnet die Änderung ausdrücklich als nicht rückwärtskompatibel. Ein Übergangsplan entfällt, weil keine Implementierung oder Bereitstellung von RFC 8928 bekannt war.
  • Der korrigierte RFC und das aktuelle Register legen die gemeinsame Zuordnung fest. Sie aktualisieren keine Firmware und beweisen weder Parserstand noch Paketdeutung oder Dienstergebnis.

Zwei korrekte Arbeitsweisen konnten zu zwei Parsern führen

RFC 8928 definierte Address-Protected Neighbor Discovery. Im Extended Address Registration Option zeigt C an, dass der Registration Ownership Verifier eine Crypto-ID enthält und der registrierende 6LoWPAN Node zu einem Eigentumsnachweis für die Adresse aufgefordert werden kann. Die Abbildung setzte C auf Bit 3.

Damit konnte ein Entwickler arbeiten. Doch im IANA-Register für Address Registration Option Flags fehlte der Eintrag. Ein kompaktes Protokollfeld ist ein gemeinsam genutzter Namensraum. Wer die Abbildung implementiert, hält die Position für belegt. Wer eine spätere Erweiterung plant, schaut in das Register, um eine freie Position zu finden. Ohne Verbindung zwischen beiden Quellen können beide sorgfältig vorgehen und dennoch unterschiedliche Grammatiken für dasselbe Oktett bauen.

RFC 9685 führte danach den Registered Address Type Indicator ein. Sein zweibittiges P-Feld belegt die Bits 2 und 3 und wurde ordnungsgemäß registriert. Bit 3 hatte damit zwei mögliche Bedeutungen. Es ging nicht um eine doppelte Bezeichnung, sondern um die Auslegung desselben Drahtwerts.

Die Quellen belegen keinen Vorfall, der daraus entstanden wäre. Belegt ist die engere Aussage: Die veröffentlichten Spezifikationen ließen zwei Parserlogiken zu.

Die Verschiebung stellt eine eindeutige Karte her

RFC 9927 ersetzt die betroffenen EARO-Abbildungen für Neighbor Solicitation und Neighbor Advertisement. C wandert auf Bit 1, P bleibt an den registrierten Bits 2 und 3. Außerdem wird „Enhanced Address Registration Option“ in „Extended Address Registration Option“ berichtigt.

Das aktuelle IANA-Register enthält nun eine überschneidungsfreie Karte: Bit 0 ist nicht zugewiesen, Bit 1 ist C, Bits 2–3 sind P, Bits 4–5 sind I, Bit 6 ist R und Bit 7 ist T. Das Register ist damit die gemeinsame Koordinationsfläche, nicht bloß eine Liste im Nachgang.

RFC 8126 erklärt den Verfahrenszweck. Die Vergabe knapper Protokollwerte ist Governance. Die Aussagekraft bleibt trotzdem begrenzt: IANA kann die im Standardisierungsprozess gültige Zuordnung belegen, aber nicht den Softwarestand eines Geräts oder die tatsächliche Deutung eines empfangenen Pakets.

„Keine bekannte Implementierung“ bleibt eine Wissensgrenze

RFC 9927 nennt die Änderung nicht rückwärtskompatibel. Ein Sender nach der alten Abbildung und ein Empfänger nach der neuen Karte können Bit 3 verschieden lesen. Dennoch wird kein Übergang vorgeschrieben, weil keine Implementierungen oder Bereitstellungen von RFC 8928 bekannt waren.

Das Wort „bekannt“ trägt die Unsicherheit. Es beschreibt den Informationsstand der Autoren, nicht das Ergebnis einer weltweiten Inventur. Die Quellen schließen privaten Versuchscode nicht aus. Aus „nichts bekannt“ darf deshalb nicht „nichts vorhanden“ werden.

Für eine Organisation ohne RFC-8928-Spuren kann RFC 9927 die Ausgangsgrammatik sein. Findet sie alten Code, braucht sie ein Inventar von Quellen, Binärdateien und Builds, kontrollierte Encoder- und Decoder-Tests, Kenntnis der Gegenstellen, gestufte Einführung und Rückfallmöglichkeit. Ein fehlender globaler Übergangsplan hebt eine lokal nachgewiesene Übergangsaufgabe nicht auf.

Registerwahrheit ist keine Laufzeitmessung

Heng Lus Minimum Initial Specification ist hier eine analytische Perspektive, keine IETF-Regel: Eine schmale gemeinsame Festlegung koordiniert den Berührungspunkt, während die Annahme lokal bleibt. Running-Code Primacy setzt die Gegenbegrenzung, wonach ein bereinigtes Dokument Betriebsnachweise nicht ersetzt. Reality Layers warnt davor, normative Autorität als operative Tatsache auszugeben.

RFC 8928 beweist, was die alte Abbildung zeigte. RFC 9685 und die IANA-Aktion beweisen die koordinierte P-Zuteilung. RFC 9927 beweist die normative Korrektur und die genannte Übergangsentscheidung. Das aktive Register beweist die heutige Zuordnung. Keine dieser Ebenen beweist allein, wie ein unbenannter Binärcode heute parst.

Eine Laufzeitaussage benötigt eine identifizierte Quell- oder Binärversion, Encoder- und Decoderverhalten, Konfiguration, kontrollierte Testpakete oder Mitschnitte, die Version der Gegenstelle und das beobachtete Ergebnis. Für eine Dienstaussage kommt die Dienstmessung hinzu. Ein repariertes Register ist nicht automatisch ein repariertes Netz.

Grenzen des Befunds

Es gibt keinen belegten Produkttyp, Knoten, Paketmitschnitt, Exploit, Ausfall, Einführungsgrad oder Geschäftseffekt. C beweist auch kein öffentliches Eigentum an einer Adresse, keine globale Routenberechtigung und keine Dienstannahme. Seine Rolle bleibt auf die Eigentumsprüfung im EARO beschränkt.

Der Fall hat deshalb zwei Lehren: Eine Abbildung, die Code prägen kann, muss mit dem gemeinsamen Zuteilungsregister verbunden sein. Ein korrigiertes Register muss von den Nachweisen über laufenden Code getrennt bleiben. RFC 9927 schließt die erste Lücke; Betreiber müssen die zweite mit eigenen Befunden schließen.

Quellen