RFC 6936

Applicability Statement for the Use of IPv6 UDP Datagrams with Zero Checksums

📅 published April 2013, from ietf

RFC 6936 💖 is an Applicability Statement for the Use of IPv6 UDP Datagrams with Zero Checksums, and bestie, it is a Standards Track doc, so this one is official ✨. It was written by G. Fairhurst from the University of Aberdeen and M. Westerlund from Ericsson, and it's dated April 2013. It's published under ISSN 2070-1721. The header doesn't list anything it obsoletes or updates, so it's standing on its own 🌸.

Abstract 🌸

okay so this doc is an applicability statement for using UDP transport checksums with IPv6 🦋. It lays out recommendations and requirements for IPv6 UDP datagrams that carry a zero UDP checksum, and it explains the issues and design principles you need to think about when UDP is used with IPv6 to support tunnel encapsulations. It also looks at the role the IPv6 UDP transport checksum plays, and it flags the problems and constraints you hit when a network path has middleboxes on it 👀. There's an appendix that sums up the trade-offs people weighed when they checked whether changing how RFC 2460 treats the UDP checksum with IPv6 was safe 💅.

Status of This Memo 📜

This is an Internet Standards Track document.

This doc is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It went through public review and got approved for publication by the Internet Engineering Steering Group (IESG). If you want more on Internet Standards, check out Section 2 of RFC 5741 🤓.

For the current status, any errata, and how to send feedback, go to http://www.rfc-editor.org/info/rfc6936 🔗.

Copyright Notice 🎀

This doc is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) as they stand on the publication date. Please actually read these, because they spell out your rights and restrictions for this doc 📖. Code Components pulled out of this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions, and they come with no warranty, as described in the Simplified BSD License 🧾.

Table of Contents 📖

   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  4
     1.1.  Document Structure . . . . . . . . . . . . . . . . . . . .  5
     1.2.  Terminology  . . . . . . . . . . . . . . . . . . . . . . .  5
     1.3.  Use of UDP Tunnels . . . . . . . . . . . . . . . . . . . .  6
       1.3.1.  Motivation for New Approaches  . . . . . . . . . . . .  6
       1.3.2.  Reducing Forwarding Costs  . . . . . . . . . . . . . .  6
       1.3.3.  Need to Inspect the Entire Packet  . . . . . . . . . .  7
       1.3.4.  Interactions with Middleboxes  . . . . . . . . . . . .  7
       1.3.5.  Support for Load Balancing . . . . . . . . . . . . . .  8
   2.  Standards-Track Transports . . . . . . . . . . . . . . . . . .  9
     2.1.  UDP with Standard Checksum . . . . . . . . . . . . . . . .  9
     2.2.  UDP-Lite . . . . . . . . . . . . . . . . . . . . . . . . .  9
       2.2.1.  Using UDP-Lite as a Tunnel Encapsulation . . . . . . . 10
     2.3.  General Tunnel Encapsulations  . . . . . . . . . . . . . . 10
     2.4.  Relationship of Zero UDP Checksum to UDP-Lite and UDP
           with Checksum  . . . . . . . . . . . . . . . . . . . . . . 11
   3.  Issues Requiring Consideration . . . . . . . . . . . . . . . . 12
     3.1.  Effect of Packet Modification in the Network . . . . . . . 13
       3.1.1.  Corruption of the Destination IP Address Field . . . . 14
       3.1.2.  Corruption of the Source IP Address Field  . . . . . . 15
       3.1.3.  Corruption of Port Information . . . . . . . . . . . . 16
       3.1.4.  Delivery to an Unexpected Port . . . . . . . . . . . . 16
       3.1.5.  Corruption of Fragmentation Information  . . . . . . . 18
     3.2.  Where Packet Corruption Occurs . . . . . . . . . . . . . . 20
     3.3.  Validating the Network Path  . . . . . . . . . . . . . . . 20
     3.4.  Applicability of the Zero UDP Checksum Method  . . . . . . 21
     3.5.  Impact on Non-Supporting Devices or Applications . . . . . 22
   4.  Constraints on Implementation of IPv6 Nodes Supporting
       Zero Checksum  . . . . . . . . . . . . . . . . . . . . . . . . 23
   5.  Requirements on Usage of the Zero UDP Checksum . . . . . . . . 24
   6.  Summary  . . . . . . . . . . . . . . . . . . . . . . . . . . . 27
   7.  Security Considerations  . . . . . . . . . . . . . . . . . . . 28
   8.  Acknowledgments  . . . . . . . . . . . . . . . . . . . . . . . 29
   9.  References . . . . . . . . . . . . . . . . . . . . . . . . . . 30
     9.1.  Normative References . . . . . . . . . . . . . . . . . . . 30
     9.2.  Informative References . . . . . . . . . . . . . . . . . . 30
   Appendix A.  Evaluation of Proposal to Update RFC 2460 to
                Support Zero Checksum . . . . . . . . . . . . . . . . 33
     A.1.  Alternatives to the Standard Checksum  . . . . . . . . . . 33
     A.2.  Comparison of Alternative Methods  . . . . . . . . . . . . 34
       A.2.1.  Middlebox Traversal  . . . . . . . . . . . . . . . . . 34
       A.2.2.  Load Balancing . . . . . . . . . . . . . . . . . . . . 35
       A.2.3.  Ingress and Egress Performance Implications  . . . . . 36
       A.2.4.  Deployability  . . . . . . . . . . . . . . . . . . . . 36
       A.2.5.  Corruption Detection Strength  . . . . . . . . . . . . 37
       A.2.6.  Comparison Summary . . . . . . . . . . . . . . . . . . 37

1. Introduction ✨

So UDP [RFC0768] is the transport defined for IPv4 [RFC0791], and it's also defined in "Internet Protocol, Version 6 (IPv6)" [RFC2460] for IPv6 hosts and routers 🌈. UDP has a super minimal feature set, and that's honestly why so many apps can use it 🦋. The catch is that those apps still have to provide plenty of important transport functions themselves 🫠. The UDP usage guidelines [RFC5405] give application designers the overall guidance, including how to use UDP to support tunneling 💜.

The big difference between UDP with IPv4 and UDP with IPv6 is that RFC 2460 basically mandates a calculated UDP checksum, meaning a non-zero value, because IPv6 doesn't have a header checksum of its own 😤. Including the pseudo-header in that checksum gives you a statistical check that the datagram reached the intended IPv6 destination node 🎯. If you want the math, the algorithms for checksum computation are described in [RFC1071] 🤓.

Not being able to send an IPv6 datagram with a zero UDP checksum turned out to be a real problem for certain apps, mainly tunnel apps 😭. That class of app was already running with a zero UDP checksum over IPv4 🙃. The IPv6 design brings up different safety questions about using a UDP checksum, and those questions can seriously affect apps 💀. This goes for the intended user and for an innocent bystander too, meaning a packet that ends up being received by a different endpoint than the one it was meant for 👀.

This doc identifies a set of issues that must be considered and mitigated so IPv6 apps that use a zero UDP checksum can be deployed safely 🔒. The appendix compares the strengths and weaknesses of a bunch of proposed solutions 📊. The comparison is also expected to be useful for apps with different goals than the ones that led to this doc, especially apps that can use existing standardized transport protocols 🧚. The analysis concludes that a zero UDP checksum is the best of the proposed alternatives for meeting the goals of certain tunnel apps 🏆.

This doc defines recommendations and requirements for using IPv6 datagrams with a zero UDP checksum 📝. Expect some early deployment headaches with middleboxes, which limit usability more than anyone would like on today's Internet 😩. The good news is this limitation is biggest at the start and will shrink as middleboxes get updated to support the zero UDP checksum for IPv6 🌸. So in this doc, we derive a set of constraints required to ensure safe deployment of a zero UDP checksum 🔐.

Last but not least, the doc points out some issues that need future consideration and maybe more research 🔭.

1.1. Document Structure 🗺️

Section 1 gives background on the key issues and introduces UDP as a tunnel transport protocol 🌷.

Section 2 describes a set of standards-track datagram transport protocols that may be used to support tunnels 🚇.

Section 3 discusses issues with a zero UDP checksum for IPv6. It covers the impact of corruption, the need to validate the path, and when it's suitable to use a zero UDP checksum 🧐.

Section 4 is an applicability statement that defines requirements and recommendations for the implementation of IPv6 nodes that support using a zero UDP checksum 🛠️.

Section 5 is an applicability statement that defines requirements and recommendations for protocols and tunnel encapsulations carried over an IPv6 transport that doesn't perform a UDP checksum calculation to verify integrity at the transport endpoints 💅.

Section 6 gives the recommendations for standardizing the zero UDP checksum, with a summary of the findings, and notes the remaining issues that need future work 📋.

Appendix A evaluates the proposals to update UDP transport behavior, plus other alternatives meant to improve support for tunnel protocols 🧪. It wraps up by weighing the trade-offs of the different methods and listing the advantages and disadvantages of each one 💖.

1.2. Terminology 🔤

Quick vocab check: the capital-letter key words are defined in [RFC2119], and this is how they work in this doc 📚.

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119] 🫶.

