Skip to main content
Engineering LibreTexts

7.11: Internet Control Message Protocol

  • Page ID
    11150
  • The Internet Control Message Protocol, or ICMP, is a protocol for sending IP-layer error and status messages; it is defined in RFC 792 [https://tools.ietf.org/html/rfc792.html]. ICMP is, like IP, host-to-host, and so they are never delivered to a specific port, even if they are sent in response to an error related to something sent from that port. In other words, individual UDP and TCP connections do not receive ICMP messages, even when it would be helpful to get them.

    ICMP messages are identified by an 8-bit type field, followed by an 8-bit subtype, or code. Here are the more common ICMP types, with subtypes listed in the description.

    Type

    Description

    Echo Request

    ping queries

    Echo Reply

    ping responses

    Destination Unreachable

    Destination network unreachable

    Destination host unreachable

    Destination port unreachable

    Fragmentation required but DF flag set

    Network administratively prohibited

    Source Quench

    Congestion control

    Redirect Message

    Redirect datagram for the network

    Redirect datagram for the host

    Redirect for TOS and network

    Redirect for TOS and host

    Router Solicitation

    Router discovery/selection/solicitation

    Time Exceeded

    TTL expired in transit

    Fragment reassembly time exceeded

    Bad IP Header or Parameter

    Pointer indicates the error

    Missing a required option

    Bad length

    Timestamp Timestamp Reply

    Like ping, but requesting a timestamp from the destination

    The Echo and Timestamp formats are queries, sent by one host to another. Most of the others are all error messages, sent by a router to the sender of the offending packet. Error-message formats contain the IP header and next 8 bytes of the packet in question; the 8 bytes will contain the TCP or UDP port numbers. Redirect and Router Solicitation messages are informational, but follow the error-message format. Query formats contain a 16-bit Query Identifier, assigned by the query sender and echoed back by the query responder.

    ICMP is perhaps best known for Echo Request/Reply, on which the ping tool (1.14   Some Useful Utilities) is based. Ping remains very useful for network troubleshooting: if you can ping a host, then the network is reachable, and any problems are higher up the protocol chain. Unfortunately, ping replies are often blocked by many firewalls, on the theory that revealing even the existence of computers is a security risk. While this may sometimes be an appropriate decision, it does significantly impair the utility of ping.

    Ping can be asked to include IP timestamps (7.1   The IPv4 Header) on Linux systems with the -T option, and on Windows with -s.

    Source Quench was used to signal that congestion has been encountered. A router that drops a packet due to congestion experience was encouraged to send ICMP Source Quench to the originating host. Generally the TCP layer would handle these appropriately (by reducing the overall sending rate), but UDP applications never receive them. ICMP Source Quench did not quite work out as intended, and was formally deprecated by RFC 6633 [https://tools.ietf.org/html/rfc6633.html]. (Routers can inform TCP connections of impending congestion by using the ECN bits.)

    The Destination Unreachable type has a large number of subtypes:

    • Network unreachable: some router had no entry for forwarding the packet, and no default route

    • Host unreachable: the packet reached a router that was on the same LAN as the host, but the host failed to respond to ARP queries

    • Port unreachable: the packet was sent to a UDP port on a given host, but that port was not open. TCP, on the other hand, deals with this situation by replying to the connecting endpoint with a reset packet. Unfortunately, the UDP Port Unreachable message is sent to the host, not to the application on that host that sent the undeliverable packet, and so is close to useless as a practical way for applications to be informed when packets cannot be delivered.

    • Fragmentation required but DF flag set: a packet arrived at a router and was too big to be forwarded without fragmentation. However, the Don’t Fragment bit in the IPv4 header was set, forbidding fragmentation.

    • Administratively Prohibited: this is sent by a router that knows it can reach the network in question, but has configureintro to drop the packet and send back Administratively Prohibited messages. A router can also be configured to blackhole messages: to drop the packet and send back nothing.

    In 12.13   Path MTU Discovery we will see how TCP uses the ICMP message Fragmentation required but DF flag set as part of Path MTU Discovery, the process of finding the largest packet that can be sent to a specific destination without fragmentation. The basic idea is that we set the DF bit on some of the packets we send; if we get back this message, that packet was too big.

    Some sites and firewalls block ICMP packets in addition to Echo Request/Reply, and for some messages one can get away with this with relatively few consequences. However, blocking Fragmentation required but DF flag set has the potential to severely affect TCP connections, depending on how Path MTU Discovery is implemented, and thus is not recommended. If ICMP filtering is contemplated, it is best to base block/allow decisions on the ICMP type, or even on the type and code. For example, most firewalls support rule sets of the form “allow ICMP destination-unreachable; block all other ICMP”.

    The Timestamp option works something like Echo Request/Reply, but the receiver includes its own local timestamp for the arrival time, with millisecond accuracy. See also the IP Timestamp option, 7.1   The IPv4 Header, which appears to be more frequently used.

    The type/code message format makes it easy to add new ICMP types. Over the years, a significant number of additional such types have been defined; a complete list [http://www.iana.org/assignments/icmp...ameters.xhtml] is maintained by the IANA. Several of these later ICMP types were seldom used and eventually deprecated, many by RFC 6918 [https://tools.ietf.org/html/rfc6918.html].

    ICMP packets are usually forwarded correctly through NAT routers, though due to the absence of port numbers the router must do a little more work. RFC 3022 [https://tools.ietf.org/html/rfc3022.html] and RFC 5508 [https://tools.ietf.org/html/rfc5508.html] address this. For ICMP queries, like ping, the ICMP Query Identifier field can be used to recognize the returning response. ICMP error messages are a little trickier, because there is no direct connection between the inbound error message and any of the previous outbound non-ICMP packets that triggered the response. However, the headers of the packet that triggered the ICMP error message are embedded in the body of the ICMP message. The NAT router can look at those embedded headers to determine how to forward the ICMP message (the NAT router must also rewrite the addresses of those embedded headers).

    7.11.1 Traceroute and Time Exceeded

    The traceroute program uses ICMP Time Exceeded messages. A packet is sent to the destination (often UDP to an unused port), with the TTL set to 1. The first router the packet reaches decrements the TTL to 0, drops it, and returns an ICMP Time Exceeded message. The sender now knows the first router on the chain. The second packet is sent with TTL set to 2, and the second router on the path will be the one to return ICMP Time Exceeded. This continues until finally the remote host returns something, likely ICMP Port Unreachable.

    For an example of traceroute output, see 1.14   Some Useful Utilities. In that example, the three traceroute probes for the Nth router are sometimes answered by two or even three different routers; this suggests routers configured to work in parallel rather than route changes.

    Many routers no longer respond with ICMP Time Exceeded messages when they drop packets. For the distance value corresponding to such a router, traceroute reports ***.

    Traceroute assumes the path does not change. This is not always the case, although in practice it is seldom an issue.

    Traceroute to a nonexistent site works up to the point when the packet reaches the Internet “backbone”: the first router which does not have a default route. At that point the packet is not routed further (and an ICMP Destination Network Unreachable should be returned).

    Traceroute also interacts somewhat oddly with routers using MPLS (see 20.12   Multi-Protocol Label Switching (MPLS)). Such routers – most likely large-ISP internal routers – may continue to forward the ICMP Time Exceeded message on further towards its destination before returning it to the sender. As a result, the round-trip time measurements reported may be quite a bit larger than they should be.

    7.11.2 Redirects

    Most non-router hosts start up with an IPv4 forwarding table consisting of a single (default) router, discovered along with their IPv4 address through DHCP. ICMP Redirect messages help hosts learn of other useful routers. Here is a classic example:

    redirect.svg

    A is configured so that its default router is R1. It addresses a packet to B, and sends it to R1. R1 receives the packet, and forwards it to R2. However, R1 also notices that R2 and A are on the same network, and so A could have sent the packet to R2 directly. So R1 sends an appropriate ICMP redirect message to A (“Redirect Datagram for the Network”), and A adds a route to B via R2 to its own forwarding table.

    7.11.3 Router Solicitation

    These ICMP messages are used by some router protocols to identify immediate neighbors. When we look at routing-update algorithms, 9   Routing-Update Algorithms, these are where the process starts.