RFC 6935

IPv6 and UDP Checksums for Tunneled Packets

📅 published April 2013, from ietf

RFC 6935: IPv6 and UDP Checksums for Tunneled Packets 🎀

Okay bestie, this one is RFC 6935, and it's giving Standards Track 💅. It was published in April 2013 and written by M. Eubanks (AmericaFree.TV LLC), P. Chimento (Johns Hopkins University Applied Physics Laboratory), and M. Westerlund (Ericsson). Its ISSN is 2070-1721. It updates RFC 2460, which is the IPv6 spec, so it's basically an edit to a classic 🧚.

Abstract 💜

So the big idea is this: when a tunnel protocol uses UDP on top of IPv6 to carry packets, this doc updates the IPv6 spec to make things faster 🚀. The speedup comes from relaxing the IPv6 UDP checksum requirement for tunnel protocols whose header info is already protected on the "inner" packet being carried. That means you skip the cost of computing UDP checksums on IPv6 packets that carry tunnel packets, which is lowkey a relief for the routers doing the work 🙈.

It explains how the checksum requirement can be relaxed when the encapsulated packet has its own checksum. It also spills the tea on the limitations and risks of this approach and talks about the restrictions on using this method. Read those parts carefully, no cap 🫶.

Status of This Memo 🌈

This is an Internet Standards Track document. It's a product of the Internet Engineering Task Force (IETF), so 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 info on Internet Standards, check Section 2 of RFC 5741.

Info about this doc's current status, any errata, and how to send feedback lives at http://www.rfc-editor.org/info/rfc6935.

Copyright (c) 2013 IETF Trust and the persons identified as the document authors. All rights reserved 🦋.

This document 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 date this document was published. Please read these carefully, because they describe your rights and restrictions for this document. 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 without warranty, as the Simplified BSD License describes 🧾.

Table of Contents 🗂️

1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  3
  2.  Terminology  . . . . . . . . . . . . . . . . . . . . . . . . .  4
    2.1.  Requirements Language  . . . . . . . . . . . . . . . . . .  4
  3.  Problem Statement  . . . . . . . . . . . . . . . . . . . . . .  4
  4.  Discussion . . . . . . . . . . . . . . . . . . . . . . . . . .  4
    4.1.  Analysis of Corruption in Tunnel Context . . . . . . . . .  5
    4.2.  Limitation to Tunnel Protocols . . . . . . . . . . . . . .  7
    4.3.  Middleboxes  . . . . . . . . . . . . . . . . . . . . . . .  8
  5.  The Zero UDP Checksum Update . . . . . . . . . . . . . . . . .  9
  6.  Additional Observations  . . . . . . . . . . . . . . . . . . . 10
  7.  Security Considerations  . . . . . . . . . . . . . . . . . . . 10
  8.  Acknowledgments  . . . . . . . . . . . . . . . . . . . . . . . 11
  9.  References . . . . . . . . . . . . . . . . . . . . . . . . . . 11
    9.1.  Normative References . . . . . . . . . . . . . . . . . . . 11
    9.2.  Informative References . . . . . . . . . . . . . . . . . . 11

1. Introduction ✨

This doc is an update to the IPv6 spec [RFC2460] for cases where a tunnel protocol uses UDP with IPv6 to tunnel packets. As the Internet keeps growing, tunnel protocols have become super important for getting new protocols out there 🌸. Tunnel protocols can be rolled out fast, but getting a new protocol onto a critical mass of routers, middleboxes, and hosts across the global Internet takes decades 😭. On top of that, more firewalls and other security-related middleboxes means that brand-new tunnel protocols with new protocol numbers are also unlikely to be deployable in a reasonable time frame 💀.

So the result is more and more interest in, and use of, UDP-based tunnel protocols 🦋. In these protocols there's an encapsulated "inner" packet, and the "outer" packet carrying that inner packet is a UDP packet. That lets it get through firewalls and other middleboxes that filter traffic, which is just a fact of life on today's Internet 🙃.

Tunnel endpoints might be routers or middleboxes that aggregate traffic from a bunch of tunnel users. So computing an extra checksum on the outer UDP packet can feel like an unwarranted burden on nodes that run a tunnel protocol, especially when the inner packets are already protected by a checksum 🧮. IPv4 has a checksum over the IP packet header, and the checksum on the outer UDP packet may be set to zero. IPv6, though, has no checksum in the IP header, and RFC 2460 [RFC2460] explicitly states that IPv6 receivers MUST discard UDP packets with a zero checksum 🚫. So sending a UDP datagram with a zero checksum is permitted in IPv4 packets, but it is explicitly forbidden in IPv6 packets.