1.3. Use of UDP Tunnels 🦋

Using UDP as a tunnel is having a major moment 🔥. A tunnel endpoint wraps the packets of another protocol inside UDP datagrams and sends them to another tunnel endpoint 📦. UDP is attractive here when the payload protocol isn't supported by the middleboxes along the path, because lots of middleboxes do support UDP transmission 🙌. On the receiving end, the endpoint unwraps the UDP datagrams and forwards the original packets from the payload [RFC5405] 🎁. Tunnels make virtual links that look like they directly connect places that are far apart in the physical Internet topology, and they can be used to build virtual (private) networks 🌐✨.

1.3.1. Motivation for New Approaches 🎀

Okay so, a bunch of tunnel encapsulations over IPv4 already use UDP with a zero checksum, and people who rely on those protocols are like, "we want the same thing for IPv6, pls" 🥺💖

There are also some new tunnel protocols being built right now, like Automated Multicast Tunnels [AMT] and Locator/Identifier Separation Protocol (LISP) [RFC6830] ✨. They gave everyone a few reasons to update IPv6 UDP checksum processing so it's simpler, including:

Reducing forwarding costs 💅. The encapsulated packet header is already redundant, because in tunnels, payload integrity and length checking can be handled by higher-layer encapsulations (often using the IPv4, UDP, UDP-Lite [RFC3828], or TCP checksums [RFC0793]).
Not having to touch the entire packet 🦋 when a tunnel endpoint forwards it.
Being able to traverse middleboxes and actually work with them 🧚.
Wanting to use the port number space for load sharing 🌈.

1.3.2. Reducing Forwarding Costs 💜

It's a super common need to terminate a huge number of tunnels on one router or host 😭. The processing cost for each tunnel includes both state (memory requirements) and per-packet processing at the tunnel ingress and egress. It adds up fast, bestie.

Automatic IP Multicast Tunneling, known as AMT [AMT], currently uses UDP as the transport protocol for packets that carry tunneled IP multicast packets. The current AMT spec says the UDP checksum in the outer packet header should be zero (see Section 6.6 of [AMT]) 🙈. That section argues that computing an extra checksum is an unnecessary burden on nodes running lightweight tunneling protocols when the inner packet is already adequately protected. AMT also has to replicate a multicast packet to each gateway tunnel. Since the outer IP addresses are different for each tunnel, a different pseudo-header has to be built for the header of each tunnel egress that gets a replicated multicast packet. Lots of work, ngl.

The redundant processing cost argument holds up when it comes to the integrity of a tunneled packet 💖. In some architectures (for example, PC-based routers), other mechanisms can also cut checksum processing costs significantly ✨. Some implementations have optimized checksum algorithms, including checksum offloading. This is totally available for IPv4 packets at high line rates, and it's reasonable to expect the same for IPv6 endpoints, letting receivers reject corrupted packets without any further processing. The catch is that for certain classes of tunnel endpoints, offloading isn't available and probably won't be anytime soon 🥲.

1.3.3. Need to Inspect the Entire Packet 🔍

The hardware in a lot of currently deployed routers uses fast-path processing, which only gives the forwarding engine the first n bytes of a packet, where typically n <= 128 🤏.

When that design is used to support a tunnel ingress and egress, it blocks fast processing of a transport checksum over an entire (large) packet 💀. So the currently defined IPv6 UDP checksum is a bad fit for a router that can't access the entire packet and doesn't offer checksum offloading. Basically, turning on checksum calculation over the complete packet can mess with router design, performance, energy consumption, and cost. Not it 🙅‍♀️.

1.3.4. Interactions with Middleboxes 🧱

Lots of paths on the Internet include one or more middleboxes of different types 🌐. A big group of middleboxes will handle zero UDP checksum packets, but they don't support UDP-Lite or the other investigated proposals. These include load balancers (see Section 1.3.5), including equal-cost multipath (ECMP) routing, traffic classifiers, and other functions that read some fields in the UDP headers but don't validate the UDP checksum.

Then there are middleboxes that either validate or modify the UDP checksum 👀. The two most common ones are firewalls and NATs. In IPv4, UDP encapsulation can be desirable for NAT traversal, since UDP support is commonly provided. It's also necessary because IPv4 NATs are almost everywhere. People have talked about NAT for IPv6 too, though not for the same reason as IPv4. If IPv6 NAT becomes a thing, hopefully it won't have the same protocol issues IPv4 NAT has. And if NAT is defined for IPv6, it should take into consideration the use of a zero UDP checksum 🧐.

IPv6 firewall traversal requirements are likely to be similar to IPv4's 🔥. Also, you can reasonably expect that a firewall conforming to RFC 2460 won't regard datagrams with a zero UDP checksum as valid 🙃. Using a zero UDP checksum with IPv6 means firewalls need to be updated before the full benefit of the change is available.

Datagrams with a zero UDP checksum will initially not have the same middlebox traversal characteristics as regular UDP (RFC 2460) 😬. But once implementations follow the requirements in this document, we expect traversal to get better over time 📈. Deployment of IPv6-capable middleboxes is also still in its early phases, so the number of non-updated boxes could quickly become a very small percentage of the deployed middleboxes. Main character glow-up incoming ✨.

1.3.5. Support for Load Balancing ⚖️

The UDP port number fields have been used as the basis for load-balancing solutions in IPv4, and that approach has also been carried over to IPv6 🫶. Another option is to use the IPv6 flow label [RFC6437] as the source of entropy for load balancing. That would be super useful because load-balancing devices wouldn't need to assume any semantics for the transport port field, and it works for all types of transport protocols 💅.

Using the Flow Label for load balancing matches its intended use, but the field needed more clarity so it could be used consistently for this purpose 🎯. So an updated IPv6 flow label [RFC6437] and ECMP routing [RFC6438] usage were specified. Router vendors could be encouraged to start using the IPv6 Flow Label as part of the flow hash, which supports ECMP without needing UDP 🌸.

Filling the outer IPv6 header with a flow label value isn't trivial, though 😩. If the inner packet uses IPv6, the flow label value could be copied to the outer packet header. But plenty of current endpoints set the flow label to zero, which means no entropy. So a tunnel ingress that wants good entropy in the flow label field would need to create a random flow label value and keep state so that all packets belonging to a flow get the same flow label. That's possible, but the complexity may not be worth it for a tunnel ingress 🙃.

Using flow labels end-to-end for load balancing is a long-term solution 🕰️. Even after the flow label usage is clarified, there'll be a transition period before a significant share of endpoints start assigning good-quality flow labels to the flows they originate. Until widespread deployment finally happens, load balancing using transport header fields will keep going 💜.

2. Standards-Track Transports 🚀

The IETF has defined a set of transport protocols that may be applicable to tunnels with IPv6 🌈. There's also a set of network-layer encapsulation tunnels, like IP-in-IP and Generic Routing Encapsulation (GRE). These solutions are already standardized, so we'll discuss them first, before getting into the issues, because they give background for the issue descriptions and let us compare with existing issues 🧠.

2.1. UDP with Standard Checksum

UDP [RFC0768] with standard checksum behavior, as defined in RFC 2460, has already been discussed 💅. UDP usage guidelines are provided in [RFC5405].

2.2. UDP-Lite

UDP-Lite [RFC3828] offers an alternate transport to UDP and is specified as a proposed standard, RFC 3828 🎀. A MIB is defined in [RFC5097], and unicast usage guidelines are defined in [RFC5405]. There's been at least one open-source implementation of UDP-Lite as part of the Linux kernel since version 2.6.20 🐧.

UDP-Lite provides a checksum with an option for partial coverage 🧩. When you use that option, a datagram is split into a sensitive part (covered by the checksum) and an insensitive part (not covered by the checksum). When the checksum covers the entire packet, UDP-Lite is fully equivalent to UDP, except that it uses a different value in the Next Header field in the IPv6 header 🔁. Errors or corruption in the insensitive part won't cause the datagram to be discarded by the transport layer at the receiving endpoint. A minor side effect is that UDP-Lite was specified for damage-tolerant payloads, and some link layers may use different link encapsulations when forwarding UDP-Lite segments (for example, radio access bearers) 📡. Most link layers will cover the insensitive part with the same strong Layer 2 frame Cyclic Redundancy Check (CRC) that covers the sensitive part 🔒.

2.2.1. Using UDP-Lite as a Tunnel Encapsulation 🎁

Tunnel encapsulations, such as Control And Provisioning of Wireless Access Points (CAPWAP) [RFC5415], can use UDP-Lite, because it provides a transport-layer checksum, including an IP pseudo-header checksum, in IPv6, without a router or middlebox needing to traverse the entire packet payload 🙌. This gives most of the verification needed for delivery and still keeps the checksumming operation low in complexity ✨. UDP-Lite may set the length of checksum coverage on a per-packet basis. This feature could be used if a tunnel protocol is designed to verify only delivery of the tunneled payload and uses a calculated checksum for control information 💡.

Right now, middlebox traversal support for UDP-Lite is poor 😔. That's because UDP-Lite uses a different IPv6 network-layer Next Header value than UDP, so few middleboxes can interpret UDP-Lite and take appropriate actions when forwarding the packet. That makes UDP-Lite less suited to protocols that need general Internet support, until it gets better support in middleboxes and endpoints 🥹.

