ICMP

Table of Contents

References

Introduction

The Internet Control Message Protocol is TCP/IP’s one-trick pony. It was designed to do a single simple thing: provide a way for a system located anywhere on the network to report problems with packets that have been sent to it.

Using ICMP, any networked system can transmit a complaint to any other networked system that is generating faulty packets or asking for resources unavailable on the addressed system. The network path may contain as few as two systems or as many as several hundred. No matter how many hops the path involves, ICMP messages can still find their way back to the originating system…that is, they usually can. In other words, ICMP acknowledges Murphy’s Third Law — “If anything can go wrong, it will” — and tries to enable prompt recovery from transient problems by letting the sending program know that a data packet is having trouble or causing problems.

The original intent of ICMP, which was introduced in the mid-1980s, was to provide error notification and some low-level network-testing mechanisms. Because IMCP was built into the system at the kernel level, it didn’t need applications-level support. Nor did it require many system resources. Naturally, researchers and users soon came up with nifty new ideas for testing the network, and ICMP became somewhat bloated. At one point, attempts were even made to load more functions into ICMP. Fortunately, the functions that didn’t refer specifically to network management were later properly moved to non-kernel protocols, such as BOOTP (Boot Protocol) and DHCP (Dynamic Host Configuration Protocol).

In addition to its error-message functions, ICMP still includes several maintenance services (which operate via query/response packets) that let a system administrator (whether human or cybernetic) track down problems on the network. These services are provided on the assumption that before a communications problem can be fixed, it first has to be found. And in order for it to be found, the network has to be diagnosed. ICMP’s diagnostic tools, such as Ping and Timestamp, help system administrators do this.

But, you may ask, aren’t ICMP packets themselves subject to diagnostics? The query/response packets are; the error packets aren’t. Query/response packets are handled by the ICMP code in just the same way as non-ICMP packets. But corrupted or defective ICMP error-report packets simply disappear. This is actually a good thing, because it would be difficult (not to mention wasteful of system resources) to try to track the permutations and combinations of layered error reports. It’s much simpler, and in fact more effective, just to forget munged error packets.

Well-Mannered Messages

In contrast to almost every other error-detection and error-notification message system in computing, whose level of civility rarely rises above “Nyah-nyah, you goofed,” ICMP messages are like a polite tap on the shoulder: “Pardon me, but your slip is showing.” In other words, they are purely advisory. They have to be, because there’s no guarantee that an ICMP message will get back to the originating system. ICMP packets are just as prone as any other Internet Protocol packet to being lost or mangled on their way through the Internet clouds. Thus, ICMP messages constitute a best-effort way to let an originating system know that something went wrong with a packet.

ICMP messages also help speed up error processing. If a computer system gets an ICMP message, it doesn’t need to wait for a timeout before taking corrective action. Assume, for example, that System A sends a defective IP packet (such as one that specifies a TCP port number that isn’t attached to a peer process in the remote system). The receiving system (System B) can either hazard a guess about what to do with the packet, silently drop the packet (forget about it), or drop the packet and send back an ICMP error message telling the originating system what went wrong.

An ICMP error message contains the headers of a packet that was sent, so the ICMP message can correlate the error with a specific location in an IP packet header. For instance, suppose a IP packet is used to carry an Exterior Gateway Protocol (EGP) packet. System A is running EGP, and directs an EGP packet (which is an IP packet that specifies the EGP in its header) to System B. But suppose System B isn’t running EGP. System B will then generate an ICMP packet that contains a copy of the front (that is, the first 48 or so bytes) of the packet that triggered the error — this is so the system receiving the ICMP message can figure out which process and socket has the problem. This ICMP packet contains a pointer to the protocol field in the IP packet header, and the type code in the ICMP packet says “Parameter problem,” and the subtype (the “code”), says “IP header bad.”

Most ICMP error messages are sent back to the ultimate, original source of the offending IP packet. However, there is one exception: the ICMP Redirect packet. When System A sends a packet to System B, and System B determines that the only route for the packet is back through System A, then not only does System B return the packet, but System B also sends an ICMP Redirect packet to System A to let System A know that System B thinks that System A has a problem in its routing tables — did you follow all that?

ICMP Packet Details

Figure 1 shows the layout of the ICMP packet and the values for specific fields within the packet, and Table 1 shows the values for the type and code fields for each type of ICMP packet. No specific ports are associated with ICMP packets. The actual length of an ICMP packet depends on the implementation of the protocol that is running on the system that is sending the packet.

For an exhaustive discussion of every combination of ICMPv4 type and code, refer to the indicated RFC for all the information. Meanwhile, the notes in Table 1 provide a “cheat sheet” for each code. The shaded codes are elements that were replaced by later RFCs. Note that some of the codes have been deprecated by later RFCs, but are not marked as such here.

Although not officially part of this Commentary (yet), we include a table of the ICMPv6 codes and their format. Note that the type numbers for ICMPv4 and ICMPv6 are different.