doc: Add RFC documents

1 files changed, 339 insertions, 0 deletions

diff --git a/doc/rfc/rfc1761.txt b/doc/rfc/rfc1761.txt
new file mode 100644
index 0000000..20720ee
--- /dev/null
+++ b/doc/rfc/rfc1761.txt
@@ -0,0 +1,339 @@
+
+
+
+
+
+
+Network Working Group                                       B. Callaghan
+Request for Comments: 1761                                   R. Gilligan
+Category: Informational                           Sun Microsystems, Inc.
+                                                           February 1995
+
+
+               Snoop Version 2 Packet Capture File Format
+
+Status of this Memo
+
+   This memo provides information for the Internet community.  This memo
+   does not specify an Internet standard of any kind.  Distribution of
+   this memo is unlimited.
+
+Abstract
+
+   This paper describes the file format used by "snoop", a packet
+   monitoring and capture program developed by Sun.  This paper is
+   provided so that people can write compatible programs to generate and
+   interpret snoop packet capture files.
+
+1.  Introduction
+
+   The availability of tools to capture, display and interpret packets
+   traversing a network has proven extremely useful in debugging
+   networking problems.  The ability to capture packets and store them
+   for later analysis allows one to de-couple the tasks of collecting
+   information about a network problem and analysing that information.
+   The "snoop" program, developed by Sun, has the ability to capture
+   packets and store them in a file, and can interpret the packets
+   stored in capture files.  This RFC describes the file format that the
+   snoop program uses to store captured packets.  This paper was written
+   so that others may write programs to interpret the capture files
+   generated by snoop, or create capture files that can be interpreted
+   by snoop.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Callaghan & Gilligan                                            [Page 1]
+
+RFC 1761            Snoop Packet Capture File Format       February 1995
+
+
+2.  File Format
+
+   The snoop packet capture file is an array of octets structured as
+   follows:
+
+        +------------------------+
+        |                        |
+        |      File Header       |
+        |                        |
+        +------------------------+
+        |                        |
+        |     Packet Record      |
+        ~        Number 1        ~
+        |                        |
+        +------------------------+
+        .                        .
+        .                        .
+        .                        .
+        +------------------------+
+        |                        |
+        |     Packet Record      |
+        ~        Number N        ~
+        |                        |
+        +------------------------+
+
+   The File Header is a fixed-length field containing general
+   information about the packet file and the format of the packet
+   records it contains.  One or more variable-length Packet Record
+   fields follow the File Header field.  Each Packet Record field holds
+   the data of one captured packet.
+
+3. File Header
+
+   The structure of the File Header is as follows:
+
+    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+    |                                                               |
+    +                     Identification Pattern                    +
+    |                                                               |
+    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+    |                       Version Number = 2                      |
+    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+    |                         Datalink Type                         |
+    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+
+
+
+
+
+
+Callaghan & Gilligan                                            [Page 2]
+
+RFC 1761            Snoop Packet Capture File Format       February 1995
+
+
+        Identification Pattern:
+
+                A 64-bit (8 octet) pattern used to identify the file as
+                a snoop packet capture file.  The Identification Pattern
+                consists of the 8 hexadecimal octets:
+
+                        73 6E 6F 6F 70 00 00 00
+
+                This is the ASCII string "snoop" followed by three null
+                octets.
+
+        Version Number:
+
+                A 32-bit (4 octet) unsigned integer value representing
+                the version of the packet capture file being used.  This
+                document describes version number 2.  (Version number 1
+                was used in early implementations and is now obsolete.)
+
+        Datalink Type:
+
+                A 32-bit (4 octet) field identifying the type of
+                datalink header used in the packet records that follow.
+                The datalink type codes are listed in the table below:
+
+                Datalink Type           Code
+                -------------           ----
+                IEEE 802.3              0
+                IEEE 802.4 Token Bus    1
+                IEEE 802.5 Token Ring   2
+                IEEE 802.6 Metro Net    3
+                Ethernet                4
+                HDLC                    5
+                Character Synchronous   6
+                IBM Channel-to-Channel  7
+                FDDI                    8
+                Other                   9
+                Unassigned              10 - 4294967295
+
+4. Packet Record Format
+
+   Each packet record holds a partial or complete copy of one packet as
+   well as some descriptive information about that packet.  The packet
+   may be truncated in order to limit the amount of data to be stored in
+   the packet file.  In addition, the packet record may be padded in
+   order for it to align on a convenient machine-dependent boundary.
+   Each packet record holds 24 octets of descriptive information about
+   the packet, followed by the packet data, which is variable-length,
+   and an optional pad field.  The descriptive information is structured
+
+
+
+Callaghan & Gilligan                                            [Page 3]
+
+RFC 1761            Snoop Packet Capture File Format       February 1995
+
+
+   as six 32-bit (4-octet) integer values.
+
+   The structure of the packet record is as follows:
+
+    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+    |                        Original Length                        |
+    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+    |                        Included Length                        |
+    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+    |                      Packet Record Length                     |
+    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+    |                        Cumulative Drops                       |
+    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+    |                       Timestamp Seconds                       |
+    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+    |                     Timestamp Microseconds                    |
+    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+    |                                                               |
+    .                                                               .
+    .                          Packet Data                          .
+    .                                                               .
+    +                                               +- - - - - - - -+
+    |                                               |     Pad       |
+    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+        Original Length
+
+                32-bit unsigned integer representing the length in
+                octets of the captured packet as received via a network.
+
+        Included Length
+
+                32-bit unsigned integer representing the length of the
+                Packet Data field.  This is the number of octets of the
+                captured packet that are included in this packet record.
+                If the received packet was truncated, the Included
+                Length field will be less than the Original Length
+                field.
+
+        Packet Record Length
+
+                32-bit unsigned integer representing the total length of
+                this packet record in octets.  This includes the 24
+                octets of descriptive information, the length of the
+                Packet Data field, and the length of the Pad field.
+
+
+
+
+
+
+Callaghan & Gilligan                                            [Page 4]
+
+RFC 1761            Snoop Packet Capture File Format       February 1995
+
+
+        Cumulative Drops
+
+                32-bit unsigned integer representing the number of
+                packets that were lost by the system that created the
+                packet file between the first packet record in the
+                file and this one.  Packets may be lost because of
+                insufficient resources in the capturing system, or for
+                other reasons.  Note: some implementations lack the
+                ability to count dropped packets.  Those
+                implementations may set the cumulative drops value to
+                zero.
+
+        Timestamp Seconds
+
+                32-bit unsigned integer representing the time, in
+                seconds since January 1, 1970, when the packet arrived.
+
+        Timestamp Microseconds
+
+                32-bit unsigned integer representing microsecond
+                resolution of packet arrival time.
+
+        Packet Data
+
+                Variable-length field holding the packet that was
+                captured, beginning with its datalink header.  The
+                Datalink Type field of the file header can be used to
+                determine how to decode the datalink header.  The length
+                of the Packet Data field is given in the Included Length
+                field.
+
+        Pad
+
+                Variable-length field holding zero or more octets that
+                pads the packet record out to a convenient boundary.
+
+5.  Data Format
+
+   All integer values are stored in "big-endian" order, with the high-
+   order bits first.
+
+6.  Security Considerations
+
+   Security issues are not discussed in this memo.
+
+
+
+
+
+
+
+Callaghan & Gilligan                                            [Page 5]
+
+RFC 1761            Snoop Packet Capture File Format       February 1995
+
+
+Authors' Addresses
+
+   Brent Callaghan
+   Sun Microsystems, Inc.
+   2550 Garcia Avenue
+   Mailstop UMTV05-44
+   Mountain View, CA 94043-1100
+
+   Phone: 1-415-336-1051
+   EMail: brent.callaghan@eng.sun.com
+
+
+   Robert E. Gilligan
+   Sun Microsystems, Inc.
+   2550 Garcia Avenue
+   Mailstop UMTV05-44
+   Mountain View, CA 94043-1100
+
+   Phone: 1-415-336-1012
+   EMail: bob.gilligan@eng.sun.com
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Callaghan & Gilligan                                            [Page 6]
+