skip to content

In IPv4, what does an ICMP Destination Unreachable message tell the sender of a packet, and what does it not prove?

level: juniorimportance: must knowfreq 45%

answer

  1. one datagram, one reason
  2. the code field carries the why
  3. router or destination host
  4. a hint, not proof
  5. silence proves nothing either

basics

~10 s

An ICMP Destination Unreachable (type 3) says one IPv4 datagram was discarded before delivery and its code gives the reason. It does not prove the destination is down, and receiving none proves nothing either.

solid answer

~50 s

Destination Unreachable is ICMP **type 3**, sent back to the source of one datagram that a router or the destination host could not deliver. The code says why: `0` no route to the network, `1` host not reachable on its final network, `2` protocol not supported, `3` no listener on the port, `4` fragmentation needed with DF set, `5` source route failed, and RFC 1812's `13` for administrative filtering. Codes 0, 1, 4 and 5 normally come from routers; 2 and 3 from the destination itself. It is advisory: RFC 1122 says net, host and source-route unreachables may come from a routing transient and MUST be treated as a hint, not proof. And it is not guaranteed: routers may rate-limit ICMP errors and may discard filtered packets silently, so the absence of one says nothing about the path.

go deeper

for a junior

Recall that type 3 reports one dropped datagram and that its code gives the reason; know net, host, port and fragmentation-needed by name and number.

for a middle

Explain which codes routers generate and which the destination host generates, and how the ICMP packet's own source address therefore tells you where the datagram died.

for a senior

Show that you treat unreachables as hints: rate limits, silent filtering and routing transients mean neither an error nor its absence settles whether a destination is reachable.

for a principal

Weigh how much failure signal a network should return to senders against what it reveals and costs, and what clients must do when that signal is missing.

## What a Destination Unreachable message is **ICMP** (Internet Control Message Protocol, RFC 792) is the error-and-diagnostics companion of IPv4: a router or host that has to throw a datagram away can tell the datagram's sender why. **Destination Unreachable** is ICMP **type 3**. It is addressed to the **source address** of one specific datagram that could not be delivered, and its 8-bit **code** field names the reason. Two properties shape everything else: - It is about **one datagram**, not about a host or a network in general. The next datagram may take another route, or arrive after a listener has started. - It carries a copy of the dropped datagram's IP header plus at least the first 8 bytes of its payload (RFC 792). Those bytes cover the transport ports, so the sending host can hand the error to the conversation that caused it; RFC 1122 says a received Destination Unreachable MUST be reported to the transport layer. ## The codes | Code | Name | Typically generated by | Defined in | |---|---|---|---| | 0 | Net unreachable | a router with no route to the destination network | RFC 792 | | 1 | Host unreachable | a router that cannot reach the host on its directly connected network (for example, no ARP answer) | RFC 792 | | 2 | Protocol unreachable | the destination host: the transport protocol is not supported | RFC 792 | | 3 | Port unreachable | the destination host: no listener, and the transport has no signal of its own | RFC 792 | | 4 | Fragmentation needed and DF set | a router that would have to fragment but the Don't Fragment flag forbids it | RFC 792, extended by RFC 1191 | | 5 | Source route failed | a router that cannot follow a source-route option | RFC 792 | | 13 | Communication administratively prohibited | a router discarding because of a filter | RFC 1812 | RFC 1122 added codes 6 to 12 (destination network or host unknown, source host isolated, two older administrative-prohibition codes, and type-of-service variants), and RFC 1812 added 14 and 15 for precedence. Most of these are rarely seen; RFC 1812 even tells routers not to generate code 6 or code 8 and to use 0 or 1 instead. ## Who sends it, and why that matters RFC 792 says it plainly: codes 0, 1, 4 and 5 may be received from a gateway (a router), codes 2 and 3 from a host. Because an ICMP message travels in its own IP datagram, its **source address** is the device that generated it. So the reply itself locates the failure: 1. A **port unreachable** from the address you were trying to reach means the packet arrived and the host is up; nothing was listening on that port. 2. A **net or host unreachable** from some other address means a router on the path gave up; the destination may never have seen anything. 3. A **fragmentation needed** from a router means the path is working but a link on it is smaller than your datagram. ## What it does not prove - **Not that the host is down.** A port unreachable is evidence that the host is up. - **Not that a network is gone.** RFC 1122: codes 0 (net), 1 (host) and 5 (bad source route) may result from a routing transient and MUST be interpreted only as a hint, not proof, that the destination is unreachable; they MUST NOT be used as proof of a dead gateway. - **Not that every packet will fail.** It reports one datagram's fate at one moment. - **Not that it is genuine.** ICMP errors are not authenticated; anyone who can construct a plausible quoted header can send one, which is why transports check them before acting. ## When no message comes back Silence is ordinary, and it is not evidence that the path is healthy: 1. RFC 792 says a router *may* send the message, and RFC 1812 says routers SHOULD be able to **rate-limit** the ICMP errors they generate. 2. RFC 1812 requires a router's filtering to allow packets to be **silently discarded**, without any ICMP error. 3. RFC 1122 forbids sending an ICMP error about an ICMP error, about a datagram sent to a broadcast or multicast address, or about a non-initial fragment. 4. The error is itself an unreliable datagram: it can be lost or filtered on its way back. So a careful client treats an unreachable as useful information about where and why one datagram died, and treats its absence as no information at all; its own timeouts still decide when to give up. ## IPv6 is a different message ICMPv6 (RFC 4443) has its own Destination Unreachable, **type 1**, with its own code numbers (port unreachable is code 4 there), and "too big" is a separate message, **Packet Too Big**, type 2. IPv4 numbers do not carry across.

  • Why does RFC 1812 tell IPv4 routers not to send code 6, destination network unknown?
    Code 6 would claim the destination network does not exist, and a router cannot know that: it only knows it has no route right now. RFC 1812 says code 6 SHOULD NOT be generated and net unreachable, code 0, SHOULD be used instead. The same caution runs through RFC 1122, which treats net and host unreachables as hints rather than proof.
  • Does an ICMP Destination Unreachable reach the application that sent the failed packet?
    It reaches the sending host's IP layer, which MUST report it to the transport layer (RFC 1122). UDP MUST pass ICMP errors up to the application layer; TCP acts on them by its own soft-error and hard-error rules. Whether and when a program actually sees the error depends on the host's socket interface, which is an implementation matter, not part of ICMP.

saying these in an interview costs you the question

  • Destination Unreachable always means the remote server is down.
  • If no ICMP error comes back, the path to the host must be working.
  • Every router must send an unreachable for every packet it drops.
  • A net unreachable proves the destination network no longer exists.
  • Port unreachable is sent by the last router before the server.