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
`
`1
`
`ARISTA 1113
`
`

`
`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
`
`2
`
`

`
`   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
`
`3
`
`

`
`    0                   1                   2                   3
`    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
`   +‐+‐+‐+‐+‐+‐+‐+‐+‐+‐+‐+‐+‐+‐+‐+‐+‐+‐+‐+‐+‐+‐+‐+‐+‐+‐+‐+‐+‐+‐+‐+‐+
`   |     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.
`
`4
`
`

`
`   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                            |
`
`5
`
`

`
`   +‐+‐+‐+‐+‐+‐+‐+‐+‐+‐+‐+‐+‐+‐+‐+‐+‐+‐+‐+‐+‐+‐+‐+‐+‐+‐+‐+‐+‐+‐+‐+‐+
`   |      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
`
`6
`
`

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

`
`   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.
`
`8
`
`

`
`                                                                [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:
`
`9
`
`

`
`   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.
`
`10
`
`

`
`                                                               [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
`
`11
`
`

`
`      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.
`
`12
`
`

`
`                                                               [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
`
`13
`
`

`
`   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.
`
`14
`
`

`
`                                                               [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
`
`15
`
`

`
`   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.
`
`16
`
`

`
`                                                               [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.
`
`17
`
`

`
`   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.
`
`18
`
`

`
`                                                               [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
`
`19
`
`

`
`[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]
`
`20