2.3. General Tunnel Encapsulations ✨

okay so the IETF has a whole family of tunneling protocols (a.k.a. network-layer encapsulations), like IP-in-IP and GRE 🎀. these either don't have a checksum or have one that's optional, bc tunnel encapsulations usually sit directly on the Internet layer (you can tell by the upper layer type in the IPv6 Next Header field) and they aren't used as endpoint transport protocols. ngl that makes sense 💅. there's basically little chance a tunneled packet gets mistaken for regular app data, and if it did, that could corrupt app state or data, which is the actual nightmare 😭

from an end-to-end view, the big difference between an endpoint transport and a tunnel encapsulation is the value of the network-layer Next Header field. in an endpoint transport, it names a transport protocol that supports endpoint apps. in a tunnel, it names a tunnel protocol egress instead 🦋. this split of jobs lowers the odds that a corrupted tunneled packet gets delivered to an app by accident. packets only get handed to protocol modules that process a specific Next Header value, so that field is a first-level check of correct demultiplexing ✨. UDP is a different story tho. its port space is shared by lots of diverse apps, so UDP demultiplexing relies solely on the port numbers 👑

2.4. Relationship of Zero UDP Checksum to UDP-Lite and UDP with Checksum 🌈

okay bestie, IPv6 with a zero UDP checksum is NOT the same as IPv4 with a zero UDP checksum 🙈 protocol designers should not be fooled into thinking they're the same. the requirements below list some extra things to consider for IPv6 💖

where it's possible, existing general tunnel encapsulations like GRE and IP-in-IP should be used. this section assumes those existing encapsulations don't give the functionality needed to meet the protocol designer's goals. it also only looks at the standardized alternatives, not the full pile of ideas from Appendix A 🧚. so the options to UDP with a zero checksum are UDP with a (calculated) checksum, and UDP-Lite.

UDP with a checksum has the advantage of being supported almost everywhere, in both endpoints and middleboxes 💅. it also gives statistical verification of delivery to the intended destination (address and port). the catch is that some classes of device have limited support for calculating a checksum over a full datagram. for those devices, that limited support can cost a lot of processing (e.g., it might need to run in the router's slow path), so it can reduce capacity or just fail to work 😭

UDP-Lite is nice bc its checksum can be calculated only over the pseudo-header and the UDP header ✨. that still gives statistical verification of delivery to the intended destination (address and port). the checksum can be calculated without touching the datagram payload, so it only needs access to the part that's being protected. the drawback is that UDP-Lite currently has limited support in both endpoints (it isn't supported on every operating system platform) and middleboxes (which have to support the UDP-Lite header type) 💀. so using a path verification method is recommended.

IPv6 with a zero UDP checksum can also be used by nodes that don't allow calculating a payload checksum 🫶. lots of existing classes of middleboxes don't verify or change the transport checksum, and for those, IPv6 with a zero UDP checksum is expected to work where UDP-Lite wouldn't. BUT support for the zero UDP checksum in middleboxes that do change or verify the checksum is currently limited, so datagrams with a zero UDP checksum might get discarded 😭 so, again, using a path verification method is recommended.

some sets of constraints have no solution at all 🥺 for example, a protocol designer who needs to send or receive datagrams on a device that can't efficiently calculate a checksum over a full datagram, AND needs those packets to pass through a middlebox that verifies or changes a UDP checksum but doesn't support a zero UDP checksum, can't use the zero UDP checksum method. similarly, a designer who needs to originate datagrams on a device with UDP-Lite support, but needs the packets to pass through a middlebox that doesn't support UDP-Lite, can't use UDP-Lite either. for cases like that there's no optimal solution, and the current recommendation is to use or fall back to UDP with full checksum coverage 🍓

3. Issues Requiring Consideration 🔍

this informative section looks at issues with the proposal to update IPv6 [RFC2460] so the UDP transport checksum can be set to zero. some of the issues it finds are shared with other protocols that are already in use. it also gives background so the requirements and recommendations that come after make more sense 💜

the decision in RFC 2460 to skip an integrity check at the network level meant the IPv6 transport checksum got overloaded with a bunch of jobs, including validating:

That the endpoint address was not corrupted within a router, i.e., a packet was intended to be received by this destination, and that the packet does not consist of a wrong header spliced to a different payload.
That extension header processing is correctly delimited, i.e., the start of data has not been corrupted. In this case, reception of a valid Next Header value provides some protection.
Reassembly processing, when used.
The length of the payload.
The port values, i.e., the correct application receives the payload. (Applications should also check the expected use of source ports/addresses.)
The payload integrity.

in IPv4, the first four of these checks are done with the IPv4 header checksum 🎀

in IPv6, these checks happen inside the endpoint stack using the UDP checksum info. an IPv6 node also relies on the header info to decide whether to send an ICMPv6 error message [RFC4443], and to figure out which node it gets sent to. so corrupted info could lead to misdelivery to an unintended application socket on an unexpected host 😱

3.1. Effect of Packet Modification in the Network 🌪️

IP packets can get corrupted as they travel across an Internet path 💀 older evidence in "When the CRC and TCP Checksum Disagree" [Sigcomm2000] showed this was an issue with IPv4 routers back in the year 2000, and that occasional corruption could come from bad internal router processing in routers or hosts. these errors aren't caught by the strong frame checksums used at the link layer [RFC3819]. while this document was being developed in 2009, a bunch of people reported observed rates for received UDP datagrams using IPv4 where the UDP checksum had been detected as corrupt. those rates were as high as 1.39E-4 on some paths, but close to zero on others 😳

there's a lot of experience with deployments using tunnel protocols in well-managed networks (e.g., corporate networks and service provider core networks) 💅 that's shown how robust methods like Pseudowire Emulation Edge-to-Edge (PWE3) and MPLS are. they don't use a transport protocol checksum, and they haven't specified mechanisms to protect the unprotected headers from corruption (like the VPN Identifier in MPLS). the reasons they still hold up may include:

A reduced probability of corruption on paths through well-managed networks.
IP forms the majority of the inner traffic carried by these tunnels. Hence, from a transport perspective, endpoint verification is already being performed when a received IPv4 packet is processed, or by the transport pseudo-header for an IPv6 packet. This update to UDP does not change this behavior.
In certain cases, a combination of additional filtering (e.g., filtering a MAC destination address in a Layer 2 tunnel) significantly reduces the probability of final misdelivery to the IP stack.
The tunnel protocols did not use a UDP transport header. Therefore, any corruption is unlikely to result in misdelivery to another UDP-based application. This concern is specific to UDP with IPv6.

this experience can guide the current recommendations 🧭 but any update to UDP has to keep working in the general Internet, which is heterogeneous and can include links and systems with super different characteristics. transport protocols used by hosts need to be designed with that in mind, especially when they have to cross edge networks, where middlebox deployments are common 🌸

right now, for the general Internet, there's no evidence that corruption is rare, and no evidence that corruption in IPv6 is rare either. so it seems prudent not to relax checks on misdelivery 🙈 the rise of low-end IPv6 routers and the proposed use of NAT with IPv6 give even more reason to protect against misdelivery 🔥

corruption in the network may result in:

A datagram being misdelivered to the wrong host/router or the wrong transport entity within an endpoint. Such a datagram needs to be discarded.
A datagram payload being corrupted, but still delivered to the intended host/router transport entity. Such a datagram needs to be either discarded or correctly processed by an application that provides its own integrity checks.
A datagram payload being truncated by corruption of the length field. Such a datagram needs to be discarded.

using a checksum significantly reduces the impact of errors, lowering the probability of undetected corruption of state (and data) on both the host stack and the applications using the transport service 👑

the next sections look at what happens when the destination and source IP address fields, the port fields, and the fragmentation information get modified 🦋

3.1.1. Corruption of the Destination IP Address Field 💌

an IPv6 endpoint destination address could get modified in the network, e.g., it could be corrupted by an error. this isn't a concern for IPv4, bc the IP header checksum will get the packet discarded by the receiving IP stack ✨ with IPv6, though, that modification in the network can't be detected at the network layer. detecting this corruption as a UDP receiver relies on the IPv6 pseudo-header that's built into the transport checksum 🫶

there are two possible outcomes:

Delivery to a destination address that is not in use. The packet will not be delivered, but an error report could be generated.
Delivery to a different destination address. This modification will normally be detected by the transport checksum, resulting in a silent discard. Without a computed checksum, the packet would be passed to the endpoint port demultiplexing function. If an application is bound to the associated ports, the packet payload will be passed to the application. (See Section 3.1.4 on port processing.)

3.1.2. Corruption of the Source IP Address Field ✨

okay so bestie, this section is about what happens when the source IP address gets corrupted in transit 👀. In IPv4 this isn't really a concern 💅, because the IP header checksum will normally make the receiving IP stack throw the packet away. For a UDP receiver, catching this kind of corruption depends on the IPv6 pseudo-header that gets folded into the transport checksum 🔐.

