Read the control message
01ICMPv6 is the Internet Control Message Protocol for IPv6. Its messages report packet-processing problems and support diagnostics. They are IPv6 payloads, not TCP or UDP messages on a port.
One changed data bit no longer matches the old checksum. Recalculating a checksum would pass the arithmetic check, so a valid checksum is not proof of who sent the message.
Source for this drawing: RFC 4443 · Read RFC section 2.1 ↗
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.
Type selects the message; the checksum covers the message plus selected IPv6 fields, but does not authenticate a sender.
- ICMPv6 is integral to IPv6. Every IPv6 node MUST fully implement the base protocol required by RFC 4443 (§2). Neighbor Discovery and other documents define additional types; this guide covers the four base errors and Echo, not every current registry entry.
- The immediately preceding IPv6 or extension header identifies ICMPv6 with Next Header 58. The common header has an 8-bit Type, 8-bit Code and 16-bit Checksum. Type determines the body and Code refines that type (§2.1). No TCP/UDP port is involved.
- Type values 0–127 are the error class; 128–255 are informational. This classification does not mean every value is assigned. RFC 4443 defines errors 1–4 and Echo 128/129 (§2.1). Registry allocations may grow without replacing this RFC.
- For checksum generation, zero the checksum field. Sum the entire ICMPv6 message with the IPv6 pseudo-header, then take the 16-bit one’s complement (§2.3). The pseudo-header includes source/final-destination addresses, upper-layer length and Next Header 58; it is calculation input, not an extra transmitted header (RFC 8200 §8.1).
- A checksum detects corruption, not hostile forgery. An attacker can recalculate it. §5 discusses attacks and IPsec protection, and recommends upper layers validate quoted errors before acting. This drawing is not a complete IPv6/IPsec validation algorithm.
Fictional addresses 2001:db8::1 and 2001:db8::2; no extension/routing header in the checksum example.
Read the RFC section ↗