TCP/IP First-Step [Electronic resources] نسخه متنی

ICMP: A Protocol for System Messages

The last architectural component of the TCP/IP protocol suite that you need to know about is ICMP, which is an abbreviation for Internet Control Message Protocol. That's a real mouthful! Unfortunately, it's not meaningful or descriptive. Whoever thought up that name surely felt it was perfect, but it is awkward at best and meaningless at worst!

Without casting aspersions on whoever came up with the name, ICMP was first described way back in September 1981. It was published by the Internet Engineering Task Force (IETF) in RFC 792. You can still check out the original document at the following URL: http://www.faqs.org/rfcs/rfc792l.

ICMP rounds out the TCP/IP protocol suite. One could argue that it's redundant given that you have both TCP and UDP, but those protocols are user tools. Okay, you caught me: Those users can't directly use those protocol suites, but they are used directly by applications that users use. ICMP, on the other hand, is designed to carry system-level traffic.

System-level communications, like two routers letting each other know about congestion in the network, are also carried inside IP packets. Those packets are sent from one machine in a network to another but not on behalf of a live user. Thus, ICMP lurks in the shadows and remains almost completely transparent to people using IP networks.

In theory, packets that carry a user's data are a higher priority than system packets. Without philosophically exploring whether your online Doom packets are more important than two routers communicating information about a failure in the network, suffice it to say that you will miss the data if it gets dropped. Systems, on the other hand, won't miss a thing. Thus, when a network gets so busy that it can't keep up with all the generated packets, it can easily differentiate between user and system packets by looking at the protocol. If a packet uses either TCP or UDP, it's a user's packet. If a packet is ICMP, it's a system message; the network can lighten its load by dropping every ICMP packet it receives until the conditions on the network improve.

IP was not designed to be a reliable delivery mechanism. Reliable delivery is only possible when you add the higher-level capabilities of TCP. Thus, it is important to note that the purpose of ICMP messages is not to make IP reliable! The ICMP messages, however, allow networked devices to provide feedback to each other about various error conditions in either the network or with specific IP packets. Because ICMP uses IP, it is inherently unreliable. That means you aren't guaranteed to receive an ICMP message, nor will you ever receive an ICMP message about another ICMP message! ICMP messages are reserved strictly for network error conditions or error conditions within packets bearing user application data.

The Architecture

ICMP is a lightweight protocol that hardly qualifies for its own layer. A common misperception is that it's the third transport layer protocol suite in TCP/IP. If you read the introduction to this chapter carefully, you saw that it came close to calling ICMP a transport layer protocolbut it didn't! After all, IP is the only network layer protocol in the TCP/IP suite and ICMP does use IP packets to operate across a networkbut the argument ends there!

In fact, TCP and UDP are the only two transport layer protocols in the TCP/IP suite. ICMP is a lightweight protocolhardly a suite of protocols unto itself. ICMP is most properly described as being an integral component of IP, although it operates only at the top of IP, which is why it probably feels like a Layer 4 protocol.

Figure 10-1 shows you how ICMP fits in the TCP/IP architecture relative to the OSI reference model.

Visually, ICMP fits within the boundaries of the IP protocol suite. That's because it is an integral component; one of the IP protocols. It lies toward the top of the IP stack because it is a higher-layer function. That is, its functionality is close to transport protocols instead of network protocols.

Fields and Functions

ICMP uses the basic IP header structure to travel through a network. Much like how a TCP segment of data gets wrapped inside an IP packet, the ICMP message occupies an IP packet's data field. It's not considered part of the header and it is treated the same as TCP and UDP, which helps explain some of the confusion that surrounds ICMP.

The ICMP message contains the following structure:

Type Indicator
The first 8 bits of the ICMP message indicate the ICMP message type. This 8-binary field (bits) yields the ability to identify 2⁸, or 256, unique message types. Relax: There aren't that many message types defined and this chapter is limited to a subset of the most useful message types. Each message type is specifically designed to perform a special task. Table 10-1 identifies each of these message types for you.

Code Field
The next 8 bits are called the code field and they enable even more information about this particular ICMP packet and type to be supplied to the receiving node. The use of this field varies based on the ICMP message type. If you really want to know more about code field options, please read RFC 792!

Checksum
The next field is a 16-bit checksum. If you recall from earlier chapters, a checksum is a mathematical function that helps ensure that the contents of a datagram don't get changed en route to its destination. If a datagram gets damaged, the result of a common mathematical algorithm will be different for the destination and source machines. This difference tells the recipient, or destination, machine that the packet is damaged and to discard it.

