Internet Control Messaging Protocol
Yesterday I wrote about RFC 791, but I didn’t mention how errors get handled or reported.
Any conforming implementation of Internet Protocol must support its companion, the Internet Control Message Protocol. Defined in RFC 792, ICMP provides a very lightweight mechanism for error reporting.
In essence, ICMP defines messages that are sent back to the source of a packet that fails delivery. These messages use the standard IP header format but contain specific data fields that define their purpose. The spec describes a dozen or so message types, but several of these have been deprecated. Some of the most notable types in active use are:
- Destination Unreachable (Type 3): Sent when a packet cannot reach its destination.
- Echo Request (Type 8) and Echo Reply (Type 0): Used by tools like
ping
to check network connectivity. - Time Exceeded (Type 11): Indicates that the packet time-to-live (TTL) has expired.
A good example of how the Time Exceeded message can be used is
traceroute
, which sends packets with successively increasing TTL
values in order to probe the route(s) taken to a host. For example,
when I run:
1traceroute 8.8.8.8
I get the following output:
traceroute to 8.8.8.8 (8.8.8.8), 64 hops max, 40 byte packets
1 192.168.1.1 (192.168.1.1) 5.796 ms 4.522 ms 6.533 ms
2 * * *
3 lag-62-10.dtr02psdnca.netops.charter.com (96.34.102.37) 13.634 ms 13.846 ms 11.718 ms
4 lag-30.crr03rvsdca.netops.charter.com (96.34.97.154) 18.296 ms 19.656 ms 26.183 ms
5 lag-811.bbr01rvsdca.netops.charter.com (96.34.3.18) 15.703 ms 19.682 ms 16.463 ms
6 lag-801.prr01lsanca.netops.charter.com (96.34.3.129) 16.699 ms 19.619 ms 16.894 ms
7 sar02sghlga-eth-2-1.sghl.ga.charter.com (96.34.1.69) 18.305 ms
72.14.219.250 (72.14.219.250) 17.759 ms 17.314 ms
8 * * *
9 dns.google (8.8.8.8) 20.087 ms 19.610 ms 17.278 ms
Here I see various intermediate nodes from my ISP all the way to Google’s DNS server. The asterisks here mean that there was no response. These nodes likely limit or disable ICMP responses.