ICMP (Internet Control Message Protocol)

What it is (Definition)

ICMP is a companion protocol to IP used for control, diagnostics, and error reporting. Rather than carrying application data, ICMP messages provide feedback about IP delivery: whether a destination is reachable, whether a packet’s TTL expired, or whether a router could not forward a packet because of a problem on the path. Tools like ping and traceroute rely heavily on ICMP.

From a protocol design point of view, ICMP sits next to IP as part of the error and control “side channel”: it reports on what happened to other packets, instead of transporting user data itself. ICMP messages are usually generated automatically by network devices and hosts in response to events, rather than being sent directly by applications.

Even though ICMP is not “reliability” in the TCP sense, it is essential for network health. When ICMP is blocked too aggressively, troubleshooting becomes harder, and in some cases normal functions like Path MTU Discovery can break in subtle ways. On the other hand, allowing all ICMP blindly can expose unnecessary information about your network, so a balanced approach is needed.

Where it sits in the stack (Layer & usage)

L3 (control) ICMP is typically considered part of the network layer ecosystem.

Runs over: IPv4 (ICMPv4). (IPv6 uses a related but distinct protocol: ICMPv6.)
Works with: Routers and hosts to signal reachability, errors, and timing.
Where used: Diagnostics (ping/traceroute), error feedback, PMTUD support, operational monitoring.
Direction: Often flows “backwards” compared to the traffic that triggered it, making it useful for understanding the return path and intermediate devices.

In packet captures, ICMP often appears “in response” to something else: a UDP probe in traceroute, a TCP packet that triggered a TTL expiration, or a large packet that required fragmentation but couldn’t be forwarded. For that reason, you often analyze ICMP side by side with the original flow to understand the full story.

Administrators frequently rate-limit ICMP on routers and firewalls. This is useful for preventing abuse, but excessive rate limiting can make tools like ping and traceroute appear unreliable, even when the underlying application traffic is perfectly fine.

Header overview (Fields at a glance)

ICMP messages are identified by Type and Code. The rest of the header depends on the message category: Echo Request/Reply includes an identifier and sequence; error messages often include a quote of the original IP header (and part of its payload) to help the sender match the error to the triggering packet.

Conceptually, you can think of the ICMP header as: a small fixed part that describes what kind of message this is, and a flexible part that carries context. The quoted original packet is especially important when multiple flows are active, because it lets the sender know exactly which connection or probe caused the error.

Field	Size	Purpose	Common values / notes
Type	1 byte	Main message category	Echo Request/Reply, Destination Unreachable, Time Exceeded
Code	1 byte	Subtype within Type	e.g., “port unreachable”, “fragmentation needed”, “TTL exceeded”
Checksum	2 bytes	Integrity of ICMP message	Validated by receiver
Rest of header	variable	Type-specific fields	Echo: Identifier/Sequence; Errors: additional info
Quoted original packet	variable	Helps correlate error to traffic	Often includes original IP header + first bytes of payload

How it works (Typical flow)

Three common ICMP-driven flows:

Ping: A host sends ICMP Echo Request to a target IP address; the peer responds with Echo Reply. Round-trip time is measured between sending the request and receiving the reply. Multiple pings let you see jitter, packet loss, and basic reachability over time.
Traceroute: Probes are sent with low TTL values, starting at 1 and increasing. Each router that decrements the TTL to zero sends an ICMP Time Exceeded message back. By correlating the TTL value with the responding router, traceroute rebuilds the path hop by hop.
Error feedback: A router or host detects an issue (unreachable network, blocked port, MTU issue) and sends an ICMP error message back to the original sender. The sender inspects the quoted packet to understand which flow was affected and may adjust behavior (for example, lowering MTU).

Correlation: Error ICMP often includes a snippet of the triggering packet so the sender can match it.
Asymmetry: ICMP may take a different return path, so latency/visibility can differ from the forward traffic.
Policy interaction: Security policies might treat ICMP differently from TCP/UDP, so you always need to compare ICMP behavior with how the actual application traffic is handled.

