Applicability Statement for the Use of IPv6 UDP Datagrams with Zero Checksums
Extracted elements (27)
Among all alternatives evaluated (IP-in-IP, UDP-Lite, delta checksum, UDPTT, IPv6 Destination Options header, checksum-ignore), zero UDP checksum was selected as the best fit because it minimizes per-packet processing, works with the largest class of existing middleboxes, and is identifiable (unlike silent checksum-ignore).
For tunnel encapsulations, the inner payload (e.g., an IP packet) already carries its own integrity check, making the outer UDP checksum redundant. AMT replication also requires a different pseudo-header per tunnel egress, making full checksum computation an unwarranted burden for lightweight tunnel protocols.
Hardware routers commonly expose only the first ~128 bytes of a packet to their forwarding engine. Computing a full-datagram UDP checksum requires access to the entire packet, making RFC 2460's mandatory UDP checksum poorly suited for tunnel ingress/egress routers and impacting router design, performance, energy consumption, and cost.
IPv6 lacks a network-layer header checksum (unlike IPv4), so the UDP transport checksum in IPv6 is overloaded with functions including verifying destination address correctness, extension header delimitation, reassembly, payload length, port demultiplexing, and payload integrity. Removing the UDP checksum therefore has greater risk in IPv6 than in IPv4.
UDP-Lite was evaluated as an alternative but rejected for general Internet tunnel use because it uses a distinct IPv6 Next Header value that nearly all deployed middleboxes (load balancers, NATs, firewalls) do not recognize, making it less deployable than zero-checksum UDP.
A middlebox MUST NOT maintain separate state for a UDP flow based on the checksum field value; doing so would break bidirectional flows where one direction uses a calculated checksum and the other uses a zero checksum.
Firewalls and NATs conforming to RFC 2460 will regard zero-checksum IPv6 UDP datagrams as invalid and discard them. A NAT that increments the checksum field will also corrupt a zero-checksum datagram. Both must be updated before zero-checksum traffic can traverse them.
Fragmentation of datagrams with a zero UDP checksum does not worsen corruption detection compared to commonly used IP-in-IP tunnels, but recursive tunneling that applies fragmentation at multiple layers without per-layer verification significantly raises the probability of undetected errors.
A middlebox MUST allow forwarding of IPv6 UDP datagrams with both zero and standard checksums using the same UDP port, and MUST NOT maintain separate flow state depending on whether a datagram's UDP checksum field is zero or non-zero.
A port for which zero UDP checksum has been enabled MUST NOT log a received datagram solely because the checksum value is zero; however, datagrams received with zero checksum on ports that have not enabled it SHOULD still be logged per RFC 2460.
A transported protocol MUST be designed so that corruption of any header information does not result in accumulation of incorrect state; it must be robust when malformed or misdelivered packets arrive on a listening port.
A transported protocol with a non-tunnel payload or one encapsulating non-IP packets MUST include a CRC or other packet-integrity mechanism, unless the non-IP payload is specifically designed for a lower layer that does not provide packet integrity guarantees.
An integrity mechanism is always RECOMMENDED at the transported protocol layer to ensure that corruption rates of the delivered payload are not increased; a mechanism that isolates causes of corruption (misdelivery, IPv6 header corruption, tunnel header corruption) is also expected.
IPv6 nodes MUST provide a mechanism (e.g., socket API) for the application or protocol to indicate which ports are enabled to send datagrams with a zero UDP checksum.
IPv6 nodes MUST provide a method for an application or protocol to require that a particular UDP datagram be sent with a calculated checksum at any time, even when the socket is operating in zero-checksum mode (e.g., for keepalive datagrams).
IPv6 nodes SHOULD NOT, by default, allow the zero UDP checksum method for transmission.
IPv6 nodes supporting zero UDP checksum MUST also accept reception of datagrams with a calculated (non-zero) checksum on all ports configured for zero-checksum reception, and MUST apply the RFC 2460 reception method when the checksum field is not zero.
IPv6 nodes that receive ICMPv6 messages referring to packets with a zero UDP checksum MUST validate the consistency of the reported packet (address and port numbers) to verify that it actually originated from the node before acting on the ICMPv6 information.
Keepalive messages SHOULD include both UDP datagrams with a calculated checksum and datagrams with a zero UDP checksum, so the remote endpoint can distinguish between a general path failure and selective dropping of zero-checksum datagrams.
The default IPv6 receiver behavior MUST be to discard all IPv6 packets carrying UDP datagrams with a zero checksum; zero-checksum reception must be explicitly enabled per port.
Transported protocols SHOULD send keepalive messages with a zero UDP checksum to discover paths with middleboxes that drop zero-checksum packets; an endpoint that observes appreciable keepalive loss MAY terminate the tunnel.
Transported protocols that enable zero UDP checksum MUST enable this only for a specific port or port range, and this must be enabled at both the sending and receiving endpoints for a UDP flow.
Path validation is required before relying on zero UDP checksum: a sender must probe the path, because middleboxes conforming to RFC 2460 will discard zero-checksum datagrams. A bidirectional path does not necessarily support zero checksum in both directions, and path characteristics may change, requiring periodic re-validation.
The zero UDP checksum method for IPv6 is defined in RFC 6935 and is applicable only to specific protocols or tunnel encapsulations that explicitly opt in on a per-port basis. It is not a general replacement for the mandatory checksum defined in RFC 2460, and IPv6 with zero UDP checksum is not equivalent to IPv4 with zero UDP checksum.
If a tunnel egress handles zero-checksum packets in the fast path but non-zero checksum packets in the slow path, an attacker can inject non-zero checksummed packets to cause overload. Protection must include source-address filtering and rate-limiting of non-zero checksum traffic on zero-checksum tunnel ports.
Probing the network path to determine whether it supports zero UDP checksum packets can reveal the operating system or tunnel type to an on-path observer. If the probing mechanism is visible in the network (e.g., not protected by IPsec), it discloses configuration information.
Transport checksums serve as the first stage of stack protection and enable accurate packet counter logging and detection of unusual behaviors; removing the UDP checksum for IPv6 requires compensating integrity mechanisms at the tunnel or application layer to preserve these properties.