]> Cisco

De kleetlaan 6a Diegem BRABANT 1831 Belgium ayourtch@cisco.com

Internet Internet Area Working Group internet checksum Over the past four decades, the Internet checksum has been used by many protocols: IPv4, TCP, UDP, and others. The practical details related to calculation and updates are scattered across different RFCs. Several protocols introduce special-case handling for +0 and -0, thus making the term "Internet checksum" ambiguous. This affects any protocol implementation which modifies the data covered by any variant of the Internet checksum. This document provides the problem statement and outlines the scope for potential future work to build a consolidated source for the Internet checksum. If there is interest in such work, this document may be converted into that consolidated specification.

Introduction The Internet checksum computation was described in detail in 38 years ago as a 1's complement of the 16-bit 1's complement sum of all 16-bit words over the range the checksum covers, with the checksum field itself set to all-zero. The same document also defined the process of checksum verification being 1's complement sum across the area, the checksum field included. If the result is 0xffff (-0 in 1's complement arithmetic), the check is successful. Intermediate nodes, like routers, often need to update the fields covered by the checksum, and recomputing it from scratch every time is inefficient. Thus, the original document also describes the incremental checksum update mechanism. The initial formulation did not lend itself to efficient implementation. To address that, described a streamlined incremental checksum update process. However, the process described there can yield an updated header checksum of -0 (0xffff) when it should be +0 (0x0000). corrected this, but it was ambiguous in places. This resulted in an erratum, which was itself incorrect and triggered additional errata. 1's complement arithmetic has two representations of zero, +0 (0x0000) and -0 (0xffff), and this redundancy resulted in some protocols treating these values differently. For example, a correct IPv4 sender never computes a header checksum of -0 (0xffff) by construction, whereas UDP uses 0x0000 as a signal "checksum not computed", and requires the computed checksum of zero to be transmitted as 0xffff. Additionally, the rules for when the checksum computation can be skipped are different between UDP-over-IPv4 and UDP-over-IPv6: the latter allows it only for the outer UDP header of the tunneled traffic , . The rules in do not take these special cases into account, thus resulting in subtle bugs even in recent code. Some protocols opted to either make their updates checksum-neutral (e.g. , ), or allocate a "sacrificial field" whose sole purpose is to be updated when another part of the checksum-covered area changes (, , ). This is a useful design technique if the header layout is still open. It may also improve performance: the "sacrificial" checksum correction field can be placed next to the fields which have to be modified, and thus end up already in the processor cache. Also, some protocols opted to use entirely different checksum mechanisms. This document does not redefine any of the existing protocols.

Conventions and Definitions The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 when, and only when, they appear in all capitals, as shown here.

Proposed Scope and Contents Taking the above into account, and in stubborn defiance of the wisdom in , this document proposes to be a single reference for all matters related to the Internet checksum, collecting the various aspects of it into the following sections:

A Recap of Internet Checksum Calculation covers this at length, but a shorter version, focusing on incremental update and the +0/-0 properties, would be useful. This section would discuss how to verify the checksum, and why recalculating the checksum and comparing it with the received one can result in occasional spurious packet drops.

A Survey Of Special-Use Values A correct IPv4 sender never transmits 0xffff as its header checksum; UDP never transmits 0x0000 unless the checksum is disabled; UDP over IPv6 permits a zero checksum only when it is the outer protocol for tunneled traffic. Handling these special cases is a frequent source of bugs. This section would contrast how different protocols use the Internet checksum.

Incremental Update, Special Cases Included This section would refer to some of the available open source implementations as well as analyze the issues related to them. It would also demonstrate branch-free approaches to dealing with special-case values during the checksum calculation.

Methods to Avoid the Need to Update the Checksum During Protocol Design During protocol design, it might make sense to make any updates unnecessary by making the transformation checksum-neutral. This section would survey the existing protocols that make use of two techniques for this: defining the transform to be checksum-neutral, or allocating a special field so that a variable transform stays checksum-neutral.

Test Vectors and Example Code This section would include various examples and corner-case test vectors, intended to help verify the implementations.

Security Considerations The document does not (yet) have any security considerations.

IANA Considerations This document has no IANA actions.

References Normative References Informative References xkcd

Acknowledgments Thanks a lot to Martin Thomson for the inspiration to write this document and to Tim Chown for reviewing the pre-00 version.