skip to content

Which received IPv4 packets must never trigger an ICMP error, and what failure does each of those rules prevent?

level: middleimportance: should knowfreq 22%

answer

  1. errors about errors
  2. one packet, many receivers
  3. fragments after the first
  4. a source that is no single host
  5. these rules override all others

basics

~20 s

RFC 1122 and RFC 1812 forbid ICMP errors about an ICMP error, a broadcast or multicast datagram, a link-layer broadcast, a non-initial fragment, or a source that is not one host. Each rule stops loops, storms or useless replies.

solid answer

~50 s

RFC 1122 section 3.2.2 lists packets that MUST NOT trigger an ICMP error, and says the list overrides every other rule that would send one. **An ICMP error** never draws another, which prevents two devices bouncing errors forever. **A datagram to an IP broadcast or multicast address, or sent as a link-layer broadcast**, draws none, because one packet would provoke a reply from every receiver: the RFC's example is a broadcast UDP datagram to an unused port. **A non-initial fragment** draws none: it holds no transport header to quote, and the first fragment speaks for the datagram. **A source that is not one host** (zero, loopback, broadcast, multicast, Class E) draws none, since the reply has no sensible destination. RFC 1812 adds header-validation failures and silently discarded packets for routers. ICMP queries such as Echo are not errors, so they can still trigger one.

go deeper

for a junior

Recall the short list: no ICMP error about an ICMP error, about broadcast or multicast traffic, or about fragments after the first.

for a middle

Explain the failure behind each rule, the error loop, the broadcast storm, the useless fragment quote, and why a link-layer broadcast check is needed too.

for a senior

Separate the error-generation rules from rate limiting and from query handling, and spot a device that answers broadcasts or fragments when diagnosing a storm.

for a principal

Discuss how much safety a protocol should hard-code into every implementation versus leave to operator policy, using these precedence-over-everything rules as the example.

## Why ICMP needs rules about not speaking ICMP errors are generated **automatically**, by every router and host, in reaction to traffic they did not choose to receive. A mechanism like that can amplify itself: one bad packet can produce many errors, and errors can produce errors. RFC 1122 section 3.2.2 (hosts) and RFC 1812 section 4.3.2.7 (routers) therefore list the cases where an ICMP error **MUST NOT** be sent, and both state that "these restrictions take precedence over any requirement elsewhere" to send one. ## The list and the failure each rule prevents | Received packet | Why no error is allowed | |---|---| | An ICMP **error** message | Two devices could otherwise bounce errors about each other's errors without end | | A datagram to an IP **broadcast** or **multicast** address | One datagram reaches many receivers, and each would answer: a storm aimed at one sender | | A datagram sent as a **link-layer broadcast** (RFC 1812 adds link-layer multicast) | Catches broadcasts that carry a unicast IP destination by mistake | | A **non-initial fragment** (fragment offset nonzero) | No transport header to quote; the first fragment's error already covers the datagram | | A datagram whose **source is not a single host**: zero, loopback, broadcast, multicast or Class E | The error would go nowhere, back to the reporter itself, or to many hosts at once | | A packet failing header validation, or one specified to be **silently discarded** (RFC 1812, routers) | "Silently" means silently: no reply of any kind | ## The broadcast storm, concretely RFC 1122 explains the broadcast rule with a scenario worth retelling in an interview: 1. A host sends a UDP datagram to the subnet's broadcast address, for a port most machines do not use. 2. Every machine on the segment receives it, and every machine without a listener on that port would owe a port unreachable. 3. Hundreds of errors converge on one sender at the same instant. The RFC notes that on a large Ethernet the resulting collisions "can render the network useless for a second or more". Checking only the IP destination is not enough, because some hosts broadcast with a unicast IP destination. Both RFCs therefore require the link layer to tell IP when a frame arrived as a link-layer broadcast, and the receiver checks both. ## Fragments: why only the first one counts When IPv4 fragments a datagram, only the fragment with **offset 0** carries the transport header with the ports. An error about a later fragment would quote bytes from the middle of the payload, useless for matching, and a datagram split into many fragments could produce one error per fragment. Errors are therefore allowed only about the first fragment, which identifies the whole datagram. ## How a receiver applies the rules Before generating any error, a host or router effectively asks, about the packet it is about to complain about: - Is it itself an ICMP **error** (protocol 1, with a type on the error list)? - Was its IP destination a **broadcast or multicast** address, or did the link layer report a broadcast or multicast frame? - Is its **fragment offset** nonzero? - Is its **source** zero, loopback, broadcast, multicast or Class E? - Is it a packet the specification says to **discard silently**? Only when every answer is no may an error be generated, and even then a router's rate limit may still suppress it. ## What the rules do not cover - **Queries are not errors.** An Echo request is an ICMP query, so a router whose TTL check drops it may still send Time Exceeded about it. The rule bans errors about errors, not errors about all ICMP. - **Rate limits are separate.** RFC 1812 section 4.3.2.8 lets routers rate-limit the errors they are allowed to send; that is a policy on top of these rules, not part of them. - **Answering queries sent to broadcast addresses** is a separate question about query handling, not about error generation. ## Telling errors from queries Applying the first rule requires knowing which ICMP types are errors. RFC 1122 lists them: Destination Unreachable, Redirect, Source Quench (deprecated by RFC 6633), Time Exceeded and Parameter Problem. Everything else is a query. ICMPv4 carries no class bit, so the check is a lookup on the type value. ICMPv6 builds the distinction into the type number, with errors at 0-127, and RFC 4443 restates the same family of suppression rules for IPv6.

  • If ICMP errors are never sent about ICMP messages, how can a router send Time Exceeded about an expired Echo request?
    The rule is narrower than that: it bans errors about ICMP error messages, not about all ICMP. Echo is a query, so a router dropping an Echo request whose TTL ran out may send Time Exceeded about it. That is why RFC 1122 sorts the types into errors and queries; the receiver needs the class to apply the rule.
  • Why may the first fragment of an IPv4 datagram trigger an ICMP error when the later fragments may not?
    Only the first fragment, with offset 0, carries the transport header with the ports, so only its quote lets the sender find the socket. Later fragments would quote payload bytes that identify nothing, and errors about every fragment would multiply one failure into many messages. One error about the first fragment speaks for the whole datagram.

saying these in an interview costs you the question

  • A host should report a malformed ICMP error so its sender can fix it.
  • Each host given a broadcast UDP datagram for a closed port sends a port unreachable.
  • Every fragment of a dropped IPv4 datagram should get its own ICMP error.
  • No ICMP message can ever trigger an ICMP error, Echo requests included.
  • Checking the IP destination address alone is enough to detect a broadcast.