draft-tuexen-opsawg-pcapng.xml

<?xml version="1.0" encoding="utf-8"?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd"[]>
<?rfc symrefs='yes' ?>
<?rfc toc='yes' ?>
<?rfc compact='yes' ?>
<?rfc subcompact='no' ?>
<?rfc inline='yes' ?>
<?rfc sortrefs='no' ?>
<?rfc strict='yes' ?>

<rfc category='info'
     ipr='trust200902'
     docName="draft-tuexen-opsawg-pcapng">

  <front>

    <title abbrev="pcapng">PCAP Next Generation (pcapng) Capture File Format</title>

    <author initials='M.' surname='Tuexen' fullname='Michael Tuexen' role='editor'>
      <organization abbrev='Muenster Univ. of Appl. Sciences'>
                    Muenster University of Applied Sciences</organization>
      <address>
        <postal>
          <street>Stegerwaldstrasse 39</street>
          <code>48565</code>
          <city>Steinfurt</city>
          <country>DE</country>
        </postal>
        <email>tuexen@fh-muenster.de</email>
      </address>
    </author>

    <author initials="F." surname="Risso" fullname="Fulvio Risso">
      <organization>Politecnico di Torino</organization>
      <address>
        <postal>
          <street>Corso Duca degli Abruzzi, 24</street>
          <city>Torino</city>
          <code>10129</code>
          <country>IT</country>
        </postal>
        <email>fulvio.risso@polito.it</email>
      </address>
    </author>

    <author initials='J.' surname='Bongertz' fullname='Jasper Bongertz'>
     <organization abbrev='Airbus DS CyberSecurity'>Airbus Defence and Space CyberSecurity</organization>
     <address>
       <postal>
         <street>Kanzlei 63c</street>
         <code>40667</code>
         <city>Meerbusch</city>
         <country>DE</country>
       </postal>
       <email>jasper@packet-foo.com</email>
     </address>
    </author>

    <author initials='G.' surname='Combs' fullname='Gerald Combs'>
     <organization abbrev='Wireshark'>
                   Wireshark Foundation</organization>
     <address>
       <postal>
         <street>339 Madson Pl</street>
         <city>Davis</city>
         <region>CA</region>
         <code>95618</code>
         <country>US</country>
       </postal>
       <email>gerald@wireshark.org</email>
     </address>
    </author>

    <author initials='G.' surname='Harris' fullname='Guy Harris'>
      <address>
        <email>guy@alum.mit.edu</email>
      </address>
    </author>

    <date />

    <abstract>
      <t>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.</t>
    </abstract>

  </front>


<!--===========================================================================

    MAIN BODY - still within the <rfc> tag

============================================================================-->

  <middle>

    <section title="Introduction">

      <t>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.</t>

      <t>This document proposes a new format for recording packet traces. The
      following goals are being pursued:

        <list style='hanging'>

          <t hangText='Extensibility:'>
          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.</t>

          <t hangText='Portability:'>
          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.</t>

          <t hangText='Merge/Append data:'>
          It should be possible to add data at the end of a given file, and
          the resulting file must still be readable.</t>

        </list>

      </t>

    </section>

    <section title='Terminology'>

      <t>The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
      "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
      document are to be interpreted as described in <xref
      target='RFC2119'/>.</t>

      <section title="Acronyms">

        <t>The following acronyms are used throughout this document:

          <list style='hanging'>
            <t hangText='SHB:'>Section Header Block</t>
            <t hangText='IDB:'>Interface Description Block</t>
            <t hangText='ISB:'>Interface Statistics Block</t>
            <t hangText='EPB:'>Enhanced Packet Block</t>
            <t hangText='SPB:'>Simple Packet Block</t>
            <t hangText='NRB:'>Name Resolution Block</t>
            <t hangText='CB:'>Custom Block</t>
          </list>

        </t>

      </section>

    </section>


    <section title="General File Structure">

      <section anchor="section_block" title="General Block Structure">

        <t>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 <xref target="formatblock"/>.</t>

        <figure anchor="formatblock" title="Basic block structure." align="center">
          <artwork xml:space="preserve" name="" type="" align="center" alt="" width="" height="">
 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                          Block Type                           |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                      Block Total Length                       |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
/                          Block Body                           /
/              variable length, padded to 32 bits               /
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                      Block Total Length                       |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
</artwork>
        </figure>

        <t>The fields have the following meaning:
          <list style="symbols">

            <t>Block Type (32 bits): unique value that identifies the block.
            Values whose Most Significant Bit (MSB) is equal to 1 are reserved
            for local use. They can be used to make extensions to the file
            format to save private data to the file. The list of currently
            defined types can be found in <xref
            target="section_block_code_registry"/>.</t>

            <t>Block Total Length: total size of this block, in octets. For
            instance, the length of a block that does not have a body is 12
            octets: 4 octets for the Block Type, 4 octets for the initial
            Block Total Length and 4 octets for the trailing Block Total
            Length. This value MUST be a multiple of 4.</t>

            <t>Block Body: content of the block.</t>

            <t>Block Total Length: total size of this block, in octets. This
            field is duplicated to permit backward file navigation.</t>

          </list>
        </t>

        <t>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.</t>

        <t>The General Block Structure allows defining other blocks if needed.
        A parser that does not understand them can simply ignore their
        content.</t>

      </section>

      <section title="Block Types">

        <t>The currently standardized Block Type codes are specified in <xref
        target="section_block_code_registry"/>; they have been grouped in the
        following four categories:</t>

        <t>The following MANDATORY block MUST appear at least once in each file:
          <list style="symbols">

            <t><xref target="section_shb">Section Header
            Block</xref>: it defines the most important characteristics of the
            capture file.</t>

          </list>
        </t>

        <t>The following OPTIONAL blocks MAY appear in a file:
          <list style="symbols">

            <t><xref target="section_idb">Interface Description Block</xref>:
            it defines the most important characteristics of the interface(s)
            used for capturing traffic. This block is required in certain
            cases, as described later.</t>

            <t><xref target="section_epb">Enhanced Packet Block</xref>: it
            contains a single captured packet, or a portion of it. It
            represents an evolution of the original, now obsolete, <xref
            target="appendix_pb" >Packet Block</xref>. If this appears in a
            file, an Interface Description Block is also required, before this
            block.</t>

            <t><xref target="section_spb">Simple Packet Block</xref>: it
            contains a single captured packet, or a portion of it, with only a
            minimal set of information about it. If this appears in a file, an
            Interface Description Block is also required, before this
            block.</t>

            <t><xref target="section_nrb" >Name Resolution Block</xref>: it
            defines the mapping from numeric addresses present in the packet
            capture and the canonical name counterpart.</t>

            <t><xref target="section_isb">Interface Statistics Block</xref>: it
            defines how to store some statistical data (e.g. packet dropped,
            etc) which can be useful to understand the conditions in which the
            capture has been made. If this appears in a file, an Interface
            Description Block is also required, before this block.</t>

            <t><xref target="section_custom_block">Custom Block</xref>: it
            contains vendor-specific data in a portable fashion.</t>

          </list>
        </t>

        <t>The following OBSOLETE block SHOULD NOT appear in newly written
        files (but is documented in the Appendix for reference):
          <list style="symbols">

            <t><xref target="appendix_pb">Packet Block</xref>: it contains a
            single captured packet, or a portion of it. It is OBSOLETE, and
            superseded by the <xref target="section_epb">Enhanced Packet
            Block</xref>.</t>

          </list>
        </t>

        <t>The following EXPERIMENTAL blocks are considered interesting but
        the authors believe that they deserve more in-depth discussion before
        being defined:
          <list style="symbols">
            <t>Alternative Packet Blocks</t>
            <t>Compression Block</t>
            <t>Encryption Block</t>
            <t>Fixed Length Block</t>
            <t>Directory Block</t>
            <t>Traffic Statistics and Monitoring Blocks</t>
            <t>Event/Security Blocks</t>
          </list>
        </t>

        <t>Requests for new standardized Block Type codes should be sent
        to the <eref
        target="https://www.winpcap.org/mailman/listinfo/pcap-ng-format">pcap-ng-format mailing list</eref>.</t>

      </section>

      <section title="Logical Block Hierarchy">

        <t>The blocks build a logical hierarchy as they refer to each other.
        <xref target="block-hierarchy"/> shows the logical hierarchy of the
        currently defined blocks in the form of a "tree view":</t>

        <figure anchor="block-hierarchy" title="Logical Block Hierarchy of a pcapng File">
          <artwork xml:space="preserve" name="" type="" align="left" alt="" width="" height="">
