Echo and its limits

An Echo response preserves the request data; the absence of a response is an uncertain diagnostic outcome.

• Type 128 Echo Request and Type 129 Echo Reply both have Code 0, a 16-bit Identifier, a 16-bit Sequence Number and zero or more data octets (§§4.1–4.2). Identifier and sequence may be zero. No Echo-specific data maximum is imposed here; IPv6 packet constraints still apply.
• Every node MUST implement an Echo responder; a diagnostic request/reply interface SHOULD also be implemented (§§4.1–4.2). An Echo Reply copies Identifier/Sequence and MUST return the entire request data unmodified. The checksum must be calculated for the new reply, rather than copied from the request.
• For a unicast request to one of the node’s addresses, the reply source MUST equal that request’s destination. A multicast/anycast Echo Request SHOULD elicit a reply, with a unicast source belonging to the receiving interface (§4.2). The reply destination is the request source, not the multicast group.
• Echo Reply messages MUST pass to the process that originated an Echo Request and MAY pass to other processes. Echo Requests MAY pass to processes receiving ICMP messages (§§4.1–4.2). Identifier/Sequence aid correlation but are not an authentication credential.
• The no-reply picture uses a locally chosen diagnostic waiting interval, not a timeout specified by RFC 4443. Loss, policy, path changes or unavailable peers can leave an exchange unanswered. Neither a reply nor a missing reply proves a particular web service works or fails.
• §5.2 discusses spoofed and malicious control messages. Do not treat a syntactically valid checksum or a matching Echo number as cryptographic identity. This guide does not supply firewall rules, Path MTU Discovery’s full algorithm or Neighbor Discovery.