Summary

  • A PCAP LinkType selects the metadata and Layer 2 encapsulation grammar that precedes captured packet bytes. It does not identify the physical wire, sensor, capture interface, traffic direction or chain of custody.
  • Safe evidence systems retain the capture and transformation record beside the decoder selector. A clean parse is syntactic success, not proof that the resulting story is true.

The file arrived during an intrusion investigation with a familiar value in its header: LINKTYPE_ETHERNET. The analysis platform decoded destination and source MAC addresses, VLAN tags, IPv4 headers and a transport flow without error. Its report then stated that the traffic had been observed on the data-centre Ethernet tap.

That last sentence was invented.

The file had been assembled by a replay service. Some packets came from a virtual switch, some from an agent export, and some from a laboratory reproduction. Each record had been normalized into an Ethernet-shaped representation so that ordinary tools could read it. The LinkType accurately described the stored bytes. It said nothing about the wire on which those bytes had once travelled—or whether they had travelled on a wire at all.

This is the authority boundary inside Link-Layer Types for PCAP-related Capture File Formats. Revision 18 is dated 6 April 2026 and expires on 8 October 2026. At the 3 October research cut-off, it was an active OPSAWG Internet-Draft intended as Informational, in the RFC Editor queue awaiting its first editor, without an assigned RFC number. That process state matters, but it does not turn the draft into a published RFC or certify any capture tool.

The document creates a proposed IANA registry for LinkType values used by legacy PCAP and pcapng. A LinkType is a 16-bit unsigned selector. Its job is narrow: choose one among hundreds of formats for metadata and Layer 2 encapsulation before the packet. That is indispensable interoperability. Without it, a reader would not know whether the first octets were an Ethernet header, a cooked Linux header, radio metadata, a loopback prefix or some other structure.

A grammar selector is not a witness.

One value, five different propositions

Evidence platforms routinely compress five propositions into one label.

The first proposition is about storage: these octets are arranged according to a named format. The second is about observation: a particular mechanism saw a packet or some representation of it. The third is about provenance: a named sensor, interface and vantage produced the record. The fourth is about custody: the record remained bound to its acquisition history. The fifth is about judgment: the decoded traffic supports an incident conclusion or automated action.

LinkType can support the first proposition. It cannot, by itself, establish the other four.

Even “Ethernet” is ambiguous at the evidentiary layer. A virtual switch can emit Ethernet frames. A tunnel decapsulator can reconstruct them. A packet broker can transform and aggregate them. A replay tool can generate them. A monitor can prepend metadata and select a different LinkType even though the underlying traffic used 802.11. A file converter can remove one pseudo-header and write another. The decoder needs to know the final representation; an investigator needs to know the entire transformation chain.

Legacy PCAP makes the temptation stronger because one file carries a single LinkType. The current PCAP draft says this often means the packets are from one network interface because not every LinkType can identify an interface. “Often” describes a common production pattern. It is not a format guarantee. One selector per file means one stored grammar, not one sensor, one direction, one owner or one continuous acquisition.

If a platform changes “single LinkType” into “single source”, it creates provenance from absence. The format omitted a general interface identity; the inference engine silently filled the gap.

Richer metadata is still an assertion

pcapng offers a better structure. Its Interface Description Blocks can carry a LinkType, snapshot length and optional interface name, description, operating-system information and capture filter. Enhanced Packet Blocks refer to a 32-bit Interface ID. This allows one file to represent several interfaces and lets a packet name the interface description to which it belongs.

But the Interface ID is unique only within its section. Interface ID 0 in a later section can denote a different interface. A Simple Packet Block has no Interface ID at all and implicitly points to the first Interface Description Block. A merge or conversion that forgets section scope can create a confident but false evidence graph.

More importantly, if_name is supplied by the writer. So is a description. So are direction flags and timestamps. Those fields can be accurate and useful, but they are not self-authenticating. A structurally valid file can say that a packet came from uplink-1 when it did not. The correct model is “the writer asserted this interface”, followed by whatever independent evidence makes that assertion trustworthy.

This is where a Minimum Initial Specification helps. The common format should carry the narrow fields needed for interoperable reading. Custody, organizational identity, sensor attestation and incident authority should be bound through explicit profiles rather than smuggled into a LinkType. A thin common layer is not a weakness. It prevents every parser from becoming an unaccountable evidence court.

The missing tail changes the claim

The LinkType draft gives a second warning that is easy to treat as mere implementation hygiene. Many capture formats use a snapshot length smaller than the actual packet. Trailing bytes can be omitted even while length fields inside the packet describe a larger object. A careless reader can overrun the stored buffer.

The evidentiary consequence is just as important as the memory-safety consequence.

Legacy PCAP records Captured Packet Length and Original Packet Length. The former is the bytes retained; the latter is the length that would have been presented absent snapshot or capture-mechanism truncation. pcapng preserves the same distinction. If the captured value is smaller, a payload signature not found in the file may have been absent from the packet—or may simply have lived in bytes the file never stored.

The parser can correctly decode every available byte and still leave the decisive question unknown. “Not present in the capture” is not automatically “not present on the network.” A report that drops the two lengths turns an explicit uncertainty into false exoneration.

Registration coordinates numbers, not truth

The proposed registry assigns values 0–65000 under Expert Review and reserves 65001–65535 for Experimental Use. Historical private values 147–162 remain supported, but new private uses should move to the experimental range. The draft says experimental values generally should not leak outside the entity that uses them.

That boundary is practical. Two organizations can assign the same experimental integer to incompatible layouts. Once the file crosses between them, the number alone cannot decide which grammar is correct. A parser may be perfectly faithful to the receiver's local definition and completely wrong about the sender's bytes.

Expert Review narrows this collision risk for official allocations. Review can identify duplicates and require a clear account of the octets before an IPv4 or IPv6 header. Yet a public specification is encouraged, not mandatory; a non-public specification is acceptable, and the minimum requirement is a contact. The registry coordinates an allocation. It does not authenticate each future file, approve a parser, disclose every private grammar or certify a claimant's story.

The same restraint applies to Data Link Type values. The draft notes that DLT values are often numerically identical to LinkTypes, but not universally. Some are operating-system-specific and not standardized. A bare integer extracted from an API and written into a portable file can preserve all its bits while losing its namespace. The transformation needs a receipt: original namespace, operating system or library, mapping rule, tool version and resulting LinkType.

Running code must test the negative claims

The useful test is not whether a parser can open a normal file. It is whether the system refuses to claim what the file cannot prove.

Feed it identical Ethernet-shaped bytes from a physical tap, a virtual switch, a replay engine and a synthetic generator. Reuse Interface ID 0 in two pcapng sections. Write a truthful interface name and then a forged one. Truncate a packet immediately before the payload evidence an analyst expects. Map an operating-system-specific DLT correctly and incorrectly. Give two partners the same experimental value with different grammars. Put malicious internal lengths behind a valid LinkType.

A mature platform will preserve the narrow successful fact—“these bytes were parsed under this definition”—while marking source, direction, completeness and custody as separately supported, declared, ambiguous or unknown. It will isolate untrusted parsers and attach their implementation versions to the result. It will not quarantine a host merely because a decoder produced a persuasive flow.

Heng Lu's reality-layer discipline offers the constitutional test: a symbol in a record must not acquire powers belonging to the event, observer, custodian or decision-maker. The LinkType registry is legitimate because it solves a small coordination problem. It becomes dangerous only when an institution uses its portability to manufacture authority.

The decoder knew how to read the frame. It never knew the wire. That knowledge must come from evidence with an owner.

Sources