To improve support for IPv6 UDP tunnels, this doc updates RFC 2460 so endpoints can use a zero UDP checksum in constrained situations. The main use case is IPv6 tunnel transports that carry checksum-protected packets, and it follows the applicability statements and constraints in [RFC6936] 🎀.

When you read this doc, the advice in "Unicast UDP Usage Guidelines for Application Designers" [RFC5405] also applies. It covers both UDP tunnels (Section 3.1.3) and the usage of checksums (Section 3.4) 📚.

The origin of this spec is a problem raised by the draft titled "Automatic Multicast Tunnels", also known as "AMT" [AMT]. But we expect it to have wide applicability 🌈. Since the first draft of this RFC was written, the need for an efficient UDP tunneling mechanism has grown. Other IETF Working Groups, notably LISP [RFC6830] and Softwires [RFC5619], have said they need to update the UDP checksum processing in RFC 2460. So we expect this update to apply in the future to other tunnel protocols specified by these and other IETF Working Groups 🧚‍♀️.

2. Terminology 💅

This document discusses only IPv6, because the problem being addressed does not exist for IPv4. So all references to "IP" should be understood as references to IPv6 🫧.

The document uses the terms "tunneling" and "tunneled" as adjectives when describing packets. When we say "tunneling packets," we mean the outer packet header that provides the tunneling function. When we say "tunneled packets," we mean the inner packet, which is the packet being carried in the tunnel 🎁.

2.1. Requirements Language 💖

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 RFC 2119 [RFC2119] 📖.

3. Problem Statement 🔍

When you use tunnel protocols based on UDP, there can be both a benefit and a cost to computing and checking the UDP checksum of the outer (encapsulating) UDP transport header 🤔. In certain cases, where reducing forwarding cost matters a lot, the cost of the computation can outweigh the benefit of the checksum. This document provides an update for how the UDP checksum is used with IPv6. The update is specified for use by a tunnel protocol that transports packets that are themselves protected by a checksum 🫶.

4. Discussion 🦋

"Applicability Statement for the Use of IPv6 UDP Datagrams with Zero Checksums" [RFC6936] describes issues related to allowing UDP over IPv6 to have a valid zero UDP checksum, and it's the starting point for this discussion 🎯. Sections 4 and 5 of [RFC6936], respectively, identify node implementation and usage requirements for datagrams sent and received with a zero UDP checksum. These sections introduce constraints on using a zero checksum for UDP over IPv6 🔒.

The rest of this section analyzes the use of general tunnels and explains why tunnel protocols are being permitted to use the method described in this update. It also talks about issues with middleboxes 👀.

4.1. Analysis of Corruption in Tunnel Context ✨

okay so this section is where we look at what each kind of corruption actually does inside a tunnel protocol 🫶 It spells out what the designer and the user of a tunnel protocol need to think about to stay robust, and it also sums up why a zero UDP checksum is thought to be safe to deploy 💅

  • Context (i.e., tunneling state) should be set up by swapping application Protocol Data Units (PDUs) that ride in checksummed UDP datagrams, or by using other protocols that give integrity protection against corruption. These control packets should also carry any negotiation needed so the tunnel endpoint can accept UDP datagrams with a zero checksum and work out which set of ports is used. Control traffic has to be robust against corruption, bestie 😭 An undetected error can cause long-lived, serious failures that hit way more than the one packet that got corrupted.
  • Keepalive datagrams with a zero UDP checksum should be sent to validate the network path 🛣️ The path between tunnel endpoints can change, so the set of middleboxes along it may change during the life of an association. Paths with middleboxes that drop datagrams with a zero UDP checksum will drop these keepalives. So the tunnel endpoints can discover and react to this in a timely way, the keepalive traffic should include datagrams with a non-zero checksum and datagrams with a zero checksum.
  • Receivers should attempt to detect corruption of the address information in an encapsulating packet 👀 A robust tunnel protocol should track tunnel context based on the 5-tuple (tunneled protocol number, IPv6 source address, IPv6 destination address, UDP source port, UDP destination port). A corrupted datagram that arrives at a destination may get filtered based on this check.
    • If the datagram header matches the 5-tuple and the node has enabled the zero checksum for this port, the payload is matched to the wrong context. The tunneled packet will then be decapsulated and forwarded by the tunnel egress.
    • If a corrupted datagram matches a different 5-tuple and the node has enabled zero checksum for the port, the datagram payload is matched to the wrong context and may be processed by the wrong tunnel protocol, provided that it also passes the verification of that protocol.
    • If a corrupted datagram matches a 5-tuple and the node has not enabled the zero checksum for this port, the datagram will be discarded.