Corrupting an IPv6 source address doesn't send the packet to a different endpoint protocol or destination address 🙈. If only the source address is messed up, the datagram will likely still get processed in the intended context, just with wrong origin info 🧚. When unicast reverse path forwarding [RFC2827] is in play, a changed address might get the packet dropped by the router if the route to the modified source address is different from the route to the real source address 🚫.

What happens next depends on the app or protocol doing the processing 💀. A few examples:

An application that needs a pre-established context may throw the datagram out as invalid, or it might map it to another context (if a context for the modified source address was already activated).
A stateless application will process the datagram outside of any context. The ECHO server is a classic example, because it will reply with a datagram aimed at the modified source address. That's unwanted extra processing load, plus traffic sent to the modified endpoint address 😭.
Some datagram apps build state from packet headers. A source address they've never seen before means receiver processing and the creation of unnecessary transport-layer state at the receiver 🌸. For instance, Real-time Protocol (RTP) [RFC3550] sessions commonly use a source-independent receiver port, and state gets created for each received flow. So a datagram with a corrupted source address causes unnecessary state to pile up in the RTP state machine. That includes collision detection and response, since the same synchronization source (SSRC) value will seem to arrive from multiple source IP addresses 🌀.
ICMP messages about a corrupted packet can get misdirected to the wrong source node 📭.

Overall, the effect of a corrupted source address depends on the protocol processing the packet and how robust it is against this error 🦋. When the packet lands on a tunnel endpoint, the tunnel application is expected to correctly handle a corrupted source address 🫶.

The impact is harder to quantify when the receiving application isn't the one originally intended and several fields have been modified in transit. That's a messy situation, bestie 😵‍💫

3.1.3. Corruption of Port Information 🎀

this section covers what happens if one or both of the UDP port values get corrupted in transit 🙃. This can also happen when IPv4 is used with a zero UDP checksum, but not when UDP checksums are calculated or when UDP-Lite is used 🔥. If the ports in the transport header of an IPv6 packet get corrupted, the packet might be delivered to the wrong application process (on the intended machine), responses or errors might go to the wrong application process (on the intended machine), or both can happen at once 💅.

3.1.4. Delivery to an Unexpected Port 🚨

if you combine the corruption effects, like a corrupted destination address and corrupted ports, there are a bunch of possible outcomes when traffic shows up at an unexpected port 👀. Here are the possibilities for a packet that does not use UDP checksum validation:

The packet could be delivered to a port that isn't in use. It gets discarded, but it could generate an ICMPv6 message (e.g., port unreachable) 📭.
The packet could be delivered to a different node that implements the same application. So it may be accepted, but side effects could occur or accumulated state could be generated 🌀.
The packet could be delivered to an application that doesn't implement the tunnel protocol. So it may get incorrectly parsed and misinterpreted, causing side effects or generating accumulated state 😭.

The probability of each outcome depends on how likely it is that the address or port info for the source or destination gets corrupted in the datagram in a way that matches an existing flow or server port 🎯. Unfortunately, that kind of match may be more likely for UDP than for connection-oriented transports, because:

There's no handshake before communication and no sequence numbers (unlike TCP, Datagram Congestion Control Protocol (DCCP), and Stream Control Transmission Protocol (SCTP)). That makes it hard to verify that an application process only gets the application data tied to a specific transport session 🧩.
Application writers often bind to wildcard values in endpoint identifiers, and they don't always validate the correctness of the datagrams they receive 🙈. (Guidance on this topic is provided in [RFC5405].)

I know it's tempting to say naive applications should be declared "historic" 📜, but that's not realistic 🙅‍♀️. The transport owes it to the stack to do its best to reject bogus datagrams 💖.

If checksum coverage is suppressed, the application needs to provide a method to detect and discard the unwanted data 🛡️. A tunnel protocol would need to do its own integrity checks on any control information if it's carried in datagrams with a zero UDP checksum 🔒. If the tunnel payload is another IP packet, the packets that require checksums can be assumed to have their own checksums, as long as the rate of corrupted packets isn't significantly larger because of the tunnel encapsulation ✨. If a tunnel carries other inner payloads that don't use IP, the assumptions of corruption detection for that particular protocol must be fulfilled 🧪. This may require an additional checksum/CRC and/or integrity protection of the payload and tunnel headers 🦋.

A protocol using a zero UDP checksum can't assume it's the only protocol doing that 🥺. So it needs to handle misdelivery gracefully 🌈. It must be robust when malformed packets arrive on a listening port, and it must expect that these packets may contain corrupted data or data tied to a completely different protocol 👑.

3.1.5. Corruption of Fragmentation Information ✨

Okay so IPv6 fragmentation info is giving main character energy 👑. It has a 32-bit identity field (compared to only a 16-bit one in IPv4 🎀), a 13-bit fragment offset, and a 1-bit flag saying whether there are more fragments. If any of these get corrupted, you can end up with one of two outcomes 💀:

Reassembly failure: An error in the More Fragments field for the last fragment will, for example, result in the packet never being considered complete, so it will eventually be timed out and discarded. A corruption in the ID field will result in the fragment not being delivered to the intended context, thus leaving the rest of the packet incomplete, unless that packet has been duplicated before the corruption. The incomplete packet will eventually be timed out and discarded. 🥲
Erroneous reassembly: The reassembled packet did not match the original packet. This can occur when the ID field of a fragment is corrupted, resulting in a fragment becoming associated with another packet and taking the place of another fragment. Corruption in the offset information can cause the fragment to be misaligned in the reassembly buffer, resulting in incorrect reassembly. Corruption can cause the packet to become shorter or longer; however, completing the reassembly is much less probable, because this would require consistent corruption of the IPv6 header's payload length and offset fields. To prevent erroneous assembly, the reassembling stack must provide strong checks that detect overlap and missing data. Note, however, that this is not guaranteed and has been clarified in "Handling of Overlapping IPv6 Fragments" [RFC5722]. 😵‍💫

Erroneous reassembly is a general concern, and such packets should be discarded instead of being passed to higher-layer processes. 🚫 The primary detector of packet length changes is the IP payload length field, with a secondary check provided by the transport checksum. The Upper-Layer Packet length field included in the pseudo-header helps verify correct reassembly, because the Internet checksum has a low probability of detecting insertion of data or overlap errors (due to misplacement of data). The checksum is also incapable of detecting insertion or removal of data that is all-zero in a chunk that is a multiple of 16 bits.

The most significant risk of corruption results from mis-association of a fragment with a different packet. This risk can be significant, because the size of fragments is often the same (e.g., fragments that form when the path MTU results in fragmentation of a larger packet, which is common when addition of a tunnel encapsulation header increases the size of a packet). Detection of this type of error requires a checksum or other integrity check of the headers and the payload. While such protection is desirable for tunnel encapsulations using IPv4, because the small fragmentation ID can easily result in wraparound [RFC4963], this is especially desirable for tunnels that perform flow aggregation [TUNNELS]. 🫣

Tunnel fragmentation behavior matters. There can be outer or inner fragmentation tunnels in the Internet Architecture [TUNNELS]. If there is inner fragmentation by the tunnel, the outer headers will never be fragmented, and thus, a zero UDP checksum in the outer header will not affect the reassembly process. When a tunnel performs outer header fragmentation, the tunnel egress needs to perform reassembly of the outer fragments into an inner packet. The inner packet is either a complete packet or a fragment. If it is a fragment, the destination endpoint of the fragment will perform reassembly of the received fragments. The complete packet or the reassembled fragments will then be processed according to the packet Next Header field. The receiver may detect reassembly anomalies only when it uses a protocol with a checksum. The larger the number of reassembly processes to which a packet has been subjected, the greater the probability of an error. The following list describes some tunnel fragmentation behaviors:

An IP-in-IP tunnel that performs inner fragmentation has similar properties to a UDP tunnel with a zero UDP checksum that also performs inner fragmentation.
An IP-in-IP tunnel that performs outer fragmentation has similar properties to a UDP tunnel with a zero UDP checksum that performs outer fragmentation.
A tunnel that performs outer fragmentation can result in a higher level of corruption due to both inner and outer fragmentation, enabling more chances for reassembly errors to occur.
Recursive tunneling can result in fragmentation at more than one header level, even for fragmentation of the encapsulated packet, unless the fragmentation is performed on the innermost IP header.
Unless there is verification at each reassembly, the probability of undetected errors will increase with the number of times fragmentation is recursively applied, making both IP-in-IP and UDP with zero UDP checksum vulnerable to undetected errors. 🌀

In conclusion, fragmenting datagrams with a zero UDP checksum does not worsen performance compared to some other commonly used tunnel encapsulations. 💜 However, caution is needed for recursive tunneling that offers no additional verification at the different tunnel layers. ⚠️

3.2. Where Packet Corruption Occurs 🔍

Corruption of IP packets can happen at any point along a network path: during packet generation, during transmission over the link, in the process of routing and switching, etc. Some transmission steps include a checksum or CRC that reduces the probability of corrupted packets being forwarded, but there still exists a probability that errors may propagate undetected. 😬

