Zusammenfassung

  • ipv6ExtensionHeadersLimit=false steht für eine durch eine Grenze eingeschränkte Beschreibung; true bedeutet, dass die Meldung den vollständig enthaltenen Erweiterungsheadern entspricht. Der Feldname darf diese Lesart nicht umkehren.
  • RFC 9740 trennt Typ, aufeinanderfolgende Wiederholung, Reihenfolge und Kettenlänge. Darstellbarkeit beweist weder die Fähigkeit eines eingesetzten Exporters noch die erfolgreiche Verarbeitung beim Empfänger.
  • Fehlende und begrenzte Beobachtungen gehören nicht zu gültigen Nullwerten. Mehr erfasste Typen nach einem Update können mehr Sichtbarkeit statt mehr Nutzung bedeuten.

Drei Wege zu einem irreführenden Nullwert

Stellen wir uns HIP weit hinten in einer IPv6-Headerkette vor. Ein Exporter untersucht die ganze Kette; ein anderer erreicht zuvor seine Prüfgrenze; ein dritter verwendet ein Feld, das HIP nicht darstellen kann. Werden die letzten beiden als „kein HIP“ ausgewertet, geht der Unterschied zwischen Unwissen und festgestellter Abwesenheit verloren. Das ist ein hypothetischer Vergleich, kein Messresultat zu einem bestimmten Gerät.

RFC 9740, im März 2025 auf dem IETF Standards Track veröffentlicht, ergänzt zwölf IPFIX-Informationselemente und den Datentyp unsigned256. Das alte ipv6ExtensionHeaders (64) hatte eine eingefrorene darstellbare Menge ohne unter anderem HIP, Protokollnummer 139, Shim6, 140, und experimentelle Erweiterungsheader. Es enthielt keine ausdrückliche Beschreibung von Reihenfolge, Wiederholung, Kettenlänge oder vollständiger gegenüber begrenzter Meldung. tcpOptions (209) konnte nur Kinds bis 63 abbilden und keine Experimente unterscheiden, die 253 und 254 teilen. Beide Elemente sind abgekündigt. Ein neuer Spaltenname erweitert nicht rückwirkend die alte Beobachtung.

Vollständig bleibt eine begrenzte Aussage

Die entscheidende Semantik steht in §3.5. Element 517 ist false, wenn nur der bis zu einer meist hardware- oder softwarebedingten Grenze verfügbare Teil beschrieben wird. True bedeutet Übereinstimmung mit den vollständig enthaltenen Erweiterungsheadern. Ein fehlendes 517 ist keine positive Vollständigkeitserklärung.

Auch die Kodierung ist nicht die eines gewöhnlichen Software-Flags. RFC 7011 §6.1.5 kodiert IPFIX-boolean true mit 1 und false mit 2; andere Werte sind undefiniert. Ein roher Nullwert ist deshalb kein standardgemäßes false. Davon getrennt ist ein gültig kodiertes Bitmap mit dem Wert null.

Selbst die vollständige Meldung sagt nicht, dass der gesamte Verkehr erfasst wurde. Ein Flow nach RFC 7011 umfasst Pakete mit gemeinsamen Eigenschaften an einem Beobachtungspunkt in einem Zeitraum. Paketwahl, Messort und Nenner bleiben maßgeblich. Daraus folgen keine Vollständigkeit für andere Pfade, keine weltweite Nichtnutzung und kein Nachweis, dass ein Endgerät die Funktion eines Headers ausführte.

Begrenzte Erfassung beweist ebenfalls keinen Paketverlust. RFC 8883 behandelt Verarbeitungsgrenzen und ICMP-Diagnosen bei übermäßiger Headerlänge, Kettenlänge oder Anzahl. Prüfung, Weiterleitungsentscheidung und Export sind verschiedene Beobachtungen. ICMP kann verloren, gefiltert oder in seiner Rate begrenzt werden. Sein Ausbleiben bestätigt daher keinen Verarbeitungserfolg.

Was die einzelnen Elemente tatsächlich erhalten

RFC 8200 beschreibt IPv6-Erweiterungen als durch Next Header verkettete Header vor der oberen Schicht. ipv6ExtensionHeaderType (513) meldet einen beobachteten Typcode. ipv6ExtensionHeaderCount (514) zählt unmittelbar aufeinanderfolgende Vorkommen desselben Typs, nicht Pakete, Nutzer oder Einführungserfolge.

