    Network Working Group                                          J. Postel
    Request for Comments: 777                                            ISI
                                                                  April 1981
    Updates:  IENs 109, 128
    Updates:  RFC  760

                       Internet Control Message Protocol

    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.

    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 check these fields.  Unless
       otherwise noted under the individual format descriptions, the values
       of the internet header fields are as follows:

                                                                    [Page 1]

                                                                  April 1981
    RFC 777

       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.

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

    April 1981
    RFC 777

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

       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, 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 sends a destination unreachable message to

                                                                    [Page 3]

                                                                  April 1981
    RFC 777

          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 return a destination
          unreachable message.

    [Page 4]

    April 1981
    RFC 777

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

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

                                                                    [Page 5]

                                                                  April 1981
    RFC 777

    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      |   Parameter   |     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 = problem with option.

       Parameter

          If code = 0, IP option type.

       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 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 an option that is not implemented, or incorrect
          arguments in an option.  The gateway or host may also notify the
          source host via the parameter problem message.

    [Page 6]

    April 1981
    RFC 777

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

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

                                                                    [Page 7]

                                                                  April 1981
    RFC 777

          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.

    [Page 8]

    April 1981
    RFC 777

    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      |            unused             |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                 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.

       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.

       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 9]

                                                                  April 1981
    RFC 777

       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.

    [Page 10]

    April 1981
    RFC 777

    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      |                  unused                       |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |     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.

       IP Fields:

       Type

          8 for echo message;

          0 for echo reply message.

       Description

          The data received in the echo message must be returned in the echo
          reply message.

                                                                   [Page 11]

                                                                  April 1981
    RFC 777

    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      |                  unused                       |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |     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.

       IP Fields:

       Type

          13 for timestamp message;

          14 for timestamp reply message.

       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].

    [Page 12]

    April 1981
    RFC 777

    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

                                                                   [Page 13]

                                                                  April 1981
    RFC 777

    References

       [1]   Postel, J., ed., "DOD Standard Internet Protocol", IEN 128,
             RFC 760, USC/Information Sciences Institute, NTIS ADA079730,
             January 1980.  Appears in: Computer Communication Review,
             Special Interest Group on Data Communications, ACM, V.10, N.4,
             October 1980.

       [2]   Cerf, V., "The Catenet Model for Internetworking," Information
             Processing Techniques Office, Defense Advanced Research
             Projects Agency, IEN 48, 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 14]