Section Header
|
+- Interface Description
|  +- Simple Packet
|  +- Enhanced Packet
|  +- Interface Statistics
|
+- Name Resolution
</artwork>
        </figure>

        <t>For example: each captured packet refers to a specific capture
        interface, the interface itself refers to a specific section.</t>

      </section>


      <section title="Physical File Layout">

        <t>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.</t>

        <t>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.</t>

        <t><xref target="fssample-SHB"/> shows a typical file layout, with a
        single Section Header that covers the whole file.</t>

        <figure anchor="fssample-SHB" title="File structure example: Typical layout with a single Section Header Block">
          <artwork xml:space="preserve" name="" type="" align="left" alt="" width="" height="">
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SHB v1.0  |                      Data                         |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
</artwork>
        </figure>

        <t><xref target="fssample-SHB3"/>
        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.</t>

        <figure anchor="fssample-SHB3" title="File structure example: three Section Header Blocks in a single file">
          <artwork xml:space="preserve" name="" type="" align="left" alt="" width="" height="">
|--   1st Section   --|--   2nd Section   --|--  3rd Section  --|
|                                                               |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SHB v1.0  |  Data   | SHB V1.1  |  Data   | SHB V1.0  |  Data |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
</artwork>
        </figure>

        <t><xref target="fssample-minimum"/>
        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).</t>

        <figure anchor="fssample-minimum" title="File structure example: a pcapng file similar to a classical libpcap file">
          <artwork xml:space="preserve" name="" type="" align="left" alt="" width="" height="">
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SHB | IDB | EPB | EPB |    ...    | EPB |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
</artwork>
        </figure>

        <t><xref target="fssample-full"/>
        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).</t>

        <figure anchor="fssample-full" title="File structure example: complex pcapng file">
          <artwork xml:space="preserve" name="" type="" align="left" alt="" width="" height="">
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SHB | IDB | IDB | EPB | NRB |...| IDB | EPB | ISB | NRB | EPB |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
</artwork>
        </figure>

        <t>The last example should make it obvious that the block structure
        makes the file format very flexible compared to the classical libpcap
        format.</t>

      </section>


      <section anchor="section_opt" title="Options">

        <t>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.</t>

        <t>A block that may contain options must be structured so that
        the number of bytes 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
        <xref target="section_block"/>) can be used to determine how
        many bytes 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.</t>

        <t>Options are a list of Type - Length - Value fields, each one
        containing a single value:
          <list style="symbols">

            <t>Option Type (2 octets): it contains the code that specifies the
            type of the current TLV record. Option types whose Most
            Significant Bit is equal to one are reserved for local use;
            therefore, there is no guarantee that the code used is unique
            among all capture files (generated by other applications), and is
            most certainly not portable. For cross-platform globally unique
            vendor-specific extensions, the Custom Option MUST be used
            instead, as defined in <xref target="section_custom_option"/>).</t>

            <t>Option Length (2 octets): it contains the actual length of the
            following 'Option Value' field without the padding octets.</t>

            <t>Option Value (variable length): it contains the value of the
            given option, padded to a 32-bit boundary. The actual length of
            this field (i.e. without the padding octets) is specified by the
            Option Length field.</t>

          </list>
        </t>

        <t>Requests for new standardized option codes for a given block
        should be sent to the <eref
        target="https://www.winpcap.org/mailman/listinfo/pcap-ng-format">pcap-ng-format mailing list</eref>.</t>

        <t>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.</t>

        <t>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.</t>

        <t>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.</t>

        <t>The option list is terminated by a 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.</t>

        <t>The format of the optional fields is shown in <xref
        target="formatopt"/>.</t>

        <figure anchor="formatopt" title="Options Format">
          <artwork xml:space="preserve" name="" type="" align="center" alt="" width="" height="">
 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|      Option Code              |         Option Length         |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
/                       Option Value                            /
/              variable length, padded to 32 bits               /
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
/                                                               /
/                 . . . other options . . .                     /
/                                                               /
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|   Option Code == opt_endofopt  |  Option Length == 0          |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 </artwork>
        </figure>

        <t>The following codes can always be present in any optional field:</t>

        <texttable anchor="optionsall" title="Common Options">
          <ttcol align="left">Name</ttcol>
          <ttcol align="left">Code</ttcol>
          <ttcol align="left">Length</ttcol>
          <ttcol align="left">Multiple allowed?</ttcol>

          <c>opt_endofopt</c>
          <c>0</c>
          <c>0</c>
          <c>no</c>

          <c>opt_comment</c>
          <c>1</c>
          <c>variable</c>
          <c>yes</c>

          <c>opt_custom</c>
          <c>2988/2989/19372/19373</c>
          <c>variable, minimum 4</c>
          <c>yes</c>
        </texttable>

        <t>
          <list hangIndent="8" style="hanging">

            <t hangText="opt_endofopt:"><vspace blankLines="0"/>The
            opt_endofopt option delimits the end of the optional fields. This
            option MUST NOT be repeated within a given list of options.</t>

            <t hangText="opt_comment:"><vspace blankLines="0"/>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.</t>

            <t>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.".</t>

            <t hangText="opt_custom:"><vspace blankLines="0"/>This option is
            described in detail in <xref target="section_custom_option"/>.</t>

          </list>
        </t>


        <section anchor="section_custom_option" title="Custom Options">

          <t>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 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 <xref
          target="section_vendor"/> for additional details.</t>

          <figure anchor="formatcustomopt" title="Custom Options Format">
            <artwork xml:space="preserve" name="" type="" align="center" alt="" width="" height="">
 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|     Custom Option Code        |         Option Length         |
+---------------------------------------------------------------+
|                Private Enterprise Number (PEN)                |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
/                        Custom Data                            /
/              variable length, padded to 32 bits               /
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 </artwork>
          </figure>

          <t>The Custom Option has the following fields:
            <list style="symbols">

              <t>Custom Option Code: The code number for the Custom Option, which
              can be one of the following decimal numbers:

                <list hangIndent="8" style="hanging">

                  <t hangText="2988:"><vspace blankLines="0"/>This option 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 <xref
                  target="section_vendor_copy"/> for details.</t>

                  <t hangText="2989:"><vspace blankLines="0"/>This option 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 <xref
                  target="section_vendor_copy"/> for details.</t>

                  <t hangText="19372:"><vspace blankLines="0"/>This option 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 <xref
                  target="section_vendor_copy"/> for details.</t>

                  <t hangText="19373:"><vspace blankLines="0"/>This option 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 <xref target="section_vendor_copy"/> for
                  details.</t>

                </list>
              </t>

              <t>Option Length: as described in <xref target="section_block"/>,
              this contains the length of the option's value, which includes the
              4-octet Private Enterprise Number and variable-length Custom Data
              fields, without the padding octets.</t>

              <t>Private Enterprise Number: An IANA-assigned Private Enterprise
              Number identifying the organization which defined the Custom
              Option. See <xref target="section_vendor_uses"/> for details. The
              PEN number MUST be encoded using the same endianness as the Section
              Header Block it is within the scope of.</t>

              <t>Custom Data: the custom data, padded to a 32 bit boundary.</t>

            </list>
          </t>

        </section>

      </section>

      <section title="Data format">

        <section title="Endianness">

          <t>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.</t>

          <t>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.</t>

          <t>Please note: The endianness is indicated by the <xref
          target="section_shb">Section Header Block</xref>. Since this block
          can appear several times in a pcapng file, a single file can contain
          both endianness variants.</t>

        </section>

        <section title="Alignment">

          <t>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.</t>

          <t>The alignment octets (marked in this document e.g. with "padded to
          32 bits") MUST be filled with zeroes.</t>

          <t>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.)</t>

        </section>

      </section>

    </section>


    <section title="Block Definition">

      <t>This section details the format of the blocks currently defined.</t>

      <section anchor="section_shb" title="Section Header Block">

        <t>The Section Header Block (SHB) is mandatory. It identifies the
        beginning of a section of the capture 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 <xref target="format_shb"/>.</t>

        <figure anchor="format_shb" title="Section Header Block Format">
          <artwork xml:space="preserve" name="" type="" align="center" alt="" width="" height="">
   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 = 0x0A0D0D0A                     |
   +---------------------------------------------------------------+
 4 |                      Block Total Length                       |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 8 |                      Byte-Order Magic                         |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
