doc: Add RFC documents

1 files changed, 1218 insertions, 0 deletions

diff --git a/doc/rfc/rfc792.txt b/doc/rfc/rfc792.txt
new file mode 100644
index 0000000..5c659e8
--- /dev/null
+++ b/doc/rfc/rfc792.txt
@@ -0,0 +1,1218 @@
+
+
+Network Working Group                                          J. Postel
+Request for Comments:  792                                           ISI
+                                                          September 1981
+Updates:  RFCs 777, 760
+Updates:  IENs 109, 128
+
+                   INTERNET CONTROL MESSAGE PROTOCOL
+
+                         DARPA INTERNET PROGRAM
+                         PROTOCOL SPECIFICATION
+
+
+
+Introduction
+
+   The Internet Protocol (IP) [1] is used for host-to-host datagram
+   service in a system of interconnected networks called the
+   Catenet [2].  The network connecting devices are called Gateways.
+   These gateways communicate between themselves for control purposes
+   via a Gateway to Gateway Protocol (GGP) [3,4].  Occasionally a
+   gateway or destination host will communicate with a source host, for
+   example, to report an error in datagram processing.  For such
+   purposes this protocol, the Internet Control Message Protocol (ICMP),
+   is used.  ICMP, uses the basic support of IP as if it were a higher
+   level protocol, however, ICMP is actually an integral part of IP, and
+   must be implemented by every IP module.
+
+   ICMP messages are sent in several situations:  for example, when a
+   datagram cannot reach its destination, when the gateway does not have
+   the buffering capacity to forward a datagram, and when the gateway
+   can direct the host to send traffic on a shorter route.
+
+   The Internet Protocol is not designed to be absolutely reliable.  The
+   purpose of these control messages is to provide feedback about
+   problems in the communication environment, not to make IP reliable.
+   There are still no guarantees that a datagram will be delivered or a
+   control message will be returned.  Some datagrams may still be
+   undelivered without any report of their loss.  The higher level
+   protocols that use IP must implement their own reliability procedures
+   if reliable communication is required.
+
+   The ICMP messages typically report errors in the processing of
+   datagrams.  To avoid the infinite regress of messages about messages
+   etc., no ICMP messages are sent about ICMP messages.  Also ICMP
+   messages are only sent about errors in handling fragment zero of
+   fragemented datagrams.  (Fragment zero has the fragment offeset equal
+   zero).
+
+
+
+
+
+
+
+                                                                [Page 1]
+
+
+                                                          September 1981
+RFC 792
+
+
+
+Message Formats
+
+   ICMP messages are sent using the basic IP header.  The first octet of
+   the data portion of the datagram is a ICMP type field; the value of
+   this field determines the format of the remaining data.  Any field
+   labeled "unused" is reserved for later extensions and must be zero
+   when sent, but receivers should not use these fields (except to
+   include them in the checksum).  Unless otherwise noted under the
+   individual format descriptions, the values of the internet header
+   fields are as follows:
+
+   Version
+
+      4
+
+   IHL
+
+      Internet header length in 32-bit words.
+
+   Type of Service
+
+      0
+
+   Total Length
+
+      Length of internet header and data in octets.
+
+   Identification, Flags, Fragment Offset
+
+      Used in fragmentation, see [1].
+
+   Time to Live
+
+      Time to live in seconds; as this field is decremented at each
+      machine in which the datagram is processed, the value in this
+      field should be at least as great as the number of gateways which
+      this datagram will traverse.
+
+   Protocol
+
+      ICMP = 1
+
+   Header Checksum
+
+      The 16 bit one's complement of the one's complement sum of all 16
+      bit words in the header.  For computing the checksum, the checksum
+      field should be zero.  This checksum may be replaced in the
+      future.
+
+
+[Page 2]                                                                
+
+
+September 1981                                                          
+RFC 792
+
+
+
+   Source Address
+
+      The address of the gateway or host that composes the ICMP message.
+      Unless otherwise noted, this can be any of a gateway's addresses.
+
+   Destination Address
+
+      The address of the gateway or host to which the message should be
+      sent.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+                                                                [Page 3]
+
+
+                                                          September 1981
+RFC 792
+
+
+
+Destination Unreachable Message
+
+    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
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |     Type      |     Code      |          Checksum             |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |                             unused                            |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |      Internet Header + 64 bits of Original Data Datagram      |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+   IP Fields:
+
+   Destination Address
+
+      The source network and address from the original datagram's data.
+
+   ICMP Fields:
+
+   Type
+
+      3
+
+   Code
+
+      0 = net unreachable;
+
+      1 = host unreachable;
+
+      2 = protocol unreachable;
+
+      3 = port unreachable;
+
+      4 = fragmentation needed and DF set;
+
+      5 = source route failed.
+
+   Checksum
+
+      The checksum is the 16-bit ones's complement of the one's
+      complement sum of the ICMP message starting with the ICMP Type.
+      For computing the checksum , the checksum field should be zero.
+      This checksum may be replaced in the future.
+
+   Internet Header + 64 bits of Data Datagram
+
+      The internet header plus the first 64 bits of the original
+
+
+[Page 4]                                                                
+
+
+September 1981                                                          
+RFC 792
+
+
+
+      datagram's data.  This data is used by the host to match the
+      message to the appropriate process.  If a higher level protocol
+      uses port numbers, they are assumed to be in the first 64 data
+      bits of the original datagram's data.
+
+   Description
+
+      If, according to the information in the gateway's routing tables,
+      the network specified in the internet destination field of a
+      datagram is unreachable, e.g., the distance to the network is
+      infinity, the gateway may send a destination unreachable message
+      to the internet source host of the datagram.  In addition, in some
+      networks, the gateway may be able to determine if the internet
+      destination host is unreachable.  Gateways in these networks may
+      send destination unreachable messages to the source host when the
+      destination host is unreachable.
+
+      If, in the destination host, the IP module cannot deliver the
+      datagram  because the indicated protocol module or process port is
+      not active, the destination host may send a destination
+      unreachable message to the source host.
+
+      Another case is when a datagram must be fragmented to be forwarded
+      by a gateway yet the Don't Fragment flag is on.  In this case the
+      gateway must discard the datagram and may return a destination
+      unreachable message.
+
+      Codes 0, 1, 4, and 5 may be received from a gateway.  Codes 2 and
+      3 may be received from a host.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+                                                                [Page 5]
+
+
+                                                          September 1981
+RFC 792
+
+
+
+Time Exceeded Message
+
+    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
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |     Type      |     Code      |          Checksum             |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |                             unused                            |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |      Internet Header + 64 bits of Original Data Datagram      |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+   IP Fields:
+
+   Destination Address
+
+      The source network and address from the original datagram's data.
+
+   ICMP Fields:
+
+   Type
+
+      11
+
+   Code
+
+      0 = time to live exceeded in transit;
+
+      1 = fragment reassembly time exceeded.
+
+   Checksum
+
+      The checksum is the 16-bit ones's complement of the one's
+      complement sum of the ICMP message starting with the ICMP Type.
+      For computing the checksum , the checksum field should be zero.
+      This checksum may be replaced in the future.
+
+   Internet Header + 64 bits of Data Datagram
+
+      The internet header plus the first 64 bits of the original
+      datagram's data.  This data is used by the host to match the
+      message to the appropriate process.  If a higher level protocol
+      uses port numbers, they are assumed to be in the first 64 data
+      bits of the original datagram's data.
+
+   Description
+
+      If the gateway processing a datagram finds the time to live field
+
+
+[Page 6]                                                                
+
+
+September 1981                                                          
+RFC 792
+
+
+
+      is zero it must discard the datagram.  The gateway may also notify
+      the source host via the time exceeded message.
+
+      If a host reassembling a fragmented datagram cannot complete the
+      reassembly due to missing fragments within its time limit it
+      discards the datagram, and it may send a time exceeded message.
+
+      If fragment zero is not available then no time exceeded need be
+      sent at all.
+
+      Code 0 may be received from a gateway.  Code 1 may be received
+      from a host.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+                                                                [Page 7]
+
+
+                                                          September 1981
+RFC 792
+
+
+
+Parameter Problem Message
+
+    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
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |     Type      |     Code      |          Checksum             |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |    Pointer    |                   unused                      |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |      Internet Header + 64 bits of Original Data Datagram      |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+   IP Fields:
+
+   Destination Address
+
+      The source network and address from the original datagram's data.
+
+   ICMP Fields:
+
+   Type
+
+      12
+
+   Code
+
+      0 = pointer indicates the error.
+
+   Checksum
+
+      The checksum is the 16-bit ones's complement of the one's
+      complement sum of the ICMP message starting with the ICMP Type.
+      For computing the checksum , the checksum field should be zero.
+      This checksum may be replaced in the future.
+
+   Pointer
+
+      If code = 0, identifies the octet where an error was detected.
+
+   Internet Header + 64 bits of Data Datagram
+
+      The internet header plus the first 64 bits of the original
+      datagram's data.  This data is used by the host to match the
+      message to the appropriate process.  If a higher level protocol
+      uses port numbers, they are assumed to be in the first 64 data
+      bits of the original datagram's data.
+
+
+
+
+[Page 8]                                                                
+
+
+September 1981                                                          
+RFC 792
+
+
+
+   Description
+
+      If the gateway or host processing a datagram finds a problem with
+      the header parameters such that it cannot complete processing the
+      datagram it must discard the datagram.  One potential source of
+      such a problem is with incorrect arguments in an option.  The
+      gateway or host may also notify the source host via the parameter
+      problem message.  This message is only sent if the error caused
+      the datagram to be discarded.
+
+      The pointer identifies the octet of the original datagram's header
+      where the error was detected (it may be in the middle of an
+      option).  For example, 1 indicates something is wrong with the
+      Type of Service, and (if there are options present) 20 indicates
+      something is wrong with the type code of the first option.
+
+      Code 0 may be received from a gateway or a host.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+                                                                [Page 9]
+
+
+                                                          September 1981
+RFC 792
+
+
+
+Source Quench Message
+
+    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
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |     Type      |     Code      |          Checksum             |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |                             unused                            |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |      Internet Header + 64 bits of Original Data Datagram      |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+   IP Fields:
+
+   Destination Address
+
+      The source network and address of the original datagram's data.
+
+   ICMP Fields:
+
+   Type
+
+      4
+
+   Code
+
+      0
+
+   Checksum
+
+      The checksum is the 16-bit ones's complement of the one's
+      complement sum of the ICMP message starting with the ICMP Type.
+      For computing the checksum , the checksum field should be zero.
+      This checksum may be replaced in the future.
+
+   Internet Header + 64 bits of Data Datagram
+
+      The internet header plus the first 64 bits of the original
+      datagram's data.  This data is used by the host to match the
+      message to the appropriate process.  If a higher level protocol
+      uses port numbers, they are assumed to be in the first 64 data
+      bits of the original datagram's data.
+
+   Description
+
+      A gateway may discard internet datagrams if it does not have the
+      buffer space needed to queue the datagrams for output to the next
+      network on the route to the destination network.  If a gateway
+
+
+[Page 10]                                                               
+
+
+September 1981                                                          
+RFC 792
+
+
+
+      discards a datagram, it may send a source quench message to the
+      internet source host of the datagram.  A destination host may also
+      send a source quench message if datagrams arrive too fast to be
+      processed.  The source quench message is a request to the host to
+      cut back the rate at which it is sending traffic to the internet
+      destination.  The gateway may send a source quench message for
+      every message that it discards.  On receipt of a source quench
+      message, the source host should cut back the rate at which it is
+      sending traffic to the specified destination until it no longer
+      receives source quench messages from the gateway.  The source host
+      can then gradually increase the rate at which it sends traffic to
+      the destination until it again receives source quench messages.
+
+      The gateway or host may send the source quench message when it
+      approaches its capacity limit rather than waiting until the
+      capacity is exceeded.  This means that the data datagram which
+      triggered the source quench message may be delivered.
+
+      Code 0 may be received from a gateway or a host.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+                                                               [Page 11]
+
+
+                                                          September 1981
+RFC 792
+
+
+
+Redirect Message
+
+    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
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |     Type      |     Code      |          Checksum             |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |                 Gateway Internet Address                      |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |      Internet Header + 64 bits of Original Data Datagram      |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+   IP Fields:
+
+   Destination Address
+
+      The source network and address of the original datagram's data.
+
+   ICMP Fields:
+
+   Type
+
+      5
+
+   Code
+
+      0 = Redirect datagrams for the Network.
+
+      1 = Redirect datagrams for the Host.
+
+      2 = Redirect datagrams for the Type of Service and Network.
+
+      3 = Redirect datagrams for the Type of Service and Host.
+
+   Checksum
+
+      The checksum is the 16-bit ones's complement of the one's
+      complement sum of the ICMP message starting with the ICMP Type.
+      For computing the checksum , the checksum field should be zero.
+      This checksum may be replaced in the future.
+
+   Gateway Internet Address
+
+      Address of the gateway to which traffic for the network specified
+      in the internet destination network field of the original
+      datagram's data should be sent.
+
+
+
+
+[Page 12]                                                               
+
+
+September 1981                                                          
+RFC 792
+
+
+
+   Internet Header + 64 bits of Data Datagram
+
+      The internet header plus the first 64 bits of the original
+      datagram's data.  This data is used by the host to match the
+      message to the appropriate process.  If a higher level protocol
+      uses port numbers, they are assumed to be in the first 64 data
+      bits of the original datagram's data.
+
+   Description
+
+      The gateway sends a redirect message to a host in the following
+      situation.  A gateway, G1, receives an internet datagram from a
+      host on a network to which the gateway is attached.  The gateway,
+      G1, checks its routing table and obtains the address of the next
+      gateway, G2, on the route to the datagram's internet destination
+      network, X.  If G2 and the host identified by the internet source
+      address of the datagram are on the same network, a redirect
+      message is sent to the host.  The redirect message advises the
+      host to send its traffic for network X directly to gateway G2 as
+      this is a shorter path to the destination.  The gateway forwards
+      the original datagram's data to its internet destination.
+
+      For datagrams with the IP source route options and the gateway
+      address in the destination address field, a redirect message is
+      not sent even if there is a better route to the ultimate
+      destination than the next address in the source route.
+
+      Codes 0, 1, 2, and 3 may be received from a gateway.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+                                                               [Page 13]
+
+
+                                                          September 1981
+RFC 792
+
+
+
+Echo or Echo Reply Message
+
+    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
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |     Type      |     Code      |          Checksum             |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |           Identifier          |        Sequence Number        |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |     Data ...
+   +-+-+-+-+-
+
+   IP Fields:
+
+   Addresses
+
+      The address of the source in an echo message will be the
+      destination of the echo reply message.  To form an echo reply
+      message, the source and destination addresses are simply reversed,
+      the type code changed to 0, and the checksum recomputed.
+
+   IP Fields:
+
+   Type
+
+      8 for echo message;
+
+      0 for echo reply message.
+
+   Code
+
+      0
+
+   Checksum
+
+      The checksum is the 16-bit ones's complement of the one's
+      complement sum of the ICMP message starting with the ICMP Type.
+      For computing the checksum , the checksum field should be zero.
+      If the total length is odd, the received data is padded with one
+      octet of zeros for computing the checksum.  This checksum may be
+      replaced in the future.
+
+   Identifier
+
+      If code = 0, an identifier to aid in matching echos and replies,
+      may be zero.
+
+   Sequence Number
+
+
+[Page 14]                                                               
+
+
+September 1981                                                          
+RFC 792
+
+
+
+      If code = 0, a sequence number to aid in matching echos and
+      replies, may be zero.
+
+   Description
+
+      The data received in the echo message must be returned in the echo
+      reply message.
+
+      The identifier and sequence number may be used by the echo sender
+      to aid in matching the replies with the echo requests.  For
+      example, the identifier might be used like a port in TCP or UDP to
+      identify a session, and the sequence number might be incremented
+      on each echo request sent.  The echoer returns these same values
+      in the echo reply.
+
+      Code 0 may be received from a gateway or a host.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+                                                               [Page 15]
+
+
+                                                          September 1981
+RFC 792
+
+
+
+Timestamp or Timestamp Reply Message
+
+    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
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |     Type      |      Code     |          Checksum             |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |           Identifier          |        Sequence Number        |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |     Originate Timestamp                                       |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |     Receive Timestamp                                         |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |     Transmit Timestamp                                        |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+   IP Fields:
+
+   Addresses
+
+      The address of the source in a timestamp message will be the
+      destination of the timestamp reply message.  To form a timestamp
+      reply message, the source and destination addresses are simply
+      reversed, the type code changed to 14, and the checksum
+      recomputed.
+
+   IP Fields:
+
+   Type
+
+      13 for timestamp message;
+
+      14 for timestamp reply message.
+
+   Code
+
+      0
+
+   Checksum
+
+      The checksum is the 16-bit ones's complement of the one's
+      complement sum of the ICMP message starting with the ICMP Type.
+      For computing the checksum , the checksum field should be zero.
+      This checksum may be replaced in the future.
+
+   Identifier
+
+
+
+
+[Page 16]                                                               
+
+
+September 1981                                                          
+RFC 792
+
+
+
+      If code = 0, an identifier to aid in matching timestamp and
+      replies, may be zero.
+
+   Sequence Number
+
+      If code = 0, a sequence number to aid in matching timestamp and
+      replies, may be zero.
+
+   Description
+
+      The data received (a timestamp) in the message is returned in the
+      reply together with an additional timestamp.  The timestamp is 32
+      bits of milliseconds since midnight UT.  One use of these
+      timestamps is described by Mills [5].
+
+      The Originate Timestamp is the time the sender last touched the
+      message before sending it, the Receive Timestamp is the time the
+      echoer first touched it on receipt, and the Transmit Timestamp is
+      the time the echoer last touched the message on sending it.
+
+      If the time is not available in miliseconds or cannot be provided
+      with respect to midnight UT then any time can be inserted in a
+      timestamp provided the high order bit of the timestamp is also set
+      to indicate this non-standard value.
+
+      The identifier and sequence number may be used by the echo sender
+      to aid in matching the replies with the requests.  For example,
+      the identifier might be used like a port in TCP or UDP to identify
+      a session, and the sequence number might be incremented on each
+      request sent.  The destination returns these same values in the
+      reply.
+
+      Code 0 may be received from a gateway or a host.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+                                                               [Page 17]
+
+
+                                                          September 1981
+RFC 792
+
+
+
+Information Request or Information Reply Message
+
+    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
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |     Type      |      Code     |          Checksum             |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |           Identifier          |        Sequence Number        |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+   IP Fields:
+
+   Addresses
+
+      The address of the source in a information request message will be
+      the destination of the information reply message.  To form a
+      information reply message, the source and destination addresses
+      are simply reversed, the type code changed to 16, and the checksum
+      recomputed.
+
+   IP Fields:
+
+   Type
+
+      15 for information request message;
+
+      16 for information reply message.
+
+   Code
+
+      0
+
+   Checksum
+
+      The checksum is the 16-bit ones's complement of the one's
+      complement sum of the ICMP message starting with the ICMP Type.
+      For computing the checksum , the checksum field should be zero.
+      This checksum may be replaced in the future.
+
+   Identifier
+
+      If code = 0, an identifier to aid in matching request and replies,
+      may be zero.
+
+   Sequence Number
+
+      If code = 0, a sequence number to aid in matching request and
+      replies, may be zero.
+
+
+[Page 18]                                                               
+
+
+September 1981                                                          
+RFC 792
+
+
+
+   Description
+
+      This message may be sent with the source network in the IP header
+      source and destination address fields zero (which means "this"
+      network).  The replying IP module should send the reply with the
+      addresses fully specified.  This message is a way for a host to
+      find out the number of the network it is on.
+
+      The identifier and sequence number may be used by the echo sender
+      to aid in matching the replies with the requests.  For example,
+      the identifier might be used like a port in TCP or UDP to identify
+      a session, and the sequence number might be incremented on each
+      request sent.  The destination returns these same values in the
+      reply.
+
+      Code 0 may be received from a gateway or a host.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+                                                               [Page 19]
+
+
+                                                          September 1981
+RFC 792
+
+
+
+Summary of Message Types
+
+    0  Echo Reply
+
+    3  Destination Unreachable
+
+    4  Source Quench
+
+    5  Redirect
+
+    8  Echo
+
+   11  Time Exceeded
+
+   12  Parameter Problem
+
+   13  Timestamp
+
+   14  Timestamp Reply
+
+   15  Information Request
+
+   16  Information Reply
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+[Page 20]                                                               
+
+
+September 1981                                                          
+RFC 792
+
+
+
+References
+
+   [1]  Postel, J. (ed.), "Internet Protocol - DARPA Internet Program
+         Protocol Specification," RFC 791, USC/Information Sciences
+         Institute, September 1981.
+
+   [2]   Cerf, V., "The Catenet Model for Internetworking," IEN 48,
+         Information Processing Techniques Office, Defense Advanced
+         Research Projects Agency, July 1978.
+
+   [3]   Strazisar, V., "Gateway Routing:  An Implementation
+         Specification", IEN 30, Bolt Beranek and Newman, April 1979.
+
+   [4]   Strazisar, V., "How to Build a Gateway", IEN 109, Bolt Beranek
+         and Newman, August 1979.
+
+   [5]   Mills, D., "DCNET Internet Clock Service," RFC 778, COMSAT
+         Laboratories, April 1981.
+
+   
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+                                                               [Page 21]
+