Computer NetworksUDP Protocol

UDP Checksum

LevelIntermediate

Duration60 mins

TopicUDP Protocol

3 / 5

Optional in IPv4

The Optional Checksum: A Legacy of Trust

If you examine UDP's specification in RFC 768 (published in 1980), you'll find a surprising statement about the checksum field:

"Checksum is the 16-bit one's complement of the one's complement sum... If the computed checksum is zero, it is transmitted as all ones (the equivalent in one's complement arithmetic). An all zero transmitted checksum value means that the transmitter generated no checksum."

This single sentence reveals a remarkable fact: in IPv4, the UDP checksum is entirely optional. A transmitter may choose to skip checksum calculation entirely by setting the checksum field to zero. When a receiver sees a zero checksum, it knows the sender opted out—and the receiver accepts the datagram without any integrity verification.

In an era where data integrity is paramount, this seems almost reckless. Why would a protocol designer make such a critical safety feature optional? The answer lies in the historical context of early internetworking—and understanding it illuminates important lessons about protocol design, performance trade-offs, and the evolution of network engineering.

What You Will Learn

By the end of this page, you will understand why the UDP checksum was made optional in IPv4, the historical and technical factors behind this decision, when (if ever) disabling the checksum is appropriate, how to disable it in practice, the security and reliability implications, and why modern guidance strongly recommends against disabling it.

Historical Context: The Internet of 1980

To understand why the UDP checksum is optional, we must transport ourselves to 1980—when UDP was standardized. The Internet of that era was radically different from today's:

Computing landscape in 1980:

CPU cycles were precious — A typical minicomputer might have a 1 MHz processor. Calculating checksums for every packet consumed significant resources.
Memory was expensive — Systems might have 64KB of RAM. Every operation had to be lean.
Networks were small and trusted — The ARPANET connected a few dozen nodes, mostly at universities and research labs. All participants were known.
Link-layer integrity was assumed — Point-to-point links typically had their own error detection (like HDLC CRC).
Real-time applications existed — Voice and early video experiments valued timeliness over perfect accuracy.

The trust model:

In 1980, the "Internet" was a research network connecting trusted institutions. The threat model didn't include malicious actors injecting corrupted packets. Network infrastructure was managed by cooperative researchers who could be trusted to maintain equipment properly.

The Internet: 1980 vs. Today
Aspect	1980	Today
Number of hosts	~200 nodes	30 billion devices
Typical CPU speed	1-10 MHz	3-5 GHz (1000x faster)
Network trust	All known, trusted parties	Anonymous, adversarial actors
Link technologies	Dedicated lines, mostly terrestrial	Wireless, satellite, shared media
Typical latency concern	Seconds acceptable	Milliseconds matter
Checksum cost (relative)	Significant CPU burden	Trivial, often hardware-accelerated
Threat model	Accidental errors only	Active attacks, widespread corruption

The Engineering Mindset of the Era

Early protocol designers practiced extreme frugality. Every byte mattered, every CPU cycle counted. Making features optional wasn't carelessness—it was pragmatism. If a feature wasn't always needed, it shouldn't always cost. The 'end-to-end principle' emphasized putting complexity at the edges, not mandating it universally.

The rationale for optional checksums:

Performance on slow machines — Checksumming UDP headers and payloads on a 1 MHz processor could measurably slow throughput
Layered redundancy — If Ethernet already has a CRC, and the application verifies data, why checksum in the middle too?
Real-time tolerance — Voice traffic would rather drop a corrupted sample than delay playback to detect corruption
End-to-end philosophy — If the application needs integrity, it should verify; forcing UDP to do it wastes resources for apps that don't care
Trusted environments — On a local, trusted network with reliable links, corruption was rare

This reasoning made sense in 1980. Today, most of these conditions have reversed—yet the specification remains unchanged for backward compatibility.

How Optional Checksums Work

The mechanism for optional checksums is simple but requires precise understanding to implement correctly.

Sender behavior:

To compute checksum: Calculate as normal; if result is 0x0000, transmit 0xFFFF instead
To skip checksum: Set the checksum field to 0x0000 (all zeros)

Receiver behavior:

If checksum field is 0x0000: Sender skipped checksum; accept datagram without verification
If checksum field is non-zero: Verify checksum; drop if invalid

The 0x0000 vs 0xFFFF distinction:

Checksum field value: 0x0000 → "No checksum computed by sender"
Checksum field value: 0xFFFF → "Checksum was computed and happened to be zero"
                               (Remember: we convert 0x0000 → 0xFFFF before sending)
Checksum field value: other  → "Checksum was computed; verify at receiver"

This encoding allows us to distinguish between "checksum not computed" and "checksum equals zero" unambiguously.

optional_checksum_handling.py
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
import struct
 
