| Internet-Draft | +pcap | +July 2023 | +
| Harris & Richardson | +Expires 24 January 2024 | +[Page] | +
This document describes the format used by the libpcap library to +record captured packets to a file. Programs using the libpcap +library to read and write those files, and thus reading and writing +files in that format, include tcpdump.¶
+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-pcap/.¶
++ 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 24 January 2024.¶
++ Copyright (c) 2023 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 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.¶
+This document describes the format used by tcpdump, and other +programs using libpcap, to read and write network traces.¶
+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 [RFC2119] [RFC8174] when, and only when, they +appear in all capitals, as shown here.¶
+A capture file begins with a File Header, followed by zero or more +Packet Records, one per packet.¶
+All fields in the File Header and in the headers of Packet Records will +always be written according to the characteristics (little endian / big +endian) of the machine that is writing the file. This refers to all the +fields that are written as numbers and that span over two or more +octets.¶
+The approach of having the file written in the native format of the host +writing the file is more efficient because it avoids translation of data +when writing the file or reading the file on the host that wrote the +file, which is the most common case when generating or processing +capture captures.¶
+The File Header has the following format, with the octet offset of +fields shown to the left of the field:¶
++ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + 0 | Magic Number | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + 4 | Major Version | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + 6 | Minor Version | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + 8 | Reserved1 | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + 12 | Reserved2 | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + 16 | SnapLen | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + 20 | LinkType and additional information | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ++
The File Header length is 24 octets.¶
+The meaning of the fields in the File Header is:¶
+an unsigned magic number, whose value is either the hexadecimal number +0xA1B2C3D4 or the hexadecimal number 0xA1B23C4D.¶
+If the value is 0xA1B2C3D4, time stamps in Packet Records (see Figure +2) are in seconds and microseconds; if it is 0xA1B23C4D, time stamps in +Packet Records are in seconds and nanoseconds.¶
+These numbers can be used to distinguish sessions that have been +written on little-endian machines from the ones written on big-endian +machines, and to heuristically identify pcap files.¶
+an unsigned value, giving the number of the current major version of +the format. The value for the current version of the format is 2. This +value should change if the format changes in such a way that code that +reads the new format could not read the old format (i.e., code to read +both formats would have to check the version number and use different +code paths for the two formats) and code that reads the old format could +not read the new format.¶
+an unsigned value, giving the number of the current minor version of +the format. The value is for the current version of the format is 4. +This value should change if the format changes in such a way that code +that reads the new format could read the old format without checking the +version number but code that reads the old format could not read all +files in the new format.¶
+not used - SHOULD be filled with 0 by pcap file writers, and MUST be +ignored by pcap file readers. This value was documented by some older +implementations as "gmt to local correction" or "time zone offset". +Some older pcap file writers stored non-zero values in this field.¶
+not used - SHOULD be filled with 0 by pcap file writers, and MUST be +ignored by pcap file readers. This value was documented by some older +implementations as "accuracy of timestamps". Some older pcap file +writers stored non-zero values in this field.¶
+an unsigned value indicating the maximum number of octets captured +from each packet. The portion of each packet that exceeds this value +will not be stored in the file. This value MUST NOT be zero; if no +limit was specified, the value should be a number greater than or equal +to the largest packet length in the file.¶
+a 32-bit unsigned value that contains the link-layer type of packets +in the file and may contain additional information.¶
+The LinkType and additional information field is in the form¶
++ 1 2 3 + 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 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + |FCS len|R|P| Reserved3 | Link-layer type | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ++
The field is shown as if it were in the byte order of the host reading +or writing the file, with bit 0 being the most-significant bit of the +field and bit 31 being the least-significant bit of the field.¶
+a 16-bit value indicating link-layer type for packets in the file; +it is a value as defined in the PCAP LinkType list registry, as defined in [I-D.ietf-opsawg-pcaplinktype].¶
+not used - MUST be set to zero by pcap writers, and MUST NOT be +interpreted by pcap readers; a reader SHOULD treat a non-zero value as +an error.¶
+a bit that, if set, indicates that the Frame Check Sequence (FCS) +length value is present and, if not set, indicates that the FCS value is +not present.¶
+not used - MUST be set to zero by pcap writers, and MUST NOT be +interpreted by pcap readers; a reader SHOULD treat a non-zero value as +an error.¶
+a 4-bit unsigned value indicating the number of 16-bit (2-octet) words +of FCS that are appended to each packet, if the P bit is set; if the P +bit is not set, and the FCS length is not indicated by the link-layer +type value, the FCS length is unknown. The valid values of the FCS len +field are between 0 and 15; Ethernet, for example, would have an FCS +length value of 2, corresponding to a 4-octet FCS.¶
+A Packet Record is the standard container for storing the packets +coming from the network.¶
++ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + 0 | Timestamp (Seconds) | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + 4 | Timestamp (Microseconds or nanoseconds) | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + 8 | Captured Packet Length | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + 12 | Original Packet Length | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + 16 / / + / Packet Data / + / variable length, not padded / + / / ++
The Packet Record begins with a 16-octet header, followed by data from +the packet.¶
+The meaning of the fields in the Packet Record is:¶
+seconds and fraction of a seconds values of a timestamp.¶
+The seconds value is a 32-bit unsigned integer that represents the +number of seconds that have elapsed since 1970-01-01 00:00:00 UTC, and +the microseconds or nanoseconds value represents the number of +microseconds or nanoseconds that have elapsed since that seconds.¶
+Whether the value represents microseconds or nanoseconds is specified +by the magic number in the File Header.¶
+an unsigned value that indicates the number of octets captured from +the packet (i.e. the length of the Packet Data field). It will be the +minimum value among the Original Packet Length and the snapshot length +for the interface (SnapLen, defined in Figure 1).¶
+an unsigned value that indicates the actual length of the packet when +it was transmitted on the network. It can be different from the +Captured Packet Length if the packet has been truncated by the capture +process; it SHOULD NOT be less than the Captured Packet Length.¶
+A pcap file writer MAY write an Original Packet Length that is less +than the Captured Packet Length if both the Captured Packet Length and +the Original Packet length came from a file in which a packet had an +Original Packet Length less than the Captured Packet Length; otherwise, +it MUST write an Original Packet Length that is greater than or equal to +the Captured Packet Length.¶
+A pcap file reader MAY convert an Original +Packet Length that is less than the Captured Packet Length to a value +that is greater than or equal to the Captured Packet Length.¶
+the data coming from the network, including link-layer headers. The +actual length of this field is Captured Packet Length. The format of +the link-layer headers depends on the LinkType field specified in the +file header (see Figure 1) and it is specified in [I-D.ietf-opsawg-pcaplinktype].¶
+Packet Records are not padded to a 4-octet boundary; if the number of +octets of packet data is not a multiple of 4, there are no padding +octets following it, so Packet Records are not guaranteed to begin on a +4-octet boundary within a file.¶
+The recommended file name extension for the "PCAP Capture File Format" +specified in this document is ".pcap".¶
+On Windows and macOS, files are distinguished by an extension to their +filename. Such an extension is technically not actually required, as +applications should be able to automatically detect the pcap file format +through the "magic bytes" at the beginning of the file, as some other +UN*X desktop environments do. However, using name extensions makes it +easier to work with files (e.g. visually distinguish file formats) so +it is recommended - though not required - to use .pcap as the name +extension for files following this specification.¶
+Please note: To avoid confusion (such as the current usage of .cap for a +plethora of different capture file formats) file name extensions other +than .pcap should be avoided.¶
+There is new work to create the PCAP Next Generation capture File Format +(see [I-D.ietf-opsawg-pcapng]). The new file format is not +compatible with this specification, but many programs read both +transparently. Files of that type will usually start with a Section +Header Block, with a magic number of 0x0A0D0D0A.¶
+TBD.¶
+This document requires the following IANA actions:¶
+This section registers the 'application/pcap' in the "Media Types" +registry. These media types are used to indicate that the content is +packet capture as described in this document.¶
++ Type name: application + Subtype name: pcap + Required parameters: none + Optional parameters: none + Encoding considerations: PCAP files contain network packets + Security considerations: See Security Considerations, Section + Interoperability considerations: The format is designed to be broadly interoperable. + Published specification: THIS RFC. + Applications that use this media type: tcpdump, wireshark, others. + Additional information: + Magic number(s): 0xA1B2C3D4, and 0xA1B23C4D in both endian orders + File extension(s): .pcap + Macintosh file type code(s): none + Person & email address to contact for further information: The Tcpdump Group, www.tcpdump.org + Intended usage: LIMITED + Restrictions on usage: NONE + Author: Guy Harris and Michael Richardson + Change controller: The Tcpdump Group + Provisional registration? (standards tree only): NO +¶ +
Insert pcap developers etc. here¶
+The authors wish to thank (many reviewers) and many others for +their invaluable comments.¶
+| Internet-Draft | +pcaplinktype | +July 2023 | +
| Harris & Richardson | +Expires 24 January 2024 | +[Page] | +
This document creates a 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.¶
+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 24 January 2024.¶
++ Copyright (c) 2023 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 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 meta data and layer 2 encapsulation of the packet.¶
+This document creates a registry for the LINKTYPE format, establishing the IANA +Considerations by which other uses of the pcap and pcapng formats may register new +formats.¶
+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 [RFC2119] [RFC8174] when, and only when, they +appear in all capitals, as shown here.¶
+This document requires the following IANA actions:¶
+IANA is requested to create a new Registry entitled: "The PCAP Registry", +and within that Registry to create a table called: "PCAP LinkType List".¶
+The LinkType Registry is a table of 16-bit numbers. +The Registry has three sections with different [RFC8126] rules:¶
+The Registry has four columns: the symbolic name (LINKTYPE_something), +the integer value, a very short description, and the document/requestor +reference.¶
+The Registry shall be populated as follows in the table below. In each +case here, the reference should be to +http://www.tcpdump.org/linktypes.html, which is not repeated each time.¶
+The initial value of table is base upon the Link type list maintained by +libpcap, and published on the tcpdump.org web site as +http://www.tcpdump.org/linktypes.html.¶
+Note that historically, values were assigned incrementally on First-Come/First-Served basis, with a preference for a public specification, but with no mandate. +Some historical values may have less specification than desired.¶
+There is often an associated DLT value which are 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.¶
+| LINKTYPE name | +LINKTYPE value | +description | +
|---|---|---|
| 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, w/LINKTYPE_SLIP header. | +
| LINKTYPE_PPP | +9 | +PPP, as per RFC 1661/RFC 1662 | +
| 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, as per RFC 1662 | +
| LINKTYPE_PPP_ETHER | +51 | +PPPoE; per RFC 2516 | +
| not to be used | +52-98 | +Do not use these values | +
| LINKTYPE_SYMANTEC_FIREWALL | +99 | +Reserved for Symantec Enterprise Firewall | +
| LINKTYPE_ATM_RFC1483 | +100 | +RFC 1483 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, as per section 4.3.1 of RFC 1547 | +
| 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 | +RFC 2625 IP-over-Fibre Channel | +
| LINKTYPE_SUNATM | +123 | +ATM traffic, / per SunATM devices | +
| 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[Radiotap], 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 ITU-T Q.703 | +
| LINKTYPE_MTP2 | +140 | +SS7 Level 2, Q.703 | +
| LINKTYPE_MTP3 | +141 | +SS7 Level 3, Q.704 | +
| LINKTYPE_SCCP | +142 | +SS7 Control Part, ITU-T Q.711/Q.712/Q.713/Q.714 | +
| LINKTYPE_DOCSIS | +143 | +DOCSIS MAC frames, DOCSIS 3.1 | +
| LINKTYPE_LINUX_IRDA | +144 | +Linux-IrDA packets w/LINKTYPE_LINUX_IRDA header | +
| 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 | +
| LINKTYPE_RESERVED_02 | +148 | +For private use | +
| LINKTYPE_RESERVED_03 | +149 | +For private use | +
| LINKTYPE_RESERVED_04 | +150 | +For private use | +
| LINKTYPE_RESERVED_05 | +151 | +For private use | +
| LINKTYPE_RESERVED_06 | +152 | +For private use | +
| LINKTYPE_RESERVED_07 | +153 | +For private use | +
| LINKTYPE_RESERVED_08 | +154 | +For private use | +
| LINKTYPE_RESERVED_09 | +155 | +For private use | +
| LINKTYPE_RESERVED_10 | +156 | +For private use | +
| LINKTYPE_RESERVED_11 | +157 | +For private use | +
| LINKTYPE_RESERVED_12 | +158 | +For private use | +
| LINKTYPE_RESERVED_13 | +159 | +For private use | +
| LINKTYPE_RESERVED_14 | +160 | +For private use | +
| LINKTYPE_RESERVED_15 | +161 | +For private use | +
| LINKTYPE_RESERVED_16 | +162 | +For private use | +
| LINKTYPE_IEEE802_11_AVS | +163 | +AVS header[AVS], followed by an 802.11 header | +
| LINKTYPE_JUNIPER_MONITOR | +164 | +Reserved for Juniper Networks | +
| LINKTYPE_BACNET_MS_TP | +165 | +BACnet MS/TP frames, per 9.3 MS/TP Frame Format ANSI 135 | +
| 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, as specified by ITU-T Recommendation G.7041/Y.1303 | +
| LINKTYPE_GPF_F | +171 | +Frame-mapped generic framing procedure, as specified by ITU-T Recommendation G.7041/Y.1303 | +
| 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 | +Link Access Procedures on the D Channel (LAPD) frames, as specified by ITU-T Recommendation Q.920 and ITU-T Recommendation Q.921 , captured via vISDN, with a LINKTYPE_LINUX_LAPD header , followed by the Q.921 frame, starting with the address field. | +
| 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_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 byte, 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 bytes 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 , for SITA | +
| LINKTYPE_ERF | +197 | +Various link-layer types, with a pseudo-header, for Endace DAG cards; encapsulates 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-byte 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-byte 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 byte, 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 1-byte KISS header containing a type indicator. | +
| LINKTYPE_LAPD | +203 | +Link Access Procedures on the D Channel (LAPD) frames, as specified by ITU-T Recommendation Q.920 and ITU-T Recommendation Q.921 , 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-byte 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 bytes are 0xff and 0x03, it's PPP in HDLC-like framing, with the PPP header following those two bytes, 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, as per section 4.3.1 of RFC 1547 , preceded with a one-byte 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-byte 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-byte 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_IPMB_LINUX | +209 | +IPMB over an I2C circuit, with a Linux-specific pseudo-header | +
| LINKTYPE_FLEXRAY | +210 | +Reserved for FlexRay automotive bus | +
| LINKTYPE_MOST | +211 | +Reserved for Media Oriented Systems Transport (MOST) bus | +
| LINKTYPE_LIN | +212 | +Reserved for Local Interconnect Network (LIN) bus for vehicle networks | +
| 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 bytes 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-byte sequences representing the corresponding ordered sets, with K28.5 represented as 0xBC, and the D symbols as the corresponding byte 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 pseudo-header , followed by an IPv4 or IPv6 datagram. | +
| LINKTYPE_CAN_SOCKETCAN | +227 | +CAN (Controller Area Network) frames, with a pseudo-header followed by the frame payload. | +
| 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 (DVB Common Interface for communication between a PC Card module and a DVB receiver), with the message format specified by the PCAP format for DVB-CI specification | +
| LINKTYPE_MUX27010 | +236 | +Variant of 3GPP TS 27.010 multiplexing protocol (similar to, but not the same as, 27.010). | +
| 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 | +Pseudo-header for Hilscher Gesellschaft fuer Systemautomation mbH netANALYZER devices , followed by an Ethernet frame, beginning with the MAC header and ending with the FCS. | +
| LINKTYPE_NETANALYZER_TRANSPARENT | +241 | +Pseudo-header for Hilscher Gesellschaft fuer Systemautomation mbH netANALYZER devices , followed by an Ethernet frame, beginning with the preamble, SFD, and MAC header, and ending with the FCS. | +
| LINKTYPE_IPOIB | +242 | +IP-over-InfiniBand, as specified by RFC 4391 section 6 | +
| LINKTYPE_MPEG_2_TS | +243 | +MPEG-2 Transport Stream transport packets, as specified by ISO 13818-1/ ITU-T Recommendation H.222.0 (see table 2-2 of section 2.4.3.2 Transport Stream packet layer). | +
| LINKTYPE_NG40 | +244 | +Pseudo-header for ng4T GmbH's UMTS Iub/Iur-over-ATM and Iub/Iur-over-IP format as used by their ng40 protocol tester , followed by frames for the Frame Protocol as specified by 3GPP TS 25.427 for dedicated channels and 3GPP TS 25.435 for common/shared channels in the case of ATM AAL2 or UDP traffic, by SSCOP packets as specified by ITU-T Recommendation Q.2110 for ATM AAL5 traffic, and by NBAP packets for SCTP traffic. | +
| LINKTYPE_NFC_LLCP | +245 | +Pseudo-header for NFC LLCP packet captures , followed by frame data for the LLCP Protocol as specified by NFCForum-TS-LLCP_1.1 | +
| 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[TM] 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 header for the Schweitzer Engineering Laboratories RTAC product , followed by a payload for one of a number of industrial control protocols. | +
| 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 encapsulation of traffic for the BlueZ stack | +
| 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 time stamps for packets in this format must match the time stamps in the Trace Data Blocks. | +
| LINKTYPE_ZWAVE_R1_R2 | +261 | +Z-Wave RF profile R1 and R2 packets , as specified by ITU-T Recommendation G.9959 , with some MAC layer fields moved. | +
| LINKTYPE_ZWAVE_R3 | +262 | +Z-Wave RF profile R3 packets , as specified by ITU-T Recommendation G.9959 , with some MAC layer fields moved. | +
| LINKTYPE_WATTSTOPPER_DLM | +263 | +Formats for WattStopper Digital Lighting Management (DLM) and Legrand Nitoo Open protocol common packet structure captures. | +
| LINKTYPE_ISO_14443 | +264 | +Messages between ISO 14443 contactless smartcards (Proximity Integrated Circuit Card, PICC) and card readers (Proximity Coupling Device, PCD), with the message format specified by the PCAP format for ISO14443 specification | +
| LINKTYPE_RDS | +265 | +Radio data system (RDS) groups, as per IEC 62106, encapsulated in this form | +
| LINKTYPE_USB_DARWIN | +266 | +USB packets, beginning with a Darwin (macOS, etc.) USB header | +
| 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, beginning with a pseudo-header | +
| LINKTYPE_DOCSIS31_XRA31 | +273 | +DOCSIS packets and bursts, preceded by a pseudo-header giving metadata about the packet | +
| 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 data as specified by VESA DisplayPort(DP) Standard preceded by a pseudo-header | +
| 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 | +Records in traces from the http://fd.io VPP graph dispatch tracer, in the graph dispatcher trace format | +
| LINKTYPE_DSA_TAG_BRCM | +281 | +Ethernet frames, with a switch tag inserted between the source address field and the type/length field in the Ethernet header. | +
| LINKTYPE_DSA_TAG_BRCM_PREPEND | +282 | +Ethernet frames, with a switch tag inserted before the destination address in the Ethernet header. | +
| 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 switch tag inserted between the source address field and the type/length field in the Ethernet header. | +
| LINKTYPE_DSA_TAG_EDSA | +285 | +Ethernet frames, with a programmable Ethernet type switch tag inserted between the source address field and the type/length field in the Ethernet header. | +
| 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, as described in section 5 of the Z-Wave Serial API Host Application Programming Guide | +
| 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 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 the ATSC 3.0 standards page , beginning with a Base Header | +
Insert pcap developers etc. here¶
+The authors wish to thank (many reviewers) and many others for +their invaluable comments.¶
+| Internet-Draft | +pcapng | +July 2023 | +
| Tuexen, et al. | +Expires 24 January 2024 | +[Page] | +
This document describes a format to record captured packets to a +file. This format is extensible; Wireshark can currently read and write +it, and libpcap can currently read some pcapng files.¶
+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-pcapng/.¶
++ 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 24 January 2024.¶
++ Copyright (c) 2023 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.¶
+The problem of exchanging packet traces becomes more and more +critical every day; unfortunately, no standard solutions exist for +this task right now. One of the most accepted packet interchange +formats is the one defined by libpcap, which is rather old and is +lacking in functionality for more modern applications particularly +from the extensibility point of view.¶
+This document proposes a new format for recording packet traces. The +following goals are being pursued:¶
+It should be possible to add new standard capabilities to the file +format over time, and third parties should be able to enrich the +information embedded in the file with proprietary extensions, with +tools unaware of newer extensions being able to ignore them.¶
+A capture trace must contain all the information needed to read data +independently from network, hardware and operating system of the +machine that made the capture.¶
+It should be possible to add data at the end of a given file, and +the resulting file must still be readable.¶
+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 [RFC2119] [RFC8174] when, and only when, they +appear in all capitals, as shown here.¶
+ +A capture file is organized in blocks, that are appended one to +another to form the file. All the blocks share a common format, which +is shown in Figure 1.¶
++ 1 2 3 + 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 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + 0 | Block Type | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + 4 | Block Total Length | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + 8 / Block Body / + / variable length, padded to 32 bits / + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Block Total Length | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ++
The fields have the following meaning:¶
+This structure, shared among all blocks, makes it easy to process a +file and to skip unneeded or unknown blocks. Some blocks can contain +other blocks inside (nested blocks). Some of the blocks are mandatory, +i.e. a capture file is not valid if they are not present, other are +optional.¶
+The General Block Structure allows defining other blocks if needed. +A parser that does not understand them can simply ignore their +content.¶
+The currently standardized Block Type codes are specified in Section 10.1; they have been grouped in the +following four categories:¶
+(1) Mandatory: The following block MUST appear at least once in each file:¶
+(2) Optional: The following blocks MAY appear in a file:¶
+(3) Obsolete: The following block SHOULD NOT appear in newly written +files (but is documented in the Appendix for reference):¶
+(4) Experimental: The following blocks are considered interesting but +the authors believe that they deserve more in-depth discussion before +being defined:¶
+Requests for new standardized Block Type codes should be made by +creating a pull request to update this document as described in +Section 10.1.¶
+The blocks build a logical hierarchy as they refer to each other. Figure 2 shows the logical hierarchy of the +currently defined blocks in the form of a "tree view":¶
++Section Header +| ++- Interface Description +| +- Simple Packet +| +- Enhanced Packet +| +- Interface Statistics +| ++- Name Resolution ++
For example: each captured packet refers to a specific capture +interface, the interface itself refers to a specific section.¶
+The file MUST begin with a Section Header Block. However, more than +one Section Header Block can be present in the capture file, each one +covering the data following it until the next one (or the end of +file). A Section includes the data delimited by two Section Header +Blocks (or by a Section Header Block and the end of the file), +including the first Section Header Block.¶
+In case an application cannot read a Section because of different +version number, it MUST skip everything until the next Section Header +Block. Note that, in order to properly skip the blocks until the next +section, all blocks MUST have the fields Type and Length at the +beginning. In order to properly skip blocks in the backward direction, +all blocks MUST have the Length repeated at the end of the block. +These are mandatory requirements that MUST be maintained in future +versions of the block format.¶
+Figure 3 shows a typical file layout, with a +single Section Header that covers the whole file.¶
+++-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +| SHB v1.0 | Data | ++-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ++
Figure 4 shows a file that contains three headers, and is normally the result +of file concatenation. An application that understands only version +1.0 of the file format skips the intermediate section and restart +processing the packets after the third Section Header.¶
++|-- 1st Section --|-- 2nd Section --|-- 3rd Section --| +| | ++-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +| SHB v1.0 | Data | SHB V1.1 | Data | SHB V1.0 | Data | ++-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ++
Figure 5 shows a file comparable to a "classic libpcap" file - the minimum for +a useful capture file. It contains a single Section Header Block +(SHB), a single Interface Description Block (IDB) and a few Enhanced +Packet Blocks (EPB).¶
+++-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +| SHB | IDB | EPB | EPB | ... | EPB | ++-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ++
Figure 6 shows a complex example file. In addition to the minimum file above, +it contains packets captured from three interfaces, capturing on the +third of which begins after packets have arrived on other interfaces, +and also includes some Name Resolution Blocks (NRB) and an Interface +Statistics Block (ISB).¶
+++-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +| SHB | IDB | IDB | EPB | NRB |...| IDB | EPB | ISB | NRB | EPB | ++-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ++
The last example should make it obvious that the block structure +makes the file format very flexible compared to the classical libpcap +format.¶
+All the block bodies MAY embed optional fields. +Optional fields can be used to insert some information that may be +useful when reading data, but that is not really needed for packet +processing. Therefore, each tool can either read the content of the +optional fields (if any), or skip some of them or even all at +once.¶
+A block that may contain options must be structured so that +the number of octets of data in the Block Body that precede the +options can be determined from that data; that allows the +beginning of the options to be found. That is true for all +standard blocks that support options; for Custom Blocks that +support options, the Custom Data must be structured in such a +fashion. This means that the Block Length field (present in +the General Block Structure, see Section 3.1) can be used to determine how +many octets of optional fields, if any, are present in the block. +That number can be used to determine whether the block has +optional fields (if it is zero, there are no optional fields), +to check, when processing optional fields, whether any optional +fields remain, and to skip all the optional fields at once.¶
+Options are a list of Type - Length - Value fields, each one +containing a single value:¶
+Requests for new standardized option codes for a given block +should be made by creating a pull request to update this document +as described in Section 10.1.¶
+A given option may have a fixed length, in which case all +instances of that option have a length that is equal to the +specified fixed length, or a variable length, in which case +the option has a minimum length and all instances of that +option must have a length equal to or greater than the specified +minimum length. The length of fixed-length options, and the +minimum length of variable-length options, is specified in the +description of the option; if the minimum length of a +variable-length option is not specified, a zero-length option is +valid. Software that reads these files SHOULD report options +that have an invalid length as errors; the software MAY stop +processing the file if it sees an option that has invalid +length, or MAY ignore the option and continue processing it. +Software that writes these files MUST NOT write files with +options that have invalid lengths.¶
+If an option's value is a string, the value is not necessarily +zero-terminated. Software that reads these files MUST NOT assume that +strings are zero-terminated, and MUST treat a zero-value octet as a +string terminator.¶
+Some options may be repeated several times; for example, a +block can have multiple comments, and an Interface Description +Block can give multiple IPv4 or IPv6 addresses for the +interface if it has multiple IPv4 or IPv6 addresses assigned to +it. Other options may appear at most once in a given block.¶
+The option list is terminated by an option which uses the +special 'End of Option' code (opt_endofopt). Code that +writes pcapng files MUST put an opt_endofopt option at the end +of an option list. Code that reads pcapng files MUST NOT assume +an option list will have an opt_endofopt option at the end; it +MUST also check for the end of the block, and SHOULD treat +blocks where the option list has no opt_endofopt option as if +the option list had an opt_endofopt option at the end.¶
+The format of the optional fields is shown in Figure 7.¶
++ 1 2 3 + 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 ++-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +| Option Type | Option Length | ++-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +/ Option Value / +/ variable length, padded to 32 bits / ++-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +/ / +/ . . . other options . . . / +/ / ++-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +| Option Type == opt_endofopt | Option Length == 0 | ++-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ++
The following codes can always be present in any optional field:¶
+| Name | +Type | +Length | +Multiple allowed? | +
|---|---|---|---|
| opt_endofopt | +0 | +0 | +no | +
| opt_comment | +1 | +variable | +yes | +
| opt_custom | +2988/2989/19372/19373 | +variable, minimum 4 | +yes | +
The +opt_endofopt option delimits the end of the optional fields. This +option MUST NOT be repeated within a given list of options.¶
+The +opt_comment option is a UTF-8 string containing human-readable +comment text that is associated to the current block. Line +separators SHOULD be a carriage-return + linefeed ('\r\n') or just +linefeed ('\n'); either form may appear and be considered a line +separator. The string is not zero-terminated.¶
+Examples: "This packet is the beginning of all of our +problems", "Packets 17-23 showing a bogus TCP retransmission!\r\n +This is reported in bugzilla entry 1486.\nIt will be fixed in the +future.".¶
+This option is +described in detail in Section 3.5.1.¶
+Customs Options are used for portable, vendor-specific data +related to the block they're in. A Custom Option can be in any block +type that can have options, can be repeated any number of times in a +block, and may come before or after other option types - except the +opt_endofopt option, which is always the last option. Different Custom +Options, of different type codes and/or different Private Enterprise +Numbers, may be used in the same pcapng file. See Section 5 for additional details.¶
++ 1 2 3 + 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 ++-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +| Custom Option Type | Option Length | ++-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +| Private Enterprise Number (PEN) | ++-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +/ Custom Data / +/ variable length, padded to 32 bits / ++-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ++
The Custom Option has the following fields:¶
+Custom Option Type: The type code number for the Custom Option, which +can be one of the following decimal numbers:¶
+This option type code +identifies a Custom Option containing a UTF-8 string in the +Custom Data portion. The string is not zero-terminated. + This Custom Option can be safely copied to a new file if +the pcapng file is manipulated by an application; otherwise +19372 should be used instead. See Section 5.2 for details.¶
+This option type code +identifies a Custom Option containing binary octets in the +Custom Data portion. This Custom Option can be safely copied +to a new file if the pcapng file is manipulated by an +application; otherwise 19372 should be used instead. See Section 5.2 for details.¶
+This option type code +identifies a Custom Option containing a UTF-8 string in the +Custom Data portion. The string is not zero-terminated. +This Custom Option should not be copied to a new file if +the pcapng file is manipulated by an application. See Section 5.2 for details.¶
+This option type code +identifies a Custom Option containing binary octets in the +Custom Data portion. This Custom Option should not be copied +to a new file if the pcapng file is manipulated by an +application. See Section 5.2 for +details.¶
+Data contained in each section will always be saved according to +the characteristics (little endian / big endian) of the capturing +machine. This refers to all the fields that are saved as numbers and +that span over two or more octets.¶
+The approach of having each section saved in the native format of +the generating host is more efficient because it avoids translation +of data when reading / writing on the host itself, which is the most +common case when generating/processing capture captures.¶
+Please note: The endianness is indicated by the Section Header Block (Section 4.1). Since this block +can appear several times in a pcapng file, a single file can contain +both endianness variants.¶
+All fields of this specification use proper alignment for 16- +and 32-bit values. This makes it easier and faster to read/write +file contents if using techniques like memory mapped files.¶
+The alignment octets (marked in this document e.g. with "padded to +32 bits") MUST be filled with zeroes.¶
+Please note: 64-bit values are not aligned to 64-bit boundaries. +This is because the file is naturally aligned to 32-bit boundaries +only. Special care MUST be taken when reading and writing such +values. (Note also that some 64-bit values are represented as a +64-bit integer in the endianness of the machine that wrote the +file, and others are represented as 2 32-bit values, one +containing the upper 32 bits of the value and one containing +the lower 32 bits of the value, each written as 32-bit +integers in the endianness of the machine that wrote the file. +Neither of these formats guarantee 64-bit alignment.)¶
+If a string is specified as being encoded as UTF-8, software that reads +that string MUST NOT assume that the string's value is valid UTF-8, and +MAY discard a string that are is valid UTF-8 or MAY repair the string by +replacing invalid octet sequences with valid sequences such as the +sequence for a Unicode REPLACEMENT CHARACTER; software that writes that +string fields MUST write only a valid UTF-8 string.¶
+This section details the format of the blocks currently defined.¶
+The Section Header Block (SHB) is mandatory. It identifies the +beginning of a section of the capture file. The Section Header +Block does not contain data but it rather identifies a list of blocks +(interfaces, packets) that are logically correlated. Its format is +shown in Figure 9.¶
++ 1 2 3 + 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 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + 0 | Block Type = 0x0A0D0D0A | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + 4 | Block Total Length | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + 8 | Byte-Order Magic | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +12 | Major Version | Minor Version | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +16 | | + | Section Length | + | | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +24 / / + / Options (variable) / + / / + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Block Total Length | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ++
The meaning of the fields is:¶
+Block Type: The block type of the Section Header Block is the +integer corresponding to the 4-char string "\n\r\r\n" +(0x0A0D0D0A). This particular value is used for 2 reasons:¶
+Writers of pcapng files MUST NOT write SHBs with a Major Version other +than 1 or a Minor Version other than 0. If they do so, they will write +a file that many readers of pcapng files, such as programs using libpcap +to read pcapng files (including, but not limited to, tcpdump), +Wireshark, and possibly other programs not to be able to read their +files.¶
+Some pcapng file writers have used a minor version of 2, but the file +format did not change incompatibly (new block types were added); Readers +of pcapng files MUST treat a Minor Version of 2 as equivalent to a Minor +Version of 0 (and, if they also write a pcapng file based on the results +of reading one or more pcapng files, they MUST NOT, as per the previous +sentence, write an SHB with a Minor Version of 2, even if they read an +SHB with a Minor Version of 2). As indicated above, using a minor +version number other than 0 when writing a section of a pcapng file will +produce a section that most existing software will not be able to read; +future versions of some of that software will be able to read sections +with a version of 1.2, but older copies of that software that are not +updated to the latest version will still not be able to read them.¶
+The Major Version would be changed only if a new version of this +specification, for a later major version of the file format, were +created. Such a version would only be created if the format were to +change in such a way that code that reads the new format could not read +the old format (i.e., code to read both formats would have to check the +version number and use different code paths for the two formats) and +code that reads the old format could not read the new format. An +incompatible change to the format of an existing block or an existing +option would be such a change; the addition of a new block or a new +option would not be such a change. An example of such an incompatible +change would be the addition of an additional field to the Section +Header Block, following the Minor Version field and before the Snaplen +field; software expecting the new SHB format would not correctly read +the old SHB format, and software expecting the old SHB format would not +correctly read the new SHB format. (Note that a change to the SHB must +leave the Block Type, Block Total Length, Byte-Order Magic, Major +Version, and Minor Version fields at the same offsets from the beginning +of the SHB and with the same lengths, must keep the value of the Block +Type the same, must keep the two possible values of the Byte-Order +Magic the same, depending on the block's byte order, so that the rest of +the SHB can be correctly interpreted.)¶
+The Minor Version would be changed only if a new version of this +specification, for a later minor version of the file format, were +created. Such a version would only be created if the format were to +change in such a way that code that reads the new format could read the +old format without checking the version number but code that reads the +old format could not read all files in the new format. A +backward-compatible change to the format of an existing block or an +existing option would be such a change; the addition of a new block or +a new option would not be such a change. An example of such a +backward-compatible but not forward-compatible change would be a change +to the Interface Description block (see below) to use the current +Reserved field to indicate the presence of additional fields before the +Options, with a zero value indicate no such fields are present.¶
+I.e., adding new block types or options would not require that either +the Major Version or the Minor Version be changed, as code that does not +know about the block type or option should just skip it; only if +skipping a block or option does not work should the minor version number +be changed.¶
+Aside from the options defined in Section 3.5, the +following options are valid within this block:¶
+| Name | +Type | +Length | +Multiple allowed? | +
|---|---|---|---|
| shb_hardware | +2 | +variable | +no | +
| shb_os | +3 | +variable | +no | +
| shb_userappl | +4 | +variable | +no | +
The +shb_hardware option is a UTF-8 string containing the description +of the hardware used to create this section. The string is +not zero-terminated.¶
+Examples: "x86 Personal Computer", "Sun Sparc Workstation".¶
+The shb_os option +is a UTF-8 string containing the name of the operating system used +to create this section. The string is not zero-terminated.¶
+Examples: "Windows XP SP2", "openSUSE 10.2".¶
+The +shb_userappl option is a UTF-8 string containing the name of the +application used to create this section. The string is not +zero-terminated.¶
+Examples: "dumpcap V0.99.7".¶
+[Open issue: does a program which re-writes a capture file change +the original hardware/os/application info?]¶
+An Interface Description Block (IDB) is the container for +information describing an interface on which packet data is +captured.¶
+Tools that write / read the capture file associate an incrementing +unsigned 32-bit number (starting from '0') to each Interface +Definition Block, called the Interface ID for the interface in +question. This number is unique within each Section and +identifies the interface to which the IDB refers; it is only +unique inside the current section, so, two Sections can have +different interfaces identified by the same Interface ID values. +This unique identifier is referenced by other blocks, such as +Enhanced Packet Blocks and Interface Statistic Blocks, to +indicate the interface to which the block refers (such the +interface that was used to capture the packet that an Enhanced +Packet Block contains or to which the statistics in an Interface +Statistic Block refer).¶
+Within a section, there must be an Interface Description Block for each +interface to which another block within that section refers. Blocks +such as an Enhanced Packet Block or an Interface Statistics Block +contain an Interface ID value referring to a particular interface, and a +Simple Packet Block implicitly refers to an interface with an Interface +ID of 0. If the file does not contain any blocks that use an Interface +ID, then the file does not need to have any IDBs.¶
+There is no requirement that all Interface Description Blocks occur +within a section before all blocks of other types, as long as the +Interface Description Block for an interface occurs before any block +that refers to that interface.¶
+An Interface Description Block is valid only inside the section +to which it belongs. The structure of an Interface Description Block is +shown in Figure 10.¶
++ 1 2 3 + 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 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + 0 | Block Type = 0x00000001 | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + 4 | Block Total Length | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + 8 | LinkType | Reserved | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +12 | SnapLen | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +16 / / + / Options (variable) / + / / + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Block Total Length | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ++
The meaning of the fields is:¶
+In addition to the options defined in Section 3.5, +the following options are valid within this block:¶
+| Name | +Type | +Length | +Multiple allowed? | +
|---|---|---|---|
| if_name | +2 | +variable | +no | +
| if_description | +3 | +variable | +no | +
| if_IPv4addr | +4 | +8 | +yes | +
| if_IPv6addr | +5 | +17 | +yes | +
| if_MACaddr | +6 | +6 | +no | +
| if_EUIaddr | +7 | +8 | +no | +
| if_speed | +8 | +8 | +no | +
| if_tsresol | +9 | +1 | +no | +
| if_tzone | +10 | +4 | +no | +
| if_filter | +11 | +variable, minimum 1 | +no | +
| if_os | +12 | +variable | +no | +
| if_fcslen | +13 | +1 | +no | +
| if_tsoffset | +14 | +8 | +no | +
| if_hardware | +15 | +variable | +no | +
| if_txspeed | +16 | +8 | +no | +
| if_rxspeed | +17 | +8 | +no | +
The if_name option +is a UTF-8 string containing the name of the device used to +capture data. The string is not zero-terminated.¶
+Examples: "eth0", "\Device\NPF_{AD1CE675-96D0-47C5-ADD0-2504B9126B68}".¶
+The +if_description option is a UTF-8 string containing the description +of the device used to capture data. The string is not +zero-terminated.¶
+Examples: "Wi-Fi", "Local Area Connection", "Wireless +Network Connection", "First Ethernet Interface".¶
+The if_IPv4addr +option is an IPv4 network address and corresponding netmask for +the interface. The first four octets are the IP address, and +the next four octets are the netmask. This option can be repeated +multiple times within the same Interface Description Block when +multiple IPv4 addresses are assigned to the interface. Note that +the IP address and netmask are both treated as four octets, one +for each octet of the address or mask; they are not 32-bit +numbers, and thus the endianness of the SHB does not affect +this field's value.¶
+Examples: '192 168 1 1 255 255 255 0'.¶
+The +if_IPv6addr option is an IPv6 network address and corresponding +prefix length for the interface. The first 16 octets are the +IP address and the next octet is the prefix length. This option +can be repeated multiple times within the same Interface +Description Block when multiple IPv6 addresses are assigned to +the interface.¶
+Example: 2001:0db8:85a3:08d3:1319:8a2e:0370:7344/64 is written +(in hex) as '20 01 0d b8 85 a3 08 d3 13 19 8a 2e 03 70 73 44 +40'.¶
+The if_MACaddr +option is the Interface Hardware EUI-48 (MAC) address (48 bits), if +available.¶
+Example: '00 01 02 03 04 05'.¶
+The if_EUIaddr +option is the Interface Hardware EUI-64 address (64 bits), if +available.¶
+Example: '02 34 56 FF FE 78 9A BC'.¶
+The if_speed +option is a 64-bit unsigned value indicating the interface +speed, in bits per second.¶
+Example: the 64-bit decimal number 100000000 for 100Mbps.¶
+The if_tsresol +option identifies the resolution of timestamps. If the Most +Significant Bit is equal to zero, the remaining bits indicates the +resolution of the timestamp as a negative power of 10 (e.g. 6 +means microsecond resolution, timestamps are the number of +microseconds since 1970-01-01 00:00:00 UTC). If the Most +Significant Bit is equal to one, the remaining bits indicates +the resolution as negative power of 2 (e.g. 10 means 1/1024 +of second). If this option is not present, a resolution of +10^-6 is assumed (i.e. timestamps have the same resolution of +the standard 'libpcap' timestamps).¶
+Example: '6'.¶
+The if_tzone +option identifies the time zone for GMT support (TODO: specify +better).¶
+Example: TODO: give a good example.¶
+The if_filter +option identifies the filter (e.g. "capture only TCP traffic") +used to capture traffic. The first octet of the Option Data keeps a +code of the filter used (e.g. if this is a libpcap string, or BPF +bytecode, and more). More details about this format will be +presented in Appendix XXX (TODO). (TODO: better use different +options for different fields? e.g. if_filter_pcap, if_filter_bpf, +...)¶
+Example: '00'"tcp port 23 and host 192.0.2.5".¶
+The if_os option is +a UTF-8 string containing the name of the operating system of the +machine in which this interface is installed. This can be +different from the same information that can be contained by the +Section Header Block (Section 4.1) because the +capture can have been done on a remote machine. The string is +not zero-terminated.¶
+Examples: "Windows XP SP2", "openSUSE 10.2".¶
+The if_fcslen +option is an 8-bit unsigned integer value that specifies the +length of the Frame Check Sequence (in bits) for this interface. +For link layers whose FCS length can change during time, the +Enhanced Packet Block epb_flags Option can be used in each +Enhanced Packet Block (see Section 4.3.1).¶
+Example: '4'.¶
+The +if_tsoffset option is a 64-bit signed integer value that +specifies an offset (in seconds) that must be added to the +timestamp of each packet to obtain the absolute timestamp of +a packet. If the option is missing, the timestamps stored +in the packet MUST be considered absolute timestamps. The +time zone of the offset can be specified with the option +if_tzone. TODO: won't a if_tsoffset_low for fractional +second offsets be useful for highly synchronized capture +systems?¶
+Example: '1234'.¶
+The +if_hardware option is a UTF-8 string containing the description +of the interface hardware. The string is not zero-terminated.¶
+Examples: "Broadcom NetXtreme", "Intel(R) PRO/1000 MT +Network Connection", "NETGEAR WNA1000Mv2 N150 Wireless USB +Micro Adapter".¶
+The +if_txrxspeeds option is a 64-bit unsigned value +indicating the interface transmit speed in bits per +second.¶
+Example: the 64-bit decimal number 1024000 for +1024Kbps.¶
+The +if_rxspeed option is a 64-bit unsigned value +indicating the interface receive speed, in bits per +second.¶
+Example: the 64-bit decimal number 8192000 for +8192Kbps.¶
+If the interface transmit speed and receive speed are the +same, the if_speed option MUST be used and the if_txspeed and +if_rxspeed options MUST NOT be used. If the transmit speed is +unknown, the if_speed and if_txspeed options MUST NOT be used; +if the receive speed is unknown, the if_speed and if_rxspeed +options MUST NOT be used.¶
+An Enhanced Packet Block (EPB) is the standard container for +storing the packets coming from the network. The Enhanced Packet Block +is optional because packets can be stored either by means of this +block or the Simple Packet Block, which can be used to speed up +capture file generation; or a file may have no packets in it. The +format of an Enhanced Packet Block is shown in Figure 11.¶
+The Enhanced Packet Block is an improvement over the original, now +obsolete, Packet Block (Appendix A):¶
++ 1 2 3 + 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 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + 0 | Block Type = 0x00000006 | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + 4 | Block Total Length | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + 8 | Interface ID | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +12 | Timestamp (High) | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +16 | Timestamp (Low) | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +20 | Captured Packet Length | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +24 | Original Packet Length | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +28 / / + / Packet Data / + / variable length, padded to 32 bits / + / / + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + / / + / Options (variable) / + / / + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Block Total Length | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ++
The Enhanced Packet Block has the following fields:¶
+Original Packet Length (32 bits): an unsigned value that +indicates the actual length of the packet when it was +transmitted on the network. It can be different from +the Captured Packet Length if the packet has been truncated +by the capture process; it SHOULD NOT be less than the Captured Packet +Length.¶
++A pcapng file writer MAY write an Original Packet Length that is less +than the Captured Packet Length if both the Captured Packet Length and +the Original Packet length came from a file in which a packet had an +Original Packet Length less than the Captured Packet Length; +otherwise, it MUST write an Original Packet Length that is greater +than or equal to the Captured Packet Length.¶
++A pcapng file reader MAY convert an Original Packet Length that is +less than the Captured Packet Length to a value that is greater than +or equal to the Captured Packet Length.¶
+In addition to the options defined in Section 3.5, +the following options are valid within this block:¶
+| Name | +Type | +Length | +Multiple allowed? | +
|---|---|---|---|
| epb_flags | +2 | +4 | +no | +
| epb_hash | +3 | +variable, minimum hash type-dependent | +yes | +
| epb_dropcount | +4 | +8 | +no | +
| epb_packetid | +5 | +8 | +no | +
| epb_queue | +6 | +4 | +no | +
| epb_verdict | +7 | +variable, minimum verdict type-dependent | +yes | +
| epb_processid_threadid | +8 | +8 | +no | +
The epb_flags +option is a 32-bit flags word containing link-layer information. A +complete specification of the allowed flags can be found in Section 4.3.1.¶
+Example: '0'.¶
+The epb_hash +option contains a hash of the packet. The first octet specifies the +hashing algorithm, while the following octets contain the actual +hash, whose size depends on the hashing algorithm, and hence from +the value in the first octet. The hashing algorithm can be: 2s +complement (algorithm octet = 0, size = XXX), XOR (algorithm octet = +1, size=XXX), CRC32 (algorithm octet = 2, size = 4), MD-5 +(algorithm octet = 3, size = 16), SHA-1 (algorithm octet = 4, +size = 20), Toeplitz (algorithm octet = 5, size = 4). The hash covers +only the packet, not the header added by the capture driver: this +gives the possibility to calculate it inside the network card. The +hash allows easier comparison/merging of different capture files, +and reliable data transfer between the data acquisition system and +the capture library.¶
+Examples: '02 EC 1D 87 97', '03 45 6E C2 17 7C 10 1E 3C 2E 99 6E C2 9A 3D +50 8E'.¶
+The +epb_dropcount option is a 64-bit unsigned integer value +specifying the number of packets lost (by the interface and +the operating system) between this packet and the preceding +one for the same interface or, for the first packet for an +interface, between this packet and the start of the capture +process.¶
+Example: '0'.¶
+The +epb_packetid option is a 64-bit unsigned integer that uniquely +identifies the packet. If the same packet is seen by multiple +interfaces and there is a way for the capture application to +correlate them, the same epb_packetid value must be used. An +example could be a router that captures packets on all its +interfaces in both directions. When a packet hits interface A +on ingress, an EPB entry gets created, TTL gets decremented, +and right before it egresses on interface B another EPB entry +gets created in the trace file. In this case, two packets are +in the capture file, which are not identical but the +epb_packetid can be used to correlate them.¶
+Example: '0'.¶
+The epb_queue +option is a 32-bit unsigned integer that identifies on which queue +of the interface the specific packet was received.¶
+Example: '0'.¶
+The epb_verdict +option stores a verdict of the packet. The verdict indicates what +would be done with the packet after processing it. For example, a +firewall could drop the packet. This verdict can be set by various +components, i.e. Hardware, Linux's eBPF TC or XDP framework, etc. +etc. The first octet specifies the verdict type, while the +following octets contain the actual verdict data, whose size +depends on the verdict type, and hence from the value in the first +octet. The verdict type can be: Hardware (type octet = 0, size = +variable), Linux_eBPF_TC (type octet = 1, size = 8 (64-bit unsigned +integer), value = TC_ACT_* as defined in the Linux pck_cls.h include), Linux_eBPF_XDP (type octet = 2, size = 8 (64-bit unsigned +integer), value = xdp_action as defined in the Linux pbf.h include).¶
+Example: '02 00 00 00 00 00 00 00 02' for Linux_eBPF_XDP with +verdict XDP_PASS.¶
+The epb_processid_threadid +option stores the numeric process identifier and thread identifier +of the process which originated the packet as unsigned 32-bit +integers. The value 0 can be used for each if the concept of a +process or thread identifier does not make sense in context (e.g. +for inbound packets) or if the operating system capturing the +packets has no concept of processes or threads, respectively.¶
+Example: '00 00 04 D2 00 00 00 00' for process 1234 and an unknown +thread.¶
+The Enhanced Packet Block Flags Word is a 32-bit value that +contains link-layer information about the packet.¶
+The word is encoded as an unsigned 32-bit integer, using the +endianness of the Section Header Block scope it is in. In the +following table, the bits are numbered with 0 being the +least-significant bit and 31 being the most-significant bit of +the 32-bit unsigned integer. The meaning of the bits is the +following:¶
+| Bit Number | +Description | +
|---|---|
| 0-1 | +Inbound / Outbound packet (00 = information not available, 01 = inbound, 10 = outbound) | +
| 2-4 | +Reception type (000 = not specified, 001 = unicast, 010 = multicast, 011 = broadcast, 100 = promiscuous). | +
| 5-8 | +FCS length, in octets (0000 if this information is not available). This value overrides the if_fcslen option of the Interface Description Block, and is used with those link layers (e.g. PPP) where the length of the FCS can change during time. | +
| 9-15 | +Reserved (MUST be set to zero). | +
| 16-31 | +link-layer-dependent errors (Bit 31 = symbol error, Bit 30 = preamble error, Bit 29 = Start Frame Delimiter error, Bit 28 = unaligned frame error, Bit 27 = wrong Inter Frame Gap error, Bit 26 = packet too short error, Bit 25 = packet too long error, Bit 24 = CRC error, other?? are 16 bit enough?). | +
NOTE: in earlier versions of this specification, the bits +were specified as being numbered with 0 being the +most-significant bit and 31 being the least-significant bit +of the 32-bit unsigned integer, rather than with 0 being the +least-significant bit and 31 being the most-significant bit. +Several implementations number the bits with 0 being the +least-significant bit, and no known implementations number +them with 0 being the most-significant bit, so the +specification was changed to reflect that reality.¶
+The Simple Packet Block (SPB) is a lightweight container for +storing the packets coming from the network. Its presence is +optional.¶
+A Simple Packet Block is similar to an Enhanced Packet Block (see Section 4.3), but it is smaller, simpler to process +and contains only a minimal set of information. This block is +preferred to the standard Enhanced Packet Block when performance or +space occupation are critical factors, such as in sustained traffic +capture applications. A capture file can contain both Enhanced Packet +Blocks and Simple Packet Blocks: for example, a capture tool could +switch from Enhanced Packet Blocks to Simple Packet Blocks when the +hardware resources become critical.¶
+The Simple Packet Block does not contain the Interface ID field. +Therefore, it MUST be assumed that all the Simple Packet Blocks have +been captured on the interface previously specified in the first +Interface Description Block.¶
+Figure 12 shows the format of the Simple Packet +Block.¶
++ 1 2 3 + 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 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + 0 | Block Type = 0x00000003 | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + 4 | Block Total Length | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + 8 | Original Packet Length | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +12 / / + / Packet Data / + / variable length, padded to 32 bits / + / / + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Block Total Length | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ++
The Simple Packet Block has the following fields:¶
+The Simple Packet Block does not contain the timestamp because this +is often one of the most costly operations on PCs. Additionally, there +are applications that do not require it; e.g. an Intrusion Detection +System is interested in packets, not in their timestamp.¶
+A Simple Packet Block cannot be present in a Section that has more +than one interface because of the impossibility to refer to the +correct one (it does not contain any Interface ID field).¶
+The Simple Packet Block is very efficient in term of disk space: a +snapshot whose length is 100 octets requires only 16 octets of overhead, +which corresponds to an efficiency of more than 86%.¶
+The Name Resolution Block (NRB) is used to support the correlation +of numeric addresses (present in the captured packets) and their +corresponding canonical names and it is optional. Having the literal +names saved in the file prevents the need for performing name +resolution at a later time, when the association between names and +addresses may be different from the one in use at capture time. +Moreover, the NRB avoids the need for issuing a lot of DNS requests +every time the trace capture is opened, and also provides name +resolution when reading the capture with a machine not connected to +the network.¶
+A Name Resolution Block is often placed at the beginning of the +file, but no assumptions can be taken about its position. Multiple +NRBs can exist in a pcapng file, either due to memory constraints or +because additional name resolutions were performed by file processing +tools, like network analyzers.¶
+A Name Resolution Block need not contain any Records, except the +nrb_record_end Record which MUST be the last Record. The addresses and +names in NRB Records MAY be repeated multiple times; i.e., the same IP +address may resolve to multiple names, the same name may resolve to +the multiple IP addresses, and even the same address-to-name pair may +appear multiple times, in the same NRB or across NRBs.¶
+The format of the Name Resolution Block is shown in Figure 13.¶
++ 1 2 3 + 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 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + 0 | Block Type = 0x00000004 | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + 4 | Block Total Length | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + 8 | Record Type | Record Value Length | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +12 / Record Value / + / variable length, padded to 32 bits / + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + . . + . . . . other records . . . . + . . + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Record Type = nrb_record_end | Record Value Length = 0 | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + / / + / Options (variable) / + / / + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Block Total Length | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ++
The Name Resolution Block has the following fields:¶
+This is followed by zero or more Name Resolution Records (in the +TLV format), each of which contains an association between a network +address and a name. An nrb_record_end MUST be added after the last +Record, and MUST exist even if there are no other Records in the NRB. +There are currently three possible types of records:¶
+| Name | +Type | +Length | +
|---|---|---|
| nrb_record_end | +0x0000 | +0 | +
| nrb_record_ipv4 | +0x0001 | +variable | +
| nrb_record_ipv6 | +0x0002 | +variable | +
| nrb_record_eui48 | +0x0003 | +variable | +
| nrb_record_eui64 | +0x0004 | +variable | +
The +nrb_record_end record delimits the end of name resolution +records. This record is needed to determine when the list of name +resolution records has ended and some options (if any) begin.¶
+The +nrb_record_ipv4 record specifies an IPv4 address (contained in the +first 4 octets), followed by one or more zero-terminated UTF-8 +strings containing the DNS entries for that address. The minimum +valid Record Length for this Record Type is thus 6: 4 for the IP +octets, 1 character, and a zero-value octet terminator. Note that +the IP address is treated as four octets, one for each octet of +the IP address; it is not a 32-bit word, and thus the endianness +of the SHB does not affect this field's value.¶
+Example: '127 0 0 1'"localhost".¶
+[Open issue: is an empty string (i.e., just a zero-value octet) +valid?]¶
+The +nrb_record_ipv6 record specifies an IPv6 address (contained in the +first 16 octets), followed by one or more zero-terminated strings +containing the DNS entries for that address. The minimum valid +Record Length for this Record Type is thus 18: 16 for the IP +octets, 1 character, and a zero-value octet terminator.¶
+Example: '20 01 0d b8 00 00 00 00 00 00 00 00 12 34 56 +78'"somehost".¶
+[Open issue: is an empty string (i.e., just a zero-value octet) +valid?]¶
+The +nrb_record_eui48 / nrb_record_eui64 records specify an EUI (or MAC) +address (contained in the first 6 octets for eui48, 8 octets for eui64), +followed by one or more zero-terminated strings containing names resolved +for that address. As above, the minimum valid Record Length is 8 for +EUI-48 and 10 for EUI-64. There is no presumption implied in how these +names were acquired unless the DNS server options listed below are present +in the NRB.¶
+Example: '02 ca ff ee f0 0d'"teapot under test".¶
+[Open issue: is an empty string (i.e., just a zero-value octet) +valid?]¶
+Record Types other than those specified earlier MUST be ignored and +skipped past. More Record Types will likely be defined in the future, +and MUST NOT break backwards compatibility.¶
+Each Record Value is aligned to and padded to a 32-bit boundary. +The corresponding Record Value Length reflects the actual length of +the Record Value; it does not include the lengths of the Record Type +field, the Record Value Length field, any padding for the Record +Value, or anything after the Record Value. For Record Types with name +strings, the Record Length does include the zero-value octet +terminating that string. A Record Length of 0 is valid, unless +indicated otherwise.¶
+After the list of Name Resolution Records, optionally, a list of +options (formatted according to the rules defined in Section 3.5) can be present.¶
+In addition to the options defined in Section 3.5, +the following options are valid within this block:¶
+| Name | +Type | +Length | +Multiple allowed? | +
|---|---|---|---|
| ns_dnsname | +2 | +variable | +no | +
| ns_dnsIP4addr | +3 | +4 | +no | +
| ns_dnsIP6addr | +4 | +16 | +no | +
The ns_dnsname +option is a UTF-8 string containing the name of the machine (DNS +server) used to perform the name resolution. The string is not +zero-terminated.¶
+Example: "our_nameserver".¶
+The +ns_dnsIP4addr option specifies the IPv4 address of the DNS server. +Note that the IP address is treated as four octets, one for each +octet of the IP address; it is not a 32-bit word, and thus the +endianness of the SHB does not affect this field's value.¶
+Example: '192 168 0 1'.¶
+The +ns_dnsIP6addr option specifies the IPv6 address of the DNS +server.¶
+Example: '20 01 0d b8 00 00 00 00 00 00 00 00 12 34 56 78'.¶
+The Interface Statistics Block (ISB) contains the capture +statistics for a given interface and it is optional. The statistics +are referred to the interface defined in the current Section +identified by the Interface ID field. An Interface Statistics Block is +normally placed at the end of the file, but no assumptions can be +taken about its position - it can even appear multiple times for the +same interface.¶
+The format of the Interface Statistics Block is shown in Figure 14.¶
++ 1 2 3 + 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 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + 0 | Block Type = 0x00000005 | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + 4 | Block Total Length | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + 8 | Interface ID | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +12 | Timestamp (High) | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +16 | Timestamp (Low) | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +20 / / + / Options (variable) / + / / + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Block Total Length | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ++
The fields have the following meaning:¶
+All the statistic fields are defined as options in order to deal +with systems that do not have a complete set of statistics. Therefore, +In addition to the options defined in Section 3.5, +the following options are valid within this block:¶
+| Name | +Type | +Length | +Multiple allowed? | +
|---|---|---|---|
| isb_starttime | +2 | +8 | +no | +
| isb_endtime | +3 | +8 | +no | +
| isb_ifrecv | +4 | +8 | +no | +
| isb_ifdrop | +5 | +8 | +no | +
| isb_filteraccept | +6 | +8 | +no | +
| isb_osdrop | +7 | +8 | +no | +
| isb_usrdeliv | +8 | +8 | +no | +
The +isb_starttime option specifies the time the capture started; time +will be stored in two blocks of four octets each. The format of the +timestamp is the same as the one defined in the Enhanced Packet +Block (Section 4.3); the length of a unit +of time is specified by the 'if_tsresol' option (see Figure 10) of the Interface Description Block +referenced by this packet.¶
+Example: '96 c3 04 00 73 89 6a 65', in Little Endian, decodes +to 2012-06-29 06:17:00.834163 UTC.¶
+The isb_endtime +option specifies the time the capture ended; time will be stored +in two blocks of four octets each. The format of the timestamp is +the same as the one defined in the Enhanced Packet Block (Section 4.3); the length of a unit of time is specified +by the 'if_tsresol' option (see Figure 10) of +the Interface Description Block referenced by this packet.¶
+Example: '97 c3 04 00 aa 47 ca 64', in Little Endian, decodes +to 2012-06-29 07:28:25.298858 UTC.¶
+The isb_ifrecv +option specifies the 64-bit unsigned integer number of packets +received from the physical interface starting from the beginning +of the capture.¶
+Example: the decimal number 100.¶
+The isb_ifdrop +option specifies the 64-bit unsigned integer number of packets +dropped by the interface due to lack of resources starting from +the beginning of the capture.¶
+Example: '0'.¶
+The +isb_filteraccept option specifies the 64-bit unsigned integer +number of packets accepted by filter starting from the beginning +of the capture.¶
+Example: the decimal number 100.¶
+The isb_osdrop +option specifies the 64-bit unsigned integer number of packets +dropped by the operating system starting from the beginning of the +capture.¶
+Example: '0'.¶
+The +isb_usrdeliv option specifies the 64-bit unsigned integer number +of packets delivered to the user starting from the beginning of +the capture. The value contained in this field can be different +from the value 'isb_filteraccept - isb_osdrop' because some +packets could still be in the OS buffers when the capture +ended.¶
+Example: '0'.¶
+All the fields that refer to packet counters are 64-bit values, +represented with the octet order of the current section. Special care +must be taken in accessing these fields: since all the blocks are +aligned to a 32-bit boundary, such fields are not guaranteed to be +aligned on a 64-bit boundary.¶
+A Decryption Secrets Block (DSB) stores (session) secrets that +enable decryption of packets within the capture file. The format of +these secrets is defined by the Secrets Type.¶
+Multiple DSBs can exist in a pcapng file, but they SHOULD be written +before packet blocks that require those secrets. Tools MAY limit +decryption to secrets that appear before packet blocks.¶
+The structure of a +Decryption Secrets Block is shown in Figure 15.¶
++ 1 2 3 + 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 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + 0 | Block Type = 0x0000000A | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + 4 | Block Total Length | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + 8 | Secrets Type | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +12 | Secrets Length | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +16 / / + / Secrets Data / + / (variable length, padded to 32 bits) / + / / + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + / / + / Options (variable) / + / / + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + / Block Total Length / + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ++
The Decryption Secrets Block has the following fields.¶
+The following is a list of Secrets Types.¶
+TLS Key Log. This +format is described at NSS Key Log Format. Every line MUST be properly terminated with +either carriage return and linefeed ('\r\n') or linefeed ('\n'). +Tools MUST be able to handle both line endings.¶
+WireGuard Key Log. +Every line consists of the key type, equals sign ('='), and the +base64-encoded 32-byte key with optional spaces before and in between. +The key type is one of LOCAL_STATIC_PRIVATE_KEY, +REMOTE_STATIC_PUBLIC_KEY, LOCAL_EPHEMERAL_PRIVATE_KEY, +or PRESHARED|_KEY. This matches the output of extract-handshakes.sh, which is part of the WireGuard project. +A PRESHARED_KEY line is linked to a session matched by a previous +LOCAL_EPHEMERAL_PRIVATE_KEY line. +Every line MUST be properly terminated with +either carriage return and linefeed ('\r\n') or linefeed ('\n'). +Tools MUST be able to handle both line endings.¶
+Warning: LOCAL_STATIC_PRIVATE_KEY and potentially PRESHARED_KEY + are long-term secrets, users SHOULD only store non-production keys, + or ensure proper protection of the pcapng file.¶
+ZigBee NWK Key +and ZigBee PANID for that network. Network Key as described in +the ZigBee Specification 05-3473-21 (R21) section 4.2.2. +The NWK Key is a 16 octet binary AES-128 key used to secure NWK Level frames +within a single PAN. The NWK key is immediately followed by the +2 octet (16 bit) network PANID in little endian format. If and when +the NWK Key changes a new DSB will contain the new NWK Key.¶
+ZigBee APS Key. +Application Support Link Key as described in the ZigBee Specification 05-3473-21 (R21) section 4.4. Each 16 octet binary AES-128 key secures +frames exchanged between a pair of network nodes. The APS Key is +immediately followed by the 2 octet (16 bit) network PANID in +little endian format. The PANID is followed by the 2 octet (16 bit) +short addresses, in little endian format, of the nodes to which +the APS Key applies. The numerically lower short address shall come +first. There is an APS Key DSB for each node pair for which the +Link Key is known. As new links are formed, new DSBs contain the +new Keys. If the APS Key changes for an existing link, it is +contained in a new DSB with the new APS Key.¶
++ 0 1 2 3 + 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 + +---------------------------------------------------------------+ + 0 | Block Type = 0x0000000A | + +---------------------------------------------------------------+ + 4 | Block Total Length | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + 8 | Secrets Type = 0x5a4e574b | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +12 | Secrets Length | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +16 | AES-128 | + | NKW Key | + | (16 octets) | + | (128 bits) | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +32 | PAN ID | padding (0) | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +36 / / + / Options (variable) / + / / + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + / Block Total Length / + +---------------------------------------------------------------+ ++
+ 0 1 2 3 + 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 + +---------------------------------------------------------------+ + 0 | Block Type = 0x0000000A | + +---------------------------------------------------------------+ + 4 | Block Total Length | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + 8 | Secrets Type = 0x5a415053 | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +12 | Secrets Length | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +16 | AES-128 | + | APS Key | + | (16 octets) | + | (128 bits) | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +32 | PAN ID | Low Node Short Address | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +36 | High Node Short Address | padding (0) | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +40 / / + / Options (variable) / + / / + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + / Block Total Length / + +---------------------------------------------------------------+ ++
A Custom Block (CB) is the container for storing custom data that +is not part of another block; for storing custom data as part of +another block, see Section 3.5.1. The Custom +Block is optional, can be repeated any number of times, and can appear +before or after any other block except the first Section Header Block +which must come first in the file. Different Custom Blocks, of +different type codes and/or different Private Enterprise Numbers, may +be used in the same pcapng file. The format of a Custom Block is shown +in Figure 18.¶
++ 1 2 3 + 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 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + 0 | Block Type = 0x00000BAD or 0x40000BAD | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + 4 | Block Total Length | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + 8 | Private Enterprise Number (PEN) | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +12 / / + / Custom Data / + / variable length, padded to 32 bits / + / / + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + / / + / Options (variable) / + / / + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Block Total Length | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ++
The Custom Block uses the type code 0x00000BAD (2989 in decimal) +for a custom block that pcapng re-writers can copy into new files, and +the type code 0x40000BAD (1073744813 in decimal) for one that should +not be copied. See Section 5.2 for details.¶
+The Custom Block has the following fields:¶
+This section uses the term "vendor" to describe an organization which +extends the pcapng file with custom, proprietary blocks or options. It +should be noted, however, that the "vendor" is just an abstract entity +that agrees on a custom extension format: for example it may be a +manufacturer, industry association, an individual user, or collective +group of users.¶
+There are two different supported use-cases for vendor-specific +custom extensions: local and portable. Local use means the custom data +is only expected to be usable on the same machine, and the same +application, which encoded it into the file. This limitation is due to +the lack of a common registry for the local use number codes (the +block or option type code numbers with the Most Significant Bit set). +Since two different vendors may choose the same number, one vendor's +application reading the other vendor's file would result in decoding +failure. Therefore, vendors SHOULD instead use the portable method, as +described next.¶
+The portable use-case supports vendor-specific custom extensions in +pcapng files which can be shared across systems, organizations, etc. +To avoid number space collisions, an IANA-registered Private +Enterprise Number (PEN) is encoded into the Custom Block or Custom +Option, using the PEN that belongs to the vendor defining the +extension. Anyone can register a new PEN with IANA, for free, by +filling out the online request form at http://pen.iana.org/pen/PenApplication.page.¶
+Both Custom Blocks and Custom Options support two different type codes +to distinguish their "copy" behavior: a type code for when the block or +option can be safely copied into a new pcapng file by a pcapng +manipulating application, and a type code for when it should not be +copied. A common reason for not copying a Custom Block or Custom Option +is because it depends on other blocks or options in some way that would +invalidate the custom data if the other blocks/options were removed or +re-ordered. For example, if a Custom Block's data includes an +Interface ID number in its Custom Data portion, then it cannot be +safely copied by a pcapng application that merges pcapng files, +because the merging application might re-order or remove one or more +of the Interface Description Blocks, and thereby change the Interface +IDs that the Custom Block depends upon. The same issue arises if a +Custom Block or Custom Option depends on the presence of, or specific +ordering of, other standard-based or custom-defined blocks or +options.¶
+Note that the copy semantics is not related to privacy - there is +no guarantee that a pcapng anonymizer will remove a Custom Block or +Custom Option, even if the appropriate type code is used requesting it +not be copied; and the original pcapng file can be shared anyway. If the +Custom Data portion of the Custom Block or Custom Option contains +sensitive information, then it should be encrypted in some +fashion.¶
+For the Custom Options, there are two Custom Data formats +supported: a UTF-8 string and a binary data payload. The rationale for +this separation is that a pcapng display application which does not +understand the specific PEN's Custom Option can still display the data +as a string if it's a string type code, rather than as hex-ascii of +the octets.¶
+Implementers writing Custom Blocks or binary data Custom Options should +be aware that a pcapng file can be re-written by machines using a +different endianness than the original file, which means all known +fields of the pcapng file will change endianness in the new file. Since +the Custom Data payload of the Custom Block or the binary data Custom +Option might be an arbitrary sequence of unknown octets to such +machines, they cannot convert multi-octet values inside the Custom Data, +or in the Options section of a Custom Block,into the appropriate +endianness.¶
+For example, a little-endian machine can create a new pcapng file and +add some binary data Custom Options to some non-Custom Block(s) in the +file. This file can then be sent to a big-endian host, which will +convert the Option Type, Option Length, and PEN fields of the options to +big-endian format if it re-writes the file. However, if the software +reading the file does not understand the contents of all of the Custom +Options, it will leave the Custom Data payload of the options alone (as +little-endian format). If this file then gets sent to a little-endian +machine, then, when that little-endian machine reads the file, it will, +if the software reading the file understands the contents of all the +Custom Options, it will detect that the file format is big-endian, and +swap the endianness while it parses the file - but that will cause the +Custom Data payload to be incorrect since it was already in +little-endian format.¶
+In addition, a little-endian machine can create a pcapng file and write +some binary data Custom Blocks, containing options, to the file. The +file can then be sent to a big-endian host, which, if the software +reading the file does not understand the contents of the Custom Blocks, +will leave the Custom Data and Options alone (as little-endian format). +If this file then gets sent to a little-endian machine, then, when that +little-endian machine reads the file, it will, if the software reading +the file understands the contents of all the Custom Blocks, it will +detect that the file format is big-endian, and swap the endianness while +it parses the file - but that will cause the Custom Data payload, the +Option Type and Option Length values in the Options, and the PEN in any +Custom Options to be incorrect since they were already in little-endian +format.¶
+Therefore, the vendor should either encode the Custom Data of their +Custom Blocks and Custom Options, the Option Type and Option Length +fields of options in Custom Blocks, and the PEN field of Custom Options +in Custom Blocks in a consistent manner, such as always in big-endian or +always in little-endian format, regardless of the host platform's +endianness, or should encode some flag in the Custom Data payload to +indicate in which endianness the rest of the payload is written.¶
+The PEN field of a Custom Block, or of a Custom Option not contained in +a Custom Block, MUST be converted by code that reads pcapng files, so +this is not an issue for that field, except for Custom Options in Custom +Blocks. This is also not an issue for the Custom Data payload of UTF-8 +string Custom Options.¶
+The recommended file name extension for the "PCAP Next Generation +Capture File Format" specified in this document is ".pcapng".¶
+On Windows and macOS, files are distinguished by an extension to their +filename. Such an extension is technically not actually required, as +applications should be able to automatically detect the pcapng file +format through the "magic bytes" at the beginning of the file, as some +other UN*X desktop environments do. However, using name extensions makes +it easier to work with files (e.g. visually distinguish file formats) so +it is recommended - though not required - to use .pcapng as the name +extension for files following this specification.¶
+Please note: To avoid confusion (such as the current usage of +.cap for a plethora of different capture file formats) file +name extensions other than .pcapng should be avoided.¶
+The file format proposed in this document should be very versatile +and satisfy a wide range of applications. In the simplest case, it can +contain a raw capture of the network data, made of a series of Simple +Packet Blocks. In the most complex case, it can be used as a repository +for heterogeneous information. In every case, the file remains easy to +parse and an application can always skip the data it is not interested +in; at the same time, different applications can share the file, and +each of them can benefit of the information produced by the others. Two +or more files can be concatenated obtaining another valid file.¶
+Some known implementations that read or write the pcapng file format +are listed on the pcapng GitHub wiki.¶
+TBD.¶
+TBD.¶
+[Open issue: decide whether the block types, option types, NRB Record +types, etc. should be IANA registries. And if so, what the IANA policy +for each should be (see RFC 5226)]¶
+Every Block is uniquely identified by a 32-bit integer value, stored +in the Block Header.¶
+As pointed out in Section 3.1, Block Type +codes whose Most Significant Bit (bit 31) is set to 1 are reserved for +local use by the application.¶
+All the remaining Block Type codes (0x00000000 to 0x7FFFFFFF) are +standardized by this document. Requests for new Block Type codes, +Option Type codes, and Secrets Type codes should be made by creating +a pull request to update this document at github.com/IETF-OPSAWG-WG/pcapng. +The pull request should add a description of the new block, option, +or secret type to Section 4. The pull request +description should contain a clear request for a new type code +assignment.¶
+The following is a list of the Standardized Block Type Codes:¶
+| Block Type Code | +Description | +
|---|---|
| 0x00000000 | +Reserved ??? | +
| 0x00000001 | ++ Interface Description Block (Section 4.2) + | +
| 0x00000002 | ++ Packet Block (Appendix A) + | +
| 0x00000003 | ++ Simple Packet Block (Section 4.4) + | +
| 0x00000004 | ++ Name Resolution Block (Section 4.5) + | +
| 0x00000005 | ++ Interface Statistics Block (Section 4.6) + | +
| 0x00000006 | ++ Enhanced Packet Block (Section 4.3) + | +
| 0x00000007 | +IRIG Timestamp Block (requested by Gianluca Varenni <gianluca.varenni@cacetech.com>, CACE Technologies LLC); code also used for Socket Aggregation Event Block + | +
| 0x00000008 | ++ ARINC 429 in AFDX Encapsulation Information Block (requested by Gianluca Varenni <gianluca.varenni@cacetech.com>, CACE Technologies LLC) | +
| 0x00000009 | +[systemd Journal Export Block][I-D.richardson-opsawg-pcapng-extras] + | +
| 0x0000000A | ++ Decryption Secrets Block (Section 4.7) + | +
| 0x00000101 | ++ Hone Project Machine Info Block (see also Google version) | +
| 0x00000102 | ++ Hone Project Connection Event Block (see also Google version) | +
| 0x00000201 | ++ Sysdig Machine Info Block | +
| 0x00000202 | ++ Sysdig Process Info Block, version 1 | +
| 0x00000203 | ++ Sysdig FD List Block | +
| 0x00000204 | ++ Sysdig Event Block | +
| 0x00000205 | ++ Sysdig Interface List Block | +
| 0x00000206 | ++ Sysdig User List Block | +
| 0x00000207 | ++ Sysdig Process Info Block, version 2 | +
| 0x00000208 | ++ Sysdig Event Block with flags | +
| 0x00000209 | ++ Sysdig Process Info Block, version 3 | +
| 0x00000210 | ++ Sysdig Process Info Block, version 4 | +
| 0x00000211 | ++ Sysdig Process Info Block, version 5 | +
| 0x00000212 | ++ Sysdig Process Info Block, version 6 | +
| 0x00000213 | ++ Sysdig Process Info Block, version 7 | +
| 0x00000BAD | ++ Custom Block that rewriters can copy into new files (Section 4.8) + | +
| 0x40000BAD | ++ Custom Block that rewriters should not copy into new files (Section 4.8) + | +
| 0x0A0D0D0A | ++ Section Header Block (Section 4.1) + | +
| 0x0A0D0A00-0x0A0D0AFF | +Reserved. Used to detect trace files corrupted because of file transfers using the HTTP protocol in text mode. | +
| 0x000A0D0A-0xFF0A0D0A | +Reserved. Used to detect trace files corrupted because of file transfers using the HTTP protocol in text mode. | +
| 0x000A0D0D-0xFF0A0D0D | +Reserved. Used to detect trace files corrupted because of file transfers using the HTTP protocol in text mode. | +
| 0x0D0D0A00-0x0D0D0AFF | +Reserved. Used to detect trace files corrupted because of file transfers using the FTP protocol in text mode. | +
| 0x80000000-0xFFFFFFFF | +Reserved for local use. | +
[Open issue: reserve 0x40000000-0x7FFFFFFF for do-not-copy-bit +range of base types?]¶
+Loris Degioanni and Gianluca Varenni were coauthoring this document +before it was submitted to the IETF.¶
+The authors wish to thank +Anders Broman, +Ulf Lamping, +Richard Sharpe +and many others for their invaluable comments.¶
+The Packet Block is obsolete, and MUST NOT be used in new files. Use +the Enhanced Packet Block or Simple Packet Block instead. This section +is for historical reference only.¶
+A Packet Block was a container for storing packets coming from the +network.¶
++ 1 2 3 + 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 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + 0 | Block Type = 0x00000002 | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + 4 | Block Total Length | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + 8 | Interface ID | Drops Count | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +12 | Timestamp (High) | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +16 | Timestamp (Low) | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +20 | Captured Packet Length | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +24 | Original Packet Length | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +28 / / + / Packet Data / + / variable length, padded to 32 bits / + / / + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + / / + / Options (variable) / + / / + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Block Total Length | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ++
The Packet Block has the following fields:¶
+In addition to the options defined in Section 3.5, +the following options were valid within this block:¶
+| Name | +Type | +Length | +Multiple allowed? | +
|---|---|---|---|
| pack_flags | +2 | +4 | +no | +
| pack_hash | +3 | +variable | +yes | +
The pack_flags +option is the same as the epb_flags of the enhanced packet +block.¶
+Example: '0'.¶
+The pack_hash +option is the same as the epb_hash of the enhanced packet block.¶
+Examples: '02 EC 1D 87 97', '03 45 6E C2 17 7C 10 1E 3C 2E 99 6E +C2 9A 3D 50 8E'.¶
+| Internet-Draft | +pcapng-extras | +July 2023 | +
| Tuexen, et al. | +Expires 24 January 2024 | +[Page] | +
This document contains a number of extensions to the PCAPng file format which are outside of the IETF networking mandate.¶
+This note is to be removed before publishing as an RFC.¶
+Discussion of this document takes place on the + OPSAWG Working Group mailing list (opsawg@ietf.org), + which is archived at https://mailarchive.ietf.org/arch/browse/opsawg/.¶
+Source for this draft and an issue tracker can be found at + https://github.com/IETF-OPSAWG-WG/draft-ietf-opsawg-pcap.¶
++ 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 24 January 2024.¶
++ Copyright (c) 2023 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.¶
+TBD¶
+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 [RFC2119] [RFC8174] when, and only when, they +appear in all capitals, as shown here.¶
+The systemd Journal Export Block is a lightweight container for systemd +Journal Export Format entry data.¶
+One of the primary components of the systemd System and +Service Manager is the "Journal", a message logging system that +uses arrays of key-value pairs. Journal entries are stored in a +database-like file on disk but can be serialized to easily +parseable "Journal Export Format" data or to a JSON object. The +block described here is limited to Journal Export Format data +only.¶
+A systemd Journal Export Block contains a single systemd +Journal Export Format entry. Each entry MUST contain a +__REALTIME_TIMESTAMP= field. If a timestamp for the block is +required it can be derived from this field. Each entry MUST be +zero-padded to 32 bits. Although the primary use of this block +is intended for importing data from systemd, it could +potentially be used to include arbitrary key-value data in a +capture file.¶
+Figure 1 shows the format of the +Journal Export Block.¶
++ 1 2 3 + 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 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + 0 | Block Type = 0x00000009 | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + 4 | Block Total Length | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + 8 / / + / Journal Entry / + / variable length, padded to 32 bits / + / / + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Block Total Length | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ++
The systemd Journal Export Block has the following fields:¶
+Can some other packet blocks (besides the ones described in the +previous paragraphs) be useful?¶
+The Compression Block is optional. A file can contain an arbitrary +number of these blocks. A Compression Block, as the name says, is used +to store compressed data. Its format is shown in Figure 2.¶
++ 1 2 3 + 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 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + 0 | Block Type = ? | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + 4 | Block Total Length | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + 8 | Compr. Type | / + +-+-+-+-+-+-+-+-+ / + / / + / Compressed Data / + / / + / variable length, octet-aligned and padded to end on a 32-bit / + / boundary / + / / + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Block Total Length | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ++
The fields have the following meaning:¶
+The Encryption Block is optional. A file can contain an arbitrary +number of these blocks. An Encryption Block is used to store encrypted +data. Its format is shown in Figure 3.¶
++ 1 2 3 + 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 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + 0 | Block Type = ? | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + 4 | Block Total Length | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + 8 | Encr. Type | / + +-+-+-+-+-+-+-+-+ / + / / + / Encrypted Data / + / / + / variable length, octet-aligned / + / / + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Block Total Length | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ++
The fields have the following meaning:¶
+The Fixed Length Block is optional. A file can contain an arbitrary +number of these blocks. A Fixed Length Block can be used to optimize +the access to the file. Its format is shown in Figure 4. A Fixed Length Block stores records with +constant size. It contains a set of Blocks (normally Enhanced Packet +Blocks or Simple Packet Blocks), of which it specifies the size. +Knowing this size a priori helps to scan the file and to load some +portions of it without truncating a block, and is particularly useful +with cell-based networks like ATM.¶
++ 1 2 3 + 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 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + 0 | Block Type = ? | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + 4 | Block Total Length | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + 8 | Cell Size | | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ / + / / + / Fixed Size Data / + / / + / variable length, octet-aligned / + / / + / / + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Block Total Length | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ++
The fields have the following meaning:¶
+If present, this block contains the following information:¶
+A directory block MUST be followed by at least N packets, otherwise +it MUST be considered invalid. It can be used to efficiently load +portions of the file to memory and to support operations on memory +mapped files. This block can be added by tools like network analyzers +as a consequence of file processing.¶
+One or more blocks could be defined to contain network statistics +or traffic monitoring information. They could be use to store data +collected from RMON or Netflow probes, or from other network +monitoring tools.¶
+This block could be used to store events. Events could contain +generic information (for example network load over 50%, server +down...) or security alerts. An event could be:¶
+TBD.¶
+TBD.¶
+[Open issue: decide whether the block types, option types, NRB Record +types, etc. should be IANA registries. And if so, what the IANA policy +for each should be (see RFC 5226)]¶
+Loris Degioanni and Gianluca Varenni were coauthoring this document +before it was submitted to the IETF.¶
+The authors wish to thank +Anders Broman, +Ulf Lamping, +Richard Sharpe +and many others for their invaluable comments.¶
+| pcaplinktype | +plain text | +same as master | +
| pcap | +plain text | +same as master | +
| pcapng | +plain text | +same as master | +
| pcapng-extras | +plain text | +same as master | +
| pcaplinktype | +plain text | +same as master | +
| pcap | +plain text | +same as master | +
| pcapng | +plain text | +same as master | +
| pcapng-extras | +plain text | +same as master | +