12 |          Major Version        |         Minor Version         |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
16 |                                                               |
   |                          Section Length                       |
   |                                                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
24 /                                                               /
   /                      Options (variable)                       /
   /                                                               /
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                      Block Total Length                       |
   +---------------------------------------------------------------+
</artwork>
        </figure>

        <t>The meaning of the fields is:
          <list style="symbols">

            <t>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:
              <list style="numbers">

                <t>This number is used to detect if a file has been transferred
                via FTP or HTTP from a machine to another with an inappropriate
                ASCII conversion. In this case, the value of this field will
                differ from the standard one ("\n\r\r\n") and the reader can
                detect a possibly corrupted file.</t>

                <t>This value is palindromic, so that the reader is able to
                recognize the Section Header Block regardless of the endianness
                of the section. The endianness is recognized by reading the Byte
                Order Magic, that is located 8 octets after the Block Type.</t>

              </list>
            </t>

            <t>Block Total Length: total size of this block, as described in
            <xref target="section_block"/>.</t>

            <t>Byte-Order Magic: magic number, whose value is the hexadecimal
            number 0x1A2B3C4D. This number can be used to distinguish sections
            that have been saved on little-endian machines from the ones saved
            on big-endian machines.</t>

            <t>Major Version: number of the current mayor version of the
            format. Current value is 1. 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.</t>

            <t>Minor Version: number of the current minor version of the
            format. Current value is 0. 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.</t>

            <t>Section Length: a signed 64-bit value specifying the length in
            octets of the following section, excluding the Section Header Block
            itself. This field can be used to skip the section, for faster
            navigation inside large files. Section Length equal -1
            (0xFFFFFFFFFFFFFFFF) means that the size of the section is not
            specified, and the only way to skip the section is to parse the
            blocks that it contains. Please note that if this field is valid
            (i.e. not negative), its value is always aligned to 32 bits, as
            all the blocks are aligned to and padded to 32-bit boundaries.
            Also, special care should be taken in accessing this field: since
            the alignment of all the blocks in the file is 32-bits, this field
            is not guaranteed to be aligned to a 64-bit boundary. This could
            be a problem on 64-bit processors.</t>

            <t>Options: optionally, a list of options (formatted according to
            the rules defined in <xref target="section_opt"/>) can be present.</t>

          </list>
        </t>

        <t>Adding new block types or options would not necessarily require
        that either Major or Minor numbers 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.</t>

        <t>Aside from the options defined in <xref target="section_opt"/>, the
        following options are valid within this block:</t>

        <texttable anchor="options_shb" title="Section Header Block Options">
          <ttcol align="left">Name</ttcol>
          <ttcol align="left">Code</ttcol>
          <ttcol align="left">Length</ttcol>
          <ttcol align="left">Multiple allowed?</ttcol>

          <c>shb_hardware</c>
          <c>2</c>
          <c>variable</c>
          <c>no</c>

          <c>shb_os</c>
          <c>3</c>
          <c>variable</c>
          <c>no</c>

          <c>shb_userappl</c>
          <c>4</c>
          <c>variable</c>
          <c>no</c>
        </texttable>

        <t>
          <list hangIndent="8" style="hanging">

            <t hangText="shb_hardware:"><vspace blankLines="0"/>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.</t>

            <t>Examples: "x86 Personal Computer", "Sun Sparc Workstation".</t>

            <t hangText="shb_os:"><vspace blankLines="0"/>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.</t>

            <t>Examples: "Windows XP SP2", "openSUSE 10.2".</t>

            <t hangText="shb_userappl:"><vspace blankLines="0"/>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.</t>

            <t>Examples: "dumpcap V0.99.7".</t>

          </list>
        </t>

        <t>[Open issue: does a program which re-writes a capture file change
        the original hardware/os/application info?]</t>

      </section>


      <section anchor="section_idb" title="Interface Description Block">

        <t>An Interface Description Block (IDB) is the container for
        information describing an interface on which packet data is
        captured.</t>

        <t>Tools that write / read the capture file associate an incrementing
        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).</t>

        <t>There must be an Interface Description Block for each
        interface to which another block 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.</t>

        <t>An Interface Description Block is valid only inside the section
        to which it belongs. The structure of a Interface Description Block is
        shown in <xref target="format_idb"/>.</t>

        <figure anchor="format_idb" title="Interface Description Block Format">
          <artwork xml:space="preserve" name="" type="" align="center" alt="" width="" height="">
    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 = 0x00000001                    |
   +---------------------------------------------------------------+
 4 |                      Block Total Length                       |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 8 |           LinkType            |           Reserved            |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
12 |                            SnapLen                            |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
16 /                                                               /
   /                      Options (variable)                       /
   /                                                               /
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                      Block Total Length                       |
   +---------------------------------------------------------------+
 </artwork>
        </figure>

        <t>The meaning of the fields is:
          <list style="symbols">

            <t>Block Type: The block type of the Interface Description Block
            is 1.</t>

            <t>Block Total Length: total size of this block, as described in
            <xref target="section_block"/>.</t>

            <t>LinkType: a value that defines the link layer type of this
            interface. The list of Standardized Link Layer Type codes is
            available in <eref
            target="http://www.tcpdump.org/linktypes.html">the tcpdump.org
            link-layer header types registry</eref>.</t>

            <t>Reserved: not used - MUST be filled with 0, and ignored by
            pcapng file readers.</t>

            <t>SnapLen: maximum number of octets captured from each packet. The
            portion of each packet that exceeds this value will not be stored
            in the file. A value of zero indicates no limit.</t>

            <t>Options: optionally, a list of options (formatted according to
            the rules defined in <xref target="section_opt"/>) can be present.</t>

          </list>
        </t>

        <t>In addition to the options defined in <xref target="section_opt"/>,
        the following options are valid within this block:</t>

        <texttable anchor="optionsifb" title="Interface Description Block Options">
          <ttcol align="left">Name</ttcol>
          <ttcol align="left">Code</ttcol>
          <ttcol align="left">Length</ttcol>
          <ttcol align="left">Multiple allowed?</ttcol>

          <c>if_name</c>
          <c>2</c>
          <c>variable</c>
          <c>no</c>

          <c>if_description</c>
          <c>3</c>
          <c>variable</c>
          <c>no</c>

          <c>if_IPv4addr</c>
          <c>4</c>
          <c>8</c>
          <c>yes</c>

          <c>if_IPv6addr</c>
          <c>5</c>
          <c>17</c>
          <c>yes</c>

          <c>if_MACaddr</c>
          <c>6</c>
          <c>6</c>
          <c>no</c>

          <c>if_EUIaddr</c>
          <c>7</c>
          <c>8</c>
          <c>no</c>

          <c>if_speed</c>
          <c>8</c>
          <c>8</c>
          <c>no</c>

          <c>if_tsresol</c>
          <c>9</c>
          <c>1</c>
          <c>no</c>

          <c>if_tzone</c>
          <c>10</c>
          <c>4</c>
          <c>no</c>

          <c>if_filter</c>
          <c>11</c>
          <c>variable, minimum 1</c>
          <c>no</c>

          <c>if_os</c>
          <c>12</c>
          <c>variable</c>
          <c>no</c>

          <c>if_fcslen</c>
          <c>13</c>
          <c>1</c>
          <c>no</c>

          <c>if_tsoffset</c>
          <c>14</c>
          <c>8</c>
          <c>no</c>

          <c>if_hardware</c>
          <c>15</c>
          <c>variable</c>
          <c>no</c>
        </texttable>

        <t>
          <list hangIndent="8" style="hanging">

            <t hangText="if_name:"><vspace blankLines="0"/>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.</t>

            <t>Examples: "eth0", "\Device\NPF_{AD1CE675-96D0-47C5-ADD0-2504B9126B68}".</t>

            <t hangText="if_description:"><vspace blankLines="0"/>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.</t>

            <t>Examples: "Wi-Fi", "Local Area Connection", "Wireless
            Network Connection", "First Ethernet Interface".</t>

            <t hangText="if_IPv4addr:"><vspace blankLines="0"/>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.</t>

            <t>Examples: '192 168 1 1 255 255 255 0'.</t>

            <t hangText="if_IPv6addr:"><vspace blankLines="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.</t>

            <t>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'.</t>

            <t hangText="if_MACaddr:"><vspace blankLines="0"/>The if_MACaddr
            option is the Interface Hardware MAC address (48 bits), if
            available.</t>

            <t>Example: '00 01 02 03 04 05'.</t>

            <t hangText="if_EUIaddr:"><vspace blankLines="0"/>The if_EUIaddr
            option is the Interface Hardware EUI address (64 bits), if
            available.</t>

            <t>Example: '02 34 56 FF FE 78 9A BC'.</t>

            <t hangText="if_speed:"><vspace blankLines="0"/>The if_speed
            option is a 64-bit number for the Interface speed (in bits per
            second).</t>

            <t>Example: the 64-bit decimal number 100000000 for 100Mbps.</t>

            <t hangText="if_tsresol:"><vspace blankLines="0"/>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 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).</t>

            <t>Example: '6'.</t>

            <t hangText="if_tzone:"><vspace blankLines="0"/>The if_tzone
            option identifies the time zone for GMT support (TODO: specify
            better).</t>

            <t>Example: TODO: give a good example.</t>

            <t hangText="if_filter:"><vspace blankLines="0"/>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,
            ...)</t>

            <t>Example: '00'"tcp port 23 and host 192.0.2.5".</t>

            <t hangText="if_os:"><vspace blankLines="0"/>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 (<xref target="section_shb"/>) because the
            capture can have been done on a remote machine. The string is
            not zero-terminated.</t>

            <t>Examples: "Windows XP SP2", "openSUSE 10.2".</t>

            <t hangText="if_fcslen:"><vspace blankLines="0"/>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 <xref
            target="section_epb_flags"/>).</t>

            <t>Example: '4'.</t>

            <t hangText="if_tsoffset:"><vspace blankLines="0"/>The
            if_tsoffset option is a 64-bit 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?</t>

            <t>Example: '1234'.</t>

            <t hangText="if_hardware:"><vspace blankLines="0"/>The
            if_hardware option is a UTF-8 string containing the description
            of the interface hardware. The string is not zero-terminated.</t>

            <t>Examples: "Broadcom NetXtreme", "Intel(R) PRO/1000 MT
            Network Connection", "NETGEAR WNA1000Mv2 N150 Wireless USB
            Micro Adapter".</t>

          </list>
        </t>
      </section>


      <section anchor="section_epb" title="Enhanced Packet Block">

        <t>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 <xref
        target="format_epb"/>.</t>

        <t>The Enhanced Packet Block is an improvement over the original, now
        obsolete, <xref target="appendix_pb">Packet Block</xref>:

          <list style="symbols">

            <t>it stores the Interface Identifier as a 32-bit integer value.
            This is a requirement when a capture stores packets coming from a
            large number of interfaces</t>

            <t>unlike the <xref target="appendix_pb">Packet Block</xref>, the
            number of packets dropped by the capture system between this
            packet and the previous one is not stored in the header, but
            rather in an option of the block itself.</t>

          </list>
        </t>

        <figure anchor="format_epb" title="Enhanced Packet Block Format">
          <artwork xml:space="preserve" name="" type="" align="center" alt="" width="" height="">
   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 = 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                       |
   +---------------------------------------------------------------+