When only the source information is corrupted, the datagram could still reach the intended applications or protocol, which will process it and try to match it against an existing tunnel context. The chance that a corrupted packet enters a valid context goes down when the protocol restricts processing to only the source addresses with established contexts. When both source and destination fields are corrupted, that also lowers the chance of matching a context. The exception is when errors replace one packet header with another, so both packets could be tunneled, and then the corrupted packet could match a previously defined context 🫠

  • Receivers should attempt to detect corruption of source-fragmented encapsulating packets 🧩 A tunnel protocol may reassemble fragments associated with the wrong context at the right tunnel endpoint. It may reassemble fragments associated with a context at the wrong tunnel endpoint. Or corrupted fragments may be reassembled at the right context at the right tunnel endpoint. In each of these cases, the IPv6 length of the encapsulating header may be checked (although [RFC6936] points out the weakness in this check). And if the encapsulated packet is protected by a transport (or other) checksum, these errors can be detected, with some probability.
  • Compared to other applications, tunnel protocols using UDP have some advantages that reduce the risk of a corrupted tunnel packet reaching a destination that will accept it 💖 These advantages come from the network processing the inner (tunneled) packet after it is forwarded from the tunnel egress using a wrong context:
    • A tunneled packet may be forwarded to the wrong address domain, for example to a private address domain where the inner packet's address is not routable. It may also fail a source address check, such as Unicast Reverse Path Forwarding [RFC2827], and get dropped.
    • The destination address of a tunneled packet may not be reachable at all from the domain it was delivered to. An example is an Ethernet frame whose destination MAC address is not present on the LAN segment that was reached.
    • The type of the tunneled packet may prevent delivery. For example, trying to interpret an IP packet payload as an Ethernet frame would likely result in the packet being dropped as invalid.
    • The tunneled packet checksum or integrity mechanism may detect corruption of the inner packet that happened at the same time as corruption to the outer packet header. The resulting packet would likely be dropped as invalid.

Each of these checks really cuts down the chance that a corrupted inner tunneled packet ends up delivered to a protocol listener that it could affect 🙌 The methods don't guarantee correctness, but they can reduce the risks of relaxing the UDP checksum requirement for a tunnel application using IPv6.

4.2. Limitation to Tunnel Protocols 🎀

this document describes where it's appropriate to use a zero UDP checksum to support tunnel protocols, and there are really good motivations behind that. The arguments are laid out here 🌸

  • Tunnels carry inner packets that have their own semantics, which may make any corruption less likely to reach the indicated destination and be accepted as a valid packet. This holds for IP packets, thanks to the verification the tunnel protocol can do, the network processing of the inner packet headers we talked about above, and verification of the inner packet checksums. Non-IP inner packets are likely to see similar effects, which may reduce the likelihood of a misdelivered packet being delivered to a protocol listener that it could affect.
  • Protocols that directly consume the payload must have sufficient robustness against misdelivered packets (from any context), including ones corrupted in tunnels or corrupted by other usage of the zero checksum 🥺 This will require an integrity mechanism. Using a standard UDP checksum reduces the computational load on the receiver needed to verify this mechanism.
  • The design for stateful protocols, or for protocols where corruption causes cascade effects, requires extra care 🧠 In tunnel usage, each encapsulating packet provides no functions other than transport from tunnel ingress to tunnel egress. A corruption will commonly affect only the single tunneled packet, not the established protocol state. One common effect is that the inner packet flow sees only a corruption and a misdelivery of the outer packet, which looks like a lost packet.
  • Some non-tunnel protocols operate with general servers that don't know the source they'll receive a packet from. In those applications, a zero UDP checksum is unsuitable, because the first level of verification, that the packet was intended for the receiving server, is necessary 🚫 A verification prevents the server from processing the datagram payload. Without it, the server may spend significant resources processing the packet, including sending replies or error messages.

