Reporting rather than guaranteeing recovery

IP does not guarantee delivery. ICMP can report unreachable destinations, exceeded lifetime or parameter problems, helping endpoints interpret forwarding failures.

It is not an ordinary application message carried on a TCP or UDP port and does not itself retransmit missing data successfully. Reliable upper layers still need their recovery and timeout behavior.

Error feedback must identify the affected communication. An ICMPv6 error quotes part of its invoking IPv6 packet so the receiver can identify the relevant upper layer; truncation, for example after long extension headers, can make that impossible. An ICMPv6 error must not itself trigger another ICMPv6 error, preventing error recursion. This rule concerns error messages rather than declaring every informational message, such as echo, ineligible for any feedback.

References: [1] [2] [5]

Echo probes and packet size

Echo requests and replies carry identifiers, sequence numbers and returned data to match probes. A reply establishes that exchange, not the health of every application on the same host.

ICMPv6 Packet Too Big reports that a packet exceeds a next-hop link’s MTU. This is important feedback for path-size discovery, distinct from echo probing.

References: [1] [2]

Limits and protocol evolution

Control traffic consumes resources, and routers can limit generation rates. A missing reply can reflect loss, filtering or rate limits rather than proving the destination has stopped.

Source Quench once supplied congestion hints, but RFC 6633 formally deprecated it. Explanations of ICMP must distinguish current error feedback from historical message types.

References: [3] [4]