It is stated in Wikipedia that

an IPv6 header does not include a checksum.

What are the reasons that were behind this decision?


3 Answers 3


One of the ideas around IPv6 was to speed up packet forwarding. To that end, several decisions were made. For example, the IPv6 header was greatly simplified and is a fixed length, unlike the variable length IPv4 header. Also, you cannot fragment IPv6 packets along the path, the way you can for IPv4, because packet fragmentation is resource intensive.

Not having a checksum in the IPv6 header means that an IPv6 router does not need to recalculate the checksum to see if the packet header is corrupt, and recalculate the checksum after decrementing the hop count. That saves processing time and speeds up the packet forwarding. The logic is that the layer-2 and layer-4 protocols each already have a checksum. The layer-2 checksum covers the entire IPv6 packet, and the layer-4 checksum covers the transport datagram.

Where UDP has an optional checksum for IPv4, it is required for IPv6.

  • Comments are not for extended discussion; this conversation has been moved to chat.
    – Ron Maupin
    Jan 28, 2020 at 21:12
  • That chat link gives me a 404
    – nog642
    Oct 27, 2021 at 15:37
  • It works for me. You have something else going on.
    – Ron Maupin
    Oct 27, 2021 at 15:40
  • 1
    The IPv6 header is a fixed size of 40 octets, unlike the IPv4 header that can be anywhere from 20 to 60 octets. It takes extra code and time to determine the IPv4 packet header size. The IPv6 extension headers are only for the destination. The intermediate devices (routers), do not deal with the IPv6 extension headers (except for Option 0, but only if explicitly configured to examine that option if present). The code for IPv6 routing is faster than for IPv4 because it can just deal with a fixed-size header.
    – Ron Maupin
    Apr 26 at 12:24
  • 1
    @AlokMaity, "Extension headers (except for the Hop-by-Hop Options header) are not processed, inserted, or deleted by any node along a packet's delivery path, until the packet reaches the node (or each of the set of nodes, in the case of multicast) identified in the Destination Address field of the IPv6 header." Also, "NOTE: While [RFC2460] required that all nodes must examine and process the Hop-by-Hop Options header, it is now expected that nodes along a packet's delivery path only examine and process the Hop-by-Hop Options header if explicitly configured to do so."
    – Ron Maupin
    Apr 26 at 12:28

Because it's redundant.

All the common link-layer protocols, like Ethernet or WiFi, have their own error checking and error correction mechanisms, so physical transmission errors are already unlikely.

What's left are logic errors in the packet itself. But almost all transport protocols based on IPv6, like TCP or UDP, also have error checking to catch logical errors. And these checksums often cover parts of the IP header as well, even though those aren't technically part of the transport layer segment (like source and destination address).

So what's the worst that could happen if an IPv6 router tries to route a corrupted packet? The packet will either not get routed at all, because the header contains invalid values or the destination address doesn't exist, or the address is a valid one (which might or might not be the intended one), so it will arrive at a destination, which will then discard it because the transport layer checksum doesn't add up. A bit of bandwidth got wasted, and that's it. And that is a scenario which doesn't really happen all that often. So it's simply not worth the additional CPU load you need on IPv6 switches to calculate the checksum for every single packet they route.

  • Shifting responsibility up a layer, more or less.
    – Andrew
    Jan 28, 2020 at 18:10
  • 2
    @Andrew: yeah, but the checksum calculation in UDP, TCP and DCCP over IPv4 already included the source and destination addresses. ICMP had a separate checksum algorithm, but it was only a small step to change this algorithm in ICMPv6 and drop the now effectively superfluous IP header checksum. The only IP-based layer 4 protocol I know that has a checksum which doesn't cover the src/dest addresses is SCTP.
    – cg909
    Jan 29, 2020 at 19:36

I read somewhere before, from someone who knew the thought process that went into this decision: IPv4 headers have a checksum, whereas IPv6 headers don't, because by the time it came to designing IPv6, networking technology in general had improved so much (much fewer errors, etc., and besides, even the rare errors that did occur, could be caught by checksums at other layes) so that the benefits of including a checksum in the IPv6 header were minimal.

Each field that would be added to the IPv6 header would add additional overhead to a header that was already larger than the IPv4 header, given that IPv6 addresses are longer than IPv4 addresses. For something that was of minimal benefit, it was considered not necessary.

  • Actually, prior to 1995, when IPv6 was published, IPv6 was being developed, and analog modem dial-up was the rule. WAN technology was still very primitive and error-prone. It may have been that the IPv6 designers could anticipate that IPv6 would be delayed so long that network technology would get better, but I doubt it because they wanted it to be adopted right away since the Internet was going commercial in 1995.
    – Ron Maupin
    Mar 31, 2021 at 16:38

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.