Zusammenfassung

  • RFC 9899 definiert einen begrenzten Vergleich: Ursprung wählen, length Bytes überspringen, Operator anwenden und binäres Muster vergleichen. Eine schemagültige Konfiguration sagt nicht, welche Bytes das Gerät inspizierte.
  • Ein Zählerdelta belegt lokale Zuordnung zu einer ACE innerhalb eines bekannten Umfangs und epoch. Paketidentität, Aktionsausführung und Dienstergebnis beweist es allein nicht.

Vier Anzeigen können grün sein: Die Feature-Angabe steht in der YANG Library, der Commit gelingt, die ACE ist lesbar und ihr Zähler wächst im Test. Alle vier Beobachtungen können stimmen, ohne den Satz „die Payload-Regel funktioniert“ zu tragen.

RFC 9899 erschien im Dezember 2025 als Proposed Standard und erweitert das ACL-Modell aus RFC 8519. Der Datatracker weist draft-ietf-netmod-acl-extensions als Vorläufer aus. Ein späteres Aktualisierungsdatum der Datatracker-Seite ist Metadatenpflege, keine neue Spezifikation. Für den Dokumentstatus gehören die RFC-Informationsseite, der Datatracker-Eintrag und die damalige Errata-Suche zusammen.

Vier Angaben bestimmen das Fenster

match-on-payload meldet eine Schemafähigkeit im Sinne von YANG 1.1, keinen Zustand der Weiterleitung. In payload-match wählt offset den semantischen Ursprung, length die Zahl der von dort zu ignorierenden Bytes, operator standardmäßig match und pattern den Binärwert. Der Vergleich beginnt bei offset + length.

length ist nicht die Musterlänge, sondern die Sprungweite. Wer nur zwei Zahlen, aber nicht Offset-Identity, Operator und vollständiges Pattern speichert, kann die Regel nicht reproduzieren.

layer2 beginnt am Link-Layer-Header, layer3 am IP-Header, layer4 nach dem IP-Header einschließlich Optionen und IP-Erweiterungsheadern wie AH. payload beginnt nach dem Transport-Header und damit gegebenenfalls nach TCP-Optionen. IANA YANG Parameters belegt Modul und Revision, nicht das Verhalten eines Forwarding-Chips.

Ein fester Wert, ein beweglicher Ursprung

Zwei TCP-Segmente können dieselben Anwendungsdaten mit unterschiedlich langen Headern tragen. Der Data Offset aus RFC 9293 markiert den Datenbeginn. Ein Test mit starrem absolutem Versatz kann beim Minimal-Header zufällig treffen und bei Optionen vorbeizielen.

RFC 8200 platziert IPv6-Erweiterungsheader vor der oberen Schicht und behandelt Fragmente vor der Wiederzusammensetzung am Ziel als einzelne Pakete. RFC 9899 beschreibt layer4, legt aber nicht für jedes Produkt fest, ob vor oder nach Reassembly, Decapsulation oder Normalisierung geprüft wird. Das sind lokale Implementierungsfakten.

RFC 9000 schützt den QUIC-Payload und Header-Felder wie die Paketnummer. Sichtbares Header-Material ist kein Anwendungs-Klartext. RFC 9899 sagt begrenzt, dass unverschlüsselte Daten deterministisch verglichen werden und die Wirksamkeit bei verschlüsselten Paketen von einem unveränderlichen Muster abhängt. Es entschlüsselt nichts. RFC 8329 liefert Kontext für Packet-Content-Matching, aber keinen Implementierungsnachweis.

Neun getrennte Aussagen

Eine vollständige Kette trennt: Schemafähigkeit; authentifizierte Identität, Autorisierung und Transaktion; intended und operational state nach RFC 8342; kompilierte und am richtigen Hook befestigte ACE; exakte Bytes in einer unabhängigen Aufzeichnung; Sichtbarkeit nach Verschlüsselung, Kapselung, Fragmentierung, Reassembly und Normalisierung; ACE-Hit im bekannten epoch; Ausführung der Aktion; Ergebnis des Dienstes.

RFC 8341 trennt Schemakonformität und Zugriffskontrolle. Die Read-only-Zähler matched-packets und matched-octets aus RFC 8519 können pro Interface oder aggregiert sein. Ein Anstieg sagt daher nur, dass der Zähler in einem Zeitraum Traffic zugeordnet hat. Ohne Umfang, Reset, kontrollierten Stimulus und Beobachtung identifiziert er nicht einmal das verursachende Paket. Auch eine konfigurierte ergänzende Log- oder Zähleraktion aus RFC 9899 ist noch keine Ausführung.

Der Paketfenster-Beleg

Ein reproduzierbarer Beleg bindet Modul, Revision, Features und Deviations; System- und Forwarding-Build; Principal, Autorisierung, Transaktions-ID und Datastore; ACE, Reihenfolge, Attachment, Interface, Richtung und Hook; Lage zu Decapsulation, Normalisierung und Reassembly; Offset-Identity, Sprung, Operator, Pattern und berechneten Bytebereich; Hashes von Fixture und unabhängiger Aufzeichnung; dekodierte Headerlängen; Verschlüsselungsgrenze; Name, Breite, Umfang, Aggregation, Reset und Werte des Zählers; getrennte Aktions- und Dienstnachweise.

Negative Tests markieren die Geltungsgrenze: TCP-Optionen bei gleichen Nutzdaten variieren, IPv6-Erweiterungsheader einfügen, dokumentierte Fragmentfälle testen, ein Pattern-Byte ändern, verschlüsselt und unverschlüsselt sowie ingress und egress vergleichen. Ein Treffer nur beim einfachsten Paket ist ein Fixture-Erfolg, keine umfassende Policy-Garantie.

Dokumentautorität und Ausführungsmacht

Daniel Kade wendet hier ausdrücklich eine externe Analyse an. Lu Hengs reality layers unterscheiden dokumentarische von ausführbarer Macht: YANG liegt auf der Spezifikationsebene; programmierter Dataplane, beobachtetes Paket, Aktion und Dienstresultat liegen auf zunehmend ausführbaren Ebenen. Das ist keine Aussage des RFC und keine unterstellte Absicht seiner Autoren.

Minimum Initial Specification und Localized Future Decision legen einen kleinen, deterministischen Kern nahe: Schemaidentität, exaktes Fenster, Stimulus, epoch und unabhängige Beobachtung. Hook, Normalisierung und Reassembly bleiben sichtbare lokale Entscheidungen. Der Text über Autorität und Glauben schärft die Grenze: Ein Dokument koordiniert; Implementierung und Betreiber des aktiven Pfades besitzen Ausführungsmacht. Diese Übertragung stammt vom Autor dieses Artikels, nicht von der IETF.

Die belastbare Aussage bleibt eng: Unter diesem Schema und dieser Autorisierung wurden an diesem programmierten Hook diese sichtbaren Bytes mit Ursprung, Sprung, Operator und Pattern verglichen; der Zähler änderte sich in diesem epoch; separate Nachweise zeigen Aktion und Ergebnis. Jede weitere Behauptung braucht einen weiteren Beleg.

Quellen