skip to content

Why is the UDP checksum optional over IPv4 but mandatory over IPv6, and what does its pseudo-header protect against?

level: middleimportance: must knowfreq 40%

answer

  1. which IP version has a header checksum
  2. zero means not computed
  3. addresses folded into the sum
  4. misdelivered datagram, wrong host
  5. tunnel exception, RFC 6935/6936

basics

~20 s

Over IPv4, RFC 768 lets a sender put zero for no checksum, and the IPv4 header checksum still guards the addresses. IPv6 has no header checksum, so UDP's checksum over a pseudo-header of the addresses is mandatory to catch corrupted or misdelivered packets.

solid answer

~40 s

The UDP checksum is a 16-bit one's-complement sum over a **pseudo-header** (source and destination IP addresses, protocol number and UDP length), the UDP header and the data. Because the addresses are in the sum, a datagram whose IP header was corrupted into another destination fails the check, which RFC 768 calls protection against misrouted datagrams. Over IPv4, RFC 768 allowed a zero checksum to mean "not computed", and the IPv4 header checksum still protects the addresses; RFC 1122 requires hosts to default to computing it anyway. IPv6 has no header checksum, so RFC 8200 §8.1 makes the UDP checksum mandatory and tells receivers to discard a zero checksum. The only exception is UDP tunnels, which may enable zero-checksum mode on specific ports under RFC 6935 and RFC 6936.

code

pseudocode · 11 lines
pseudocode
function udp_checksum(src_ip, dst_ip, udp_len, udp_header, data):
    pseudo = src_ip ++ dst_ip ++ zero_byte ++ protocol(17) ++ udp_len
    header = udp_header with checksum field set to 0
    bytes  = pseudo ++ header ++ data
    if length(bytes) is odd:
        bytes = bytes ++ zero_byte
    sum = ones_complement_sum_of_16bit_words(bytes)
    result = ones_complement(sum)
    if result == 0x0000:
        result = 0xFFFF      # zero on the wire would mean 'not computed'
    return result

go deeper

for a junior

Remember that the checksum is optional over IPv4 and mandatory over IPv6, and that zero in the field over IPv4 means no checksum was computed.

for a middle

Explain the pseudo-header's contents and purpose, the missing IPv6 header checksum as the reason for the IPv6 rule, and the 0xFFFF encoding of a computed zero.

for a senior

Discuss the RFC 6935/6936 tunnel exception and its conditions, why address-rewriting devices must update the checksum, and why applications needing integrity add their own hash.

for a principal

Weigh per-packet checksum cost against end-to-end protection when designing an encapsulation, and explain why IPv6 moved address protection out of the network layer.

