Zusammenfassung

  • RFC 9778 stellt IGMP Types, Codes und die Register für Erweiterungsflags unter Standards Action; das verbessert Prüfung und Sichtbarkeit, zertifiziert aber keine laufende Software.
  • Ein älterer Analysator kann den unbekannten Wert ablehnen und Konnektivität verlieren oder ihn ohne wirksame Prüfung weiterleiten und Sicherheit verlieren.
  • Autorität, IANA-Veröffentlichung, Implementierung, Analysatorverhalten, gestufte Interoperabilität, Verkehrswirkung und Rollback benötigen getrennte Belege.

Ein Registereintrag ist eine Aussage über einen gemeinsamen Namensraum. Im Betrieb wird daraus leicht eine Aussage über Geräte: „Der Wert ist standardisiert, also wird er unterstützt.“ Zwischen beiden Sätzen liegt die gesamte Beweisarbeit.

RFC 9778 erschien im März 2025 als BCP 57 und ersetzt RFC 3228. Die Vergabe von IGMP Types erfolgt nun per Standards Action. Für IGMP Code gilt dasselbe; das Dokument eines neuen Type muss zugleich die Vergabepolitik seines Code-Feldes festlegen. Zusätzlich entstehen zwei Register: Query flags weist Bit 0 als E aus und lässt Bit 1 bis 3 frei; Report flags weist Bit 0 als E aus und lässt Bit 1 bis 15 frei. Beide verlangen Standards Action.

MLD Types und Codes bleiben dagegen Teil der ICMPv6 Parameters mit IETF Review. Die Nähe der Protokolle erzeugt keine einheitliche Verwaltungsautorität. Entscheidend ist der genaue Feld- und Registerkontext.

Sichtbarkeit ist kein Laufzeitzeugnis

RFC 8126 bindet Standards Action an einen vom IESG gebilligten Standards-Track-RFC oder BCP. Das sorgt für breite Begutachtung, stabile Semantik und eine belastbare Referenz. Es beweist, dass eine Zuteilung das vorgesehene Verfahren durchlaufen hat.

Es beweist nicht, dass eine bestimmte Firmware den Wert erkennt, ein IDS einen semantischen Befund erzeugt, ein Decoder ihn richtig benennt, eine Policy nicht in den alten Default fällt oder der vorherige Zustand rechtzeitig wiederhergestellt werden kann.

RFC 9778 nennt den Konflikt ausdrücklich. Firewalls und NIDS brauchen eindeutige Felder. Wird ein unbekannter neuer Wert abgelehnt, kann Konnektivität ausfallen. Wird er ohne Verständnis weitergeleitet, kann er Teil eines Angriffs sein. Der erste Fehler ist laut, der zweite kann hinter scheinbar gesundem Verkehr verschwinden.

RFC 6709 beschreibt die bekannten Ursachen: unbekannte Erweiterungen, früher als null erwartete Bits, Teilimplementierungen und stilles Verwerfen. RFC 9279 zeigt eine konkrete Unterscheidung zwischen wohlgeformten, aber nicht unterstützten Extension-TLVs und fehlerhaften Strukturen. Ob ein Produkt diese Grenze bewahrt, lässt sich nur aus beobachtetem Verhalten ableiten.

Belege mit begrenzter Reichweite

Der Autoritätsbeleg nennt Norm und Verfahren. Der Publikationsbeleg friert den IANA-Stand mit Zeitpunkt ein. Der Implementierungsbeleg nennt Software-, Firmware-, Bibliotheks- oder Regelsatzversion. Der Analysebeleg dokumentiert Entscheidungen zu bekannten, unbekannten und fehlerhaften Vektoren. Der Interop-Beleg kombiniert alte und neue Endpunkte und Kontrollen. Der Wirkungsbeleg misst Membership, Verlust, Latenz, Alarme und Ressourcen. Der Rollback-Beleg demonstriert Dauer und Begrenzung der Rücknahme.

Kein Beleg darf den nächsten ersetzen. Eine publizierte Zuteilung kann noch ohne Implementierung sein. Syntaxakzeptanz kann neben einer unklaren Sicherheitsentscheidung bestehen. Ein Paket hinter der Firewall belegt Durchlass, nicht Inspektion. Eine ungemessene Rückfallanweisung belegt keine Wiederanlaufzeit.

Heng Lus Gedanken zu laufendem Code und Realitätsebenen geben dem Register seinen richtigen Platz: Es ist in der Koordination wahr. Der Gerätebefund ist in der Ausführung wahr. Für den Übergang braucht es eine neue Beobachtung.

Gestuft prüfen, begrenzt scheitern

Ein hypothetischer Test inventarisiert Host-Stack, Switch, Router, Firewall, Sensor, Packet Broker, Collector und Diagnosewerkzeug, jeweils mit Version und Konfigurations-Hash. Auf den Altverkehr folgen einzeln der geplante Wert, ein unzugeteilter Wert, eine wohlgeformte unbekannte Erweiterung, ungültige Längen oder Prüfsummen und gemischte Peer-Versionen.

Pro Hop wird zwischen erkannt, ausdrücklich ignoriert, abgelehnt, alarmiert und ohne semantischen Befund weitergeleitet unterschieden. Diese Entscheidung wird mit Membership-Zustand und Datenverkehr verknüpft. Vor einem begrenzten Canary stehen Abbruchwerte fest: mehr Ablehnungen, fehlende Reports, Analyzer-Fallback, Ressourcenlast, Zustandsabweichung oder unerklärter Verlust. Altes Sendeverhalten und alte Policy bleiben unabhängige Rückfallhebel.

Quellen

  1. RFC 9778
  2. RFC 3228
  3. RFC 8126
  4. RFC 6709
  5. RFC 9279
  6. RFC 9776
  7. RFC 9777
  8. RFC 4443
  9. IANA — IGMP Type Numbers
  10. IANA — ICMPv6 Parameters
  11. Heng Lu — Running-code primacy
  12. Heng Lu — Minimum initial specification
  13. Heng Lu — Reality layers