Zusammenfassung

  • pcapng vergibt Interface-IDs ab null innerhalb jeder Section. Die ID ist dort eindeutig, nicht im gesamten Dateiverbund. Dieselbe Zahl in zwei Sections darf nicht als dieselbe Schnittstelle korreliert werden.
  • LinkType und Interface Description Block ermöglichen präzisere Speicherung. Namen, Beschreibungen und Richtung bleiben Aussagen des Schreibers; sie ersetzen weder Herkunftsbeleg noch Authentizität.

Die Auswertung zeigte einen überzeugenden Bewegungsablauf. Ein Paket erschien auf Interface 0, wurde wenige Mikrosekunden später verändert und tauchte wieder auf Interface 0 auf. Das System interpretierte dies als Hin- und Rückweg durch denselben Sensor.

Die erste Beobachtung lag in Section A, die zweite in Section B. Beide Sections begannen ihre Interface-Nummerierung bei null. Section A beschrieb einen Außenport in Frankfurt, Section B einen virtuellen Adapter in einem Labor. Beim Import hatte die Plattform den Schlüssel {Section, Interface ID} auf Interface ID verkürzt.

Zwei lokal korrekte Identitäten wurden zu einer global falschen Identität.

Diese Art Fehler zeigt, warum Link-Layer Types for PCAP-related Capture File Formats nicht als Herkunftsstandard gelesen werden darf. Revision 18 ist vom 6. April 2026 und läuft am 8. Oktober 2026 aus. Am Stichtag 3. Oktober war sie ein aktiver OPSAWG-Internet-Draft mit vorgesehenem Status Informational, in der RFC-Editor-Queue vor Zuweisung des ersten Editors und ohne RFC-Nummer. Der Prozessstand belegt weder Implementierungsqualität noch Dateiauthentizität.

Der Entwurf schlägt ein IANA-Register für LinkType-Werte vor. Ein 16-Bit-Wert wählt das Format der Metadaten und Layer-2-Kapselung vor den gespeicherten Paketdaten. LinkType legt also eine Grammatik fest. pcapng setzt diese Grammatik pro Interface Description Block ein und kann dadurch mehrere Schnittstellen in einer Datei beschreiben.

Das ist mehr Struktur als im klassischen PCAP. Mehr Struktur ist jedoch nur dann mehr Evidenz, wenn ihre Geltungsbereiche erhalten bleiben.

Eine Identität besteht aus Zahl und Reichweite

In pcapng erhält jeder Interface Description Block innerhalb einer Section eine fortlaufende 32-Bit-Interface-ID ab null. Enhanced Packet Blocks und Interface Statistics Blocks verweisen auf diese ID. Für jede referenzierte Schnittstelle muss in derselben Section ein passender Beschreibungsblock existieren.

Die Spezifikation sagt zugleich: Die ID ist nur in der aktuellen Section eindeutig. Eine spätere Section kann dieselben Werte für andere Schnittstellen verwenden. Sections können durch Verkettung entstehen und sogar unterschiedliche Versions- oder Byte-Order-Kontexte haben.

Ein Datenmodell, das lediglich interface_id = 0 speichert, hat deshalb keine Identität gespeichert. Es hat eine lokale Position aus ihrem Namespace gerissen. Der minimale Schlüssel ist mindestens Dateiversion oder Dateiidentität, Section-Identität und Interface-ID. Bei Transformationen braucht es zusätzlich einen Mapping-Beleg.

Simple Packet Blocks erhöhen die Sorgfaltspflicht: Sie enthalten keine Interface-ID und beziehen sich implizit auf die erste Interface Description der Section. Wer sie in eine globale Tabelle exportiert, muss diese implizite Bindung ausdrücklich materialisieren, ohne daraus mehr Herkunft abzuleiten als die Datei behauptet.

Optionen sind Daten, keine Zeugen

Ein Interface Description Block kann if_name, if_description, Betriebssystem, Filter und weitere Optionen tragen. Ein Enhanced Packet Block kann die Schnittstelle benennen, auf der ein Paket empfangen oder gesendet wurde; Flags können Richtungshinweise liefern.

Diese Felder sind operational nützlich. Sie ermöglichen eine sauberere Rekonstruktion als ein Dateiname wie tap-final-2.pcap. Dennoch stammen sie vom Schreiber. Eine manipulierte oder konvertierte Datei kann einen glaubwürdigen Namen und konsistente Zeitstempel enthalten.