class UDPChecksumMode:
    """Demonstrates UDP checksum optional handling for IPv4."""
    
    @staticmethod
    def create_udp_header(
        src_port: int,
        dst_port: int,
        payload_length: int,
        checksum: int = None  # None means compute, 0 means skip
    ) -> bytes:
        """
        Create UDP header with optional checksum.
        
        Args:
            src_port: Source port number
            dst_port: Destination port number
            payload_length: Length of UDP payload
            checksum: None to compute, 0 to skip, or specific value
        
        Returns:
            8-byte UDP header
        """
        udp_length = 8 + payload_length
        
        if checksum is None:
            # Checksum will be computed later
            # This is a placeholder
            checksum_value = 0x0000
        elif checksum == 0:
            # Explicitly skip checksum (IPv4 only!)
            checksum_value = 0x0000
        else:
            checksum_value = checksum
        
        return struct.pack(
            '!HHHH',
            src_port,
            dst_port,
            udp_length,
            checksum_value
        )
    
    @staticmethod
    def process_received_checksum(checksum_field: int, data: bytes) -> str:
        """
        Process received UDP checksum according to IPv4 rules.
        
        Args:
            checksum_field: Value from UDP header checksum field
            data: Complete data for verification (pseudo-hdr + segment)
        
        Returns:
            Status string describing outcome
        """
        if checksum_field == 0x0000:
            # Sender skipped checksum
            return "ACCEPTED_NO_CHECKSUM (sender opted out)"
        
        # Verify checksum
        # Calculate sum including the checksum field
        total = 0
        padded = data if len(data) % 2 == 0 else data + b'\x00'
        for i in range(0, len(padded), 2):
            word = (padded[i] << 8) + padded[i + 1]
            total += word
            while total > 0xFFFF:
                total = (total & 0xFFFF) + (total >> 16)
        
        if total == 0xFFFF:
            return "ACCEPTED_VALID_CHECKSUM"
        else:
            return f"REJECTED_INVALID_CHECKSUM (sum=0x{total:04X})"
 
# Demonstration
print("Creating UDP header with checksum skipped (IPv4 allowed):")
hdr = UDPChecksumMode.create_udp_header(12345, 53, 100, checksum=0)
print(f"  Header hex: {hdr.hex()}")
print(f"  Checksum bytes: {hdr[6:8].hex()} (0x0000 = skipped)")

Protocol Implementation Warning

When implementing UDP, you must correctly handle the zero checksum case. A common bug is treating 0x0000 as an error rather than 'no checksum'. Another bug is allowing checksum skipping in IPv6, where it's forbidden. Test both paths explicitly.

When Skipping Might Make Sense (Historical & Edge Cases)

While modern guidance strongly recommends against disabling UDP checksums, there are historical and extremely niche scenarios where it was or could be considered:

Scenario 1: Embedded Systems with Severe Constraints (Historical)

In the 1980s and 1990s, tiny microcontrollers with 8-bit CPUs and kilobytes of RAM ran network stacks. Checksum calculation consumed precious cycles and could limit throughput on these constrained devices.

Example: Early weather sensors, industrial controllers
  - 8 MHz 8-bit CPU
  - 4KB RAM total
  - Sending 100 readings/second
  - Checksum adds 5-10% CPU overhead
  - Trusted, local, wired network

Scenario 2: Tunneling Protocols with Inner Checksums

When UDP encapsulates another protocol that already has its own integrity check:

┌─────────────────────────────────────────────────┐
│ IP Header                                       │
├─────────────────────────────────────────────────┤
│ UDP Header (checksum could be skipped)          │
├─────────────────────────────────────────────────┤
│ ┌─────────────────────────────────────────────┐ │
│ │ Inner Protocol                              │ │
│ │ (with its own checksum/integrity check)     │ │
│ └─────────────────────────────────────────────┘ │
└─────────────────────────────────────────────────┘

If the inner protocol verifies integrity, the outer UDP checksum is redundant. However, this argument is weaker than it appears—we'll discuss why shortly.

Checksum Skipping Decision Matrix
Condition	Skip Checksum?	Rationale
Modern general-purpose system	NO	CPU overhead is trivial; integrity is critical
Untrusted network (Internet)	NEVER	Corruption and attacks are real threats
Trusted LAN with reliable hardware	Probably not	Hardware offload makes it free anyway
Real-time audio/video over local LAN	Maybe	Latency matters; app handles quality
Tunneled protocol with inner integrity	Consider	But header corruption still matters
IPv6	NOT ALLOWED	Specification mandates checksum
Any security-sensitive application	NEVER	Integrity is foundational to security

Modern Recommendation: Always Compute

RFC 1122 (Host Requirements) states: 'An application MAY optionally be able to control whether a UDP checksum will be generated, but it MUST default to checksumming on.' Modern interpretation: always leave it on. The 'optional' feature is a historical artifact, not a recommended practice.

Why the redundancy argument is flawed:

Even when the inner protocol has integrity checks, the UDP checksum covers information the inner protocol cannot verify:

Port numbers: Wrong ports could cause misrouting to wrong application
Length field: Corruption could cause buffer issues
IP addresses (via pseudo-header): Inner protocol doesn't know about these

Skipping the checksum saves almost nothing on modern systems while creating real risks. The few nanoseconds saved aren't worth the potential for silent data corruption.

The Risks of Skipping the Checksum

Let's examine concrete scenarios where skipping the UDP checksum causes real problems.

Risk 1: Misdelivery to Wrong Application

If the destination port is corrupted, the datagram goes to the wrong application:

Intended:   Port 53 (DNS server)    → DNS query processed correctly
Corrupted:  Port 5353 (mDNS)        → mDNS receives garbage, may crash
            Port 530 (RPC)          → RPC receives malformed request
            Port 5300 (some app)    → Unknown behavior