In day-to-day operations, you typically do not “configure ICMP” directly in applications; instead you rely on the network stack and infrastructure devices to generate and interpret these messages correctly. When something goes wrong, having a basic mental model of these flows is critical for troubleshooting.

How it looks in Wireshark

Display filter example:

icmp

What you typically see:

Type/Code decoded into friendly text (e.g., “Destination unreachable (Port unreachable)”).
For Echo: Identifier and Sequence fields, which let you follow individual ping requests and replies.
For errors: “Original IP” section showing the quoted header and ports/protocol if available.
In the packet list, ICMP frames often appear in a different color compared to TCP/UDP, making them easy to spot in mixed captures.

Quick read tip: When debugging traceroute-like behavior, filter on icmp.type == 11 (Time Exceeded) and check the quoted original destination to confirm which probe triggered each hop response. When analyzing MTU problems, filters that focus on Destination unreachable (Fragmentation needed) help you spot where along the path packets are being rejected.

Common issues & troubleshooting hints

1) Ping works, application doesn’t (or the reverse)

Symptom: ICMP Echo succeeds but TCP/UDP connections fail, or ICMP is blocked while applications still work. Users may report that “ping is fine, but the web page never loads” or that monitoring systems show packet loss even though the service itself is reachable.
Likely cause: Firewall policy treats ICMP differently from application traffic, allowing one while restricting the other. In some environments, ICMP is fully allowed but only specific TCP/UDP ports are permitted; in others, ICMP is heavily filtered even though application ports are open.
How to confirm: Compare captures: Echo Request/Reply vs the target TCP/UDP flow. Look for resets, timeouts, or silent drops on the application ports while ICMP continues to succeed. On border firewalls, review rules to see whether Echo, Time Exceeded, and Destination Unreachable are handled differently than web or VPN ports.

2) PMTUD failures / “black hole” links

Symptom: Small traffic works but large transfers stall; TLS handshakes may hang intermittently or only some sites break. Users may be able to open a login page but fail when uploading files or loading content-heavy dashboards.
Likely cause: ICMP “Fragmentation needed” (or Packet Too Big in IPv6) is blocked or rate-limited, preventing Path MTU Discovery from adjusting segment size. Intermediate devices might drop these ICMP errors because of overly strict security policies or misconfiguration.
How to confirm: Look for repeated TCP retransmissions with no progress, MSS that is too large for the path, and an absence of matching ICMP errors in the capture. Testing with a smaller MTU on the endpoint can temporarily “fix” the issue and strongly suggests that PMTUD is failing somewhere along the path.

3) Traceroute stops early

Symptom: Traceroute shows a few hops and then only “* * *” for the remaining hops. Other tests may show that the destination is still reachable, so the missing hops are confusing for operators.
Likely cause: Routers or firewalls on the path rate-limit or block ICMP Time Exceeded messages, or treat the probe transport (UDP/TCP/ICMP) differently after a certain hop. Some networks intentionally block traceroute to hide internal topology while still allowing actual application traffic.
How to confirm: Capture on the source side, verify that probes continue to be sent with increasing TTL, and check whether any ICMP Time Exceeded or related responses return from further hops. Comparing different traceroute methods (ICMP/UDP/TCP) can also reveal policy differences and help you identify which device is performing the filtering.

Security notes (if relevant)

ICMP can be used in scanning, reflection, or signaling attacks, so networks often rate-limit or filter some types. The key is balance: blocking all ICMP may reduce visibility and can break legitimate mechanisms. A common approach is to allow essential ICMP (errors, PMTUD-related messages) while rate-limiting or restricting echo in exposed zones.

In hardened environments, you may see policies like “no echo from the Internet, but allow Destination Unreachable and Packet Too Big back to servers.” From a troubleshooting point of view, documenting which ICMP types and codes are allowed through each security zone can save a lot of time when chasing intermittent connectivity problems.

Related pages (internal links)

Back to Dictionary Index
Key fields (Field Index) — planned: ICMP type/code (Soon), ICMP echo id/seq (Soon)
Related topics (Topic Index) — planned: Ping vs reachability (Soon), PMTUD explained (Soon)