Recognize the four base errors
03The first four ICMPv6 Types describe different failures: unreachable destination, an oversized packet, an expired Hop Limit or reassembly timer, and a bad header field. Their bodies carry different evidence.
Separate RFC example: Pointer 40 identifies the Next Header field in the first extension header, after the 40-byte base IPv6 header. It is not offset 40 inside the returned ICMP message.
Source for this drawing: RFC 4443 · Read RFC section 3 ↗
New to this? Start hereA quick picture + helpful background
A message needs an address.
Think of a packet as a small addressed envelope. Devices pass it onward; transport protocols decide what delivery promises an application gets.
Helpful first, if these ideas are unfamiliar
These pictures are analogies to help you learn. The linked RFC explains the actual rules.
Terms in this drawing
Related RFCs and changes
“Updates” changes part of an earlier RFC. “Obsoletes” replaces it. This list shows selected related documents.
Put the error at the failing hop and return its specific Type, Code and evidence.
- Destination Unreachable is Type 1. Codes 0–6 in this RFC mean no route, administratively prohibited, beyond source scope, address unreachable, port unreachable, source-policy failure, and reject route. A router/originating IPv6 layer SHOULD generate it for nondelivery other than congestion; MUST NOT generate ICMPv6 for a congestion drop (§3.1). Code 4 SHOULD report no listener when the transport has no alternative way to inform the sender.
- Type 2 Packet Too Big MUST be sent by a router that cannot forward because the packet exceeds the outgoing-link MTU (§3.2), subject to §2.4 suppression/rate precedence. MTU is a 32-bit next-hop link size; Code is sent as zero and ignored by the receiver. This enables, but does not fully specify, Path MTU Discovery. IPv6 routers do not fragment transit packets (RFC 8200 §5).
- Type 3 Time Exceeded Code 0 reports Hop Limit zero on receipt or after decrement: the router MUST discard and originate the error (§3.3), subject to §2.4. It is not a seconds timer. Code 1 separately reports fragment reassembly timeout; do not confuse the two.
- Type 4 Parameter Problem uses Code 0 for an erroneous header field, 1 for unrecognized Next Header, and 2 for an unrecognized IPv6 option. A node unable to complete processing MUST discard and SHOULD originate this error (§3.4), subject to §2.4. Its 32-bit Pointer is an octet offset from the start of the original IPv6 packet, not the start of the ICMP message.
- The RFC’s Type 4 / Code 1 / Pointer 40 example points to the unrecognized Next Header field in an extension header immediately following the 40-byte IPv6 header (§3.4). A pointer can lie beyond the included quote if the original error field is too far into the packet.
- Unused fields in base Type 1/3 are sent as zero and ignored on receipt; selected fields are updated by RFC 4884. §3.1 also forbids bouncing a packet back onto its arrival point-to-point link in the stated same-subnet case (Code 3), and says implementations SHOULD allow Destination Unreachable sending to be disabled. These are not successful-forwarding arrows.
The four states are separate fictional packets. Ordinary unicast sources and available error-rate credit are assumed.
Read the RFC section ↗