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 that 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 mechanisms if reliable communication is required. 

The ICMP messages typically report errors in the processing of datagrams; for fragmented datagrams, ICMP messages are sent only about errors in handling fragment 0 of the datagram.  To avoid the infinite regress of messages about messages etc., no ICMP messages are sent about ICMP messages.  ICMP may however be sent in response to ICMP messages (for example, ECHOREPLY).  There are eleven 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 specifying the cause of certain errors. 

/∗
 ∗ Definition of type and code field values
 ∗/
#define ICMP_ECHOREPLY  0/∗ echo reply ∗/
#define ICMP_UNREACH    3/∗ dest unreachable, codes: ∗/
#define  ICMP_UNREACH_NET0/∗ bad net ∗/
#define  ICMP_UNREACH_HOST1/∗ bad host ∗/
#define  ICMP_UNREACH_PROTOCOL2/∗ bad protocol ∗/
#define  ICMP_UNREACH_PORT3/∗ bad port ∗/
#define  ICMP_UNREACH_NEEDFRAG4/∗ IP_DF caused drop ∗/
#define  ICMP_UNREACH_SRCFAIL5/∗ src route failed ∗/
#define ICMP_SOURCEQUENCH4/∗ packet lost, slow down ∗/
#define ICMP_REDIRECT   5/∗ shorter route, codes: ∗/
#define  ICMP_REDIRECT_NET0/∗ for network ∗/
#define  ICMP_REDIRECT_HOST1/∗ for host ∗/
#define  ICMP_REDIRECT_TOSNET2/∗ for tos and net ∗/
#define  ICMP_REDIRECT_TOSHOST3/∗ for tos and host ∗/
#define ICMP_ECHO       8/∗ echo service ∗/
#define ICMP_TIMXCEED   11/∗ time exceeded, code: ∗/
#define  ICMP_TIMXCEED_INTRANS0/∗ ttl==0 in transit ∗/
#define  ICMP_TIMXCEED_REASS1/∗ ttl==0 in reass ∗/
#define ICMP_PARAMPROB  12/∗ ip header bad ∗/
#define ICMP_TSTAMP     13/∗ timestamp request ∗/
#define ICMP_TSTAMPREPLY14/∗ timestamp reply ∗/
#define ICMP_IREQ       15/∗ information request ∗/
#define ICMP_IREQREPLY   16/∗ 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 Release 3.0β  —  Last change: 25 July 1985