38

It is stated in Wikipedia that

an IPv6 header does not include a checksum.

What are the reasons that were behind this decision?

Improve this question
1

3 Answers 3

Reset to default
56

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.

Improve this answer
11
  • 2
    And even in IPv4, the UDP checksum is strongly recommended. RFC 1122 says it has to default to enabled, and "The advisability of ever turning off UDP checksumming is very controversial." It's probably considered a design mistake that the original spec made it optional.
    – Barmar
    Jan 27, 2020 at 16:05
  • 2
    That is all true, but when you look at the networking tag on Stack Overflow, most of the programmers there that do things like raw sockets simply set it to 0 (disabled) and ignore any incoming CRCs. It appears to be too difficult for them to calculate the CRC.
    – Ron Maupin ♦
    Jan 27, 2020 at 16:26
  • 5
    Based on what I have seen on Stack Overflow, the guys programming network applications really do not understand networking, and that really scares me. No wonder we have so many vulnerabilities in network applications. It's OK if they are just learning, but some of them have some real stuff in production, and I would not run any of it, except I do not know the names.
    – Ron Maupin ♦
    Jan 27, 2020 at 16:30
  • 3
    Most questions on SO are from beginners, so it's hard to extrapolate. But I agree that programming seems to be an area where many people feel comfortable working without much formal education. Would anyone hire an architect who learned from Internet tutorials?
    – Barmar
    Jan 27, 2020 at 16:33
  • 3
    @RonMaupin Amen to that. I'm a sysadmin (with a programming background) and I need to support a large development department working on networked devices. Most programmers don't have a clue and are outright dangerous. Most can't even configure the network settings of their own computer properly. You wouldn't believe how many times I have said "No, the DHCP server isn't broken. Don't set your laptop to static IP."
    – Tonny
    Jan 27, 2020 at 23:09
27

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.

Improve this answer
2
  • Shifting responsibility up a layer, more or less.
    – Andrew
    Jan 28, 2020 at 18:10
  • 3
    @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
1

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.

Improve this answer
2
  • 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
  • PPP already handled checksumming, only SLIP would've been an issue.
    – rsaxvc
    Dec 1, 2022 at 17:53

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge that you have read and understand our privacy policy and code of conduct.

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