Chapter 5 - The Internet Control Message Protocol
 |  |
|
IP is an unreliable protocol, and as such, delivery is not guaranteed. In this model, if important datagrams are lost, then a higher-layer protocol (such as a transport-layer protocol like TCP or an application-layer protocol like TFTP) will eventually recognize that a problem has occurred and will deal with it. As the theory goes, important data will eventually get through.
However, sometimes a problem crops up that prevents all datagrams from getting through to their destination. When these kinds of nontransient errors occur, IP fails for a specific and avoidable reason, and the sender should be notified about the problem so that it can either stop sending data to that destination or modify its behavior so that the specific problem is avoided. IP uses the Internet Control Message Protocol (ICMP) for reporting these kinds of problems.
The ICMP Specification
ICMP is documented in RFC 792, which is included in STD 5 (the IP standard). As such, ICMP is a part of STD 5 and is therefore considered to be an Internet Standard protocol. However, RFC 792 contained some vagaries that were clarified in RFC 1122 (Host Network Requirements) and RFC 1812 (Router Requirements). In addition, much of ICMP's core functionality has been redefined and clarified in STD 2. As such, ICMP implementations need to incorporate RFC 792, RFC 1122, RFC 1812, and STD 2 in order to work reliably and consistently with other implementations.
RFC 792 states that the Protocol ID for ICMP is 1. When a system receives an IP datagram that is marked as containing Protocol 1, it should pass the contents of the datagram to ICMP for further processing. However, ICMP is not a transport protocol and is not used to deliver application data. Rather, ICMP is a control protocol like IGMP, useful for informing devices of network events and changes.
RFC 792 states that ICMP must be used whenever IP itself needs to report a problem. Thus, although ICMP works at a layer above IP, IP also depends on ICMP in order to function properly. ICMP and IP are tightly interwoven, and for all practical purposes are inseparable. For this reason, every IP implementation is also required to include ICMP.
The Need for ICMP
Remember that IP is only responsible for getting datagrams from one host to another, one network at a time. Each IP datagram gets sent as an individual entity capable of following whatever path is available to it. Datagrams are moved across whatever hosts, routers, and networks are capable of getting that specific chunk of data closer to its destination.
In this model, any IP datagram can fail to get delivered for any number of reasons. Some datagrams will get discarded simply because the next-hop router is unavailable, and the current router is unable to forward them. Sometimes a datagram will be destroyed due to the user on the sending system providing a nonexistent destination IP address or port number to their local application. In all of these cases, the system that detects an error will simply destroy the IP datagram that's failing, and move on to the next datagram waiting to be processed.
Depending upon the exact cause of the failure, the system that destroyed the datagram may or may not choose to return an ICMP error message back to the original sender, notifying it of the failure and its cause. Typically this decision is made based on whether the failure is transient or semi-permanent.
Transient failures such as invalid checksums are generally ignored, since it is assumed that the sender will eventually notice the failure and retransmit any important data (which may be handled by TCP or by an application-specific reliability mechanism). The assumption is that if the data wasn't important enough for the sender to use a reliable protocol, then the sender probably doesn't care that delivery failed, and the problem can go unreported. In this model, transient errors can be safely ignored, since it is somewhat unlikely that the next packet will have the exact same problem. Eventually, the transport or application protocol in use will detect the error, and the failure itself does not indicate that there is a problem with the network at large.
Conversely, semipermanent failures (such as invalid destination IP addresses) need to be reported to the sender immediately, since these kinds of failures represent fundamental problems with the network itself, or at least indicate that there is a problem in the way that the sender is trying to use the network. In either case, semi-permanent failures should always be reported back to the sender, thus either causing it to stop sending data to that destination, or forcing it to modify its behavior so that the specific problem is avoided.
ICMP is the protocol used to send failure messages back to a system when a semipermanent delivery problem has been detected. This includes events such as a destination being unreachable, the IP Time-to-Live value reaching zero, and so forth. In addition, ICMP can be used for exchanging general information about the network, or for probing the network for certain characteristics. For example, the popular ping program uses ICMP messages to test basic connectivity between two devices.
In fact, ICMP is essentially just a collection of predefined messages, each of which provide very specific functionality. When a system needs to send an ICMP message, it chooses a message from the dictionary, places the code for the message into an ICMP-specific datagram, and then transmits the ICMP message via IP back to the system that sent the original (failing) datagram.
The recipient will see that the IP datagram contains an ICMP message (as indicated in the IP header's Protocol Type field), examine the message and its data, and then hand the message off to the appropriate protocol for additional processing. If the message is intended for ICMP itself (such a message might be an echo request message, generated by ping), then ICMP will deal with the message directly and not involve any other protocols.
If the message is intended for IP (such a message might be a redirect message, suggesting that the sender should use a different router), then the message will be delivered to the system's IP software for processing. In this example, the IP software should update the local routing table to reflect the path suggested by the message and use that router for any subsequent traffic for the affected destination.
If the message is intended for a transport protocol (such a message might be destination port is unreachable ), then the message will be delivered to the appropriate transport protocol for processing. The transport protocol should process the message directly and then inform the application protocol of the error, suggesting that it stop sending data to that particular destination socket. Most of the ICMP error messages are meant to be processed by the transport protocols.
When Not to Send ICMP Messages
Just as it is important to know when to send an error message, it is also important to know when an error message should not be sent. For example, any transient error that causes delivery to fail (such as an invalid checksum or a data-link delivery failure) should not be reported. However, the ICMP specifications also state that ICMP error messages should not be generated when their usage will generate an excessive amount of network traffic. For example, RFC 1122 states that ICMP error messages should not be sent as the result of receiving:
Another ICMP error message (although ICMP error messages can be sent in response to ICMP query messages)
An IGMP message of any kind
An IP datagram with a destination IP address for a broadcast or multicast address
An IP datagram with a nonspecific source address (all zeroes, a loopback address, or a broadcast or multicast address)
A data-link frame with a broadcast or multicast address
Any fragment—other than the first fragment—from a fragmented IP datagram
The first rule is obvious. You would not want to generate ICMP error messages in response to other ICMP error messages, as a message loop could cause a network storm that would prevent any other packets from getting sent. However, RFC 1122 states that devices can send ICMP error messages in response to ICMP query messages. For example, a router can issue an ICMP Redirect error message in response to an ICMP Echo Request query message that was sent to the wrong router.
The reason that systems shouldn't generate ICMP error messages in response to broadcast or multicast datagrams is to keep network traffic to a minimum. For example, assume that a user on one host broadcasts a UDP message to all of the hosts on the local network, but only a few of the hosts were running the application associated with that UDP traffic. If all of the other hosts on the network sent a Destination Port Unreachable error message back to the sender, then the number of ICMP messages could be quite high. Every time a broadcast was sent, several ICMP error messages would also get generated, which could theoretically overwhelm the network if there were enough of these errors.
With multicast traffic (such as is used for streaming audio or video), this problem would be exacerbated since there could be many thousands of multicast datagrams, which would be followed by many tens- or hundreds-of-thousands of ICMP error messages. On a large shared-access network (such as nonswitched Ethernet), the resulting collisions could theoretically render the network useless. In addition, ICMP error messages should not be generated in response to IGMP messages, for much the same reason.
Note however that ICMP query messages can be sent to a broadcast address, and those messages should be responded to with additional query messages (but should not be responded to with ICMP error messages). For example, a user can use ping to send an ICMP Echo Request query message to all of the hosts on the local network, and any of the hosts on that network may respond with ICMP Echo Reply query messages (although this behavior is entirely optional according to RFC 1122). Therefore, the no errors for broadcast or multicast traffic rule only applies to ICMP error messages.
Similarly, systems should not return error messages in response to every fragment of a fragmented packet, since this process would also result in multiple messages being sent in response to a single IP datagram. Although the resulting congestion would probably not be as much of a problem as it would be with broadcast or multicast traffic, it would still be an unnecessary utilization of the available network bandwidth.
Reporting on Delivery Problems
As mentioned earlier, ICMP error messages are used when it is necessary to report a problem that is preventing delivery from occurring. Although IP is an unreliable protocol that may fail without warning, it is important for the network to know when problems occur that will prevent delivery from ever occurring.
This is a fundamentally different concept from packets simply becoming lost or corrupted. If a system is trying to send data to a destination network that is totally unavailable, then the sending system ought to know that no datagrams are ever going to make it through to the destination system. The problem should be reported to the sending application so it can stop sending data to that destination.
Although ICMP can be used to report on IP failures, it is important to note that ICMP does not make IP a reliable protocol. IP is still capable of losing packets, sending duplicate or out-of-sequence packets, or doing anything else that it wants to. Nor does the lack of ICMP messages mean that the network is functioning perfectly; a host may be ignoring messages for any number of reasons without an ICMP message ever getting returned to the sender.
By the same token, TCP is a reliable transport that uses negotiated connections for data exchange, and as such many of ICMP's error messages are not needed or used by TCP. For example, if an application specified an invalid port number on a destination system, the remote system's TCP software would simply reject the connection request, using the TCP Reset flag. The sender's TCP stack would be informed of the error immediately, and it would be redundant to send an ICMP message stating that the destination port was unreachable. This is true of almost every ICMP error message (but not all of them): TCP just doesn't need to know that a segment was not processed, because it's already keeping track of every segment that it sends.
Conversely, UDP does not have any circuit-management mechanisms, so it has no way to monitor individual segments. As such, UDP benefits greatly from ICMP error messages, and is the principle user of these messages.
Destination Unreachable error messages.
A Destination Unreachable error message can signify any number of problems. It can mean that a router was unable to find a path to a remote system, or it can mean that a port number on the destination system is currently unavailable, or it can signal a variety of other problems.
In order to provide more-detailed reporting, the Destination Unreachable message provides a variety of submessages (using the ICMP Message Code field as described later in Error message headers ). The major Destination Unreachable submessages documented in the various ICMP RFCs, include:
Network Unreachable
This error message means that no route for the destination network could be found in the routing table on the reporting router, and is commonly seen when a user tries to connect to a private address that is non-routable across the Internet. This message can also result when datagrams are sent to a router that has corrupt or out-of-date routing tables.
For example, Figure 5-1 shows Ferret (192.168.10.10) trying to send an IP datagram to 192.168.30.10. Since the default route on Ferret points to Sasquatch, Ferret sends the datagram to that router for forwarding. However, Sasquatch does not have a routing table entry for the 192.168.30.0 network, so it returns
an ICMP Destination Unreachable: Network Unreachable error message back to the sender.
 | ||||
| Figure 5-1. A typical scenario for Network Unreachable error messages | ||||
It's important to note that this error can be generated by any router between the source and destination systems. Since the problem may be short-term (and thus, may get fixed), Network Unreachable error messages are not meant to be the interpreted as a final work on routing issues, but should only be used to indicate that a temporary routing problem has occurred.
Host Unreachable
This error message means that the IP datagram could not be delivered to the final destination system. This error message is generated by the last-hop router if that router does not know how to reach the destination system in particular. Like the Network Unreachable error, this is only an advisory message and should not be interpreted to mean that the host does not exist.
Protocol Unreachable
This error message indicates that the specified transport protocol is unavailable on the destination system. This message is normally seen when a user tries to use a nonstandard transport protocol (like XTP) to communicate with another host that isn't running that protocol.
Port Unreachable
This error message means that the specified destination port number is not in use on the destination host. Typically, this error indicates that a client application has attempted to connect to a server application that is not loaded or that isn't using the port number expected by the client.
For example, Figure 5-2 shows Ferret trying to send an UDP datagram to port 69 (the well-known port for TFTP) on Froggy. However, Froggy is not running a TFTP server, so it returns an ICMP Destination Unreachable: Port Unreachable error message back to the sender.
 | ||||
| Figure 5-2. A typical scenario for Port Unreachable error messages | ||||
Port Unreachable errors are almost always generated by UDP. Since TCP uses a handshake to establish a connection with a remote system, the destination system's TCP stack would use the TCP Reset flag to reject the connection request if the destination port number were not in use by any applications.
Fragmentation Required but DF Bit Is Set
This error message indicates that the IP datagram had to travel across a network whose MTU was smaller than the IP datagram, but the datagram's Don't Fragment flag in the IP header was enabled. Since the router is unable to forward or fragment the datagram, it must be rejected.
For example, Figure 5-3 shows the host at 192.168.30.10 trying to send a 16 kilobyte datagram (with the Don't Fragment flag set in the IP header) to 192.168.10.10, which is on a segment that offers an MTU of only 1500 bytes. Since the router is unable to forward the datagram without fragmenting it, and the Don't Fragment flag is enabled, the router returns an ICMP Destination Unreachable: Fragmentation Required but DF Bit Is Set error message back to the sender.
Nowadays, the Fragmentation Required but DF Bit Is Set error message is most often seen with Path MTU Discovery, an algorithm defined in RFC 1191 that allows a sending system to discover the largest MTU size for an end-to-end
 | ||||
| Figure 5-3. A typical scenario for Fragmentation Required error messages | ||||
connection. Once the largest-possible MTU has been discovered, the sender can use that MTU on all subsequent datagrams, thereby preventing fragmentation from occurring on that connection. For more information on this procedure, refer to Notes on Path MTU Discovery later in this chapter.
Source Route Failed
This error message means that the router was unable to deliver the packet to the next-hop router as specified in the datagram's Source Route IP Option fields. Source routing may fail because an invalid next-hop router was specified, or because the router was unable to send the datagram to the specified next-hop router.
Destination Network Unknown
This error message means that the destination network absolutely does not exist. It should be sent only when the data-link network has unequivocable proof that the destination network really does not exist. This is the opposite of the Network Unreachable error, which only suggests that a path to the destination network could not be found in the current routing tables (although the network may actually exist). Whereas the Network Unreachable error message suggests that a network may not exist, the Destination Network Unknown error message states it as fact.
Destination Host Unknown
This error message means that the destination host absolutely does not exist. It should be sent only when the data-link network has unequivocable proof that the destination system simply does not exist. This is the opposite of the Host
Unreachable error, which only suggests that the destination system cannot be found (although the host may actually exist). Whereas the Host Unreachable error message suggests that a host may not exist, the Destination Host Unknown error message states it as fact.
Network Unreachable for Type-of-Service
This error message is generated by intermediary routers if any of the next-hop networks in between the sender and destination systems either do not support the Type-of-Service value requested in the IP datagram, or do not support the default Type-of-Service.If a device sends an IP packet with a particular Type-of-Service defined, but no path is available that matches that particular Type-of-Service, then the router should reject the packet and inform the sender of the problem.
Host Unreachable for Type-of-Service
This error message is generated by the last-hop router if the last-hop network for the destination system either does not support the Type-of-Service value requested in the IP datagram, or does not support the default Type-of-Service. If a device sends an IP packet with a particular Type-of-Service defined, but the last-hop network does not support that particular Type-of-Service, then the last-hop router should reject the packet and inform the sender of the problem.
Communication Administratively Prohibited
This error message means that the destination system is configured to reject datagrams from the sending system. This error is generally used when firewall restrictions or other security measures are filtering datagrams based on some sort of criteria. This message effectively says, The destination may be up and running, but it will not get the datagrams that you're sending. Stop sending them.
For example, Figure 5-4 shows Ferret (192.168.10.10) trying to send a datagram to Fungi (192.168.20.60). However, the router Sasquatch is configured to reject all datagrams from the 192.168.10.0 network, so it returns an ICMP Destination Unreachable: Communications Administratively Prohibited error message back to the sender.
Some firewalls are configured not to issue the Communication Administratively Prohibited messages, since such messages may be considered a security risk in their own right. Telling an attacker which hosts are being protected is not necessarily a good idea; sometimes saying nothing is the most secure option.
RFC 1122 also defines Communication With Destination Network Administratively Prohibited (code 9) and Communication With Destination Host Administratively Prohibited (code 10). However, these messages are reserved for use by U.S. military agencies, and aren't supposed to be used by the general public.
 | ||||
| Figure 5-4. Typical scenario for Communications Administratively Prohibited error messages | ||||
Host Precedence Violation
This error message means that the sender has specified a Precedence value for the IP datagram that is not supported by the intermediary network, destination network, destination host, or destination application. In order for the source to communicate with the destination, it must change the Precedence value of the IP datagram to a supported value.
Precedence Cutoff in Effect
This error will occur if a sending system defines a specific Precedence value that is lower than the minimum Precedence required on an intermediary or destination network. Such filters are typically found only on very expensive networks. In order for the source to communicate with the destination, it must increase the Precedence value of the IP datagram, or else use a different route for that specific destination.
According to RFC 1122, all Destination Unreachable error messages must be reported to the transport layer that triggered the failure. If the error indicates a soft failure (such as Network Unreachable), the transport layer should not abort the connection, but instead should note that the problem occurred. If the connection fails due to this problem, the error may be passed to the application protocol so that it can inform the user of the failure. If the error indicates a hard failure (such as Network Unknown), then the connection should be terminated immediately.
For more information on the Destination Unreachable error message, refer to
Destination Unreachable later in this chapter.
Time Exceeded error messages
Time Exceeded error messages are used to indicate that a forwarding or reassembly operation took too long to complete and that the reporting device is discarding the data. In order to provide more-detailed reporting, the Time Exceeded message provides two different submessages (using the ICMP Message Code field as described later in Error message headers ). The submessages offered by Time Exceeded include:
Time-to-Live Exceeded in Transit
This error message is used when an IP datagram's Time-to-Live value has reached zero but the datagram has not yet been delivered to its final destination. Since the Time-to-Live field indicates the maximum number of hops that a datagram can take, the router cannot forward a datagram with a Time-to-Live value of zero, and must destroy it instead. Since most systems use Time-to-Live values of 30 or more, the presence of this message generally indicates that a routing loop is preventing the datagram from being delivered.
However, this message is also used with the traceroute program to identify the routers in between a source and destination system. For more information on how traceroute uses this message, refer to Notes on traceroute later in this chapter.
Fragment Reassembly Time Exceeded
This error message is used when a datagram has been fragmented but the destination system has not received all of the fragments within the allotted time (60 seconds on most Unix systems). This message generally indicates that a fragment has been lost in transit somewhere and that the destination system is discarding the other fragments that it has received.
According to RFC 1122, all Time Exceeded error messages must be reported to the transport layer that triggered the failure, although the transport layer should not abort the connection. Instead, the transport layer should note that the problem occurred, and if the connection fails due to this problem, the message may be passed to the application protocol so that it can inform the user of the failure.
For more information on the Time Exceeded error message, refer to Time Exceeded later in this chapter.
Redirect error messages
The Redirect error message is used whenever a router needs to inform a sender of a shorter path to the specified destination. This message is typically seen when users only have a single (default) route defined on a network with multiple routers, and they should be sending datagrams for a specific network to a router other than the default. If the users don't send the datagrams to the better router, then the default router may use Redirect error messages to inform the sender of the correct router to use.
There are some rules that have to be taken into consideration with this design. First and foremost among them is the fact that Redirect error messages can only be sent when the better router is on the same subnet as the host that is sending the packets. This is pretty obvious; if the specified router were on a remote subnet, then the host would not be able to forward packets through it to the destination system. Furthermore, Redirect error messages should be sent only from a router on the same subnet as the original sender, since other routers on other subnets are not likely to know the routing paths available to the sender.
RFC 1122 even goes so far as to state that systems should discard any redirect messages that do not originate from first-hop routers, or messages with a suggested route that does not point to another first-hop router. In addition, RFC 1122 also states that whenever a system receives a Redirect error message, it must update its routing tables to use the suggested router if it is on the same network as the device itself. This rule is important, since a failure to update the routing table results in the sender continuously transmitting packets through the wrong gateway.
Figure 5-5 shows Ferret (192.168.10.10) trying to send a datagram for 192.168.30.10 to Sasquatch (which is the default router for Ferret). The router examines its local routing table and sees that the best router for the 192.168.30.0 network is via Canary (192.168.10.1), which is also on the same network as the original sender. Since Canary is closer to the final destination network than Sasquatch, Sasquatch issues an ICMP Redirect error message back to Ferret, telling it to use Canary for that traffic.
Note that Sasquatch will go ahead and forward the pending datagram to Canary on Ferret's behalf (as shown in step 3), but after that initial transfer, Ferret should hand all datagrams for the 192.168.30.0 network to Canary directly (as shown in step 4).
Redirect error messages are most commonly seen on networks that rely on the Router Discovery protocol (as described in RFC 1256) for dynamic routing services. Router Discovery makes extensive use of the Redirect error message, and in that environment, these messages do not signify problems with the network.
In order to provide more-detailed reporting, the Redirect message provides four different submessages (using the ICMP Message Code field as described later in Error message headers ). The submessages offered by Redirect include:
Redirect for Destination Network
This message is used when all traffic for the destination network should go through another router. This is the most common form of the Redirect error
 | ||||
| Figure 5-5. A typical scenario for Redirect error messages | ||||
message on local networks that rely on Router Discover for dynamic routing services.
Redirect for Destination Host
This message is used when all traffic for the final destination system should go through another router. Since routing tables can contain host-specific entries (just as they can have network-specific entries), this error is useful if a host-specific redirect is required.
Redirect for Destination Network Based on Type-of-Service
This error message is used when the sending system has requested a particular Type-of-Service for a specific destination, and all traffic with that Type-of-Service for the destination network should go through another router.
Redirect for Destination Host Based on Type-of-Service
This error message is used when the sending system has requested a particular Type-of-Service for a specific system, and all traffic with that Type-of-Service for that destination should be sent through another router.
The Redirect message can be a very useful tool for network administrators, since administrators only have to configure their network devices to use a single router, and that router will provide redirection services to the rest of the devices based on its own routing tables. In fact, this is how the Router Discovery protocol works. As the network topology changes, the routers can inform the other devices about the changes dynamically.
However, even though RFC 1122 states that all IP implementations must support Redirect message, many products do not do so, either failing to update their routing tables or ignoring the Redirect messages entirely. In addition, different implementations support Redirect to different degrees, with some systems taking the redirection message as permanent and modifying their routing tables accordingly, while other systems will only accept the change as a temporary suggestion and will modify their routing tables for only a few minutes. You should verify that your systems fully support the Redirect message to the extent that you require before attempting to implement dynamic routing services across your network using this mechanism.
Note that ICMP Redirect error messages are not sent when a route has been specified using the Source Route IP Option. In that case, the source route takes priority over the optimal path, and the first-hop router specified by the Source Route IP Option must forward the datagram to the next-hop router, regardless of any better paths that may be available.
For more information on the Redirect error message, refer ahead to Redirect .
Source Quench error messages
The Source Quench error message is perhaps the simplest of all the ICMP error messages. Whenever a device is sending too much data for the destination host to process, the recipient can send an ICMP Source Quench error message back to the sender, suggesting that the sender throttle back on the rate at which it is sending data. If the sender does not slow down, then some packets are likely to be discarded by the congested device.
Source Quench is most often seen when a dial-up server connects a high-bandwidth network (such as a LAN) to a low-bandwidth device (such as a dial-up client). In this kind of scenario, it is easy for a high-powered system on the LAN to transmit more data than the dial-up server can feed to the end-point system. Eventually, the dial-up server will fill its transfer buffers and will have to start dropping packets if the sender doesn't slow down. Source Quench allows the dial-up server to inform the sender of the congestion, effectively requesting it to please stop sending so much data.
According to RFC 1122, all Source Quench error messages must be reported to the transport layer that triggered the failure. In addition, RFC 1122 states that if the Source Quench error message is handed to TCP, then TCP should shrink the congestion window for that virtual circuit to one segment and implement the slow start recovery algorithm (as described in Congestion window sizing in Chapter 7, The Transmission Control Protocol).
It is also important to note that RFC 792 states that either the destination system or any router in between the source and destination systems could issue an ICMP Source Quench error message. However, RFC 1812 states that routers should not send Source Quench error messages, claiming they are of questionable benefit. In fact, RFC 1812 even says that routers can choose not to forward Source Quench error messages if they do not want to.
It is my opinion that this is probably a priori call, however, and that Source Quench is an extremely effective tool for controlling intensive traffic flows (particularly those that use UDP, which does not provide for any flow-control services whatsoever). As such, it is my opinion that Source Quench should be used whenever and wherever possible.
For more information on the Source Quench error message, refer to Source Quench later in this chapter.
Parameter Problem error messages
The Parameter Problem error message generally means that something is wrong with the IP datagram itself, and that the datagram is being discarded.
Parameter Problem errors almost always result from an incorrect usage of an IP option. For example, a device may have sent an IP datagram with a malformed Source Route option in the IP header. This datagram would fail to be delivered due to this error, and would get discarded by the recipient (or an intermediary gateway) once the error was detected. Although it might seem that a Destination Unreachable: Source Route Failed error message would be sent in this case, that would not be true since the problem was a malformed option, rather than an undeliverable address.
In order to provide more-detailed reporting, the Parameter Problem message provides three different submessages (using the ICMP Message Code field as described later in Error message headers ). The submessages offered by Parameter Problem include:
Pointer Indicates the Error
This error means that there is a specific problem with the datagram's structure (such as a malformed header field). The location of the bad data is provided in the ICMP Message Data field of the Parameter Problem error message, allowing the sender to determine the cause of the failure.
Required Option Is Missing
This error means that a required IP option has not been defined. This message is used only with the Security options, which are used only by the U.S. military, and are therefore not discussed in this book.
Bad Length
This error indicates that the Header Length and/or Total Packet Length values of the IP datagram do not appear to be accurate.
Note that there is no checksum failure submessage. If a checksum does not calculate correctly, then the entire packet is deemed to be corrupt and is discarded without warning. Any portion of the packet may have been corrupted, including the Destination Address field of the datagram's header. In this case, the recipient may not even be the desired destination system, so it should not do anything other than destroy the packet.
For more information on the Parameter Problem error message, refer to Parameter Problem later in this chapter.
Probing the Network
Since ICMP is a generic messaging protocol, it is also useful for determining general characteristics about the network. ICMP query messages provide this service, allowing systems to request information about the network in general.
ICMP queries are conversational by nature, with one system seeking information from another, and with the remote system returning the requested information. This process can be seen with the ping program's use of Echo Request query messages, which are responded to with Echo Reply query messages. This model is in contrast to the one-way nature of ICMP error messages, which are sent but not responded to.
Echo Request and Echo Reply query messages
One of the simplest tests that a user may wish to perform is verifying that a remote system is up and running on the network. Such a test may be required when basic connectivity appears to be failing.
ICMP provides two query messages that work together to provide just this service. The ICMP Echo Request query message is a probe sent by a user to a destination system, which responds with an ICMP Echo Reply query message.
RFC 1122 states that every host must implement an ICMP Echo server. Since this service is mandatory, any user should be able to send an ICMP Echo Request to any host on the Internet and receive an ICMP Echo Reply message in return. However, this is not always the case, as firewalls may be blocking the packets (for security reasons), or the packets may simply fail to be delivered.
Furthermore, RFC 1122 also states that every host should implement an end-user-accessible application interface for sending Echo Request query messages to other hosts. Typically this application interface is implemented as a program called ping.
Almost every computing environment—even the most basic network print servers and fax gateways—offers some kind of ping program for testing basic connectivity. This is expected, since RFC 1122 mandates that any device with a TCP/IP stack must have one.
ping works by sending one or more ICMP Echo Request messages to a destination system, and then measuring the amount of time it took for the ICMP Echo Reply messages to be received from the system being probed. Some implementations do less than this, only printing a message that the destination system is alive, while others do more than this, allowing the user to specify oversized messages or specific Precedence and Type-of-Service values for the IP datagrams that hold the ICMP Echo Request messages.
Figure 5-6 shows a simple ping between two hosts on a local network. In that example, Ferret sends an ICMP Echo Request query message to Froggy, which responds with an ICMP Echo Reply query message. This is a typical example of how ping is used on any local network.
 | ||||
| Figure 5-6. A typical exchange of Echo Request and Echo Reply query messages | ||||
Although the structure of the Echo Request and Echo Reply messages are described later in detail in Echo Request and Echo Reply, some aspects of the formatting of these messages are important to understanding how the messages can be used for more-detailed testing. For example, Echo Request messages have an ancillary field for storing test data (called the Optional Data field), allowing the sender to provide customized test data inside the ICMP message. Most ping applications use some sort of default data in the test block (such as 64 bytes of 7-bit
US-ASCII text), although many of them will also let you provide your own data in this field, or will at least let you change the quatity of data being sent.
For example, you could choose to have ping send 2,000 bytes of data in the Optional Data field. This Echo Request message could then be used to test the effects of fragmentation when the datagram had to be sent across a network with an MTU that was smaller than that (such as an Ethernet segment).
RFC 1122 states that any data that is received in an ICMP Echo Request must be returned in the resulting Echo Reply message, so if your test data made it to the recipient, you should get all of the data back. However, if the recipient does not support fragmentation (and not every IP device does), then an Echo Reply message would still need to be returned. It would only have to contain as much data as would fit within a single message (according to the MTU restrictions of the target system).
This concept is illustrated in Figure 5-7, which shows a Token-Ring-attached device with an MTU of four kilobytes (192.168.30.10) sending a two-kilobyte Echo Request message to an Ethernet-attached device with an MTU of 1500 bytes (192.168.10.10). In order for the router to forward the message to the Ethernet segment, it must split the IP datagram into two fragments, which will be reassembled by the destination host once both fragments have arrived.
 | ||||
| Figure 5-7. Fragmenting Echo Request and Echo Reply query messages | ||||
Once the message was received, 192.168.10.10 would respond with an ICMP Echo Reply message that was also two kilobytes long (this datagram would have to be fragmented by the sender before it could be sent, since it exceeds the local network's MTU size). The router would then forward both fragments back to 192.168. 30.10, who would reassemble them into a single datagram before the data is processed. This illustrates how it is possible to use oversized datagrams with ping to test fragmentation across a complex network.
Another interesting (but limited) test for ping is for a device to send an ICMP Echo Request query message to all of the devices on the local network, by specifying the broadcast address or the all-hosts multicast address for the local network in the Destination Address field of the IP datagram. However, RFC 1122 explicitly states that devices do not have to respond to these queries, and many implementations will not do so. In addition, not all versions of ping are capable of dealing with multiple responses to a single request, and will report erroneous information when this situation occurs.
In addition, some ping implementations also allow the user to specify the Precedence or Type-of-Service values for the underlying IP datagrams. According to RFC 1122, the remote system is supposed to use those same value in the Echo Reply messages that they return. By specifying non-default values, you can use ping to test how well your network handles classified data as opposed to regular (i.e., nonclassified) data, or how traffic is routed according to nondefault Type-of-Service or Precedence values.
Other IP options and services explicitly supported by ICMP Echo Request and Echo Reply query messages are the Source Route, Record Route, and Timestamp IP Options. For example, RFC 1122 states that if an ICMP Echo Request query message is received within an IP datagram that has the Source Route IP Option defined, then the ICMP Echo Reply query message must follow the same route back to the sender, in reverse order.
For more information on the Echo Request and Echo Reply query messages, refer ahead to Echo Request and Echo Reply.
Timestamp Request and Timestamp Reply query messages
Another pair of ICMP query messages that can be useful for testing the network is the Timestamp Request and Timestamp Reply query messages, which allow a sender to determine the amount of latency that a particular network is experiencing. This gives good insight into the performance characteristics of the network.
As can be imagined, this information also provides more insight than most people want to provide, at least to users outside the local network. For this reason, RFC 1122 states that the Timestamp Request and Timestamp Reply query messages are entirely optional. Indeed, there are only a few TCP/IP implementations that support them.
Timestamp works by having one system send a Timestamp Request query message to another host, with the current time in the Timestamp Request message's Originate Timestamp field. The recipient then creates a Timestamp Reply query message that contains the Originate Timestamp field from the original message, along with new Receive Timestamp and Transmit Timestamp fields.
Once the Timestamp Reply query message is received by the querying device, the different timestamps can be examined, allowing the system to determine the amount of time that it took for the remote system to process the Timestamp Request query message. This data can then be subtracted from the round-trip delivery time, allowing the system to calculate the length of time that it took for the datagrams to travel across the network. This provides a better indication of actual network latency than the Echo Request and Echo Reply query messages, which do not provide any information about the amount of time that the remote system spent processing the ICMP messages.
Note that the timestamps used in the Timestamp Request and Timestamp Reply query messages are based on the number of milliseconds since midnight, using Universal Time (UTC). By using UTC, network devices do not have to worry about timezone issues, since all devices are on the same timezone (UTC).
The ICMP Timestamp Request and Timestamp Reply messages can also be set to use specific Type-of-Service and Precedence values, allowing latency to be measured across specific networks. In addition, RFC 1122 states that if an ICMP Timestamp Request query message is received within an IP datagram that has the Source Route IP Option defined, then the ICMP Timestamp Reply query message must follow the same route back to the sender, in reverse order. This sequence allows a user to measure latency across a specific network path.
Also note that accurate measurements of network latency depend upon each system having accurate (or consistent) time values for their local clocks. Before relying on the Timestamp query messages for latency measurements, synchronize the clocks on the systems being tested using a protocol such as NTP.
For more information on the Timestamp Request and Timestamp Reply query messages, refer ahead to Timestamp Request and Timestamp Reply.
Address Mask Request and Address Mask Reply query messages
RFC 792 defined a variety of host-configuration messages, allowing diskless systems to obtain IP addresses and other data during the boot process by using ICMP messages. However, the primary ICMP query messages used for this—the Information Request and Information Reply query messages—have since been deprecated and are now obsolete. The Address Mask Request and Address Mask Reply query messages are also somewhat obsolete, although their usage has not been deprecated as of yet.
Essentially, the Address Mask Request and Address Mask Reply query messages allow a host to determine the subnet mask in use on the local network. Once a host has obtained an IP address (which could be obtained via Reverse ARP, BOOTP, or DHCP), they could then send an Address Mask Request message to the local broadcast address of 255.255.255.255. An Address Mask server on the network would then respond with an Address Mask Reply query message that is unicast back to the requesting device directly, providing the host with a subnet mask for the IP address being used.
RFC 1122 states that the Address Mask Request and Address Mask Reply query messages are entirely optional. Indeed, only a handful of systems use these messages today.
For more information on the Address Request and Address Reply query messages, refer to Address Mask Request and Address Mask Reply later in this chapter.
Router Solicitation and Router Advertisement query messages.
RFC 1256 introduced the concept of a Router Discovery protocol that allows the devices on a network to locate routers using ICMP query messages, rather than having to be configured to use static routing entries or run a full-fledged routing protocol like RIP or OSPF.
The Router Discovery protocol consists of a Router Solicitation query message, which is issued by hosts when they first become active on the network (sent to the all-routers multicast address of 224.0.0.2). Each router on the network should then respond to the Router Solicitation query messages with a unicast Router Advertisement query message, informing the querying device directly of the IP addresses that can be used for packet forwarding. In addition, routers will also issue unsolicited Router Advertisement messages on a periodic basis (sent to the all-hosts multicast address of 224.0.0.1), allowing hosts both to change their routing tables as higher-priority routers become available, and to expire old routers if they are no longer being advertised after a certain length of time.
According to RFC 1256, unsolicited Router Advertisement query messages should be sent to the all-hosts multicast address of 224.0.0.1 through every network interface in use by the router, although directed Router Advertisements that result from Router Solicitations are only unicast back to the requesting device, through the most appropriate interface. Each of these advertisement messages must contain the IP address in use on the local interface, as well as a Preference value for the IP address being published. Network devices then use the IP address with the highest Preference (the lowest number) as their default router.
This process is illustrated in Figure 5-8. In that example, Ferret issues an ICMP Router Solicitation query message to the all-routers multicast group address of 224. 0.0.2, which both Sasquatch and Canary respond to (using the ICMP Router Advertisement query message, also sent to the all-routers multicast address of 224.0.0.2). Each response also contains a Preference value for that specific router, with Sasquatch having the highest preference (this router will become the default router for Ferret).
 | ||||
| Figure 5-8. Router Discovery using Router Solicitation and Advertisement query messages | ||||
Note that routers do not advertise the networks or paths that they can route for. Devices must discover (and build) their own routing tables dynamically, by way of the ICMP Redirect error message discussed earlier in Redirect error messages. In that model, the Router Discovery client uses the Router Solicitation query message to choose a default route, and then relies on the Redirect error messages whenever the host tries to send a datagram to the default router for delivery, but the router knows of a better path for the specified destination system.
This concept is illustrated in Figure 5-9. As we saw in Figure 5-8, Sasquatch had the strongest preference, and was chosen as the default router by Ferret. If the host wants to send a datagram to 192.168.30.10 (a non-local device), it would send the packets to Sasquatch for delivery. However, Sasquatch would know that Canary was the better router for that destination, so it would return an ICMP Redirect error message back to Ferret, informing it that all traffic for the 192.168.30.0
network should go to Canary. Sasquatch would then forward on the packets it had already received, while Ferret would make note of the new path, and (hopefully) start to use that router for any future datagrams for that destination network.
 | ||||
| Figure 5-9. Router Discovery using Redirect error messages | ||||
On small or isolated networks that have only one or two routers on any given segment, the process of learning about the entire network will only take a few moments and is not nearly as complicated as it sounds here. Conversely, on large and complex networks with many different routers, this process can be significantly more complicated than it sounds here.
For more information on the Router Solicitation and Router Advertisement query messages, refer to Router Solicitation and Router Advertisement, both later in this chapter.
ICMP Messages
ICMP is used for two different types of operations: reporting on problems that prevent delivery (such as Destination Unreachable errors), and probing the network through the use of request and reply messages (such as those found in the ping program's Echo Request and Echo Reply ICMP messages).
Every ICMP message is assigned a unique message type, which is simply a numeric code that represents each of the predefined messages. There are a variety of predefined message types that devices can choose from when they need to send a message to another device. Many of these messages were defined in RFC 792, while others were added in RFC 950, RFC 1122, RFC 1812, and RFC 1256. In addition, some messages have been rendered obsolete (such as the Information Request and Information Reply query messages), and are no longer considered part of the standard dictionary of message types.
For a detailed listing of all of the ICMP Message Types that are currently registered, refer to the Internet Assigned Numbers Authority's (IANA) online registry (accessible at http://www.isi.edu/in-notes/iana/assignments/icmp-parameters). Note that RFC 1122 states that if a system receives an ICMP message with a type or code that it does not understand, it must ignore the message.
Table 5-1 lists the Message Types most often used with IPv4.
| ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Since these messages are used for specific types of functionality, they vary widely in their structure and formatting, with some messages having more fields than others. Refer to Error message headers for information on the structure of ICMP error messages, and Query message headers, both later in this chapter, for information on the structure of ICMP query messages.
ICMP Error Messages
ICMP error messages are used whenever a nontransient delivery problem occurs
that the sender should be made aware of. A variety of ICMP error messages
exist (as described later in Error message types and codes ),
although each of these
messages have their own special requirements and treatments. However, all ICMP error messages have the same basic structure, and these fields are described in the next section.
Error message headers
ICMP error messages consist of a predefined set of fields that indicate the type of message being passed, and that also provide message-specific services (such as IP addresses or pointers to corrupt data). These predefined fields are followed by the IP header and the first eight bytes of data from the datagram that caused the error to be generated.
Since delivery problems can occur at any layer, ICMP error messages must include the full header and the first eight bytes of data from the failing IP datagram in order for the sender to see which packet failed, and in order for the sender to notify the transport and application protocols that generated the failure. This process allows the sender to pass the error message to the appropriate layer for subsequent processing.
Table 5-2 lists all of the fields in an ICMP error message's header, along with their size (in bytes), and some usage notes. For more information on these fields, refer to the individual discussions throughout this section.
| ||||||||||||||||||||||||
The total length of an ICMP error message is eight bytes. However, this measurement does not include the original datagram's IP headers, which can add anywhere from 20 to 60 bytes of additional data to the message, not does it include the first eight bytes of data from the failing packet. All told, an ICMP error message can be anywhere from 36 to 72 bytes, including all of these fields.
All ICMP messages are sent within IP datagrams directly. Each of these datagrams must have a protocol identifier of 1. Also, RFC 1122 (Host Network Requirements)
states that ICMP error messages sent from hosts should use the default Type-of-Service and Precedence values (0), although RFC 1812 (Router Requirements) states that error messages sent from routers should have a precedence value of 6 or 7.
The remainder of this section discusses the ICMP error messages in detail, using the capture shown in Figure 5-10 for reference purposes.
 | ||||
| Figure 5-10. A simple ICMP error message | ||||
Message Type
The Type field is used to specify the exact ICMP error message being sent.
Size
Eight bits.
Notes
ICMP essentially consists of a predefined dictionary of messages, allowing messages to be exchanged using numeric identifiers. The Type field is used to specify the major class of the message, while the Code field is used to specify the minor class, though some message Types do not have any subtype Codes.
Table 5-3 lists all of the ICMP error message Types used with IPv4, and their meanings.
| |||||||||||||||||||||
Capture Sample
In the capture shown in Figure 5-11, the Type field is set to 3, which is used for all Destination Unreachable errors.
 | ||||
| Figure 5-11. The Message Type field | ||||
See Also
Message Code
Message Code
The Code field is used to specify a specific subtype of the ICMP error message, which was specified in the Type field.
Size
Eight bits.
Notes
ICMP essentially consists of a predefined dictionary of messages, allowing messages to be exchanged using numeric identifiers. The Type field is used to specify the major class of the message, while the Code field is used to specify the minor class, although some message Types do not have any subtype Codes.
The values used in this field vary according to the Message Type for the current error message.
Capture Sample
In the capture shown in Figure 5-12, the Code field is set to 3, which is the value associated with the subtype of Port Unreachable when used with Type 3 (Destination Unreachable) error messages.
 | ||||
| Figure 5-12. The Message Code field | ||||
See Also
Message Type
Checksum
Used to store a checksum of the ICMP message, allowing destination systems to validate the contents of the message and test for possible corruption.
Size
Sixteen bits.
Notes
The checksum field provides a simple validation scheme for ICMP messages. When calculating the checksum, the sending system looks at the entire message (with the checksum field set to 0) and performs a simple checksum operation. This procedure is reversed by all recipients before the contents of the message are processed.
Capture Sample
In the capture shown in Figure 5-13, the Checksum has been calculated to be hexadecimal 81 97 , which is correct.
 | ||||
| Figure 5-13. The Checksum field | ||||
Message Data
Used to provide additional information about the cause of certain ICMP error messages
Size
Thirty-two bits.
Notes
This field is used differently by each of the ICMP error messages (and is even used differently by some message types). For example, the ICMP Redirect error message uses this field to provide the IP address of a preferred router, while the Destination Unreachable: Fragmentation Required but DF Bit Is Set
error message will use this field to provide the Next-Hop MTU (if Path MTU Discovery is supported by the router reporting the error). Most of the ICMP error messages do not use this field.
Capture Sample
In the capture shown in Figure 5-14, the Message Data field is filled with zeroes, indicating that the field is unused.
 | ||||
| Figure 5-14. The Message Data field | ||||
See Also
Destination Unreachable
Redirect
Parameter Problem
Original Headers
In order for ICMP to determine which datagram failed, it must be given information about that datagram. For this reason, the original headers from the failing IP datagram are always included with the ICMP error message.
Size
20 to 60 bytes, depending on the length of the original datagram's IP header.
Notes
IP is a datagram-centric protocol, and not a circuit-centric protocol. As such, it cannot keep track of failed datagrams by referencing a sequence number or some other counter like TCP can. Instead, in order for IP to know when a datagram failed, the headers from the failing datagram must be returned to the sender, allowing it to parse through the information and locate the transport protocol that caused the problem.
This feature is especially important when a host sends many different datagrams to another specific destination. If the host sends hundreds of datagrams and then gets an ICMP error message, which datagram does the failure apply to? The only way to authoritatively answer this question is to examine the failing datagram explicitly.
Typically, this information is used in conjunction with the Original Data field, which allows a transport protocol to determine the application that generated the failing datagram.
Capture Sample
In the capture shown in Figure 5-15, the original headers indicate that the failing datagram was a UDP message sent from Greywolf to Arachnid. The Message Type and Code fields (shown previously) indicate that the datagram was undeliverable because the destination port number for the UDP message was unreachable.
 | ||||
| Figure 5-15. The IP headers from the failing IP datagram | ||||
See Also
Message Type
Message Code
Original Data
Original Data.
Just as ICMP needs to know which IP datagram failed in order to inform the appropriate transport protocol of the problem, the transport protocols also need to know which application sent the failing datagram before they can notify the application of the failure. For this reason, the first eight bytes of data from the failing IP datagram are always included with the ICMP error message, since these bytes contain the source and destination port number fields used by UDP and TCP (or the Message Type and Code fields from ICMP query messages).
Size
Sixty-four bits.
Notes
In order for the transport protocols to know which application generated the failing datagram, they have to be able to examine data that is outside of the original IP headers. All of the upper-layer protocols in use with IP—including TCP, UDP, and ICMP itself—place the source and destination application information in the first eight bytes of the datagram's data segment. As long as the transport protocols have access to that data, they can locate the offending application.
This information is used in conjunction with the Original Headers field, which allows ICMP to determine the higher-layer protocol that sent the failing datagram.
Capture Sample
In Figure 5-15, we saw that the failing datagram originated from UDP. Since UDP uses the first two bytes of the UDP header to indicate the source port, we can tell from the capture shown in Figure 5-16 that the application that sent the failing datagram was using port 1051 on Greywolf (shown as hexadecimal 04 58 ). Furthermore, since UDP uses the next two bytes for the destination port number, we can tell that the packet was destined for port 69 (the well-known port number associated with the Trivial File Transfer Protocol) on Arachnid (shown as hexadecimal 00 45 ).
Therefore, we can tell that this packet failed to be delivered due to there not being a TFTP server running on port 69 on Arachnid. This information should be reported to the application that is using UDP port 1051.
 | ||||
| Figure 5-16. The first eight bytes of data from the failing datagram | ||||
See Also
Message Type
Message Code
Original Headers
Error message types and codes
The remainder of this section discusses the different ICMP error messages, as listed earlier in Table 5-3.
Destination Unreachable
Destination Unreachable means that the destination network, host, or port number specified in the IP datagram was unreachable. This could be a result of a variety of factors, ranging from a router being unable to find a path to the remote system, to the network refusing to accept connections from this particular sender, among many other factors.
ICMP Message Type
The Message Type for Destination Unreachable is 3.
ICMP Message Codes
Destination Unreachable makes extensive use of the Code field. RFC 792 defined six different possible failure codes, numbered 0 through 5. This list was supplemented by RFC 1122, which added seven additional codes (6 through 12). Finally, RFC 1812 added three more codes (13 through 15), but also declared codes 8 through 10 as either obsolete or inappropriate for nonmilitary usage (for this reason, they are not documented in this book). Table 5-4 lists the Codes currently used by Destination Unreachable
| ||||||||||||||||||||||||||||||||||||
ICMP Message Data
The ICMP Message Data field is unused with Destination Unreachable error messages (except when Path MTU Discovery is being used), and must be empty. When Path MTU Discovery is being used, the Message Data field is split into two subfields of two bytes each, as shown in Table 5-5.
| ||||||||||||
If a router supports Path MTU Discovery and was unable to forward a datagram due to size issues, then it would reject the datagram using the Destination Unreachable: Fragmentation Required but DF Bit Is Set error message, and also inform the original sender of the next-hop network's MTU size using the Next-Hop MTU subfield.
Defined In
RFC 792, RFC 1122, RFC 1191, and RFC 1812.
Notes
A Destination Unreachable error message can signify any number of problems, and as such is fairly complex. Refer to Destination Unreachable error messages earlier in this chapter for a comprehensive discussion of this error message.
Capture Sample
The packet capture shown in Figure 5-17 shows a Destination Unreachable: Port Unreachable error message being sent to Greywolf from Arachnid. By looking at the failing packet's headers and first eight bytes of data, we can tell that Greywolf had tried to send a UDP message to port 69 on Arachnid, which does not appear to have a listener on that port.
See Also
Destination Unreachable error messages
Notes on Path MTU Discovery
Source Quench
Source Quench error messages are used when data is arriving too fast to be processed by an intermediate router or by the final destination system, informing the sender that a bottleneck has occurred and that it should slow down the rate of transfer.
ICMP Message Type
The Message Type for Source Quench is 4.
ICMP Message Codes
Source Quench does not use any Codes, and this field must be zero.
ICMP Message Data
The ICMP Message Data field is unused with Source Quench, and must be zero.
Defined In
RFC 792.
Notes
Source Quench is most often used when a router connects a high-bandwidth network (such as a LAN) to a low-bandwidth network or device (such as a
 | ||||
| Figure 5-17. An ICMP Destination Unreachable: Port Unreachable error message | ||||
dial-up server). In such a scenario, it is easy for a sender to transmit more data than the dial-up server can feed to the end-point system. Eventually, the dial-up server will fill its transfer buffers and will have to start dropping packets if the sender doesn't slow down the rate at which it sends data. Source Quench allows the router (or the destination system) to inform the sending device that the network is congested, and to please stop sending so much data.
RFC 1812 stated that the Source Quench error message had not proven to be of much use in preventing congestion from occurring and that routers were therefore not required to send (or relay) these messages in case congestion did occur. While this is particularly true with TCP-based applications that can rely on TCP's sliding window for flow control services, it is not true for UDP-based applications that could otherwise flood a network. Furthermore, no other protocol or service has yet been standardized that offers similar services, and as such the Source Quench error message still serves an important service in some instances.
Capture Sample
The packet capture shown in Figure 5-18 shows a Source Quench error message being sent from Sasquatch to Ferret. By studying the headers from the original IP packet (as provided in the ICMP message), we can see that the failing packet was a UDP datagram sent from Ferret to Dial-Client, a remote dial-up user. This would indicate that Sasquatch (the dial-up router) was unable to send all of the data it had queued for Dial-Client, and that Ferret needs to slow down the rate of transfer. Ferret should react to this message by momentarily pausing the data transmission.
 | ||||
| Figure 5-18. An ICMP Source Quench error message | ||||
See Also
Source Quench error messages
Redirect
The Redirect error message is used when a router needs to tell a host that a different router should be used for a particular destination.
ICMP Message Type
The Message Type for Redirect is 5.
ICMP Message Codes
Redirect uses four different Codes, each of which indicate different types of redirection. Table 5-6 lists the codes used and their meanings.
| ||||||||||||
ICMP Message Data
The ICMP Message Data field is used to specify the alternate router and must contain the 32-bit IP address of that router.
Defined In
RFC 792.
Notes
The Redirect error message is fairly complicated. Refer back to Redirect error messages for a comprehensive discussion of this error message.
Capture Sample
In the capture sample shown in Figure 5-19, Sasquatch has sent a Redirect for Destination Host error message to Ferret. Notice that according to the IP header embedded in the ICMP datagram, Ferret was trying to open a connection to www.ora.com (O'Reilly & Associates' web site), and that it sent the initial segment to Sasquatch for forwarding. However, Sasquatch knows that Canary (192.168.10.1) offers a better route for that destination, so it returns the Network Redirect message back to Ferret, informing Ferret to use Canary for that destination network. From this point on, Ferret should use Canary as the default route for that destination.
See Also
Redirect error messages
 | ||||
| Figure 5-19. An ICMP Redirect for Destination Host error message | ||||
Time Exceeded
Time Exceeded messages can be sent when the IP datagram's Time-to-Live value has reached zero but the datagram has not yet been delivered to the final destination. They can also be sent when all of the fragments from an IP datagram have not been received within the allotted time.
ICMP Message Type
The Message Type for Time Exceeded is 11.
ICMP Message Codes
Time Exceeded error messages have two possible Codes, shown in Table 5-7.
| ||||||||
ICMP Message Data
The ICMP Message Data field is unused with Time Exceeded and must be zero.
Defined In
RFC 792.
Notes
The Time Exceeded error message is fairly complicated. Refer back to Time Exceeded error messages for a comprehensive discussion of this error message.
Capture Sample
In the capture shown in Figure 5-20, a datagram sent from Greywolf to Sasquatch (as seen in the original datagram's IP header) had a very small Time-To-Live value (1 hop). Sasquatch was unable to forward the packet without the Time-To-Live reaching zero, so the packet was destroyed, and a Time Exceeded: Time-to-Live Exceeded In Transit error message was returned to Greywolf.
See Also
Time Exceeded error messages
Time-to-Live in Chapter 2, The Internet Protocol
Notes on traceroute
Parameter Problem
RFC 1122 states that the Parameter Problem error message should be used only if no other ICMP error message is appropriate for the particular problem that arose.
ICMP Message Type
The Message Type for Parameter Problem is 12.
ICMP Message Codes
Parameter Problem has three possible Codes, as shown in Table 5-8.
| ||||||||||
 | ||||
| Figure 5-20. An ICMP Time Exceeded: Time-to-Live Exceeded In Transit error message | ||||
ICMP Message Data
The ICMP Message Data field is used differently by each of the different Parameter Problem Codes. Table 5-9 shows how the ICMP Message Data field is used for each of the different Codes.
| ||||||||||
Defined In
RFC 792 and RFC 1122.
Notes
The Parameter Problem error message is fairly complicated. Refer back to Parameter Problem error messages for a comprehensive discussion of this error message.
See Also
Parameter Problem error messages
ICMP Query Messages
ICMP query messages are used to probe the network for specific characteristics (such as host availability and network latency) and are also used for some general purpose lookup services (such as locating routers). A variety of ICMP query messages exist (as described late in Query message types andcodes ), although each of these message shave their own special requirements and treatments. However, all ICMP query messages share some fields, and these fields are described in the next section.
Query message headers
Since ICMP query messages are used for specific types of functionality, they vary widely in their formatting. However, each of them share the same first three header fields, as shown in Table 5-10, along with their size (in bytes) and some usage notes. Beyond these common fields however, each of the ICMP query messages differs widely in their formatting and structure. For more information on these fields, refer to the individual discussions throughout this section.
| ||||||||||||||||||
The total length of a normal ICMP query message is eight bytes. However, this does not include any additional data that may be provided by an ICMP query message's additional fields, which can add a substantial amount of data to a datagram (Echo Request messages can be as large as 64 kilobytes).
All ICMP messages are sent within IP datagrams directly. Each of these datagrams must have a protocol identifier of 1. In addition, RFC 1122 states that ICMP error messages should use the default Type-of-Service and Precedence values when they are sent over IP. However, if a user wishes to set these values to higher levels, then the responses must use the same values they received in the queries.
The following sections discuss ICMP query messages in detail, using the capture shown in Figure 5-21 for reference purposes.
 | ||||
| Figure 5-21. A simple ICMP query message | ||||
Message Type.
The Type field is used to specify the exact ICMP query message being sent.
Size
Eight bits.
Notes
ICMP essentially consists of a predefined dictionary of messages, allowing messages to be exchanged using numeric identifiers. The Type field is used to specify the major class of the message, while the Code field is used to specify the minor class, although some message Types do not have any subtype Codes.
Table 5-11 lists all of the ICMP query message Types used with IPv4 and their meanings.
| ||||||||||||||||||||||||||||||
Capture Sample
In the capture shown in Figure 5-22, the Type field is set to 8, which is used for Echo Request query messages.
 | ||||
| Figure 5-22: The Message Type field | ||||
See Also
Message Code
Message Code
The Code field is used to specify a specify subtype of the ICMP query message, which was specified in the Type field.
Size
Eight bits.
Notes
ICMP essentially consists of a predefined dictionary of messages, allowing messages to be exchanged using numeric identifiers. The Type field is used to specify the major class of the message, while the Code field is used to specify the minor class, although some message types do not have any subtype Codes.
The values used in this field vary according to the Message Type for the current error message.
Capture Sample
In the capture shown in Figure 5-23, the Code field is set to 0, which is the default for Echo Reply query messages, since those messages do not use the Code field.
 | ||||
| Figure 5-23. The Message Code field | ||||
See Also
Message Type
Checksum
Used to store a checksum of the ICMP message, allowing destination systems to validate the contents of the message and test for possible corruption.
Size
Sixteen bits.
Notes
The checksum field provides a simple validation scheme for ICMP messages. When calculating the checksum, the sending system looks at the entire message (with the checksum field set to 0) and performs a simple checksum operation. This procedure is reversed by all recipients before the contents of the message are processed.
Capture Sample
In the capture shown in Figure 5-24, the Checksum has been calculated to hexadecimal 89 07 , which is correct.
 | ||||
| Figure 5-24. The Checksum field | ||||
Additional Fields
Each ICMP query message has distinct functionality, and as such has unique fields that are associated with that specific message. The fields that appear from this point on in the message will be unique to the specific Message Type being sent.
Size
Varies according to Message Type.
Notes
Since ICMP query messages are conversational in nature, they provide very specific sets of functionality that are not shared by all other query messages. For example, the functionality provided by Echo Request and Echo Reply messages is nothing at all like the functionality offered by Router Solicitation and Router Advertisement messages. As such, the fields they use for their specific purposes vary considerably.
Capture Sample
The capture shown in Figure 5-25 shows that the Echo Request query message defines several additional fields, including Identifier, Sequence Number, and Optional Data fields. Note that these fields only appear in ICMP Echo Request and Echo Reply query messages. The optional data is the 56 bytes of data following the sequence number.
 | ||||
| Figure 5-25. The additional fields used with Echo Request query messages | ||||
See Also
Message Type
Message Code
Query message types and codes
The remainder of this section discusses the different ICMP query messages, as listed earlier in Table 5-11.
Echo Request and Echo Reply
Echo Request and Echo Reply query messages provide the ability for one system to see if another system is on the network and functional. Any Echo Request message received by a system must be responded to with an Echo Reply query message.
ICMP Message Type
The Message Type for Echo Request is 8. The Message Type for Echo Reply is 0.
ICMP Message Codes
Neither the Echo Request nor Echo Reply query messages uses any Codes, and this field must be zero. However, some vendors (such as Cisco) use some message codes for specific services. If you see a non-zero value in this field, check the documentation for the sending system to determine what purpose it serves.
Defined In
RFC 792.
Additional Fields
Both the Echo Request and Echo Reply query messages use four additional fields. Table 5-12 lists these fields, their size (in bytes), and their usage.
| |||||||||||||||
These fields are explained below, but if you are familiar with the ping program, then you're probably already aware of the functions they provide.
The Identifier field provides a kind of session identification number to the set of Echo Request and Echo Reply messages being passed. For example, if Ferret were to send multiple Echo Request query messages to Greywolf as part of a single test, then each of the Echo Request (and each of the Echo Reply) messages would all share the same Identifier. This allows Ferret to also send Echo Request messages to another host simultaneously, while keeping all of the ICMP messages separate.
The Sequence Number field allows the hosts to keep track of the unique Echo Request and Echo Reply messages that are associated with a single Identifier. For example, if Ferret were to send multiple Echo Request queries to Greywolf as part of a single test, then each message would have a unique Sequence Number (although the Identifier would remain consistent). The Echo Reply messages sent back to Ferret from Greywolf would show the Sequence Number that they applied to.
The Optional Data field is used to store test data. The Echo Request query message does not need to place any data in the Optional Data field (which is why it is optional ), but it may place any data here that the user wishes. Any Optional Data received by the final destination must be returned in the Echo Reply query message.
Notes
Echo Request messages are generally issued by a user running the ping program (although some network management applications use the Echo Request query message to automate testing). Echo Reply messages are sent only in response to an Echo Request query message. For more information on the ping program, refer ahead in this chapter to Notes on ping.
Capture Sample
In the capture shown in Figure 5-26, Greywolf has sent an Echo Request query message to Krill, to which Krill responds with an Echo Reply query message. Note that both messages contain the same Identifier, Sequence Number, and Optional Data fields.
See Also
Echo Request and Echo Reply query messages
Notes on ping
Timestamp Request and Timestamp Reply
The ICMP Timestamp Request and Timestamp Reply query messages provide the ability to determine the length of time that ICMP query messages spend in transit, which is extremely useful for measuring the latency across a specific network.
ICMP Message Type
The Message Type for Timestamp Request is 13. The Message Type for Timestamp Reply is 14.
ICMP Message Codes
Neither the Timestamp Request nor Timestamp Reply query messages use any Codes, and this field must be zero.
Defined In
RFC 792.
Additional Fields
Both the Timestamp Request and Timestamp Reply query messages use the same message structure. The additional fields used by these messages are shown in Table 5-13.
 | ||||
| Figure 5-26. A pair of Echo Request and Echo Reply query messages | ||||
| |||||||||||||||
| ||||||||||||
These fields are explained below:
The Identifier field provides a kind of session identification number for the Timestamp Request and Timestamp Reply query messages being passed between various hosts. For example, if Ferret sends multiple Timestamp Request queries to Greywolf as part of a single test, then each of the Timestamp Request (and each of the Timestamp Reply) queries would all share the same Identifier. This feature allows Ferret to send Timestamp Request messages to another host simultaneously, while keeping all of the ICMP traffic separate locally.
The Sequence Number field allows the hosts to keep track of the unique Timestamp Request and Timestamp Reply messages that are sent for a single Identifier. For example, if Ferret sends multiple Timestamp Request queries to Greywolf as part of a single test, then each message would have a unique Sequence Number (although the Identifier would remain consistent). The Timestamp Reply messages sent back to Ferret from Greywolf would show the Sequence Number that they applied to.
The Originate Timestamp field stores the exact time in milliseconds that the Timestamp Request query message was sent.
The Receive Timestamp field stores the exact time in milliseconds that the Timestamp Request query message was received by the final destination system. This provides a latency measure.
The Transmit Timestamp field is used to store the exact time in milliseconds that The Timestamp Reply query message was sent in response to the Timestamp Request query.
Notes
When the system that sent the Timestamp Request query message receives the Timestamp Response query message, it can examine the data stored in the Receive Timestamp and Transmit Timestamp fields, and thereby determine the amount of time used by the remote system to process the ICMP query message. This value can then be subtracted from the round-trip delivery times for the ICMP query messages, providing insight into the latency of the network (as it applies to those messages, anyway).
Timestamp data is based on the number of milliseconds since midnight, using the Universal Time Zone (UTC).
Note that using the Timestamp Request and Timestamp Reply query messages to determine the latency between two devices requires that the devices have identical system times. You must synchronize the clocks on the test systems using a protocol such as NTP before accurate measurements can be obtained.
See Also
Timestamp Request and Timestamp Reply query messages
Address Mask Request and Address Mask Reply
The ICMP Address Mask Request and Address Mask Reply query messages provide a host with the ability to determine the subnet mask in use on the local network. This is achieved by sending an Address Mask Request query message to the local broadcast address of 255.255.255.255, which is then responded to with an Address Mask Reply message.
ICMP Message Type
The Message Type for Address Mask Request is 17. The Message Type for Address Mask Reply is 18.
ICMP Message Codes
Neither the Address Mask Request nor Address Mask Reply query messages use any Codes, and this field must be zero.
Defined In
RFC 950.
Additional Fields
Both the Address Mask Request and Address Mask Reply query messages use the same message structure. The additional fields used by these messages are shown in Table 5-14.
| |||||||||||||||
These fields are explained below:
The Identifier field provides a kind of session identification number for the Address Mask Request and Address Mask Reply query messages being passed between various hosts. For example, if Ferret issues multiple Address Mask Request queries as part of a single operation, then each of the Address Mask Request (and each of the Address Mask Reply) queries would share the same Identifier. This feature allows Ferret to send multiple Address Mask Request messages simultaneously, while keeping all of the ICMP traffic separate locally.
The Sequence Number field allows the hosts to keep track of the unique Address Mask Request and Address Mask Reply messages that are sent for a single Identifier. For example, if Ferret sends multiple Address Mask Request queries as part of a single operation, then each message would have a unique Sequence Number (although the Identifier would remain consistent). The Address Mask Reply messages sent back to Ferret would show the Sequence Number that they were responding to.
The Subnet Mask field is used to store the subnet mask in use on the local network. This field is unused with Address Mask Requests and must be zero, and is only filled in for Address Mask Reply messages.
Notes
The Address Mask Request and Address Mask Reply query messages were originally provided as ancillary messages for the Information Request and Information Reply query messages, which provided a mechanism for diskless workstations to obtain an IP address during startup. However, the Information Request and Information Reply messages have since been deprecated and are now obsolete. The Address Mask Request and Address Mask Reply query messages are also obsolete, although they have not yet been deprecated. They are quite rare, however.
See Also
Address Mask Request and Address Mask Reply query messages
Router Solicitation
When a device that supports the Router Discovery protocol first comes onto the network, it issues a Router Solicitation query message. Routers on the network can then respond with the Router Advertisement query message, informing the device of the available routers.
ICMP Message Type
The Message Type for Router Solicitation is 10.
ICMP Message Codes
Router Solicitation does not use any Codes, and this field must be zero.
Defined In
RFC 1256.
Additional Fields
Router Solicitation query messages have a single four-byte field, which is currently unused, and which must be zero.
Notes
The Router Advertisement and Router Solicitation query messages are both part of the Router Discovery Protocol. However, the Router Advertisement query messages are substantially different from the Router Solicitation query messages. Both messages need to be understood before a complete understanding of the Router Discovery protocol can be reached.
The Router Discovery protocol offers a dynamic-routing service to devices on a network, by way of a handful of ICMP query messages and error messages. When a device first comes onto the network, it will issue an ICMP Router Solicitation query message to the all-routers multicast address of 224.0.0.2 (or to the broadcast address of 255.255.255.255). Any routers that are active on the local network should then respond with unicast Router Advertisement query messages (as described in Router Advertisement, the next section). In addition, routers will also issue Router Advertisement query messages to the all-hosts multicast address of 224.0.0.1 on a periodic basis, allowing devices to update their list of known routers.
Once a device has chosen a default router, then all traffic will go to that router. If another router exists on the local network that is more appropriate for a specific destination, then the default router should issue an ICMP Redirect error message to the device, informing it of the alternative router. This allows the network devices to build maps of the network dynamically
Capture Sample
In the capture shown in Figure 5-27, Fungi has sent a Router Discovery query message to the all-routers multicast address of 224.0.0.2. The response to this query is shown later in Figure 5-28.
See Also
Router Solicitation and Router Advertisement query messages
Router Advertisement
Router Advertisement.
When a device that supports the Router Discovery protocol first comes onto the network, it issues a Router Solicitation query message. Routers on the network can then respond with the Router Advertisement query message, informing the device of the available routers.
In addition, routers will send Router Advertisement query messages every seven to ten minutes, allowing the local devices to refresh their lists of available routers.
 | ||||
| Figure 5-27. An ICMP Router Solicitation query message | ||||
ICMP Message Type
The Message Type for Router Advertisement is 9.
ICMP Message Codes
Router Advertisement does not use any Codes, and this field must be zero.
Defined In
RFC 1256.
Additional Fields
The Router Advertisement query message uses several additional fields. Table 5-15 lists these fields, their size (in bytes), and their usage.
| |||||||||||||||||||||
These fields are used as follows:
The Number of Addresses field indicates the number of IP address entries in use on this interface. Since the Router Advertisement messages are sent out on each unique interface—some of which may have multiple IP addresses—this field indicates the number of IP addresses in use on this particular interface.
The Address Size field is used to indicate the size of each IP address, as well as the size of the Preference value being provided for each IP address. The use of Preference values allows the router to dictate how much weight devices should give to each IP address.
The Lifetime field provides a Time-to-Live metric for this Router Advertisement message. Since routers may come and go, devices will need to expire routing table entries from time to time. The Lifetime field is used to tell the devices how long they should keep the information being provided, before it is expired. Note that this field should be set to a value that is higher than the frequency of unsolicited Router Advertisements, allowing the unsolicited messages to renew the network devices' routing table entries before the Lifetime expires.
The Address Entry N field is used to provide the Nth IP address. This field will be repeated N number of times, as dictated by the Number of Addresses field above.
The Preference for N field is used to provide the Preference value for Address Entry N. This field will be repeated N number of times, as dictated by the Number of Addresses field above.
Notes
The Router Advertisement and Router Solicitation query messages are both part of the Router Discovery Protocol. However, the Router Advertisement query messages are substantially different from the Router Solicitation query messages. Both messages need to be understood before a complete understanding of the Router Discovery protocol can be reached.
The Router Discovery protocol offers a dynamic-routing service to devices on a network, by way of a handful of ICMP query messages and error messages. When a device first comes onto the network, it will issue an ICMP Router Solicitation query message to the all-routers multicast address of 224.0.0.2 (or to the broadcast address of 255.255.255.255). Any routers that are active on the local network should then respond with unicast Router Advertisement query messages (as described earlier in this section). In addition, routers will also issue Router Advertisement query messages to the all-hosts multicast address of 224.0.0.1 on a periodic basis, allowing devices to update their list of known routers.
Each of the Router Advertisement query messages—regardless of whether they are solicited unicasts or unsolicited multicasts—will contain information about,
the router that is sending it (as described in the Additional Fields reference text above). Devices on the network will then use that information to choose the most appropriate router as their default.
Capture Sample
In the capture shown in Figure 5-28, Sasquatch has sent a Router Advertisement query message directly to Fungi, in response to the query shown in Figure 5-27. Most of the time, Router Advertisement query messages are sent to the all-hosts multicast address of 224.0.0.1, although they can also be unicast directly to a system that has issued a Router Solicitation query message (as shown in Figure 5-27). As can be seen here, this advertisement is only showing a single IP address on the local network and has assigned a preference value of zero to that interface.
 | ||||
| Figure 5-28. An ICMP Router Advertisement query message | ||||
See Also
Router Solicitation and Router Advertisement query messages
Router Solicitation
ICMP in Action
If you were to look at all of the ICMP traffic crossing your network, you would probably be surprised at the amount that gets generated and exchanged during a normal day. This is not necessarily a bad thing, since ICMP is what keeps IP working so well. Most web sites will experience a significant amount of Path MTU
Discovery messages, for example. In addition, sites that move services around on different hosts frequently will see a lot of Destination Unreachable messages, as clients attempt to connect to relocated services.
Notes on Reading ICMP Error Messages
ICMP error messages can be overwhelming, to say the least. They present a lot of information that has be parsed through, deciphered, and generally made sense of.
The easiest way to read an ICMP error message is to break it into manageable chunks. The first portion of the message always identifies the specific ICMP error message being reported, while the remainder of the message consists of the headers and first eight bytes of data from the IP datagram that's being bounced.
For example, Figure 5-29 shows an ICMP Destination Unreachable: Host Unreachable Error message that appears to be very complex on the surface, but actually only consists of a few key pieces of data.
 | ||||
| Figure 5-29. An ICMP Destination Unreachable: Port Unreachable error message | ||||
By following a few simple steps and answering some simple questions, you can easily decipher the source and cause of the ICMP error message. The questions are:
What is the Message Type?
The ICMP Message Type for this message is 3, which indicates that it is part of the Destination Unreachable family of error messages.
What is the Message Code?
The ICMP Message Code for this message is 3, which tells us that this particular Destination Unreachable error message indicates that the destination port was unreachable (this is different from the destination host or network being unreachable).
What does it mean?
We can tell from the discussion of Port Unreachable earlier in Destination Unreachable error messages that the Destination Unreachable: Port Unreachable error message means that the destination port number specified by the UDP or TCP message was not in a listening state, which generally indicates that there was no server running on that port number.
What other evidence is there?
Obviously, the most important piece of evidence for resolving this problem is looking at the destination port number sent in the original message. Since this is an ICMP error message, the original IP datagram has been provided in the message body, so all we have to do is find the Destination Port number field in the original datagram, which points to UDP port 69 (the well-known port for TFTP servers).
What conclusions can we draw?
We can tell that a host on our internal network tried to send a UDP message to the well-known port for TFTP servers on a remote server. Since the message was rejected, we can assume that this means that there was no TFTP server running on the destination system. Furthermore, we can also assume that this was not a configuration issue at the server, where it was configured to block access to this particular client, since the datagram would have cleared the server's UDP stack (although nothing else may have happened, the packet would have gone through and then been ignored, rather than being blocked at the gate by UDP).
Most ICMP error messages can be read using this same series of procedures. In almost all cases, all the information that you need to diagnose the cause of a failure is presented in the ICMP error message's headers, in the headers from the failing datagram, or in the first eight bytes of data from the failing datagram (which is where the source and destination port numbers are provided for TCP and UDP connections).
Notes on ping
One of the most common uses for ICMP is the ping program. According to RFC 1122, every system should implement a user-accessible program for generating ICMP Echo Request and ICMP Echo Reply query messages, and the most common method for this has historically been the ping utility. The ping program allows a user to test network connectivity between two devices by sending out ICMP Echo Request messages and then measuring the amount of time it took to receive an ICMP Echo Reply message back from the destination system.
Figure 5-30 shows three ICMP Echo Request query messages being sent from Arachnid to Krill, with no special Type-of-Service, Precedence or IP Options defined. In addition, Figure 5-30 shows the response time from Krill back to Arachnid, as well as some summary data for the session. This is pretty typical of Unix-based ping programs.
 | ||||
| Figure 5-30. A simple unicast ping test | ||||
There are some details that should be paid attention to whenever ping is used for network testing and diagnostics. In particular, the Identifier field used for the ICMP Echo Request and Echo Reply query messages is the same across every session, while the Sequence Number fields are unique for every message sent during a session.
For example, Figure 5-31 shows the first Echo Request query message from the ping output shown in Figure 5-30, while Figure 5-32 shows the last Echo Reply query message. Notice that each of them share the same Identifier field, although they also have different values in the Sequence Number fields.
 | ||||
| Figure 5-31. The first ICMP Echo Request query message from Figure 5-30 | ||||
 | ||||
| Figure 5-32. The last ICMP Echo Reply query message from Figure 5-30 | ||||
Another interesting aspect to this particular session is the fact that the Sequence Number fields do not match the sequence numbers shown in Figure 5-30. Whereas ping showed sequence numbers of 0 through 2 for the three query messages, we can tell from Figure 5-32 that the Sequence Number fields are actually being incremented by 256 with each Echo Request message getting sent (ranging from 0 through 512). Thus, what ping shows as message number 2 actually has the Sequence Number of 512.
Some ping programs also allow you to send ICMP Echo Request query messages to a broadcast or multicast address. However, not all of the nodes will necessary respond to the request message, since RFC 1122 states that an ICMP Echo Request destined to an IP broadcast or IP multicast address may be silently discarded. This behavior occurs in Figure 5-33, where an ICMP Echo Request message was sent from Greywolf to the broadcast address of the local LAN (see the Destination Address field of the IP datagram), but only a handful of the devices on the local network responded to the ICMP Echo Request, while the rest of the systems just ignored it.
 | ||||
| Figure 5-33. A broadcast ping test | ||||
Notice that Krill, Greywolf, Weasel, Sasquatch, and Froggy all responded to the Echo Request message sent in Figure 5-33, which had the local network broadcast address of 192.168.10.255 in the IP datagram's Destination Address field. However, neither Ferret, Arachnid, nor Canary responded to the query.
Some implementations of ping also let you define specific network characteristics such as the Type-of-Service or Precedence values to be used with the underlying IP datagrams. According to RFC 1122, ICMP Echo Request query messages should use the default Precedence and Type-of-Service values (0), although if you set it higher then the responding system should use the same Precedence and/or Type-of-Service values in their corresponding ICMP Echo Reply Messages.
This concept is illustrated in Figure 5-34. In that example, Ferret sent an ICMP Echo Request query message to Krill, with the Precedence value set to 6 ( flash ) and with the low-latency Type-of-Service flag defined. On a congested network, this packet would have been sent before any other packets that had a lower priority value, and may have even taken an alternate route (perhaps going across a fiber backbone, rather than across a slower data circuit).
 | ||||
| Figure 5-34. A pair of high-priority Echo Request and Echo Reply query messages | ||||
Many ping applications will also allow you to define your own test data. This can be used to test for fragmentation-related problems, and also to test for problems related to equipment that is interpreting specific bit-patterns as hardware test patterns. For example, Media-Related Issues in Chapter 2, The Internet Protocol,
showed how some WAN equipment will interpret a series of ones or zeroes as a test pattern for the equipment itself, causing it to go into test mode. You can use ping to send ICMP Echo Requests with these bit patterns to devices on the other side of the networks, thereby testing for this event. In addition, some implementations will also let you define the amount of data that gets generated by ping. This can be useful for determining end-to-end fragmentation and MTU requirements, particularly where a specific size of message seems to have problems.
For example, Figure 5-35 shows a simple ping test from Krill to Ferret that uses a predefined pattern of 0011001100110011AAFFAAFFAAFF . This test pattern is incorporated into the Optional Data field of the ICMP Echo Request query message and is also returned in the corresponding ICMP Echo Reply query message.
 | ||||
| Figure 5-35. A pair of patterned Echo Request and Echo Reply query messages | ||||
Ping tests may fail for a variety of reasons, ranging from firewall filters to routing errors on the sender's or receiver's networks. For a comprehensive discussion on these problems, refer to Troubleshooting ICMP later in this chapter.
Notes on traceroute
Just as ping allows you to verify connectivity between different devices, traceroute allows you to identify the route that datagrams are taking on their way to a remote device. This is achieved by sending a series of packets with incrementally larger
Time-to-Live values, and then monitoring for ICMP Time Exceeded error messages as the packets expire on the way to the destination system.
The first packet sent by traceroute will have a Time-to-Live value of 1. When the packet is received by the first-hop router on the local network, the router will be unable to forward the datagram without the Time-to-Live value reaching zero, so the router will discard the datagram and send an ICMP Time Exceeded error message back to the sender.
traceroute records the IP address of the router that returned the datagram, and then sends another datagram with the Time-to-Live field set to 2. This time the datagram makes it past the first-hop router to the next router in the path. However, since the Time-to-Live value will have been set to 1 by the first-hop router during the forwarding process, the next-hop router will reject the packet and send an ICMP Time Exceeded error message back to the sending system.
This process is repeated over and over, until the final destination system has been reached. Once that occurs, the local system will have received ICMP Time Exceeded error messages from every router between itself and the final destination system, and will therefore have a complete map of the intermediary network.
It is important to note that different versions of traceroute use different types of data for the seed datagrams, and the responses you get will probably vary according to the version you use. The original version of traceroute was written by Van Jacobsen at the Lawrence Berkeley Labs in Berkeley, California, and is the default version that ships with most Unix systems. Other vendors and TCP/IP implementations ship versions of traceroute that work somewhat differently
Van Jacobsen's version of traceroute sends three UDP messages for every send effort, allowing average latencies to be determined for each hop along the path. In addition, this version of traceroute increments the destination UDP port number of each datagram that it sends, allowing the latency times for each datagram to be tracked individually (this is important in case one or more packets gets sidetracked somewhere, and ends up getting returned later than other datagrams sent afterwards).
For example, Figure 5-36 shows a capture of a traceroute session between Greywolf and www.ora.com. This version of traceroute uses the Van Jacobsen model, which sends three UDP datagrams to the destination system in a batch, with each of the datagrams having an incrementally higher destination port number. As the Time-to-Live values of the IP datagrams expire, they are rejected by intermediary routers along the way. This information is then used to display summary data about the latencies of the networks in between the sender and the destination system.
 | ||||
| Figure 5-36. traceroute using UDP datagrams | ||||
Once the seed UDP datagrams reach the destination system, they may be rejected with ICMP Destination Unreachable: Port Unreachable error messages, although it is also possible that some form of response may come back to the sender via UDP (if one of the target port numbers were active). Regardless, some sort of event should happen that will indicate the complete path has been discovered.
However, that was not the case in this example. Indeed, the last-hop from the traceroute shown in this test failed on a continuous basis, due to no response coming back from the remote system, as is shown in Figure 5-37.
This could be a result of a number of factors, although most likely it is due to a firewall on the ora.com network blocking the unsolicited UDP messages from entering the network, meaning they will never be seen by the target system. This scenario is quite common, and is discussed in detail in Firewalls Blocking UDP Messages in Chapter 6, The User Datagram Protocol. It could also be that a firewall is blocking the ICMP response messages, preventing the local system from seeing the resulting messages. This is also quite common and is discussed in detail later in Troubleshooting ICMP.
The output from the traceroute session shown in Figure 5-36 can be seen in Figure 5-38. As can be seen, the last-hop is shown as unknown (the * indicates that the request timed out), since traceroute is not receiving any responses from either the destination system or any intermediary routers. As such, it continues to increment the Time-To-Live value of the outgoing IP packets, until the process is terminated by the user.
 | ||||
| Figure 5-37. UDP traceroute failing, due to firewall blocking | ||||
 | ||||
| Figure 5-38. Visual output of the traceroute from Figure 5-36 | ||||
There have been some problems with the Van Jacobsen version of traceroute. For one thing, many firewalls block unsolicited UDP datagrams (as discussed above). In addition, the use of incremental UDP port numbers can make these messages appear to be port scans on the destination system, which can trigger false alarms for security-conscious sites.
For these reasons, there are a variety of other traceroute programs that use ICMP Echo Request query messages for the seed data, instead of UDP datagrams. Another advantage to using ICMP Echo Request messages is that these messages contain built-in Identifier and Sequence Number fields, which provide better packet-tracking mechanisms for traceroute to use in its per-hop calculations than UDP port numbers do.
Figure 5-39 shows a traceroute session between Arachnid and www.ora.com, using ICMP Echo Request query messages as the seed. Three ICMP Echo Request query messages are sent to the destination system in a batch, with each of the messages having incrementally higher Sequence Numbers (although the Identifier stays the same for all of them). As the Time-to-Live values of the IP datagrams expire, they are rejected by intermediary routers along the way. This information is then used to display summary data about the networks between the sender and the destination system.
 | ||||
| Figure 5-39. traceroute using ICMP Echo Request query messages | ||||
Once the seed ICMP Echo Request query messages have reached the destination system, they should be responded to with ICMP Echo Reply query messages, indicating that the complete path has been discovered.
The output from the traceroute session shown in Figure 5-39 can be seen in Figure 5-40. This time traceroute runs to completion.
There are problems with using ICMP Echo Request messages too, of course. One major problem is that many firewalls also block all forms of ICMP traffic, just as many firewalls will block unsolicited UDP datagrams.
 | ||||
| Figure 5-40. Visual output of the traceroute from Figure 5-39 | ||||
The other big problem with this model is that not all TCP/IP implementations return ICMP error messages in response to an ICMP query message. RFC 1122 states that ICMP error messages should not be generated in response to other ICMP error messages. However, devices can (and should) generate ICMP error messages in response to ICMP query messages that fail. Unfortunately, not all vendors have made this distinction, and there are some implementations that do not return ICMP error messages in response to any ICMP traffic whatsoever.
RFC 1393 proposed yet another mechanism for traceroute programs to use, although this proposal has not been widely accepted. Essentially, RFC 1393 proposed that a device send a single IP datagram that contained an experimental Traceroute IP Option. As the datagram wound its way through the network, routers would issue an experimental ICMP Traceroute message back to the sending system, showing their IP address. By the time the original request datagram gets to the destination system, the sender would have a full map of all the devices on the path.
Although there are benefits to this model (only one seed datagram is required, and the return path could also be discovered independently of the seed path), there are also major problems with it, including the use of the experimental Traceroute IP Option and the experimental ICMP Traceroute message, neither of which have been standardized. For these reasons, this model is not widely supported.
Notes on Path MTU Discovery
Just as traceroute allows a system to discover the path taken between two devices, an algorithm called Path MTU Discovery allows the sender to find the most efficient packet size for the connection between two systems. This is particularly important when the two systems are going to exchange a significant amount of data, since sending large datagrams may cause fragmentation (which introduces delay and also increases the risk of errors), while sending small packets generates an excessive amount of traffic. Finding the largest possible MTU on an end-to-end connection allows the systems to send the most amount of data in the least number of packets, thereby keeping fragmentation from occurring.
Path MTU Discovery is described in detail by RFC 1191. Essentially, Path MTU Discovery works by having the sender decrement the size of the IP datagrams until they can be sent to the recipient without being fragmented.
The optimal MTU size is determined by the sender starting with the largest possible size (as determined by their local MTU), and then setting the Don't Fragment flag in the datagram's IP header. If an ICMP Destination Unreachable: Fragmentation Required but DF Bit Is Set error message comes back to the sender, then the datagram is too large to be sent across the network. The sender would then reduce the size of the datagram and try the operation again. This process is repeated until no errors are returned. At this point, the sender can use the lastknown MTU of the test datagram as the MTU of the entire network.
In addition, RFC 1191 states that the Message Data field of the ICMP Fragmentation Required but DF Bit Is Set error message should be split into two subfields, one of which is a two-byte field called the Next-Hop MTU. This field can be used by a rejecting router to specify the exact MTU of the next-hop network. If a router was not aware of this extension, then it would simply return the Fragmentation Required error message, and the sender would have to guess about the nexthop network's MTU size. But if the router were aware of the extension, it could provide the MTU value explicitly, which the sender would use on subsequent probes.
For example, Figure 5-41 shows a capture of a packet containing the Next-Hop MTU data. Since the ICMP Message Data field contains four bytes of hexadecimal data (00 00 02 40), it indicates that the MTU of the next hop is 576 bytes (the first two bytes are ignored, and hexadecimal 0240 is equal to decimal 576). If this were a regular Fragmentation Required error message, the ICMP Message Data field would contain zeroes.
Path MTU Discovery is mostly seen when a remote system is connected on a network with a smaller MTU than the MTU of the sender. This could be a remote Ethernet segment with an MTU that is smaller than the Token Ring network that the sender is on, or a remote dial-up system with an MTU that is smaller than the Ethernet network that the sender is using. Since most end-user networks are Ethernet (which has an MTU of 1500 bytes)—and since most of the Internet backbone
 | ||||
| Figure 5-41. A Path MTU-aware Destination Unreachable error message | ||||
uses high-speed networks with MTUs that are significantly larger than 1500 bytes—most network-to-network connections that travel across the Internet use the same MTU all of the time.
However, users who try to exchange a lot of data between a host on a Token Ring network and a host on an Ethernet network will likely see a substantial amount of Path MTU Discovery messages. Similarly, users who try to exchange a lot of data between a host on an Ethernet network and a dial-up user who has a small MTU will also see a lot of these kinds of messages.
For example, Figure 5-42 shows a 1500-byte packet being sent from 192.168.10.10 to 192.168.100.10, by way of an Ethernet segment, a data circuit, and a dial-up connection. The Ethernet and leased-line networks both provide MTUs of 1,500 bytes, so the datagram is able to be sent across both of those networks without difficulty. However, once it gets to the router at 192.168.60.70, the datagram is deemed too large to travel across the network and is rejected.
However, the rejecting router supports the Path MTU Discovery extensions defined in RFC 1191, and so it returns an ICMP Destination Unreachable: Fragmentation Required error message with the Next-Hop MTU field showing the next network as being limited to 512-byte MTU sizes. 192.168.10.10 can then use this value for the remainder of the connection, and will resend the data using 512-byte datagrams.
 | ||||
| Figure 5-42. An overview of Path MTU Discovery | ||||
Unfortunately, there are a lot of problems with Path MTU Discovery, although most of them are related to implementation issues rather than being problems with the protocol itself. The biggest such problem is that many firewalls block the sending and/or receiving of ICMP messages, and in those situations, the ICMP Destination Unreachable error messages will not get returned to the sender of the large datagrams (a phenomenon referred to as PMTU Black Hole ). Many implementations assume that a lack of error messages means that the datagram went through successfully, so the MTU is fine, which might be wrong in this situation (particularly if the sender's MTU was indeed too large to reach the destination network intact).
One solution to this problem that works with TCP connections in particular is to watch for lost data. If full-sized datagrams are not being acknowledged by the remote TCP end-point, then the sender should reduce the size of the segments being sent and try again until an acceptable MTU is found.
Another workaround to this problem is for the sender to stop using the Don't Fragment flag on subsequent datagrams, which would then allow the data to get through the rest of the network (although it would get fragmented if the end-to-end MTU were not large enough to handle the over-sized datagrams). However, some implementations do this in a schizophrenic way, forgetting when they have cleared the flag. For example, a sender may detect that the MTU is too large and then clear the Don't Fragment bit after detecting lost data, only to reset the flag on subsequent packets. This results in three or four sends that are too large, followed by a send without the Don't Fragment flag, followed by more big sends with the flag enabled. Obviously, this will have a negative impact on overall performance.
Note that the alternative traceroute mechanism defined in RFC 1393 also provided services for returning the MTU sizes of the next-hop network, using the ICMP Traceroute messages that routers would return. However, RFC 1393 is not widely supported, due to its heavy reliance on experimental and non-standard IP Options and ICMP Messages.
Troubleshooting ICMP
Although ICMP is effective at informing devices of problems with the network, it is also succeptible to these same problems, since it relies on IP for delivery services. Many times, you will encounter a connectivity problem, and get no clue as to the true source of the problem from ICMP. There are several possible causes for not receiving ICMP error messages back from a problem network.
Firewalls Blocking ICMP Traffic
Let's say that you are trying to ping a remote web server. Perhaps you are able to connect to it using HTTP, but you are unable to get a response from it when using ping. In this case, it is entirely possible that your ICMP Echo Request messages are getting sent to the remote network, but that a firewall at the remote network is filtering out all incoming ICMP messages. In this case, your messages are simply getting eaten by the firewall, and no ICMP messages (neither ICMP query responses, nor ICMP errors) are being sent back.
Although the polite thing to do would be for the remote firewall to send a Destination Unreachable: Communication Administratively Prohibited error message, many network administrators consider these messages to be security holes, and disable their use on their firewalls. In this scenario, you would not receive any message back whatsoever.
Conversely, the problem may be with your firewall. It is entirely possible that your network administrator has also blocked all incoming ICMP messages, although outgoing messages are allowed to pass freely. In that situation, your ICMP Echo Request messages may be getting to the remote system—and it may be responding—but your firewall is blocking the responses from getting back into your network.
For example, Figure 5-43 shows Ferret sending an ICMP Echo Request query message to Fungi. Sasquatch is configured to allow traffic out from the 192.168.10.0 network, so it forwards the message on to the destination system. However, when Fungi tries to send an ICMP Echo Reply query message back to Ferret, the firewall blocks the datagram, since it is configured to block all incoming ICMP messages. In this example, Ferret would not be able to successfully ping Fungi, even though other forms of IP traffic may work just fine.
 | ||||
| Figure 5-43. An ICMP Echo Reply query message being blocked by a firewall | ||||
A variation on this theme is when firewalls filter out unsolicited ICMP messages (such as Source Quench and Destination Unreachable) or allow these messages to be sent to predefined internal hosts (such as an internal web server). In this case, you would never receive these warning messages, although you should be able to see ICMP Echo Replies since they were solicited by an earlier ICMP Echo Request message.
This process can result in all kinds of problems, particularly when the firewall interfaces with the Path MTU Discovery algorithm. In that scenario, the ICMP Destination Unreachable: Fragmentation Required but DF Bit Is Set error messages being generated on the open Internet are getting blocked by your firewall. Since no errors are making it back to you, the local system is working under the assumption that the destination system is able to handle the larger MTU sizes. In reality, the remote system just cannot handle the larger datagrams.
For all of these reasons, you must monitor the ICMP traffic on both networks simultaneously when you try to use ping to diagnose remote connectivity. You would need to monitor the local network to make sure that the Echo Request messages are being sent (and also looking for any Echo Reply messages that may not be getting sent back), and you should also monitor the remote network to ensure that the Echo Request messages are being received and that the Echo Reply messages are also getting sent. If the Echo Replies are getting sent by the remote network but are not getting received by the local network, then either end may be blocking the ICMP traffic at a firewall, or the remote end-point may have routing errors.
Misconfigured Routing Tables
It is also quite possible that your datagrams are going out to the remote destination, and that datagrams are being sent back to your system, but that they are taking a bad route on the way back to your network. This problem occurs when the advertised routes for your network point to an illegal route.
This is a very common problem with new or recently changed networks. It is not at all uncommon for somebody to forget to define the route back to your new network. Remember that just because the datagrams are going out does not mean that return datagrams are coming back on the same route.
Large Quantities of Redirect Error Messages.
Some networks are known to generate a large number of ICMP Redirect error messages. Typically this is a result of one of two situations: misconfigured subnet mask on the hosts and routers, or a heavy dependence upon Router Discovery for host configuration.
Router Discovery
If you are seeing a lot of ICMP Redirect error messages in conjunction with Router Discovery, then you are not experiencing a problem (this is almost by definition). It is the prescribed behavior for the Router Discovery Protocol.
Remember that network devices will only choose a single default router, based on the preference values that are advertised by routers when they respond to Router Solicitation query messages. In this model, hosts will use that router for all non-local datagrams until they are informed of a better router for a specific destination system. Therefore, if your network has multiple routers, you will see a multitude of ICMP Redirect error messages on your network, as the devices learn about the various routers and the paths they support.
It may be that you have given the wrong router the highest preference value, and that by assigning a higher preference to another (more frequently used) router, the number of ICMP Redirect error messages on your network could be reduced. Another option would be to concentrate your routers together, allowing only one router to serve the local segment. This would essentially cause all traffic to go through the one remaining router, which would eliminate all ICMP Redirect traffic on the local segment.
For more information on Router Discovery, refer back to Router Solicitation and Router Advertisement query messages .
Misconfigured subnet masks
Another common cause for high numbers of ICMP Redirect error messages can be seen on networks that have hosts with invalid subnet masks. Whenever these hosts try to connect to another system on the local network, they may think that the destination system is actually on a different network (due to the boundaries of the subnet mask in use), and as such will send the datagrams to the local router for delivery. The router would then inform the sender that the destination system was indeed local to the sender (using a Redirect error message for the job).
The best solution to this problem is to assign the correct subnet mask to the devices on the network, allowing them to communicate with each directly without one of them trying to contact a router first.
First Packet from ping Always Fails
Sometimes, when trying to use ping to test connectivity with other devices, the first packet sent will fail to be acknowledged. This could happen for a number of reasons:
ARP cache is empty
If the ARP cache on the sending system does not have an entry for the destination system (assuming that the destination system is local), then the time it takes to locate the hardware address of the destination device may exceed the timeout threshold defined in the ping client. In addition, if the size of the ICMP Echo Request Message is larger than the local system's MTU, then another (somewhat rare) condition can also be met, whereby ping has flushed the first fragment from its call-back queue, and as such only the second (and subsequent) fragments from the first datagram are getting sent. In that case, the recipient will ignore the IP packet, since it is not complete. These issues
are discussed in more detail in Bursted Duplicate ARP Requests in Chapter 3, The Address Resolution Protocol.
Routing cache is empty
There are millions of networks in use on the Internet today, and most of the routers are simply incapable of keeping track of all the others. In fact, most routers store only a few routing paths in their caches at any given time. In that model, if a packet is getting sent to a network that has not been processed lately, it may take some time for the router to determine the correct network path for the packet to take. This may result in the ping client reaching a timeout threshold before the ICMP Echo Request query message is responded to successfully. In that case, ping may mark the first few messages as lost.
DNS name cache is empty
If you are using host names with ping, then some messages may get delayed during the DNS lookup operation, and may be either bumped out of the queue during processing or erroneously reported as timed out. In either case, you should always use IP addresses during probe operations (this includes traceroute when possible) to keep the name resolution process from interfering with the system tests.
| | |
EAN: 2147483647
Pages: 17