Tunnel protocols that encapsulate IP will generally be safe for deployment, because all IPv4 and IPv6 packets include at least one checksum at either the network or transport layer 💅 The network delivery of the inner packet then reduces the effects of corruption even further. Tunnel protocols carrying non-IP packets may offer equivalent protection when the non-IP networks reduce the risk of misdelivery to applications. However, further analysis is necessary to understand the implications of misdelivery of corrupted packets for each non-IP protocol 🔍 The analysis above suggests that non-tunnel protocols can be expected to have significantly more cases where a zero checksum would result in misdelivery or negative side effects.

One unfortunate side effect of increased use of a zero checksum is that it also increases the likelihood of acceptance when a datagram with a zero UDP checksum is misdelivered 😬 This requires all tunnel protocols using this method to be designed to be robust in the face of misdelivery.

4.3. Middleboxes 🧚

"Applicability Statement for the Use of IPv6 UDP Datagrams with Zero Checksums" [RFC6936] specifies requirements for middleboxes and for tunnels that need to traverse middleboxes 📜 Tunnel protocols intending to use a zero UDP checksum need to make sure they have defined a method for handling cases where a middlebox prevents the path between the tunnel ingress and egress from supporting transmission of datagrams with a zero UDP checksum. This is especially important, because middleboxes that conform to RFC 2460 are likely to discard datagrams with a zero UDP checksum 🥹 Main character energy: plan for the middlebox drama before it happens ✨

5. The Zero UDP Checksum Update ✨

okay so this section is the actual update bit 🦋 It says this spec updates IPv6 so a tunnel protocol can use a zero UDP checksum in its outer encapsulating datagram 💖 Any UDP endpoint that does this MUST follow the node requirements in "Applicability Statement for the Use of IPv6 UDP Datagrams with Zero Checksums" [RFC6936]. No skipping, bestie 💅

The next bit says the following text in [RFC2460], Section 8.1, fourth bullet should be deleted. Here's the original text being removed 👇

Unlike IPv4, when UDP packets are originated by an IPv6 node, the
UDP checksum is not optional.  That is, whenever originating a UDP
packet, an IPv6 node must compute a UDP checksum over the packet
and the pseudo-header, and, if that computation yields a result of
zero, it must be changed to hex FFFF for placement in the UDP
header.  IPv6 receivers must discard UDP packets containing a zero
checksum, and should log the error.

Then it says that text should be replaced by the new stuff below 🌸 Here's how the new version goes:

An IPv6 node associates a mode with each UDP port it uses, for sending and/or receiving packets 🎀

Whenever an IPv6 node originates a UDP packet for a port in the default mode, it MUST compute a UDP checksum over the packet and the pseudo-header. If that computation gives zero, the checksum MUST be changed to hex FFFF for placement in the UDP header, as specified in [RFC2460]. IPv6 receivers MUST by default discard UDP packets containing a zero checksum, and SHOULD log the error. Main character energy for the default path 👑

Now the alternative 🧚 Certain protocols that use UDP as a tunnel encapsulation MAY turn on zero-checksum mode for a specific port (or a set of ports) for sending and/or receiving. Any node running zero-checksum mode MUST follow the node requirements in Section 4 of "Applicability Statement for the use of IPv6 UDP Datagrams with Zero Checksums" [RFC6936]. ngl this part is where the vibes get serious 💀

Any protocol that turns on zero-checksum mode for a specific port or ports MUST follow the usage requirements in Section 5 of "Applicability Statement for the Use of IPv6 UDP Datagrams with Zero Checksums" [RFC6936] 🫶

Last one: middleboxes that support IPv6 MUST follow requirements 9, 10, and 11 of the usage requirements in Section 5 of "Applicability Statement for the Use of IPv6 UDP Datagrams with Zero Checksums" [RFC6936] 🔥

6. Additional Observations

