ICMP, ping, and How traceroute Works

The Internet Control Message Protocol (ICMP)

IP provides only best-effort service, so when something goes wrong with a datagram the network needs a way to tell the source. The Internet Control Message Protocol (ICMP) does this job: hosts and routers use it to exchange network-layer error reports and control information.

ICMP messages are carried as the data of IP datagrams, with protocol field 1 in the IP header. In that sense ICMP sits "above" IP, although it is usually considered part of the network layer. Every ICMP message has a type field and a code field. Error-report messages also carry the header and the first 8 data bytes of the datagram that caused the error, so the source can tell which protocol and port were affected.

To keep error messages from triggering more error messages, ICMP never reports errors about ICMP error messages themselves, about broadcast or multicast datagrams, or about fragments other than the first.

ping

The ping program sends ICMP echo requests (type 8) to a target host, which answers with echo replies (type 0) that carry back the request's identifier and sequence number. Ping measures the round-trip time (RTT) of each request and finishes with statistics, including the loss rate and the average of the $n$ received RTTs:

PING 203.0.113.7: 56 data bytes
64 bytes from 203.0.113.7: icmp_seq=0 ttl=60 time=20.4 ms
64 bytes from 203.0.113.7: icmp_seq=1 ttl=60 time=21.9 ms
Request timeout for icmp_seq 2
64 bytes from 203.0.113.7: icmp_seq=3 ttl=60 time=22.5 ms
--- 203.0.113.7 ping statistics ---
4 packets transmitted, 3 packets received, 25.0% packet loss
round-trip min/avg/max = 20.4/21.6/22.5 ms

The RTT includes propagation delay, processing delay, and queuing delay in every queue along the way (see Section 1.3). RTTs that vary noticeably between measurements usually indicate a queue somewhere on the path that keeps changing; losses may mean a queue has overflowed. Some hosts and firewalls are configured not to answer ping, so a missing reply does not necessarily mean the host is unreachable.

How traceroute Works

Chapter 1 used traceroute to observe the path that datagrams take. It is built from TTL and ICMP:

1. The source sends a series of UDP datagrams to an unlikely destination port (usually starting at 33434). The first datagram has TTL 1, the second TTL 2, and so on.
2. When datagram $n$ reaches router $n$, its TTL drops to 0. The router discards it and returns an ICMP TTL-expired message (type 11, code 0) to the source. The source address of that message is the router's IP address.
3. The source records the time from sending the datagram to receiving the ICMP message: the RTT to that router.
4. When a datagram finally reaches the destination host, it does not expire. But no process uses that port, so the destination returns an ICMP port-unreachable message (type 3, code 3). On receiving it, the source knows it has arrived and stops.

Traceroute usually sends three probes per TTL, so each line shows three RTTs. If no reply arrives before the timeout, it prints *. The probe may have been lost, or the router may be configured not to send ICMP messages. As long as later hops still answer, the path is not broken. Windows tracert uses ICMP echo requests instead of UDP datagrams and receives an echo reply from the destination.

 1  192.168.1.1     1.2 ms   1.1 ms   1.3 ms
 2  100.64.0.1      8.4 ms   8.9 ms   8.1 ms
 3  * * *
 4  203.0.113.1    35.2 ms  34.8 ms  36.1 ms
 5  198.51.100.20  33.9 ms  34.1 ms  33.7 ms