Flatten vendor/libpcap and remove keyword expansion.

1 files changed, 1680 insertions, 0 deletions

diff --git a/doc/pcap.txt b/doc/pcap.txt
new file mode 100644
index 0000000..cfa6645
--- /dev/null
+++ b/doc/pcap.txt
@@ -0,0 +1,1680 @@
+
+
+Network Working Group                                       L. Degioanni
+Internet-Draft                                                  F. Risso
+Expires: August 30, 2004                           Politecnico di Torino
+                                                              March 2004
+
+
+                  PCAP New Generation Dump File Format
+                                  pcap
+
+Status of this Memo
+
+   This document is an Internet-Draft and is in full conformance with
+   all provisions of Section 10 of RFC2026.
+
+   Internet-Drafts are working documents of the Internet Engineering
+   Task Force (IETF), its areas, and its working groups. Note that other
+   groups may also distribute working documents as Internet-Drafts.
+
+   Internet-Drafts are draft documents valid for a maximum of six months
+   and may be updated, replaced, or obsoleted by other documents at any
+   time. It is inappropriate to use Internet-Drafts as reference
+   material or to cite them other than as "work in progress."
+
+   The list of current Internet-Drafts can be accessed at http://
+   www.ietf.org/ietf/1id-abstracts.txt.
+
+   The list of Internet-Draft Shadow Directories can be accessed at
+   http://www.ietf.org/shadow.html.
+
+   This Internet-Draft will expire on August 30, 2004.
+
+Copyright Notice
+
+   Copyright (C) The Internet Society (2004). All Rights Reserved.
+
+Abstract
+
+   This document describes a format to dump captured packets on a file.
+   This format is extensible and it is currently proposed for
+   implementation in the libpcap/WinPcap packet capture library.
+
+
+
+
+
+
+
+
+
+
+
+
+Degioanni & Risso       Expires August 30, 2004                 [Page 1]
+
+Internet-Draft    PCAP New Generation Dump File Format        March 2004
+
+
+Table of Contents
+
+   1.  Objectives . . . . . . . . . . . . . . . . . . . . . . . . . .  3
+   2.  General File Structure . . . . . . . . . . . . . . . . . . . .  4
+   2.1 General Block Structure  . . . . . . . . . . . . . . . . . . .  4
+   2.2 Block Types  . . . . . . . . . . . . . . . . . . . . . . . . .  5
+   2.3 Block Hierarchy and Precedence . . . . . . . . . . . . . . . .  5
+   2.4 Data format  . . . . . . . . . . . . . . . . . . . . . . . . .  6
+   3.  Block Definition . . . . . . . . . . . . . . . . . . . . . . .  8
+   3.1 Section Header Block (mandatory) . . . . . . . . . . . . . . .  8
+   3.2 Interface Description Block (mandatory)  . . . . . . . . . . .  9
+   3.3 Packet Block (optional)  . . . . . . . . . . . . . . . . . . . 13
+   3.4 Simple Packet Block (optional) . . . . . . . . . . . . . . . . 15
+   3.5 Name Resolution Block (optional) . . . . . . . . . . . . . . . 16
+   3.6 Interface Statistics Block (optional)  . . . . . . . . . . . . 18
+   4.  Options  . . . . . . . . . . . . . . . . . . . . . . . . . . . 21
+   5.  Experimental Blocks (deserved to a further investigation)  . . 23
+   5.1 Other Packet Blocks (experimental) . . . . . . . . . . . . . . 23
+   5.2 Compression Block (experimental) . . . . . . . . . . . . . . . 23
+   5.3 Encryption Block (experimental)  . . . . . . . . . . . . . . . 23
+   5.4 Fixed Length Block (experimental)  . . . . . . . . . . . . . . 24
+   5.5 Directory Block (experimental) . . . . . . . . . . . . . . . . 25
+   5.6 Traffic Statistics and Monitoring Blocks (experimental)  . . . 25
+   5.7 Event/Security Block (experimental)  . . . . . . . . . . . . . 25
+   6.  Conclusions  . . . . . . . . . . . . . . . . . . . . . . . . . 27
+   7.  Most important open issues . . . . . . . . . . . . . . . . . . 28
+       Intellectual Property and Copyright Statements . . . . . . . . 29
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Degioanni & Risso       Expires August 30, 2004                 [Page 2]
+
+Internet-Draft    PCAP New Generation Dump File Format        March 2004
+
+
+1. Objectives
+
+   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 does
+   not fit for some of the nowadays applications especially in terms of
+   extensibility.
+
+   This document proposes a new format for dumping packet traces. The
+   following goals are being pursued:
+
+   o  Extensibility: aside of some common functionalities, third parties
+      should be able to enrich the information embedded in the file with
+      proprietary extensions, which will be ignored by tools that are
+      not able to understand them.
+
+   o  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.
+
+   o  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.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Degioanni & Risso       Expires August 30, 2004                 [Page 3]
+
+Internet-Draft    PCAP New Generation Dump File Format        March 2004
+
+
+2. General File Structure
+
+2.1 General Block Structure
+
+   A capture file is organized in blocks, that are appended one to
+   another to form the file. All the blocks share a common format, which
+   is shown in Figure 1.
+
+       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, aligned to 32 bits */            /
+      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+      |                      Block Total Length                       |
+      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+                    Figure 1: Basic block structure.
+
+   The fields have the following meaning:
+
+   o  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 allow to save private data to the file and to
+      extend the file format.
+
+   o  Block Total Length: total size of this block, in bytes. For
+      instance, a block that does not have a body has a length of 12
+      bytes.
+
+   o  Block Body: content of the block.
+
+   o  Block Total Length: total size of this block, in bytes. This field
+      is duplicated for permitting backward file navigation.
+
+   This structure, shared among all blocks, makes easy to process a file
+   and to skip unneeded or unknown blocks. Blocks can be nested one
+   inside the others (NOTE: needed?). Some of the blocks are mandatory,
+   i.e. a dump file is not valid if they are not present, other are
+   optional.
+
+   The structure of the blocks allows to define other blocks if needed.
+   A parser that does non understand them can simply ignore their
+   content.
+
+
+
+Degioanni & Risso       Expires August 30, 2004                 [Page 4]
+
+Internet-Draft    PCAP New Generation Dump File Format        March 2004
+
+
+2.2 Block Types
+
+   The currently defined blocks are the following:
+
+   1.  Section Header Block: it defines the most important
+       characteristics of the capture file.
+
+   2.  Interface Description Block: it defines the most important
+       characteristics of the interface(s) used for capturing traffic.
+
+   3.  Packet Block: it contains a single captured packet, or a portion
+       of it.
+
+   4.  Simple Packet Block: it contains a single captured packet, or a
+       portion of it, with only a minimal set of information about it.
+
+   5.  Name Resolution Block: it defines the mapping from numeric
+       addresses present in the packet dump and the canonical name
+       counterpart.
+
+   6.  Capture Statistics Block: it defines how to store some
+       statistical data (e.g. packet dropped, etc) which can be useful
+       to undestand the conditions in which the capture has been made.
+
+   7.  Compression Marker Block: TODO
+
+   8.  Encryption Marker Block: TODO
+
+   9.  Fixed Length Marker Block: TODO
+
+   The following blocks instead are considered interesting but the
+   authors believe that they deserve more in-depth discussion before
+   being defined:
+
+   1.  Further Packet Blocks
+
+   2.  Directory Block
+
+   3.  Traffic Statistics and Monitoring Blocks
+
+   4.  Alert and Security Blocks
+
+   TODO Currently standardized Block Type codes are specified in
+   Appendix 1.
+
+2.3 Block Hierarchy and Precedence
+
+   The file must begin with a Section Header Block. However, more than
+
+
+
+Degioanni & Risso       Expires August 30, 2004                 [Page 5]
+
+Internet-Draft    PCAP New Generation Dump File Format        March 2004
+
+
+   one Section Header Block can be present on the dump, each one
+   covering the data following it till the next one (or the end of
+   file). A Section includes the data delimited by two Section Header
+   Blocks (or by a Section Header Block and the end of the file),
+   including the first Section Header Block.
+
+   In case an application cannot read a Section because of different
+   version number, it must skip everything until the next Section Header
+   Block. Note that, in order to properly skip the blocks until the next
+   section, all blocks must have the fields Type and Length at the
+   beginning. This is a mandatory requirement that must be maintained in
+   future versions of the block format.
+
+   Figure 2 shows two valid files: the first has a typical
+   configuration, with a single Section Header that covers the whole
+   file. The second one 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.
+
+      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+      | SHB v1.0  |                      Data                         |
+      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+      Typical configuration with a single Section Header Block
+
+
+      |--   1st Section   --|--   2nd Section   --|--  3rd Section  --|
+      |                                                               |
+      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+      | SHB v1.0  |  Data   | SHB V1.1  |  Data   | SHB V1.0  |  Data |
+      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+      Configuration with three different Section Header Blocks
+
+      Figure 2: File structure example: the Section Header Block.
+
+   NOTE: TO BE COMPLETED with some examples of other blocks
+
+2.4 Data format
+
+   Data contained in each section will always be saved according to the
+   characteristics (little endian / big endian) of the dumping machine.
+   This refers to all fields that are saved as numbers and that span
+   over two or more bytes.
+
+   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 dumps.
+
+
+
+Degioanni & Risso       Expires August 30, 2004                 [Page 6]
+
+Internet-Draft    PCAP New Generation Dump File Format        March 2004
+
+
+   TODO Probably we have to specify something more here. Is what we're
+   saying enough to avoid any kind of ambiguity?.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Degioanni & Risso       Expires August 30, 2004                 [Page 7]
+
+Internet-Draft    PCAP New Generation Dump File Format        March 2004
+
+
+3. Block Definition
+
+   This section details the format of the body of the blocks currently
+   defined.
+
+3.1 Section Header Block (mandatory)
+
+   The Section Header Block is mandatory. It identifies the beginning of
+   a section of the capture dump file. Its format is shown in Figure 3.
+
+       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
+      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+      |                            Magic                              |
+      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+      |              Major            |             Minor             |
+      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+      /                                                               /
+      /                      Options (variable)                       /
+      /                                                               /
+      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+                 Figure 3: Section Header Block format.
+
+   The meaning of the fields is:
+
+   o  Magic: magic number, whose value is the hexadecimal number
+      0x1A2B3C4D. This number can be used to distinguish section that
+      have been saved on little-endian machines from the one saved on
+      big-endian machines.
+
+   o  Major: number of the current mayor version of the format. Current
+      value is 1.
+
+   o  Minor: number of the current minor version of the format. Current
+      value is 0.
+
+   o  Options: optionally, a list of options (formatted according to the
+      rules defined in Section 4) can be present.
+
+   Aside form the options defined in Section 4, the following options
+   are valid within this block:
+
+   +----------------+----------------+----------------+----------------+
+   | Name           | Code           | Length         | Description    |
+   +----------------+----------------+----------------+----------------+
+   | Hardware       | 2              | variable       | An ascii       |
+   |                |                |                | string         |
+
+
+
+Degioanni & Risso       Expires August 30, 2004                 [Page 8]
+
+Internet-Draft    PCAP New Generation Dump File Format        March 2004
+
+
+   |                |                |                | containing the |
+   |                |                |                | description of |
+   |                |                |                | the hardware   |
+   |                |                |                | used to create |
+   |                |                |                | this section.  |
+   |                |                |                |                |
+   | Operating      | 3              | variable       | An ascii       |
+   | System         |                |                | string         |
+   |                |                |                | containing the |
+   |                |                |                | name of the    |
+   |                |                |                | operating      |
+   |                |                |                | system used to |
+   |                |                |                | create this    |
+   |                |                |                | section.       |
+   |                |                |                |                |
+   | User           | 3              | variable       | An ascii       |
+   | Application    |                |                | string         |
+   |                |                |                | containing the |
+   |                |                |                | name of the    |
+   |                |                |                | application    |
+   |                |                |                | used to create |
+   |                |                |                | this section.  |
+   +----------------+----------------+----------------+----------------+
+
+                                Table 1
+
+   The Section Header Block does not contain data but it rather
+   identifies a list of blocks (interfaces, packets) that are logically
+   correlated. This block does not contain any reference to the size of
+   the section it is currently delimiting, therefore the reader cannot
+   skip a whole section at once. In case a section must be skipped, the
+   user has to repeatedly skip all the blocks contained within it; this
+   makes the parsing of the file slower but it permits to append several
+   capture dumps at the same file.
+
+3.2 Interface Description Block (mandatory)
+
+   The Interface Description Block is mandatory. This block is needed to
+   specify the characteristics of the network interface on which the
+   capture has been made. In order to properly associate the captured
+   data to the corresponding interface, the Interface Description Block
+   must be defined before any other block that uses it; therefore, this
+   block is usually placed immediately after the Section Header Block.
+
+   An Interface Description Block is valid only inside the section which
+   it belongs to. The structure of a Interface Description Block is
+   shown in Figure 4.
+
+
+
+
+Degioanni & Risso       Expires August 30, 2004                 [Page 9]
+
+Internet-Draft    PCAP New Generation Dump File Format        March 2004
+
+
+       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
+      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+      |          Interface ID         |           LinkType            |
+      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+      |                            SnapLen                            |
+      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+      /                                                               /
+      /                      Options (variable)                       /
+      /                                                               /
+      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+             Figure 4: Interface Description Block format.
+
+   The meaning of the fields is:
+
+   o  Interface ID: a progressive number that identifies uniquely any
+      interface inside current section. Two Interface Description Blocks
+      can have the same Interface ID only if they are in different
+      sections of the file. The Interface ID is referenced by the packet
+      blocks.
+
+   o  LinkType: a value that defines the link layer type of this
+      interface.
+
+   o  SnapLen: maximum number of bytes dumped from each packet. The
+      portion of each packet that exceeds this value will not be stored
+      in the file.
+
+   o  Options: optionally, a list of options (formatted according to the
+      rules defined in Section 4) can be present.
+
+   In addition to the options defined in Section 4, the following
+   options are valid within this block:
+
+   +----------------+----------------+----------------+----------------+
+   | Name           | Code           | Length         | Description    |
+   +----------------+----------------+----------------+----------------+
+   | if_name        | 2              | Variable       | Name of the    |
+   |                |                |                | device used to |
+   |                |                |                | capture data.  |
+   |                |                |                |                |
+   | if_IPv4addr    | 3              | 8              | Interface      |
+   |                |                |                | network        |
+   |                |                |                | address and    |
+   |                |                |                | netmask.       |
+   |                |                |                |                |
+   | if_IPv6addr    | 4              | 17             | Interface      |
+
+
+
+Degioanni & Risso       Expires August 30, 2004                [Page 10]
+
+Internet-Draft    PCAP New Generation Dump File Format        March 2004
+
+
+   |                |                |                | network        |
+   |                |                |                | address and    |
+   |                |                |                | prefix length  |
+   |                |                |                | (stored in the |
+   |                |                |                | last byte).    |
+   |                |                |                |                |
+   | if_MACaddr     | 5              | 6              | Interface      |
+   |                |                |                | Hardware MAC   |
+   |                |                |                | address (48    |
+   |                |                |                | bits).         |
+   |                |                |                |                |
+   | if_EUIaddr     | 6              | 8              | Interface      |
+   |                |                |                | Hardware EUI   |
+   |                |                |                | address (64    |
+   |                |                |                | bits), if      |
+   |                |                |                | available.     |
+   |                |                |                |                |
+   | if_speed       | 7              | 8              | Interface      |
+   |                |                |                | speed (in      |
+   |                |                |                | bps).          |
+   |                |                |                |                |
+   | if_tsaccur     | 8              | 1              | Precision of   |
+   |                |                |                | timestamps. If |
+   |                |                |                | the Most       |
+   |                |                |                | Significant    |
+   |                |                |                | Bit is equal   |
+   |                |                |                | to zero, the   |
+   |                |                |                | remaining bits |
+   |                |                |                | indicates the  |
+   |                |                |                | accuracy as as |
+   |                |                |                | a negative     |
+   |                |                |                | power of 10    |
+   |                |                |                | (e.g. 6 means  |
+   |                |                |                | microsecond    |
+   |                |                |                | accuracy). If  |
+   |                |                |                | the Most       |
+   |                |                |                | Significant    |
+   |                |                |                | Bit is equal   |
+   |                |                |                | to zero, the   |
+   |                |                |                | remaining bits |
+   |                |                |                | indicates the  |
+   |                |                |                | accuracy as as |
+   |                |                |                | negative power |
+   |                |                |                | of 2 (e.g. 10  |
+   |                |                |                | means 1/1024   |
+   |                |                |                | of second). If |
+   |                |                |                | this option is |
+   |                |                |                | not present, a |
+
+
+
+Degioanni & Risso       Expires August 30, 2004                [Page 11]
+
+Internet-Draft    PCAP New Generation Dump File Format        March 2004
+
+
+   |                |                |                | precision of   |
+   |                |                |                | 10^-6 is       |
+   |                |                |                | assumed.       |
+   |                |                |                |                |
+   | if_tzone       | 9              | 4              | Time zone for  |
+   |                |                |                | GMT support    |
+   |                |                |                | (TODO: specify |
+   |                |                |                | better).       |
+   |                |                |                |                |
+   | if_flags       | 10             | 4              | Interface      |
+   |                |                |                | flags. (TODO:  |
+   |                |                |                | specify        |
+   |                |                |                | better.        |
+   |                |                |                | Possible       |
+   |                |                |                | flags:         |
+   |                |                |                | promiscuous,   |
+   |                |                |                | inbound/outbou |
+   |                |                |                | nd, traffic    |
+   |                |                |                | filtered       |
+   |                |                |                | during         |
+   |                |                |                | capture).      |
+   |                |                |                |                |
+   | if_filter      | 11             | variable       | The filter     |
+   |                |                |                | (e.g. "capture |
+   |                |                |                | only TCP       |
+   |                |                |                | traffic") used |
+   |                |                |                | to capture     |
+   |                |                |                | traffic. The   |
+   |                |                |                | first byte 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).        |
+   |                |                |                |                |
+   | if_opersystem  | 12             | variable       | An ascii       |
+   |                |                |                | string         |
+   |                |                |                | containing the |
+
+
+
+Degioanni & Risso       Expires August 30, 2004                [Page 12]
+
+Internet-Draft    PCAP New Generation Dump File Format        March 2004
+
+
+   |                |                |                | name of the    |
+   |                |                |                | operating      |
+   |                |                |                | system of the  |
+   |                |                |                | machine that   |
+   |                |                |                | hosts this     |
+   |                |                |                | interface.     |
+   |                |                |                | This can be    |
+   |                |                |                | different from |
+   |                |                |                | the same       |
+   |                |                |                | information    |
+   |                |                |                | that can be    |
+   |                |                |                | contained by   |
+   |                |                |                | the Section    |
+   |                |                |                | Header Block   |
+   |                |                |                | (Section 3.1)  |
+   |                |                |                | because the    |
+   |                |                |                | capture can    |
+   |                |                |                | have been done |
+   |                |                |                | on a remote    |
+   |                |                |                | machine.       |
+   +----------------+----------------+----------------+----------------+
+
+                                Table 2
+
+
+3.3 Packet Block (optional)
+
+   A Packet Block is the standard container for storing the packets
+   coming from the network. The 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 dump generation. The format of a
+   packet block is shown in Figure 5.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Degioanni & Risso       Expires August 30, 2004                [Page 13]
+
+Internet-Draft    PCAP New Generation Dump File Format        March 2004
+
+
+       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
+      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+      |         Interface ID          |          Drops Count          |
+      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+      |                        Timestamp (High)                       |
+      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+      |                        Timestamp (Low)                        |
+      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+      |                         Captured Len                          |
+      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+      |                          Packet Len                           |
+      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+      |                                                               |
+      |                          Packet Data                          |
+      |                                                               |
+      |              /* variable length, byte-aligned */              |
+      |                                                               |
+      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+      /                                                               /
+      /                      Options (variable)                       /
+      /                                                               /
+      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+                     Figure 5: Packet Block format.
+
+   The Packet Block has the following fields:
+
+   o  Interface ID: Specifies the interface this packet comes from, and
+      corresponds to the ID of one of the Interface Description Blocks
+      present in this section of the file (see Figure 4).
+
+   o  Drops Count: a local drop counter. It specified 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.
+
+   o  Timestamp (High): the most significative part of the timestamp. in
+      standard Unix format, i.e. from 1/1/1970.
+
+   o  Timestamp (Low): the less significative part of the timestamp. The
+      way to interpret this field is specified by the 'ts_accur' option
+      (see Figure 4) of the Interface Description block referenced by
+      this packet. If the Interface Description block does not contain a
+      'ts_accur' option, then this field is expressed in microseconds.
+
+   o  Captured Len: number of bytes captured from the packet (i.e. the
+
+
+
+Degioanni & Risso       Expires August 30, 2004                [Page 14]
+
+Internet-Draft    PCAP New Generation Dump File Format        March 2004
+
+
+      length of the Packet Data field). It will be the minimum value
+      among the actual Packet Length and the snapshot length (defined in
+      Figure 4).
+
+   o  Packet Len: actual length of the packet when it was transmitted on
+      the network. Can be different from Captured Len if the user wants
+      only a snapshot of the packet.
+
+   o  Packet Data: the data coming from the network, including
+      link-layer headers. The length of this field is Captured Len. The
+      format of the link-layer headers depends on the LinkType field
+      specified in the Interface Description Block (see Section 3.2) and
+      it is specified in Appendix XXX (TODO).
+
+   o  Options: optionally, a list of options (formatted according to the
+      rules defined in Section 4) can be present.
+
+
+3.4 Simple Packet Block (optional)
+
+   The Simple Packet Block is a lightweight container for storing the
+   packets coming from the network. Its presence is optional.
+
+   A Simple Packet Block is similar to a Packet Block (see Section 3.3),
+   but it is smaller, simpler to process and contains only a minimal set
+   of information. This block is preferred to the standard Packet Block
+   when performance or space occupation are critical factors, such as in
+   sustained traffic dump applications. A capture file can contain both
+   Packet Blocks and Simple Packet Blocks: for example, a capture tool
+   could switch from Packet Blocks to Simple Packet Blocks when the
+   hardware resources become critical.
+
+   The Simple Packet Block does not contain the Interface ID field.
+   Therefore, it must be assumed that all the Simple Packet Blocks have
+   been captured on the interface previously specified in the Interface
+   Description Block.
+
+   Figure 6 shows the format of the Simple Packet Block.
+
+
+
+
+
+
+
+
+
+
+
+
+
+Degioanni & Risso       Expires August 30, 2004                [Page 15]
+
+Internet-Draft    PCAP New Generation Dump File Format        March 2004
+
+
+       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
+      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+      |                          Packet Len                           |
+      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+      |                                                               |
+      |                          Packet Data                          |
+      |                                                               |
+      |              /* variable length, byte-aligned */              |
+      |                                                               |
+      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+                 Figure 6: Simple Packet Block format.
+
+   The Packet Block has the following fields:
+
+   o  Packet Len: actual length of the packet when it was transmitted on
+      the network. Can be different from captured len if the packet has
+      been truncated.
+
+   o  Packet data: the data coming from the network, including
+      link-layers headers. The length of this field can be derived from
+      the field Block Total Length, present in the Block Header.
+
+   The Simple Packet Block does not contain the timestamp because this
+   is 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.
+
+   The Simple Packet Block is very efficient in term of disk space: a
+   snapshot of length 100 bytes requires only 16 bytes of overhead,
+   which corresponds to an efficiency of more than 86%.
+
+3.5 Name Resolution Block (optional)
+
+   The Name Resolution Block 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, this prevents the need of a name resolution
+   in a delayed time, when the association between names and addresses
+   can be different from the one in use at capture time. Moreover, The
+   Name Resolution Block avoids the need of issuing a lot of DNS
+   requests every time the trace capture is opened, and allows to have
+   name resolution also when reading the capture with a machine not
+   connected to the network.
+
+   The format of the Name Resolution Block is shown in Figure 7.
+
+
+
+
+Degioanni & Risso       Expires August 30, 2004                [Page 16]
+
+Internet-Draft    PCAP New Generation Dump File Format        March 2004
+
+
+       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
+      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+      |      Record Type              |         Record Length         |
+      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+      |                       Record Value                            |
+      |              /* variable length, byte-aligned */              |
+      |               + + + + + + + + + + + + + + + + + + + + + + + + +
+      |               |               |               |               |
+      +-+-+-+-+-+-+-+-+ + + + + + + + + + + + + + + + + + + + + + + + +
+                . . . other records . . .
+      |  Record Type == end_of_recs   |  Record Length == 00          |
+      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+      /                                                               /
+      /                      Options (variable)                       /
+      /                                                               /
+      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+                Figure 7: Name Resolution Block format.
+
+   A Name Resolution Block is a zero-terminated list of records (in the
+   TLV format), each of which contains an association between a network
+   address and a name. There are three possible types of records:
+
+   +----------------+----------------+----------------+----------------+
+   | Name           | Code           | Length         | Description    |
+   +----------------+----------------+----------------+----------------+
+   | end_of_recs    | 0              | 0              | End of records |
+   |                |                |                |                |
+   | ip4_rec        | 1              | Variable       | Specifies an   |
+   |                |                |                | IPv4 address   |
+   |                |                |                | (contained in  |
+   |                |                |                | the first 4    |
+   |                |                |                | bytes),        |
+   |                |                |                | followed by    |
+   |                |                |                | one or more    |
+   |                |                |                | zero-terminate |
+   |                |                |                | d strings      |
+   |                |                |                | containing the |
+   |                |                |                | DNS entries    |
+   |                |                |                | for that       |
+   |                |                |                | address.       |
+   |                |                |                |                |
+   | ip6_rec        | 1              | Variable       | Specifies an   |
+   |                |                |                | IPv6 address   |
+   |                |                |                | (contained in  |
+   |                |                |                | the first 16   |
+   |                |                |                | bytes),        |
+
+
+
+Degioanni & Risso       Expires August 30, 2004                [Page 17]
+
+Internet-Draft    PCAP New Generation Dump File Format        March 2004
+
+
+   |                |                |                | followed by    |
+   |                |                |                | one or more    |
+   |                |                |                | zero-terminate |
+   |                |                |                | d strings      |
+   |                |                |                | containing the |
+   |                |                |                | DNS entries    |
+   |                |                |                | for that       |
+   |                |                |                | address.       |
+   +----------------+----------------+----------------+----------------+
+
+                                Table 3
+
+   After the list or Name Resolution Records, optionally, a list of
+   options (formatted according to the rules defined in Section 4) can
+   be present.
+
+   A Name Resolution Block is normally placed at the beginning of the
+   file, but no assumptions can be taken about its position. Name
+   Resolution Blocks can be added in a second time by tools that process
+   the file, like network analyzers.
+
+   In addiction to the options defined in Section 4, the following
+   options are valid within this block:
+
+   +----------------+----------------+----------------+----------------+
+   | Name           | Code           | Length         | Description    |
+   +----------------+----------------+----------------+----------------+
+   | ns_dnsname     | 2              | Variable       | An ascii       |
+   |                |                |                | string         |
+   |                |                |                | containing the |
+   |                |                |                | name of the    |
+   |                |                |                | machine (DNS   |
+   |                |                |                | server) used   |
+   |                |                |                | to perform the |
+   |                |                |                | name           |
+   |                |                |                | resolution.    |
+   +----------------+----------------+----------------+----------------+
+
+
+3.6 Interface Statistics Block (optional)
+
+   The Interface Statistics Block 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.
+
+   The format of the Interface Statistics Block is shown in Figure 8.
+
+
+
+
+Degioanni & Risso       Expires August 30, 2004                [Page 18]
+
+Internet-Draft    PCAP New Generation Dump File Format        March 2004
+
+
+       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
+      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+      |                         IfRecv                                |
+      |                          (high + low)                         |
+      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+      |                         IfDrop                                |
+      |                          (high + low)                         |
+      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+      |                         FilterAccept                          |
+      |                          (high + low)                         |
+      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+      |                         OSDrop                                |
+      |                          (high + low)                         |
+      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+      |                         UsrDelivered                          |
+      |                          (high + low)                         |
+      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+      |          Interface ID         |           Reserved            |
+      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+      /                                                               /
+      /                      Options (variable)                       /
+      /                                                               /
+      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+              Figure 8: Interface Statistics Block format.
+
+   The fields have the following meaning:
+
+   o  IfRecv: number of packets received from the interface during the
+      capture. This number is reported as a 64 bits value, in which the
+      most significat bits are located in the first four bytes of the
+      field.
+
+   o  IfDrop: number of packets dropped by the interface during the
+      capture due to lack of resources.
+
+   o  FilterAccept: number of packets accepeted by filter during current
+      capture.
+
+   o  OSDrop: number of packets dropped by the operating system during
+      the capture.
+
+   o  UsrDelivered: number of packets delivered to the user.
+      UsrDelivered can be different from the value 'FilterAccept -
+      OSDropped' because some packets could still lay in the OS buffers
+      when the capture ended.
+
+
+
+
+Degioanni & Risso       Expires August 30, 2004                [Page 19]
+
+Internet-Draft    PCAP New Generation Dump File Format        March 2004
+
+
+   o  Interface ID: reference to an Interface Description Block.
+
+   o  Reserved: Reserved to future use.
+
+   o  Options: optionally, a list of options (formatted according to the
+      rules defined in Section 4) can be present.
+
+   In addiction to the options defined in Section 4, the following
+   options are valid within this block:
+
+   +----------------+----------------+----------------+----------------+
+   | Name           | Code           | Length         | Description    |
+   +----------------+----------------+----------------+----------------+
+   | isb_starttime  | 2              | 8              | Time in which  |
+   |                |                |                | the capture    |
+   |                |                |                | started; time  |
+   |                |                |                | will be stored |
+   |                |                |                | in two blocks  |
+   |                |                |                | of four bytes  |
+   |                |                |                | each,          |
+   |                |                |                | containing the |
+   |                |                |                | timestamp in   |
+   |                |                |                | seconds and    |
+   |                |                |                | nanoseconds.   |
+   |                |                |                |                |
+   | isb_endtime    | 3              | 8              | Time in which  |
+   |                |                |                | the capture    |
+   |                |                |                | started; time  |
+   |                |                |                | will be stored |
+   |                |                |                | in two blocks  |
+   |                |                |                | of four bytes  |
+   |                |                |                | each,          |
+   |                |                |                | containing the |
+   |                |                |                | timestamp in   |
+   |                |                |                | seconds and    |
+   |                |                |                | nanoseconds.   |
+   +----------------+----------------+----------------+----------------+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Degioanni & Risso       Expires August 30, 2004                [Page 20]
+
+Internet-Draft    PCAP New Generation Dump File Format        March 2004
+
+
+4. Options
+
+   Almost all blocks have the possibility to embed optional fields.
+   Optional fields can be used to insert some information that may be
+   useful when reading data, but that it is not really needed for packet
+   processing. Therefore, each tool can be either read the content of
+   the optional fields (if any), or skip them at once.
+
+   Skipping all the optional fields at once is straightforward because
+   most of the blocks have a fixed length, therefore the field Block
+   Length (present in the General Block Structure, see  Section 2.1) can
+   be used to skip everything till the next block.
+
+   Options are a list of Type - Length - Value fields, each one
+   containing a single value:
+
+   o  Option Type (2 bytes): 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). In case
+      of vendor-specific extensions that have to be identified uniquely,
+      vendors must request an Option Code whose MSB is equal to zero.
+
+   o  Option Length (2 bytes): it contains the length of the following
+      'Option Value' field.
+
+   o  Option Value (variable length): it contains the value of the given
+      option. The length of this field as been specified by the Option
+      Length field.
+
+   Options may be repeated several times (e.g. an interface that has
+   several IP addresses associated to it). The option list is terminated
+   by a special code which is the 'End of Option'.
+
+   The format of the optional fields is shown in Figure 9.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Degioanni & Risso       Expires August 30, 2004                [Page 21]
+
+Internet-Draft    PCAP New Generation Dump File Format        March 2004
+
+
+       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, byte-aligned */              |
+      |               + + + + + + + + + + + + + + + + + + + + + + + + +
+      |               /               /               /               |
+      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+      /                                                               /
+      /                 . . . other options . . .                     /
+      /                                                               /
+      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+      |   Option Code == opt_endofopt  |  Option Length == 0          |
+      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+                       Figure 9: Options format.
+
+   The following codes can always be present in any optional field:
+
+   +----------------+----------------+----------------+----------------+
+   | Name           | Code           | Length         | Description    |
+   +----------------+----------------+----------------+----------------+
+   | opt_endofopt   | 0              | 0              | End of         |
+   |                |                |                | options: it is |
+   |                |                |                | used to        |
+   |                |                |                | delimit the    |
+   |                |                |                | end of the     |
+   |                |                |                | optional       |
+   |                |                |                | fields. This   |
+   |                |                |                | block cannot   |
+   |                |                |                | be repeated    |
+   |                |                |                | within a given |
+   |                |                |                | list of        |
+   |                |                |                | options.       |
+   |                |                |                |                |
+   | opt_comment    | 1              | variable       | Comment: it is |
+   |                |                |                | an ascii       |
+   |                |                |                | string         |
+   |                |                |                | containing a   |
+   |                |                |                | comment that   |
+   |                |                |                | is associated  |
+   |                |                |                | to the current |
+   |                |                |                | block.         |
+   +----------------+----------------+----------------+----------------+
+
+
+
+
+
+Degioanni & Risso       Expires August 30, 2004                [Page 22]
+
+Internet-Draft    PCAP New Generation Dump File Format        March 2004
+
+
+5. Experimental Blocks (deserved to a further investigation)
+
+5.1 Other Packet Blocks (experimental)
+
+   Can some other packet blocks (besides the two described in the
+   previous paragraphs) be useful?
+
+5.2 Compression Block (experimental)
+
+   The Compression Block is optional. A file can contain an arbitrary
+   number of these blocks. A Compression Block, as the name says, is
+   used to store compressed data. Its format is shown in Figure 10.
+
+       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
+      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+      |  Compr. Type  |                                               |
+      +-+-+-+-+-+-+-+-+                                               |
+      |                                                               |
+      |                       Compressed Data                         |
+      |                                                               |
+      |              /* variable length, byte-aligned */              |
+      |                                                               |
+      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+                  Figure 10: Compression Block format.
+
+   The fields have the following meaning:
+
+   o  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?
+
+   o  Compressed Data: data of this block. Once decompressed, it is made
+      of other blocks.
+
+
+5.3 Encryption Block (experimental)
+
+   The Encryption Block is optional. A file can contain an arbitrary
+   number of these blocks. An Encryption Block is used to sotre
+   encrypted data. Its format is shown in Figure 11.
+
+
+
+
+
+
+
+Degioanni & Risso       Expires August 30, 2004                [Page 23]
+
+Internet-Draft    PCAP New Generation Dump File Format        March 2004
+
+
+       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
+      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+      |   Encr. Type  |                                               |
+      +-+-+-+-+-+-+-+-+                                               |
+      |                                                               |
+      |                       Compressed Data                         |
+      |                                                               |
+      |              /* variable length, byte-aligned */              |
+      |                                                               |
+      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+                  Figure 11: Encryption Block format.
+
+   The fields have the following meaning:
+
+   o  Compression Type: specifies the encryption algorithm. Possible
+      values for this field are ??? NOTE: this block should probably
+      contain other fields, depending on the encryption algorithm. To be
+      define precisely.
+
+   o  Encrypted Data: data of this block. Once decripted, it consists of
+      other blocks.
+
+
+5.4 Fixed Length Block (experimental)
+
+   The Fixed Length Block is optional. A file can contain an arbitrary
+   number of these blocks. A Fixed Length Block can be used to optimize
+   the access to the file. Its format is shown in Figure 12. A Fixed
+   Length Block stores records with constant size. It contains a set of
+   Blocks (normally Packet Blocks or Simple Packet Blocks), of wihich 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.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Degioanni & Risso       Expires August 30, 2004                [Page 24]
+
+Internet-Draft    PCAP New Generation Dump File Format        March 2004
+
+
+       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
+      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+      |          Cell Size            |                               |
+      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+                               |
+      |                                                               |
+      |                        Fixed Size Data                        |
+      |                                                               |
+      |              /* variable length, byte-aligned */              |
+      |                                                               |
+      |                                                               |
+      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+                 Figure 12: Fixed Length Block format.
+
+   The fields have the following meaning:
+
+   o  Cell size: the size of the blocks contained in the data field.
+
+   o  Fixed Size Data: data of this block.
+
+
+5.5 Directory Block (experimental)
+
+   If present, this block contains the following information:
+
+   o  number of indexed packets (N)
+
+   o  table with position and length of any indexed packet (N entries)
+
+   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.
+
+5.6 Traffic Statistics and Monitoring Blocks (experimental)
+
+   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.
+
+5.7 Event/Security Block (experimental)
+
+   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:
+
+
+
+Degioanni & Risso       Expires August 30, 2004                [Page 25]
+
+Internet-Draft    PCAP New Generation Dump File Format        March 2004
+
+
+   o  skipped, if the application doesn't know how to do with it
+
+   o  processed independently by the packets. In other words, the
+      applications skips the packets and processes only the alerts
+
+   o  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 monitorg tool could skip the packets captured while the
+      server was down.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Degioanni & Risso       Expires August 30, 2004                [Page 26]
+
+Internet-Draft    PCAP New Generation Dump File Format        March 2004
+
+
+6. Conclusions
+
+   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 dump 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 benfit of the information
+   produced by the others. Two or more files can be concatenated
+   obtaining another valid file.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Degioanni & Risso       Expires August 30, 2004                [Page 27]
+
+Internet-Draft    PCAP New Generation Dump File Format        March 2004
+
+
+7. Most important open issues
+
+   o  Data, in the file, must be byte or word aligned? Currently, the
+      structure of this document is not consistent with respect to this
+      point.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Degioanni & Risso       Expires August 30, 2004                [Page 28]
+
+Internet-Draft    PCAP New Generation Dump File Format        March 2004
+
+
+Intellectual Property Statement
+
+   The IETF takes no position regarding the validity or scope of any
+   intellectual property or other rights that might be claimed to
+   pertain to the implementation or use of the technology described in
+   this document or the extent to which any license under such rights
+   might or might not be available; neither does it represent that it
+   has made any effort to identify any such rights. Information on the
+   IETF's procedures with respect to rights in standards-track and
+   standards-related documentation can be found in BCP-11. Copies of
+   claims of rights made available for publication and any assurances of
+   licenses to be made available, or the result of an attempt made to
+   obtain a general license or permission for the use of such
+   proprietary rights by implementors or users of this specification can
+   be obtained from the IETF Secretariat.
+
+   The IETF invites any interested party to bring to its attention any
+   copyrights, patents or patent applications, or other proprietary
+   rights which may cover technology that may be required to practice
+   this standard. Please address the information to the IETF Executive
+   Director.
+
+
+Full Copyright Statement
+
+   Copyright (C) The Internet Society (2004). All Rights Reserved.
+
+   This document and translations of it may be copied and furnished to
+   others, and derivative works that comment on or otherwise explain it
+   or assist in its implementation may be prepared, copied, published
+   and distributed, in whole or in part, without restriction of any
+   kind, provided that the above copyright notice and this paragraph are
+   included on all such copies and derivative works. However, this
+   document itself may not be modified in any way, such as by removing
+   the copyright notice or references to the Internet Society or other
+   Internet organizations, except as needed for the purpose of
+   developing Internet standards in which case the procedures for
+   copyrights defined in the Internet Standards process must be
+   followed, or as required to translate it into languages other than
+   English.
+
+   The limited permissions granted above are perpetual and will not be
+   revoked by the Internet Society or its successors or assignees.
+
+   This document and the information contained herein is provided on an
+   "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
+   TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
+   BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
+
+
+
+Degioanni & Risso       Expires August 30, 2004                [Page 29]
+
+Internet-Draft    PCAP New Generation Dump File Format        March 2004
+
+
+   HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
+   MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
+
+
+Acknowledgment
+
+   Funding for the RFC Editor function is currently provided by the
+   Internet Society.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Degioanni & Risso       Expires August 30, 2004                [Page 30]
+