Without checksum verification, the receiving application has no warning that the data was meant for someone else.

Risk 2: Silent Data Corruption

Payload corruption passes through undetected:

Original payload:  "temperature=25.0°C"
Corrupted payload: "temperature=35.0°C"  (bit flip: 25→35)

Without checksum: Receiver logs incorrect temperature
With checksum: Packet dropped; sender retries or app handles missing data

Real-World Corruption Sources

•Memory errors in network equipment — Routers and switches have RAM; ECC isn't universal
•Cosmic rays — High-energy particles flip bits; one study estimated ~1 error/GB/month
•Faulty cables and connectors — Damaged wiring introduces noise
•Overheating hardware — Thermal issues cause bit errors
•Software bugs in routers — Firmware bugs can corrupt packets
•Power fluctuations — Unstable power affects signal integrity
•Wireless interference — Even with link-layer CRC, errors slip through

The 'Ethernet Has CRC' Fallacy

A common argument for skipping UDP checksums is 'Ethernet already checks integrity.' This ignores that (1) corruptions can occur AFTER the Ethernet CRC is stripped by the NIC, (2) packets traverse multiple hops with potential corruption at each, (3) the CRC is per-link, not end-to-end, (4) some corruption patterns can pass both Ethernet CRC and reach the CPU.

Risk 3: Security Implications

Without checksum validation, attackers have more room to craft malicious packets:

Easier packet injection: Attacker doesn't need to compute valid checksum
Bypass detection: IDS/IPS may not flag packets with no checksum to verify
Exploitation: Malformed data more likely to trigger parser bugs

Case study: The Stone et al. study (2000)

Researchers found that 1 in ~10,000 TCP segments arriving at busy web servers had valid TCP checksums but corrupted data (the corruption eluded detection). TCP's checksum is identical to UDP's. If this happens with checksums enabled, imagine the error rate with checksums disabled.

Risk 4: Loss of Cross-Layer Protection

The pseudo-header includes IP addresses. Without checksum verification:

Corrupted source IP: Replies go to wrong host
Corrupted destination IP already caused misdelivery
Protocol field corruption: Wrong transport handler

The checksum is the only mechanism catching these cross-layer inconsistencies.