ICMP has many different message types and you are introduced to them. Each message type is designed for a specific purpose and, consequently, has a slightly different structure to suit that purpose. The different structures share a common foundation, which is comprised of the fields just described.

Each message type can contain hundreds more bits of information, but some things vary greatly from message type to message type: the length, how those bits are carved up, and what each field does. For right now, consider these three fieldsa whopping 32 bitsthe ICMP "header." The rest of the ICMP structure is better thought of as data. The actual functionality of each ICMP message is determined by the message type and the contents of some of its code field.

Types of Messages

As mentioned, ICMP supports the creation of many types of messages. Each message type is designed for a specific purpose. These messages are listed in Table 10-1.

That probably didn't make much sense. Those really are all the types of special-purpose messages that you can createor that can be created by ICMP. If nothing else, looking at each message type enlightens you as to precisely what ICMP does!

Echo and Echo Reply

Echo and Echo Reply, two interrelated ICMP message types, are extremely useful. Their structures are remarkably similar so it wouldn't make sense to treat them separately. An Echo message contains two addresses: the sending computer's address and the destination machine's IP address.

Echo's purpose is to test whether any given machine is reachable through the network. Of course, this isn't a perfect test because, again, ICMP messages are the first to be dropped whenever a network gets congested. Consequently, testing reachability to any given destination using an ICMP Echo message only gives you an idea of that machine's reachability. It cannot, however, give you an understanding of that machine's status.

The Echo Reply message is virtually identical to the Echo message except that in an Echo Reply message the source and destination IP addresses are reversed. Thus, the Echo message's source IP address becomes the Echo Reply's destination address, and vice versa for the Echo message's destination IP address.

Destination Unreachable

When a destination is unreachable, it might be due to a wide variety of reasons. ICMP's job is to tell the source machine (whose packet failed to reach its intended destination) that it failed and to supply as much information regarding why it failed. To do that, ICMP must have some way of letting the source machine know exactly which of its packets failed. Thus, the failed IP packet's original header and the first 64 bits of the packet are tacked onto the ICMP header and sent back to the source machine.

When a machine in the network determines that a destination is unreachable (usually when trying to forward a packet addressed to that destination), it generates an ICMP Destination Unreachable message. The code field in that message uses its options to identify where the failure occurred. For example, the destination machine could be powered off or the network it is connected to could have suffered a major failure. Alternately, the network and the host could be perfectly fine, but the protocol (as identified by the destination port number in the TCP header) might not be configured.

Communicating the source of the problem is important. For example, if the entire network were unreachable, you want to spread the word broadly so that everybody's network knows about the problem and stops trying to send IP packets to machines within that unreachable network. If, however, the problem were that just one machine was turned off, all the other machines in that network would still be reachable. Thus, you wouldn't want to continue sending IP packets addressed to that network.

The possible code field options are listed in Table 10-2.

Although the code field values in this section are identified in decimal numbers, the actual field in the ICMP header is a binary field. The decimal values are given to make life a little easier.

Networks are remarkably complex and lots of things can go wrong. The code field helps you understand which packet failed to get where it was going and why! After seeing Table 10-2, you should have a fairly good appreciation for how that happens.

Source Quench

Source quench is another classic example of a name that must have made sense to some nerdy bunch of engineers locked inside a conference room for too many consecutive hours. The ICMP Source Quench message requests that the source machine in a TCP/IP communications session slow down.

Sometimes, a router or switch in the network or even a destination computer might become overloaded. That's a bad thing because it means the device will start dropping packets due to its inability to keep up with the incoming packets. Rather than sit back and wait for the inevitable, that troubled machine can start sending out ICMP Source Quench messages that tell sending machines to throttle down their packet transmission.

When (or if) network conditions improve, TCP/IP might allow networked devices to increase the rate of packet transmission. That's a function of TCP, not ICMPbut both protocols must work together to determine the most appropriate rate of transmission. ICMP handles the throttling back via source quench messages while TCP always tries to increase its rate of transfer using its sliding window mechanism.

Redirect

It's better to have something that you probably won't ever need than to need something you probably won't ever have! The redirect message falls into the former category. Under normal operating circumstances you won't need this function. However, things can and do change in a network. When changes occur, packets sometimes get caught midstream! This is where the ICMP Redirect message can come in handy.

To better understand this, a couple of pictures are required. Please take a look at Figure 10-2. This shows a sample internetwork that consists of Networks 10.1.1.0/24, 10.1.2.0/24, 10.1.3.0/24, 10.1.4.0/24, and 10.1.5.0/24. Rather than show you a complicated network topology, you see the network engineer's old standby: a cloud! Clouds are commonly used to portray networks from an architectural perspective.

