idnits 2.17.1 draft-gharris-opsawg-pcap-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (21 December 2020) is 1222 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Missing Reference: 'LINKTYPES' is mentioned on line 262, but not defined == Missing Reference: 'TM' is mentioned on line 944, but not defined == Outdated reference: A later version (-05) exists of draft-tuexen-opsawg-pcapng-02 Summary: 0 errors (**), 0 flaws (~~), 4 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group G. Harris, Ed. 3 Internet-Draft 4 Intended status: Informational M. Richardson 5 Expires: 24 June 2021 Sandelman 6 21 December 2020 8 PCAP Capture File Format 9 draft-gharris-opsawg-pcap-01 11 Abstract 13 This document describes the format used by the libpcap library to 14 record captured packets to a file. Programs using the libpcap 15 library to read and write those files, and thus reading and writing 16 files in that format, include tcpdump. 18 Discussion Venues 20 This note is to be removed before publishing as an RFC. 22 Discussion of this document takes place on the OPSAWG Working Group 23 mailing list (opsawg@ietf.org), which is archived at 24 https://mailarchive.ietf.org/arch/browse/opsawg/. 26 Source for this draft and an issue tracker can be found at 27 https://github.com/pcapng/pcapng. 29 Status of This Memo 31 This Internet-Draft is submitted in full conformance with the 32 provisions of BCP 78 and BCP 79. 34 Internet-Drafts are working documents of the Internet Engineering 35 Task Force (IETF). Note that other groups may also distribute 36 working documents as Internet-Drafts. The list of current Internet- 37 Drafts is at https://datatracker.ietf.org/drafts/current/. 39 Internet-Drafts are draft documents valid for a maximum of six months 40 and may be updated, replaced, or obsoleted by other documents at any 41 time. It is inappropriate to use Internet-Drafts as reference 42 material or to cite them other than as "work in progress." 44 This Internet-Draft will expire on 24 June 2021. 46 Copyright Notice 48 Copyright (c) 2020 IETF Trust and the persons identified as the 49 document authors. All rights reserved. 51 This document is subject to BCP 78 and the IETF Trust's Legal 52 Provisions Relating to IETF Documents (https://trustee.ietf.org/ 53 license-info) in effect on the date of publication of this document. 54 Please review these documents carefully, as they describe your rights 55 and restrictions with respect to this document. Code Components 56 extracted from this document must include Simplified BSD License text 57 as described in Section 4.e of the Trust Legal Provisions and are 58 provided without warranty as described in the Simplified BSD License. 60 Table of Contents 62 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 63 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 64 3. General File Structure . . . . . . . . . . . . . . . . . . . 3 65 4. File Header . . . . . . . . . . . . . . . . . . . . . . . . . 3 66 5. Packet Record . . . . . . . . . . . . . . . . . . . . . . . . 5 67 6. Recommended File Name Extension: .pcap . . . . . . . . . . . 7 68 7. Security Considerations . . . . . . . . . . . . . . . . . . . 7 69 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7 70 8.1. LinkType Registry . . . . . . . . . . . . . . . . . . . . 7 71 9. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 28 72 10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 28 73 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 28 74 11.1. Normative References . . . . . . . . . . . . . . . . . . 28 75 11.2. Informative References . . . . . . . . . . . . . . . . . 28 76 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 28 78 1. Introduction 80 In the late 1980's, Van Jacobson, Steve McCanne, and others at the 81 Network Research Group at Lawrence Berkeley National Laboratory 82 developed the tcpdump program to capture and dissect network traces. 83 The code to capture traffic, using low-level mechanisms in various 84 operating systems, and to read and write network traces to a file was 85 later put into a library named libpcap. 87 This document describes the format used by tcpdump, and other 88 programs using libpcap, to read and write network traces. 90 2. Terminology 92 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 93 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 94 "OPTIONAL" in this document are to be interpreted as described in 95 BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all 96 capitals, as shown here. 98 3. General File Structure 100 A capture file begins with a File Header, followed by zero or more 101 Packet Records, one per packet. 103 All fields in the File Header and in Packet Records will always be 104 saved according to the characteristics (little endian / big endian) 105 of the capturing machine. This refers to all the fields that are 106 saved as numbers and that span over two or more octets. 108 The approach of having the file saved in the native format of the 109 generating host is more efficient because it avoids translation of 110 data when reading / writing on the host itself, which is the most 111 common case when generating/processing capture captures. 113 The packets are shown in traditional IETF diagram, with the bits 114 numbered from the left to the right. The bit numbering does not 115 reflect the binary value position, as IETF protocols are 116 traditionally in big-endian network-byte order. The most significant 117 bit is therefore on the left in this diagram as if the file is being 118 stored on a big-endian system. 120 4. File Header 122 The File Header has the following format: 124 1 2 3 125 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 126 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 127 0 | Magic Number | 128 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 129 4 | Major Version | Minor Version | 130 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 131 8 | Reserved1 | 132 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 133 12 | Reserved2 | 134 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 135 16 | SnapLen | 136 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 137 20 | FCS |f|0 0 0 0 0 0 0 0 0 0 0 0| LinkType | 138 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 140 Figure 1: File Header 142 The File Header length is 24 octets. 144 The meaning of the fields in the File Header is: 146 Magic Number (32 bits): an unsigned magic number, whose value is 147 either the hexadecimal number 0xA1B2C3D4 or the hexadecimal number 148 0xA1B23C4D. 150 If the value is 0xA1B2C3D4, time stamps in Packet Records (see 151 Figure 2) are in seconds and microseconds; if it is 0xA1B23C4D, 152 time stamps in Packet Records are in seconds and nanoseconds. 154 These numbers can be used to distinguish sections that have been 155 saved on little-endian machines from the ones saved on big-endian 156 machines, and to heuristically identify pcap files. 158 Major Version (16 bits): an unsigned value, giving the number of the 159 current major version of the format. The value for the current 160 version of the format is 2. This value should change if the 161 format changes in such a way that code that reads the new format 162 could not read the old format (i.e., code to read both formats 163 would have to check the version number and use different code 164 paths for the two formats) and code that reads the old format 165 could not read the new format. 167 Minor Version (16 bits): an unsigned value, giving the number of the 168 current minor version of the format. The value is for the current 169 version of the format is 4. This value should change if the 170 format changes in such a way that code that reads the new format 171 could read the old format without checking the version number but 172 code that reads the old format could not read all files in the new 173 format. 175 Reserved1 (32 bits): not used - SHOULD be filled with 0 by pcap file 176 writers, and MUST be ignored by pcap file readers. This value was 177 documented by some older implementations as "gmt to local 178 correction". Some older pcap file writers stored non-zero values 179 in this field. 181 Reserved2 (32 bits): not used - SHOULD be filled with 0 by pcap file 182 writers, and MUST be ignored by pcap file readers. This value was 183 documented by some older implementations as "accuracy of 184 timestamps". Some older pcap file writers stored non-zero values 185 in this field. 187 SnapLen (32 bits): an unsigned value indicating the maximum number 188 of octets captured from each packet. The portion of each packet 189 that exceeds this value will not be stored in the file. This 190 value MUST NOT be zero; if no limit was specified, the value 191 should be a number greater than or equal to the largest packet 192 length in the file. 194 LinkType (16 bits): a 16-bit unsigned value that defines the link 195 layer type of packets in the file. This field is defined in the 196 Section 8.1 IANA registry. 198 Frame Cyclic Sequence (FCS) present (4 bits): if the "f" bit is set, 199 then the 3 FCS bits provide the number of 16-bit (2 byte) words of 200 FCS that are appended to each packet. 202 valid values are between 0 and 7, with ethernet typically having a 203 length of 4 bytes, or a value of 2. 205 The bits marked as zero MUST be set to zero by pcap writers, and MUST 206 be ignored by pcap readers. 208 5. Packet Record 210 A Packet Record is the standard container for storing the packets 211 coming from the network. 213 1 2 3 214 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 215 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 216 0 | Timestamp (Seconds) | 217 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 218 4 | Timestamp (Microseconds or nanoseconds) | 219 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 220 8 | Captured Packet Length | 221 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 222 12 | Original Packet Length | 223 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 224 16 / / 225 / Packet Data / 226 / variable length / 227 / / 228 +---------------------------------------------------------------+ 230 Figure 2: Packet Record 232 The Packet Header length is 16 octets. 234 The meaning of the fields in the Packet Record is: 236 Timestamp (Seconds) and Timestamp (Microseconds or nanoseconds): sec 237 onds and fraction of a seconds values of a timestamp. 239 The seconds value is a 32-bit unsigned integer that represents the 240 number of seconds that have elapsed since 1970-01-01 00:00:00 UTC, 241 and the microseconds or nanoseconds value represents the number of 242 microseconds or nanoseconds that have elapsed since that seconds. 244 Whether the value represents microseconds or nanoseconds is 245 specified by the magic number in the File Header. 247 Captured Packet Length (32 bits): an unsigned value that indicates 248 the number of octets captured from the packet (i.e. the length of 249 the Packet Data field). It will be the minimum value among the 250 Original Packet Length and the snapshot length for the interface 251 (SnapLen, defined in Figure 1). 253 Original Packet Length (32 bits): an unsigned value that indicates 254 the actual length of the packet when it was transmitted on the 255 network. It can be different from the Captured Packet Length if 256 the packet has been truncated by the capture process. 258 Packet Data: the data coming from the network, including link-layer 259 headers. The actual length of this field is Captured Packet 260 Length. The format of the link-layer headers depends on the 261 LinkType field specified in the file header (see Figure 1) and it 262 is specified in the entry for that format in [LINKTYPES]. 264 6. Recommended File Name Extension: .pcap 266 The recommended file name extension for the "PCAP Capture File 267 Format" specified in this document is ".pcap". 269 On Windows and macOS, files are distinguished by an extension to 270 their filename. Such an extension is technically not actually 271 required, as applications should be able to automatically detect the 272 pcap file format through the "magic bytes" at the beginning of the 273 file, as some other UN*X desktop environments do. However, using 274 name extensions makes it easier to work with files (e.g. visually 275 distinguish file formats) so it is recommended - though not required 276 - to use .pcap as the name extension for files following this 277 specification. 279 Please note: To avoid confusion (such as the current usage of .cap 280 for a plethora of different capture file formats) file name 281 extensions other than .pcap should be avoided. 283 There is new work to create the PCAP Next Generation capture File 284 Format (see [I-D.tuexen-opsawg-pcapng]). The new file format is not 285 compatible with this specification, but many programs read both 286 transparently. Files of that type will usually start with a 287 Section Header Block, with a magic number of 0x0A0D0D0A. 289 7. Security Considerations 291 TBD. 293 8. IANA Considerations 295 This document requires the following IANA actions: 297 8.1. LinkType Registry 299 IANA is requested to create a new Registry entitled: "The PCAP 300 Registry", and within that Registry to create a table called: "PCAP 301 LinkType List". 303 The LinkType Registry is a table of 16-bit numbers. The Registry has 304 three sections according to [RFC8126]: * values from 0 to 32767 are 305 marked as Specification Required. * except that values 147 to 162 are 306 reserved for Private Use * values from 32768 to 65000 are marked as 307 First-Come First-Served. * values from 65000 to 65536 are marked as 308 Private Use. 310 The Registry has three columns: the integer value, the symbolic name 311 (LINKTYPE_something), a very short description, and the document/ 312 requestor reference. 314 The Registry shall be populated as follows in the table below. 316 This table is base upon the Link type list maintained by libpcap, and 317 published on the tcpdump.org web site as http://www.tcpdump.org/ 318 linktypes.html. 320 There is often an associated DLT value which are often identical in 321 value, but not universally so. DLT values are associated with 322 specific operation system captures, and are operating system 323 specific. In each case here, the reference should be 324 http://www.tcpdump.org/linktypes.html, which is not repeated. 326 +=====================================+========+====================+ 327 | LINKTYPE name |LINKTYPE|description | 328 | | value | | 329 +=====================================+========+====================+ 330 | LINKTYPE_NULL | 0 |BSD loopback | 331 | | |encapsulation | 332 +-------------------------------------+--------+--------------------+ 333 | LINKTYPE_ETHERNET | 1 |IEEE 802.3 Ethernet | 334 +-------------------------------------+--------+--------------------+ 335 | LINKTYPE_AX25 | 3 |AX.25 packet | 336 +-------------------------------------+--------+--------------------+ 337 | LINKTYPE_IEEE802_5 | 6 |IEEE 802.5 Token | 338 | | |Ring | 339 +-------------------------------------+--------+--------------------+ 340 | LINKTYPE_ARCNET_BSD | 7 |ARCNET Data Packets | 341 +-------------------------------------+--------+--------------------+ 342 | LINKTYPE_SLIP | 8 |SLIP, w/ | 343 | | |LINKTYPE_SLIP | 344 | | |header. | 345 +-------------------------------------+--------+--------------------+ 346 | LINKTYPE_PPP | 9 |PPP, as per RFC | 347 | | |1661/RFC 1662 | 348 +-------------------------------------+--------+--------------------+ 349 | LINKTYPE_FDDI | 10 |FDDI: per ANSI | 350 | | |INCITS 239-1994. | 351 +-------------------------------------+--------+--------------------+ 352 | LINKTYPE_PPP_HDLC | 50 |PPP in HDLC-like | 353 | | |framing, as per RFC | 354 | | |1662 | 355 +-------------------------------------+--------+--------------------+ 356 | LINKTYPE_PPP_ETHER | 51 |PPPoE; per RFC 2516 | 357 +-------------------------------------+--------+--------------------+ 358 | LINKTYPE_ATM_RFC1483 | 100 |RFC 1483 LLC/SNAP- | 359 | | |encapsulated ATM | 360 +-------------------------------------+--------+--------------------+ 361 | LINKTYPE_RAW | 101 |Raw IP; begins with | 362 | | |an IPv4 or IPv6 | 363 | | |header | 364 +-------------------------------------+--------+--------------------+ 365 | LINKTYPE_C_HDLC | 104 |Cisco PPP with HDLC | 366 | | |framing, as per | 367 | | |section 4.3.1 of RFC| 368 | | |1547 | 369 +-------------------------------------+--------+--------------------+ 370 | LINKTYPE_IEEE802_11 | 105 |IEEE 802.11 wireless| 371 | | |LAN. | 372 +-------------------------------------+--------+--------------------+ 373 | LINKTYPE_FRELAY | 107 |Frame Relay LAPF | 374 | | |frames | 375 +-------------------------------------+--------+--------------------+ 376 | LINKTYPE_LOOP | 108 |OpenBSD loopback | 377 | | |encapsulation | 378 +-------------------------------------+--------+--------------------+ 379 | LINKTYPE_LINUX_SLL | 113 |Linux "cooked" | 380 | | |capture | 381 | | |encapsulation | 382 +-------------------------------------+--------+--------------------+ 383 | LINKTYPE_LTALK | 114 |Apple LocalTalk | 384 +-------------------------------------+--------+--------------------+ 385 | LINKTYPE_PFLOG | 117 |OpenBSD pflog; | 386 | | |"struct pfloghdr" | 387 | | |structure | 388 +-------------------------------------+--------+--------------------+ 389 | LINKTYPE_IEEE802_11_PRISM | 119 |Prism monitor mode | 390 +-------------------------------------+--------+--------------------+ 391 | LINKTYPE_IP_OVER_FC | 122 |RFC 2625 IP-over- | 392 | | |Fibre Channel | 393 +-------------------------------------+--------+--------------------+ 394 | LINKTYPE_SUNATM | 123 |ATM traffic, / per | 395 | | |SunATM devices | 396 +-------------------------------------+--------+--------------------+ 397 | LINKTYPE_IEEE802_11_RADIOTAP | 127 |Radiotap - followed | 398 | | |by an 802.11 header | 399 +-------------------------------------+--------+--------------------+ 400 | LINKTYPE_ARCNET_LINUX | 129 |ARCNET Data Packets,| 401 | | |per RFC 1051 frames | 402 | | |w/variations | 403 +-------------------------------------+--------+--------------------+ 404 | LINKTYPE_APPLE_IP_OVER_IEEE1394 | 138 |Apple IP-over-IEEE | 405 | | |1394 cooked header | 406 +-------------------------------------+--------+--------------------+ 407 | LINKTYPE_MTP2_WITH_PHDR | 139 |Signaling System 7 | 408 | | |(SS7) Message | 409 | | |Transfer Part Level | 410 | | |ITU-T Q.703 | 411 +-------------------------------------+--------+--------------------+ 412 | LINKTYPE_MTP2 | 140 |SS7 Level 2, Q.703 | 413 +-------------------------------------+--------+--------------------+ 414 | LINKTYPE_MTP3 | 141 |SS7 Level 3, Q.704 | 415 +-------------------------------------+--------+--------------------+ 416 | LINKTYPE_SCCP | 142 |SS7 Control Part, | 417 | | |ITU-T | 418 | | |Q.711/Q.712/Q.713/ | 419 | | |Q.714 | 420 +-------------------------------------+--------+--------------------+ 421 | LINKTYPE_DOCSIS | 143 |DOCSIS MAC frames, | 422 | | |DOCSIS 3.1 | 423 +-------------------------------------+--------+--------------------+ 424 | LINKTYPE_LINUX_IRDA | 144 |Linux-IrDA packets | 425 | | |w/ | 426 | | |LINKTYPE_LINUX_IRDA | 427 | | |header | 428 +-------------------------------------+--------+--------------------+ 429 | LINKTYPE_IEEE802_11_AVS | 163 |AVS monitor mode | 430 | | |w/802.11 header | 431 +-------------------------------------+--------+--------------------+ 432 | LINKTYPE_BACNET_MS_TP | 165 |BACnet MS/TP frames,| 433 | | |per 9.3 MS/TP Frame | 434 | | |Format ANSI 135 | 435 +-------------------------------------+--------+--------------------+ 436 | LINKTYPE_PPP_PPPD | 166 |PPP in HDLC-like | 437 | | |encapsulation, like | 438 | | |LINKTYPE_PPP_HDLC, | 439 | | |different stuffing | 440 +-------------------------------------+--------+--------------------+ 441 | LINKTYPE_GPRS_LLC | 169 |General Packet Radio| 442 | | |Service Logical Link| 443 | | |Control, as per 3GPP| 444 | | |TS 04.64 | 445 +-------------------------------------+--------+--------------------+ 446 | LINKTYPE_GPF_T | 170 |Transparent-mapped | 447 | | |generic framing | 448 | | |procedure, as | 449 | | |specified by ITU-T | 450 | | |Recommendation | 451 | | |G.7041/Y.1303 | 452 +-------------------------------------+--------+--------------------+ 453 | LINKTYPE_GPF_F | 171 |Frame-mapped generic| 454 | | |framing procedure, | 455 | | |as specified by | 456 | | |ITU-T Recommendation| 457 | | |G.7041/Y.1303 | 458 +-------------------------------------+--------+--------------------+ 459 | LINKTYPE_LINUX_LAPD | 177 |Link Access | 460 | | |Procedures on the D | 461 | | |Channel (LAPD) | 462 | | |frames, as specified| 463 | | |by ITU-T | 464 | | |Recommendation Q.920| 465 | | |and ITU-T | 466 | | |Recommendation Q.921| 467 | | |, captured via | 468 | | |vISDN, with a | 469 | | |LINKTYPE_LINUX_LAPD | 470 | | |header , followed by| 471 | | |the Q.921 frame, | 472 | | |starting with the | 473 | | |address field. | 474 +-------------------------------------+--------+--------------------+ 475 | LINKTYPE_MFR | 182 |FRF.16.1 Multi-Link | 476 | | |Frame Relay frames, | 477 | | |beginning with an | 478 | | |FRF.12 Interface | 479 | | |fragmentation format| 480 | | |fragmentation | 481 | | |header. | 482 +-------------------------------------+--------+--------------------+ 483 | LINKTYPE_BLUETOOTH_HCI_H4 | 187 |Bluetooth HCI UART | 484 | | |transport layer; the| 485 | | |frame contains an | 486 | | |HCI packet indicator| 487 | | |byte, as specified | 488 | | |by the UART | 489 | | |Transport Layer | 490 | | |portion of the most | 491 | | |recent Bluetooth | 492 | | |Core specification ,| 493 | | |followed by an HCI | 494 | | |packet of the | 495 | | |specified packet | 496 | | |type, as specified | 497 | | |by the Host | 498 | | |Controller Interface| 499 | | |Functional | 500 | | |Specification | 501 | | |portion of the most | 502 | | |recent Bluetooth | 503 | | |Core Specification. | 504 +-------------------------------------+--------+--------------------+ 505 | LINKTYPE_USB_LINUX | 189 |USB packets, | 506 | | |beginning with a | 507 | | |Linux USB header, as| 508 | | |specified by the | 509 | | |struct usbmon_packet| 510 | | |in the | 511 | | |Documentation/usb/ | 512 | | |usbmon.txt file in | 513 | | |the Linux source | 514 | | |tree. Only the | 515 | | |first 48 bytes of | 516 | | |that header are | 517 | | |present. All fields| 518 | | |in the header are in| 519 | | |host byte order. | 520 | | |When performing a | 521 | | |live capture, the | 522 | | |host byte order is | 523 | | |the byte order of | 524 | | |the machine on which| 525 | | |the packets are | 526 | | |captured. When | 527 | | |reading a pcap file,| 528 | | |the byte order is | 529 | | |the byte order for | 530 | | |the file, as | 531 | | |specified by the | 532 | | |file's magic number;| 533 | | |when reading a | 534 | | |pcapng file, the | 535 | | |byte order is the | 536 | | |byte order for the | 537 | | |section of the | 538 | | |pcapng file, as | 539 | | |specified by the | 540 | | |Section Header | 541 | | |Block. | 542 +-------------------------------------+--------+--------------------+ 543 | LINKTYPE_PPI | 192 |Per-Packet | 544 | | |Information | 545 | | |information, as | 546 | | |specified by the | 547 | | |Per-Packet | 548 | | |Information Header | 549 | | |Specification , | 550 | | |followed by a packet| 551 | | |with the LINKTYPE_ | 552 | | |value specified by | 553 | | |the pph_dlt field of| 554 | | |that header. | 555 +-------------------------------------+--------+--------------------+ 556 | LINKTYPE_IEEE802_15_4_WITHFCS | 195 |IEEE 802.15.4 Low- | 557 | | |Rate Wireless | 558 | | |Networks, with each | 559 | | |packet having the | 560 | | |FCS at the end of | 561 | | |the frame. | 562 +-------------------------------------+--------+--------------------+ 563 | LINKTYPE_SITA | 196 |Various link-layer | 564 | | |types, with a | 565 | | |pseudo-header , for | 566 | | |SITA | 567 +-------------------------------------+--------+--------------------+ 568 | LINKTYPE_ERF | 197 |Various link-layer | 569 | | |types, with a | 570 | | |pseudo-header, for | 571 | | |Endace DAG cards; | 572 | | |encapsulates Endace | 573 | | |ERF records. | 574 +-------------------------------------+--------+--------------------+ 575 | LINKTYPE_BLUETOOTH_HCI_H4_WITH_PHDR | 201 |Bluetooth HCI UART | 576 | | |transport layer; the| 577 | | |frame contains a | 578 | | |4-byte direction | 579 | | |field, in network | 580 | | |byte order (big- | 581 | | |endian), the low- | 582 | | |order bit of which | 583 | | |is set if the frame | 584 | | |was sent from the | 585 | | |host to the | 586 | | |controller and clear| 587 | | |if the frame was | 588 | | |received by the host| 589 | | |from the controller,| 590 | | |followed by an HCI | 591 | | |packet indicator | 592 | | |byte, as specified | 593 | | |by the UART | 594 | | |Transport Layer | 595 | | |portion of the most | 596 | | |recent Bluetooth | 597 | | |Core specification ,| 598 | | |followed by an HCI | 599 | | |packet of the | 600 | | |specified packet | 601 | | |type, as specified | 602 | | |by the Host | 603 | | |Controller Interface| 604 | | |Functional | 605 | | |Specification | 606 | | |portion of the most | 607 | | |recent Bluetooth | 608 | | |Core Specification. | 609 +-------------------------------------+--------+--------------------+ 610 | LINKTYPE_AX25_KISS | 202 |AX.25 packet, with a| 611 | | |1-byte KISS header | 612 | | |containing a type | 613 | | |indicator. | 614 +-------------------------------------+--------+--------------------+ 615 | LINKTYPE_LAPD | 203 |Link Access | 616 | | |Procedures on the D | 617 | | |Channel (LAPD) | 618 | | |frames, as specified| 619 | | |by ITU-T | 620 | | |Recommendation Q.920| 621 | | |and ITU-T | 622 | | |Recommendation Q.921| 623 | | |, starting with the | 624 | | |address field, with | 625 | | |no pseudo-header. | 626 +-------------------------------------+--------+--------------------+ 627 | LINKTYPE_PPP_WITH_DIR | 204 |PPP, as per RFC 1661| 628 | | |and RFC 1662 , | 629 | | |preceded with a one-| 630 | | |byte pseudo-header | 631 | | |with a zero value | 632 | | |meaning received by | 633 | | |this host and a non-| 634 | | |zero value meaning | 635 | | |sent by this host; | 636 | | |if the first 2 bytes| 637 | | |are 0xff and 0x03, | 638 | | |it's PPP in HDLC- | 639 | | |like framing, with | 640 | | |the PPP header | 641 | | |following those two | 642 | | |bytes, otherwise | 643 | | |it's PPP without | 644 | | |framing, and the | 645 | | |packet begins with | 646 | | |the PPP header. The| 647 | | |data in the frame is| 648 | | |not octet-stuffed or| 649 | | |bit-stuffed. | 650 +-------------------------------------+--------+--------------------+ 651 | LINKTYPE_C_HDLC_WITH_DIR | 205 |Cisco PPP with HDLC | 652 | | |framing, as per | 653 | | |section 4.3.1 of RFC| 654 | | |1547 , preceded with| 655 | | |a one-byte pseudo- | 656 | | |header with a zero | 657 | | |value meaning | 658 | | |received by this | 659 | | |host and a non-zero | 660 | | |value meaning sent | 661 | | |by this host. | 662 +-------------------------------------+--------+--------------------+ 663 | LINKTYPE_FRELAY_WITH_DIR | 206 |Frame Relay LAPF | 664 | | |frames, beginning | 665 | | |with a one-byte | 666 | | |pseudo-header with a| 667 | | |zero value meaning | 668 | | |received by this | 669 | | |host (DCE->DTE) and | 670 | | |a non-zero value | 671 | | |meaning sent by this| 672 | | |host (DTE->DCE), | 673 | | |followed by an ITU-T| 674 | | |Recommendation Q.922| 675 | | |LAPF header starting| 676 | | |with the address | 677 | | |field, and without | 678 | | |an FCS at the end of| 679 | | |the frame. | 680 +-------------------------------------+--------+--------------------+ 681 | LINKTYPE_LAPB_WITH_DIR | 207 |Link Access | 682 | | |Procedure, Balanced | 683 | | |(LAPB), as specified| 684 | | |by ITU-T | 685 | | |Recommendation X.25 | 686 | | |, preceded with a | 687 | | |one-byte pseudo- | 688 | | |header with a zero | 689 | | |value meaning | 690 | | |received by this | 691 | | |host (DCE->DTE) and | 692 | | |a non-zero value | 693 | | |meaning sent by this| 694 | | |host (DTE->DCE). | 695 +-------------------------------------+--------+--------------------+ 696 | LINKTYPE_IPMB_LINUX | 209 |IPMB over an I2C | 697 | | |circuit, with a | 698 | | |Linux-specific | 699 | | |pseudo-header | 700 +-------------------------------------+--------+--------------------+ 701 | LINKTYPE_IEEE802_15_4_NONASK_PHY | 215 |IEEE 802.15.4 Low- | 702 | | |Rate Wireless | 703 | | |Networks, with each | 704 | | |packet having the | 705 | | |FCS at the end of | 706 | | |the frame, and with | 707 | | |the PHY-level data | 708 | | |for the O-QPSK, | 709 | | |BPSK, GFSK, MSK, and| 710 | | |RCC DSS BPSK PHYs (4| 711 | | |octets of 0 as | 712 | | |preamble, one octet | 713 | | |of SFD, one octet of| 714 | | |frame length + | 715 | | |reserved bit) | 716 | | |preceding the MAC- | 717 | | |layer data (starting| 718 | | |with the frame | 719 | | |control field). | 720 +-------------------------------------+--------+--------------------+ 721 | LINKTYPE_USB_LINUX_MMAPPED | 220 |USB packets, | 722 | | |beginning with a | 723 | | |Linux USB header, as| 724 | | |specified by the | 725 | | |struct usbmon_packet| 726 | | |in the | 727 | | |Documentation/usb/ | 728 | | |usbmon.txt file in | 729 | | |the Linux source | 730 | | |tree. All 64 bytes | 731 | | |of the header are | 732 | | |present. All fields| 733 | | |in the header are in| 734 | | |host byte order. | 735 | | |When performing a | 736 | | |live capture, the | 737 | | |host byte order is | 738 | | |the byte order of | 739 | | |the machine on which| 740 | | |the packets are | 741 | | |captured. When | 742 | | |reading a pcap file,| 743 | | |the byte order is | 744 | | |the byte order for | 745 | | |the file, as | 746 | | |specified by the | 747 | | |file's magic number;| 748 | | |when reading a | 749 | | |pcapng file, the | 750 | | |byte order is the | 751 | | |byte order for the | 752 | | |section of the | 753 | | |pcapng file, as | 754 | | |specified by the | 755 | | |Section Header | 756 | | |Block. For | 757 | | |isochronous | 758 | | |transfers, the ndesc| 759 | | |field specifies the | 760 | | |number of | 761 | | |isochronous | 762 | | |descriptors that | 763 | | |follow. | 764 +-------------------------------------+--------+--------------------+ 765 | LINKTYPE_FC_2 | 224 |Fibre Channel FC-2 | 766 | | |frames, beginning | 767 | | |with a Frame_Header.| 768 +-------------------------------------+--------+--------------------+ 769 | LINKTYPE_FC_2_WITH_FRAME_DELIMS | 225 |Fibre Channel FC-2 | 770 | | |frames, beginning an| 771 | | |encoding of the SOF,| 772 | | |followed by a | 773 | | |Frame_Header, and | 774 | | |ending with an | 775 | | |encoding of the SOF.| 776 | | |The encodings | 777 | | |represent the frame | 778 | | |delimiters as 4-byte| 779 | | |sequences | 780 | | |representing the | 781 | | |corresponding | 782 | | |ordered sets, with | 783 | | |K28.5 represented as| 784 | | |0xBC, and the D | 785 | | |symbols as the | 786 | | |corresponding byte | 787 | | |values; for example,| 788 | | |SOFi2, which is | 789 | | |K28.5 - D21.5 - D1.2| 790 | | |- D21.2, is | 791 | | |represented as 0xBC | 792 | | |0xB5 0x55 0x55. | 793 +-------------------------------------+--------+--------------------+ 794 | LINKTYPE_IPNET | 226 |Solaris ipnet | 795 | | |pseudo-header , | 796 | | |followed by an IPv4 | 797 | | |or IPv6 datagram. | 798 +-------------------------------------+--------+--------------------+ 799 | LINKTYPE_CAN_SOCKETCAN | 227 |CAN (Controller Area| 800 | | |Network) frames, | 801 | | |with a pseudo-header| 802 | | |followed by the | 803 | | |frame payload. | 804 +-------------------------------------+--------+--------------------+ 805 | LINKTYPE_IPV4 | 228 |Raw IPv4; the packet| 806 | | |begins with an IPv4 | 807 | | |header. | 808 +-------------------------------------+--------+--------------------+ 809 | LINKTYPE_IPV6 | 229 |Raw IPv6; the packet| 810 | | |begins with an IPv6 | 811 | | |header. | 812 +-------------------------------------+--------+--------------------+ 813 | LINKTYPE_IEEE802_15_4_NOFCS | 230 |IEEE 802.15.4 Low- | 814 | | |Rate Wireless | 815 | | |Network, without the| 816 | | |FCS at the end of | 817 | | |the frame. | 818 +-------------------------------------+--------+--------------------+ 819 | LINKTYPE_DBUS | 231 |Raw D-Bus messages ,| 820 | | |starting with the | 821 | | |endianness flag, | 822 | | |followed by the | 823 | | |message type, etc., | 824 | | |but without the | 825 | | |authentication | 826 | | |handshake before the| 827 | | |message sequence. | 828 +-------------------------------------+--------+--------------------+ 829 | LINKTYPE_DVB_CI | 235 |DVB-CI (DVB Common | 830 | | |Interface for | 831 | | |communication | 832 | | |between a PC Card | 833 | | |module and a DVB | 834 | | |receiver), with the | 835 | | |message format | 836 | | |specified by the | 837 | | |PCAP format for DVB-| 838 | | |CI specification | 839 +-------------------------------------+--------+--------------------+ 840 | LINKTYPE_MUX27010 | 236 |Variant of 3GPP TS | 841 | | |27.010 multiplexing | 842 | | |protocol (similar | 843 | | |to, but not the same| 844 | | |as, 27.010). | 845 +-------------------------------------+--------+--------------------+ 846 | LINKTYPE_STANAG_5066_D_PDU | 237 |D_PDUs as described | 847 | | |by NATO standard | 848 | | |STANAG 5066, | 849 | | |starting with the | 850 | | |synchronization | 851 | | |sequence, and | 852 | | |including both | 853 | | |header and data | 854 | | |CRCs. The current | 855 | | |version of STANAG | 856 | | |5066 is backwards- | 857 | | |compatible with the | 858 | | |1.0.2 version , | 859 | | |although newer | 860 | | |versions are | 861 | | |classified. | 862 +-------------------------------------+--------+--------------------+ 863 | LINKTYPE_NFLOG | 239 |Linux netlink | 864 | | |NETLINK NFLOG socket| 865 | | |log messages. | 866 +-------------------------------------+--------+--------------------+ 867 | LINKTYPE_NETANALYZER | 240 |Pseudo-header for | 868 | | |Hilscher | 869 | | |Gesellschaft fuer | 870 | | |Systemautomation mbH| 871 | | |netANALYZER devices | 872 | | |, followed by an | 873 | | |Ethernet frame, | 874 | | |beginning with the | 875 | | |MAC header and | 876 | | |ending with the FCS.| 877 +-------------------------------------+--------+--------------------+ 878 | LINKTYPE_NETANALYZER_TRANSPARENT | 241 |Pseudo-header for | 879 | | |Hilscher | 880 | | |Gesellschaft fuer | 881 | | |Systemautomation mbH| 882 | | |netANALYZER devices | 883 | | |, followed by an | 884 | | |Ethernet frame, | 885 | | |beginning with the | 886 | | |preamble, SFD, and | 887 | | |MAC header, and | 888 | | |ending with the FCS.| 889 +-------------------------------------+--------+--------------------+ 890 | LINKTYPE_IPOIB | 242 |IP-over-InfiniBand, | 891 | | |as specified by RFC | 892 | | |4391 section 6 | 893 +-------------------------------------+--------+--------------------+ 894 | LINKTYPE_MPEG_2_TS | 243 |MPEG-2 Transport | 895 | | |Stream transport | 896 | | |packets, as | 897 | | |specified by ISO | 898 | | |13818-1/ ITU-T | 899 | | |Recommendation | 900 | | |H.222.0 (see table | 901 | | |2-2 of section | 902 | | |2.4.3.2 Transport | 903 | | |Stream packet | 904 | | |layer). | 905 +-------------------------------------+--------+--------------------+ 906 | LINKTYPE_NG40 | 244 |Pseudo-header for | 907 | | |ng4T GmbH's UMTS | 908 | | |Iub/Iur-over-ATM and| 909 | | |Iub/Iur-over-IP | 910 | | |format as used by | 911 | | |their ng40 protocol | 912 | | |tester , followed by| 913 | | |frames for the Frame| 914 | | |Protocol as | 915 | | |specified by 3GPP TS| 916 | | |25.427 for dedicated| 917 | | |channels and 3GPP TS| 918 | | |25.435 for common/ | 919 | | |shared channels in | 920 | | |the case of ATM AAL2| 921 | | |or UDP traffic, by | 922 | | |SSCOP packets as | 923 | | |specified by ITU-T | 924 | | |Recommendation | 925 | | |Q.2110 for ATM AAL5 | 926 | | |traffic, and by NBAP| 927 | | |packets for SCTP | 928 | | |traffic. | 929 +-------------------------------------+--------+--------------------+ 930 | LINKTYPE_NFC_LLCP | 245 |Pseudo-header for | 931 | | |NFC LLCP packet | 932 | | |captures , followed | 933 | | |by frame data for | 934 | | |the LLCP Protocol as| 935 | | |specified by | 936 | | |NFCForum-TS-LLCP_1.1| 937 +-------------------------------------+--------+--------------------+ 938 | LINKTYPE_INFINIBAND | 247 |Raw InfiniBand | 939 | | |frames, starting | 940 | | |with the Local | 941 | | |Routing Header, as | 942 | | |specified in Chapter| 943 | | |5 Data packet format| 944 | | |of InfiniBand[TM] | 945 | | |Architectural | 946 | | |Specification | 947 | | |Release 1.2.1 Volume| 948 | | |1 - General | 949 | | |Specifications | 950 +-------------------------------------+--------+--------------------+ 951 | LINKTYPE_SCTP | 248 |SCTP packets, as | 952 | | |defined by RFC 4960 | 953 | | |, with no lower- | 954 | | |level protocols such| 955 | | |as IPv4 or IPv6. | 956 +-------------------------------------+--------+--------------------+ 957 | LINKTYPE_USBPCAP | 249 |USB packets, | 958 | | |beginning with a | 959 | | |USBPcap header | 960 +-------------------------------------+--------+--------------------+ 961 | LINKTYPE_RTAC_SERIAL | 250 |Serial-line packet | 962 | | |header for the | 963 | | |Schweitzer | 964 | | |Engineering | 965 | | |Laboratories RTAC | 966 | | |product , followed | 967 | | |by a payload for one| 968 | | |of a number of | 969 | | |industrial control | 970 | | |protocols. | 971 +-------------------------------------+--------+--------------------+ 972 | LINKTYPE_BLUETOOTH_LE_LL | 251 |Bluetooth Low Energy| 973 | | |air interface Link | 974 | | |Layer packets, in | 975 | | |the format described| 976 | | |in section 2.1 | 977 | | |PACKET FORMAT of | 978 | | |volume 6 of the | 979 | | |Bluetooth | 980 | | |Specification | 981 | | |Version 4.0 (see PDF| 982 | | |page 2200), but | 983 | | |without the | 984 | | |Preamble. | 985 +-------------------------------------+--------+--------------------+ 986 | LINKTYPE_NETLINK | 253 |Linux Netlink | 987 | | |capture | 988 | | |encapsulation | 989 +-------------------------------------+--------+--------------------+ 990 | LINKTYPE_BLUETOOTH_LINUX_MONITOR | 254 |Bluetooth Linux | 991 | | |Monitor | 992 | | |encapsulation of | 993 | | |traffic for the | 994 | | |BlueZ stack | 995 +-------------------------------------+--------+--------------------+ 996 | LINKTYPE_BLUETOOTH_BREDR_BB | 255 |Bluetooth Basic Rate| 997 | | |and Enhanced Data | 998 | | |Rate baseband | 999 | | |packets | 1000 +-------------------------------------+--------+--------------------+ 1001 | LINKTYPE_BLUETOOTH_LE_LL_WITH_PHDR | 256 |Bluetooth Low Energy| 1002 | | |link-layer packets | 1003 +-------------------------------------+--------+--------------------+ 1004 | LINKTYPE_PROFIBUS_DL | 257 |PROFIBUS data link | 1005 | | |layer packets, as | 1006 | | |specified by IEC | 1007 | | |standard 61158-4-3, | 1008 | | |beginning with the | 1009 | | |start delimiter, | 1010 | | |ending with the end | 1011 | | |delimiter, and | 1012 | | |including all octets| 1013 | | |between them. | 1014 +-------------------------------------+--------+--------------------+ 1015 | LINKTYPE_PKTAP | 258 |Apple PKTAP capture | 1016 | | |encapsulation | 1017 +-------------------------------------+--------+--------------------+ 1018 | LINKTYPE_EPON | 259 |Ethernet-over- | 1019 | | |passive-optical- | 1020 | | |network packets, | 1021 | | |starting with the | 1022 | | |last 6 octets of the| 1023 | | |modified preamble as| 1024 | | |specified by | 1025 | | |65.1.3.2 Transmit in| 1026 | | |Clause 65 of | 1027 | | |Section 5 of IEEE | 1028 | | |802.3 , followed | 1029 | | |immediately by an | 1030 | | |Ethernet frame. | 1031 +-------------------------------------+--------+--------------------+ 1032 | LINKTYPE_IPMI_HPM_2 | 260 |IPMI trace packets, | 1033 | | |as specified by | 1034 | | |Table 3-20 Trace | 1035 | | |Data Block Format in| 1036 | | |the PICMG HPM.2 | 1037 | | |specification The | 1038 | | |time stamps for | 1039 | | |packets in this | 1040 | | |format must match | 1041 | | |the time stamps in | 1042 | | |the Trace Data | 1043 | | |Blocks. | 1044 +-------------------------------------+--------+--------------------+ 1045 | LINKTYPE_ZWAVE_R1_R2 | 261 |Z-Wave RF profile R1| 1046 | | |and R2 packets , as | 1047 | | |specified by ITU-T | 1048 | | |Recommendation | 1049 | | |G.9959 , with some | 1050 | | |MAC layer fields | 1051 | | |moved. | 1052 +-------------------------------------+--------+--------------------+ 1053 | LINKTYPE_ZWAVE_R3 | 262 |Z-Wave RF profile R3| 1054 | | |packets , as | 1055 | | |specified by ITU-T | 1056 | | |Recommendation | 1057 | | |G.9959 , with some | 1058 | | |MAC layer fields | 1059 | | |moved. | 1060 +-------------------------------------+--------+--------------------+ 1061 | LINKTYPE_WATTSTOPPER_DLM | 263 |Formats for | 1062 | | |WattStopper Digital | 1063 | | |Lighting Management | 1064 | | |(DLM) and Legrand | 1065 | | |Nitoo Open protocol | 1066 | | |common packet | 1067 | | |structure captures. | 1068 +-------------------------------------+--------+--------------------+ 1069 | LINKTYPE_ISO_14443 | 264 |Messages between ISO| 1070 | | |14443 contactless | 1071 | | |smartcards | 1072 | | |(Proximity | 1073 | | |Integrated Circuit | 1074 | | |Card, PICC) and card| 1075 | | |readers (Proximity | 1076 | | |Coupling Device, | 1077 | | |PCD), with the | 1078 | | |message format | 1079 | | |specified by the | 1080 | | |PCAP format for | 1081 | | |ISO14443 | 1082 | | |specification | 1083 +-------------------------------------+--------+--------------------+ 1084 | LINKTYPE_RDS | 265 |Radio data system | 1085 | | |(RDS) groups, as per| 1086 | | |IEC 62106, | 1087 | | |encapsulated in this| 1088 | | |form | 1089 +-------------------------------------+--------+--------------------+ 1090 | LINKTYPE_USB_DARWIN | 266 |USB packets, | 1091 | | |beginning with a | 1092 | | |Darwin (macOS, etc.)| 1093 | | |USB header | 1094 +-------------------------------------+--------+--------------------+ 1095 | LINKTYPE_SDLC | 268 |SDLC packets, as | 1096 | | |specified by Chapter| 1097 | | |1, DLC Links, | 1098 | | |section Synchronous | 1099 | | |Data Link Control | 1100 | | |(SDLC) of Systems | 1101 | | |Network Architecture| 1102 | | |Formats, | 1103 | | |GA27-3136-20 , | 1104 | | |without the flag | 1105 | | |fields, zero-bit | 1106 | | |insertion, or Frame | 1107 | | |Check Sequence | 1108 | | |field, containing | 1109 | | |SNA path information| 1110 | | |units (PIUs) as the | 1111 | | |payload. | 1112 +-------------------------------------+--------+--------------------+ 1113 | LINKTYPE_LORATAP | 270 |LoRaTap pseudo- | 1114 | | |header , followed by| 1115 | | |the payload, which | 1116 | | |is typically the | 1117 | | |PHYPayload from the | 1118 | | |LoRaWan | 1119 | | |specification | 1120 +-------------------------------------+--------+--------------------+ 1121 | LINKTYPE_VSOCK | 271 |Protocol for | 1122 | | |communication | 1123 | | |between host and | 1124 | | |guest machines in | 1125 | | |VMware and KVM | 1126 | | |hypervisors. | 1127 +-------------------------------------+--------+--------------------+ 1128 | LINKTYPE_NORDIC_BLE | 272 |Messages to and from| 1129 | | |a Nordic | 1130 | | |Semiconductor nRF | 1131 | | |Sniffer for | 1132 | | |Bluetooth LE | 1133 | | |packets, beginning | 1134 | | |with a pseudo-header| 1135 +-------------------------------------+--------+--------------------+ 1136 | LINKTYPE_DOCSIS31_XRA31 | 273 |DOCSIS packets and | 1137 | | |bursts, preceded by | 1138 | | |a pseudo-header | 1139 | | |giving metadata | 1140 | | |about the packet | 1141 +-------------------------------------+--------+--------------------+ 1142 | LINKTYPE_ETHERNET_MPACKET | 274 |mPackets, as | 1143 | | |specified by IEEE | 1144 | | |802.3br Figure 99-4,| 1145 | | |starting with the | 1146 | | |preamble and always | 1147 | | |ending with a CRC | 1148 | | |field. | 1149 +-------------------------------------+--------+--------------------+ 1150 | LINKTYPE_DISPLAYPORT_AUX | 275 |DisplayPort AUX | 1151 | | |channel monitoring | 1152 | | |data as specified by| 1153 | | |VESA DisplayPort(DP)| 1154 | | |Standard preceded by| 1155 | | |a pseudo-header | 1156 +-------------------------------------+--------+--------------------+ 1157 | LINKTYPE_LINUX_SLL2 | 276 |Linux cooked capture| 1158 | | |encapsulation v2 | 1159 +-------------------------------------+--------+--------------------+ 1160 | LINKTYPE_OPENVIZSLA | 278 |Openvizsla FPGA- | 1161 | | |based USB sniffer | 1162 +-------------------------------------+--------+--------------------+ 1163 | LINKTYPE_EBHSCR | 279 |Elektrobit High | 1164 | | |Speed Capture and | 1165 | | |Replay (EBHSCR) | 1166 | | |format | 1167 +-------------------------------------+--------+--------------------+ 1168 | LINKTYPE_VPP_DISPATCH | 280 |Records in traces | 1169 | | |from the | 1170 | | |http://fd.io VPP | 1171 | | |graph dispatch | 1172 | | |tracer, in the the | 1173 | | |graph dispatcher | 1174 | | |trace format | 1175 +-------------------------------------+--------+--------------------+ 1176 | LINKTYPE_DSA_TAG_BRCM | 281 |Ethernet frames, | 1177 | | |with a switch tag | 1178 | | |inserted between the| 1179 | | |source address field| 1180 | | |and the type/length | 1181 | | |field in the | 1182 | | |Ethernet header. | 1183 +-------------------------------------+--------+--------------------+ 1184 | LINKTYPE_DSA_TAG_BRCM_PREPEND | 282 |Ethernet frames, | 1185 | | |with a switch tag | 1186 | | |inserted before the | 1187 | | |destination address | 1188 | | |in the Ethernet | 1189 | | |header. | 1190 +-------------------------------------+--------+--------------------+ 1191 | LINKTYPE_IEEE802_15_4_TAP | 283 |IEEE 802.15.4 Low- | 1192 | | |Rate Wireless | 1193 | | |Networks, with a | 1194 | | |pseudo-header | 1195 | | |containing TLVs with| 1196 | | |metadata preceding | 1197 | | |the 802.15.4 header.| 1198 +-------------------------------------+--------+--------------------+ 1199 | LINKTYPE_DSA_TAG_DSA | 284 |Ethernet frames, | 1200 | | |with a switch tag | 1201 | | |inserted between the| 1202 | | |source address field| 1203 | | |and the type/length | 1204 | | |field in the | 1205 | | |Ethernet header. | 1206 +-------------------------------------+--------+--------------------+ 1207 | LINKTYPE_DSA_TAG_EDSA | 285 |Ethernet frames, | 1208 | | |with a programmable | 1209 | | |Ethernet type switch| 1210 | | |tag inserted between| 1211 | | |the source address | 1212 | | |field and the type/ | 1213 | | |length field in the | 1214 | | |Ethernet header. | 1215 +-------------------------------------+--------+--------------------+ 1216 | LINKTYPE_ELEE | 286 |Payload of lawful | 1217 | | |intercept packets | 1218 | | |using the ELEE | 1219 | | |protocol The packet | 1220 | | |begins with the ELEE| 1221 | | |header; it does not | 1222 | | |include any | 1223 | | |transport-layer or | 1224 | | |lower-layer headers | 1225 | | |for protcols used to| 1226 | | |transport ELEE | 1227 | | |packets. | 1228 +-------------------------------------+--------+--------------------+ 1229 | LINKTYPE_Z_WAVE_SERIAL | 287 |Serial frames | 1230 | | |transmitted between | 1231 | | |a host and a Z-Wave | 1232 | | |chip over an RS-232 | 1233 | | |or USB serial | 1234 | | |connection, as | 1235 | | |described in section| 1236 | | |5 of the Z-Wave | 1237 | | |Serial API Host | 1238 | | |Application | 1239 | | |Programming Guide | 1240 +-------------------------------------+--------+--------------------+ 1241 | LINKTYPE_USB_2_0 | 288 |USB 2.0, 1.1, or 1.0| 1242 | | |packet, beginning | 1243 | | |with a PID, as | 1244 | | |described by Chapter| 1245 | | |8 Protocol Layer of | 1246 | | |the the Universal | 1247 | | |Serial Bus | 1248 | | |Specification | 1249 | | |Revision 2.0 | 1250 +-------------------------------------+--------+--------------------+ 1251 | LINKTYPE_ATSC_ALP | 289 |ATSC Link-Layer | 1252 | | |Protocol frames, as | 1253 | | |described in section| 1254 | | |5 of the A/330 Link-| 1255 | | |Layer Protocol | 1256 | | |specification, found| 1257 | | |at the ATSC 3.0 | 1258 | | |standards page , | 1259 | | |beginning with a | 1260 | | |Base Header | 1261 +-------------------------------------+--------+--------------------+ 1262 Table 1 1264 9. Contributors 1266 [Insert pcap developers etc. here]. 1268 10. Acknowledgments 1270 The authors wish to thank [insert list here] and many others for 1271 their invaluable comments. 1273 11. References 1275 11.1. Normative References 1277 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1278 Requirement Levels", BCP 14, RFC 2119, 1279 DOI 10.17487/RFC2119, March 1997, 1280 . 1282 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 1283 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 1284 May 2017, . 1286 11.2. Informative References 1288 [I-D.tuexen-opsawg-pcapng] 1289 Tuexen, M., Risso, F., Bongertz, J., Combs, G., Harris, 1290 G., and M. Richardson, "PCAP Next Generation (pcapng) 1291 Capture File Format", Work in Progress, Internet-Draft, 1292 draft-tuexen-opsawg-pcapng-02, 28 September 2020, 1293 . 1296 [RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for 1297 Writing an IANA Considerations Section in RFCs", BCP 26, 1298 RFC 8126, DOI 10.17487/RFC8126, June 2017, 1299 . 1301 Authors' Addresses 1303 Guy Harris (editor) 1305 Email: gharris@sonic.net 1306 Michael C. Richardson 1307 Sandelman Software Works Inc 1309 Email: mcr+ietf@sandelman.ca 1310 URI: http://www.sandelman.ca/