]> Link-Layer Types for PCAP and PCAPNG Capture File Formats
gharris@sonic.net
Sandelman Software Works Inc
mcr+ietf@sandelman.ca http://www.sandelman.ca/
This document creates an IANA registry for the PCAP and PCAPNG LINKTYPE values. The PCAP and PCAPNG formats are used to save network captures from programs such as tcpdump and wireshark, when using libraries such as libpcap. About This Document Status information for this document may be found at . Discussion of this document takes place on the opsawg Working Group mailing list (), which is archived at . Subscribe at . Source for this draft and an issue tracker can be found at .
Introduction In the late 1980's, 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 . Other documents describe the original (legacy) format used by tcpdump (pcap), as well as the revised format (pcapng) which is used by tcpdump and Wireshark . Within those formats each packet that is captured is described 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 the LINKTYPE format, establishing the IANA Considerations by which other uses of the pcap and pcapng formats may register new LINKTYPE values.
Terminology The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 when, and only when, they appear in all capitals, as shown here.
IANA Considerations
PCAP Registry IANA is requested to create a new registry group entitled "The PCAP Registry".
LinkType Registry IANA is also requested to create a registry entitled "PCAP LinkType List" under The PCAP registry group (). The registry has the following structure:
  • LINKTYPE Name: Indicates the symbolic name for this LinkType. The name is prefixed with "LINKTYPE_" (i.e., LINKTYPE_something).
  • LINKTYPE Value: Indicates the integer value assigned for this LinkType.
  • Description: Provides a very short description.
  • Reference: Indicates an authoritative the document reference for the LinkType or a requester reference.
The LinkType value is a 16-bit number. The policy allocation for the LinkType values is as follows:
  • Values from 0 to 32767 must be allocated via Specification Required (). Guidance for Designated Experts is provided in .
  • Values from 32768 to 65000 are allocated following a First-Come First-Served policy ().
  • Values from 65001 to 65535 are reserved for Private Use ().
The initial version of the registry is provided in . In each case here, the reference should be to and the RFC number to be assigned to this document, which is not repeated each time. The initial values table is based upon the Link type list maintained by libpcap, and published on . Note that historically, values were assigned incrementally following First Come First Served policy, with a preference for a public specification, but with no mandate. Some historical values may have less specification than desired. LinkType values 147 to 162 named LINKTYPE_RESERVED_xx were originally reserved for Private Use. Their use is Deprecated in favour of the values in the 65001-65535 range. In general, Private Use values should never leak out of the entity that uses it. As the First Come First Served range is large and easily obtained, official values are recommended.
  • There is often an associated DLT value which is often identical in value, but not universally so. DLT values are associated with specific operation system captures, and are operating system specific, and are thus not subject to standardization.
