From 4bfd864f10b68b71482b35c818559068ef8d5797 Mon Sep 17 00:00:00 2001
From: Thomas Voss <mail@thomasvoss.com>
Date: Wed, 27 Nov 2024 20:54:24 +0100
Subject: doc: Add RFC documents

---
 doc/rfc/rfc760.txt | 2707 ++++++++++++++++++++++++++++++++++++++++++++++++++++
 1 file changed, 2707 insertions(+)
 create mode 100644 doc/rfc/rfc760.txt

(limited to 'doc/rfc/rfc760.txt')

diff --git a/doc/rfc/rfc760.txt b/doc/rfc/rfc760.txt
new file mode 100644
index 0000000..e20fbf0
--- /dev/null
+++ b/doc/rfc/rfc760.txt
@@ -0,0 +1,2707 @@
+
+
+RFC: 760
+IEN: 128
+                                    
+                                    
+                                    
+                                    
+                                    
+                                    
+                                    
+                              DOD STANDARD
+                                    
+                           INTERNET PROTOCOL
+                                    
+                                    
+                                    
+                              January 1980
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+                              prepared for
+                                    
+               Defense Advanced Research Projects Agency
+                Information Processing Techniques Office
+                         1400 Wilson Boulevard
+                       Arlington, Virginia  22209
+
+
+
+
+
+
+
+                                   by
+
+                     Information Sciences Institute
+                   University of Southern California
+                           4676 Admiralty Way
+                   Marina del Rey, California  90291
+
+January 1980                                                            
+                                                       Internet Protocol
+
+
+
+                           TABLE OF CONTENTS
+
+    PREFACE ........................................................ iii
+
+1.  INTRODUCTION ..................................................... 1
+
+  1.1  Motivation .................................................... 1
+  1.2  Scope ......................................................... 1
+  1.3  Interfaces .................................................... 1
+  1.4  Operation ..................................................... 2
+
+2.  OVERVIEW ......................................................... 5
+
+  2.1  Relation to Other Protocols ................................... 5
+  2.2  Model of Operation ............................................ 5
+  2.3  Function Description .......................................... 7
+
+3.  SPECIFICATION ................................................... 11
+
+  3.1  Internet Header Format ....................................... 11
+  3.2  Discussion ................................................... 21
+  3.3  Examples & Scenarios ......................................... 30
+  3.4  Interfaces ................................................... 34
+
+GLOSSARY ............................................................ 37
+
+REFERENCES .......................................................... 41
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+                                                                [Page i]
+
+
+                                                            January 1980
+Internet Protocol
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+[Page ii]                                                               
+
+
+January 1980                                                            
+                                                       Internet Protocol
+
+
+
+                                PREFACE
+
+
+
+This document specifies the DoD Standard Internet Protocol.  This
+document is based on five earlier editions of the ARPA Internet Protocol
+Specification, and the present text draws heavily from them.  There have
+been many contributors to this work both in terms of concepts and in
+terms of text.  This edition revises the details security,
+compartmentation, and precedence features of the internet protocol.
+
+                                                           Jon Postel
+
+                                                           Editor
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+                                                              [Page iii]
+
+
+January 1980 
+RFC: 760
+IEN: 128
+Replaces:  IENs 123, 111,
+80, 54, 44, 41, 28, 26
+
+                              DOD STANDARD
+
+                           INTERNET PROTOCOL
+
+
+
+                            1.  INTRODUCTION
+
+1.1.  Motivation
+
+  The Internet Protocol is designed for use in interconnected systems of
+  packet-switched computer communication networks.  Such a system has
+  been called a "catenet" [1].  The internet protocol provides for
+  transmitting blocks of data called datagrams from sources to
+  destinations, where sources and destinations are hosts identified by
+  fixed length addresses.  The internet protocol also provides for
+  fragmentation and reassembly of long datagrams, if necessary, for
+  transmission through "small packet" networks.
+
+1.2.  Scope
+
+  The internet protocol is specifically limited in scope to provide the
+  functions necessary to deliver a package of bits (an internet
+  datagram) from a source to a destination over an interconnected system
+  of networks.  There are no mechanisms to promote data reliability,
+  flow control, sequencing, or other services commonly found in
+  host-to-host protocols.
+
+1.3.  Interfaces
+
+  This protocol is called on by host-to-host protocols in an internet
+  environment.  This protocol calls on local network protocols to carry
+  the internet datagram to the next gateway or destination host.
+
+  For example, a TCP module would call on the internet module to take a
+  TCP segment (including the TCP header and user data) as the data
+  portion of an internet datagram.  The TCP module would provide the
+  addresses and other parameters in the internet header to the internet
+  module as arguments of the call.  The internet module would then
+  create an internet datagram and call on the local network interface to
+  transmit the internet datagram.
+
+  In the ARPANET case, for example, the internet module would call on a
+  local net module which would add the 1822 leader [2] to the internet
+  datagram creating an ARPANET message to transmit to the IMP.  The
+  ARPANET address would be derived from the internet address by the
+  local network interface and would be the address of some host in the
+  ARPANET, that host might be a gateway to other networks.
+
+
+                                                                [Page 1]
+
+
+                                                            January 1980
+Internet Protocol
+Introduction
+
+
+
+1.4.  Operation
+
+  The internet protocol implements two basic functions:  addressing and
+  fragmentation.
+
+  The internet modules use the addresses carried in the internet header
+  to transmit internet datagrams toward their destinations.  The
+  selection of a path for transmission is called routing.
+
+  The internet modules use fields in the internet header to fragment and
+  reassemble internet datagrams when necessary for transmission through
+  "small packet" networks.
+
+  The model of operation is that an internet module resides in each host
+  engaged in internet communication and in each gateway that
+  interconnects networks.  These modules share common rules for
+  interpreting address fields and for fragmenting and assembling
+  internet datagrams.  In addition, these modules (especially in
+  gateways) may have procedures for making routing decisions and other
+  functions.
+
+  The internet protocol treats each internet datagram as an independent
+  entity unrelated to any other internet datagram.  There are no
+  connections or logical circuits (virtual or otherwise).
+
+  The internet protocol uses four key mechanisms in providing its
+  service:  Type of Service, Time to Live, Options, and Header Checksum.
+
+  The Type of Service is used to indicate the quality of the service
+  desired; this may be thought of as selecting among Interactive, Bulk,
+  or Real Time, for example.  The type of service is an abstract or
+  generalized set of parameters which characterize the service choices
+  provided in the networks that make up the internet.  This type of
+  service indication is to be used by gateways to select the actual
+  transmission parameters for a particular network, the network to be
+  used for the next hop, or the next gateway when routing an internet
+  datagram.
+
+  The Time to Live is an indication of the lifetime of an internet
+  datagram.  It is set by the sender of the datagram and reduced at the
+  points along the route where it is processed.  If the time to live
+  reaches zero before the internet datagram reaches its destination, the
+  internet datagram is destroyed.  The time to live can be thought of as
+  a self destruct time limit.
+
+  The Options provide for control functions needed or useful in some
+  situations but unnecessary for the most common communications.  The
+
+
+
+[Page 2]                                                                
+
+
+January 1980                                                            
+                                                       Internet Protocol
+                                                            Introduction
+
+
+
+  options include provisions for timestamps, error reports, and special
+  routing.
+
+  The Header Checksum provides a verification that the information used
+  in processing internet datagram has been transmitted correctly.  The
+  data may contain errors.  If the header checksum fails, the internet
+  datagram is discarded at once by the entity which detects the error.
+
+  The internet protocol does not provide a reliable communication
+  facility.  There are no acknowledgments either end-to-end or
+  hop-by-hop.  There is no error control for data, only a header
+  checksum.  There are no retransmissions.  There is no flow control.
+
+  
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+                                                                [Page 3]
+
+
+                                                            January 1980
+Internet Protocol
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+[Page 4]                                                                
+
+
+January 1980                                                            
+                                                       Internet Protocol
+
+
+
+                              2.  OVERVIEW
+
+2.1.  Relation to Other Protocols
+
+  The following diagram illustrates the place of the internet protocol
+  in the protocol hierarchy:
+
+                                    
+                 +------+ +-----+ +-----+       +-----+
+                 |Telnet| | FTP | |Voice|  ...  |     |
+                 +------+ +-----+ +-----+       +-----+
+                       |   |         |             |   
+                      +-----+     +-----+       +-----+
+                      | TCP |     | RTP |  ...  |     |
+                      +-----+     +-----+       +-----+
+                         |           |             |   
+                      +-------------------------------+
+                      |       Internet Protocol       |
+                      +-------------------------------+
+                                     |                 
+                        +---------------------------+  
+                        |   Local Network Protocol  |  
+                        +---------------------------+  
+                                     |                 
+
+
+
+                         Protocol Relationships
+
+                               Figure 1.
+
+  Internet protocol interfaces on one side to the higher level
+  host-to-host protocols and on the other side to the local network
+  protocol.
+
+2.2.  Model of Operation
+
+  The  model of operation for transmitting a datagram from one
+  application program to another is illustrated by the following
+  scenario:
+
+    We suppose that this transmission will involve one intermediate
+    gateway.
+
+    The sending application program prepares its data and calls on its
+    local internet module to send that data as a datagram and passes the
+    destination address and other parameters as arguments of the call.
+
+    The internet module prepares a datagram header and attaches the data
+
+
+                                                                [Page 5]
+
+
+                                                            January 1980
+Internet Protocol
+Overview
+
+
+
+    to it.  The internet module determines a local network address for
+    this internet address, in this case it is the address of a gateway.
+    It sends this datagram and the local network address to the local
+    network interface.
+
+    The local network interface creates a local network header, and
+    attaches the datagram to it, then sends the result via the local
+    network.
+
+    The datagram arrives at a gateway host wrapped in the local network
+    header, the local network interface strips off this header, and
+    turns the datagram over to the internet module.  The internet module
+    determines from the internet address that the datagram should be
+    forwarded to another host in a second network.  The internet module
+    determines a local net address for the destination host.  It calls
+    on the local network interface for that network to send the
+    datagram.
+
+    This local network interface creates a local network header and
+    attaches the datagram sending the result to the destination host.
+
+    At this destination host the datagram is stripped of the local net
+    header by the local network interface and handed to the internet
+    module.
+
+    The internet module determines that the datagram is for an
+    application program in this host.  It passes the data to the
+    application program in response to a system call, passing the source
+    address and other parameters as results of the call.
+
+                                    
+   Application                                           Application
+   Program                                                   Program
+         \                                                   /      
+       Internet Module      Internet Module      Internet Module    
+             \                 /       \                /           
+             LNI-1          LNI-1      LNI-2         LNI-2          
+                \           /             \          /              
+               Local Network 1           Local Network 2            
+
+
+
+                            Transmission Path
+
+                                Figure 2
+
+
+
+
+
+[Page 6]                                                                
+
+
+January 1980                                                            
+                                                       Internet Protocol
+                                                                Overview
+
+
+
+2.3.  Function Description
+
+  The function or purpose of Internet Protocol is to move datagrams
+  through an interconnected set of networks.  This is done by passing
+  the datagrams from one internet module to another until the
+  destination is reached.  The internet modules reside in hosts and
+  gateways in the internet system.  The datagrams are routed from one
+  internet module to another through individual networks based on the
+  interpretation of an internet address.  Thus, one important mechanism
+  of the internet protocol is the internet address.
+
+  In the routing of messages from one internet module to another,
+  datagrams may need to traverse a network whose maximum packet size is
+  smaller than the size of the datagram.  To overcome this difficulty, a
+  fragmentation mechanism is provided in the internet protocol.
+
+  Addressing
+
+    A distinction is made between names, addresses, and routes [3].   A
+    name indicates what we seek.  An address indicates where it is.  A
+    route indicates how to get there.  The internet protocol deals
+    primarily with addresses.  It is the task of higher level (i.e.,
+    host-to-host or application) protocols to make the mapping from
+    names to addresses.   The internet module maps internet addresses to
+    local net addresses.  It is the task of lower level (i.e., local net
+    or gateways) procedures to make the mapping from local net 
+    addresses to routes.
+
+    Addresses are fixed length of four octets (32 bits).  An address
+    begins with a one octet network number, followed by a three octet
+    local address.  This three octet field is called the "rest" field.
+
+    Care must be taken in mapping internet addresses to local net
+    addresses; a single physical host must be able to act as if it were
+    several distinct hosts to the extent of using several distinct
+    internet addresses.  A host should also be able to have several
+    physical interfaces (multi-homing).
+
+    That is, a host should be allowed several physical interfaces to the
+    network with each having several logical internet addresses.
+
+    Examples of address mappings may be found in reference [4].
+
+  Fragmentation
+
+    Fragmentation of an internet datagram may be necessary when it
+    originates in a local net that allows a large packet size and must
+
+
+
+                                                                [Page 7]
+
+
+                                                            January 1980
+Internet Protocol
+Overview
+
+
+
+    traverse a local net that limits packets to a smaller size to reach
+    its destination.
+
+    An internet datagram can be marked "don't fragment."  Any internet
+    datagram so marked is not to be internet fragmented under any
+    circumstances.  If internet datagram marked don't fragment cannot be
+    delivered to its destination without fragmenting it, it is to be
+    discarded instead.
+
+    Fragmentation, transmission and reassembly across a local network
+    which is invisible to the internet protocol module is called
+    intranet fragmentation and may be used [5].
+
+    The internet fragmentation and reassembly procedure needs to be able
+    to break a datagram into an almost arbitrary number of pieces that
+    can be later reassembled.  The receiver of the fragments uses the
+    identification field to ensure that fragments of different datagrams
+    are not mixed.  The fragment offset field tells the receiver the
+    position of a fragment in the original datagram.  The fragment
+    offset and length determine the portion of the original datagram
+    covered by this fragment.  The more-fragments flag indicates (by
+    being reset) the last fragment.  These fields provide sufficient
+    information to reassemble datagrams.
+
+    The identification field is used to distinguish the fragments of one
+    datagram from those of another.  The originating protocol module of
+    an internet datagram sets the identification field to a value that
+    must be unique for that source-destination pair and protocol for the
+    time the datagram will be active in the internet system.  The
+    originating protocol module of a complete datagram sets the
+    more-fragments flag to zero and the fragment offset to zero.
+
+    To fragment a long internet datagram, an internet protocol module
+    (for example, in a gateway), creates two new internet datagrams and
+    copies the contents of the internet header fields from the long
+    datagram into both new internet headers.  The data of the long
+    datagram is divided into two portions on a 8 octet (64 bit) boundary
+    (the second portion might not be an integral multiple of 8 octets,
+    but the first must be).  Call the number of 8 octet blocks in the
+    first portion NFB (for Number of Fragment Blocks).  The first
+    portion of the data is placed in the first new internet datagram,
+    and the total length field is set to the length of the first
+    datagram.  The more-fragments flag is set to one.  The second
+    portion of the data is placed in the second new internet datagram,
+    and the total length field is set to the length of the second
+    datagram.  The more-fragments flag carries the same value as the
+    long datagram.  The fragment offset field of the second new internet
+
+
+
+[Page 8] 
+
+
+January 1980 
+                                                       Internet Protocol
+                                                                Overview
+
+
+
+    datagram is set to the value of that field in the long datagram plus
+    NFB.
+
+    This procedure can be generalized for an n-way split, rather than
+    the two-way split described.
+
+    To assemble the fragments of an internet datagram, an internet
+    protocol module (for example at a destination host) combines
+    internet datagram that all have the same value for the four fields:
+    identification, source, destination, and protocol.  The combination
+    is done by placing the data portion of each fragment in the relative
+    position indicated by the fragment offset in that fragment's
+    internet header.  The first fragment will have the fragment offset
+    zero, and the last fragment will have the more-fragments flag reset
+    to zero.
+
+    
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+                                                                [Page 9]
+
+
+                                                            January 1980
+Internet Protocol
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+[Page 10]                                                               
+
+
+January 1980                                                            
+                                                       Internet Protocol
+
+
+
+                           3.  SPECIFICATION
+
+3.1.  Internet Header Format
+
+  A summary of the contents of the internet header follows:
+
+                                    
+    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 
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |Version|  IHL  |Type of Service|          Total Length         |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |         Identification        |Flags|      Fragment Offset    |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |  Time to Live |    Protocol   |         Header Checksum       |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |                       Source Address                          |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |                    Destination Address                        |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |                    Options                    |    Padding    |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+                    Example Internet Datagram Header
+
+                               Figure 3.
+
+  Note that each tick mark represents one bit position.
+
+  Version:  4 bits
+
+    The Version field indicates the format of the internet header.  This
+    document describes version 4.
+
+  IHL:  4 bits
+
+    Internet Header Length is the length of the internet header in 32
+    bit words, and thus points to the beginning of the data.  Note that
+    the minimum value for a correct header is 5.
+
+
+
+
+
+
+
+
+
+
+
+
+                                                               [Page 11]
+
+
+                                                            January 1980
+Internet Protocol
+Specification
+
+
+
+  Type of Service:  8 bits
+
+    The Type of Service provides an indication of the abstract
+    parameters of the quality of service desired.  These parameters are
+    to be used to guide the selection of the actual service parameters
+    when transmitting a datagram through a particular network.  Several
+    networks offer service precedence, which somehow treats high
+    precedence traffic as more important than other traffic.  A few
+    networks offer a Stream service, whereby one can achieve a smoother
+    service at some cost.  Typically this involves the reservation of
+    resources within the network.  Another choice involves a low-delay
+    vs. high-reliability trade off.  Typically networks invoke more
+    complex (and delay producing) mechanisms as the need for reliability
+    increases.
+
+      Bits 0-2:  Precedence.
+      Bit    3:  Stream or Datagram.
+      Bits 4-5:  Reliability.
+      Bit    6:  Speed over Reliability.
+      Bits   7:  Speed.
+
+         0     1     2     3     4     5     6     7
+      +-----+-----+-----+-----+-----+-----+-----+-----+
+      |                 |     |           |     |     |
+      |   PRECEDENCE    | STRM|RELIABILITY| S/R |SPEED|
+      |                 |     |           |     |     |
+      +-----+-----+-----+-----+-----+-----+-----+-----+
+
+      PRECEDENCE          STRM      RELIABILITY  S/R      SPEED
+      111-Flash Override  1-STREAM  11-highest   1-speed  1-high
+      110-Flash           0-DTGRM   10-higher    0-rlblt  0-low
+      11X-Immediate                 01-lower
+      01X-Priority                  00-lowest
+      00X-Routine
+
+    The type of service is used to specify the treatment of the datagram
+    during its transmission through the internet system.  In the
+    discussion (section 3.2) below, a chart shows the relationship of
+    the internet type of service to the actual service provided on the
+    ARPANET, the SATNET, and the PRNET.
+
+  Total Length:  16 bits
+
+    Total Length is the length of the datagram, measured in octets,
+    including internet header and data.  This field allows the length of
+    a datagram to be up to 65,535 octets.  Such long datagrams are
+    impractical for most hosts and networks.  All hosts must be prepared
+    to accept datagrams of up to 576 octets (whether they arrive whole
+
+
+[Page 12]                                                               
+
+
+January 1980                                                            
+                                                       Internet Protocol
+                                                           Specification
+
+
+
+    or in fragments).  It is recommended that hosts only send datagrams
+    larger than 576 octets if they have assurance that the destination
+    is prepared to accept the larger datagrams.
+
+    The number 576 is selected to allow a reasonable sized data block to
+    be transmitted in addition to the required header information.  For
+    example, this size allows a data block of 512 octets plus 64 header
+    octets to fit in a datagram.  The maximal internet header is 60
+    octets, and a typical internet header is 20 octets, allowing a
+    margin for headers of higher level protocols.
+
+  Identification:  16 bits
+
+    An identifying value assigned by the sender to aid in assembling the
+    fragments of a datagram.
+
+  Flags:  3 bits
+
+    Various Control Flags.
+
+      Bit 0: reserved, must be zero
+      Bit 1: Don't Fragment This Datagram (DF).
+      Bit 2: More Fragments Flag (MF).
+
+          0   1   2
+        +---+---+---+
+        |   | D | M |
+        | 0 | F | F |
+        +---+---+---+
+
+  Fragment Offset:  13 bits
+
+    This field indicates where in the datagram this fragment belongs.
+    The fragment offset is measured in units of 8 octets (64 bits).  The
+    first fragment has offset zero.
+
+  Time to Live:  8 bits
+
+    This field indicates the maximum time the datagram is allowed to
+    remain the internet system.  If this field contains the value zero,
+    then the datagram should be destroyed.  This field is modified in
+    internet header processing.  The time is measured in units of
+    seconds.  The intention is to cause undeliverable datagrams to be
+    discarded.
+
+
+
+
+
+
+                                                               [Page 13]
+
+
+                                                            January 1980
+Internet Protocol
+Specification
+
+
+
+  Protocol:  8 bits
+
+    This field indicates the next level protocol used in the data
+    portion of the internet datagram.  The values for various protocols
+    are specified in reference [6].
+
+  Header Checksum:  16 bits
+
+    A checksum on the header only.  Since some header fields may change
+    (e.g., time to live), this is recomputed and verified at each point
+    that the internet header is processed.
+
+    The checksum algorithm is:
+
+      The checksum field is the 16 bit one's complement of the one's
+      complement sum of all 16 bit words in the header.  For purposes of
+      computing the checksum, the value of the checksum field is zero.
+
+    This is a simple to compute checksum and experimental evidence
+    indicates it is adequate, but it is provisional and may be replaced
+    by a CRC procedure, depending on further experience.
+
+  Source Address:  32 bits
+
+    The source address.  The first octet is the Source Network, and the
+    following three octets are the Source Local Address.
+
+  Destination Address:  32 bits
+
+    The destination address.  The first octet is the Destination
+    Network, and the following three octets are the Destination Local
+    Address.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+[Page 14]                                                               
+
+
+January 1980                                                            
+                                                       Internet Protocol
+                                                           Specification
+
+
+
+  Options:  variable
+
+    The option field is variable in length.  There may be zero or more
+    options.  There are two cases for the format of an option:
+
+      Case 1:  A single octet of option-type.
+
+      Case 2:  An option-type octet, an option-length octet, and the
+               actual option-data octets.
+
+    The option-length octet counts the option-type octet and the
+    option-length octet as well as the option-data octets.
+
+    The option-type octet is viewed as having 3 fields:
+
+      1 bit   reserved, must be zero
+      2 bits  option class,
+      5 bits  option number.
+
+    The option classes are:
+
+      0 = control
+      1 = internet error
+      2 = experimental debugging and measurement
+      3 = reserved for future use
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+                                                               [Page 15]
+
+
+                                                            January 1980
+Internet Protocol
+Specification
+
+
+
+    The following internet options are defined:
+
+      CLASS NUMBER LENGTH DESCRIPTION
+      ----- ------ ------ -----------
+        0     0      -    End of Option list.  This option occupies only
+                          1 octet; it has no length octet.
+        0     1      -    No Operation.  This option occupies only 1
+                          octet; it has no length octet.
+        0     2      4    Security.  Used to carry Security, and user
+                          group (TCC) information compatible with DOD
+                          requirements.
+        0     3     var.  Source Routing.  Used to route the internet
+                          datagram based on information supplied by the
+                          source.
+        0     7     var.  Return Route.  Used to record the route an
+                          internet datagram takes.
+        0     8      4    Stream ID.  Used to carry the stream
+                          identifier.
+        1     1     var.  General Error Report.  Used to report errors
+                          in internet datagram processing.
+        2     4      6    Internet Timestamp.
+        2     5      6    Satellite Timestamp.
+
+      
+
+    Specific Option Definitions
+
+      End of Option List
+
+        +--------+
+        |00000000|
+        +--------+
+          Type=0
+
+        This option indicates the end of the option list.  This might
+        not coincide with the end of the internet header according to
+        the internet header length.  This is used at the end of all
+        options, not the end of each option, and need only be used if
+        the end of the options would not otherwise coincide with the end
+        of the internet header.
+
+        May be copied, introduced, or deleted on fragmentation.
+
+
+
+
+
+
+
+
+[Page 16]                                                               
+
+
+January 1980                                                            
+                                                       Internet Protocol
+                                                           Specification
+
+
+
+      No Operation
+
+        +--------+
+        |00000001|
+        +--------+
+          Type=1
+
+        This option may be used between options, for example, to align
+        the beginning of a subsequent option on a 32 bit boundary.
+
+        May be copied, introduced, or deleted on fragmentation.
+
+      Security
+
+        This option provides a way for DOD hosts to send security and
+        TCC (closed user groups) parameters through networks whose
+        transport leader does not contain fields for this information.
+        The format for this option is as follows:
+
+          +--------+--------+---------+--------+
+          |00000010|00000100|000000SS |  TCC   |
+          +--------+--------+---------+--------+
+            Type=2  Length=4
+
+        Security:  2 bits
+
+          Specifies one of 4 levels of security
+
+            11-top secret
+            10-secret
+            01-confidential
+            00-unclassified
+
+        Transmission Control Code:  8 bits
+
+          Provides a means to compartmentalize traffic and define
+          controlled communities of interest among subscribers.
+
+        Note that this option does not require processing by the
+        internet module but does require that this information be passed
+        to higher level protocol modules.  The security and TCC
+        information might be used to supply class level and compartment
+        information for transmitting datagrams into or through
+        AUTODIN II.
+
+        Must be copied on fragmentation.
+
+
+
+
+                                                               [Page 17]
+
+
+                                                            January 1980
+Internet Protocol
+Specification
+
+
+
+      Source Route
+
+        +--------+--------+--------+---------//--------+
+        |00000011| length |        source route        |
+        +--------+--------+--------+---------//--------+
+          Type=3
+
+        The source route option provides a means for the source of an
+        internet datagram to supply routing information to be used by
+        the gateways in forwarding the datagram to the destination.
+
+        The option begins with the option type code.  The second octet
+        is the option length which includes the option type code and the
+        length octet, as well as length-2 octets of source route data.
+
+        A source route is composed of a series of internet addresses.
+        Each internet address is 32 bits or 4 octets.  The length
+        defaults to two, which indicates the source route is empty and
+        the remaining routing is to be based on the destination address
+        field.
+
+        If the address in destination address field has been reached and
+        this option's length is not two, the next address in the source
+        route replaces the address in the destination address field, and
+        is deleted from the source route and this option's length is
+        reduced by four.  (The Internet Header Length Field must be
+        changed also.)
+
+        Must be copied on fragmentation.
+
+      Return Route
+
+        +--------+--------+--------+---------//--------+
+        |00000111| length |        return route        |
+        +--------+--------+--------+---------//--------+
+          Type=7
+
+        The return route option provides a means to record the route of
+        an internet datagram.
+
+        The option begins with the option type code.  The second octet
+        is the option length which includes the option type code and the
+        length octet, as well as length-2 octets of return route data.
+
+        A return route is composed of a series of internet addresses.
+        The length defaults to two, which indicates the return route is
+        empty.
+
+
+
+[Page 18]                                                               
+
+
+January 1980                                                            
+                                                       Internet Protocol
+                                                           Specification
+
+
+
+        When an internet module routes a datagram it checks to see if
+        the return route option is present.  If it is, it inserts its
+        own internet address as known in the environment into which this
+        datagram is being forwarded into the return route at the front
+        of the address string and increments the length by four.
+
+        Not copied on fragmentation, goes in first fragment only.
+
+      Stream Identifier
+
+        +--------+--------+---------+--------+
+        |00001000|00000010|     Stream ID    |
+        +--------+--------+---------+--------+
+          Type=8  Length=4
+
+        This option provides a way for the 16-bit SATNET stream
+        identifier to be carried through networks that do not support
+        the stream concept.
+
+        Must be copied on fragmentation.
+
+      General Error Report
+
+        +--------+--------+--------+--------+--------+----//----+
+        |00100001| length |err code|        id       |          |
+        +--------+--------+--------+--------+--------+----//----+
+         Type=33
+
+        The general error report is used to report an error detected in
+        processing an internet datagram to the source internet module of
+        that datagram.  The "err code" indicates the type of error
+        detected, and the "id" is copied from the identification field
+        of the datagram in error, additional octets of error information
+        may be present depending on the err code.
+
+        If an internet datagram containing the general error report
+        option is found to be in error or must be discarded, no error
+        report is sent.
+
+        ERR CODE:
+
+          0 - Undetermined Error, used when no information is available
+          about the type of error or the error does not fit any defined
+          class.  Following the id should be as much of the datagram
+          (starting with the internet header) as fits in the option
+          space.
+
+          1 - Datagram Discarded, used when specific information is
+
+
+                                                               [Page 19]
+
+
+                                                            January 1980
+Internet Protocol
+Specification
+
+
+
+          available about the reason for discarding the datagram can be
+          reported.  Following the id should be the original (4-octets)
+          destination address, and the (1-octet) reason.
+
+            Reason   Description
+            ------   -----------
+               0     No Reason
+               1     No One Wants It - No higher level protocol or
+                     application program at destination wants this
+                     datagram.
+               2     Fragmentation Needed & DF - Cannot deliver with out
+                     fragmenting and has don't fragment bit set.
+               3     Reassembly Problem - Destination could not
+                     reassemble due to missing fragments when time to
+                     live expired.
+               4     Gateway Congestion - Gateway discarded datagram due
+                     to congestion.
+
+        The error report is placed in a datagram with the following
+        values in the internet header fields:
+
+          Version:  Same as the datagram in error.
+          IHL:  As computed.
+          Type of Service:  Zero.
+          Total Length:  As computed.
+          Identification:  A new identification is selected.
+          Flags:  Zero.
+          Fragment Offset:  Zero.
+          Time to Live:  Sixty.
+          Protocol:  Same as the datagram in error.
+          Header Checksum:  As computed.
+          Source Address:  Address of the error reporting module.
+          Destination Address:  Source address of the datagram in error.
+          Options:  The General Error Report Option.
+          Padding:  As needed.
+
+        Not copied on fragmentation, goes with first fragment.
+
+      Internet Timestamp
+
+        +--------+--------+--------+--------+--------+--------+
+        |01000100|00000100|        time in milliseconds       |
+        +--------+--------+--------+--------+--------+--------+
+         Type=68  Length=6
+
+        The data of the timestamp is a 32 bit time measured in
+        milliseconds.
+
+
+
+[Page 20]                                                               
+
+
+January 1980                                                            
+                                                       Internet Protocol
+                                                           Specification
+
+
+
+        Not copied on fragmentation, goes with first fragment
+
+      Satellite Timestamp
+
+        +--------+--------+--------+--------+--------+--------+
+        |01000101|00000100|        time in milliseconds       |
+        +--------+--------+--------+--------+--------+--------+
+         Type=69  Length=6
+
+        The data of the timestamp is a 32 bit time measured in
+        milliseconds.
+
+        Not copied on fragmentation, goes with first fragment
+
+  Padding:  variable
+
+    The internet header padding is used to ensure that the internet
+    header ends on a 32 bit boundary.  The padding is zero.
+
+3.2.  Discussion
+
+  The implementation of a protocol must be robust.  Each implementation
+  must expect to interoperate with others created by different
+  individuals.  While the goal of this specification is to be explicit
+  about the protocol there is the possibility of differing
+  interpretations.  In general, an implementation should be conservative
+  in its sending behavior, and liberal in its receiving behavior.  That
+  is, it should be careful to send well-formed datagrams, but should
+  accept any datagram that it can interpret (e.g., not object to
+  technical errors where the meaning is still clear).
+
+  The basic internet service is datagram oriented and provides for the
+  fragmentation of datagrams at gateways, with reassembly taking place
+  at the destination internet protocol module in the destination host.
+  Of course, fragmentation and reassembly of datagrams within a network
+  or by private agreement between the gateways of a network is also
+  allowed since this is transparent to the internet protocols and the
+  higher-level protocols.  This transparent type of fragmentation and
+  reassembly is termed "network-dependent" (or intranet) fragmentation
+  and is not discussed further here.
+
+  Internet addresses distinguish sources and destinations to the host
+  level and provide a protocol field as well.  It is assumed that each
+  protocol will provide for whatever multiplexing is necessary within a
+  host.
+
+
+
+
+
+                                                               [Page 21]
+
+
+                                                            January 1980
+Internet Protocol
+Specification
+
+
+
+  Addressing
+
+    The 8 bit network number, which is the first octet of the address,
+    has a value as specified in reference [6].
+
+    The 24 bit local address, assigned by the local network, should
+    allow for a single physical host to act as several distinct internet
+    hosts.  That is, there should be mapping between internet host
+    addresses and network/host interfaces that allows several internet
+    addresses to correspond to one interface.  It should also be allowed
+    for a host to have several physical interfaces and to treat the
+    datagrams from several of them as if they were all addressed to a
+    single host.  Address mappings between internet addresses and
+    addresses for ARPANET, SATNET, PRNET, and other networks are
+    described in reference [4].
+
+  Fragmentation and Reassembly.
+
+    The internet identification field (ID) is used together with the
+    source and destination address, and the protocol fields, to identify
+    datagram fragments for reassembly.
+
+    The More Fragments flag bit (MF) is set if the datagram is not the
+    last fragment.  The Fragment Offset field identifies the fragment
+    location, relative to the beginning of the original unfragmented
+    datagram.  Fragments are counted in units of 8 octets.  The
+    fragmentation strategy is designed so than an unfragmented datagram
+    has all zero fragmentation information (MF = 0, fragment offset =
+    0).  If an internet datagram is fragmented, its data portion must be
+    broken on 8 octet boundaries.
+
+    This format allows 2**13 = 8192 fragments of 8 octets each for a
+    total of 65,536 octets.  Note that this is consistent with the the
+    datagram total length field.
+
+    When fragmentation occurs, some options are copied, but others
+    remain with the first fragment only.
+
+    Every internet module must be able to forward a datagram of 68
+    octets without further fragmentation.  This is because an internet
+    header may be up to 60 octets, and the minimum fragment is 8 octets.
+
+    Every internet destination must be able to receive a datagram of 576
+    octets either in one piece or in fragments to be reassembled.
+
+
+
+
+
+
+[Page 22]                                                               
+
+
+January 1980                                                            
+                                                       Internet Protocol
+                                                           Specification
+
+
+
+    The fields which may be affected by fragmentation include:
+
+      (1) options field
+      (2) more fragments flag
+      (3) fragment offset
+      (4) internet header length field
+      (5) total length field
+      (6) header checksum
+
+    If the Don't Fragment flag (DF) bit is set, then internet
+    fragmentation of this datagram is NOT permitted, although it may be
+    discarded.  This can be used to prohibit fragmentation in cases
+    where the receiving host does not have sufficient resources to
+    reassemble internet fragments.
+
+    General notation in the following pseudo programs: "=<" means "less
+    than or equal", "#" means "not equal", "=" means "equal", "<-" means
+    "is set to".  Also, "x to y" includes x and excludes y; for example,
+    "4 to 7" would include 4, 5, and 6 (but not 7).
+
+    Fragmentation Procedure
+
+      The maximum sized datagram that can be transmitted through the
+      next network is called the maximum transmission unit (MTU).
+
+      If the total length is less than or equal the maximum transmission
+      unit then submit this datagram to the next step in datagram
+      processing; otherwise cut the datagram into two fragments, the
+      first fragment being the maximum size, and the second fragment
+      being the rest of the datagram.  The first fragment is submitted
+      to the next step in datagram processing, while the second fragment
+      is submitted to this procedure in case it still too large.
+
+      Notation:
+
+        FO    -  Fragment Offset
+        IHL   -  Internet Header Length
+        MF    -  More Fragments flag
+        TL    -  Total Length
+        OFO   -  Old Fragment Offset
+        OIHL  -  Old Internet Header Length
+        OMF   -  Old More Fragments flag
+        OTL   -  Old Total Length
+        NFB   -  Number of Fragment Blocks
+        MTU   -  Maximum Transmission Unit
+
+
+
+
+
+                                                               [Page 23]
+
+
+                                                            January 1980
+Internet Protocol
+Specification
+
+
+
+      Procedure:
+
+        IF TL =< MTU THEN Submit this datagram to the next step
+             in datagram processing ELSE
+        To produce the first fragment:
+        (1)  Copy the original internet header;
+        (2)  OIHL <- IHL; OTL <- TL; OFO <- FO; OMF <- MF;
+        (3)  NFB <- (MTU-IHL*4)/8;
+        (4)  Attach the first NFB*8 data octets;
+        (5)  Correct the header:
+             MF <- 1;  TL <- (IHL*4)+(NFB*8);
+             Recompute Checksum;
+        (6)  Submit this fragment to the next step in
+             datagram processing;
+        To produce the second fragment:
+        (7)  Selectively copy the internet header (some options
+             are not copied, see option definitions);
+        (8)  Append the remaining data;
+        (9)  Correct the header:
+             IHL <- (((OIHL*4)-(length of options not copied))+3)/4;
+             TL <- OTL - NFB*8 - (OIHL-IHL)*4);
+             FO <- OFO + NFB;  MF <- OMF;  Recompute Checksum;
+        (10) Submit this fragment to the fragmentation test; DONE.
+
+    Reassembly Procedure
+
+      For each datagram the buffer identifier is computed as the
+      concatenation of the source, destination, protocol, and
+      identification fields.  If this is a whole datagram (that is both
+      the fragment offset and the more fragments  fields are zero), then
+      any reassembly resources associated with this buffer identifier
+      are released and the datagram is forwarded to the next step in
+      datagram processing.
+
+      If no other fragment with this buffer identifier is on hand then
+      reassembly resources are allocated.  The reassembly resources
+      consist of a data buffer, a header buffer, a fragment block bit
+      table, a total data length field, and a timer.  The data from the
+      fragment is placed in the data buffer according to its fragment
+      offset and length, and bits are set in the fragment block bit
+      table corresponding to the fragment blocks received.
+
+      If this is the first fragment (that is the fragment offset is
+      zero)  this header is placed in the header buffer.  If this is the
+      last fragment ( that is the more fragments field is zero) the
+      total data length is computed.  If this fragment completes the
+      datagram (tested by checking the bits set in the fragment block
+      table), then the datagram is sent to the next step in datagram
+
+
+[Page 24]                                                               
+
+
+January 1980                                                            
+                                                       Internet Protocol
+                                                           Specification
+
+
+
+      processing; otherwise the timer is set to the maximum of the
+      current timer value and the value of the time to live field from
+      this fragment; and the reassembly routine gives up control.
+
+      If the timer runs out, the all reassembly resources for this
+      buffer identifier are released.  The initial setting of the timer
+      is a lower bound on the reassembly waiting time.  This is because
+      the waiting time will be increased if the Time to Live in the
+      arriving fragment is greater than the current timer value but will
+      not be decreased if it is less.  The maximum this timer value
+      could reach is the maximum time to live (approximately 4.25
+      minutes).  The current recommendation for the initial timer
+      setting is 15 seconds.  This may be changed as experience with
+      this protocol accumulates.  Note that the choice of this parameter
+      value is related to the buffer capacity available and the data
+      rate of the transmission medium; that is, data rate times timer
+      value equals buffer size (e.g., 10Kb/s X 15s = 150Kb).
+
+      Notation:
+
+        FO    -  Fragment Offset
+        IHL   -  Internet Header Length
+        MF    -  More Fragments flag
+        TTL   -  Time To Live
+        NFB   -  Number of Fragment Blocks
+        TL    -  Total Length
+        TDL   -  Total Data Length
+        BUFID -  Buffer Identifier
+        RCVBT -  Fragment Received Bit Table
+        TLB   -  Timer Lower Bound
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+                                                               [Page 25]
+
+
+                                                            January 1980
+Internet Protocol
+Specification
+
+
+
+      Procedure:
+
+        (1)  BUFID <- source|destination|protocol|identification;
+        (2)  IF FO = 0 AND MF = 0
+        (3)     THEN IF buffer with BUFID is allocated
+        (4)             THEN flush all reassembly for this BUFID;
+        (5)          Submit datagram to next step; DONE.
+        (6)     ELSE IF no buffer with BUFID is allocated
+        (7)             THEN allocate reassembly resources
+                             with BUFID;
+                             TIMER <- TLB; TDL <- 0;
+        (8)          put data from fragment into data buffer with
+                     BUFID from octet FO*8 to
+                                         octet (TL-(IHL*4))+FO*8;
+        (9)          set RCVBT bits from FO
+                                        to FO+((TL-(IHL*4)+7)/8);
+        (10)         IF MF = 0 THEN TDL <- TL-(IHL*4)+(FO*8)
+        (11)         IF FO = 0 THEN put header in header buffer
+        (12)         IF TDL # 0
+        (13)          AND all RCVBT bits from 0
+                                             to (TDL+7)/8 are set
+        (14)            THEN TL <- TDL+(IHL*4)
+        (15)                 Submit datagram to next step;
+        (16)                 free all reassembly resources
+                             for this BUFID; DONE.
+        (17)         TIMER <- MAX(TIMER,TTL);
+        (18)         give up until next fragment or timer expires;
+        (19) timer expires: flush all reassembly with this BUFID; DONE.
+
+      In the case that two or more fragments contain the same data
+      either identically or through a partial overlap, this procedure
+      will use the more recently arrived copy in the data buffer and
+      datagram delivered.
+
+  Identification
+
+    The choice of the Identifier for a datagram is based on the need to
+    provide a way to uniquely identify the fragments of a particular
+    datagram.  The protocol module assembling fragments judges fragments
+    to belong to the same datagram if they have the same source,
+    destination, protocol, and Identifier.  Thus, the sender must choose
+    the Identifier to be unique for this source, destination pair and
+    protocol for the time the datagram (or any fragment of it) could be
+    alive in the internet.
+
+    It seems then that a sending protocol module needs to keep a table
+    of Identifiers, one entry for each destination it has communicated
+    with in the last maximum packet lifetime for the internet.
+
+
+[Page 26]                                                               
+
+
+January 1980                                                            
+                                                       Internet Protocol
+                                                           Specification
+
+
+
+    However, since the Identifier field allows 65,536 different values,
+    some host may be able to simply use unique identifiers independent
+    of destination.
+
+    It is appropriate for some higher level protocols to choose the
+    identifier. For example, TCP protocol modules may retransmit an
+    identical TCP segment, and the probability for correct reception
+    would be enhanced if the retransmission carried the same identifier
+    as the original transmission since fragments of either datagram
+    could be used to construct a correct TCP segment.
+
+  Type of Service
+
+    The type of service (TOS) is for internet service quality selection.
+    The type of service is specified along the abstract parameters
+    precedence, reliability, and speed.  A further concern is the
+    possibility of efficient handling of streams of datagrams.  These
+    abstract parameters are to be mapped into the actual service
+    parameters of the particular networks the datagram traverses.
+
+    Precedence.  An independent measure of the importance of this
+    datagram.
+
+    Stream or Datagram.  Indicates if there will be other datagrams from
+    this source to this destination at regular frequent intervals
+    justifying the maintenance of stream processing information.
+
+    Reliability.  A measure of the level of effort desired to ensure
+    delivery of this datagram.
+
+    Speed over Reliability.  Indicates the relative importance of speed
+    and reliability when a conflict arises in meeting the pair of
+    requests.
+
+    Speed.  A measure of the importance of prompt delivery of this
+    datagram.
+
+    For example, the ARPANET has a priority bit, and a choice between
+    "standard" messages (type 0) and "uncontrolled" messages (type 3),
+    (the choice between single packet and multipacket messages can also
+    be considered a service parameter). The uncontrolled messages tend
+    to be less reliably delivered and suffer less delay.  Suppose an
+    internet datagram is to be sent through the ARPANET.  Let the
+    internet type of service be given as:
+
+
+
+
+
+
+                                                               [Page 27]
+
+
+                                                            January 1980
+Internet Protocol
+Specification
+
+
+
+      Precedence:    5
+      Stream:        0
+      Reliability:   1
+      S/R:           1
+      Speed:         1
+
+    The mapping of these parameters to those available for the ARPANET
+    would be  to set the ARPANET priority bit on since the Internet
+    priority is in the upper half of its range, to select uncontrolled
+    messages since the speed and reliability requirements are equal and
+    speed is preferred.
+
+    The following chart presents the recommended mappings from the
+    internet protocol type of service into the service parameters
+    actually available on the ARPANET, the PRNET, and the SATNET:
+
+      +------------+----------+----------+----------+----------+
+      |Application | INTERNET | ARPANET  | PRNET    | SATNET   |
+      +------------+----------+----------+----------+----------+
+      |TELNET      |S/D:stream| T: 3     | R: ptp   | T: block |
+      |  on        |  R:normal| S: S     | A: no    | D: min   |
+      |   TCP      |S/R:speed |          |          | H: inf   |
+      |            |  S:fast  |          |          | R: no    |
+      +------------+----------+----------+----------+----------+
+      |FTP         |S/D:stream| T: 0     | R: ptp   | T: block |
+      |  on        |  R:normal| S: M     | A: no    | D: normal|
+      |   TCP      |S/R:rlblt |          |          | H: inf   |
+      |            |  S:normal|          |          | R: no    |
+      +------------+----------+----------+----------+----------+
+      |interactive |S/D:strm* | T: 3     | R: ptp   | T: stream|
+      |narrow band |  R:least | S: S     | A: no    | D: min   |
+      |  speech    |  P:speed |          |          | H: short |
+      |            |  S:asap  |          |          | R: no    |
+      +------------+----------+----------+----------+----------+
+      |datagram    |S/D:dtgrm | T: 3 or 0| R:station| T: block |
+      |            |  R:normal| S: S or M| A: no    | D: min   |
+      |            |S/R:speed |          |          | H: short |
+      |            |  S:fast  |          |          | R: no    |
+      +------------+----------+----------+----------+----------+
+       key:    S/D=strm/dtgrm   T=type     R=route  T=type
+               R=reliability    S=size     A=ack    D=delay
+               S/R=speed/rlblt                      H=holding time
+               S=speed                              R=reliability
+               *=requires stream set up
+
+
+
+
+
+
+[Page 28]                                                               
+
+
+January 1980                                                            
+                                                       Internet Protocol
+                                                           Specification
+
+
+
+  Time to Live
+
+    The time to live is set by the sender to the maximum time the
+    datagram is allowed to be in the internet system.  If the datagram
+    is in the internet system longer than the time to live, then the
+    datagram should be destroyed.  This field should be decreased at
+    each point that the internet header is processed to reflect the time
+    spent processing the datagram.  Even if no local information is
+    available on the time actually spent, the field should be
+    decremented by 1.  The time is measured in units of seconds (i.e.
+    the value 1 means one second).  Thus, the maximum time to live is
+    255 seconds or 4.25 minutes.
+
+  Options
+
+    The options are just that, optional.  That is, the presence or
+    absence of an option is the choice of the sender, but each internet
+    module must be able to parse every option.  There can be several
+    options present in the option field.
+
+    The options might not end on a 32-bit boundary.  The internet header
+    should be filled out with octets of zeros.  The first of these would
+    be interpreted as the end-of-options option, and the remainder as
+    internet header padding.
+
+    Every internet module must be able to act on the following options:
+    End of Option List (0), No Operation (1), Source Route (3), Return
+    Route (7), General Error Report (33), and Internet Timestamp (68).
+    The Security Option (2) is required only if classified or
+    compartmented traffic is to be passed.
+
+  Checksum
+
+    The internet header checksum is recomputed if the internet header is
+    changed.  For example, a reduction of the time to live, additions or
+    changes to internet options, or due to fragmentation.  This checksum
+    at the internet level is intended to protect the internet header
+    fields from transmission errors.
+
+
+
+
+
+
+
+
+
+
+
+
+                                                               [Page 29]
+
+
+                                                            January 1980
+Internet Protocol
+Specification
+
+
+
+3.3.  Examples & Scenarios
+
+  Example 1:
+
+    This is an example of the minimal data carrying internet datagram:
+
+                                    
+    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 
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |Ver= 4 |IHL= 5 |Type of Service|        Total Length = 21      |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |      Identification = 111     |Flg=0|   Fragment Offset = 0   |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |   Time = 123  |  Protocol = 1 |        header checksum        |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |                         source address                        |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |                      destination address                      |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |     data      |                                                
+   +-+-+-+-+-+-+-+-+                                                
+
+                       Example Internet Datagram
+
+                               Figure 4.
+
+    Note that each tick mark represents one bit position.
+
+    This is a internet datagram in version 4 of internet protocol; the
+    internet header consists of five 32 bit words, and the total length
+    of the datagram is 21 octets.  This datagram is a complete datagram
+    (not a fragment).
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+[Page 30]                                                               
+
+
+January 1980                                                            
+                                                       Internet Protocol
+                                                           Specification
+
+
+
+  Example 2:
+
+    In this example, we show first a moderate size internet datagram
+    (552 data octets), then two internet fragments that might result
+    from the fragmentation of this datagram if the maximum sized
+    transmission allowed were 280 octets.
+
+                                    
+    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 
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |Ver= 4 |IHL= 5 |Type of Service|       Total Length = 472      |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |     Identification = 111      |Flg=0|     Fragment Offset = 0 |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |   Time = 123  | Protocol = 6  |        header checksum        |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |                         source address                        |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |                      destination address                      |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |                             data                              |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |                             data                              |
+   \                                                               \
+   \                                                               \
+   |                             data                              |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |             data              |                                
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+                                
+
+                       Example Internet Datagram
+
+                               Figure 5.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+                                                               [Page 31]
+
+
+                                                            January 1980
+Internet Protocol
+Specification
+
+
+
+    Now the first fragment that results from splitting the datagram
+    after 256 data octets.
+
+                                    
+    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 
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |Ver= 4 |IHL= 5 |Type of Service|       Total Length = 276      |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |     Identification = 111      |Flg=1|     Fragment Offset = 0 |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |   Time = 119  | Protocol = 6  |        Header Checksum        |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |                         source address                        |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |                      destination address                      |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |                             data                              |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |                             data                              |
+   \                                                               \
+   \                                                               \
+   |                             data                              |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |                             data                              |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+                       Example Internet Fragment
+
+                               Figure 6.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+[Page 32]                                                               
+
+
+January 1980                                                            
+                                                       Internet Protocol
+                                                           Specification
+
+
+
+    And the second fragment.
+
+                                    
+    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 
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |Ver= 4 |IHL= 5 |Type of Service|       Total Length = 216      |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |     Identification = 111      |Flg=0|  Fragment Offset  =  32 |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |   Time = 119  | Protocol = 6  |        Header Checksum        |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |                         source address                        |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |                      destination address                      |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |                             data                              |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |                             data                              |
+   \                                                               \
+   \                                                               \
+   |                             data                              |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |            data               |                                
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+                                
+
+                       Example Internet Fragment
+
+                               Figure 7.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+                                                               [Page 33]
+
+
+                                                            January 1980
+Internet Protocol
+Specification
+
+
+
+  Example 3:
+
+    Here, we show an example of a datagram containing options:
+
+                                    
+    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 
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |Ver= 4 |IHL= 8 |Type of Service|       Total Length = 576      |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |       Identification = 111    |Flg=0|     Fragment Offset = 0 |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |   Time = 123  |  Protocol = 6 |       Header Checksum         |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |                        source address                         |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |                      destination address                      |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   | Opt. Code = x | Opt.  Len.= 3 | option value  | Opt. Code = x |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   | Opt. Len. = 4 |           option value        | Opt. Code = 1 |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   | Opt. Code = y | Opt. Len. = 3 |  option value | Opt. Code = 0 |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |                             data                              |
+   \                                                               \
+   \                                                               \
+   |                             data                              |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |                             data                              |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+                       Example Internet Datagram
+
+                               Figure 8.
+
+3.4.  Interfaces
+
+  Internet protocol interfaces on one side to the local network and on
+  the other side to either a higher level protocol or an application
+  program.  In the following, the higher level protocol or application
+  program (or even a gateway program) will be called the "user" since it
+  is using the internet module.  Since internet protocol is a datagram
+  protocol, there is minimal memory or state maintained between datagram
+  transmissions, and each call on the internet protocol module by the
+  user supplies all the necessary information.
+
+
+
+
+[Page 34]                                                               
+
+
+January 1980                                                            
+                                                       Internet Protocol
+                                                           Specification
+
+
+
+  For example, the following two calls satisfy the requirements for the
+  user to internet protocol module communication ("=>" means returns):
+
+    SEND (dest, TOS, TTL, BufPTR, len, Id, DF, options => result)
+
+      where:
+
+        dest = destination address
+        TOS = type of service
+        TTL = time to live
+        BufPTR = buffer pointer
+        len = length of buffer
+        Id  = Identifier
+        DF = Don't Fragment
+        options = option data
+        result = response
+          OK = datagram sent ok
+          Error = error in arguments or local network error
+
+    RECV (BufPTR => result, source, dest, prot, TOS, len)
+
+      where:
+
+        BufPTR = buffer pointer
+        result = response
+          OK = datagram received ok
+          Error = error in arguments
+        source = source address
+        dest = destination address
+        prot = protocol
+        TOS = type of service
+        len = length of buffer
+
+  When the user sends a datagram, it executes the SEND call supplying
+  all the arguments.  The internet protocol module, on receiving this
+  call, checks the arguments and prepares and sends the message.  If the
+  arguments are good and the datagram is accepted by the local network,
+  the call returns successfully.  If either the arguments are bad, or
+  the datagram is not accepted by the local network, the call returns
+  unsuccessfully.  On unsuccessful returns, a reasonable report should
+  be made as to the cause of the problem, but the details of such
+  reports are up to individual implementations.
+
+  When a datagram arrives at the internet protocol module from the local
+  network, either there is a pending RECV call from the user addressed
+  or there is not.  In the first case, the pending call is satisfied by
+  passing the information from the datagram to the user.  In the second
+  case, the user addressed is notified of a pending datagram.  If the
+
+
+                                                               [Page 35]
+
+
+                                                            January 1980
+Internet Protocol
+Specification
+
+
+
+  user addressed does not exist, an error datagram is returned to the
+  sender, and the data is discarded.
+
+  The notification of a user may be via a pseudo interrupt or similar
+  mechanism, as appropriate in the particular operating system
+  environment of the implementation.
+
+  A user's RECV call may then either be immediately satisfied by a
+  pending datagram, or the call may be pending until a datagram arrives.
+
+  An implementation may also allow or require a call to the internet
+  module to indicate interest in or reserve exclusive use of a class of
+  datagrams (e.g., all those with a certain value in the protocol
+  field).
+
+  
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+[Page 36]                                                               
+
+
+January 1980                                                            
+                                                       Internet Protocol
+
+
+
+                                GLOSSARY
+
+
+
+1822
+          BBN Report 1822, "The Specification of the Interconnection of
+          a Host and an IMP".  The specification of interface between a
+          host and the ARPANET.
+
+ARPANET message
+          The unit of transmission between a host and an IMP in the
+          ARPANET.  The maximum size is about 1012 octets (8096 bits).
+
+ARPANET packet
+          A unit of transmission used internally in the ARPANET between
+          IMPs. The maximum size is about 126 octets (1008 bits).
+
+Destination
+          The destination address, an internet header field.
+
+DF
+          The Don't Fragment bit carried in the flags field.
+
+Flags
+          An internet header field carrying various control flags.
+
+Fragment Offset
+          This internet header field indicates where in the internet
+          datagram a fragment belongs.
+
+header
+          Control information at the beginning of a message, segment,
+          datagram, packet or block of data.
+
+Identification
+          An internet header field carrying the identifying value
+          assigned by the sender to aid in assembling the fragments of a
+          datagram.
+
+IHL
+          The internet header field Internet Header Length is the length
+          of the internet header measured in 32 bit words.
+
+IMP
+          The Interface Message Processor, the packet switch of the
+          ARPANET.
+
+
+
+
+
+                                                               [Page 37]
+
+
+                                                            January 1980
+Internet Protocol
+Glossary
+
+
+
+Internet Address
+          A four octet (32 bit) source or destination address consisting
+          of a Network field and a Local Address field.
+
+internet fragment
+          A portion of the data of an internet datagram with an internet
+          header.
+
+internet datagram
+          The unit of data exchanged between a pair of internet modules
+          (includes the internet header).
+
+ARPANET leader
+          The control information on an ARPANET message at the host-IMP
+          interface.
+
+Local Address
+          The address of a host within a network.  The actual mapping of
+          an internet local address on to the host addresses in a
+          network is quite general, allowing for many to one mappings.
+
+MF
+          The More-Fragments Flag carried in the internet header flags
+          field.
+
+module
+          An implementation, usually in software, of a protocol or other
+          procedure.
+
+more-fragments flag
+          A flag indicating whether or not this internet datagram
+          contains the end of an internet datagram, carried in the
+          internet header Flags field.
+
+NFB
+          The Number of Fragment Blocks in a the data portion of an
+          internet fragment.  That is, the length of a portion of data
+          measured in 8 octet units.
+
+octet
+          An eight bit byte.
+
+Options
+          The internet header Options field may contain several options,
+          and each option may be several octets in length.  The options
+          are used primarily in testing situations, for example to carry
+          timestamps.
+
+
+
+[Page 38]                                                               
+
+
+January 1980                                                            
+                                                       Internet Protocol
+                                                                Glossary
+
+
+
+Padding
+          The internet header Padding field is used to ensure that the
+          data begins on 32 bit word boundary.  The padding is zero.
+
+Protocol
+          In this document, the next higher level protocol identifier,
+          an internet header field.
+
+Rest
+          The 3 octet (24 bit) local address portion of an Internet
+          Address.
+
+RTP
+          Real Time Protocol:  A host-to-host protocol for communication
+          of time critical information.
+
+Source
+          The source address, an internet header field.
+
+TCP
+          Transmission Control Protocol:  A host-to-host protocol for
+          reliable communication in internet environments.
+
+TCP Segment
+          The unit of data exchanged between TCP modules (including the
+          TCP header).
+
+Total Length
+          The internet header field Total Length is the length of the
+          datagram in octets including internet header and data.
+
+Type of Service
+          An internet header field which indicates the type (or quality)
+          of service for this internet datagram.
+
+User
+          The user of the internet protocol.  This may be a higher level
+          protocol module, an application program, or a gateway program.
+
+Version
+          The Version field indicates the format of the internet header.
+
+
+
+
+
+
+
+
+
+                                                               [Page 39]
+
+
+                                                            January 1980
+Internet Protocol
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+[Page 40]                                                               
+
+
+January 1980                                                            
+                                                       Internet Protocol
+
+
+
+                               REFERENCES
+
+
+
+[1]  Cerf, V., "The Catenet Model for Internetworking," Information
+     Processing Techniques Office, Defense Advanced Research Projects
+     Agency, IEN 48, July 1978.
+
+[2]  Bolt Beranek and Newman, "Specification for the Interconnection of
+     a Host and an IMP," BBN Technical Report 1822, May 1978 (Revised).
+
+[3]  Shoch, J., "Inter-Network Naming, Addressing, and Routing,"
+     COMPCON, IEEE Computer Society, Fall 1978.
+
+[4]  Postel, J., "Address Mappings," IEN 115, USC/Information Sciences
+     Institute, August 1979.
+
+[5]  Shoch, J., "Packet Fragmentation in Inter-Network Protocols,"
+     Computer Networks, v. 3, n. 1, February 1979.
+
+[6]  Postel, J., "Assigned Numbers," RFC 762, IEN 127, USC/Information
+     Sciences Institute, January 1980.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+                                                               [Page 41]
+
+
+                                                            January 1980
+Internet Protocol
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+[Page 42]                                                               
+
-- 
cgit v1.2.3