IPv6 and UDP Checksums for Tunneled Packets
updates
- rfc-2460 — Internet Protocol, Version 6 (IPv6) Specification
Extracted elements (21)
Context establishment (tunneling state) must use checksummed UDP or other integrity-protected protocols so that undetected errors cannot create long-lived, widespread failures affecting more than a single corrupted packet.
In tunnel usage, each outer encapsulating packet provides only transport from ingress to egress; a corruption typically affects only that single tunneled packet rather than cascading into protocol state. This limits the blast radius of undetected corruption compared to stateful non-tunnel protocols.
IPv4 allows zero UDP checksum because IPv4 has a checksum over the IP header. IPv6 has no IP header checksum, so RFC 2460 explicitly forbade zero UDP checksums. This update relaxes that rule specifically for tunnel protocols whose inner packets carry their own checksums.
The UDP checksum is overloaded with the task of protecting the IPv6 header for UDP flows (analogous to TCP checksum for TCP). Protocols that do not use a pseudo-header approach to checksums have essentially no protection from misdelivered packets.
UDP-based tunneling is increasingly necessary because deploying new protocol numbers on a critical mass of routers and middleboxes now takes decades, while UDP passes through firewalls and other middleboxes. This motivates allowing zero UDP checksums to reduce tunnel endpoint overhead.
UDP-Lite (RFC 3828) would provide better protection than zero UDP checksums but lacks middlebox support. If middleboxes were updated to support UDP-Lite, it would be preferred over the zero-checksum method for many tunnel protocols.
Zero UDP checksum is restricted to tunnel protocols because tunneled (inner) packets carry their own checksums or integrity mechanisms, providing a second layer of corruption detection. Non-tunnel protocols that directly consume the payload must rely on the UDP checksum for first-level verification and therefore cannot safely use a zero checksum.
Middleboxes that conform to RFC 2460 are likely to discard datagrams with a zero UDP checksum. Tunnel protocols intending to use zero UDP checksum MUST define a method for handling cases when a middlebox prevents the path from supporting such datagrams.
Tunnel protocols carrying non-IP inner packets require further analysis before using zero UDP checksums; IP inner packets are generally safe because all IPv4 and IPv6 packets include at least one checksum at the network or transport layer.
Any node implementing zero-checksum mode MUST follow the node requirements specified in Section 4 of RFC 6936 ('Applicability Statement for the Use of IPv6 UDP Datagrams with Zero Checksums').
Any protocol that enables zero-checksum mode for a specific port or ports MUST follow the usage requirements specified in Section 5 of RFC 6936.
IPv6 receivers MUST by default discard UDP packets containing a zero checksum and SHOULD log the error. This default behavior is preserved from RFC 2460; only explicitly configured zero-checksum-mode ports are exempted.
Keepalive datagrams with a zero UDP checksum SHOULD be sent to validate the network path, and keepalive traffic should include both zero-checksum and non-zero-checksum datagrams so that endpoints can discover middleboxes that drop zero-checksum packets.
Middleboxes supporting IPv6 MUST follow requirements 9, 10, and 11 of the usage requirements specified in Section 5 of RFC 6936, which govern handling of datagrams with zero UDP checksums.
Receivers SHOULD attempt to detect corruption of the address information in an encapsulating packet by checking against the established tunnel context 5-tuple. They SHOULD also attempt to detect corruption of source-fragmented encapsulating packets.
Whenever originating a UDP packet for a port in the default mode, an IPv6 node MUST compute a UDP checksum over the packet and pseudo-header; if that computation yields zero, the checksum MUST be changed to hex FFFF before placement in the UDP header.
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). This 5-tuple check provides a first filter against misdelivered or corrupted datagrams.
An IPv6 node associates a mode—default or zero-checksum—with each used UDP port (for sending and/or receiving). Zero-checksum mode is an opt-in per-port configuration permitted only for specific tunnel encapsulation protocols.
If hardware processes zero-checksum UDP packets faster than non-zero-checksum packets, an attacker can inject non-zero-checksum packets into a tunnel that forwards zero-checksum packets to cause overload in the slow path. Protection mechanisms such as source-address filtering and throttling of non-zero-checksum traffic should be employed.
Less work is required to generate an attack using a zero UDP checksum than a standard checksum, but this does not introduce significant new vulnerabilities because checksums are not a security measure and can be trivially computed by any attacker.
Source address validation can help prevent injection of traffic into tunnel contexts by an attacker, but will not protect against an intentional attacker who forges correct source information. Zero-checksum users should apply all available context verification checks to minimize misdelivery risk.