Unfortunately, the Internet community lacks reliable information to identify the most common functions or equipment that results in packet corruption. However, there are indications that the place where corruption occurs can vary significantly from one path to another. However, there is a risk in taking evidence from one usage domain and using it to infer characteristics for another. Methods intended for general Internet usage must therefore assume that corruption can occur, and mechanisms must be deployed to mitigate the effects of corruption and any resulting misdelivery. 🛠️

3.3. Validating the Network Path 🛤️

IP transports designed for use in the general Internet should not assume specific path characteristics. Network protocols may reroute packets, thus changing the set of routers and middleboxes along a path. Therefore, transports such as TCP, SCTP, and DCCP have been designed to negotiate protocol parameters, adapt to different network path characteristics, and receive feedback to verify that the current path is suited to the intended application. Applications using UDP and UDP-Lite need to provide their own mechanisms to confirm the validity of the current network path. 🧭

A zero value in the UDP checksum field is explicitly disallowed in RFC 2460. Thus, it may be expected that any device on the path that has a reason to look beyond the IP header, for example, to validate the UDP checksum, will consider such a packet as erroneous or illegal and may discard it, unless the device is updated to support the new behavior. Any middlebox that modifies the UDP checksum, for example, a NAT that changes the values of the IP and UDP header in such a way that the checksum over the pseudo-header changes value, will need to be updated to support this behavior. Until then, a zero UDP checksum packet is likely to be discarded, either directly in the middlebox or at the destination, when a zero UDP checksum has been modified to be non-zero by an incremental update. 🙅‍♀️

A pair of endpoints intending to use the new behavior will therefore need not only to ensure support at each endpoint, but also to ensure that the path between them will deliver packets with the new behavior. This may require using negotiation or an explicit mandate to use the new behavior by all nodes that support the new protocol. 🤝

Enabling the use of a zero checksum places new requirements on equipment deployed within the network, such as middleboxes. A middlebox (e.g., a firewall or NAT) may enable zero checksum usage for a particular range of ports. Note that checksum off-loading and operating system design may result in all IPv6 UDP traffic being sent with a calculated checksum. This requires middleboxes that are configured to enable a zero UDP checksum to continue to work with bidirectional UDP flows that use a zero UDP checksum in only one direction, and therefore, they must not maintain separate state for a UDP flow based on its checksum usage. 🧱

Support along the path between endpoints can be guaranteed in limited deployments by appropriate configuration. In general, it can be expected to take time for deployment of any updated behavior to become ubiquitous. ⏳

A sender will need to probe the path to verify the expected behavior. Path characteristics may change, and usage therefore should be robust and able to detect a failure of the path under normal usage, and should be able to renegotiate. Note that a bidirectional path does not necessarily support the same checksum usage in both the forward and return directions. Receipt of a datagram with a zero UDP checksum does not imply that the remote endpoint can also receive a datagram with a zero UDP checksum. This behavior will require periodic validation of the path, adding complexity to any solution using the new behavior. 🔁

3.4. Applicability of the Zero UDP Checksum Method 🎯

The update to the IPv6 specification defined in [RFC6935] modifies only IPv6 nodes that implement specific protocols designed to permit omission of a UDP checksum. This document provides an applicability statement for the updated method, indicating when the mechanism can (and cannot) be used. Enabling a zero UDP checksum, and ensuring correct interactions with the stack, implies much more than simply disabling the checksum algorithm for specific packets at the transport interface. 🧐

When the zero UDP checksum method is widely available, we expect that it will be used by applications that perceive to gain benefit from it. Any solution that uses an end-to-end transport protocol rather than an IP-in-IP encapsulation needs to minimize the possibility that application processes could confuse a corrupted or wrongly delivered UDP datagram with that of data addressed to the application running on their endpoint. 👀

A protocol or application that uses the zero UDP checksum method must ensure that the lack of checksum does not affect the protocol operation. This includes being robust to receiving an unintended packet from another protocol or context following corruption of a destination or source address and/or port value. It also includes considering the need for additional implicit protection mechanisms required when using the payload of a UDP packet received with a zero checksum. 💖

3.5. Impact on Non-Supporting Devices or Applications 🙈

Okay bestie, we need to talk about the apps that never got the memo about zero UDP checksums 😭. Endpoint devices and applications that aren't modified to support the new behavior, or that by default (or by preference) don't use the regular behavior, still exist, and they must not be significantly impacted by the update 🛡️.

Why does this matter? Picture a node that turns on zero UDP checksum at the interface level. Now every application listening on a UDP socket gets datagrams where the checksum was never verified 💀. An app that wasn't built with the extra robustness to handle corrupted packets could end up creating state or destroying existing state. That's a whole disaster, iykyk.

So the rule is that a zero UDP checksum only gets enabled for individual ports, and only when the application explicitly asks for it 🎀. Apps on other ports keep the current IPv6 behavior, which means they keep discarding incoming datagrams with a zero UDP checksum, and they aren't affected by this change at all ✨. An app that does allow the changed behavior should be aware of the risk of corruption and the increased level of misdirected traffic, and it can be designed robustly to handle that risk 💪.

4. Constraints on Implementation of IPv6 Nodes Supporting Zero Checksum 🎀

This section is an applicability statement, which is just a fancy way of saying it lays out the requirements and recommendations for implementing IPv6 nodes that support using a zero value in the checksum field of a UDP datagram 🧚.

All implementations that support the zero UDP checksum method MUST conform to the requirements defined below:

An IPv6 sending node MAY use a calculated RFC 2460 checksum for all datagrams that it sends. This explicitly permits an interface that supports checksum off-loading to insert an updated UDP checksum value in all UDP datagrams that it forwards. Note, however, that sending a calculated checksum requires the receiver to also perform the checksum calculation. Checksum off-loading can normally be switched off for a particular interface to ensure that datagrams are sent with a zero UDP checksum 🔥.
IPv6 nodes SHOULD, by default, NOT allow the zero UDP checksum method for transmission 🙅‍♀️.
IPv6 nodes MUST provide a way for the application/protocol to indicate the set of ports that will be enabled to send datagrams with a zero UDP checksum. This may be implemented by enabling a transport mode using a socket API call when the socket is established, or by a similar mechanism. It may also be implemented by enabling the method for a pre-assigned static port used by a specific tunnel protocol 🌸.
IPv6 nodes MUST provide a method to allow an application/protocol to indicate that a particular UDP datagram is required to be sent with a UDP checksum. This needs to be allowed by the operating system at any time (e.g., to send keepalive datagrams), not just when a socket is established in zero checksum mode 💖.
The default IPv6 node receiver behavior MUST be to discard all IPv6 packets carrying datagrams with a zero UDP checksum 🚫.
IPv6 nodes MUST provide a way for the application/protocol to indicate the set of ports that will be enabled to receive datagrams with a zero UDP checksum. This may be implemented via a socket API call or by a similar mechanism. It may also be implemented by enabling the method for a pre-assigned static port used by a specific tunnel protocol 🦋.
IPv6 nodes supporting usage of zero UDP checksums MUST also allow reception using a calculated UDP checksum on all ports configured to allow zero UDP checksum usage. (The sending endpoint, e.g., the encapsulating ingress, may choose to compute the UDP checksum or may calculate it by default.) The receiving endpoint MUST use the reception method specified in RFC2460 when the checksum field is not zero 🫶.
RFC 2460 specifies that IPv6 nodes SHOULD log received datagrams with a zero UDP checksum. This remains the case for any datagram received on a port that does not explicitly enable processing of a zero UDP checksum. A port for which the zero UDP checksum has been enabled MUST NOT log the datagram solely because the checksum value is zero 📝.
IPv6 nodes MAY separately identify received UDP datagrams that are discarded with a zero UDP checksum. They SHOULD NOT add these to the standard log, because the endpoint has not been verified. This may be used to support other functions (such as a security policy) 🕵️‍♀️.
IPv6 nodes that receive ICMPv6 messages that refer to packets with a zero UDP checksum MUST provide appropriate checks concerning the consistency of the reported packet to verify that the reported packet actually originated from the node, before acting upon the information (e.g., validating the address and port numbers in the ICMPv6 message body) 👀.

5. Requirements on Usage of the Zero UDP Checksum 💅

This section is an applicability statement that identifies requirements and recommendations for protocols and tunnel encapsulations that are carried over an IPv6 transport flow (e.g., a tunnel) that does not perform a UDP checksum calculation to verify integrity at the transport endpoints. Before a protocol developer decides to use the zero UDP checksum and give up the integrity verification that non-zero checksumming provides, they should seriously consider whether they can use checksummed UDP packets or UDP-Lite [RFC3828] instead, because IPv6 with a zero UDP checksum is not equivalent in behavior to IPv4 with zero UDP checksum 🤔.

The requirements and recommendations for protocols and tunnel encapsulations using an IPv6 transport flow that does not perform a UDP checksum calculation to verify integrity at the transport endpoints are:

