| Internet-Draft | pcaplinktype | December 2025 |
| Harris & Richardson | Expires 12 June 2026 | [Page] |
This document describes a set of Packet CAPture (PCAP)-related LinkType values and creates an IANA registry for those values. These values are used by the PCAP and PCAP-Now-Generic specifications.¶
This note is to be removed before publishing as an RFC.¶
Status information for this document may be found at https://datatracker.ietf.org/doc/draft-ietf-opsawg-pcaplinktype/.¶
Discussion of this document takes place on the opsawg Working Group mailing list (mailto:opsawg@ietf.org), which is archived at https://mailarchive.ietf.org/arch/browse/opsawg/. Subscribe at https://www.ietf.org/mailman/listinfo/opsawg/.¶
Source for this draft and an issue tracker can be found at https://github.com/IETF-OPSAWG-WG/pcapng.¶
This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79.¶
Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet-Drafts is at https://datatracker.ietf.org/drafts/current/.¶
Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress."¶
This Internet-Draft will expire on 12 June 2026.¶
Copyright (c) 2025 IETF Trust and the persons identified as the document authors. All rights reserved.¶
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Revised BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Revised BSD License.¶
In the late 1980s, Van Jacobson, Steve McCanne, and others at the Network Research Group at Lawrence Berkeley National Laboratory developed the tcpdump program to capture and dissect network traces. The code to capture traffic, using low-level mechanisms in various operating systems, and to read and write network traces to a file was later put into a library named libpcap [LIBPCAP].¶
Other documents describe the original (legacy) file format used by tcpdump (PCAP, [I-D.ietf-opsawg-pcap]), as well as a revised file format [I-D.ietf-opsawg-pcapng], both of which are used by tcpdump and Wireshark [Wireshark].¶
Within those file formats each packet that is captured is indicated by a LinkType value. The LinkType value selects one of many hundred formats for metadata and Layer 2 encapsulation of the packet.¶
This document creates an IANA registry for LinkType values, establishing the IANA Considerations by which other uses of the PCAP-related formats may register new LinkType values.¶
IANA is requested to create a new registry group entitled "The PCAP Registry".¶
IANA is also requested to create a registry entitled "PCAP-related LinkType List" under The PCAP registry group (Section 2.1).¶
The registry has the following structure:¶
LinkType Value: Indicates the 16-bit unsigned integer assigned for this LinkType.¶
LinkType Name: Indicates the symbolic name for this LinkType. The name is prefixed with "LINKTYPE_" (i.e., LINKTYPE_something).¶
Change Controller: as per [RFC8126], Section 2.3¶
Description: Provides a very short description.¶
Reference: Indicates an authoritative document reference for the LinkType or a requester reference.¶
The policy allocation for the LinkType values is as follows:¶
Values from 0 to 65000 are allocated following an Expert Review policy (Section 4.5 of [RFC8126]). Values in the ranges 0-10, 50-51, and 98-301 are already assigned; values in the ranges 11-49 and 52-97 are reserved and must not be assigned.¶
Values from 65001 to 65535 are reserved for Experimental Use (Section 4.2 of [RFC8126]).¶
The initial version of the registry is provided in Section 2.2.1. In each case here, the reference should be set to [TCPDUMP] and the RFC number to be assigned to this document, which is not repeated each time.¶
The initial contents of the table are based upon the link-layer header type list maintained by libpcap, and published on [TCPDUMP]. The change controller for all initial entries that have no other reference is linktype@tcpdump.org.¶
LinkType values 147 to 162 named LINKTYPE_RESERVED_xx were originally reserved for Experimental/Private Use, and that use continues to be supported. However, new private use cases should use the values in the 65001-65535 range.¶
In general, Experimental Use values should never leak out of the entity that uses it. As the FCFS range is large and easily obtained, official values are recommended.¶
There is often an associated Data Link Type (DLT) value which is often identical in value, but not universally so. DLT values are associated with specific operating systems, and the numerical values for some of them are operating system specific, and are thus not subject to standardization.¶
This is the initial table for the registry:¶
LINKTYPE_EXP_ETHERNET¶
2¶
Xerox experimental 3Mb Ethernet¶
LINKTYPE_ARCNET_BSD¶
7¶
ARCNET Data Packets with BSD encapsulation¶
Not available for assignment¶
11-49¶
Do not use these values¶
Not available for assignment¶
52-98¶
Used historically by NetBSD¶
LINKTYPE_SYMANTEC_FIREWALL¶
99¶
Symantec Enterprise Firewall¶
LINKTYPE_ATM_RFC1483¶
100¶
LLC/SNAP-encapsulated ATM¶
LINKTYPE_RAW¶
101¶
IP without link-layer headers¶
[LINKTYPE_RAW] [RFC791] [RFC8200]¶
LINKTYPE_C_HDLC¶
104¶
Cisco PPP with HDLC framing¶
LINKTYPE_ATM_CLIP¶
106¶
ATM Classical IP, with no header preceding IP¶
LINKTYPE_LOOP¶
108¶
OpenBSD loopback encapsulation¶
LINKTYPE_LINUX_SLL¶
113¶
Linux "cooked" capture encapsulation¶
LINKTYPE_IEEE802_11_PRISM¶
119¶
IEEE 802.11 wireless LAN, preceded by a Prism monitor mode header¶
LINKTYPE_IEEE802_11_AIRONET¶
120¶
802.11 + FreeBSD Aironet radio metadata¶
LINKTYPE_IP_OVER_FC¶
122¶
IP and ATM over Fibre Channel¶
LINKTYPE_SUNATM¶
123¶
ATM traffic captured from a SunATM device¶
LINKTYPE_IEEE802_11_RADIOTAP¶
127¶
IEEE 802.11 wireless LAN, preceded by a Radiotap header¶
LINKTYPE_ARCNET_LINUX¶
129¶
ARCNET Data Packets with Linux encapsulation¶
LINKTYPE_APPLE_IP_OVER_IEEE1394¶
138¶
Apple IP-over-IEEE 1394 cooked header¶
LINKTYPE_MTP2_WITH_PHDR¶
139¶
SS7 MTP2 frames, with a pseudo-header¶
LINKTYPE_IEEE802_11_AVS¶
163¶
IEEE 802.11 wireless LAN, preceded by an AVS header¶
LINKTYPE_PPP_PPPD¶
166¶
PPP preceded by a direction octet and an HDLC-like control field¶
LINKTYPE_GPRS_LLC¶
169¶
General Packet Radio Service Logical Link Control, as per 3GPP TS 04.64¶
LINKTYPE_GPF_T¶
170¶
Transparent-mapped generic framing procedure¶
LINKTYPE_GPF_F¶
171¶
Frame-mapped generic framing procedure¶
LINKTYPE_GCOM_T1E1¶
172¶
Gcom T1/E1 line monitoring equipment¶
LINKTYPE_GCOM_SERIAL¶
173¶
Gcom T1/E1 line monitoring equipment¶
LINKTYPE_ERF_ETH¶
175¶
Endace TYPE_ETH ERF records¶
LINKTYPE_ERF_POS¶
176¶
Endace TYPE_POS_HDLC ERF records¶
LINKTYPE_LINUX_LAPD¶
177¶
Linux vISDN LAPD frames¶
LINKTYPE_MFR¶
182¶
FRF.16.1 Multi-Link Frame Relay frames¶
LINKTYPE_A653_ICM¶
185¶
Arinc 653 Interpartition Communication messages¶
LINKTYPE_USB_FREEBSD¶
186¶
USB traffic captured on FreeBSD¶
LINKTYPE_BLUETOOTH_HCI_H4¶
187¶
Bluetooth HCI UART Transport Layer packets¶
LINKTYPE_IEEE802_16_MAC_CPS¶
188¶
IEEE 802.16 MAC Common Part Sublayer¶
LINKTYPE_USB_LINUX¶
189¶
USB packets, beginning with a Linux USB header¶
LINKTYPE_CAN20B¶
190¶
Controller Area Network (CAN) v. 2.0B packets¶
LINKTYPE_IEEE802_15_4_LINUX¶
191¶
IEEE 802.15.4 with address fields padded by Linux¶
LINKTYPE_PPI¶
192¶
Per-Packet Information header preceding packet data¶
LINKTYPE_IEEE802_16_MAC_CPS_RADIO¶
193¶
802.16 MAC Common Part Sublayer plus radio header¶
LINKTYPE_IEEE802_15_4_WITHFCS¶
195¶
IEEE 802.15.4 with FCS¶
LINKTYPE_SITA¶
196¶
Various link-layer types, with a pseudo-header¶
LINKTYPE_RAIF1¶
198¶
Ethernet packets captured from a u10 Networks board¶
LINKTYPE_IPMB_KONTRON¶
199¶
IPMB packet for IPMI, with a 2-octet header¶
LINKTYPE_BLUETOOTH_HCI_H4_WITH_PHDR¶
201¶
Bluetooth HCI UART Transport Layer packets with a direction pseudo-header¶
LINKTYPE_AX25_KISS¶
202¶
KISS frames between a host and an AX.25 TNC¶
LINKTYPE_PPP_WITH_DIR¶
204¶
PPP, with a direction header¶
LINKTYPE_C_HDLC_WITH_DIR¶
205¶
Cisco PPP with HDLC framing, with a direction header¶
LINKTYPE_FRELAY_WITH_DIR¶
206¶
Frame Relay LAPF, with a direction header¶
LINKTYPE_LAPB_WITH_DIR¶
207¶
X.25 LAPB, with a direction header¶
LINKTYPE_FLEXRAY¶
210¶
FlexRay frames or symbols, with a pseudo-header¶
LINKTYPE_MOST¶
211¶
Media Oriented Systems Transport (MOST) bus¶
LINKTYPE_LIN¶
212¶
Local Interconnect Network (LIN) automotive bus, with a metadata header¶
LINKTYPE_IEEE802_15_4_NONASK_PHY¶
215¶
IEEE 802.15.4 with PHY header¶
LINKTYPE_GSMTAP_UM¶
217¶
GSM Um interface, with gsmtap header¶
LINKTYPE_GSMTAP_ABIS¶
218¶
GSM Abis interface, with gsmtap header¶
LINKTYPE_MPLS¶
219¶
MPLS packets with MPLS label as the header¶
LINKTYPE_USB_LINUX_MMAPPED¶
220¶
USB packets, beginning with an extended Linux USB header¶
LINKTYPE_WIHART¶
223¶
Wireless HART (Highway Addressable Remote Transducer)¶
LINKTYPE_FC_2_WITH_FRAME_DELIMS¶
225¶
Fibre Channel FC-2 frames with SOF and EOF¶
LINKTYPE_CAN_SOCKETCAN¶
227¶
Controller Area Network (CAN) frames, with a metadata header¶
LINKTYPE_IPV4¶
228¶
IPv4 without link-layer headers¶
[LINKTYPE_IPV4] [RFC791]¶
LINKTYPE_IPV6¶
229¶
IPv6 without link-layer headers¶
LINKTYPE_IEEE802_15_4_NOFCS¶
230¶
IEEE 802.15.4 without FCS¶
LINKTYPE_DVB_CI¶
235¶
DVB-CI messages, with a pseudo-header¶
LINKTYPE_MUX27010¶
236¶
Variant of 3GPP TS 27.010 multiplexing protocol¶
LINKTYPE_STANAG_5066_D_PDU¶
237¶
STANAG 5066 D_PDUs¶
LINKTYPE_NFLOG¶
239¶
Linux netlink NETLINK NFLOG socket log messages¶
LINKTYPE_NETANALYZER¶
240¶
Ethernet frames with netANALYZER pseudo-header¶
LINKTYPE_NETANALYZER_TRANSPARENT¶
241¶
Ethernet frames with netANALYZER pseudo-header, preamble, and SFD¶
LINKTYPE_MPEG_2_TS¶
243¶
MPEG-2 Transport Stream transport packets¶
LINKTYPE_NG40¶
244¶
Frames from ng4T GmbH's ng40 protocol tester¶
LINKTYPE_NFC_LLCP¶
245¶
NFC Logical Link Control Protocol frames, with a pseudo-header¶
LINKTYPE_INFINIBAND¶
247¶
InfiniBand data packets¶
LINKTYPE_SCTP¶
248¶
SCTP packets, with no lower-level protocols such as IPv4 or IPv6¶
LINKTYPE_USBPCAP¶
249¶
USB packets, beginning with a USBPcap header¶
LINKTYPE_RTAC_SERIAL¶
250¶
Serial-line packet from the Schweitzer Engineering Laboratories RTAC product¶
LINKTYPE_BLUETOOTH_LE_LL¶
251¶
Bluetooth Low Energy link-layer packets¶
LINKTYPE_NETLINK¶
253¶
Linux Netlink capture encapsulation¶
LINKTYPE_BLUETOOTH_LINUX_MONITOR¶
254¶
Bluetooth Linux Monitor¶
LINKTYPE_BLUETOOTH_BREDR_BB¶
255¶
Bluetooth Basic Rate and Enhanced Data Rate baseband packets¶
LINKTYPE_BLUETOOTH_LE_LL_WITH_PHDR¶
256¶
Bluetooth Low Energy link-layer packets¶
LINKTYPE_PROFIBUS_DL¶
257¶
PROFIBUS data link layer packets¶
LINKTYPE_PKTAP¶
258¶
Apple PKTAP capture encapsulation¶
LINKTYPE_EPON¶
259¶
Ethernet-over-passive-optical-network packets, including preamble octets¶
LINKTYPE_IPMI_HPM_2¶
260¶
IPMI HPM.2 trace packets¶
LINKTYPE_ZWAVE_R1_R2¶
261¶
Z-Wave RF profile R1 and R2 packets¶
LINKTYPE_ZWAVE_R3¶
262¶
Z-Wave RF profile R3 packets¶
LINKTYPE_WATTSTOPPER_DLM¶
263¶
WattStopper Digital Lighting Management (DLM) and Legrand Nitoo Open protocol packets¶
LINKTYPE_ISO_14443¶
264¶
ISO 14443 contactless smartcard messages¶
LINKTYPE_RDS¶
265¶
IEC 62106 Radio data system (RDS) groups¶
LINKTYPE_USB_DARWIN¶
266¶
USB packets captured on a Darwin-based operating system (macOS, etc.)¶
LINKTYPE_TI_LLN_SNIFFER¶
269¶
Texas Instruments protocol sniffer¶
LINKTYPE_LORATAP¶
270¶
LoRaWan packets with a LoRaTap pseudo-header¶
LINKTYPE_VSOCK¶
271¶
Protocol for communication between host and guest machines in VMware and KVM hypervisors¶
LINKTYPE_NORDIC_BLE¶
272¶
Messages to and from a Nordic Semiconductor nRF Sniffer for Bluetooth LE packets¶
LINKTYPE_DOCSIS31_XRA31¶
273¶
DOCSIS packets and bursts, preceded by a pseudo-header¶
LINKTYPE_ETHERNET_MPACKET¶
274¶
IEEE 802.3 mPackets¶
LINKTYPE_DISPLAYPORT_AUX¶
275¶
DisplayPort AUX channel monitoring messages¶
LINKTYPE_LINUX_SLL2¶
276¶
Linux cooked capture encapsulation v2¶
LINKTYPE_OPENVIZSLA¶
278¶
OpenVizsla FPGA-based USB sniffer¶
LINKTYPE_EBHSCR¶
279¶
Elektrobit High Speed Capture and Replay (EBHSCR) format¶
LINKTYPE_VPP_DISPATCH¶
280¶
fd.io VPP graph dispatcher trace records¶
LINKTYPE_DSA_TAG_BRCM¶
281¶
Ethernet frames, with a Broadcom switch tag inserted¶
LINKTYPE_DSA_TAG_BRCM_PREPEND¶
282¶
Ethernet frames, with a Broadcom switch tag prepended¶
LINKTYPE_IEEE802_15_4_TAP¶
283¶
IEEE 802.15.4 with a tap header preceding it¶
LINKTYPE_DSA_TAG_DSA¶
284¶
Ethernet frames, with a Marvell DSA switch tag inserted¶
LINKTYPE_DSA_TAG_EDSA¶
285¶
Ethernet frames, with a Marvell EDSA switch tag inserted¶
LINKTYPE_Z_WAVE_SERIAL¶
287¶
Serial frames transmitted between a host and a Z-Wave chip over an RS-232 or USB serial connection¶
[Z_WAVE_SERIAL] section 5¶
LINKTYPE_USB_2_0¶
288¶
USB 2.0, 1.1, or 1.0 packets¶
LINKTYPE_ATSC_ALP¶
289¶
ATSC Link-Layer Protocol frames¶
LINKTYPE_ETW¶
290¶
Event Tracing for Windows messages¶
LINKTYPE_NETANALYZER_NG¶
291¶
Hilscher Gesellschaft fuer Systemautomation mbH netANALYZER NG hardware and software¶
LINKTYPE_ZBOSS_NCP¶
292¶
ZBOSS NCP Serial Protocol, with a pseudo-header¶
LINKTYPE_USB_2_0_LOW_SPEED¶
293¶
Low-Speed USB 2.0, 1.1, or 1.0 packets¶
LINKTYPE_USB_2_0_FULL_SPEED¶
294¶
Full-Speed USB 2.0, 1.1, or 1.0 packets¶
LINKTYPE_USB_2_0_HIGH_SPEED¶
295¶
High-Speed USB 2.0 packets¶
LINKTYPE_AUERSWALD_LOG¶
296¶
Auerswald Logger Protocol¶
LINKTYPE_ZWAVE_TAP¶
297¶
Z-Wave packets, with a metadata header¶
LINKTYPE_SILABS_DEBUG_CHANNEL¶
298¶
Silicon Labs debug channel protocol¶
LINKTYPE_FIRA_UCI¶
299¶
Ultra-wideband (UWB) controller interface protocol (UCI)¶
LINKTYPE_MDB¶
300¶
MDB (Multi-Drop Bus) protocol¶
When processing a request for an allocation, the Designated Experts will encourage the requester to provide a specification at a stable URL.¶
There is no requirement for a specification, but often review of the specification allows the Designated Expert to determine if the allocation actually is a duplicate of another specification.¶
When the contents of the link type can contain an IPv4 or IPv6 header, then the octets between the beginning of the link type and the IP header needs to be clearly specified.¶
Specifications that are not publicly available, but which may be obtained via liaison agreements (such as to ITU-T, drafts, IEEE, etc.) are acceptable particularly if the specification document will be public eventually. This includes specifications that might be subject to a security classification for which no public document will ever be made. The minimal requirement is to provide a contact for that link type.¶
For other documents, the Designated Expert will need use their judgement, or consult the OPSAWG or an Area Director.¶
This document describes the IANA registration rules for the LinkType encapsulations. PCAP-related packet file formats use this value to determine what kind of headers precede network packet captures. Many of these formats can contain IPv4 and IPv6 packets. A system reading PCAP-related format captures can be subject to arbitrary inputs that may be controlled by malicious entities, so utmost caution is required.¶
Many LinkType formats include a "snapshot" length, which may be smaller than the actual packet. It is therefore very likely that trailing parts of a packet capture may be omitted, yet internal length fields in the packets will claim the packet is bigger than the capture. This leads to trivial buffer overreads, and systems interpreting the packets need to carefully scrutinize all attempts to read data from a capture.¶
PCAP has been developed over three and half decades by a variety of developers, including: Bill Fenner, Denis Ovsienko, Francois-Xavier Le Bail, Fulvio Risso, Gerald Combs, Gianluca Varenni, Gisle Vanem, Hannes Gredler, Joerg Mayer, Michal Sekletar, Stephen Donnelly, Torsten Landschoff, and Jun-ichiro itojun Hagino.¶
PCAP was originally created at LBL by Steve McCanne, Craig Leres, and Van Jacobson.¶
The authors wish to thank: Michael Tuexen, Mohamed Boucadair, Carsten Bormann, Henk Birkholtz, and Robert Wilton their invaluable comments and encouragement.¶