</artwork>
        </figure>

        <t>The Enhanced Packet Block has the following fields:
          <list style="symbols">

            <t>Block Type: The block type of the Enhanced Packet Block is 6.</t>

            <t>Block Total Length: total size of this block, as described in
            <xref target="section_block"/>.</t>

            <t>Interface ID: it specifies the interface this packet comes
            from; the correct interface will be the one whose Interface
            Description Block (within the current Section of the file) is
            identified by the same number (see <xref target="section_idb"/>)
            of this field. The interface ID MUST be valid, which means that an
            matching interface description block MUST exist.</t>

            <t>Timestamp (High) and Timestamp (Low): upper 32 bits and
            lower 32 bits of a 64-bit timestamp. The timestamp is a
            single 64-bit unsigned integer that represents the number of
            units of time that have elapsed since 1970-01-01 00:00:00 UTC.
            The length of a unit of time is specified by the 'if_tsresol'
            option (see <xref target="format_idb"/>) of the Interface
            Description Block referenced by this packet. Note that,
            unlike timestamps in the libpcap file format, timestamps in
            Enhanced Packet Blocks are not saved as two 32-bit values
            that represent the seconds and microseconds that have
            elapsed since 1970-01-01 00:00:00 UTC. Timestamps in Enhanced
            Packet Blocks are saved as two 32-bit words that represent
            the upper and lower 32 bits of a single 64-bit quantity.</t>

            <t>Captured Packet Length: 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
            <xref target="format_idb"/>). The value of this field does
            not include the padding octets added at the end of the Packet
            Data field to align the Packet Data field to a 32-bit
            boundary.</t>

            <t>Original Packet Length: actual length of the packet when it was
            transmitted on the network. It can be different from Captured
            Packet Length if the packet has been truncated by the capture
            process.</t>

            <t>Packet Data: the data coming from the network, including
            link-layer headers. The actual length of this field is
            Captured Packet Length plus the padding to a 32-bit
            boundary. The format of the link-layer headers depends on
            the LinkType field specified in the Interface Description
            Block (see <xref target="section_idb"/>) and it is specified
            in the entry for that format in the <eref
            target="http://www.tcpdump.org/linktypes.html">the
            tcpdump.org link-layer header types registry</eref>.</t>

            <t>Options: optionally, a list of options (formatted according to
            the rules defined in <xref target="section_opt"/>) can be present.</t>

          </list>
        </t>

        <t>In addition to the options defined in <xref target="section_opt"/>,
        the following options are valid within this block:</t>

        <texttable anchor="options_epb" title="Enhanced Packet Block Options">
          <ttcol align="left">Name</ttcol>
          <ttcol align="left">Code</ttcol>
          <ttcol align="left">Length</ttcol>
          <ttcol align="left">Multiple allowed?</ttcol>

          <c>epb_flags</c>
          <c>2</c>
          <c>4</c>
          <c>no</c>

          <c>epb_hash</c>
          <c>3</c>
          <c>variable, minimum hash type-dependent</c>
          <c>yes</c>

          <c>epb_dropcount</c>
          <c>4</c>
          <c>8</c>
          <c>no</c>
        </texttable>

        <t>
          <list hangIndent="8" style="hanging">

            <t hangText="epb_flags:"><vspace blankLines="0"/>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 <xref
            target="section_epb_flags"/>.</t>

            <t>Example: '0'.</t>

            <t hangText="epb_hash:"><vspace blankLines="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=XXX), SHA-1 (algorithm octet = 4,
            size=XXX). 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.</t>

            <t>Examples: '02 EC 1D 87 97', '03 45 6E C2 17 7C 10 1E 3C 2E 99 6E C2 9A 3D 50 8E'.</t>

            <t hangText="epb_dropcount:"><vspace blankLines="0"/>The
            epb_dropcount option is a 64-bit 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.</t>

            <t>Example: '0'.</t>

          </list>
        </t>

        <section anchor="section_epb_flags" title="Enhanced Packet Block Flags Word">

          <t>The Enhanced Packet Block Flags Word is a 32-bit value that
          contains link-layer information about the packet.</t>

          <t>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:</t>

          <texttable title="">
            <ttcol align="left">Bit Number</ttcol>
            <ttcol align="left">Description</ttcol>

            <c>0-1</c>
            <c>Inbound / Outbound packet (00 = information not available, 01 =
            inbound, 10 = outbound)</c>

            <c>2-4</c>
            <c>Reception type (000 = not specified, 001 = unicast, 010 =
            multicast, 011 = broadcast, 100 = promiscuous).</c>

            <c>5-8</c>
            <c>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.</c>

            <c>9-15</c>
            <c>Reserved (MUST be set to zero).</c>

            <c>16-31</c>
            <c>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?).</c>

          </texttable>

          <t>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.</t>

        </section>

      </section>


      <section anchor="section_spb" title="Simple Packet Block">

        <t>The Simple Packet Block (SPB) is a lightweight container for
        storing the packets coming from the network. Its presence is
        optional.</t>

        <t>A Simple Packet Block is similar to an Enhanced Packet Block (see
        <xref target="section_epb"/>), 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.</t>

        <t>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.</t>

        <t><xref target="format_spb"/> shows the format of the Simple Packet
        Block.</t>

        <figure anchor="format_spb" title="Simple Packet Block Format">
          <artwork xml:space="preserve" name="" type="" align="center" alt="" width="" height="">
    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 = 0x00000003                    |
   +---------------------------------------------------------------+
 4 |                      Block Total Length                       |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 8 |                    Original Packet Length                     |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
