Section 25.3.  ICMP Types

25.3. ICMP Types Table 25-1 lists the ICMP types and the RFCs where they are defined, shows whether they are generally transmitted and processed by the kernel or in user space, and classifies each as an error or query message. The kernel symbols are listed in include/linux/icmp.h. The table lists only the ICMP message types the Linux kernel cares about (regardless of whether they are implemented). You can refer to the URL provided in the chapter's introduction for an updated list. Table 25-1. ICMP types Type Name TX by RX by RFC Error/Query 0 8 Echo Reply Echo Request Kernel User User Kernel 792 792 Query Query 1 2 Not assigned Not assigned         3 Destination Unreachable Kernel Kernel 792 Error 4 Source Quench (obsolete; see RFC 1812 section 4.3.3.3)         5 Redirect Kernel Kernel 792 Error 6 Alternate Host Address (obsoletea)         7 Not assigned         9 10 Router Advertisement Router Solicitation User User User User 1256 Query 11 Time Exceeded Kernel Kernel 792 Error 12 Parameter Problem Kernel Kernel 792 Error 13 Timestamp Request User Kernel 792 Query 14 Timestamp Reply Kernel User 792 Query 15 16 Information Request Information Reply (obsolete; see RFC 1122 section 3.2.2.7 and RFC 1812 section 4.3.3.7)         17 18 Address Mask Request Address Mask Reply Kernel Kernel Kernel Kernel 950 Query aThis option was defined by the same author of RFC 792, but it is not defined in any RFC. ICMP types 1, 2, and 7 are simply listed as unassigned, and type 6 is not defined in any RFC. Types 9 and 10 are not handled (and therefore are not defined) in kernel space; the Router discovery messages are processed in user space by applications that implement RFC 1256. For Linux, you can refer to rdisc, which is an application that comes as part of the iputils package. RFC 1122 and RFC 1812 tell whether the implementation for each ICMP message type is optional or mandatory, for hosts and routers respectively. Table 25-2 summarizes these requirements. For the exact interpretation of the words must, should and may, you can refer to RFC 2119. The table does not include obsolete options. Table 25-2. Host and router requirements Type Name Hosts (RFC 1122) Routers (RFC 1812) Linux is compliant 0 8 Echo Reply Echo Request Must implement an echo server Must implement an echo server Yes 3 Destination Unreachable Should transmit Must receive Must transmit Yes 5 Redirect Should not transmit Must receive Must transmit May receive Yes 9 10 Router Advertisement Router Solicitation N/A Must receive No (Support is available in user space) 11 Time Exceeded Must receive Must transmit Yes 12 Parameter Problem Should transmit Must receive Must transmit Yes 13 14 Timestamp Request Timestamp Reply May receive May receive May receive/transmit Yes 17 18 Address Mask Request Address Mask Reply May receive/transmit Must receive/transmit No A router must respect the host requirements when it is the originator of the IP packet that triggered the transmission of an ICMP message. For example, the Destination Unreachable ICMP message is sent to the host whose IP packet could not be delivered. When an offending packet is generated by a router, the router must process the ICMP error message according to the host requirements in Table 25-2. Note that a router cannot be the target of a Destination Unreachable message sent for an IP packet it has not generated (which explains why Table 25-2 does not specify how a router must behave when it receives one). Similar comments apply to other message types. 25.3.1. ICMP_ECHO and ICMP_ECHOREPLY These are probably the most common and best-known ICMP types. They are used by different applications, the most famous of which is ping. The ICMP_ECHO message type is used to test the reachability of a remote host. When a host receives an ICMP_ECHO message, it replies with an ICMP_ECHOREPLY message. See the section "ping." 25.3.2. ICMP_DEST_UNREACH When an IP packet cannot be delivered to its destination, or when the IP payload cannot be delivered to the target application on the remote host, this ICMP type is used to notify the sender about the failed delivery and its cause. This ICMP type has quite a few different subtypes (code values), all listed in Table 25-3. Not all of them are used by Linux. The header used for this message includes the 32-bit field shown in Figure 25-1(a). Table 25-3. ICMP codes for ICMP type ICMP_UNREACH Code Kernel symbol Description 0 ICMP_NET_UNREACH Network unreachable. 1 ICMP_HOST_UNREACH Host unreachable. 2 ICMP_PROT_UNREACH Protocol unreachable. The transport protocol used on top of IP is not implemented on the target host. 3 ICMP_PORT_UNREACH Port unreachable. There is no application listening to the port number specified by the destination port in the transport header. 4 ICMP_FRAG_NEEDED Fragmentation needed. The IP packet needed to be fragmented but the Don't Fragment (DF) flag was set in the IP header. 5 ICMP_SR_FAILED Source route failed. 6 ICMP_NET_UNKNOWN Destination network unknown. 7 ICMP_HOST_UNKNOWN Destination host unknown. 8 ICMP_HOST_ISOLATED Source host isolated. 9 ICMP_NET_ANO Communication with destination network is administratively prohibited. 10 ICMP_HOST_ANO Communication with destination host is administratively prohibited. 11 ICMP_NET_UNR_TOS Destination network unreachable for Type of Service. 12 ICMP_HOST_UNR_TOS Destination host unreachable for Type of Service. 13 ICMP_PKT_FILTERED Communication administratively prohibited. 14 ICMP_PREC_VIOLATION Host precedence violation. 15 ICMP_PREC_CUTOFF Precedence cutoff in effect. 25.3.3. ICMP_SOURCE_QUENCH This message type was originally defined as a mechanism for routers to inform peers about congestion. However, generating more traffic to help with congestion recovery did not turn out to be that effective, and RFC 1812 made this ICMP message type obsolete. The original goal of this ICMP type (congestion control) is now taken care of by the Early Congestion Notification (ECN) mechanism described in RFC 3168. 25.3.4. ICMP_REDIRECT ICMP REDIRECT message types are sent only by routers, and are processed by hosts and optionally by routers.[*] Linux provides a file in /proc that allows you to enable and disable the processing of ICMP_REDIRECT messages. Routers generate this type of message when they detect that a neighboring host is using suboptimal routing; that is, when a destination can be reached through a better gateway than the one generating the message. [*] See RFC 1812, sections 4.3.3.2 and 5.2.7.2. The basic and most common cause for an ICMP_REDIRECT message is an ingress packet that needs to be forwarded out of the same device it was received from. We will see an example later in this section. There are four subtypes for this ICMP message type, shown in Table 25-4. RFC 1812 states that only ICMP_REDIR_HOST and ICMP_REDIR_HOSTTOS should be generated because there are cases where the use of subnetting makes it harder to handle the other two ICMP codes. Linux follows this recommendation. Table 25-4. ICMP codes for ICMP type ICMP_REDIRECT Code Kernel symbol Description 0 ICMP_REDIR_NET (obsolete) Redirect for network address 1 ICMP_REDIR_HOST Redirect for host address 2 ICMP_REDIR_NETTOS (obsolete) Redirect for network address and Type of Service 3 ICMP_REDIR_HOSTTOS Redirect for host address and Type of Service Figure 25-3 provides a scenario where a router generates an ICMP_REDIRECT message. From the topology it looks clear that Host X should use Router RT2 to reach Host Y. But suppose Host X has been configured only with the default gateway RT1 so that any traffic Host X sends outside its local network goes to Router RT1. Figure 25-3. Example of ICMP_REDIRECT This is what happens when Host X transmits an IP packet to Host Y: Host X sends Router RT1 a packet addressed to Host Y. Router RT1 consults its routing table and realizes the next hop is Router RT2. It also realizes that because Router RT2 is on the same subnet as Host X, Host X could have sent the packet directly to Router RT2. Router RT1 sends Host X an ICMP_REDIRECT message to inform it about the better route. Host X will save the route and use it next time. Router RT1 forwards the packet to Router RT2. Normally, when a router detects that it is being asked to route a packet along a suboptimal route, it replies back to the sender with an ICMP_REDIRECT message that describes the correct route. For security reasons, however, these suggestions are often rejected nowadays: you can imagine how easy it otherwise could be to create trouble by just saying, "Look, to get to that network you should use Router XYZ rather than the one you have been configured with." In the section "Transmitting ICMP_REDIRECT Messages" in Chapter 31, you can find the exact conditions that trigger the transmission of ICMP_REDIRECT messages. Also see the section "ICMP Redirect" in Chapter 20 for the interaction between this ICMP type and the Source Route IP option. In the section "Processing Ingress ICMP_REDIRECT Messages" in Chapter 31, you can find details about whether an ingress ICMP_REDIRECT message is processed. 25.3.5. ICMP_TIME_EXCEEDED This message type has two subtypes, as shown in Table 25-5. Table 25-5. ICMP codes for ICMP type ICMP_TIME_EXCEEDED Code Kernel symbol Description 0 ICMP_EXC_TTL TTL exceeded 1 ICMP_EXC_FRAGTIME Fragment reassembly time exceeded The IP header includes a field, TTL, that is decremented at each intermediate hop between source and destination. If TTL becomes 0 before the packet reaches the destination host, the IP packet is dropped. The intermediate host that drops the packet sends an ICMP_EXEC_TTL message to the sender to inform it that its packet was dropped. We will see in the section "traceroute" how the popular command traceroute uses it. The ICMP_EXC_FRAGTIME message is generated when the defragmentation of an IP packet takes too long to complete and is therefore aborted. 25.3.6. ICMP_PARAMETERPROB When a problem is found while processing the IP header of an ingress IP packet, the host that detects the problem sends an ICMP message of this type back to the source. The ICMP header (see Figure 25-1(c)) includes an offset that indicates where in the IP header the problem was found. 25.3.7. ICMP_TIMESTAMP and ICMP_TIMESTAMPREPLY The ICMP_TIMESTAMP message type can be used to ask a remote host for a timestamp (actually two of them) and use it to synchronize the hosts' clocks. A host that receives an ICMP_TIMESTAMP message replies with an ICMP_TIMESTAMPREPLY message like that in Figure 25-4. Figure 25-4. ICMP_TIMESTAMPREPLY structure While the first timestamp is initialized by the ICMP_TIMESTAMP sender, the other two are initialized by the ICMP_TIMESTAMPREPLY sender. The second and third timestamps should reflect the time the ICMP_TIMESTAMP message was received and the time the associated ICMP_TIMESTAMPREPLY was transmitted. These ICMP types are not of much use because other protocols are better suited for the same purpose (e.g., NTP). 25.3.8. ICMP_INFO_REQUEST and ICMP_INFO_REPLY According to RFC 1122, these two ICMP message types were made obsolete because other protocols such as DHCP (and the older BOOTP and RARP) can do the same thing, and much more. 25.3.9. ICMP_ADDRESS and ICMP_ADDRESSREPLY The purpose of these ICMP types is to allow a host to discover the netmasks to use on its interfaces by broadcasting a query on the attached networks. A router that receives an ICMP_ADDRESS message replies with an ICMP_ADDRESSREPLY message. The reply is usually unicast to the sender, but may be broadcasted when the sender uses a source IP address of 0 (i.e., not configured). The goal of these two message types is achieved nowadays by other means, such as DHCP. The Linux kernel does not reply to ingress ICMP_ADDRESS messages, but it listens to ingress ICMP_ADDRESSREPLY messages to detect misconfigurations (such as wrong netmask configurations). Among the reasons why Linux does not process ICMP_ADDRESS messages is that the same interface can be configured with multiple IP addresses, and therefore there may not be a unique netmask to return to any given request. According to RFC 1812, the implementation of the ICMP_ADDRESS and ICMP_ADDRESSREPLY messages is mandatory on routers, so Linux is not compliant. However, since these ICMP message types are not commonly used, this missing compliance does not represent a compatibility problem in any way for Linux.