How to Disable Checksums (And Why You Shouldn't)

For completeness and understanding—not as a recommendation—here's how UDP checksum generation can be disabled on various systems.

Linux:

Linux provides a socket option to disable UDP checksums:

int fd = socket(AF_INET, SOCK_DGRAM, 0);
int disable = 1;
setsockopt(fd, SOL_SOCKET, SO_NO_CHECK, &disable, sizeof(disable));

Alternatively, with raw sockets, you have complete control over the checksum field.

BSD/macOS:

Similar to Linux, but the option may be named differently or unsupported on some versions.

Windows:

Windows doesn't expose a simple option to disable UDP checksums. Raw sockets or NDIS drivers would be required.

Most applications:

Standard socket APIs (like Python's socket module) don't expose checksum control. The OS handles checksums automatically. You'd need low-level access to modify this behavior.

linux_no_check_example.c
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
/* 
 * Example: Disabling UDP checksum on Linux
 * WARNING: This is for educational purposes only!
 * DO NOT USE IN PRODUCTION
 */
 
#include <sys/socket.h>
#include <netinet/in.h>
#include <netinet/udp.h>
#include <stdio.h>
 
int create_udp_socket_no_checksum(void) {
    int fd = socket(AF_INET, SOCK_DGRAM, 0);
    if (fd < 0) {
        perror("socket");
        return -1;
    }
    
    /*
     * SO_NO_CHECK disables checksum generation on transmit.
     * Note: This is IPv4 only! IPv6 mandates checksums.
     * Note: Received packets with checksum=0 are always accepted.
     */
    int disable = 1;
    if (setsockopt(fd, SOL_SOCKET, SO_NO_CHECK, 
                   &disable, sizeof(disable)) < 0) {
        perror("setsockopt SO_NO_CHECK");
        /* Not all kernels support this; continue anyway */
    } else {
        printf("WARNING: UDP checksum disabled!\n");
        printf("This socket will send UDP with checksum=0\n");
    }
    
    return fd;
}
 
/*
 * Why you should NOT do this:
 * 1. Corruption in payload won't be detected
 * 2. Corruption in pseudo-header (IPs, ports) won't be detected
 * 3. Saves negligible CPU with modern hardware offloading
 * 4. Creates hard-to-diagnose data integrity bugs
 * 5. Violates modern best practices (RFC 1122)
 */

Seriously, Don't Do This

There is almost no legitimate reason to disable UDP checksums in modern systems. Hardware checksum offloading means the CPU cost is zero anyway. The tiny performance gain is vastly outweighed by the risk of undetected corruption. If you're tempted to disable checksums for 'performance', profile first—you'll find the checksum isn't your bottleneck.

When the kernel computes checksums:

Even if you don't explicitly disable checksums, timing matters:

Without offloading: Kernel computes checksum in software during sendmsg()
With TX offloading: Kernel writes placeholder; NIC computes in hardware

With offloading enabled (the default on modern systems), the CPU never calculates the checksum anyway. Disabling it saves literally nothing.

Checking if offloading is active:

# Linux: Check UDP checksum offloading
ethtool -k eth0 | grep tx-checksum
# Output example:
# tx-checksum-ipv4: on
# tx-checksum-ipv6: on

If offloading is on (and it usually is), you're arguing about zero CPU cycles.

Modern Guidance and Best Practices

Contemporary network engineering guidance is clear: always compute UDP checksums over IPv4.

RFC Guidance:

RFC 1122 (Host Requirements, 1989):

"An application MAY optionally be able to control whether a UDP checksum will be generated, but it MUST default to checksumming on."

RFC 8085 (UDP Usage Guidelines, 2017):

"An application SHOULD enable UDP checksums." "Applications that disable UDP checksums need to understand that they will be unable to detect UDP datagram corruption."

Industry practice:

Major protocol implementations always enable checksums:

DNS servers compute checksums
DHCP servers compute checksums
Streaming protocols compute checksums
Gaming servers compute checksums
VoIP systems compute checksums

Even time-sensitive applications use checksums because hardware offloading makes them free.

Modern Best Practices Summary

•Always enable UDP checksums — There's no good reason not to on modern hardware
•Enable hardware offloading — Let the NIC compute checksums for zero CPU cost
•Verify your implementation — Test that checksums are actually being computed
•Don't assume link-layer suffices — End-to-end integrity requires transport-layer verification
•Add application-layer integrity — For critical data, layer additional checks (HMAC, signatures)
•Validate on receive — Don't accept zero-checksum packets from untrusted sources without consideration

Defense in Depth

The UDP checksum is one layer of defense. For high-value data, add more: application-level checksums (CRC32, SHA256), message authentication codes (HMAC), end-to-end encryption (which provides integrity via AEAD), and/or protocol-level acknowledgments. Each layer catches different failure modes.

What about performance-critical applications?

If you're building a high-frequency trading system, real-time game server, or video streaming platform where every microsecond matters:

Profile first — Is checksum actually your bottleneck? (It almost never is.)
Enable hardware offloading — CPU cost becomes zero
Use kernel bypass (DPDK, etc.) — If you're this performance-sensitive, you'll implement checksums in your low-latency stack anyway
Measure both ways — Compare throughput/latency with and without; the difference is typically unmeasurable

The bottom line:

The option to skip checksums is a 45-year-old concession to 1980s hardware limitations. It has no place in modern network engineering. Enable checksums, let hardware accelerate them, and focus your optimization efforts elsewhere.

Receiving Zero-Checksum Packets

As a receiver, you may encounter UDP packets with checksum = 0. How should you handle them?

Receiver obligations per specification:

The receiver MUST accept packets with zero checksum without verification. There's no option to reject them—if the checksum field is zero, the sender legitimately opted out.

Practical considerations:

You can't tell if data is corrupted — The payload might be garbage, and you won't know
Application must handle bad data — Robust parsing, input validation become critical
Logging is advisable — Consider logging or counting zero-checksum packets for diagnostics
Firewall filtering — In security-sensitive contexts, you might drop zero-checksum packets at the firewall (though this violates the spec)

handle_zero_checksum.py
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
import struct
import logging
 
logger = logging.getLogger(__name__)
 
class UDPReceiver:
    """Handles receiving UDP datagrams with zero-checksum awareness."""
    
    def __init__(self, strict_mode: bool = False):
        """
        Args:
            strict_mode: If True, log warnings for zero-checksum packets
        """
        self.strict_mode = strict_mode
        self.zero_checksum_count = 0
        self.validated_count = 0
        self.failed_count = 0
    
    def process_udp_segment(
        self,
        pseudo_header: bytes,
        udp_segment: bytes
    ) -> tuple[bool, bytes, str]:
        """
        Process a received UDP segment.
        
        Returns:
            (accepted, payload, status_message)
        """
        # Extract checksum from UDP header
        checksum = struct.unpack('!H', udp_segment[6:8])[0]
        
        if checksum == 0x0000:
            # Zero checksum: sender opted out (IPv4 only)
            self.zero_checksum_count += 1
            
            if self.strict_mode:
                logger.warning(
                    f"Received UDP packet with no checksum "
                    f"(count: {self.zero_checksum_count})"
                )
            
            # Per spec, we MUST accept without verification
            payload = udp_segment[8:]
            return (True, payload, "ACCEPTED_NO_CHECKSUM")
        
        else:
            # Non-zero checksum: verify
            data = pseudo_header + udp_segment
            if len(data) % 2 == 1:
                data += b'\x00'
            
            total = 0
            for i in range(0, len(data), 2):
                word = (data[i] << 8) + data[i + 1]
                total += word
                while total > 0xFFFF:
                    total = (total & 0xFFFF) + (total >> 16)
            
            if total == 0xFFFF:
                self.validated_count += 1
                payload = udp_segment[8:]
                return (True, payload, "ACCEPTED_VALID")
            else:
                self.failed_count += 1
                logger.error(
                    f"UDP checksum failed! "
                    f"Expected 0xFFFF, got 0x{total:04X}"
                )
                return (False, b'', "REJECTED_CHECKSUM_FAILED")
    
    def get_statistics(self) -> dict:
        """Return statistics about checksum processing."""
        total = (self.zero_checksum_count + 
                 self.validated_count + 
                 self.failed_count)
        return {
            "total_packets": total,
            "zero_checksum": self.zero_checksum_count,
            "validated": self.validated_count,
            "failed": self.failed_count,
            "zero_checksum_pct": (
                self.zero_checksum_count / total * 100 
                if total > 0 else 0
            )
        }

Monitoring Zero-Checksum Traffic

If you see a significant percentage of incoming UDP traffic with zero checksums, investigate. It might indicate: (1) legacy devices on your network, (2) misconfigured embedded systems, (3) certain tunneling protocols, or (4) unusual traffic that warrants inspection.

Summary: The Optional Checksum in Perspective

We've explored the optional nature of UDP checksums in IPv4—a fascinating case study in protocol design evolution and the legacy of historical engineering decisions. Let's consolidate the key insights:

Key Takeaways

•Checksum = 0x0000 means 'not computed' — This is how senders signal they skipped checksum calculation
•Checksum = 0xFFFF means 'checksum is zero' — The 0→0xFFFF conversion resolves ambiguity
•The option exists for historical reasons — 1980s CPU constraints justified the trade-off
•Modern guidance: always compute — Hardware offloading makes it free; the risks of skipping are real
•Receivers must accept zero-checksum packets — The spec requires it, but you can log and monitor
•Link-layer CRC is not sufficient — End-to-end integrity requires transport-layer verification
•Performance concerns are outdated — NIC offloading eliminates CPU overhead entirely
•IPv6 changes everything — Checksums are mandatory in IPv6 (next topic)

What's next:

While IPv4 made the checksum optional, IPv6 took the opposite approach: the UDP checksum is mandatory. The next page explores why this change was made, how it reflects evolved understanding of network reliability, and the implementation implications for dual-stack systems.

Page Complete

You now understand the historical context behind optional UDP checksums, the mechanism by which they're disabled, the risks involved, and the modern consensus that they should always be enabled. This context prepares you for understanding IPv6's mandatory checksum requirement.

3 / 5

Loading learning content...

Computer NetworksUDP Protocol

UDP Checksum

LevelIntermediate

Duration60 mins

TopicUDP Protocol

3 / 5

Optional in IPv4

The Optional Checksum: A Legacy of Trust

If you examine UDP's specification in RFC 768 (published in 1980), you'll find a surprising statement about the checksum field:

"Checksum is the 16-bit one's complement of the one's complement sum... If the computed checksum is zero, it is transmitted as all ones (the equivalent in one's complement arithmetic). An all zero transmitted checksum value means that the transmitter generated no checksum."

What You Will Learn

Historical Context: The Internet of 1980

To understand why the UDP checksum is optional, we must transport ourselves to 1980—when UDP was standardized. The Internet of that era was radically different from today's:

Computing landscape in 1980:

CPU cycles were precious — A typical minicomputer might have a 1 MHz processor. Calculating checksums for every packet consumed significant resources.
Memory was expensive — Systems might have 64KB of RAM. Every operation had to be lean.
Networks were small and trusted — The ARPANET connected a few dozen nodes, mostly at universities and research labs. All participants were known.
Link-layer integrity was assumed — Point-to-point links typically had their own error detection (like HDLC CRC).
Real-time applications existed — Voice and early video experiments valued timeliness over perfect accuracy.

The trust model:

The Internet: 1980 vs. Today
Aspect	1980	Today
Number of hosts	~200 nodes	30 billion devices
Typical CPU speed	1-10 MHz	3-5 GHz (1000x faster)
Network trust	All known, trusted parties	Anonymous, adversarial actors
Link technologies	Dedicated lines, mostly terrestrial	Wireless, satellite, shared media
Typical latency concern	Seconds acceptable	Milliseconds matter
Checksum cost (relative)	Significant CPU burden	Trivial, often hardware-accelerated
Threat model	Accidental errors only	Active attacks, widespread corruption

The Engineering Mindset of the Era

The rationale for optional checksums:

Performance on slow machines — Checksumming UDP headers and payloads on a 1 MHz processor could measurably slow throughput
Layered redundancy — If Ethernet already has a CRC, and the application verifies data, why checksum in the middle too?
Real-time tolerance — Voice traffic would rather drop a corrupted sample than delay playback to detect corruption
End-to-end philosophy — If the application needs integrity, it should verify; forcing UDP to do it wastes resources for apps that don't care
Trusted environments — On a local, trusted network with reliable links, corruption was rare

This reasoning made sense in 1980. Today, most of these conditions have reversed—yet the specification remains unchanged for backward compatibility.

How Optional Checksums Work

The mechanism for optional checksums is simple but requires precise understanding to implement correctly.

Sender behavior:

To compute checksum: Calculate as normal; if result is 0x0000, transmit 0xFFFF instead
To skip checksum: Set the checksum field to 0x0000 (all zeros)

Receiver behavior:

If checksum field is 0x0000: Sender skipped checksum; accept datagram without verification
If checksum field is non-zero: Verify checksum; drop if invalid

The 0x0000 vs 0xFFFF distinction:

Checksum field value: 0x0000 → "No checksum computed by sender"
Checksum field value: 0xFFFF → "Checksum was computed and happened to be zero"
                               (Remember: we convert 0x0000 → 0xFFFF before sending)
Checksum field value: other  → "Checksum was computed; verify at receiver"

This encoding allows us to distinguish between "checksum not computed" and "checksum equals zero" unambiguously.

optional_checksum_handling.py
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
import struct
 
class UDPChecksumMode:
    """Demonstrates UDP checksum optional handling for IPv4."""
    
    @staticmethod
    def create_udp_header(
        src_port: int,
        dst_port: int,
        payload_length: int,
        checksum: int = None  # None means compute, 0 means skip
    ) -> bytes:
        """
        Create UDP header with optional checksum.
        
        Args:
            src_port: Source port number
            dst_port: Destination port number
            payload_length: Length of UDP payload
            checksum: None to compute, 0 to skip, or specific value
        
        Returns:
            8-byte UDP header
        """
        udp_length = 8 + payload_length
        
        if checksum is None:
            # Checksum will be computed later
            # This is a placeholder
            checksum_value = 0x0000
        elif checksum == 0:
            # Explicitly skip checksum (IPv4 only!)
            checksum_value = 0x0000
        else:
            checksum_value = checksum
        
        return struct.pack(
            '!HHHH',
            src_port,
            dst_port,
            udp_length,
            checksum_value
        )
    
    @staticmethod
    def process_received_checksum(checksum_field: int, data: bytes) -> str:
        """
        Process received UDP checksum according to IPv4 rules.
        
        Args:
            checksum_field: Value from UDP header checksum field
            data: Complete data for verification (pseudo-hdr + segment)
        
        Returns:
            Status string describing outcome
        """
        if checksum_field == 0x0000:
            # Sender skipped checksum
            return "ACCEPTED_NO_CHECKSUM (sender opted out)"
        
        # Verify checksum
        # Calculate sum including the checksum field
        total = 0
        padded = data if len(data) % 2 == 0 else data + b'\x00'
        for i in range(0, len(padded), 2):
            word = (padded[i] << 8) + padded[i + 1]
            total += word
            while total > 0xFFFF:
                total = (total & 0xFFFF) + (total >> 16)
        
        if total == 0xFFFF:
            return "ACCEPTED_VALID_CHECKSUM"
        else:
            return f"REJECTED_INVALID_CHECKSUM (sum=0x{total:04X})"
 
# Demonstration
print("Creating UDP header with checksum skipped (IPv4 allowed):")
hdr = UDPChecksumMode.create_udp_header(12345, 53, 100, checksum=0)
print(f"  Header hex: {hdr.hex()}")
print(f"  Checksum bytes: {hdr[6:8].hex()} (0x0000 = skipped)")

Protocol Implementation Warning

When Skipping Might Make Sense (Historical & Edge Cases)

While modern guidance strongly recommends against disabling UDP checksums, there are historical and extremely niche scenarios where it was or could be considered:

Scenario 1: Embedded Systems with Severe Constraints (Historical)

Example: Early weather sensors, industrial controllers
  - 8 MHz 8-bit CPU
  - 4KB RAM total
  - Sending 100 readings/second
  - Checksum adds 5-10% CPU overhead
  - Trusted, local, wired network

Scenario 2: Tunneling Protocols with Inner Checksums

When UDP encapsulates another protocol that already has its own integrity check:

┌─────────────────────────────────────────────────┐
│ IP Header                                       │
├─────────────────────────────────────────────────┤
│ UDP Header (checksum could be skipped)          │
├─────────────────────────────────────────────────┤
│ ┌─────────────────────────────────────────────┐ │
│ │ Inner Protocol                              │ │
│ │ (with its own checksum/integrity check)     │ │
│ └─────────────────────────────────────────────┘ │
└─────────────────────────────────────────────────┘

If the inner protocol verifies integrity, the outer UDP checksum is redundant. However, this argument is weaker than it appears—we'll discuss why shortly.

Checksum Skipping Decision Matrix
Condition	Skip Checksum?	Rationale
Modern general-purpose system	NO	CPU overhead is trivial; integrity is critical
Untrusted network (Internet)	NEVER	Corruption and attacks are real threats
Trusted LAN with reliable hardware	Probably not	Hardware offload makes it free anyway
Real-time audio/video over local LAN	Maybe	Latency matters; app handles quality
Tunneled protocol with inner integrity	Consider	But header corruption still matters
IPv6	NOT ALLOWED	Specification mandates checksum
Any security-sensitive application	NEVER	Integrity is foundational to security

Modern Recommendation: Always Compute

Why the redundancy argument is flawed:

Even when the inner protocol has integrity checks, the UDP checksum covers information the inner protocol cannot verify:

Port numbers: Wrong ports could cause misrouting to wrong application
Length field: Corruption could cause buffer issues
IP addresses (via pseudo-header): Inner protocol doesn't know about these

Skipping the checksum saves almost nothing on modern systems while creating real risks. The few nanoseconds saved aren't worth the potential for silent data corruption.

The Risks of Skipping the Checksum

Let's examine concrete scenarios where skipping the UDP checksum causes real problems.

Risk 1: Misdelivery to Wrong Application

If the destination port is corrupted, the datagram goes to the wrong application:

Intended:   Port 53 (DNS server)    → DNS query processed correctly
Corrupted:  Port 5353 (mDNS)        → mDNS receives garbage, may crash
            Port 530 (RPC)          → RPC receives malformed request
            Port 5300 (some app)    → Unknown behavior

Without checksum verification, the receiving application has no warning that the data was meant for someone else.

Risk 2: Silent Data Corruption

Payload corruption passes through undetected:

Original payload:  "temperature=25.0°C"
Corrupted payload: "temperature=35.0°C"  (bit flip: 25→35)

Without checksum: Receiver logs incorrect temperature
With checksum: Packet dropped; sender retries or app handles missing data

Real-World Corruption Sources

•Memory errors in network equipment — Routers and switches have RAM; ECC isn't universal
•Cosmic rays — High-energy particles flip bits; one study estimated ~1 error/GB/month
•Faulty cables and connectors — Damaged wiring introduces noise
•Overheating hardware — Thermal issues cause bit errors
•Software bugs in routers — Firmware bugs can corrupt packets
•Power fluctuations — Unstable power affects signal integrity
•Wireless interference — Even with link-layer CRC, errors slip through

The 'Ethernet Has CRC' Fallacy

Risk 3: Security Implications

Without checksum validation, attackers have more room to craft malicious packets:

Easier packet injection: Attacker doesn't need to compute valid checksum
Bypass detection: IDS/IPS may not flag packets with no checksum to verify
Exploitation: Malformed data more likely to trigger parser bugs

Case study: The Stone et al. study (2000)

Risk 4: Loss of Cross-Layer Protection

The pseudo-header includes IP addresses. Without checksum verification:

Corrupted source IP: Replies go to wrong host
Corrupted destination IP already caused misdelivery
Protocol field corruption: Wrong transport handler

The checksum is the only mechanism catching these cross-layer inconsistencies.

How to Disable Checksums (And Why You Shouldn't)

For completeness and understanding—not as a recommendation—here's how UDP checksum generation can be disabled on various systems.

Linux:

Linux provides a socket option to disable UDP checksums:

int fd = socket(AF_INET, SOCK_DGRAM, 0);
int disable = 1;
setsockopt(fd, SOL_SOCKET, SO_NO_CHECK, &disable, sizeof(disable));

Alternatively, with raw sockets, you have complete control over the checksum field.

BSD/macOS:

Similar to Linux, but the option may be named differently or unsupported on some versions.

Windows:

Windows doesn't expose a simple option to disable UDP checksums. Raw sockets or NDIS drivers would be required.

Most applications:

Standard socket APIs (like Python's socket module) don't expose checksum control. The OS handles checksums automatically. You'd need low-level access to modify this behavior.

linux_no_check_example.c
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
/* 
 * Example: Disabling UDP checksum on Linux
 * WARNING: This is for educational purposes only!
 * DO NOT USE IN PRODUCTION
 */
 
#include <sys/socket.h>
#include <netinet/in.h>
#include <netinet/udp.h>
#include <stdio.h>
 
int create_udp_socket_no_checksum(void) {
    int fd = socket(AF_INET, SOCK_DGRAM, 0);
    if (fd < 0) {
        perror("socket");
        return -1;
    }
    
    /*
     * SO_NO_CHECK disables checksum generation on transmit.
     * Note: This is IPv4 only! IPv6 mandates checksums.
     * Note: Received packets with checksum=0 are always accepted.
     */
    int disable = 1;
    if (setsockopt(fd, SOL_SOCKET, SO_NO_CHECK, 
                   &disable, sizeof(disable)) < 0) {
        perror("setsockopt SO_NO_CHECK");
        /* Not all kernels support this; continue anyway */
    } else {
        printf("WARNING: UDP checksum disabled!\n");
        printf("This socket will send UDP with checksum=0\n");
    }
    
    return fd;
}
 
/*
 * Why you should NOT do this:
 * 1. Corruption in payload won't be detected
 * 2. Corruption in pseudo-header (IPs, ports) won't be detected
 * 3. Saves negligible CPU with modern hardware offloading
 * 4. Creates hard-to-diagnose data integrity bugs
 * 5. Violates modern best practices (RFC 1122)
 */

Seriously, Don't Do This

When the kernel computes checksums:

Even if you don't explicitly disable checksums, timing matters:

Without offloading: Kernel computes checksum in software during sendmsg()
With TX offloading: Kernel writes placeholder; NIC computes in hardware

With offloading enabled (the default on modern systems), the CPU never calculates the checksum anyway. Disabling it saves literally nothing.

Checking if offloading is active:

# Linux: Check UDP checksum offloading
ethtool -k eth0 | grep tx-checksum
# Output example:
# tx-checksum-ipv4: on
# tx-checksum-ipv6: on

If offloading is on (and it usually is), you're arguing about zero CPU cycles.

Modern Guidance and Best Practices

Contemporary network engineering guidance is clear: always compute UDP checksums over IPv4.

RFC Guidance:

RFC 1122 (Host Requirements, 1989):

"An application MAY optionally be able to control whether a UDP checksum will be generated, but it MUST default to checksumming on."

RFC 8085 (UDP Usage Guidelines, 2017):

"An application SHOULD enable UDP checksums." "Applications that disable UDP checksums need to understand that they will be unable to detect UDP datagram corruption."

Industry practice:

Major protocol implementations always enable checksums:

DNS servers compute checksums
DHCP servers compute checksums
Streaming protocols compute checksums
Gaming servers compute checksums
VoIP systems compute checksums

Even time-sensitive applications use checksums because hardware offloading makes them free.

Modern Best Practices Summary

•Always enable UDP checksums — There's no good reason not to on modern hardware
•Enable hardware offloading — Let the NIC compute checksums for zero CPU cost
•Verify your implementation — Test that checksums are actually being computed
•Don't assume link-layer suffices — End-to-end integrity requires transport-layer verification
•Add application-layer integrity — For critical data, layer additional checks (HMAC, signatures)
•Validate on receive — Don't accept zero-checksum packets from untrusted sources without consideration

Defense in Depth

What about performance-critical applications?

If you're building a high-frequency trading system, real-time game server, or video streaming platform where every microsecond matters:

Profile first — Is checksum actually your bottleneck? (It almost never is.)
Enable hardware offloading — CPU cost becomes zero
Use kernel bypass (DPDK, etc.) — If you're this performance-sensitive, you'll implement checksums in your low-latency stack anyway
Measure both ways — Compare throughput/latency with and without; the difference is typically unmeasurable

The bottom line:

Receiving Zero-Checksum Packets

As a receiver, you may encounter UDP packets with checksum = 0. How should you handle them?

Receiver obligations per specification:

The receiver MUST accept packets with zero checksum without verification. There's no option to reject them—if the checksum field is zero, the sender legitimately opted out.

Practical considerations:

You can't tell if data is corrupted — The payload might be garbage, and you won't know
Application must handle bad data — Robust parsing, input validation become critical
Logging is advisable — Consider logging or counting zero-checksum packets for diagnostics
Firewall filtering — In security-sensitive contexts, you might drop zero-checksum packets at the firewall (though this violates the spec)

handle_zero_checksum.py
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
import struct
import logging
 
logger = logging.getLogger(__name__)
 
class UDPReceiver:
    """Handles receiving UDP datagrams with zero-checksum awareness."""
    
    def __init__(self, strict_mode: bool = False):
        """
        Args:
            strict_mode: If True, log warnings for zero-checksum packets
        """
        self.strict_mode = strict_mode
        self.zero_checksum_count = 0
        self.validated_count = 0
        self.failed_count = 0
    
    def process_udp_segment(
        self,
        pseudo_header: bytes,
        udp_segment: bytes
    ) -> tuple[bool, bytes, str]:
        """
        Process a received UDP segment.
        
        Returns:
            (accepted, payload, status_message)
        """
        # Extract checksum from UDP header
        checksum = struct.unpack('!H', udp_segment[6:8])[0]
        
        if checksum == 0x0000:
            # Zero checksum: sender opted out (IPv4 only)
            self.zero_checksum_count += 1
            
            if self.strict_mode:
                logger.warning(
                    f"Received UDP packet with no checksum "
                    f"(count: {self.zero_checksum_count})"
                )
            
            # Per spec, we MUST accept without verification
            payload = udp_segment[8:]
            return (True, payload, "ACCEPTED_NO_CHECKSUM")
        
        else:
            # Non-zero checksum: verify
            data = pseudo_header + udp_segment
            if len(data) % 2 == 1:
                data += b'\x00'
            
            total = 0
            for i in range(0, len(data), 2):
                word = (data[i] << 8) + data[i + 1]
                total += word
                while total > 0xFFFF:
                    total = (total & 0xFFFF) + (total >> 16)
            
            if total == 0xFFFF:
                self.validated_count += 1
                payload = udp_segment[8:]
                return (True, payload, "ACCEPTED_VALID")
            else:
                self.failed_count += 1
                logger.error(
                    f"UDP checksum failed! "
                    f"Expected 0xFFFF, got 0x{total:04X}"
                )
                return (False, b'', "REJECTED_CHECKSUM_FAILED")
    
    def get_statistics(self) -> dict:
        """Return statistics about checksum processing."""
        total = (self.zero_checksum_count + 
                 self.validated_count + 
                 self.failed_count)
        return {
            "total_packets": total,
            "zero_checksum": self.zero_checksum_count,
            "validated": self.validated_count,
            "failed": self.failed_count,
            "zero_checksum_pct": (
                self.zero_checksum_count / total * 100 
                if total > 0 else 0
            )
        }

Monitoring Zero-Checksum Traffic

Summary: The Optional Checksum in Perspective

Key Takeaways

•Checksum = 0x0000 means 'not computed' — This is how senders signal they skipped checksum calculation
•Checksum = 0xFFFF means 'checksum is zero' — The 0→0xFFFF conversion resolves ambiguity
•The option exists for historical reasons — 1980s CPU constraints justified the trade-off
•Modern guidance: always compute — Hardware offloading makes it free; the risks of skipping are real
•Receivers must accept zero-checksum packets — The spec requires it, but you can log and monitor
•Link-layer CRC is not sufficient — End-to-end integrity requires transport-layer verification
•Performance concerns are outdated — NIC offloading eliminates CPU overhead entirely
•IPv6 changes everything — Checksums are mandatory in IPv6 (next topic)

What's next:

Page Complete

3 / 5