ICMP

If a packet was sent and never arrived, how does the sender know what went wrong? “No response” is not enough. It cannot distinguish between a broken path, expired TTL, unreachable destination, or a destination port with nothing listening. IP deliberately does not do that kind of reporting. It forwards best effort and does not explain failure.

ICMP handles the layer where the network talks to the network about what happened. It is not a business-data protocol, but it carries error feedback, reachability probes, path exposure, and some control signals. Without it, many troubleshooting judgments collapse from “know where it broke” to “guess where it broke.”

ICMP does not exist to carry application data. It exists to give IP a limited but essential feedback channel

Why It Appears

IP has a very clear boundary:

• It handles addressing and forwarding
• It does not guarantee delivery
• It does not explain why failure happened

That makes IP scalable, but it also creates a practical problem: once a packet cannot move forward, the source host has no way to know whether the failure was at the path, the hop, the destination, or the MTU boundary.

ICMP exists exactly for that:

• When a router or host detects a network-layer problem, it can report it back
• When the sender wants to probe reachability or path behavior, it can use dedicated ICMP types

It does not turn IP into a reliable protocol. It adds the feedback boundary that best-effort networks still need.

The Background It Came From

ICMP comes from the early Internet protocol stack and sits in the network-layer context alongside IP. It was never designed to carry application sessions. It was designed to carry control and error notification between hosts and routers.

That gives it a very specific character:

• It is an attached companion to IP, not a separate transport layer like TCP or UDP
• It does not use ports to separate business traffic
• Many of its messages are strongly diagnostic or control-oriented
• It must not create a new error storm by feeding back endlessly

So ICMP looks broad in use, but its main line is actually narrow: letting the network explain itself when needed.

Grasp the Main Model First

To understand ICMP, first separate two kinds of messages:

• Error feedback: tells the source host why a packet could not continue
• Query and reply: lets the host actively probe reachability, latency, or path

You can compress the logic like this:

Data packet cannot continue
  -> Router / Host generates ICMP Error
  -> Source learns the failure reason

Source wants to probe actively
  -> Send ICMP Query
  -> Peer returns ICMP Reply

Those two paths together are what you usually see as ping, traceroute, destination unreachable, and TTL exceeded.

The Most Common Main Path

First, an error-feedback path:

Then a reachability probe:

The two look very different, but they share the same point: ICMP does not carry business data. It adds feedback or probes around the result of IP delivery.

Why Explanation of Failure Matters Most

If the network layer has no feedback, the source host only sees:

• Application timeout
• TCP retransmission
• Long periods with no response

Those signals are too vague. ICMP compresses the failure into more specific signs such as:

• Destination Unreachable
• Time Exceeded
• Fragmentation Needed

That tells you directly:

• Was the path broken
• Was the TTL too small
• Was the MTU wrong
• Or was the destination port simply not listening

That changes both implementation and troubleshooting.

Why ping Works, but Does Not Mean the Business Works

ping usually uses:

• Echo Request
• Echo Reply

It tests one very specific thing: whether the destination host or some middle network is willing to answer an ICMP echo.

That is useful, but the boundary must stay clear:

• If ping works, it does not mean TCP / HTTPS / the application service is available
• If ping fails, it does not necessarily mean the host is completely unreachable. It may just be blocking Echo

So ping is more like a minimal connectivity probe, not a universal health check.

Why traceroute Works

traceroute is not clever because it asks routers to report the path voluntarily. It uses IP TTL and ICMP Time Exceeded to force the path to reveal itself.

The logic can be compressed like this:

Each extra TTL lets the probe go one hop farther, and each router that decrements TTL to zero reports Time Exceeded. The path gets exposed hop by hop.

So traceroute is not “all routers report their path”. It is “TTL and ICMP are used to pull the path out one hop at a time”.

Why ICMP Also Exposes MTU Problems

Large packets that fail while small packets work are often an MTU problem on the path. ICMP matters here too.

If a link cannot carry the current packet and fragmentation is not possible, the device may report something like:

• Destination Unreachable
• Fragmentation Needed

That tells the source host the problem is not that the destination is down. The packet is just too large.

Without that feedback, the sender can only guess through timeout and retransmission. That is also why blocking too much ICMP often turns a problem from “diagnosable” into “just black-hole guessing”.

Why ICMP Cannot Feed Back Forever

If every error packet caused another ICMP error, and those errors kept causing more errors, the network would quickly drown in feedback.

So ICMP has to stay limited. Think of it as a bounded feedback channel:

• Feedback exists, but not as an infinite blame chain
• The feedback is enough for diagnosis, but not enough to create a storm

That is why ICMP is important in real networks, but it also has to be used carefully and rate-limited.

What to Look At First in Packet Capture

Do not start by memorizing every Type and Code. A better order is usually this.

First tell whether it is reporting a failure or probing reachability

Separate:

• Echo Request / Echo Reply
• Destination Unreachable
• Time Exceeded

That tells you whether you are looking at an active probe or the network’s explanation of failure.

Then tell who is explaining the failure

Many ICMP errors are not independent events. They are explanations for why the original IP packet failed. Ask:

• Which original packet is being answered
• Where the original packet was trying to go
• Which hop reported the error first

ICMP only becomes complete when it is tied back to the packet it explains.

Finally check whether ICMP was filtered, rate-limited, or distorted

ICMP is useful, but real networks do not always pass it fully:

• Some networks block Echo
• Some devices rate-limit error feedback
• Some paths make traceroute look like it stops in the middle

So “I did not see ICMP” does not automatically mean “the network has no problem”.

What Engineering Should Actually Think About ICMP Today

• Do not think of ICMP as “the ping protocol”. It is first of all the network layer’s feedback and probing channel
• Do not treat ping success as proof of application availability, and do not treat ping failure as proof that the host is dead
• Do not ignore Time Exceeded, Destination Unreachable, and Fragmentation Needed. They often carry more information than application timeout
• Do not treat ICMP as optional trivia. Many path and MTU problems can only be exposed accurately through it
• Do not forget that ICMP itself can be filtered, rate-limited, or weakened. Interpret what you observe against the real path

Further Reading

• IP - why ICMP always works around IP forwarding and reachability boundaries
• UDP - why many Destination Unreachable results map cleanly to UDP’s connectionless model
• TCP - how the network layer can explain failure beyond TCP retransmission and timeout
• NAT - why address rewriting and state timeout change the ICMP symptoms you see
• NDP - how many IPv6 local-link control messages moved into ICMPv6
• ARP - why a local first hop that is not resolved may keep upper-layer problems from ever reaching ICMP

References

• RFC 792 - Internet Control Message Protocol
• RFC 1122 - Requirements for Internet Hosts – Communication Layers
• RFC 1812 - Requirements for IP Version 4 Routers