| The Internet Control Message Protocol (ICMP) is the error-report mechanism for the IP layer, which also resides in the network layer. Though ICMP is based on IP, it doesn't make IP more reliable. Packets can be lost despite the use of ICMP, and IP or ICMP won't notice that packets are lost. The only purposes of this error-report mechanism are to report errors to other computers and to respond to such reports. It is mendatory for each IP implementation to implement ICMP. The ICMP implementation is defined in the following RFC documents: RFC 792 [Post81b]: This is the basic definition, describing the packet types and their uses. RFC 1122 [Brad89]: Definition of the requirements on terminal equipment (hosts) connected to the Internet. RFC 1812 [Bake95]: This document describes the requirements for switching computers (routers) in the Internet.
However, RFC specifications often leave much room for flexible implementation. For some functions, it is even optional whether you implement them. For this reason, ICMP implementations and even configurations of the same implementation can differ considerably. The most popular application of ICMP is error detection or error diagnostics. In more than ninety percent of all cases, the first information transmitted by a newly installed network adapter over an IP network will probably be that of the ping command, which is fully based on ICMP. This allows you to check the reachability of other computers easily and without noticeable load on the network. This procedure is often done in automated form (e.g., to monitor servers). Beyond simply checking the reachability of computers, the set of different error messages allow a network administrator (or a network-analysis tool) to obtain a detailed overview of the internal state of an IP network. For example, poorly selected local routing tables or wrongly set transmit options in individual computers can be detected. And finally, it is possible to use ICMP to synchronize computer clocks within a network, in addition to other partly outdated functions, which will be briefly discussed in this section. 14.4.1 Functional Principle of ICMP ICMP sends and receives special IP packets representing error or information messages. Error messages occur whenever IP packets have not reached their destinations. All other cases create information messages, which can additionally include a request for reply. Notice that the ICMP functionality becomes active within the network implementation of the Linux kernel only provided that a problem situation occurs during another data traffic or when ICMP packets arrive from another computer. As mentioned earlier, ICMP transmits messages in IP packets. Figure 14-11 shows the general structure of ICMP messages (gray fields), which are transported in the payload of an IP packet. It is typical for the IP header of a packet containing an ICMP message that the Type-of-Service field is set to 0x00, which means that the packet is treated like a regular IP packet without priority. The protocol type in the IP header for ICMP messages is set to 0x01, as specified in RFC 790 [Post81a]. Figure 14-11. Structure of an IP packet containing an ICMP message. 
The 8-bit Type field in the ICMP part specifies the type of ICMP message. The Code field specifies the values an ICMP message can take. The original RFC 792 defines a total of eleven messages, but the current Linux implementation supports only some of them. These eleven messages are listed in Table 14-2. The 16-bit checksum extends over all fields starting from the ICMP type (i.e., over the entire part that IP treats as payload). Table 14-2. ICMP packet types defined in RFC 792.Type | Description |
|---|
Destination Unreachable | The destination address cannot be reached. | Time Exceeded | A packet was discarded, because its TTL has expired. | Parameter Problem | Unknown or false options. | Source Quench | Informs the sender that IP packets were lost to overload. | Redirect | Enables path optimization. | Echo and Echo Reply | The data sent to the destination address is returned in a reply. | Timestamp and Timestamp Reply | The timestamp sent to the destination address is used-to reply with the timestamp of the destination address. | Information Request und Information Reply | Request/reply used to find the network a computer connects to. |
The following subsections describe the ICMP messages defined in RFC 791. Destination Unreachable The packet for a Destination Unreachable message includes the following fields: Type-0x03 | Code | Checksum | unused | IP Header + 64 Bits of Original Data |
Code = 0x00 (Network Unreachable): The network of an IP packet's receiver is not reachable. This can happen, for example, if the distance to the receiver's network is set to infinite in the routing table of a router. Code = 0x01 (Host Unreachable): The desired destination computer in the specified network cannot be reached. Code = 0x02 (Protocol Unreachable): This message can be generated if another protocol listens to the destination port specified in the TCP packet header. The message can be sent both by a router and by a router and by an end system. Code = 0x03 (Port Unreachable): The port address of the receiver specified in the TCP packet header is not reachable. The end system is "reachable" in this case, too, so both a router and an end system can generate this message. Code = 0x04 (Fragmentation Needed): This ICMP packet can be sent if an IP packet has to be fragmented in a router, but the Don't-Fragment flag is set in the packet header, so that the packet may not be fragmented. In this case, the router has to discard the IP packet. Code = 0x05 (Source Route Failed): If the IP packet option Source Routing is set and an error occurs, then this ICMP message is returned to the sender.
The IP header of the packet that caused the ICMP message, plus the first 64 data bits, are specified in the payload part of the ICMP message Destination Unreachable. Source Quench The packet of a Source Quench message is structured as follows: Type-0x04 | Code-0x00 | Checksum | unused | IP Header + 64 Bits of Original Data |
When the network load is high, it can happen that a router (or the receiver) discards IP packets because of a lack of resources (e.g., memory space or computing capacity). If this happens, then a Source Quench message can be transmitted to the sender. RFC 792 specifies that an ICMP implementation can generate such an ICMP message for each discarded packet. The sender should then respond by slowing down its transmission rate until no more Source Quench messages arrive. Subsequently, the sender can gradually increase its rate. Instead of responding to discarded packets, routers, or end systems can send ICMP messages of the Source Quench type before they reach their capacity limits, to prevent the consequences of lost packets. The only value defined for the Code field of a Source Quench message is 0x00. The payload part includes the IP header of the triggering IP packet and the first 64 bits of that packet's payload. Redirect The packet of a Redirect message is structured as follows: Type-0x05 | Code | Checksum | Router IP Address | IP Header + 64 Bits of Original Data |
This ICMP message type is designed to optimize routing through the Internet. Assume that a router, R1, receives an IP packet of a sending end system, S, with receiver E. Based on a corresponding entry in the routing table of R1, this packet is forwarded to router R2. However, if R2 and S are in the same network (which can be determined based on the sender address), this route can be optimized by sending packets from S to receiver E directly to router R2 over R1, without detour. In this case, router R2 would send a Redirect message to end system S to announce that packets to receiver E will be sent directly to R2 in the future. Consequently, the field Router IP Address would contain the IP address of R2. The Code field would take either of the following values: Code = 0x00: Redirect IP packets that should be sent to the network that connects the receiver of these IP packets. Code = 0x01: Redirect all IP packets that should be sent to the specified receiver. Code = 0x02: Redirect all IP packets that should be sent to the receiver's network and have the same value in the TOS field as the IP packet that triggers the ICMP message. Code = 0x03: Redirect all IP packets that have the same receiver and the same TOS field as the IP packet that triggers the ICMP message.
Notice that no Redirect message is sent if the Source Route option is set in the IP packet options, even if there would be a shorter path to the receiver. The last field specifies the IP header and the first 64 data bits of the initiating packet. Echo and Echo Reply The packet of an Echo or Echo Reply message is structured as follows: Type | Code-0x00 | Checksum | Identifier | Sequence Number | Data... |
Echo and Echo Reply messages are normally used to verify the existence of an end system or intermediate system. To this end, an Echo message is sent to the desired system. The ICMP implementation in the receiver has to respond to this Echo request by sending an Echo Reply message. Echo and Echo Reply messages differ only in the Type field: 0x08 specifies an Echo message and 0x00 specifies an Echo Reply message. The Code value has to be set to 0x00 for both types. RFC 792 does not define explicit values for the other fields (i.e., Identifier, Sequence Number, and Data); therefore, the application can set these fields arbitrarily. The only thing the ICMP implementation has to ensure is that these three fields are copied from an Echo message to the Echo Reply message. The Data field can have an arbitrary length. For example, an ICMP application could use session numbers for the Identifier field and increment the sequence number for each Echo message it sends. Time Exceeded The packet of a Time Exceeded message is structured as follows: Type-0x0B | Code | Checksum | unused | IP Header + 64 Bits of Original Data |
An ICMP message of the type Time Exceeded is generated and returned to the sender if the lifetime of the IP packet has expired (i.e., its TTL value is 0) and the packet was discarded. There could occur either of the following two cases: Code = 0x00: A router sends this message if it discarded a packet because its TTL had expired. Code = 0x01: An end system sends a message with this code if it was unable to reassemble a fragmented IP message correctly within a certain time, because fragments were missing.
As in the Destination Unreachable message, the payload part in the Time Exceeded message includes the IP header of the packet that caused the ICMP message, plus the first 64 data bits from that packet. Parameter Problem The packet of a Parameter Problem message is structured as follows: Type-0x0C | Code-0x00 | Checksum | Pointer | unused | IP Header + 64 Bits of Original Data |
If an error due to an invalid parameter in the IP header occurs while an IP packet is being handled in an intermediate node or end system, then this IP packet is discarded. For example, this can happen if there is a wrong argument in the IP packet options. In this case, the router or end system can generate an ICMP message of the type Parameter Problem and return it to the sender of the discarded IP packet. The Code field has to be set to 0x00 in all cases, which means that the Pointer field shows an error. More specifically, the pointer points to the octet in the original IP packet header where the problem occurred while the packet was being processed. For example, the value Pointer=0x01 means that the version number (i.e., the first field in the IP packet header; see Figure 14-11) is faulty. The IP packet header of the discarded packet and the first 64 bits of its payload are attached to the ICMP message. Timestamp and Timestamp Reply The packet of an Timestamp or Timestamp Reply message is structured as follows: Type | Code-0x00 | Checksum | Identifier | Sequence Number | Originate Timestamp | Receive Timestamp | Transmit Timestamp |
These two ICMP message types are used to poll the current time from an intermediate or end system. The exchange is similar to the two previous message types, Echo and Echo Reply. The Type field is used to distinguish between Timestamp and Timestamp Reply: A value of 0x00 specifies a Timestamp message, and 0x0E denotes a Timestamp Reply message. The exclusive value for the Code field is 0x00. As for Echo and Echo Reply, the fields Identifier and Sequence Number are required by the sender to be able to allocate a Timestamp Echo message to a Timestamp message properly. The payload part of these two ICMP messages consists of 32-bit timestamps. A timestamp is the time in milliseconds that has passed since midnight (GMT). The Originate Timestamp field defines the time when the transmitted ICMP message was last "touched" by the sender. Similarly, there is a Receive Timestamp specifying the time that the message arrived in the receiver. Transmit Timestamp stores the time at which the Timestamp Reply message was sent. Information Request and Information Reply The packet of an Information Request or Information Reply message is structured as follows: Type | Code-0x00 | Checksum | Identifier | Sequence Number |
The way these two ICMP message types operate is similar to the Echo and Echo Request messages, except that they don't have a payload field. This message pair allows you to additionally identify the network that connects a computer. For this purpose, the value 0.0.0.0 is used as receiver address, which means that all computers in the local area network are addressed. The ICMP modules of these computers react to an Information Request by sending an Information Reply, where they state the LAN identifier instead of 0.0.0.0. The Identifier and Sequence Number fields are used to allocate Information Request and Information Reply pairs, similarly to an Echo and Echo Reply pair. The Type field is defined as follows: 14.4.2 Configuring ICMP The specified RFCs allow the local system administrator to control the behavior of some ICMP functions. The Linux implementation includes three cases where the sysctl() function can be used to control behavior at runtime: Echo Replies: The system manager can decide whether Echo Replies may be sent at all, for security reasons. This option is activated by default. Echo Replies to broadcast packets: The system manager can decide whether a reply should be sent to an Echo Request packet addressed to all computers in a LAN (i.e., destination address 0.0.0.0). This option is deactivated by default. Monitoring illegal ICMP broadcast replies: Faulty ICMP messages sent as a response to an IP broadcast can be ignored. (See RFC 1122 [Brad89].) This is not the case by default.
In addition, RFC 1812 [Bake95] specifies that the transmission rate of ICMP messages should be limited and that this limit should be configurable. The transmit function icmp_send() is limited accordingly, but the rate can be set only in the source code (in the xrlim_allow() function, XRLIM_BURST_FACTOR constant), which means that you have to recompile the Linux kernel. 14.4.3 ICMP in the Linux Kernel The Linux implementation is done mainly in the file net/ipv4/icmp.c and in the associated header file include/linux/icmp.h. Each ICMP message type is defined as a constant with the type fields specified in RFC 792: ICMP_ECHOREPLY = 0 ICMP_DEST_UNREACH = 3 ICMP_SOURCE_QUENCH = 4 ICMP_REDIRECT = 5 ICMP_ECHO = 8 ICMP_TIME_EXCEEDED = 11 ICMP_PARAMETERPROB = 12 ICMP_TIMESTAMP = 13 ICMP_TIMESTAMPREPLY = 14 ICMP_INFO_REQUEST = 15 ICMP_INFO_REPLY = 16 ICMP_ADDRESS = 17 ICMP_ADDRESSREPLY = 18
Almost all IP modules use the ICMP implementation to send ICMP messages. icmp_unit() | include/linux/icmp.h |
From the local perspective, the ICMP layer is stateless, except for a few internal statistics, but messages exchanged between two computers can include states. The ICMP socket is the only central structure included in the implementation. This socket can be reached exclusively with root privileges. This is the reason why, for example, the ping command requires root privileges. The initialization function icmp_unit() creates this socket. The statistical information mentioned in the previous section is maintained in the data structure icmp_statistics. It includes the number of packets sent and received in total, the number of errors incurred, and the accumulated number of ICMP types. The current contents from this statistics variable can be output from the pseudo file /proc/net/snmp. This file includes the meaning of the individual entries in the form of abbreviated ICMP types with leading "In" or "Out" for each packet and an additional row with values from the statistics array. The following listing is an example to show you what the contents of the /proc/net/snmp can look like: > cat /proc/net/snmp Ip: Forwarding DefaultTTL InReceives InHdrErrors InAddrErrors ForwDatagrams InUnknownProtos InDiscards InDelivers OutRequests OutDiscards OutNoRoutes ReasmTimeout ReasmReqds ReasmOKs ReasmFails FragOKs FragFails FragCreates IP: 2 64 900 0 0 0 0 0 64 963 0 0 0 0 0 0 0 0 0 Icmp: InMsgs InErrors InDestUnreachs InTimeExcds InParmProbs InSrcQuenchs InRedirects InEchos InEchoReps InTimestamps InTimestampReps InAddrMasks InAddrMaskReps OutMsgs OutErrors OutDestUnreachs OutTimeExcds OutParmProbs OutSrcQuenchs OutRedirects OutEchos OutEchoReps OutTimestamps OutTimestampReps OutAddrMasks OutAddrMaskReps Icmp: 35 0 15 0 0 0 0 11 9 0 0 0 0 26 0 15 0 0 0 0 0 11 0 0 0 0 Tcp: RtoAlgorithm RtoMin RtoMax MaxConn ActiveOpens PassiveOpens AttemptFails EstabResets CurrEstab InSegs OutSegs RetransSegs InErrs OutRsts Tcp: 0 0 0 0 4 0 0 0 0 816 888 0 0 0 Udp: InDatagrams NoPorts InErrors OutDatagrams Udp: 25 6 0 31
Sending ICMP Packets You can send ICMP packets from outside of the ICMP implementation in the Linux kernel for example, from within the ping program. This case is independent of the functions discussed below and will not be further discussed here. icmp_send() | include/linux/icmp.h |
Within the Linux kernel, an ICMP message is sent by the function icmp_send() in all cases where the message is not a reply to an ICMP message. This function gets all data from an ICMP message as call parameters, which means that it can send any ICMP type. In addition, to generate an ICMP packet correctly, this function is responsible for limiting the transmission rate of ICMP messages (see also the configuration options discussed in Section 14.4.2) and for catching cases where no ICMP messages may be sent. In this respect, two cases are possible: If the IP packet that initiated an ICMP message was an ICMP error message, then a reply to this error message could cause an infinite cycle of ICMP messages. If an IP packet was fragmented, then an ICMP message is sent for the first fragment only to avoid loading the network unnecessarily with redundant packets.
Table 14-3 shows the cases where Linux kernel modules send ICMP messages. Table 14-3. Generating ICMP messages from within the kernel modules.Type | Module | Reason |
|---|
Time Exceeded | Forward and defragment packets | A packet was discarded because it's TTL expired. | Parameter Problem | Detect packet options | Unknown or false options | Redirect | Packet routing | Obvious potential for optimization | Destination Unreachable | All modules that send, forward, or deliver IP packets | Inability to deliver a packet |
Handling Incoming ICMP Packets The central structure used to handle ICMP packets that arrive in an end system or intermediate system is a function pointer array named icmp_pointers. This array is responsible for flow control and includes the function handling ICMP type n in position n. The major benefit of this method, compared to using a switch-case instruction to implement the same behavior, is that each function in the array includes context information in the form of statistics variables. These statistics variables are defined in relation to the respective ICMP handling function. This means that this array specifies the auxiliary function used to handle an ICMP message. These auxiliary functions can be divided into two groups: auxiliary functions for local changes only, and auxiliary functions that also send a new ICMP packet. The most important functions used in the ICMP implementation in Linux will be described next. icmp_rcv() | include/linux/icmp.h |
This function is responsible for processing incoming ICMP packets, including a preprocessing process that drops noncompliant packets. While the internal statistics are being updated when an ICMP message arrives, the packet is also checked for correct length. In addition, the checksum is computed over the packet header, and the ICMP type is checked for a valid number. If the user has not set options in sysctl, then incoming broadcast packets of the types ICMP Echo, ICMP Timestamp, ICMP Information Request, and ICMP Information Reply are discarded. The following functions are invoked from within the icmp_rcv() function for incoming ICMP packets: icmp_reply() | include/linux/icmp.h |
The function icmp_reply() is generally used to reply to ICMP request packets. Before a reply is sent, the internal statistics variables are updated first; then the TOS field is taken from Request, and the IP addresses of the sender and the receiver are swapped. Next, the packet is returned to the sender, including the payload passed as argument (corresponding to the ICMP reply packet). icmp_reply() is used by two functions, icmp_echo() and icmp_times(), to reply to Echo Request and Timestamp Request, respectively. icmp_redirect() | include/linux/icmp.h |
This function updates the routing table when an end system receives an ICMP message of the type Redirect. icmp_unreach() | include/linux/icmp.h |
This function handles three ICMP message types: Destination Unreachable, Source Quench, and Time Exceeded. After a number of tests for packet validity, this function passes the error message to the service of the next higher layer belonging to the initiating packet. Error messages as a result of ICMP messages are similar to the error codes defined in Section 14.4.1. In the case of Source Quench, the receiving computer is expected to reduce its sending rate, which will be handled by the protocol in the transport layer above IP. icmp_echo(), icmp_timestamp() | include/linux/icmp.h |
A new ICMP packet has to be sent to handle ICMP messages of the types Echo Request and Timestamp Request. The basic function icmp_reply() is used in either case. The transmission is based on the rules discussed in Section 14.4.3. For icmp_echo(), only the ICMP type is changed, to ICMP_ECHOREPLY, then the payload part is copied from the Echo packet, and finally icmp_reply() returns the packet to the sender. The function icmp_timestamp() responds to incoming Timestamp requests. Initially, it checks the length of packets previously received and finds out the current time. The payload is removed from the original ICMP packet and put into the reply packet, and the time is added to the Receive Timestamp and Transmit Timestamp fields. This means that the two time values in Receive Timestamp and Transmit Timestamp are always identical. Once the packet type has been changed to ICMP_TIMESTAMPREPLY, the function icmp_reply() returns the packet. icmp_addres(), icmp_address_reply() | include/linux/icmp.h |
The standard actually specifies that these two functions be implemented. However, this functionality is not supported by the Linux kernel, because the designers found inconsistencies in the standards and thought that an implementation would not be meaningful at this time. When icmp_address() is invoked, only a kernel message is output. When a Linux computer receives an ICMP Information Reply packet, then it checks this packet for correct network mask (and complains by outputting a kernel message if it finds an inconsistency). Another thing specific to the Linux implementation is that no reply is sent to packet types not discussed in this chapter. Deviations from the Standard Several ICMP functionalities originally specified in RFCs were not included in the ICMP implementation of Linux. The following properties are missing: The use of a Source Route specified in the IP options is not supported. If an IP packet that initiates an ICMP message is to use a specified route, then the ICMP packet would actually have to follow the same path back. This property is currently missing, but will presumably be implemented later. Sending Source Quench messages: The ICMP implementation in Linux sends no Source Quench packets. Today, it is considered pointless to send such packets, because they generate additional network load in an overload situation. (See RFC 1812 [Bake95].) Information Request/Reply: These packet types were originally designed for tasks that have more recently been handled by other protocols (e.g., allocating of IP addresses to booting computers without persistent memory). Currently, this problem is solved by RARP. For this reason, these packets are simply ignored. In addition, the use of these ICMP packet types was found to cause problems, because these two ICMP messages cannot be correctly applied in all cases. (See RFC 1812.) Though this functionality is still specified in this RFC, the Linux designers decided not to implement it. The only thing done is that a local error message is output when the computer receives an Information Reply message.
| 