## What the checksum covers The UDP `Checksum` field is 16 bits. RFC 768 defines it as the **one's complement of the one's-complement sum** of three things, padded with a zero octet if the total length is odd: 1. A **pseudo-header** built from the IP layer: source address, destination address, a zero byte, the protocol number (17 for UDP) and the UDP length. 2. The UDP header itself, with the checksum field taken as zero during computation. 3. The data. The pseudo-header is never transmitted. Both ends reconstruct it from the IP header they send or receive. Its purpose, in RFC 768's words, is "protection against misrouted datagrams": if a bit error in the IP header changes the destination address, the datagram may still arrive somewhere, but the receiver's pseudo-header will not match the sender's and the checksum fails. RFC 8085 §3.4 adds that because the sum covers addresses, ports, protocol and the length field, it also detects a datagram that was truncated or padded in transit. Over IPv6 the pseudo-header has the same shape with 128-bit addresses, a 32-bit upper-layer length and the `Next Header` value 17 (RFC 8200 §8.1). ## Why IPv4 could make it optional - The **IPv4 header carries its own checksum**, so corruption of the addresses can be caught at the IP layer; RFC 8085 §3.4.1 notes that the IPv4 header validates information an IPv6 packet leaves unprotected. - RFC 768 let a sender transmit **zero** to mean "no checksum was generated", describing it as useful "for debugging or for higher level protocols that don't care". - That created one ambiguity: a sum that genuinely computes to zero. RFC 768 resolves it by sending **all ones** (0xFFFF) instead, which is the same value in one's-complement arithmetic. RFC 1122 §4.1.3.4 notes this as a common implementation error and says no special action is needed at the receiver. - RFC 1122 then tightened host behaviour: a host MUST be able to generate and validate UDP checksums, MUST **default to checksumming on**, and MUST silently discard a datagram whose non-zero checksum is invalid. An application MAY be allowed to turn generation off, and MAY choose whether to accept datagrams that arrive with no checksum. So "optional over IPv4" means optional for the sender, strongly discouraged, and off only by explicit choice. ## Why IPv6 made it mandatory IPv6 has **no header checksum** at all. That moves the job of protecting the addresses to the transport. RFC 8200 §8.1 states the result directly: - an IPv6 node originating a UDP packet **must compute** the checksum over the packet and the pseudo-header; - a computed zero is sent as **0xFFFF**; - IPv6 receivers **must discard** UDP packets that carry a zero checksum, and should log the error. RFC 6936 gives the reason in one line: IPv6 mandates a calculated UDP checksum "due to the lack of an IPv6 header checksum". Without it, a corrupted destination address in an IPv6 packet would go undetected all the way to the application. | | UDP over IPv4 | UDP over IPv6 | |---|---|---| | IP header checksum | yes | none | | Zero in checksum field | allowed, means "not computed" | receiver discards the packet | | Computed sum of zero | sent as 0xFFFF | sent as 0xFFFF | | Specification | RFC 768, RFC 1122 §4.1.3.4 | RFC 8200 §8.1 | | Exception | not needed | UDP tunnels, RFC 6935 / RFC 6936 | ## The tunnel exception Tunnel protocols that carry whole packets inside UDP found the mandatory checksum costly, because the inner packet usually carries its own checksum. **RFC 6935** relaxes the IPv6 rule for such tunnels, and **RFC 6936** is the applicability statement that sets the conditions. RFC 8085 §3.4.1 summarises them: checksumming MUST remain the default, a receiver MUST enable zero-checksum mode only on specifically configured destination ports, and the application MUST add its own measures to stop mis-delivered traffic leaking to other applications. Middleboxes that validate or rewrite the UDP checksum will not pass zero-checksum IPv6 datagrams, which limits where the mode works. ## What the checksum does not do - It is **weak**: RFC 8085 §3.4 says it is not strong from a coding or cryptographic perspective and is not designed to catch malicious modification. Applications that care about integrity SHOULD add a CRC or a hash of their own. - It does not make UDP reliable. A datagram that fails the check is dropped silently; nobody is told. - It must be updated by any device that rewrites addresses or ports, because both are inside the sum. ## How interviewers probe it Expect "what is a pseudo-header", "why does IPv6 care more", and "what if the real sum is zero". A good answer names the missing IPv6 header checksum as the reason, the 0xFFFF rule for the edge case, and the tunnel exception as the one sanctioned way to send zero over IPv6.

  • If a UDP sender computes a checksum that comes out as zero, what does it put in the header, and why?
    It sends all ones, 0xFFFF. RFC 768 reserves a transmitted zero to mean "no checksum generated", and in one's-complement arithmetic 0x0000 and 0xFFFF are equal, so the receiver's verification still succeeds. RFC 1122 §4.1.3.4 flags missing this as a common implementation error, and RFC 8200 §8.1 repeats the rule for IPv6.
  • Under what conditions may an IPv6 UDP sender transmit a zero checksum?
    Only for a UDP tunnel encapsulation, under RFC 6935 and the requirements of RFC 6936. Checksumming must remain the default, the receiver must enable zero-checksum mode only on specific destination ports, and the application must guard against mis-delivered traffic reaching other applications. Middleboxes that validate the checksum may still drop such packets.
  • Is a valid UDP checksum enough to trust that the data is intact?
    No. RFC 8085 §3.4 describes it as a statistical check that is not strong from a coding or cryptographic perspective and does not detect malicious modification. Where integrity matters, the application SHOULD add its own CRC or a keyed or unkeyed hash over the data.

saying these in an interview costs you the question

  • The UDP checksum covers only the UDP header, not the data
  • IPv6 also has a header checksum, so UDP's is redundant there
  • A UDP checksum field of zero means the computed sum was zero
  • The pseudo-header is transmitted in front of the UDP header
  • A valid UDP checksum proves the data was not tampered with
  • IPv6 never allows a zero UDP checksum under any circumstances