12 /                                                               /
   /                          Packet Data                          /
   /              variable length, padded to 32 bits               /
   /                                                               /
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                      Block Total Length                       |
   +---------------------------------------------------------------+
 </artwork>
        </figure>

        <t>The Simple Packet Block has the following fields:
          <list style="symbols">
            <t>Block Type: The block type of the Simple Packet Block is 3.</t>

            <t>Block Total Length: total size of this block, as described in
            <xref target="section_block"/>.</t>

            <t>Original Packet Length: actual length of the packet when it was
            transmitted on the network. It can be different from length of the
            Packet Data field's length if the packet has been truncated by the
            capture process, in which case the SnapLen value in <xref
            target="section_idb"/> will be less than this Original Packet
            Length value, and the SnapLen value MUST be used to determine the
            size of the Packet Data field length.</t>

            <t>Packet Data: the data coming from the network, including
            link-layer headers. The length of this field can be derived
            from the field Block Total Length, present in the Block
            Header, and it is the minimum value among the SnapLen
            (present in the Interface Description Block) and the
            Original Packet Length (present in this header). The format
            of the data within this Packet Data field depends on the
            LinkType field specified in the Interface Description Block
            (see <xref target="section_idb"/>) and it is specified in
            the entry for that format in <eref
            target="http://www.tcpdump.org/linktypes.html">the
            tcpdump.org link-layer header types registry</eref>.</t>

          </list>
        </t>

        <t>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.</t>

        <t>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).</t>

        <t>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%.</t>

      </section>


      <section anchor="section_nrb" title="Name Resolution Block">

        <t>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.</t>

        <t>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.</t>

        <t>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.</t>

        <t>The format of the Name Resolution Block is shown in <xref
        target="format_nrb"/>.</t>

        <figure anchor="format_nrb" title="Name Resolution Block Format">
          <artwork xml:space="preserve" name="" type="" align="center" alt="" width="" height="">
    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 = 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                       |
   +---------------------------------------------------------------+
 </artwork>
        </figure>

        <t>The Name Resolution Block has the following fields:
          <list style="symbols">

            <t>Block Type: The block type of the Name Resolution Block is 4.</t>

            <t>Block Total Length: total size of this block, as described in
            <xref target="section_block"/>.</t>

          </list>
        </t>

        <t>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:</t>

        <texttable anchor="nrrecords" title="Name Resolution Block Records">
          <ttcol align="left">Name</ttcol>
          <ttcol align="left">Code</ttcol>
          <ttcol align="left">Length</ttcol>

          <c>nrb_record_end</c>
          <c>0x0000</c>
          <c>0</c>

          <c>nrb_record_ipv4</c>
          <c>0x0001</c>
          <c>variable</c>

          <c>nrb_record_ipv6</c>
          <c>0x0002</c>
          <c>variable</c>
        </texttable>

        <t>
          <list hangIndent="8" style="hanging">

            <t hangText="nrb_record_end:"><vspace blankLines="0"/>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.</t>

            <t hangText="nrb_record_ipv4:"><vspace blankLines="0"/>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.</t>

            <t>Example: '127 0 0 1'"localhost".</t>

            <t>[Open issue: is an empty string (i.e., just a zero-value octet)
            valid?]</t>

            <t hangText="nrb_record_ipv6:"><vspace blankLines="0"/>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.</t>

            <t>Example: '20 01 0d b8 00 00 00 00 00 00 00 00 12 34 56
            78'"somehost".</t>

            <t>[Open issue: is an empty string (i.e., just a zero-value octet)
            valid?]</t>

          </list>
        </t>

        <t>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.</t>

        <t>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.</t>

        <t>After the list of Name Resolution Records, optionally, a list of
        options (formatted according to the rules defined in <xref
        target="section_opt"/>) can be present.</t>

        <t>In addition to the options defined in <xref target="section_opt"/>,
        the following options are valid within this block:</t>

        <texttable  anchor="options_nrb" title="Name Resolution Block Options">
          <ttcol align="left">Name</ttcol>
          <ttcol align="left">Code</ttcol>
          <ttcol align="left">Length</ttcol>
          <ttcol align="left">Multiple allowed?</ttcol>

          <c>ns_dnsname</c>
          <c>2</c>
          <c>variable</c>
          <c>no</c>

          <c>ns_dnsIP4addr</c>
          <c>3</c>
          <c>4</c>
          <c>no</c>

          <c>ns_dnsIP6addr</c>
          <c>4</c>
          <c>16</c>
          <c>no</c>
        </texttable>

        <t>
          <list hangIndent="8" style="hanging">

            <t hangText="ns_dnsname:"><vspace blankLines="0"/>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.</t>

            <t>Example: "our_nameserver".</t>

            <t hangText="ns_dnsIP4addr:"><vspace blankLines="0"/>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.</t>

            <t>Example: '192 168 0 1'.</t>

            <t hangText="ns_dnsIP6addr:"><vspace blankLines="0"/>The
            ns_dnsIP6addr option specifies the IPv6 address of the DNS
            server.</t>

            <t>Example: '20 01 0d b8 00 00 00 00 00 00 00 00 12 34 56 78'.</t>

          </list>
        </t>

      </section>


      <section anchor="section_isb" title="Interface Statistics Block">

        <t>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.</t>

        <t>The format of the Interface Statistics Block is shown in <xref
        target="format_isb"/>.</t>

        <figure anchor="format_isb" title="Interface Statistics Block Format">
          <artwork xml:space="preserve" name="" type="" align="center" alt="" width="" height="">
    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 = 0x00000005                     |
   +---------------------------------------------------------------+
 4 |                      Block Total Length                       |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 8 |                         Interface ID                          |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