In Figure 10-2, a router inside Network 10.1.3.0/24 accepts a packet that was sent by a computer connected to Network 10.1.1.0/24. This packet is bound for Network 10.1.4.0/24. Unfortunately, Network 10.1.3.0/24 doesn't have a direct connection to that network. To get that packet delivered, it would have to be passed through Networks 10.1.2.0/24 and 10.2.5.0/25 before finally reaching its destination. There's nothing wrong with that.

Quite often when you surf the Internet, your packets pass through 20 or more networks; passing through five should not be a big deal. The real problem is that Network 10.1.3.0/24 doesn't have a direct connection to Network 10.1.4.0/24, but Network 10.1.1.0/24 does! The fact that Network 10.1.1.0/24 has a more direct connection to the destination network but didn't use it indicates that something is wrong. It is likely working with obsolete information as a result of a recent change in the network. Believe it or not, information flows quicklybut not immediatelythroughout devices in a network.

In situations like this one, the right thing to do is let Network 10.1.1.0/24 know, "Hey! There's a better way!" with the hope that future packets will take the more efficient path. That "Hey" message is really an ICMP Redirect message. This is shown in Figure 10-3.

The router on Network 10.1.3.0/24 sends that packet along, but takes the time to notify its peer network using an ICMP Redirect message. Redirects can be a difficult topic to understand, but after you understand them you develop a greater appreciation for just how much goes on behind the scenes in a TCP/IP network. This simple example should give you a sense of how ICMP and redirects actually work.

Time Exceeded

Time can be exceeded two ways with respect to transmitting TCP/IP. The first, and most obvious, is that the packet wandered around a congested or ailing network for too long without finding a route to its destination. Eventually, the IP packet's Time-To-Live (TTL) timer expires and the packet is destroyed. Rather than wait until TCP figures out that a segment has gone missing, the machine that destroyed the segment sends a courtesy note back to the source machine. That note comes in the form of an ICMP Time Exceeded message! That message has a code value of 0.

The second way is a bit more subtle. Remember that TCP segments might require reassembly at their destination. Thus, incoming TCP segments are stored in a section of memory until enough consecutive segments are received to completely reassemble a larger piece of data that the application can actually use. A file, for example, might require dozens or more segments/packets. It is entirely possible that the destination machine loses patience and declares the segments in memory too old to be useful. That machine would generate an ICMP Time Exceeded message to inform the source machine of its actions. That message bears a code value of 1.

Parameter Problem

Sometimes IP packets just don't get formed properly. Other times, a well-made IP packet gets damaged in transit by electromagnetic interference. Either way, the result is the same: A machine receives an IP packet that just doesn't make sense!

The contents of the IP header are not consistent with valid value ranges in one or more of the fields. When this happens, your best bet is to just throw it away!

IP packets that have header parameters with problems can be identified either at the destination machine or at any network device between the source and destination. Regardless of who finds the problem, the right thing to do is request a retransmission. The ICMP Parameter Problem message is the right way to accomplish this task.

To make sure the source machine knows exactly which packet was damaged and then discarded, the machine that generates the ICMP Parameter Problem message must include some information about that damaged packet. As with any ICMP message dealing with a specific IP packet, this is accomplished by taking the header of that IP packet plus the first 64 bits of its payload and appending them at the back of the ICMP message. Upon receipt of such a message, the source machine knows precisely which packet to retransmit.

In all fairness, today's network and computing devices are sophisticated and manufactured to strict specifications. They operate extremely reliably and rarely generate a poorly formed IP packet. Thus, the ICMP Parameter Problem message type probably sees less use than any other. Still, it is nice to know it's there!

Timestamp and Timestamp Reply

Timestamp and Timestamp Reply are the last message types covered. It takes some time and a few more chapters to fully appreciate the purpose for the functionality enabled by these two messages.

This pair's goal is to establish not only the date and time, but how many milliseconds have elapsed since midnight, Universal Time. Although that might sound esoteric, if not completely silly, that capability allows you to establish a common point of reference throughout a network. That common point of reference forms the foundation for timing events such as computing roundtrip times in a network. Imagine trying to perform that task in an environment in which there were no consistent time from device to device. That would truly be an exercise in frustration. It is important to note that the ICMP Timestamp message doesn't keep track of time in your network. The message enables you to check the time on a given system.Network Time Protocol (NTP), which is responsible for maintaining the synchronicity of time throughout a network.