Transported protocols that enable the use of zero UDP checksum MUST enable this only for a specific port or port range. This needs to be enabled at the sending and receiving endpoints for a UDP flow 🎯.
An integrity mechanism is always RECOMMENDED at the transported protocol layer to ensure that corruption rates of the delivered payload are not increased (e.g., at the innermost packet of a UDP tunnel). A mechanism that isolates the causes of corruption (e.g., identifying misdelivery, IPv6 header corruption, or tunnel header corruption) is also expected to provide additional information about the status of the tunnel (e.g., to suggest a security attack) 🔐.
A transported protocol that encapsulates Internet Protocol (IPv4 or IPv6) packets MAY rely on the inner packet integrity checks, provided that the tunnel protocol will not significantly increase the rate of corruption of the inner IP packet. If a significantly increased corruption rate can occur, the tunnel protocol MUST provide an additional integrity verification mechanism. Early detection is desirable to avoid wasting unnecessary computation, transmission capacity, or storage for packets that will subsequently be discarded ⏱️.
A transported protocol that supports the use of a zero UDP checksum MUST be designed so that corruption of any header information does not result in accumulation of incorrect state for the protocol 🧠.
A transported protocol with a non-tunnel payload or one that encapsulates non-IP packets MUST have a CRC or other mechanism for checking packet integrity, unless the non-IP packet is specifically designed for transmission over a lower layer that does not provide a packet integrity guarantee 🧩.
A transported protocol with control feedback SHOULD be robust to changes in the network path, because the set of middleboxes on a path may vary during the life of an association. The UDP endpoints need to discover paths with middleboxes that drop packets with a zero UDP checksum. Therefore, transported protocols SHOULD send keepalive messages with a zero UDP checksum. An endpoint that discovers an appreciable loss rate for keepalive packets MAY terminate the UDP flow (e.g., a tunnel). Section 3.1.3 of RFC 5405 describes requirements for congestion control when using a UDP-based transport 🌊.
A protocol with control feedback that can fall back to using UDP with a calculated RFC 2460 checksum is expected to be more robust to changes in the network path. Therefore, keepalive messages SHOULD include both UDP datagrams with a checksum and datagrams with a zero UDP checksum. This will enable the remote endpoint to distinguish between a path failure and the dropping of datagrams with a zero UDP checksum 🔍.
A middlebox implementation MUST allow forwarding of an IPv6 UDP datagram with both a zero and a standard UDP checksum using the same UDP port 🚪.
A middlebox MAY configure a restricted set of specific port ranges that forward UDP datagrams with a zero UDP checksum. The middlebox MAY drop IPv6 datagrams with a zero UDP checksum that are outside a configured range 🚧.
When a middlebox forwards an IPv6 UDP flow containing datagrams with both a zero and a standard UDP checksum, the middlebox MUST NOT maintain separate state for flows, depending on the value of their UDP checksum field. (This requirement is necessary to enable a sender that always calculates a checksum to communicate via a middlebox with a remote endpoint that uses a zero UDP checksum.) 🤝

Special considerations are required when designing a UDP tunnel protocol where the tunnel ingress or egress may be a router that may not have access to the packet payload. When the node is acting as a host (i.e., sending or receiving a packet addressed to itself), the checksum processing is similar to other hosts. However, when the node (e.g., a router) is acting as a tunnel ingress or egress that forwards a packet to or from a UDP tunnel, there may be restricted access to the packet payload. This prevents calculating (or verifying) a UDP checksum. In this case, the tunnel protocol may use a zero UDP checksum and must:

Ensure that tunnel ingress and tunnel egress router are both configured to use a zero UDP checksum. For example, this may include ensuring that hardware checksum off-loading is disabled ⚙️.
The tunnel operator must ensure that middleboxes on the network path are updated to support use of a zero UDP checksum 🛠️.
A tunnel egress should implement appropriate security techniques to protect from overload, including source address filtering to prevent traffic injection by an attacker and rate-limiting of any packets that incur additional processing, such as UDP datagrams used for control functions that require verification of a calculated checksum to verify the network path. Usage of common control traffic for multiple tunnels between a pair of nodes can assist in reducing the number of packets to be processed 🛡️🔥.

6. Summary 💅

Okay bestie, this is the wrap-up section and it's giving "here's the whole tea in one place" 🫖✨. This document is an applicability statement for using UDP transport checksums with IPv6 🦋.

It looks at what the UDP checksum does when you're on IPv6, and it lays out the trade-offs for whether it's safe to update RFC 2460 so an IPv6 endpoint can set the UDP checksum field to zero and say "no checksum here" 🙈.

So application designers, first check whether you can hit your goals with standard UDP (with a calculated checksum) or with UDP-Lite 🌸. Using UDP with a zero checksum is actually useful for some apps, like tunnel encapsulation, and it's super common in IPv4 💜. But IPv6 has different dangers. The risk of corruption and misdelivery goes up compared to IPv4, because IPv6 has no header checksum 😭. So you need to weigh those risks, and think about a solution that gives at least the same delivery protection you'd get on IPv4, like using UDP-Lite or turning the UDP checksum back on 🔥. Checksum off-loading can help cut the cost of checksum processing, and it still lets you use a checksum method defined in RFC 2460 ✨.

Tunnel apps that use UDP for encapsulation can often use a zero UDP checksum without wrecking the corruption rate 🎀. A well-designed tunnel should run consistency checks to validate the header info that gets encapsulated with each received packet 🧚. In most cases, tunnels carrying IP packets can count on the integrity protection from the transported protocol (or the tunneled inner packet) 💖. If it's implemented correctly, that endpoint won't be hurt by leaving out the transport-layer checksum 👑. Recursive tunneling and fragmentation are the real troublemakers, though. They can push corruption rates way up, so they need careful thought 🙈💀.

Other UDP apps on the intended destination node, or on other nodes, can get affected if nodes are allowed to receive datagrams with a zero UDP checksum 😬. It's really important that apps already out in the wild don't get messed up by a change at the transport layer 🫶. If those apps run on nodes that implement RFC 2460, those nodes will discard (and log) every datagram with a zero UDP checksum. That part is fine, not an issue ✅💅.

In general, UDP-based apps need some mechanism that catches a large percentage of corrupted packets before they reach the app 🛡️. That protects both the app's data stream and the control plane of higher-layer protocols 🌈. Right now, those checks are done by the UDP checksum for IPv6, or by the reduced checksum for UDP-Lite when it's used with IPv6 ⭐.

Recursive tunneling and fragmentation are hard problems that tunnel protocol designers have to think about 🧩. The innermost packet has a higher chance of errors when fragmentation happens across several tunneling layers, and several different reassembly processes run without any correctness check 😱. That needs extra thought and care when designing transported tunnels 🍓.

Any use of the updated method has to consider what it means for firewalls, NATs, and other middleboxes 🚧. IPv6 NATs aren't expected to handle IPv6 UDP datagrams the same way they handle IPv4 UDP datagrams 🙃. In lots of deployed cases, an update to support the IPv6 zero UDP checksum will be needed 🛠️. Firewalls are meant to be configured, so they may need explicit updates to allow new services or protocols 🔒. IPv6 middleboxes aren't as widespread as IPv4 ones yet, so new devices are expected to follow the methods in this document 🦋.

Last but not least, each application should think hard about what it means to pick an IPv6 transport that uses a zero UDP checksum 🧠. It should also ask whether other standard methods would fit better and make app design simpler 💜✨.

7. Security Considerations 🔐

Transport checksums are the first layer of protection for the stack, but they can't be treated as authentication mechanisms 🙅‍♀️. Checks like these are also worth having so packet counters correctly log what's really happening, and they can help detect unusual behaviors 👀.

Depending on the hardware design, the processing requirements can be different for tunnels that have a zero UDP checksum versus tunnels that calculate one 🖥️. That processing overhead might need to be considered when you decide whether to enable a tunnel and what transmission rate is acceptable 📊. This can become a security risk for designs that can handle a much bigger number of zero-checksum UDP packets than checksummed datagrams, like a tunnel egress 😨. An attacker could try to inject non-zero-checksum UDP packets into a tunnel that forwards zero-checksum UDP packets, and overload the processing of those non-zero checksums. That could happen if it's done in a router's slow path, for example 🐢💥. So protection mechanisms should be used whenever this threat exists 🛡️. Protection may include source-address filtering to stop an attacker from injecting traffic, and throttling the amount of non-zero-checksum traffic 🚦. Throttling might affect how the tunnel protocol works 🫠.