12 |                        Timestamp (High)                       |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
16 |                        Timestamp (Low)                        |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
20 /                                                               /
   /                      Options (variable)                       /
   /                                                               /
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                      Block Total Length                       |
   +---------------------------------------------------------------+
 </artwork>
        </figure>

        <t>The fields have the following meaning:
          <list style="symbols">

            <t>Block Type: The block type of the Interface Statistics Block is
            5.</t>

            <t>Block Total Length: total size of this block, as described in
            <xref target="section_block"/>.</t>

            <t>Interface ID: specifies the interface these statistics refers
            to; the correct interface will be the one whose Interface
            Description Block (within the current Section of the file) is
            identified by same number (see <xref target="section_idb"/>) of
            this field.</t>

            <t>Timestamp: time this statistics refers to. The format of the
            timestamp is the same already defined in the Enhanced Packet Block
            (<xref target="section_epb"/>); the length of a unit of time is
            specified by the 'if_tsresol' option (see <xref
            target="format_idb"/>) of the Interface Description Block
            referenced by this packet.</t>

            <t>Options: optionally, a list of options (formatted according to
            the rules defined in <xref target="section_opt"/>) can be present.</t>

          </list>
        </t>

        <t>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 <xref target="section_opt"/>,
        the following options are valid within this block:</t>

        <texttable anchor="options_isb" title="Interface Statistics Block Options">
          <ttcol align="left">Name</ttcol>
          <ttcol align="left">Code</ttcol>
          <ttcol align="left">Length</ttcol>
          <ttcol align="left">Multiple allowed?</ttcol>

          <c>isb_starttime</c>
          <c>2</c>
          <c>8</c>
          <c>no</c>

          <c>isb_endtime</c>
          <c>3</c>
          <c>8</c>
          <c>no</c>

          <c>isb_ifrecv</c>
          <c>4</c>
          <c>8</c>
          <c>no</c>

          <c>isb_ifdrop</c>
          <c>5</c>
          <c>8</c>
          <c>no</c>

          <c>isb_filteraccept</c>
          <c>6</c>
          <c>8</c>
          <c>no</c>

          <c>isb_osdrop</c>
          <c>7</c>
          <c>8</c>
          <c>no</c>

          <c>isb_usrdeliv</c>
          <c>8</c>
          <c>8</c>
          <c>no</c>
        </texttable>

        <t>
          <list hangIndent="8" style="hanging">

            <t hangText="isb_starttime:"><vspace blankLines="0"/>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 (<xref target="section_epb"/>); the length of a unit
            of time is specified by the 'if_tsresol' option (see <xref
            target="format_idb"/>) of the Interface Description Block
            referenced by this packet.</t>

            <t>Example: '96 c3 04 00 73 89 6a 65', in Little Endian, decodes
            to 2012-06-29 06:17:00.834163 UTC.</t>

            <t hangText="isb_endtime:"><vspace blankLines="0"/>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 (<xref
            target="section_epb"/>); the length of a unit of time is specified
            by the 'if_tsresol' option (see <xref target="format_idb"/>) of
            the Interface Description Block referenced by this packet.</t>

            <t>Example: '97 c3 04 00 aa 47 ca 64', in Little Endian, decodes
            to 2012-06-29 07:28:25.298858 UTC.</t>

            <t hangText="isb_ifrecv:"><vspace blankLines="0"/>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.</t>

            <t>Example: the decimal number 100.</t>

            <t hangText="isb_ifdrop:"><vspace blankLines="0"/>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.</t>

            <t>Example: '0'.</t>

            <t hangText="isb_filteraccept:"><vspace blankLines="0"/>The
            isb_filteraccept option specifies the 64-bit unsigned integer
            number of packets accepted by filter starting from the beginning
            of the capture.</t>

            <t>Example: the decimal number 100.</t>

            <t hangText="isb_osdrop:"><vspace blankLines="0"/>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.</t>

            <t>Example: '0'.</t>

            <t hangText="isb_usrdeliv:"><vspace blankLines="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.</t>

            <t>Example: '0'.</t>

          </list>
        </t>

        <t>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.</t>

      </section><!-- section_isb -->


      <section anchor="section_sdj_export" title="systemd Journal Export Block">

        <t>The <eref target="https://www.freedesktop.org/wiki/Software/systemd/">systemd</eref>
        <eref target="https://www.freedesktop.org/wiki/Software/systemd/export/">Journal
        Export Block</eref> is a lightweight containter for systemd
        Journal Export Format entry data.</t>

        <t>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
        databse-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.</t>

        <t>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.</t>

        <t><xref target="format_sdj_export"/> shows the format of the
        Journal Export Block.</t>

        <figure anchor="format_sdj_export" title="systemd Journal Export Block Format">
          <artwork xml:space="preserve" name="" type="" align="center" alt="" width="" height="">
    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 = 0x00000009                    |
   +---------------------------------------------------------------+
 4 |                      Block Total Length                       |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 8 /                                                               /
   /                         Journal Entry                         /
   /              variable length, padded to 32 bits               /
   /                                                               /
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                      Block Total Length                       |
   +---------------------------------------------------------------+
 </artwork>
        </figure>

        <t>The systemd Journal Export Block has the following fields:
          <list style="symbols">
            <t>Block Type: The block type of the Journal Export Block is 9.</t>

            <t>Block Total Length: total size of this block, as described in
            <xref target="section_block"/>.</t>

            <t>Journal Entry: A journal entry as described in the <eref
            target="https://www.freedesktop.org/wiki/Software/systemd/export/">Journal
            Export Format</eref> documentation. Entries consist of a
            series of field names followed by text or binary field data.
            Common field names can be found in the <eref
            target="https://www.freedesktop.org/software/systemd/man/systemd.journal-fields.html">systemd.journal-fields</eref>
            documentation. The __REALTIME_TIMESTAMP= field MUST be
            present and valid as described above. Entries are not
            guaranteed to be a multiple of four bytes and must be
            zero-padded. This allows the length of the entry to be be
            determined by finding the last non-zero byte in the Journal
            Entry data. An entry may contain an entry separator
            (trailing newline) as described in the Journal Export Format
            specification</t>

          </list>
        </t>

      </section><!-- section_sdj_export -->


      <section anchor="section_dsb" title="Decryption Secrets Block">

        <t>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.</t>

        <t>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.</t>

        <t>The structure of a
        Decryption Secrets Block is shown in <xref target="format_dsb"/>.</t>

        <figure anchor="format_dsb" title="Decryption Secrets Block Format">
          <artwork xml:space="preserve" name="" type="" align="center" alt="" width="" height="">
   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                         |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
12 |                         Secrets Length                        |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
16 /                                                               /
   /                          Secrets Data                         /
   /              (variable length, padded to 32 bits)             /
   /                                                               /
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   /                                                               /
   /                       Options (variable)                      /
   /                                                               /
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   /                       Block Total Length                      /
   +---------------------------------------------------------------+
</artwork>
        </figure>

        <t>The Decryption Secrets Block has the following fields.
          <list style="symbols">

            <t>Block Type: The block type of the Decryption Secrets Block is
            10.</t>

            <t>Block Total Length: total size of this block, as described in
            <xref target="section_block"/>.</t>

            <t>Secrets Type: a 32-bit unsigned integer identifier that describes
            the format of the following Secrets field. Requests for new Secrets
            Type codes should be sent to the <eref
            target="https://www.winpcap.org/mailman/listinfo/pcap-ng-format">pcap-ng-format mailing list</eref>.</t>

            <t>Secrets Length: size of the following Secrets field, without
            any padding octets.</t>

            <t>Secrets Data: binary data containing secrets, padded to a 32 bit
            boundary.</t>

            <t>Options: optionally, a list of options (formatted according to
            the rules defined in <xref target="section_opt"/>) can be present.
            No DSB-specific options are currently defined.
            </t>

          </list>
        </t>

        <t>The following is a list of Secrets Types.
          <list hangIndent="8" style="hanging">

            <t hangText="0x544c534b:"><vspace blankLines="0"/>TLS Key Log. This
            format is described at <eref
            target="https://developer.mozilla.org/NSS_Key_Log_Format">NSS Key
            Log Format</eref>. 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.</t>

          </list>
        </t>

      </section>


      <section anchor="section_custom_block" title="Custom Block">

        <t>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 <xref target="section_custom_option"/>. 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 <xref target="format_custom_block"/>.</t>

        <figure anchor="format_custom_block" title="Custom Block Format">
          <artwork xml:space="preserve" name="" type="" align="center" alt="" width="" height="">
   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 = 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                       |
   +---------------------------------------------------------------+
</artwork>
        </figure>

        <t>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 <xref target="section_vendor_copy"/> for details.</t>

        <t>The Custom Block has the following fields:
          <list style="symbols">

            <t>Block Type: The block type of the Custom Block is 0x00000BAD or
            0x40000BAD, as described previously.</t>

            <t>Block Total Length: total size of this block, as described in
            <xref target="section_block"/>.</t>

            <t>Private Enterprise Number: An IANA-assigned Private Enterprise
            Number identifying the organization which defined the Custom
            Block. See <xref target="section_vendor_uses"/> for details. The
            PEN number MUST be encoded using the same endianness as the Section
            Header Block it is within the scope of.</t>

            <t>Custom Data: the custom data, padded to a 32 bit boundary.</t>

            <t>Options: optionally, a list of options (formatted according to
            the rules defined in <xref target="section_opt"/>) can be present.
            Note that custom options for the Custom Block still use the custom
            option format and type code, as described in <xref
            target="section_custom_option"/>.</t>

          </list>
        </t>

      </section>

    </section>


    <section title="Experimental Blocks (deserve further investigation)">

      <section title="Alternative Packet Blocks (experimental)">

        <t>Can some other packet blocks (besides the ones described in the
        previous paragraphs) be useful?</t>

      </section>

      <section title="Compression Block (experimental)">

        <t>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 <xref
        target="formatcb"/>.</t>

        <figure anchor="formatcb" title="Compression Block Format">
          <artwork xml:space="preserve" name="" type="" align="left" alt="" width="" height="">
 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
+---------------------------------------------------------------+
|                        Block Type = ?                         |
+---------------------------------------------------------------+
|                      Block Total Length                       |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|  Compr. Type  |                                               |
+-+-+-+-+-+-+-+-+                                               |
|                                                               |
|                       Compressed Data                         |
|                                                               |
|  variable length, octet-aligned and padded to end on a 32-bit |
|                         boundary                              |
|                                                               |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                      Block Total Length                       |
+---------------------------------------------------------------+
 </artwork>
        </figure>

        <t>The fields have the following meaning:
          <list style="symbols">

            <t>Block Type: The block type of the Compression Block is not yet
            assigned.</t>

            <t>Block Total Length: total size of this block, as described in
            <xref target="section_block"/>.</t>

            <t>Compression Type: specifies the compression algorithm. Possible
            values for this field are 0 (uncompressed), 1 (Lempel Ziv), 2
            (Gzip), other?? Probably some kind of dumb and fast compression
            algorithm could be effective with some types of traffic (for
            example web), but which?</t>

            <t>Compressed Data: data of this block. Once decompressed, it is
            made of other blocks.</t>

          </list>
        </t>
      </section>


      <section title="Encryption Block (experimental)">

        <t>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 <xref target="formateb"/>.</t>

        <figure anchor="formateb" title="Encryption Block Format">
          <artwork xml:space="preserve" name="" type="" align="left" alt="" width="" height="">
 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