ipv6ExtensionHeaderTypeCountList (516) erhält die Reihenfolge der Typ-Anzahl-Paare. Bei Hop-by-Hop, Destination Options, Fragment, Destination Options bleiben die beiden Destination-Options-Positionen getrennt. Verschiedene Ketten innerhalb eines Flow müssen getrennt gemeldet werden. Erkennt eine Implementierung einen beobachteten unbekannten Typ als Erweiterungsheader, muss sie dessen exakten Code melden, auch ohne seine Funktion zu unterstützen. Ob ein unbekannter Next Header Erweiterung oder obere Schicht ist, bleibt eine eigene Klassifikationsfrage.

ipv6ExtensionHeadersFull (515) ist ein gröberes Präsenz-Bitmap über beobachtete Pakete des Flow. Die Position stammt aus dem IANA-IPFIX-Register, nicht unmittelbar aus der Protokollnummer: Destination Options, 60, liegt auf Bit 0; Hop-by-Hop, 0, auf Bit 1; HIP, 139, auf Bit 10. No Next Header ist ein bewusst enthaltenes Sondermerkmal, obwohl es kein Erweiterungsheader ist. 515 und 516 dürfen nicht gemeinsam exportiert werden. Aus einem Bitmap lässt sich die Reihenfolge nicht zurückgewinnen.

ipv6ExtensionHeadersChainLength (518) summiert die Länge aller Erweiterungsheader in Oktetten, ohne IPv6-Basisheader oder Header der oberen Schicht. Das ist keine Headeranzahl. ipv6ExtensionHeaderChainLengthList (519) verbindet 515 mit 518 und hält unterschiedliche Ketten auseinander. Mit 519 dürfen deren Bitmaps nicht zusammengefasst werden; ohne diese Liste erlaubt der RFC bestimmte gemeinsame oder getrennte Beschreibungen. Präsenz plus Länge rekonstruiert weder Reihenfolge noch den unerfassten Rest einer begrenzten Meldung.

Ein Formatwechsel kann eine Zeitreihe brechen

Für TCP ordnet tcpOptionsFull (520) den Kind direkt seiner Bitposition von 0 bis 255 zu. So kann eine beobachtete Option ohne Unterstützung ihrer Funktion erfasst werden. IPv6 verwendet dagegen eine Registerzuordnung: Neue Erweiterungsheader erhalten das nächste freie IPFIX-Bit; Ausnahmen mit besonderen Verhaltensbits unterliegen Expert Review. Eine neue Registerzeile aktualisiert nicht alle eingesetzten Programme.

256 logische Bits bedeuten nicht immer 32 übertragene Oktette. Bei zulässiger verkürzter Kodierung werden führende Nullen weggelassen; das Template gibt die tatsächliche Feldlänge an. Ein vorhandener korrekt verkürzter Wert ist kein fehlendes Element. Auch ein großer Integer im Datenspeicher beweist keine tiefe Prüfung am Exporter.

RFC 6994 trennt Experimente mit den gemeinsamen Kinds 253 und 254 durch 16- oder 32-Bit-ExIDs. In RFC 9740 haben ExID-Listen Vorrang: Sind sie für den Flow vorhanden, müssen die generischen gemeinsamen Bits null bleiben. Eine reine Bitmap-Auswertung kann positive Information übersehen. Autonome Erkennung und Breitenbestimmung setzen eine von der Implementierung gepflegte gültige ExID-Liste voraus. Das Datenformat allein stellt sie nicht bereit.

Ein Wechsel von 64 oder 209, ein tieferer Parser oder eine neue Zuordnungstabelle kann im unveränderten Verkehr zusätzliche Typen sichtbar machen. Umgekehrt kann eine stabile erfasste Nutzung einen wachsenden blinden Bereich verbergen. Überlappende Messungen einer vergleichbaren Population helfen, Sichtbarkeits- und Nutzungsänderung auseinanderzuhalten. Fehlt die Überlappung, braucht die Reihe einen erklärten Bruch und eine offene Unsicherheit. Den früher nicht darstellbaren oder nicht untersuchten Bereich mit null zu füllen glättet die Kurve durch erfundene Evidenz.

Die Quellen belegen hier Standardsemantik, keine aktuelle globale Verbreitung oder Endpunkterfolgsrate.

Quellen