Introduction to ICMP
Every protocol in this module so far either carries application data (HTTP, SMTP, FTP) or sets up the addressing that data depends on (DNS, DHCP, ARP). None of them answer a much more basic question: when something goes wrong — a host unreachable, a packet that can't get where it's going — how does the network actually tell anyone?
Control messages, not user data
ICMP — Internet Control Message Protocol, defined for IPv4 in RFC 792 — carries diagnostic and error information about the IP layer itself, not application data. No application ever opens an "ICMP connection" the way it opens a TCP socket; ICMP messages are generated automatically, by routers and hosts, in response to conditions the IP layer itself needs to report.
That distinction shows up directly in how ICMP is addressed. TCP and UDP both use ports so a host can tell which application a piece of data belongs to — but ICMP has no ports at all, because it isn't addressed to an application in the first place. ICMP messages are wrapped directly in an IP packet, using IP protocol number 1, and delivered straight to the operating system's network stack rather than to any listening process on a specific port.
Message format: type, code, and a payload that depends on both
Every ICMP message shares the same opening structure, then diverges based on what it's actually reporting:
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Code | Checksum |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Rest of Header (type-specific) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Data |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type identifies the broad category of message; Code narrows it down within that type — Type 3 alone has over a dozen distinct codes, each meaning a different specific reason the destination couldn't be reached. The most common types a network engineer actually deals with:
| Type | Name | What it means |
|---|---|---|
| 0 | Echo Reply | Answer to a ping request |
| 3 | Destination Unreachable | The packet couldn't be delivered; the code says why |
| 5 | Redirect | A router telling a host a better route exists |
| 8 | Echo Request | A ping request |
| 11 | Time Exceeded | A packet's TTL hit zero before reaching its destination |
For error messages — Destination Unreachable and Time Exceeded among them — the Data field carries a copy of the original IP packet's header plus its first eight bytes of payload, exactly enough for whatever generated the original packet to identify which specific packet the error refers to. A host that sent several packets in quick succession, and gets one Destination Unreachable back, needs this copy to know which of those packets actually failed.
Two tools built entirely on top of ICMP
The rest of this module's ICMP coverage is two articles, each about a familiar command-line tool and the specific ICMP message types underneath it:
- ping — built on Echo Request and Echo Reply, Types 8 and 0.
- traceroute — built on Time Exceeded, Type 11, exploited deliberately via the IP TTL field.
Both tools are simple to run and easy to misread if you don't know what's actually happening at the ICMP level underneath — which is exactly what the next two articles cover in turn.
ICMPv6: the same idea, a bigger job
IPv6 has its own version, ICMPv6 (RFC 4443), and it isn't optional the way ICMPv4 sometimes is treated in practice — IPv6 relies on it for far more than diagnostics. The ARP article already flagged this: IPv6 has no ARP at all, and address resolution runs instead through ICMPv6 Neighbor Discovery messages. Blocking ICMPv6 wholesale on an IPv6 network, the way some firewalls block ICMPv4 by default, breaks basic address resolution on that network — a mistake with no equivalent on IPv4, where ARP is a fully separate protocol ICMP has no part in.