Das richtige Evidenzmodell unterscheidet daher mindestens drei Zustände: vom Format strukturell gebunden, vom Produzenten behauptet und unabhängig bestätigt. Die Interface-ID kann die strukturelle Bindung liefern. if_name ist eine Behauptung. Sensoridentität, Signatur, Erwerbshash, Konfigurationsnachweis und Verwahrung können Bestätigung liefern.

Ein LinkType fügt eine weitere strukturelle Aussage hinzu: So sind die Bytes vor dem Paket zu lesen. Er beweist nicht den physischen Medientyp, den Sensorstandort oder die Ehrlichkeit des Schreibers.

Das alte PCAP zeigt die andere Fehlerseite

PCAP v2 erlaubt nur ein LinkType-Format pro Datei. PCAP-09 erklärt, dies bedeute häufig Pakete von einer Schnittstelle, weil nicht alle LinkTypes eine Interface-Zuordnung enthalten. Häufigkeit ist keine Invariante. Mehrere Quellen können vor dem Schreiben auf eine gemeinsame Darstellung normalisiert werden.

Das alte Format verleitet dazu, fehlende Identität zu erfinden; pcapng verleitet dazu, vorhandene lokale Identität zu globalisieren. Beide Fehler entstehen, wenn ein Feld mehr Autorität bekommt als sein Scope.

Auch DLT und LinkType müssen getrennt bleiben. Laut Entwurf sind ihre Zahlen oft gleich, aber nicht universell. Manche DLT-Werte sind betriebssystemspezifisch. Wer eine Zahl ohne Namespace übernimmt, kann eine syntaktisch gültige, semantisch falsche Zuordnung erzeugen.

Vollständigkeit bleibt pro Paket offen

Die Interface Description enthält SnapLen. Enhanced Packet Blocks unterscheiden Captured Packet Length und Original Packet Length. Ein gespeichertes Paket kann nur ein Präfix des ursprünglichen Pakets enthalten. Der LinkType kann das Präfix korrekt deuten, nicht den ausgelassenen Rest.

Der LinkType-Entwurf warnt, dass interne Längen ein größeres Paket beanspruchen können als im Capture vorhanden ist. Unbegrenzte Leseversuche führen zu einfachen Buffer-Overreads. Da Dateien absichtlich fehlerhaft sein können, muss der Parser jede Grenze prüfen.

Für die Analyse bedeutet dies: Eine Interface-Zuordnung plus ein erfolgreicher Decode ergibt noch keinen vollständigen Beobachtungsbeleg. Aussageumfang, Section-Scope, SnapLen, Filter, Richtung und Verwahrung gehören zusammen.

Registry-Scope ist ebenfalls begrenzt

Werte von 0 bis 65000 werden nach Expert Review vergeben, 65001 bis 65535 dienen Experimental Use. Historische private Werte 147 bis 162 bleiben unterstützt. Experimentelle Werte sollen im Allgemeinen nicht aus der verwendenden Entität entweichen, weil verschiedene Entitäten dieselbe Zahl anders definieren können.

Die Experten ermutigen zu einer stabilen Spezifikation und können Duplikate erkennen. Eine öffentliche Spezifikation ist aber nicht vorgeschrieben; ein Kontakt ist die Mindestanforderung. Das Register koordiniert Nummern und Beschreibungen. Es beglaubigt keine einzelne Datei und keine darin behauptete Schnittstelle.

Heng Lus Minimum Initial Specification liefert die richtige Architektur: Der gemeinsame Layer enthält nur, was für interoperables Lesen notwendig ist—Format, Namespace, LinkType, Section und lokale Interface-ID, Längen und Versionsbezug. Lokale Systeme dürfen reichere Herkunft, Sensorattestierung und Aktionspolitik ergänzen. Sie dürfen diese Entscheidungen nur nicht als Eigenschaft des gemeinsamen Integers ausgeben.

Running-Code-Tests müssen die Scope-Fehler absichtlich erzeugen: zwei Sections mit Interface 0, Verkettung, Reordering, falscher Name, Simple Packet Block, abweichende Byte Order, gekürztes Paket, kollidierender Experimentalwert und fehlerhafte DLT-Abbildung. Ein korrektes System behält zusammengesetzte Schlüssel und kennzeichnet Behauptungen, statt eine elegante globale Topologie zu erfinden.

Interface 0 war zweimal vorhanden. Das Problem war nicht die Wiederholung, sondern ein Datenmodell, das Lokalität als Duplikat behandelte und Kontext löschte.

Quellen