okay so this update got made because a bunch of protocols being built in the IETF are expected to benefit from it 🌈 A few observations to note:

  • ngl the last real empirical study on how often packets get corrupted (with or without checksums) was around 2000, as far as the authors know 😭 It's now 2013, at publication time. The authors strongly suggest a new empirical study, plus a deep dive into how corruption probabilities hit the IPv6 header. That could let them revise the recommendations in this document 🔬
  • A big reason UDP is showing up more in tunneling is that middleboxes don't support the protocols people want. LISP [RFC6830], for example, may prefer UDP tunnels so it can get across an end-to-end path and avoid having its packets dropped by middleboxes 🦋 If middleboxes were updated to support UDP-Lite [RFC3828], UDP-Lite would protect better than this update does. UDP-Lite may suit a bunch of applications, and for many tunnel protocols it would be expected to be the preferred option over this method 💜
  • The UDP checksum is also overloaded: it has to protect the IPv6 header for UDP flows, same as the TCP checksum does for TCP flows 🙈 Protocols that don't use a pseudo-header approach to computing a checksum or CRC basically have no protection from misdelivered packets. Yikes 🍓

7. Security Considerations

okay this section is serious but also kinda iconic 👑

Generating an attack with a zero UDP checksum takes less work than with a standard full UDP checksum 😬 But this doesn't lead to any big new vulnerabilities, because checksums aren't a security measure, and any attacker can generate them easily 💅

In general, anyone using zero UDP checksums should run whatever checks and context verification are possible, to lower the risk of unintended traffic reaching a given context ✨ Heads up though: this won't protect against an intentional attack that creates packets with the correct information 🚨 Source address validation can help stop an attacker from injecting traffic into contexts 🛡️

Depending on the hardware design, processing requirements may be different for tunnels with a zero UDP checksum versus ones that calculate a checksum 🤓 That processing overhead might need to be considered when deciding whether to turn on a tunnel and figuring out an acceptable transmission rate. Here's the scary part 😭 The overhead can become a security risk for designs that handle way more zero-checksum packets than non-zero-checksum datagrams, like a tunnel egress. An attacker could try to inject non-zero checksummed UDP packets into a tunnel that forwards zero-checksum UDP packets, and overload the processing of the non-zero checksums. For example, this could happen in a router's slow path 🐢 So protection mechanisms should be used whenever this threat exists. Protection can include source-address filtering to stop an attacker injecting traffic, and throttling the amount of non-zero checksum traffic. Just know the throttling may impact how the tunnel protocol works 🥺

8. Acknowledgments

big thank you to Brian Haberman, Dan Wing, Joel Halpern, David Waltermire, J.W. Atwood, Peter Yee, Joe Touch, and the IESG of 2012 for the discussions and reviews 🫶 Gorry Fairhurst was super diligent about reviewing and helping keep this document and [RFC6936] lined up 🌸

9. References

9.1. Normative References

  • [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. 🌈
  • [RFC6936] Fairhurst, G. and M. Westerlund, "Applicability Statement for the Use of IPv6 UDP Datagrams with Zero Checksums", RFC 6936, April 2013. ✨

9.2. Informative References

  • [AMT] Bumgardner, G., "Automatic Multicast Tunneling", Work in Progress, June 2012. 🦋
  • [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. 🛡️
  • [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. 💜
  • [RFC5405] Eggert, L. and G. Fairhurst, "Unicast UDP Usage Guidelines for Application Designers", BCP 145, RFC 5405, November 2008. 🍓
  • [RFC5619] Yamamoto, S., Williams, C., Yokota, H., and F. Parent, "Softwire Security Analysis and Requirements", RFC 5619, August 2009. 🌸
  • [RFC6830] Farinacci, D., Fuller, V., Meyer, D., and D. Lewis, "The Locator/ID Separation Protocol (LISP)", RFC 6830, January 2013. 🧚

Authors' Addresses ✨

Marshall Eubanks
AmericaFree.TV LLC
P.O. Box 141
Clifton, Virginia  20124
USA

Phone: +1-703-501-4376
EMail: marshall.eubanks@gmail.com


P.F. Chimento
Johns Hopkins University Applied Physics Laboratory
11100 Johns Hopkins Road
Laurel, Maryland  20723
USA

Phone: +1-443-778-1743
EMail: Philip.Chimento@jhuapl.edu


Magnus Westerlund
Ericsson
Farogatan 6
SE-164 80 Kista
Sweden

Phone: +46 10 719 00 00
EMail: magnus.westerlund@ericsson.com

That's the whole RFC, bestie! 🌈💖 Zero checksums, but make it a whole vibe 💅

📦 where this page comes from