NAME

icmp − Internet Control Message Protocol

SYNOPSIS

None; included automatically with inet(4F).

DESCRIPTION

The Internet Control Message Protocol ICMP is used by gateways and destination hosts which process datagrams to communicate errors in datagram processing to source hosts.  (The datagram level of Internet is discussed in ip(4P).) ICMP uses the basic support of IP as if it were a higher level protocol, however ICMP is actually an integral part of IP.

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 which 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 0 of fragmented datagrams. 

There are 11 types of ICMP packets which can be received by the system.  They are defined in this excerpt from <netinet/ip_icmp.h>, which also defines the values of some additional codes further specifying the cause of certain errors. 

/∗
 ∗ Definition of type and code field values
 ∗/
#defineICMP_ECHOREPLY0/∗ echo reply ∗/
#defineICMP_UNREACH3/∗ dest unreachable, codes: ∗/
#defineICMP_UNREACH_NET0/∗ bad net ∗/
#defineICMP_UNREACH_HOST1/∗ bad host ∗/
#defineICMP_UNREACH_PROTOCOL2/∗ bad protocol ∗/
#defineICMP_UNREACH_PORT3/∗ bad port ∗/
#defineICMP_UNREACH_NEEDFRAG4/∗ IP_DF caused drop ∗/
#defineICMP_UNREACH_SRCFAIL5/∗ src route failed ∗/
#defineICMP_SOURCEQUENCH4/∗ packet lost, slow down ∗/
#defineICMP_REDIRECT5/∗ shorter route, codes: ∗/
#defineICMP_REDIRECT_NET0/∗ for network ∗/
#defineICMP_REDIRECT_HOST1/∗ for host ∗/
#defineICMP_REDIRECT_TOSNET2/∗ for tos and net ∗/
#defineICMP_REDIRECT_TOSHOST3/∗ for tos and host ∗/
#defineICMP_ECHO8/∗ echo service ∗/
#defineICMP_TIMXCEED11/∗ time exceeded, code: ∗/
#defineICMP_TIMXCEED_INTRANS0/∗ ttl==0 in transit ∗/
#defineICMP_TIMXCEED_REASS1/∗ ttl==0 in reass ∗/
#defineICMP_PARAMPROB12/∗ ip header bad ∗/
#defineICMP_TSTAMP13/∗ timestamp request ∗/
#defineICMP_TSTAMPREPLY14/∗ timestamp reply ∗/
#defineICMP_IREQ15/∗ information request ∗/
#defineICMP_IREQREPLY16/∗ information reply ∗/

Arriving ECHO and TSTAMP packets cause the system to generate ECHOREPLY and TSTAMPREPLY packets.  IREQ packets are not yet processed by the system, and are discarded.   UNREACH, SOURCEQUENCH, TIMXCEED and PARAMPROB packets are processed internally by the protocols implemented in the system, or reflected to the user if a raw socket is being used; see ip(4P). REDIRECT, ECHOREPLY, TSTAMPREPLY and IREQREPLY are also reflected to users of raw sockets.  In addition, REDIRECT messages cause the kernel routing tables to be updated; see routing(4N).

SEE ALSO

inet(4F), ip(4P)
Internet Control Message Protocol, RFC792, J. Postel, USC-ISI (Sun 800-1064-01)

BUGS

IREQ messages are not processed properly: the address fields are not set. 

Messages which are source routed are not sent back using inverted source routes, but rather go back through the normal routing mechanisms. 

Sun System Release 1.0  —  17 August 1983