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
     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 that 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 and so on, 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 that 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



January 1992                                                    1

icmp(5P)                                                 icmp(5P)



          #define  ICMP_UNREACH_NEEDFRAG  4
          #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
     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(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 updated; see routing(5N).

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

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

SEE ALSO
     inet(5F), ip(5P)

     Internet Control Message Protocol, RFC792, J. Postel, USC-
     ISI













2                                                    January 1992