Zusammenfassung

  • udpSafeOptions und udpUnsafeOptions bilden die Optionstypen ab, die in den zu einem Flow gehörenden Paketen mindestens einmal beobachtet wurden.
  • ExID-Listen erhalten die Identität beobachteter Experimente und haben Vorrang vor dem allgemeinen EXP- oder UEXP-Bit. Eine Ereignisfolge entsteht daraus nicht.
  • Aussagekräftig ist der Wert nur zusammen mit Beobachtungspunkt, Flow-Grenzen, Auswahlverfahren, Template, Exporter-Zustand und Collector-Eingang. Beobachtung ist keine Verarbeitung.

Von einzelnen Paketen zur Menge

UDP-Optionen treten pro Paket auf und können während eines Flows jederzeit hinzukommen. RFC 9870 projiziert diese Vorgänge in zwei Mengenfelder. ElementID 525 ordnet den SAFE Kinds 0 bis 191 Bits zu. ElementID 526 deckt die UNSAFE Kinds 192 bis 255 ab.

Schon die erste Beobachtung setzt das Bit. Ob danach keine oder zehntausend weitere folgen, ist im Wert nicht erkennbar. Ebenso verschwinden Anfang und Ende, regelmäßiges und vereinzeltes Auftreten sowie die Frage, ob mehrere Optionen im selben Datagramm lagen.

Für skalierbare Bestandsaufnahme ist das sinnvoll. Der Datensatz beantwortet eine kleine Frage mit wenig Raum. Er wird erst irreführend, wenn eine Automatisierung daraus Häufigkeit, Dauer oder Kausalität ableitet. Die formale Genauigkeit des Bitfelds erweitert seine Semantik nicht.

Spezifische Listen verdrängen allgemeine Bits

RFC 9868 reserviert EXP im SAFE- und UEXP im UNSAFE-Bereich. RFC 9870 ergänzt das 16-Bit-Element udpExID sowie je eine Liste für beobachtete SAFE- und UNSAFE-Experimente. Damit bleiben verschiedene Versuche unterscheidbar.

Bei vorhandener SAFE-Liste gilt EXP als beobachtet; der Exporter darf das allgemeine EXP-Bit für denselben Flow nicht zusätzlich setzen. Für UEXP gilt dasselbe. Diese Vorrangregel spart redundante Darstellung, verlangt vom Auswerter aber, beide Formen zu verstehen. Wer nur das Bitfeld prüft, kann einen positiven Listeneintrag übersehen.

Die Liste wahrt Identitäten, nicht deren Verlauf. Sie zählt keine Vorkommen, ordnet sie keinen Paketen zu und erklärt nicht, ob Experimente gleichzeitig oder nacheinander liefen. Auch eine Antwort oder Akzeptanz der Gegenstelle folgt daraus nicht.

Ein Nullwert braucht seinen Beobachtungsraum

Nach RFC 7011 umfasst ein Flow Pakete, die an einem Observation Point innerhalb eines Zeitraums beobachtet werden und festgelegte Eigenschaften teilen. Null bedeutet deshalb: In diesem repräsentierten Flow wurde der Kind nicht gesehen. Dafür müssen Messprozess, Auswahl und Datensatz vollständig genug sein.

Ohne Observation Point, Schlüssel, aktive und inaktive Timeouts, Sampling und Exporter-Fähigkeit wird aus Null keine netzweite Abwesenheit. Die Option kann an anderer Stelle, außerhalb des Intervalls oder in nicht ausgewählten Paketen vorkommen.

Eins bleibt ebenfalls lokal. Es ist ein positiver Beleg des Messpfads, aber keine Empfangsbestätigung. SAFE oder UNSAFE beschreibt die Folgen des Ignorierens durch Altgeräte. Ob ein konkreter Endpunkt die Option erkannte, prüfte, annahm und ausführte, braucht eigene Belege.

Ohne Template verliert der Wert seine Sprache

Das SAFE-Feld nutzt unsigned256 aus RFC 9740, darf aber führende Nullbytes durch Reduced-Size Encoding weglassen. Die ExID-Listen verwenden basicList aus RFC 6313. Rohbytes ohne Template, Feldlänge, ElementID und Registry-Revision sind daher kein dauerhaft selbsterklärender Beleg.

IANA führt die Elemente 525 bis 529 sowie UDP Kinds und ExIDs. Diese Register sichern gemeinsame Bezeichner. Sie bescheinigen weder Implementierungsunterstützung noch Einsatz, Beobachtung oder Betriebsergebnis.

Quellen