Sending IPv6 packets with a zero UDP checksum could reveal extra information that helps an on-path attacker figure out the operating system or configuration of a sending node 🕵️‍♀️. The network path needs to be probed to find out whether it supports IPv6 packets with a zero UDP checksum 🔍. The details of the probing mechanism can differ between tunnel encapsulations. If those details are visible in the network (for example, when IPsec in encryption mode isn't being used), they could reveal extra information that helps an on-path attacker identify the type of tunnel in use 🥺🚨.

IP-in-IP or GRE tunnels get through middleboxes that weren't designed for security, like firewalls, pretty well 🌊. But firewalls are often expected to block general tunnels, because those tunnels have a big attack surface 🏰. So this applicability statement only allows this method to be enabled for specific port ranges 🎯.

When the zero UDP checksum mode is enabled for a range of ports, nodes and middleboxes must forward received UDP datagrams that have either a calculated checksum or a zero checksum. ⚠️

8. Acknowledgments 🫶

We'd like to thank Brian Haberman, Brian Carpenter, Margaret Wasserman, Lars Eggert, and others in the TSV directorate 💖. Barry Leiba, Ronald Bonica, Pete Resnick, and Stewart Bryant helped make this document one with greater applicability 👑. Thanks to P.F. Chimento for careful review and editorial corrections ✨.

Thanks also to Remi Denis-Courmont, Pekka Savola, Glen Turner, and many others who shared comments and ideas on the 6man, behave, lisp, and mboned lists 🌸💜.

9. References 📚

9.1. Normative References

[RFC0768]     Postel, J., "User Datagram Protocol", STD 6, RFC 768,
              August 1980.

[RFC0791]     Postel, J., "Internet Protocol", STD 5, RFC 791,
              September 1981.

[RFC2119]     Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119, March 1997.

[RFC2460]     Deering, S. and R. Hinden, "Internet Protocol, Version
              6 (IPv6) Specification", RFC 2460, December 1998.

[RFC6935]     Eubanks, M., Chimento, P., and M. Westerlund, "IPv6 and
              UDP Checksums for Tunneled Packets", RFC 6935,
              April 2013.

9.2. Informative References

[AMT]         Bumgardner, G., "Automatic Multicast Tunneling", Work
              in Progress, June 2012.

[RFC0793]     Postel, J., "Transmission Control Protocol", STD 7,
              RFC 793, September 1981.

[RFC1071]     Braden, R., Borman, D., Partridge, C., and W. Plummer,
              "Computing the Internet checksum", RFC 1071,
              September 1988.

[RFC1141]     Mallory, T. and A. Kullberg, "Incremental updating of
              the Internet checksum", RFC 1141, January 1990.

[RFC1624]     Rijsinghani, A., "Computation of the Internet Checksum
              via Incremental Update", RFC 1624, May 1994.

[RFC2827]     Ferguson, P. and D. Senie, "Network Ingress Filtering:
              Defeating Denial of Service Attacks which employ IP
              Source Address Spoofing", BCP 38, RFC 2827, May 2000.

[RFC3550]     Schulzrinne, H., Casner, S., Frederick, R., and V.
              Jacobson, "RTP: A Transport Protocol for Real-Time
              Applications", STD 64, RFC 3550, July 2003.

[RFC3819]     Karn, P., Bormann, C., Fairhurst, G., Grossman, D.,
              Ludwig, R., Mahdavi, J., Montenegro, G., Touch, J., and
              L. Wood, "Advice for Internet Subnetwork Designers",
              BCP 89, RFC 3819, July 2004.

[RFC3828]     Larzon, L-A., Degermark, M., Pink, S., Jonsson, L-E.,
              and G. Fairhurst, "The Lightweight User Datagram
              Protocol (UDP-Lite)", RFC 3828, July 2004.

[RFC4443]     Conta, A., Deering, S., and M. Gupta, "Internet Control
              Message Protocol (ICMPv6) for the Internet Protocol
              Version 6 (IPv6) Specification", RFC 4443, March 2006.

[RFC4963]     Heffner, J., Mathis, M., and B. Chandler, "IPv4
              Reassembly Errors at High Data Rates", RFC 4963,
              July 2007.

[RFC5097]     Renker, G. and G. Fairhurst, "MIB for the UDP-Lite
              protocol", RFC 5097, January 2008.

[RFC5405]     Eggert, L. and G. Fairhurst, "Unicast UDP Usage
              Guidelines for Application Designers", BCP 145,
              RFC 5405, November 2008.

[RFC5415]     Calhoun, P., Montemurro, M., and D. Stanley, "Control
              And Provisioning of Wireless Access Points (CAPWAP)
              Protocol Specification", RFC 5415, March 2009.

[RFC5722]     Krishnan, S., "Handling of Overlapping IPv6 Fragments",
              RFC 5722, December 2009.

[RFC6437]     Amante, S., Carpenter, B., Jiang, S., and J.
              Rajahalme, "IPv6 Flow Label Specification", RFC 6437,
              November 2011.

[RFC6438]     Carpenter, B. and S. Amante, "Using the IPv6 Flow Label
              for Equal Cost Multipath Routing and Link Aggregation
              in Tunnels", RFC 6438, November 2011.

[RFC6830]     Farinacci, D., Fuller, V., Meyer, D., and D. Lewis,
              "The Locator/ID Separation Protocol (LISP)", RFC 6830,
              January 2013.

[Sigcomm2000] Stone, J. and C. Partridge, "When the CRC and TCP
              Checksum Disagree", 2000,
              <http://conferences.sigcomm.org/sigcomm/2000/conf/
              abstract/9-1.htm>.

[TUNNELS]     Touch, J. and M. Townsley, "Tunnels in the Internet
              Architecture", Work in Progress, March 2010.

[UDPTT]       Fairhurst, G., "The UDP Tunnel Transport mode", Work in
              Progress, February 2010.

Appendix A. Evaluation of Proposal to Update RFC 2460 to Support Zero Checksum ✨

Okay bestie, this appendix is informative 🤓, so it's context, not a rule. It looks at a proposal to update IPv6 [RFC2460] so that some nodes can skip generating and checking the UDP transport checksum 💅. It also compares that idea with other options, and admits that for some applications, standard methods might be more iconic than IPv6 with a zero UDP checksum 🦋.

A.1. Alternatives to the Standard Checksum

So there are a few ways to avoid the normal method of calculating the UDP checksum [RFC1071] that don't make a tunnel endpoint inspect the entire packet 👀. Here they are:

IP-in-IP tunneling. This one drops the transport protocol in the outer layer completely, so it has less overhead and complexity 🪶. But it also has less functionality. There's no outer checksum over the packet, and there are no ports to demultiplex among different tunnel types. That means a load balancer has less info to work with 😅.
UDP-Lite with checksum coverage set to only the header portion. This needs a pseudo-header checksum calculation only on the encapsulating packet header ✨. The computed checksum may be cached (before adding the Length field) for each flow/destination, then combined with the Length of each packet to cut down per-packet processing. This value is combined with the UDP payload length for the pseudo-header. The catch is that this length is expected to be known when performing packet forwarding 🧐.
Delta computation of the checksum from an encapsulated checksum field. Because the checksum is a cumulative sum [RFC1624], an encapsulating header checksum can be derived from the new pseudo-header, the inner checksum, and the sum of the other network-layer fields not included in the pseudo-header of the encapsulated packet. It's kind of like an incremental checksum update [RFC1141] 🧮. This doesn't need access to the whole packet, but it does mean collecting fields across the header and doing arithmetic on each packet. It only works for packets that contain a 2's complement transport checksum, so it wouldn't be appropriate for SCTP or when IP fragmentation is used 🚫.
UDP modified to disable checksum processing (Zero UDP Checksum) [RFC6935]. This gets rid of the need for a checksum calculation, but it needs constraints on appropriate usage and updates to endpoints and middleboxes 🛠️.
The proposed UDP Tunnel Transport [UDPTT] protocol. This suggested modifying UDP to derive the checksum only from the encapsulating packet protocol header. That value doesn't change between packets in a single flow, so it may be cached per flow/destination to minimize per-packet processing 💜.
A new (to-be-defined) IPv6 Destination Options Header. This would give an end-to-end validation check at the network layer 🔐. It would let an endpoint verify delivery to an appropriate endpoint, but IPv6 nodes would need to correctly handle the additional header, and middlebox behavior would need changes (for example, when used with a NAT that always adjusts the checksum value) 🙈.
Simply ignoring the UDP checksum value on reception at the tunnel egress. This lets a tunnel ingress insert any value, correct or false 🎲. For tunnel usage, a non-standard checksum value may be used, which forces an RFC 2460 receiver to drop the packet. The big downside is that it would be impossible to tell a UDP datagram treated this way (in the network or at an endpoint) apart from a packet that was actually corrupted 💀.

These options get compared and discussed further in the following sections 🎀.

A.2. Comparison of Alternative Methods

This section compares the methods listed above for supporting datagram tunneling. It also includes proposals for updating UDP's behavior 🌸.

While this comparison focuses on applications expected to run on routers, the line between a router and a host isn't always clear, especially at the transport level. Systems like UNIX-based operating systems routinely provide both functions 💻. From a received packet, there's no way to figure out the role of the receiving node 🤷‍♀️.

A.2.1. Middlebox Traversal

Regular UDP with a standard checksum, or the delta-encoded optimization for creating correct checksums, has the best chance of successfully traversing a middlebox 🏆. No new support is required.

A method that ignores the UDP checksum on reception is expected to have a good probability of traversal, because most middleboxes perform an incremental checksum update ✨. UDPTT would also be able to traverse a middlebox with this behavior. However, a middlebox on the path that tries to verify a standard checksum won't forward packets using either of these methods, so traversal gets blocked 🚧. A method that ignores the checksum has an extra downside too: it prevents improvement of middlebox traversal, because there's no way to identify UDP datagrams that use the modified checksum behavior 😤.

IP-in-IP or GRE tunnels offer good traversal of middleboxes that weren't designed for security, like firewalls. However, firewalls may be configured to block general tunnels, because they present a large attack surface 🧱.

A new IPv6 Destination Options header will have traversal issues with middleboxes, especially firewalls and NATs, and those will likely need to be updated before the extension header gets passed 🔧.

Datagrams with a zero UDP checksum won't be passed by any middlebox that validates the checksum using RFC 2460 or updates the checksum field, such as NATs or firewalls 🚫. Handling a datagram with a zero UDP checksum correctly would take an update 💅.

UDP-Lite will require an update to almost all types of middleboxes, because it needs support for a separate network-layer protocol number 🥲. Once enabled, the method to support incremental checksum updates would be identical to the one for UDP, but different for checksum validation 🌈.

A.2.2. Load Balancing

The usefulness of solutions for load balancers depends on the difference in entropy in the headers for different flows that can be included in a hash function 📊. All the proposals that use the UDP protocol number have equal behavior. UDP-Lite has the potential to be equally as good as UDP. However, UDP-Lite is currently unlikely to be supported by deployed hashing mechanisms, which could cause a load balancer not to use the transport header in the computed hash 😬.

A load balancer that uses only the IP header will have low entropy 📉. This could be improved by including the IPv6 flow label, as long as the tunnel ingress makes sure different flow labels are assigned to different flows 🏷️. But moving to common use of good-quality flow labels is likely to take time to deploy ⏳.

A.2.3. Ingress and Egress Performance Implications

IP-in-IP tunnels are often considered efficient, because they introduce very little processing and have low data overhead 🏎️. The other proposals introduce a UDP-like header, which comes with an associated data overhead 📦.

Processing is minimized for the zero UDP checksum method and for the method that ignores the UDP checksum on reception. Processing is only slightly higher for UDPTT, the extension header, and UDP-Lite ⚖️. The delta calculation scheme operates on a few more fields, but it also introduces serious failure modes that can end up needing a checksum calculated over the complete datagram 😱. Regular UDP is clearly the most costly to process, since it always requires a checksum calculation over the entire datagram 🐢.

It's important to note that the zero UDP checksum method, ignoring the checksum on reception, the Option Header, UDPTT, and UDP-Lite will likely add complexity to the application, since it has to incorporate a negotiation and validation mechanism 🧩.

A.2.4. Deployability

The major factors influencing deployability of these solutions are the need to update both endpoints, the need for negotiation, and the need to update middleboxes 🚀. Here's the summary:

The solution with the best deployability is regular UDP 👑. It requires no changes and has good middlebox traversal characteristics.
The next easiest to deploy is the delta checksum solution 🥈. It doesn't modify the protocol on the wire, and it only needs changes at the tunnel ingress.
IP-in-IP tunnels shouldn't require changes to the endpoints, but they raise issues around traversal of firewalls and other security devices, which are expected to need updates 🔒.
Ignoring the checksum on reception will require changes at both endpoints 😵. The never-ceasing risk of path failure means extra checks are needed to make this solution robust, plus changes or additions to the tunnel control protocol to negotiate support and validate the path 🛤️.
The remaining solutions (including the zero UDP checksum method) offer similar deployability 🤝. UDP-Lite requires support at both endpoints and in middleboxes. UDPTT and the zero UDP checksum method, with or without an extension header, also require support at both endpoints and in middleboxes. UDP-Lite, UDPTT, the zero UDP checksum method, and the use of extension headers may also require changes or additions to the tunnel control protocol to negotiate support and path validation 🧾.

A.2.5. Corruption Detection Strength

The standard UDP checksum and the delta checksum can both provide some verification at the tunnel egress 🛡️. This can significantly reduce the probability that a corrupted inner packet is forwarded. UDP-Lite, UDPTT, and the extension header all provide some verification against corruption, but they don't verify the inner packet. They only provide a strong indication that the delivered packet was intended for the tunnel egress and was correctly delimited 🎯.

The methods using a zero UDP checksum, ignoring the UDP checksum on reception, and IP-and-IP encapsulation all provide no verification that a received datagram was intended to be processed by a specific tunnel egress, or that the inner encapsulated packet was correct 😬. Section 3.1 discusses experience using specific protocols in well-managed networks. 💖

A.2.6. Comparison Summary ✨

okay so the comparisons above basically boil down to "there is no silver bullet that will slay all the issues" 💅. You have to pick which downsides you can live with, bestie 🫶. Here's the tea on the existing solutions:

Regular UDP: The method defined in RFC 2460 has good middlebox traversal, good load balancing, and good multiplexing 🦋. It requires a checksum in the outer headers to cover the whole packet.
IP-in-IP: A low-complexity encapsulation with limited middlebox traversal, no multiplexing support, and poor load-balancing support that could improve over time 🧚.
UDP-Lite: A medium-complexity encapsulation with good multiplexing support, limited middlebox traversal that may possibly improve over time, and poor load-balancing support that could improve over time. In most cases it requires application-level negotiation to select the protocol, and validation to confirm that the path forwards UDP-Lite 🌸.
Delta computation of a tunnel checksum: The delta checksum is an optimization in the processing of UDP, so it has some of the same drawbacks as regular UDP 🙈.

The remaining proposals are kind of similar vibes, ngl:

Zero Checksum: A low-complexity encapsulation with good multiplexing support, limited middlebox traversal that could improve over time, and good load-balancing support. In most cases it requires application-level negotiation and validation to confirm that the path forwards a zero UDP checksum 🍓.
UDPTT: A medium-complexity encapsulation with good multiplexing support, limited middlebox traversal that may possibly improve over time, and good load-balancing support. In most cases it requires application-level negotiation to select the transport, and validation to confirm the path forwards UDPTT datagrams 💜.
IPv6 Destination Option IP-in-IP Tunneling: A medium-complexity encapsulation with no multiplexing support, limited middlebox traversal, and poor load-balancing support that could improve over time. In most cases it requires negotiation to confirm that the option is supported, and validation to confirm the path forwards the option 🎀.
IPv6 Destination Option Combined with Zero UDP Checksum: A medium-complexity encapsulation with good multiplexing support, limited load-balancing support that could improve over time. In most cases it requires negotiation to confirm the option is supported, and validation to confirm the path forwards the option 🌈.
Ignore the Checksum on Reception: A low-complexity encapsulation with good multiplexing support, medium middlebox traversal that can never improve, and good load-balancing support. In most cases it requires negotiation to confirm that the option is supported by the remote endpoint, and validation to confirm the path forwards a zero UDP checksum 👑.

So there is no clear single optimum solution 😭. If the most important need is traversing middleboxes, the best choice is to stay with regular UDP and consider the optimizations that may be required to perform the checksumming. If you can live with limited middlebox traversal, low complexity is necessary, and you don't need load balancing, IP-in-IP tunneling is the simplest. If you want strengthened error detection, but you're okay with the currently limited middlebox traversal and load balancing, UDP-Lite is appropriate. Zero UDP checksum handles a different set of constraints: low complexity and a need for load balancing from the current Internet, provided that the usage can accept the currently limited support for middlebox traversal 🦋.

Techniques for load balancing and middlebox traversal do keep evolving ✨. Over a long time, developments in load balancing have good potential to improve. This time horizon is long, because it requires both load balancer and endpoint updates to get the full benefit. The challenges of middlebox traversal are also expected to change over time as device capabilities evolve. Middleboxes are super prolific, with a larger share owned by end users, so they may be expected to take a long time to evolve 🙈.

However, the deployment of IPv6-capable middleboxes is still in its initial phase, and if a new method becomes standardized quickly, fewer boxes will be non-compliant. Timing is everything, babe ⏰.

Thus, whether to permit use of datagrams with a zero UDP checksum for IPv6 under reasonable constraints is best viewed as a trade-off among a number of more subjective questions:

Is there sufficient interest in using a zero UDP checksum with the given constraints (summarized below)?
Are there other avenues of change that will resolve the issue in a better way and sufficiently quickly?
Do we accept the complexity cost of having one more solution in the future?

The analysis concludes that the IETF should carefully consider constraints on sanctioning the use of any new transport mode 🔥. The 6man working group of the IETF has determined that the answers to the above questions are sufficient to update IPv6 to standardize use of a zero UDP checksum for use by tunnel encapsulations for specific applications 👑.

Each application should consider the implications of choosing an IPv6 transport that uses a zero UDP checksum. In many cases, standard methods may be more appropriate and may simplify application design 💖. Checksum off-loading may help alleviate the checksum processing cost and permit use of a checksum using the method defined in RFC 2460 🧚.

Authors' Addresses 🎀

Here's who to contact, iykyk 💅:

Godred Fairhurst
University of Aberdeen
School of Engineering
Aberdeen, AB24 3UE
Scotland, UK

EMail: gorry@erg.abdn.ac.uk
URI:   http://www.erg.abdn.ac.uk/users/gorry


Magnus Westerlund
Ericsson
Farogatan 6
Stockholm,  SE-164 80
Sweden

Phone: +46 8 719 0000
EMail: magnus.westerlund@ericsson.com

📦 where this page comes from

ietf: rfc6936 2013-04
💖 girlified by claude-haiku-5-5 on 2026-10-17: a language model's rewrite of the original, under its terms