Initial Values
LINKTYPE Name LINKTYPE Value Description Reference
LINKTYPE_NULL 0 BSD loopback encapsulation
LINKTYPE_ETHERNET 1 IEEE 802.3 Ethernet  
LINKTYPE_EXP_ETHERNET 2 Xerox experimental 3Mb Ethernet  
LINKTYPE_AX25 3 AX.25 packet
LINKTYPE_PRONET 4 Reserved for PRONET  
LINKTYPE_CHAOS 5 Reserved for MIT CHAOSNET  
LINKTYPE_IEEE802_5 6 IEEE 802.5 Token Ring  
LINKTYPE_ARCNET_BSD 7 ARCNET Data Packets with BSD encapsulation  
LINKTYPE_SLIP 8 SLIP
LINKTYPE_PPP 9 PPP /
LINKTYPE_FDDI 10 FDDI: per ANSI INCITS 239-1994  
not to be used 11-49 Do not use these values  
LINKTYPE_PPP_HDLC 50 PPP in HDLC-like framing
LINKTYPE_PPP_ETHER 51 PPPoE
Reserved 52-98 Do not use these values  
LINKTYPE_SYMANTEC_FIREWALL 99 Reserved for Symantec Enterprise Firewall  
LINKTYPE_ATM_RFC1483 100 LLC/SNAP-encapsulated ATM
LINKTYPE_RAW 101 Raw IP; begins with an IPv4 or IPv6 header  
LINKTYPE_SLIP_BSDOS 102 Reserved for BSD/OS SLIP BPF header  
LINKTYPE_PPP_BSDOS 103 Reserved for BSD/OS PPP BPF header  
LINKTYPE_C_HDLC 104 Cisco PPP with HDLC framing
LINKTYPE_IEEE802_11 105 IEEE 802.11 wireless LAN  
LINKTYPE_ATM_CLIP 106 ATM Classical IP, with no header preceding IP  
LINKTYPE_FRELAY 107 Frame Relay LAPF frames  
LINKTYPE_LOOP 108 OpenBSD loopback encapsulation
LINKTYPE_ENC 109 Reserved for OpenBSD IPSEC encapsulation  
LINKTYPE_LANE8023 110 Reserved for ATM LANE + 802.3  
LINKTYPE_HIPPI 111 Reserved for NetBSD HIPPI  
LINKTYPE_HDLC 112 Reserved for NetBSD HDLC framing  
LINKTYPE_LINUX_SLL 113 Linux "cooked" capture encapsulation
LINKTYPE_LTALK 114 Apple LocalTalk  
LINKTYPE_ECONET 115 Reserved for Acorn Econet  
LINKTYPE_IPFILTER 116 Reserved for OpenBSD ipfilter  
LINKTYPE_PFLOG 117 OpenBSD pflog; "struct pfloghdr" structure  
LINKTYPE_CISCO_IOS 118 Reserved for Cisco-internal use  
LINKTYPE_IEEE802_11_PRISM 119 Prism monitor mode
LINKTYPE_IEEE802_11_AIRONET 120 Reserved for 802.11 + FreeFreeBSD Aironet radio metadata  
LINKTYPE_HHDLC 121 Reserved for Siemens HiPath HDLC  
LINKTYPE_IP_OVER_FC 122 IP-over-Fibre Channel, starting with the Network_Header
LINKTYPE_SUNATM 123 ATM traffic captured from a SunATM device
LINKTYPE_RIO 124 Reserved for RapidIO  
LINKTYPE_PCI_EXP 125 Reserved for PCI Express  
LINKTYPE_AURORA 126 Reserved for Xilinx Aurora link layer  
LINKTYPE_IEEE802_11_RADIOTAP 127 Radiotap header, followed by an 802.11 header
LINKTYPE_TZSP 128 Reserved for Tazmen Sniffer Protocol  
LINKTYPE_ARCNET_LINUX 129 ARCNET Data Packets, per RFC 1051 frames w/variations  
LINKTYPE_JUNIPER_MLPPP 130 Reserved for Juniper Networks  
LINKTYPE_JUNIPER_MLFR 131 Reserved for Juniper Networks  
LINKTYPE_JUNIPER_ES 132 Reserved for Juniper Networks  
LINKTYPE_JUNIPER_GGSN 133 Reserved for Juniper Networks  
LINKTYPE_JUNIPER_MFR 134 Reserved for Juniper Networks  
LINKTYPE_JUNIPER_ATM2 135 Reserved for Juniper Networks  
LINKTYPE_JUNIPER_SERVICES 136 Reserved for Juniper Networks  
LINKTYPE_JUNIPER_ATM1 137 Reserved for Juniper Networks  
LINKTYPE_APPLE_IP_OVER_IEEE1394 138 Apple IP-over-IEEE 1394 cooked header
LINKTYPE_MTP2_WITH_PHDR 139 Signaling System 7 (SS7) Message Transfer Part Level
LINKTYPE_MTP2 140 SS7 Level 2
LINKTYPE_MTP3 141 SS7 Level 3, with no MTP2 header
LINKTYPE_SCCP 142 SS7 Control Part, with no MTP3 or MTP2 header
LINKTYPE_DOCSIS 143 DOCSIS MAC frames
LINKTYPE_LINUX_IRDA 144 Linux-IrDA packets
LINKTYPE_IBM_SP 145 Reserved for IBM SP switch  
LINKTYPE_IBM_SN 146 Reserved for IBM Next Federation switch  
LINKTYPE_RESERVED_01 147 For private use (deprecated)  
LINKTYPE_RESERVED_02 148 For private use (deprecated)  
LINKTYPE_RESERVED_03 149 For private use (deprecated)  
LINKTYPE_RESERVED_04 150 For private use (deprecated)  
LINKTYPE_RESERVED_05 151 For private use (deprecated)  
LINKTYPE_RESERVED_06 152 For private use (deprecated)  
LINKTYPE_RESERVED_07 153 For private use (deprecated)  
LINKTYPE_RESERVED_08 154 For private use (deprecated)  
LINKTYPE_RESERVED_09 155 For private use (deprecated)  
LINKTYPE_RESERVED_10 156 For private use (deprecated)  
LINKTYPE_RESERVED_11 157 For private use (deprecated)  
LINKTYPE_RESERVED_12 158 For private use (deprecated)  
LINKTYPE_RESERVED_13 159 For private use (deprecated)  
LINKTYPE_RESERVED_14 160 For private use (deprecated)  
LINKTYPE_RESERVED_15 161 For private use (deprecated)  
LINKTYPE_RESERVED_16 162 For private use (deprecated)  
LINKTYPE_IEEE802_11_AVS 163 AVS header, followed by an 802.11 header
LINKTYPE_JUNIPER_MONITOR 164 Reserved for Juniper Networks  
LINKTYPE_BACNET_MS_TP 165 BACnet MS/TP frames Section 9.3 MS/TP Frame Format of
LINKTYPE_PPP_PPPD 166 PPP in HDLC-like encapsulation, like LINKTYPE_PPP_HDLC, different stuffing  
LINKTYPE_JUNIPER_PPPOE 167 Reserved for Juniper Networks  
LINKTYPE_JUNIPER_PPPOE_ATM 168 Reserved for Juniper Networks  
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 Reserved for Gcom T1/E1 line monitoring equipment  
LINKTYPE_GCOM_SERIAL 173 Reserved for Gcom T1/E1 line monitoring equipment  
LINKTYPE_JUNIPER_PIC_PEER 174 Reserved for Juniper Networks  
LINKTYPE_ERF_ETH 175 Endace ERF header followed by 802.3 Ethernet  
LINKTYPE_ERF_POS 176 Endace ERF header followed by Packet-over-SONET  
LINKTYPE_LINUX_LAPD 177 Linux vISDN LAPD frames
LINKTYPE_JUNIPER_ETHER 178 Reserved for Juniper Networks  
LINKTYPE_JUNIPER_PPP 179 Reserved for Juniper Networks  
LINKTYPE_JUNIPER_FRELAY 180 Reserved for Juniper Networks  
LINKTYPE_JUNIPER_CHDLC 181 Reserved for Juniper Networks  
LINKTYPE_MFR 182 FRF.16.1 Multi-Link Frame Relay frames, beginning with an FRF.12 Interface fragmentation format fragmentation header
LINKTYPE_JUNIPER_VP 183 Reserved for Juniper Networks  
LINKTYPE_A429 184 Reserved for ARINC 429 frames  
LINKTYPE_A653_ICM 185 Reserved for Arinc 653 Interpartition Communication messages  
LINKTYPE_USB_FREEBSD 186 USB packets, beginning with a FreeBSD USB header  
LINKTYPE_BLUETOOTH_HCI_H4 187 Bluetooth HCI UART transport layer; the frame contains an HCI packet indicator octet, as specified by the UART Transport Layer portion of the most recent Bluetooth Core specification, followed by an HCI packet of the specified packet type, as specified by the Host Controller Interface Functional Specification portion of the most recent Bluetooth Core Specification  
LINKTYPE_IEEE802_16_MAC_CPS 188 Reserved for IEEE 802.16 MAC Common Part Sublayer  
LINKTYPE_USB_LINUX 189 USB packets, beginning with a Linux USB header, as specified by the struct usbmon_packet in the Documentation/usb/usbmon.txt file in the Linux source tree. Only the first 48 octets of that header are present. All fields in the header are in host byte order. When performing a live capture, the host byte order is the byte order of the machine on which the packets are captured. When reading a pcap file, the byte order is the byte order for the file, as specified by the file's magic number; when reading a pcapng file, the byte order is the byte order for the section of the pcapng file, as specified by the Section Header Block  
LINKTYPE_CAN20B 190 Reserved for Controller Area Network (CAN) v. 2.0B packets  
LINKTYPE_IEEE802_15_4_LINUX 191 IEEE 802.15.4, with address fields padded, as is done by Linux drivers  
LINKTYPE_PPI 192 Per-Packet Information information, as specified by the Per-Packet Information Header Specification , followed by a packet with the LINKTYPE_ value specified by the pph_dlt field of that header
LINKTYPE_IEEE802_16_MAC_CPS_RADIO 193 Reserved for 802.16 MAC Common Part Sublayer plus radio header  
LINKTYPE_JUNIPER_ISM 194 Reserved for Juniper Networks  
LINKTYPE_IEEE802_15_4_WITHFCS 195 IEEE 802.15.4 Low-Rate Wireless Networks, with each packet having the FCS at the end of the frame  
LINKTYPE_SITA 196 Various link-layer types, with a pseudo-header
LINKTYPE_ERF 197 Endace ERF records
LINKTYPE_RAIF1 198 Reserved for Ethernet packets captured from a u10 Networks board  
LINKTYPE_IPMB_KONTRON 199 Reserved for IPMB packet for IPMI, with a 2-octet header  
LINKTYPE_JUNIPER_ST 200 Reserved for Juniper Networks  
LINKTYPE_BLUETOOTH_HCI_H4_WITH_PHDR 201 Bluetooth HCI UART transport layer; the frame contains a 4-octet direction field, in network byte order (big-endian), the low-order bit of which is set if the frame was sent from the host to the controller and clear if the frame was received by the host from the controller, followed by an HCI packet indicator octet, as specified by the UART Transport Layer portion of the most recent Bluetooth Core specification, followed by an HCI packet of the specified packet type, as specified by the Host Controller Interface Functional Specification portion of the most recent Bluetooth Core Specification  
LINKTYPE_AX25_KISS 202 AX.25 packet, with a KISS header
LINKTYPE_LAPD 203 Link Access Procedures on the D Channel (LAPD) frames, starting with the address field, with no pseudo-header
LINKTYPE_PPP_WITH_DIR 204 PPP, as per RFC 1661 and RFC 1662 , preceded with a one-octet pseudo-header with a zero value meaning received by this host and a non-zero value meaning sent by this host; if the first 2 octets are 0xff and 0x03, it's PPP in HDLC-like framing, with the PPP header following those two octets, otherwise it's PPP without framing, and the packet begins with the PPP header. The data in the frame is not octet-stuffed or bit-stuffed  
LINKTYPE_C_HDLC_WITH_DIR 205 Cisco PPP with HDLC framing, preceded with a one-octet pseudo-header with a zero value meaning received by this host and a non-zero value meaning sent by this host
LINKTYPE_FRELAY_WITH_DIR 206 Frame Relay LAPF frames, beginning with a one-octet pseudo-header with a zero value meaning received by this host (DCE->DTE) and a non-zero value meaning sent by this host (DTE->DCE), followed by an ITU-T Recommendation Q.922 LAPF header starting with the address field, and without an FCS at the end of the frame  
LINKTYPE_LAPB_WITH_DIR 207 Link Access Procedure, Balanced (LAPB), as specified by ITU-T Recommendation X.25 , preceded with a one-octet pseudo-header with a zero value meaning received by this host (DCE->DTE) and a non-zero value meaning sent by this host (DTE->DCE)  
Reserved 208 Reserved for an unspecified link-layer type  
LINKTYPE_I2C_LINUX 209 Linux I2C packets
LINKTYPE_FLEXRAY 210 FlexRay frames or symbols, with a pseudo-header
LINKTYPE_MOST 211 Reserved for Media Oriented Systems Transport (MOST) bus  
LINKTYPE_LIN 212 Local Interconnect Network (LIN) automotive bus
LINKTYPE_X2E_SERIAL 213 Reserved for X2E serial line captures  
LINKTYPE_X2E_XORAYA 214 Reserved for X2E Xoraya data loggers  
LINKTYPE_IEEE802_15_4_NONASK_PHY 215 IEEE 802.15.4 Low-Rate Wireless Networks, with each packet having the FCS at the end of the frame, and with the PHY-level data for the O-QPSK, BPSK, GFSK, MSK, and RCC DSS BPSK PHYs (4 octets of 0 as preamble, one octet of SFD, one octet of frame length + reserved bit) preceding the MAC-layer data (starting with the frame control field)  
LINKTYPE_LINUX_EVDEV 216 Reserved for Linux evdev messages  
LINKTYPE_GSMTAP_UM 217 Reserved for GSM Um interface, with gsmtap header  
LINKTYPE_GSMTAP_ABIS 218 Reserved for 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 a Linux USB header, as specified by the struct usbmon_packet in the Documentation/usb/usbmon.txt file in the Linux source tree. All 64 octets of the header are present. All fields in the header are in host byte order. When performing a live capture, the host byte order is the byte order of the machine on which the packets are captured. When reading a pcap file, the byte order is the byte order for the file, as specified by the file's magic number; when reading a pcapng file, the byte order is the byte order for the section of the pcapng file, as specified by the Section Header Block. For isochronous transfers, the ndesc field specifies the number of isochronous descriptors that follow  
LINKTYPE_DECT 221 Reserved for DECT packets, with a pseudo-header  
LINKTYPE_AOS 222 Reserved for OS Space Data Link Protocol  
LINKTYPE_WIHART 223 Reserved for Wireless HART (Highway Addressable Remote Transducer)  
LINKTYPE_FC_2 224 Fibre Channel FC-2 frames, beginning with a Frame_Header  
LINKTYPE_FC_2_WITH_FRAME_DELIMS 225 Fibre Channel FC-2 frames, beginning an encoding of the SOF, followed by a Frame_Header, and ending with an encoding of the SOF. The encodings represent the frame delimiters as 4-octet sequences representing the corresponding ordered sets, with K28.5 represented as 0xBC, and the D symbols as the corresponding octet values; for example, SOFi2, which is K28.5 - D21.5 - D1.2 - D21.2, is represented as 0xBC 0xB5 0x55 0x55  
LINKTYPE_IPNET 226 Solaris ipnet
LINKTYPE_CAN_SOCKETCAN 227 Controller Area Network frames
LINKTYPE_IPV4 228 Raw IPv4; the packet begins with an IPv4 header  
LINKTYPE_IPV6 229 Raw IPv6; the packet begins with an IPv6 header  
LINKTYPE_IEEE802_15_4_NOFCS 230 IEEE 802.15.4 Low-Rate Wireless Network, without the FCS at the end of the frame  
LINKTYPE_DBUS 231 Raw D-Bus messages , starting with the endianness flag, followed by the message type, etc., but without the authentication handshake before the message sequence
LINKTYPE_JUNIPER_VS 232 Reserved for Juniper Networks  
LINKTYPE_JUNIPER_SRX_E2E 233 Reserved for Juniper Networks  
LINKTYPE_JUNIPER_FIBRECHANNEL 234 Reserved for Juniper Networks  
LINKTYPE_DVB_CI 235 DVB-CI messages
LINKTYPE_MUX27010 236 Variant of 3GPP TS 27.010 multiplexing protocol
LINKTYPE_STANAG_5066_D_PDU 237 D_PDUs as described by NATO standard STANAG 5066, starting with the synchronization sequence, and including both header and data CRCs. The current version of STANAG 5066 is backwards-compatible with the 1.0.2 version , although newer versions are classified
LINKTYPE_JUNIPER_ATM_CEMIC 238 Reserved for Juniper Networks  
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_IPOIB 242 IP-over-InfiniBand
LINKTYPE_MPEG_2_TS 243 MPEG-2 Transport Stream transport packets Table 2-2 of section 2.4.3.2 Transport Stream packet layer of
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_PFSYNC 246 Reserved for pfsync output  
LINKTYPE_INFINIBAND 247 Raw InfiniBand frames, starting with the Local Routing Header, as specified in Chapter 5 Data packet format of InfiniBand™ Architectural Specification Release 1.2.1 Volume 1 - General Specifications  
LINKTYPE_SCTP 248 SCTP packets, as defined by RFC 4960 , 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 air interface Link Layer packets, in the format described in Section 2.1 (PACKET FORMAT) of volume 6 of the Bluetooth Specification Version 4.0 (see PDF page 2200), but without the Preamble  
LINKTYPE_WIRESHARK_UPPER_PDU 252 Reserved for Wireshark  
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, as specified by IEC standard 61158-4-3, beginning with the start delimiter, ending with the end delimiter, and including all octets between them  
LINKTYPE_PKTAP 258 Apple PKTAP capture encapsulation
LINKTYPE_EPON 259 Ethernet-over-passive-optical-network packets, starting with the last 6 octets of the modified preamble as specified by 65.1.3.2 Transmit in Clause 65 of Section 5 of IEEE 802.3, followed immediately by an Ethernet frame  
LINKTYPE_IPMI_HPM_2 260 IPMI trace packets, as specified by Table 3-20 Trace Data Block Format in the PICMG HPM.2 specification The timestamps for packets in this format must match the timestamps in the Trace Data Blocks  
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_OPENFLOW 267 Reserved for OpenBSD DLT_OPENFLOW  
LINKTYPE_SDLC 268 SDLC packets, as specified by Chapter 1, DLC Links, section Synchronous Data Link Control (SDLC) of Systems Network Architecture Formats, GA27-3136-20 , without the flag fields, zero-bit insertion, or Frame Check Sequence field, containing SNA path information units (PIUs) as the payload  
LINKTYPE_TI_LLN_SNIFFER 269 Reserved for Texas Instruments protocol sniffer  
LINKTYPE_LORATAP 270 LoRaTap pseudo-header , followed by the payload, which is typically the PHYPayload from the LoRaWan specification  
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 mPackets, as specified by IEEE 802.3br Figure 99-4, starting with the preamble and always ending with a CRC field  
LINKTYPE_DISPLAYPORT_AUX 275 DisplayPort AUX channel monitoring messages
LINKTYPE_LINUX_SLL2 276 Linux cooked capture encapsulation v2
LINKTYPE_SERCOS_MONITOR 277 Reserved for Sercos Monitor  
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 Low-Rate Wireless Networks, with a pseudo-header containing TLVs with metadata preceding the 802.15.4 header  
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_ELEE 286 Payload of lawful intercept packets using the ELEE protocol The packet begins with the ELEE header; it does not include any transport-layer or lower-layer headers for protocols used to transport ELEE packets  
LINKTYPE_Z_WAVE_SERIAL 287 Serial frames transmitted between a host and a Z-Wave chip over an RS-232 or USB serial connection section 5
LINKTYPE_USB_2_0 288 USB 2.0, 1.1, or 1.0 packet, beginning with a PID, as described by Chapter 8 Protocol Layer of the the Universal Serial Bus Specification Revision 2.0  
LINKTYPE_ATSC_ALP 289 ATSC Link-Layer Protocol frames, as described in section 5 of the A/330 Link-Layer Protocol specification, found at https://www.atsc.org/atsc-documents/type/3-0-standards/, beginning with a Base Header  
LINKTYPE_ETW 290 Event Tracing for Windows messages
LINKTYPE_NETANALYZER_NG 291 Reserved for 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 packet, beginning with a PID, as described by Chapter 8 "Protocol Layer" of the https://www.usb.org/document-library/usb-20-specification the Universal Serial Bus Specification Revision 2.0  
LINKTYPE_USB_2_0_FULL_SPEED 294 Full-Speed USB 2.0, 1.1, or 1.0 packet, beginning with a PID, as described by Chapter 8 "Protocol Layer" of the https://www.usb.org/document-library/usb-20-specification the Universal Serial Bus Specification Revision 2.0  
LINKTYPE_USB_2_0_HIGH_SPEED 295 High-Speed USB 2.0 packet, beginning with a PID, as described by Chapter 8 "Protocol Layer" of the https://www.usb.org/document-library/usb-20-specification the Universal Serial Bus Specification Revision 2.0  
LINKTYPE_AUERSWALD_LOG 296 Auerswald Logger Protocol, as described in https://github.com/Auerswald-GmbH/auerlog/blob/master/auerlog.txt  
LINKTYPE_ZWAVE_TAP 297 Z-Wave packets, as specified by ITU-T Recommendation G.9959, with a https://gitlab.com/exegin/zwave-g9959-tap TAP meta-data header
LINKTYPE_SILABS_DEBUG_CHANNEL 298 Silicon Labs debug channel protocol, as described in https://github.com/SiliconLabs/java_packet_trace_library/blob/master/doc/debug-channel.md  
LINKTYPE_FIRA_UCI 299 Ultra-wideband (UWB) controller interface protocol (UCI)
LINKTYPE_MDB 300 MDB (Multi-Drop Bus) protocol between a vending machine controller and peripherals inside the vending machine, with the message format specified by https://www.kaiser.cx/pcap-mdb.html the PCAP format for MDB specification  
LINKTYPE_DECT_NR 301 DECT-2020 New Radio (NR) MAC layer specified in https://www.etsi.org/committee/1394-dect ETSI TS 103 636-4. The Physical Header Field is always encoded using 80 bits (10 bytes). Broadcast transmissions using 40 bits (5 bytes) is padded with 40 zero bits (5 bytes). When padding is used the Receiver Identity value 0x0000 (reserved address) is used to detect broadcast transmissions  
Guidance for Designated Experts When processing a request for a Specification Required allocation the Designated Experts are expected to be able to find the relevant specification at a clearly stable URL. It is noted that many enterprise web sites do not maintain URLs over a long period of time, and a documented in a "wp-uploaded" section is highly likely to disappear. In addition Specifications that require a reader to click through any kind of marketing or legal agreement are not considered public. (This is the opinion of other corporate lawyers, who worry about what their employees might have agreed to) The specification needs to be clearly written, and 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 very clearly specified in that document. Specifications which are not publically available, but which may be obtained via liason agreements (such as to ITU-T, 3GPP, IEEE, etc.) are acceptable particularly if the document will be public eventually, but are discouraged. For other documents, the Designated Expert will need use their judgement, or consult the WG or an Area Director. Linktypes may be allocated for specifications not publically available may be made within the First-Come/First-Served area. This includes specifications that might be classified. The minimal requirement is for a contact person for that link type.
Security Considerations This document describes the IANA registration rules for the LINKTYPE encapsulations. PCAP, and PCAPNG packet file formats use this value to determine what kind of headers preceed network packet captures. Many of these formats can contain IPv4 and IPv6 packets. A system reading PCAP or PCAPNG 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.
Contributors 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.
Acknowledgments The authors wish to thank: Michael Tuexen, Mohamed Boucadair, Carsten Bormann, Henk Birkholtz, and Robert Wilton their invaluable comments and encouragement.
References Normative References Key words for use in RFCs to Indicate Requirement Levels In many standards track documents several words are used to signify the requirements in the specification. These words are often capitalized. This document defines these words as they should be interpreted in IETF documents. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements. Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words RFC 2119 specifies common key words that may be used in protocol specifications. This document aims to reduce the ambiguity by clarifying that only UPPERCASE usage of the key words have the defined special meanings. Guidelines for Writing an IANA Considerations Section in RFCs Many protocols make use of points of extensibility that use constants to identify various protocol parameters. To ensure that the values in these fields do not have conflicting uses and to promote interoperability, their allocations are often coordinated by a central record keeper. For IETF protocols, that role is filled by the Internet Assigned Numbers Authority (IANA). To make assignments in a given registry prudently, guidance describing the conditions under which new values should be assigned, as well as when and how modifications to existing values can be made, is needed. This document defines a framework for the documentation of these guidelines by specification authors, in order to assure that the provided guidance for the IANA Considerations is clear and addresses the various issues that are likely in the operation of a registry. This is the third edition of this document; it obsoletes RFC 5226. Informative References LINK-LAYER HEADER TYPES n.d. libpcap n.d. Homepage of Wireshark n.d. Digital cellular telecommunications system (Phase 2+); General Packet Radio Service (GPRS); Mobile Station - Serving GPRS Support Node (MS-SGSN) Logical Link Control (LLC) layer specification n.d. 3GPP TS 04.64 BACnet(TM): A Data Communication Protocol for Building Automation and Control Networks n.d. ANSI/ASHRAE Standard 135 Archived AVS specification n.d. AX.25 Link Access Protocol for Amateur Packet Radio Version 2.2 D-Bus Specification Red Hat, Inc. CodeFactory AB Red Hat, Inc. Imendio AB Collabora Ltd. n.d. DOCSIS 4.0 MAC and Upper Layer Protocols Interface Specification n.d. Excentis XRA Header n.d. Common Interface Specification for Conditional Access and other Digital Video Broadcasting Decoder Applications n.d. PCAP format for DVB-CI Documentation EBHSCR n.d. ERF Types Reference Guide n.d. IEEE 802.15.4 TAP Link Type Specification n.d. VNET (VPP Network Stack) n.d. Multilink Frame Relay UNI/NNI Implementation Agreement FRF.16.1 Generic Framing Procedure n.d. ITU-T Recommendation G.7041/Y.1303 Short range narrow-band digital radiocommunication transceivers - PHY, MAC, SAR and LLC layer specifications n.d. ITU-T Recommendation G.9959 Information technology - Generic coding of moving pictures and associated audio information: Systems n.d. ITU-T Recommendation H.222.0 PCAP format for ISO14443 The KISS TNC - A simple Host-to-TNC communications protocol n.d. LINKTYPE_APPLE_IP_OVER_IEEE1394 n.d. LINKTYPE_BLUETOOTH_BREDR_BB n.d. LINKTYPE_BLUETOOTH_LE_LL_WITH_PHDR n.d. LINKTYPE_BLUETOOTH_LINUX_MONITOR n.d. LINKTYPE_CAN_SOCKETCAN n.d. LINKTYPE_DISPLAYPORT_AUX n.d. LINKTYPE_DSA_TAG_BRCM n.d. LINKTYPE_DSA_TAG_BRCM_PREPEND n.d. LINKTYPE_DSA_TAG_DSA n.d. LINKTYPE_DSA_TAG_EDSA n.d. LINKTYPE_ETW n.d. LINKTYPE_FIRA_UCI n.d. LINKTYPE_FLEXRAY n.d. LINKTYPE_I2C_LINUX n.d. LINKTYPE_IEEE802_11_PRISM n.d. LINKTYPE_IPNET n.d. LINKTYPE_LIN n.d. LINKTYPE_LINUX_IRDA n.d. LINKTYPE_LINUX_LAPD n.d. LINKTYPE_LINUX_SLL n.d. LINKTYPE_LINUX_SLL2 n.d. LINKTYPE_LOOP n.d. LINKTYPE_MUX27010 n.d. LINKTYPE_NETANALYZER n.d. LINKTYPE_NETANALYZER_TRANSPARENT n.d. LINKTYPE_NETLINK n.d. LINKTYPE_NFC_LLCP n.d. LINKTYPE_NFLOG n.d. LINKTYPE_NG40 n.d. LINKTYPE_NORDIC_BLE n.d. LINKTYPE_NULL n.d. LINKTYPE_PKTAP n.d. LINKTYPE_RDS n.d. LINKTYPE_RTAC_SERIAL n.d. LINKTYPE_SITA n.d. LINKTYPE_SLIP n.d. LINKTYPE_SUNATM n.d. LINKTYPE_USB_DARWIN n.d. LINKTYPE_VSOCK n.d. LINKTYPE_WATTSTOPPER_DLM n.d. LINKTYPE_ZBOSS_NCP n.d. LINKTYPE_ZWAVE_R1_R2 n.d. LINKTYPE_ZWAVE_R3 n.d. LoRaTap n.d. About the LoRaWAN Standards n.d. OpenVizsla protocol description Per-Packet Information Header Specification Specifications of Signalling System No. 7 Signalling Link n.d. ITU-T Recommendation Q.703 Specifications of Signalling System No. 7 Signalling Network Functions And Messages n.d. ITU-T Recommendation Q.704 Specifications of Signalling System No. 7 Functional description of the signalling connection control part n.d. ITU-T Recommendation Q.711 Specifications of Signalling System No. 7 Definition and function of signalling connection control part messages n.d. ITU-T Recommendation Q.712 Specifications of Signalling System No. 7 Signalling connection control part functions and codes n.d. ITU-T Recommendation Q.713 Specifications of Signalling System No. 7 Signalling connection control part procedures n.d. ITU-T Recommendation Q.714 Radiotap Web site radiotap.org n.d. Digital Subscriber Signalling System No. 1 (DSS1) - ISDN User-Network Interface Data Link Layer - General aspects n.d. ITU-T Recommendation Q.920 ISDN user-network interface - Data Link Layer specification n.d. ITU-T Recommendation Q.921 Profile for Maritime High Frequency (HF) Radio Data Communications n.d. STANAG 5066 USBPcap Capture format specification n.d. Z-Wave Serial API Host Application Programming Guide n.d. The Point-to-Point Protocol (PPP) This document defines the PPP organization and methodology, and the PPP encapsulation, together with an extensible option negotiation mechanism which is able to negotiate a rich assortment of configuration parameters and provides additional management functions. [STANDARDS-TRACK] PPP in HDLC-like Framing This document describes the use of HDLC-like framing for PPP encapsulated packets. [STANDARDS-TRACK] A Method for Transmitting PPP Over Ethernet (PPPoE) This document describes how to build PPP sessions and encapsulate PPP packets over Ethernet. This memo provides information for the Internet community. Multiprotocol Encapsulation over ATM Adaptation Layer 5 This memo describes two encapsulations methods for carrying network interconnect traffic over ATM AAL5. [STANDARDS-TRACK] Requirements for an Internet Standard Point-to-Point Protocol This document discusses the evaluation criteria for an Internet Standard Data Link Layer protocol to be used with point-to-point links. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind. IP and ARP over Fibre Channel The purpose of this document is to specify a way of encapsulating IP and Address Resolution Protocol(ARP) over Fibre Channel and also to describe a mechanism(s) for IP address resolution. [STANDARDS-TRACK] Transmission of IP over InfiniBand (IPoIB) This document specifies a method for encapsulating and transmitting IPv4/IPv6 and Address Resolution Protocol (ARP) packets over InfiniBand (IB). It describes the link-layer address to be used when resolving the IP addresses in IP over InfiniBand (IPoIB) subnets. The document also describes the mapping from IP multicast addresses to InfiniBand multicast addresses. In addition, this document defines the setup and configuration of IPoIB links. [STANDARDS-TRACK] Linux Netlink as an IP Services Protocol This document describes Linux Netlink, which is used in Linux both as an intra-kernel messaging system as well as between kernel and user space. The focus of this document is to describe Netlink's functionality as a protocol between a Forwarding Engine Component (FEC) and a Control Plane Component (CPC), the two components that define an IP service. As a result of this focus, this document ignores other uses of Netlink, including its use as a intra-kernel messaging system, as an inter- process communication scheme (IPC), or as a configuration tool for other non-networking or non-IP network services (such as decnet, etc.). This document is intended as informational in the context of prior art for the ForCES IETF working group. This memo provides information for the Internet community.