+---------------------------------------------------------------+
|                        Block Type = ?                         |
+---------------------------------------------------------------+
|                      Block Total Length                       |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|   Encr. Type  |                                               |
+-+-+-+-+-+-+-+-+                                               |
|                                                               |
|                       Encrypted Data                          |
|                                                               |
|                 variable length, octet-aligned                |
|                                                               |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                      Block Total Length                       |
+---------------------------------------------------------------+
 </artwork>
        </figure>

        <t>The fields have the following meaning:
          <list style="symbols">

            <t>Block Type: The block type of the Encryption Block is not yet
            assigned.</t>

            <t>Block Total Length: total size of this block, as described in
            <xref target="section_block"/>.</t>

            <t>Encryption Type: specifies the encryption algorithm. Possible
            values for this field are ??? (TODO) NOTE: this block should
            probably contain other fields, depending on the encryption
            algorithm. To be defined precisely.</t>

            <t>Encrypted Data: data of this block. Once decrypted, it
            originates other blocks.</t>

          </list>
        </t>
      </section>


      <section title="Fixed Length Block (experimental)">

        <t>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 <xref
        target="formatflm"/>. 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.</t>

        <figure anchor="formatflm" title="Fixed Length Block Format">
          <artwork xml:space="preserve" name="" type="" align="left" alt="" width="" height="">
 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
+---------------------------------------------------------------+
|                        Block Type = ?                         |
+---------------------------------------------------------------+
|                      Block Total Length                       |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|          Cell Size            |                               |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+                               |
|                                                               |
|                        Fixed Size Data                        |
|                                                               |
|                 variable length, octet-aligned                |
|                                                               |
|                                                               |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                      Block Total Length                       |
+---------------------------------------------------------------+
 </artwork>
        </figure>

        <t>The fields have the following meaning:
          <list style="symbols">

            <t>Block Type: The block type of the Fixed Length Block is not yet
            assigned.</t>

            <t>Block Total Length: total size of this block, as described in
            <xref target="section_block"/>.</t>

            <t>Cell size: the size of the blocks contained in the data
            field.</t>

            <t>Fixed Size Data: data of this block.</t>

          </list>
        </t>
      </section>


      <section title="Directory Block (experimental)">

        <t>If present, this block contains the following information:
          <list style="symbols">
            <t>number of indexed packets (N)</t>

            <t>table with position and length of any indexed packet (N
            entries)</t>

          </list>
        </t>

        <t>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.</t>

      </section>


      <section title="Traffic Statistics and Monitoring Blocks (experimental)">

        <t>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.</t>

      </section>


      <section title="Event/Security Block (experimental)">

        <t>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:

          <list style="symbols">
            <t>skipped, if the application doesn't know how to do with it</t>

            <t>processed independently by the packets. In other words, the
            applications skips the packets and processes only the alerts</t>

            <t>processed in relation to packets: for example, a security tool
            could load only the packets of the file that are near a security
            alert; a monitoring tool could skip the packets captured while the
            server was down.</t>

          </list>
        </t>
      </section>

    </section>


    <section anchor="section_vendor" title="Vendor-Specific Custom Extensions">

      <t>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.</t>

      <section anchor="section_vendor_uses" title="Supported Use-Cases">

        <t>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.</t>

        <t>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 number 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 <eref
        target="http://pen.iana.org/pen/PenApplication.page">http://pen.iana.org/pen/PenApplication.page</eref>.</t>

      </section>

      <section anchor="section_vendor_copy" title="Controlling Copy Behavior">

        <t>Both Custom Blocks and Custom Options support two different codes
        to distinguish their "copy" behavior: a code for when the block or
        option can be safely copied into a new pcapng file by a pcapng
        manipulating application, and a 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.</t>

        <t>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 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.</t>

      </section>

      <section anchor="section_vendor_strings" title="Strings vs. Bytes">

        <t>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.</t>

      </section>

      <section anchor="section_vendor_endian" title="Endianness Issues">

        <t>Implementers writing Custom Blocks or 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 Custom Option
        might be an arbitrary sequence of unknown octets to such machines, they
        cannot convert multi-byte values inside the Custom Data into the
        appropriate endianness.</t>

        <t>For example, a little-endian machine can create a new pcapng file
        and add some binary data Custom Options to some Block(s) in the file.
        This file can then be sent to a big-endian host, which will convert it
        to big-endian format if it re-writes the file. It will, however, leave
        the Custom Data payload alone (as little-endian format). If this file
        then gets sent back to the little-endian machine, then when that
        little-endian machine reads the file it will detect the 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.</t>

        <t>Therefore, the vendor should either encode all of their fields in a
        consistent manner, such as always in big-endian or always little-
        endian format, regardless of the host platform's endianness; or they
        should encode some flag in the Custom Data payload to indicate which
        endianness the rest of the payload is written in.</t>

      </section>

    </section>


    <section title="Recommended File Name Extension: .pcapng">

      <t>The recommended file name extension for the "PCAP Next Generation
      Capture File Format" specified in this document is ".pcapng".</t>

      <t>On Windows and OS X, 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.</t>

      <t>Please note: To avoid confusion (like the current usage of .cap for a
      plethora of different capture file formats) other file name extensions
      than .pcapng should be avoided.</t>

    </section>


    <section title="Conclusions">

      <t>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.</t>

    </section>


    <section title="Implementations">

      <t>Some known implementations that read or write the pcapng file format
      are listed on the <eref
      target="https://github.com/pcapng/pcapng/wiki/Implementations">pcapng
      GitHub wiki</eref>.</t>

    </section>


    <section title="Security Considerations">

      <t>TBD.</t>

    </section>

    <section title="IANA Considerations">
      <t>TBD.</t>

      <t>[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)]</t>

      <section anchor="section_block_code_registry" title="Standardized Block Type Codes">

        <t>Every Block is uniquely identified by a 32-bit integer value, stored
        in the Block Header.</t>

        <t>As pointed out in <xref target="section_block"></xref>, Block Type
        codes whose Most Significant Bit (bit 31) is set to 1 are reserved for
        local use by the application.</t>

        <t>All the remaining Block Type codes (0x00000000 to 0x7FFFFFFF) are
        standardized by this document. Requests for new Block Type codes
        should be sent to the <eref
        target="https://www.winpcap.org/mailman/listinfo/pcap-ng-format">pcap-ng-format mailing list</eref>.</t>

        <t>The following is a list of the Standardized Block Type Codes:</t>

        <texttable anchor="blockcodes" title="Standardized Block Type Codes">
          <ttcol align="left">Block Type Code</ttcol>
          <ttcol align="left">Description</ttcol>

          <c>0x00000000</c>
          <c>Reserved ???</c>

          <c>0x00000001</c>
          <c>
            <xref target="section_idb">Interface Description Block</xref>
          </c>

          <c>0x00000002</c>
          <c>
            <xref target="appendix_pb">Packet Block</xref>
          </c>

          <c>0x00000003</c>
          <c>
            <xref target="section_spb">Simple Packet Block</xref>
          </c>

          <c>0x00000004</c>
          <c>
            <xref target="section_nrb">Name Resolution Block</xref>
          </c>

          <c>0x00000005</c>
          <c>
            <xref target="section_isb">Interface Statistics Block</xref>
          </c>

          <c>0x00000006</c>
          <c>
            <xref target="section_epb" >Enhanced Packet Block</xref>
          </c>

          <c>0x00000007</c>
          <c>
            IRIG Timestamp Block (requested by Gianluca Varenni
            &lt;gianluca.varenni@cacetech.com&gt;, CACE Technologies LLC);
            code also used for <eref target="https://github.com/google/linux-sensor/blob/master/hone-pcapng.txt">Socket
            Aggregation Event Block</eref>
          </c>

          <c>0x00000008</c>
          <c>
            <eref target="https://en.wikipedia.org/wiki/ARINC_429">ARINC
            429</eref> in AFDX Encapsulation Information Block (requested by
            Gianluca Varenni &lt;gianluca.varenni@cacetech.com&gt;, CACE
            Technologies LLC)
          </c>

          <c>0x00000009</c>
          <c>
            <xref target="section_sdj_export">systemd Journal Export Block</xref>
          </c>

          <c>0x0000000A</c>
          <c>
            <xref target="section_dsb">Decryption Secrets Block</xref>
          </c>

          <c>0x00000101</c>
          <c>
            <eref target="https://github.com/HoneProject">Hone Project</eref>
            <eref target="https://github.com/HoneProject/Linux-Sensor/wiki/Augmented-PCAP-Next-Generation-Dump-File-Format">Machine
            Info Block</eref> (see also <eref target="https://github.com/google/linux-sensor/blob/master/hone-pcapng.txt">Google
            version</eref>)
          </c>

          <c>0x00000102</c>
          <c>
            <eref target="https://github.com/HoneProject">Hone Project</eref>
            <eref target="https://github.com/HoneProject/Linux-Sensor/wiki/Augmented-PCAP-Next-Generation-Dump-File-Format">Connection
            Event Block</eref> (see also <eref target="https://github.com/google/linux-sensor/blob/master/hone-pcapng.txt">Google
            version</eref>)
          </c>

          <c>0x00000201</c>
          <c>
            <eref target="https://github.com/draios/sysdig">Sysdig</eref>
            Machine Info Block
          </c>

          <c>0x00000202</c>
          <c>
            <eref target="https://github.com/draios/sysdig">Sysdig</eref>
            Process Info Block, version 1
          </c>

          <c>0x00000203</c>
          <c>
            <eref target="https://github.com/draios/sysdig">Sysdig</eref>
            FD List Block
          </c>

          <c>0x00000204</c>
          <c>
            <eref target="https://github.com/draios/sysdig">Sysdig</eref>
            Event Block
          </c>

          <c>0x00000205</c>
          <c>
            <eref target="https://github.com/draios/sysdig">Sysdig</eref>
            Interface List Block
          </c>

          <c>0x00000206</c>
          <c>
            <eref target="https://github.com/draios/sysdig">Sysdig</eref>
            User List Block
          </c>

          <c>0x00000207</c>
          <c>
            <eref target="https://github.com/draios/sysdig">Sysdig</eref>
            Process Info Block, version 2
          </c>

          <c>0x00000208</c>
          <c>
            <eref target="https://github.com/draios/sysdig">Sysdig</eref>
            Event Block with flags
          </c>

          <c>0x00000209</c>
          <c>
            <eref target="https://github.com/draios/sysdig">Sysdig</eref>
            Process Info Block, version 3
          </c>

          <c>0x00000210</c>
          <c>
            <eref target="https://github.com/draios/sysdig">Sysdig</eref>
            Process Info Block, version 4
          </c>

          <c>0x00000211</c>
          <c>
            <eref target="https://github.com/draios/sysdig">Sysdig</eref>
            Process Info Block, version 5
          </c>

          <c>0x00000212</c>
          <c>
            <eref target="https://github.com/draios/sysdig">Sysdig</eref>
            Process Info Block, version 6
          </c>

          <c>0x00000213</c>
          <c>
            <eref target="https://github.com/draios/sysdig">Sysdig</eref>
            Process Info Block, version 7
          </c>

          <c>0x00000BAD</c>
          <c>
            <xref target="section_custom_block">Custom Block that rewriters can
            copy into new files</xref>
          </c>

          <c>0x40000BAD</c>
          <c>
            <xref target="section_custom_block">Custom Block that rewriters should
            not copy into new files</xref>
          </c>

          <c>0x0A0D0D0A</c>
          <c>
            <xref target="section_shb" >Section Header Block</xref>
          </c>

          <c>0x0A0D0A00-0x0A0D0AFF</c>
          <c>Reserved. Used to detect trace files corrupted because of file
          transfers using the HTTP protocol in text mode.</c>

          <c>0x000A0D0A-0xFF0A0D0A</c>
          <c>Reserved. Used to detect trace files corrupted because of file
          transfers using the HTTP protocol in text mode.</c>

          <c>0x000A0D0D-0xFF0A0D0D</c>
          <c>Reserved. Used to detect trace files corrupted because of file
          transfers using the HTTP protocol in text mode.</c>

          <c>0x0D0D0A00-0x0D0D0AFF</c>
          <c>Reserved. Used to detect trace files corrupted because of file
          transfers using the FTP protocol in text mode.</c>

          <c>0x80000000-0xFFFFFFFF</c>
          <c>Reserved for local use.</c>

        </texttable>

        <t>[Open issue: reserve 0x40000000-0x7FFFFFFF for do-not-copy-bit
        range of base types?]</t>

      </section>

    </section>


    <section title='Contributors'>

      <t>Loris Degioanni and Gianluca Varenni were coauthoring this document
      before it was submitted to the IETF.</t>

    </section>


    <section title="Acknowledgments">

      <t>The authors wish to thank
      Anders Broman,
      Ulf Lamping,
      Richard Sharpe
      and many others for their invaluable comments.</t>

    </section>

  </middle>


