icmp(5P) icmp(5P)NAME icmp - Internet Control Message Protocol SYNOPSIS None; included automatically with inet(5F). 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(5P). 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 gate- way does not have the buffering capacity to forward a da- tagram, and when the gateway can direct the host to send traffic on a shorter route. The Internet protocol is not designed to be absolutely reli- able. 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 proto- cols 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 da- tagram. To avoid the infinite regress of messages about messages etc., no ICMP messages are sent about ICMP mes- sages. ICMP may however be sent in response to ICMP mes- sages (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. (Comments have been stripped for this listing.) /* * Definition of type and code field values */ #define ICMP_ECHOREPLY 0 #define ICMP_UNREACH 3 #define ICMP_UNREACH_NET 0 #define ICMP_UNREACH_HOST 1 #define ICMP_UNREACH_PROTOCOL 2 #define ICMP_UNREACH_PORT 3 #define ICMP_UNREACH_NEEDFRAG 4 April, 1990 1
icmp(5P) icmp(5P)#define ICMP_UNREACH_SRCFAIL 5 #define ICMP_SOURCEQUENCH 4 #define ICMP_REDIRECT 5 #define ICMP_REDIRECT_NET 0 #define ICMP_REDIRECT_HOST 1 #define ICMP_REDIRECT_TOSNET 2 #define ICMP_REDIRECT_TOSHOST 3 #define ICMP_ECHO 8 #define ICMP_TIMXCEED 11 #define ICMP_TIMXCEED_INTRANS 0 #define ICMP_TIMXCEED_REASS 1 #define ICMP_PARAMPROB 12 #define ICMP_TSTAMP 13 #define ICMP_TSTAMPREPLY 14 #define ICMP_IREQ 15 #define ICMP_IREQREPLY 16 Arriving ECHO and TSTAMP packets cause the system to gen- erate ECHOREPLY and TSTAMPREPLY packets. IREQ packets are not yet processed by the system, and are discarded. UN- REACH, SOURCEQUENCH, TIMXCEED and PARAMPROB packets are pro- cessed internally by the protocols implemented in the sys- tem, or reflected to the user if a raw socket is being used; see ip(5P). REDIRECT, ECHOREPLY, TSTAMPREPLY and IREQREPLY are also reflected to users of raw sockets. In addition, REDIRECT messages cause the kernel routing tables to be up- dated; see routing(5N). SEE ALSO inet(5F), ip(5P). Internet Control Message Protocol, RFC792, J. Postel, USC- ISI BUGS IREQ messages are not processed properly: the address fields are not set. Messages which are source routed are not sent back using in- verted source routes, but rather go back through the normal routing mechanisms. 2 April, 1990