ICMP RFC 792

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

   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

   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

   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

   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

   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.