<!--===========================================================================

    Back End - still within the <rfc> tag

============================================================================-->


  <back>
    <references title='Normative References'>
      <?rfc include='reference.RFC.2119'?>
    </references>

    <!--
    <references title='Informational References'>
    </references>
    -->

    <section anchor="appendix_pb" title="Packet Block (obsolete!)">

      <t>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.</t>

      <t>A Packet Block was a container for storing packets coming from the
      network.</t>

      <figure anchor="formatpb" title="Packet Block Format">
        <artwork xml:space="preserve" name="" type="" align="center" alt="" width="" height="">
    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 = 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                       |
   +---------------------------------------------------------------+
</artwork>
      </figure>

      <t>The Packet Block has the following fields:
        <list style="symbols">
          <t>Block Type: The block type of the Packet Block is 2.</t>

          <t>Block Total Length: total size of this block, as described in
          <xref target="section_block"/>.</t>

          <t>Interface ID: specifies the interface this packet comes from;
          the correct interface will be the one whose Interface Description
          Block (within the current Section of the file) is identified by the
          same number (see <xref target="section_idb"/>) of this field. The
          interface ID MUST be valid, which means that an matching interface
          description block MUST exist.</t>

          <t>Drops Count: a local drop counter. It specifies the number of
          packets lost (by the interface and the operating system) between
          this packet and the preceding one. The value xFFFF (in hexadecimal)
          is reserved for those systems in which this information is not
          available.</t>

          <t>Timestamp (High) and Timestamp (Low): timestamp of the packet.
          The format of the timestamp is the same as was already defined
          for the Enhanced Packet Block (<xref target="section_epb"/>).</t>

          <t>Captured Packet Length: 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
          <xref target="format_idb"/>). The value of this field does
          not include the padding octets added at the end of the Packet
          Data field to align the Packet Data field to a 32-bit
          boundary.</t>

          <t>Original Packet Length: actual length of the packet when it was
          transmitted on the network. It can be different from Captured Packet
          Length if the packet has been truncated by the capture process.</t>

          <t>Packet Data: the data coming from the network, including
          link-layer headers. The actual length of this field is
          Captured Packet Length plus the padding to a 32-bit
          boundary. The format of the link-layer headers depends on
          the LinkType field specified in the Interface Description
          Block (see <xref target="section_idb"/>) and it is specified
          in the entry for that format in the <eref
          target="http://www.tcpdump.org/linktypes.html">the
          tcpdump.org link-layer header types registry</eref>.</t>

          <t>Options: optionally, a list of options (formatted according to
          the rules defined in <xref target="section_opt"/>) can be present.</t>

        </list>
      </t>

      <t>In addition to the options defined in <xref target="section_opt"/>,
      the following options were valid within this block:</t>

      <texttable anchor="optionspb" title="Packet Block Options">
        <ttcol align="left">Name</ttcol>
        <ttcol align="left">Code</ttcol>
        <ttcol align="left">Length</ttcol>
          <ttcol align="left">Multiple allowed?</ttcol>

        <c>pack_flags</c>
        <c>2</c>
        <c>4</c>
        <c>no</c>

        <c>pack_hash</c>
        <c>3</c>
        <c>variable</c>
        <c>yes</c>
      </texttable>

      <t>
        <list hangIndent="8" style="hanging">

          <t hangText="pack_flags:"><vspace blankLines="0"/>The pack_flags
          option is the same as the epb_flags of the enhanced packet
          block.</t>

          <t>Example: '0'.</t>

          <t hangText="pack_hash:"><vspace blankLines="0"/>The pack_hash
          option is the same as the epb_hash of the enhanced packet block.</t>

          <t>Examples: '02 EC 1D 87 97', '03 45 6E C2 17 7C 10 1E 3C 2E 99 6E
          C2 9A 3D 50 8E'.</t>

        </list>
      </t>
    </section>


  </back>
</rfc>