RFC 4443 · March 2006 · A. Conta, S. Deering, M. Gupta
Internet Control Message Protocol (ICMPv6) for the Internet Protocol Version 6 (IPv6) Specification
Index fetched 2026-10-19 from rfc-editor.org
How it works
Built by hand from RFC 4443. Every arrow, step and field cites the RFC sentence it comes from, and an automated test checks each quote against the RFC text. Provisional: not yet reviewed by a maintainer. Help verify this visual
RFC 4443 §4.1 A node SHOULD also implement an application-layer interface for originating Echo Requests and receiving Echo Replies, for diagnostic purposes.
1. Sender → Echo responder: Echo Request
A sends an Echo Request (Type 128). Every node must have an Echo responder that answers it.
RFC 4443 §4.1Every node MUST implement an ICMPv6 Echo responder function that receives Echo Requests and originates corresponding Echo Replies.
2. Echo responder → Sender: Echo Reply
B answers with an Echo Reply (Type 129). It copies the Identifier, Sequence Number and Data from the request, and sends it back to the request's source address.
RFC 4443 §4.2The data received in the ICMPv6 Echo Request message MUST be returned entirely and unmodified in the ICMPv6 Echo Reply message.
Quoted text consists of unmodified excerpts from RFC 4443, published by the IETF (line breaks reflowed). Copyright in the RFC text belongs to the IETF Trust and the persons identified as the document authors, as stated in the RFC. The diagrams and plain-English explanations are rfc-visual's own and do not replace the RFC.
Not shown: Error messages: Destination Unreachable, Packet Too Big, Time Exceeded, Parameter Problem (§3); Source address selection for ICMPv6 messages (§2.2); Checksum calculation and the IPv6 pseudo-header (§2.3); Message processing rules, including when not to send errors and rate limiting (§2.4); Echo Replies to multicast or anycast Echo Requests (§4.2); Security considerations (§5).
Lineage
Text
Loading the RFC text…