Computer NetworksError Detection & Correction

Checksum

LevelIntermediate

Duration75 mins

TopicError Detection & Correction

2 / 5

Internet Checksum

The Checksum That Powers the Internet

Every second, billions of IP packets traverse the global Internet. Each packet carries a header containing critical routing information—source address, destination address, protocol type, and more. If even a single bit in this header is corrupted, the packet might be delivered to the wrong destination, processed by the wrong protocol, or cause cascading failures in network equipment.

Protecting this header is a surprisingly simple algorithm: the Internet checksum. First specified in 1981 with IPv4 (RFC 791), refined in RFC 1071, and still in use today, this algorithm has verified more data than any other checksum in history.

What makes the Internet checksum remarkable is not its error detection power—CRC algorithms are stronger—but its exceptional combination of simplicity, speed, and portability. It was designed to run efficiently on the limited hardware of 1970s minicomputers, yet scales to modern multi-gigabit network interfaces. Understanding this algorithm reveals deep lessons about protocol design under constraints.

What You Will Learn

By the end of this page, you will understand the Internet checksum algorithm in complete detail: its specification, mathematical properties, why one's complement arithmetic was chosen, how it achieves byte-order independence, and its role across IP, TCP, UDP, and ICMP. You'll be able to implement it correctly and understand its strengths and limitations.

The RFC 1071 Specification

RFC 1071, titled "Computing the Internet Checksum," provides the authoritative specification and implementation guidance. Let's examine the algorithm as defined:

The Official Algorithm (paraphrased from RFC 1071):

Set the checksum field to zero
Divide the data into 16-bit words
Compute the sum of all 16-bit words using one's complement arithmetic
Take the one's complement of the resulting sum
This value is the checksum

Verification is equally straightforward:

Compute the one's complement sum of the data including the checksum field
If the result is all 1-bits (0xFFFF), the data is valid
Otherwise, an error has occurred

The elegance of verification is notable: rather than extracting the checksum, computing over the remaining data, and comparing, we simply include everything in the sum. If correct, the original checksum exactly complements the rest, producing zero (represented as all 1s in one's complement).

Internet Checksum Field Locations
Protocol	Header Position	Covers	RFC
IPv4	Bytes 10-11	IP header only	RFC 791
ICMP	Bytes 2-3	ICMP header + data	RFC 792
TCP	Bytes 16-17	Pseudo-header + TCP segment	RFC 793
UDP	Bytes 6-7	Pseudo-header + UDP datagram	RFC 768

IPv6 Difference

IPv6 (RFC 8200) removed the header checksum entirely! The rationale: the IPv6 header is simpler and checksum computation was consuming significant processing time at routers. Link-layer CRCs and transport-layer checksums provide sufficient protection. This decision reflects changing hardware capabilities and protocol design philosophy over 20 years.

Pseudo-Header Concept:

TCP and UDP checksums cover more than just the transport header and payload. They also include a "pseudo-header" containing IP-layer information: source address, destination address, protocol number, and segment length.

Why? This creates a connection between layers that isn't strictly necessary for layer independence but provides valuable protection. If a packet is delivered to the wrong IP address (perhaps due to corruption in the IP header), the TCP/UDP checksum will likely fail because the destination address in the transport calculation won't match the corrupted IP header.

The pseudo-header is never transmitted; it's constructed at both sender and receiver from the IP header and used only for checksum computation.

pseudo_header.py
Python
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
"""
TCP/UDP Pseudo-Header Structure for IPv4
 
The pseudo-header is prepended to TCP/UDP data for checksum calculation only.
It is never transmitted on the wire.
 
+--------+--------+--------+--------+
|          Source Address          |
+--------+--------+--------+--------+
|       Destination Address        |
+--------+--------+--------+--------+
|  Zero  |Protocol|   TCP Length   |
+--------+--------+--------+--------+
 
For IPv6, the pseudo-header is similar but with 128-bit addresses
and a 32-bit length field.
"""
 
import struct
 
def build_tcp_pseudoheader(
    src_ip: str,
    dst_ip: str,
    tcp_length: int
) -> bytes:
    """
    Construct the IPv4 TCP pseudo-header for checksum calculation.
    
    Args:
        src_ip: Source IP address as dotted-decimal string
        dst_ip: Destination IP address as dotted-decimal string
        tcp_length: Length of TCP header + data in bytes
    
    Returns:
        12-byte pseudo-header
    """
    import socket
    
    src_addr = socket.inet_aton(src_ip)  # 4 bytes
    dst_addr = socket.inet_aton(dst_ip)  # 4 bytes
    reserved = 0                          # 1 byte
    protocol = 6                          # TCP protocol number
    length = tcp_length                   # 2 bytes
    
    # Pack in network byte order (big-endian)
    pseudoheader = struct.pack(
        '!4s4sBBH',
        src_addr,
        dst_addr,
        reserved,
        protocol,
        length
    )
    
    return pseudoheader
 
 
# Example: Build pseudo-header for a TCP segment
pseudo = build_tcp_pseudoheader('192.168.1.100', '10.0.0.1', 32)
print(f"Pseudo-header ({len(pseudo)} bytes): {pseudo.hex()}")

One's Complement Arithmetic Deep Dive

The defining characteristic of the Internet checksum is its use of one's complement arithmetic. This choice, which may seem arbitrary today, was deliberate and provides important benefits. To understand the algorithm, we must first understand one's complement representation.

One's Complement vs Two's Complement:

Modern computers universally use two's complement for signed integers. But early computers (including the PDP-10, UNIVAC, and CDC 6600) used one's complement. The Internet checksum was designed when one's complement machines were still common.

Key Difference: Negative Zero

In two's complement, there's exactly one representation of zero: all bits set to 0. But in one's complement, there are two representations:

Positive zero: 0000000000000000 (all zeros)
Negative zero: 1111111111111111 (all ones)

Mathematically, both represent the same value, but this quirk has important implications for the checksum algorithm.

Comparison: Two's Complement vs One's Complement
Property	Two's Complement	One's Complement
Zero representations	One (0x0000)	Two (0x0000 and 0xFFFF)
Negation	Invert bits, add 1	Invert bits only
Range (16-bit)	-32,768 to +32,767	-32,767 to +32,767
Overflow handling	Wraps around	End-around carry required
Hardware support	Universal today	Rare (legacy systems)

End-Around Carry (EAC):

The critical operation in one's complement arithmetic is the end-around carry. When adding two 16-bit numbers produces a 17-bit result (carry out), that carry bit is added back to the least significant bit of the result.

Example:

  0xFFFF  (65535, or -0 in one's complement)
+ 0x0003  (3)
--------
 0x10002  (overflow! 17 bits)

End-around carry: (0x10002 & 0xFFFF) + (0x10002 >> 16)
                = 0x0002 + 0x0001
                = 0x0003

This is equivalent to computing modulo (2^16 - 1) rather than modulo 2^16. The mathematical properties of this operation enable several important optimizations.

ones_complement_add.py
Python
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
def ones_complement_add(a: int, b: int, bits: int = 16) -> int:
    """
    Add two numbers using one's complement arithmetic.
    
    In one's complement:
    - Addition may produce a carry-out bit
    - This carry is added back to the result (end-around carry)
    - Mathematically equivalent to addition modulo (2^bits - 1)
    
    Args:
        a, b: 16-bit unsigned integers
        bits: Number of bits (default 16)
    
    Returns:
        One's complement sum as unsigned integer
    """
    mask = (1 << bits) - 1  # 0xFFFF for 16 bits
    
    # Standard addition
    result = a + b
    
    # Extract carry bits (everything above 'bits' position)
    carry = result >> bits
    
    # Fold carry back into result (end-around carry)
    result = (result & mask) + carry
    
    # May need another fold if the above addition also caused carry
    if result > mask:
        result = (result & mask) + (result >> bits)
    
    return result
 
 
def ones_complement(value: int, bits: int = 16) -> int:
    """
    Compute the one's complement (bitwise NOT within bit width).
    
    Args:
        value: Integer to complement
        bits: Number of bits
    
    Returns:
        One's complement of value
    """
    mask = (1 << bits) - 1
    return (~value) & mask
 
 
# Demonstration
print("One's Complement Addition Examples:")
print(f"0x8001 + 0x8001 = 0x{ones_complement_add(0x8001, 0x8001):04X}")
print(f"0xFFFF + 0x0001 = 0x{ones_complement_add(0xFFFF, 0x0001):04X}")
print(f"0xFFFF + 0xFFFF = 0x{ones_complement_add(0xFFFF, 0xFFFF):04X}")
 
print("\nOne's Complement (negation):")
print(f"~0x0001 = 0x{ones_complement(0x0001):04X}")
print(f"~0xFFFF = 0x{ones_complement(0xFFFF):04X}")  # Note: ~(-0) = +0

Why Not Two's Complement?

One's complement arithmetic has a crucial property: the checksum is byte-order independent. Whether you process words as big-endian or little-endian, you get the same final checksum value (in the appropriate byte order). Two's complement addition lacks this property. This made the algorithm portable across machines with different architectures—critical for Internet interoperability.

Byte-Order Independence: A Deep Analysis

One of the Internet checksum's most elegant properties is byte-order independence. This means that the checksum computed on a big-endian machine matches the checksum computed on a little-endian machine, despite processing bytes in different order within each 16-bit word.

Why This Matters:

Network protocols specify that multi-byte fields use "network byte order" (big-endian). But if every arithmetic operation required byte-swapping on little-endian machines (like x86), checksum computation would be significantly slower.

The Internet checksum allows implementations to use native byte order throughout, producing the correct result without explicit swaps.

Mathematical Proof (Sketch):

The key insight is that one's complement addition treats each byte position independently across the sum, then combines results. Let's denote:

Original sum computed in big-endian: SUM_BE
Original sum computed in little-endian: SUM_LE

For any 16-bit word W = H:L (high byte:low byte):

Big-endian sees: (H << 8) | L
Little-endian sees: H | (L << 8)

When we sum many such words, the total contribution from high bytes and low bytes accumulates separately. With end-around carry, these contributions interact only through the carry path, and that interaction is symmetric.

The final checksums SUM_BE and SUM_LE are byte-swapped versions of each other. If we complement each, they remain byte-swapped. When the receiver computes using its native order and complements, the verification still produces all-ones (or all-zeros) correctly.

byte_order_proof.py
Python
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
"""
Demonstration that Internet checksum is byte-order independent.
 
We compute the checksum two ways:
1. Treating first byte of each pair as MSB (big-endian / network order)
2. Treating first byte of each pair as LSB (little-endian / host order on x86)
 
Both produce the same checksum value!
"""
 
def internet_checksum(data: bytes, native_order: str = 'big') -> int:
    """
    Compute Internet checksum with specified byte interpretation.
    
    Args:
        data: Bytes to checksum
        native_order: 'big' for big-endian, 'little' for little-endian
    
    Returns:
        16-bit checksum value
    """
    if len(data) % 2 == 1:
        data = data + b'\x00'
    
    total = 0
    
    for i in range(0, len(data), 2):
        if native_order == 'big':
            word = (data[i] << 8) | data[i + 1]
        else:  # little
            word = data[i] | (data[i + 1] << 8)
        total += word
    
    # Fold to 16 bits with end-around carry
    while total > 0xFFFF:
        total = (total & 0xFFFF) + (total >> 16)
    
    # One's complement
    return (~total) & 0xFFFF
 
 
# Test with sample data
test_data = b'\x45\x00\x00\x73\x00\x00\x40\x00\x40\x11\x00\x00\xc0\xa8\x00\x01\xc0\xa8\x00\xc7'
 
checksum_be = internet_checksum(test_data, 'big')
checksum_le = internet_checksum(test_data, 'little')
 
print(f"Test data: {test_data.hex()}")
print(f"Big-endian computation:    0x{checksum_be:04X}")
print(f"Little-endian computation: 0x{checksum_le:04X}")
 
# The checksums are byte-swapped versions of each other
checksum_le_swapped = ((checksum_le & 0xFF) << 8) | (checksum_le >> 8)
print(f"Little-endian (swapped):   0x{checksum_le_swapped:04X}")
print(f"Match after swap: {checksum_be == checksum_le_swapped}")
 
# Key insight: When placed in the header (in network byte order),
# verification works regardless of host byte order!

Practical Implication

This property means network stacks don't need conditional code for checksumming based on machine architecture. The same code runs on x86 (little-endian), SPARC (big-endian), ARM (configurable), and any other architecture, producing interoperable results.

Complete Implementation with Optimizations

A production-quality Internet checksum implementation requires attention to correctness, edge cases, and performance. Let's build one step by step, then explore common optimizations.

Reference Implementation:

internet_checksum_complete.py
Python
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
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
"""
Complete Internet Checksum Implementation (RFC 1071)
 
This implementation prioritizes clarity and correctness.
For production use, consider assembly-level or hardware-offloaded versions.
"""
 
from typing import Union
 
 
def compute_internet_checksum(
    data: Union[bytes, bytearray],
    initial: int = 0
) -> int:
    """
    Compute the Internet checksum per RFC 1071.
    
    Args:
        data: Binary data to checksum
        initial: Initial sum value (for incremental checksums)
    
    Returns:
        16-bit checksum value in network byte order
    """
    # Start with initial value (for combining with pseudo-header)
    total = initial
    
    # Process complete 16-bit words
    length = len(data)
    i = 0
    
    while i < length - 1:
        # Combine two bytes into 16-bit word (network byte order)
        word = (data[i] << 8) | data[i + 1]
        total += word
        i += 2
    
    # Handle trailing odd byte by zero-padding
    if length % 2 == 1:
        total += data[-1] << 8
    
    # Fold 32-bit sum to 16 bits using end-around carry
    # Keep folding until all overflow bits are absorbed
    while total > 0xFFFF:
        total = (total & 0xFFFF) + (total >> 16)
    
    # Return one's complement of the sum
    return (~total) & 0xFFFF
 
 
def verify_internet_checksum(data: bytes) -> bool:
    """
    Verify data with embedded checksum.
    
    For correct data, summing all words (including checksum)
    and complementing should yield zero (or 0xFFFF in one's complement).
    
    Args:
        data: Data with checksum already embedded
    
    Returns:
        True if checksum is valid
    """
    total = 0
    length = len(data)
    i = 0
    
    while i < length - 1:
        word = (data[i] << 8) | data[i + 1]
        total += word
        i += 2
    
    if length % 2 == 1:
        total += data[-1] << 8
    
    while total > 0xFFFF:
        total = (total & 0xFFFF) + (total >> 16)
    
    # If all is correct, total should be 0xFFFF (all ones)
    # The complement of 0xFFFF is 0x0000
    return total == 0xFFFF or total == 0x0000
 
 
# === Demonstration ===
 
# Create a sample IP header (with checksum field set to zero)
ip_header = bytearray([
    0x45, 0x00,  # Version, IHL, DSCP, ECN
    0x00, 0x73,  # Total length: 115 bytes
    0x00, 0x00,  # Identification
    0x40, 0x00,  # Flags, Fragment offset
    0x40, 0x11,  # TTL: 64, Protocol: UDP (17)
    0x00, 0x00,  # Checksum (initially zero)
    0xc0, 0xa8, 0x00, 0x01,  # Source: 192.168.0.1
    0xc0, 0xa8, 0x00, 0xc7   # Dest: 192.168.0.199
])
 
# Compute checksum
checksum = compute_internet_checksum(ip_header)
print(f"Computed checksum: 0x{checksum:04X}")
 
# Insert checksum into header (bytes 10-11, big-endian)
ip_header[10] = (checksum >> 8) & 0xFF
ip_header[11] = checksum & 0xFF
print(f"IP header with checksum: {ip_header.hex()}")
 
# Verify
is_valid = verify_internet_checksum(bytes(ip_header))
print(f"Verification result: {is_valid}")
 
# Test error detection
corrupted = bytearray(ip_header)
corrupted[15] ^= 0x01  # Flip one bit in destination IP
is_valid_corrupted = verify_internet_checksum(bytes(corrupted))
print(f"Corrupted data verification: {is_valid_corrupted}")

Common Optimizations:

32-bit or 64-bit Accumulator: Process multiple words at once using a wider accumulator, then fold at the end. This reduces loop iterations.
Loop Unrolling: Process 4 or 8 words per iteration to reduce loop overhead.
Deferred Folding: Accumulate into a 32-bit (or 64-bit) variable without folding after each addition. Only fold once at the end. This works because overflows don't affect the final result if folded correctly.
SIMD Instructions: Use vector operations (SSE/AVX on x86, NEON on ARM) to process multiple words in parallel.
Hardware Offload: Modern NICs compute checksums in hardware, eliminating software overhead entirely.

optimized_checksum.c
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
45
46
47
48
49
50
51
52
53
54
/*
 * Optimized Internet Checksum (C/Assembly hybrid)
 * 
 * This version uses a 64-bit accumulator and processes
 * 8 bytes at a time for better performance.
 */
 
#include <stdint.h>
#include <stddef.h>
 
uint16_t fast_internet_checksum(const void* data, size_t len) {
    const uint16_t* ptr = (const uint16_t*) data;
    uint64_t sum = 0;  // Wide accumulator for deferred folding
    
    // Process 8 bytes (4 words) at a time
    while (len >= 8) {
        sum += ptr[0];
        sum += ptr[1];
        sum += ptr[2];
        sum += ptr[3];
        ptr += 4;
        len -= 8;
    }
    
    // Process remaining complete words
    while (len >= 2) {
        sum += *ptr++;
        len -= 2;
    }
    
    // Handle trailing byte
    if (len > 0) {
        sum += *(const uint8_t*)ptr << 8;  // Network byte order
    }
    
    // Fold 64-bit sum to 16 bits
    // First fold 64 -> 32
    sum = (sum >> 32) + (sum & 0xFFFFFFFF);
    sum = (sum >> 32) + (sum & 0xFFFFFFFF);
    
    // Then fold 32 -> 16
    sum = (sum >> 16) + (sum & 0xFFFF);
    sum = (sum >> 16) + (sum & 0xFFFF);
    
    return (uint16_t)(~sum);
}
 
/*
 * For maximum performance on x86-64, assembly can use:
 * - ADC (Add with Carry) instruction for end-around carry
 * - SIMD for parallel processing
 * 
 * Linux kernel uses assembly versions optimized per architecture.
 */

Real-World Performance

A naive Python implementation might achieve 100 MB/s. An optimized C implementation can exceed 10 GB/s. Hardware offload in a modern NIC can handle 100+ Gbps wire speed. Always use hardware offload when available; it's faster and frees CPU for other work.

Incremental Checksum Update

One of the most valuable properties of the Internet checksum is that it can be updated incrementally when small changes are made to the data. This is critical for routers and NAT devices that modify packet headers millions of times per second.

The Problem:

When a router forwards an IPv4 packet, it decrements the TTL (Time To Live) field. If we had to recompute the entire header checksum for every packet, routers would waste enormous CPU cycles.

The Solution: Incremental Update

RFC 1624 describes how to update the checksum when specific fields change:

new_checksum = ~(~old_checksum + ~old_value + new_value)

In one's complement:

Subtract the old word contribution: add its complement
Add the new word contribution
Complement the result

This is O(1) regardless of packet size!

incremental_checksum.py
Python
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
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
"""
Incremental Checksum Update (RFC 1624)
 
When modifying a small part of checksummed data,
we can update the checksum without reprocessing all data.
"""
 
def incremental_checksum_update(
    old_checksum: int,
    old_value: int,
    new_value: int
) -> int:
    """
    Update checksum when a single 16-bit word changes.
    
    Based on RFC 1624:
    new_checksum = ~(~old_checksum + ~old_value + new_value)
    
    In one's complement arithmetic with end-around carry.
    
    Args:
        old_checksum: The current checksum value
        old_value: The 16-bit word being replaced
        new_value: The new 16-bit word value
    
    Returns:
        Updated checksum
    """
    # Convert to "sum form" by complementing the checksum
    # (checksum = ~sum, so ~checksum = sum)
    sum_val = (~old_checksum) & 0xFFFF
    
    # Subtract old value (add its complement in one's complement)
    sum_val += (~old_value) & 0xFFFF
    
    # Add new value
    sum_val += new_value
    
    # Fold overflows
    while sum_val > 0xFFFF:
        sum_val = (sum_val & 0xFFFF) + (sum_val >> 16)
    
    # Complement back to checksum form
    return (~sum_val) & 0xFFFF
 
 
def decrement_ttl_update_checksum(
    ip_header: bytearray
) -> None:
    """
    Decrement IP header TTL and update checksum in-place.
    
    This is what routers do for every forwarded packet.
    """
    # TTL is at byte 8, checksum at bytes 10-11
    old_ttl_word = (ip_header[8] << 8) | ip_header[9]  # TTL + Protocol
    old_checksum = (ip_header[10] << 8) | ip_header[11]
    
    # Decrement TTL (upper byte of the word)
    new_ttl = ip_header[8] - 1
    if new_ttl < 0:
        raise ValueError("TTL expired!")
    
    ip_header[8] = new_ttl
    new_ttl_word = (ip_header[8] << 8) | ip_header[9]
    
    # Update checksum incrementally
    new_checksum = incremental_checksum_update(
        old_checksum, old_ttl_word, new_ttl_word
    )
    
    # Write back updated checksum
    ip_header[10] = (new_checksum >> 8) & 0xFF
    ip_header[11] = new_checksum & 0xFF
 
 
# === Demonstration ===
 
# Sample IP header with valid checksum
ip_header = bytearray([
    0x45, 0x00, 0x00, 0x73,  # Version, IHL, DSCP, Total length
    0x00, 0x00, 0x40, 0x00,  # ID, Flags, Fragment
    0x40, 0x11,              # TTL=64, Protocol=UDP
    0xB8, 0x61,              # Checksum (pre-computed)
    0xC0, 0xA8, 0x00, 0x01,  # Source: 192.168.0.1
    0xC0, 0xA8, 0x00, 0xC7   # Dest: 192.168.0.199
])
 
print(f"Before:  TTL={ip_header[8]}, Checksum=0x{ip_header[10]:02X}{ip_header[11]:02X}")
 
# Decrement TTL and update checksum
decrement_ttl_update_checksum(ip_header)
 
print(f"After:   TTL={ip_header[8]}, Checksum=0x{ip_header[10]:02X}{ip_header[11]:02X}")
 
# Verify the updated checksum is correct
from typing import Union
def verify(data: bytes) -> bool:
    total = 0
    for i in range(0, len(data), 2):
        total += (data[i] << 8) | data[i + 1]
    while total > 0xFFFF:
        total = (total & 0xFFFF) + (total >> 16)
    return total == 0xFFFF
 
print(f"Checksum valid: {verify(bytes(ip_header))}")

NAT Implications

Network Address Translation (NAT) modifies both IP addresses (changing IP checksum) and port numbers (changing TCP/UDP checksum). Incremental update makes this feasible at high packet rates. Without it, NAT would be a significant bottleneck.

Protocol-Specific Usage

The Internet checksum is used differently in each protocol layer. Understanding these differences is essential for network programming and protocol analysis.

IPv4 Header Checksum

•Covers only the IP header (minimum 20 bytes, up to 60 with options)
•Recalculated at each hop because TTL changes
•Field position: Bytes 10-11 of IP header
•Zero if offloaded: Hardware may set to 0x0000 if checksum is computed by NIC
•Not in IPv6: Removed to speed up routing; link-layer CRC is trusted

TCP Checksum

•Mandatory — Must always be computed and verified
•Covers: Pseudo-header + TCP header + TCP payload
•Pseudo-header includes: Source IP, Dest IP, Protocol (6), TCP Length
•End-to-end: Computed by sender, verified by receiver; intermediate nodes don't modify
•Payload included: Catches corruption in application data, not just headers

UDP Checksum

•Optional in IPv4 — Can be set to 0x0000 to skip (though RFC recommends computing)
•Mandatory in IPv6 — IPv6 has no header checksum, so UDP must verify
•Covers: Pseudo-header + UDP header + UDP payload
•Zero means unused: If computed checksum is 0, transmit 0xFFFF instead (ambiguity avoidance)
•Often offloaded: NICs compute UDP checksum in hardware

Checksum Scope Comparison
Protocol	Header Protected	Payload Protected	Pseudo-Header	Recalculated Per Hop
IPv4	Yes (20-60 bytes)	No	No	Yes (TTL changes)
ICMP	Yes	Yes (data portion)	No	No
TCP	Yes	Yes	Yes	No
UDP	Yes	Yes	Yes	No

Checksum Offload Pitfalls

When capturing packets with tools like Wireshark on the sending machine, you may see incorrect checksums. This is because the capture happens before the NIC computes the checksum (checksum offload). The packets on the wire have correct checksums. This is a common source of confusion when debugging network issues.

Error Detection Limitations

While the Internet checksum has served admirably for decades, honest engineering requires acknowledging its limitations. These aren't failures of implementation but inherent to the algorithm's design.

Known Weaknesses:

Undetectable Error Patterns

•Word transposition — Swapping any two 16-bit words leaves the checksum unchanged
•Byte transposition within words — Swapping bytes 2i and 2i+1 with bytes 2j and 2j+1 (for some i,j)
•Compensating single-bit errors — +1 in one position canceled by -1 in corresponding position of another word
•Zero-sum insertions — Adding 0x0000 words doesn't change the sum
•Certain burst patterns — Long bursts that happen to sum to zero

Research on Detection Rates:

Studies have measured the Internet checksum's effectiveness against real-world errors:

Stone & Partridge (2000): Analyzed TCP/IP traffic and found that 1 in 16 million to 1 in 10 billion TCP segments arrive with undetected errors (depending on the network). The checksum catches most errors, but not all.
Random bit errors: For uniformly random errors, approximately 1 in 65,536 pass undetected (as expected from a 16-bit checksum).
Burst errors: Detection depends on burst alignment and length. Short bursts (< 16 bits) are usually detected; longer bursts may escape.

Why This Is Acceptable:

Layered defense: Link-layer CRCs catch most errors before they reach IP/TCP.
Application-layer checks: Critical applications add their own integrity verification.
Error rarity: Modern fiber and Ethernet have very low bit error rates.
Cost-benefit: Stronger checksums would slow every packet on the Internet.

Defense in Depth

The Internet checksum is not meant to be the only protection. Ethernet CRC-32, application-layer TLS, and end-user verification (visual confirmation, file hashes) all contribute. No single mechanism needs to be perfect when multiple independent checks are in place.

Summary: The Internet Checksum

The Internet checksum exemplifies elegant engineering under constraints. Let's consolidate the essential knowledge:

Key Takeaways

•One's complement arithmetic is the key — The use of end-around carry enables byte-order independence and efficient incremental updates.
•Verification is elegant — Sum everything including the checksum; if the result is all-ones, the data is valid.
•Incremental update enables routing — Routers can modify headers and update checksums in O(1) time, essential for high-speed forwarding.
•Pseudo-headers provide cross-layer protection — TCP/UDP checksums catch IP-layer corruption that might misdirect packets.
•Hardware offload is standard — Modern NICs compute and verify checksums without CPU involvement.
•Known weaknesses exist — Word transposition and certain burst patterns escape detection, but layered defenses compensate.

Looking Ahead:

With the Internet checksum's design and properties understood, we can dive deeper into the one's complement arithmetic that makes it work. The next page explores one's complement representation in full mathematical detail, showing exactly how end-around carry achieves its remarkable properties.

Page Complete

You now understand the Internet checksum algorithm: its specification, mathematical foundations, byte-order independence, incremental update capability, and protocol-specific usage. This knowledge is essential for network programming, protocol debugging, and understanding why the Internet works reliably.

2 / 5

Loading learning content...

Computer NetworksError Detection & Correction

Checksum

LevelIntermediate

Duration75 mins

TopicError Detection & Correction

2 / 5

Internet Checksum

The Checksum That Powers the Internet

What You Will Learn

The RFC 1071 Specification

RFC 1071, titled "Computing the Internet Checksum," provides the authoritative specification and implementation guidance. Let's examine the algorithm as defined:

The Official Algorithm (paraphrased from RFC 1071):

Set the checksum field to zero
Divide the data into 16-bit words
Compute the sum of all 16-bit words using one's complement arithmetic
Take the one's complement of the resulting sum
This value is the checksum

Verification is equally straightforward:

Compute the one's complement sum of the data including the checksum field
If the result is all 1-bits (0xFFFF), the data is valid
Otherwise, an error has occurred

Internet Checksum Field Locations
Protocol	Header Position	Covers	RFC
IPv4	Bytes 10-11	IP header only	RFC 791
ICMP	Bytes 2-3	ICMP header + data	RFC 792
TCP	Bytes 16-17	Pseudo-header + TCP segment	RFC 793
UDP	Bytes 6-7	Pseudo-header + UDP datagram	RFC 768

IPv6 Difference

Pseudo-Header Concept:

The pseudo-header is never transmitted; it's constructed at both sender and receiver from the IP header and used only for checksum computation.

pseudo_header.py
Python
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
"""
TCP/UDP Pseudo-Header Structure for IPv4
 
The pseudo-header is prepended to TCP/UDP data for checksum calculation only.
It is never transmitted on the wire.
 
+--------+--------+--------+--------+
|          Source Address          |
+--------+--------+--------+--------+
|       Destination Address        |
+--------+--------+--------+--------+
|  Zero  |Protocol|   TCP Length   |
+--------+--------+--------+--------+
 
For IPv6, the pseudo-header is similar but with 128-bit addresses
and a 32-bit length field.
"""
 
import struct
 
def build_tcp_pseudoheader(
    src_ip: str,
    dst_ip: str,
    tcp_length: int
) -> bytes:
    """
    Construct the IPv4 TCP pseudo-header for checksum calculation.
    
    Args:
        src_ip: Source IP address as dotted-decimal string
        dst_ip: Destination IP address as dotted-decimal string
        tcp_length: Length of TCP header + data in bytes
    
    Returns:
        12-byte pseudo-header
    """
    import socket
    
    src_addr = socket.inet_aton(src_ip)  # 4 bytes
    dst_addr = socket.inet_aton(dst_ip)  # 4 bytes
    reserved = 0                          # 1 byte
    protocol = 6                          # TCP protocol number
    length = tcp_length                   # 2 bytes
    
    # Pack in network byte order (big-endian)
    pseudoheader = struct.pack(
        '!4s4sBBH',
        src_addr,
        dst_addr,
        reserved,
        protocol,
        length
    )
    
    return pseudoheader
 
 
# Example: Build pseudo-header for a TCP segment
pseudo = build_tcp_pseudoheader('192.168.1.100', '10.0.0.1', 32)
print(f"Pseudo-header ({len(pseudo)} bytes): {pseudo.hex()}")

One's Complement Arithmetic Deep Dive

One's Complement vs Two's Complement:

Key Difference: Negative Zero

In two's complement, there's exactly one representation of zero: all bits set to 0. But in one's complement, there are two representations:

Positive zero: 0000000000000000 (all zeros)
Negative zero: 1111111111111111 (all ones)

Mathematically, both represent the same value, but this quirk has important implications for the checksum algorithm.

Comparison: Two's Complement vs One's Complement
Property	Two's Complement	One's Complement
Zero representations	One (0x0000)	Two (0x0000 and 0xFFFF)
Negation	Invert bits, add 1	Invert bits only
Range (16-bit)	-32,768 to +32,767	-32,767 to +32,767
Overflow handling	Wraps around	End-around carry required
Hardware support	Universal today	Rare (legacy systems)

End-Around Carry (EAC):

Example:

  0xFFFF  (65535, or -0 in one's complement)
+ 0x0003  (3)
--------
 0x10002  (overflow! 17 bits)

End-around carry: (0x10002 & 0xFFFF) + (0x10002 >> 16)
                = 0x0002 + 0x0001
                = 0x0003

This is equivalent to computing modulo (2^16 - 1) rather than modulo 2^16. The mathematical properties of this operation enable several important optimizations.

ones_complement_add.py
Python
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
def ones_complement_add(a: int, b: int, bits: int = 16) -> int:
    """
    Add two numbers using one's complement arithmetic.
    
    In one's complement:
    - Addition may produce a carry-out bit
    - This carry is added back to the result (end-around carry)
    - Mathematically equivalent to addition modulo (2^bits - 1)
    
    Args:
        a, b: 16-bit unsigned integers
        bits: Number of bits (default 16)
    
    Returns:
        One's complement sum as unsigned integer
    """
    mask = (1 << bits) - 1  # 0xFFFF for 16 bits
    
    # Standard addition
    result = a + b
    
    # Extract carry bits (everything above 'bits' position)
    carry = result >> bits
    
    # Fold carry back into result (end-around carry)
    result = (result & mask) + carry
    
    # May need another fold if the above addition also caused carry
    if result > mask:
        result = (result & mask) + (result >> bits)
    
    return result
 
 
def ones_complement(value: int, bits: int = 16) -> int:
    """
    Compute the one's complement (bitwise NOT within bit width).
    
    Args:
        value: Integer to complement
        bits: Number of bits
    
    Returns:
        One's complement of value
    """
    mask = (1 << bits) - 1
    return (~value) & mask
 
 
# Demonstration
print("One's Complement Addition Examples:")
print(f"0x8001 + 0x8001 = 0x{ones_complement_add(0x8001, 0x8001):04X}")
print(f"0xFFFF + 0x0001 = 0x{ones_complement_add(0xFFFF, 0x0001):04X}")
print(f"0xFFFF + 0xFFFF = 0x{ones_complement_add(0xFFFF, 0xFFFF):04X}")
 
print("\nOne's Complement (negation):")
print(f"~0x0001 = 0x{ones_complement(0x0001):04X}")
print(f"~0xFFFF = 0x{ones_complement(0xFFFF):04X}")  # Note: ~(-0) = +0

Why Not Two's Complement?

Byte-Order Independence: A Deep Analysis

Why This Matters:

The Internet checksum allows implementations to use native byte order throughout, producing the correct result without explicit swaps.

Mathematical Proof (Sketch):

The key insight is that one's complement addition treats each byte position independently across the sum, then combines results. Let's denote:

Original sum computed in big-endian: SUM_BE
Original sum computed in little-endian: SUM_LE

For any 16-bit word W = H:L (high byte:low byte):

Big-endian sees: (H << 8) | L
Little-endian sees: H | (L << 8)

byte_order_proof.py
Python
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
"""
Demonstration that Internet checksum is byte-order independent.
 
We compute the checksum two ways:
1. Treating first byte of each pair as MSB (big-endian / network order)
2. Treating first byte of each pair as LSB (little-endian / host order on x86)
 
Both produce the same checksum value!
"""
 
def internet_checksum(data: bytes, native_order: str = 'big') -> int:
    """
    Compute Internet checksum with specified byte interpretation.
    
    Args:
        data: Bytes to checksum
        native_order: 'big' for big-endian, 'little' for little-endian
    
    Returns:
        16-bit checksum value
    """
    if len(data) % 2 == 1:
        data = data + b'\x00'
    
    total = 0
    
    for i in range(0, len(data), 2):
        if native_order == 'big':
            word = (data[i] << 8) | data[i + 1]
        else:  # little
            word = data[i] | (data[i + 1] << 8)
        total += word
    
    # Fold to 16 bits with end-around carry
    while total > 0xFFFF:
        total = (total & 0xFFFF) + (total >> 16)
    
    # One's complement
    return (~total) & 0xFFFF
 
 
# Test with sample data
test_data = b'\x45\x00\x00\x73\x00\x00\x40\x00\x40\x11\x00\x00\xc0\xa8\x00\x01\xc0\xa8\x00\xc7'
 
checksum_be = internet_checksum(test_data, 'big')
checksum_le = internet_checksum(test_data, 'little')
 
print(f"Test data: {test_data.hex()}")
print(f"Big-endian computation:    0x{checksum_be:04X}")
print(f"Little-endian computation: 0x{checksum_le:04X}")
 
# The checksums are byte-swapped versions of each other
checksum_le_swapped = ((checksum_le & 0xFF) << 8) | (checksum_le >> 8)
print(f"Little-endian (swapped):   0x{checksum_le_swapped:04X}")
print(f"Match after swap: {checksum_be == checksum_le_swapped}")
 
# Key insight: When placed in the header (in network byte order),
# verification works regardless of host byte order!

Practical Implication

Complete Implementation with Optimizations

A production-quality Internet checksum implementation requires attention to correctness, edge cases, and performance. Let's build one step by step, then explore common optimizations.

Reference Implementation:

internet_checksum_complete.py
Python
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
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
"""
Complete Internet Checksum Implementation (RFC 1071)
 
This implementation prioritizes clarity and correctness.
For production use, consider assembly-level or hardware-offloaded versions.
"""
 
from typing import Union
 
 
def compute_internet_checksum(
    data: Union[bytes, bytearray],
    initial: int = 0
) -> int:
    """
    Compute the Internet checksum per RFC 1071.
    
    Args:
        data: Binary data to checksum
        initial: Initial sum value (for incremental checksums)
    
    Returns:
        16-bit checksum value in network byte order
    """
    # Start with initial value (for combining with pseudo-header)
    total = initial
    
    # Process complete 16-bit words
    length = len(data)
    i = 0
    
    while i < length - 1:
        # Combine two bytes into 16-bit word (network byte order)
        word = (data[i] << 8) | data[i + 1]
        total += word
        i += 2
    
    # Handle trailing odd byte by zero-padding
    if length % 2 == 1:
        total += data[-1] << 8
    
    # Fold 32-bit sum to 16 bits using end-around carry
    # Keep folding until all overflow bits are absorbed
    while total > 0xFFFF:
        total = (total & 0xFFFF) + (total >> 16)
    
    # Return one's complement of the sum
    return (~total) & 0xFFFF
 
 
def verify_internet_checksum(data: bytes) -> bool:
    """
    Verify data with embedded checksum.
    
    For correct data, summing all words (including checksum)
    and complementing should yield zero (or 0xFFFF in one's complement).
    
    Args:
        data: Data with checksum already embedded
    
    Returns:
        True if checksum is valid
    """
    total = 0
    length = len(data)
    i = 0
    
    while i < length - 1:
        word = (data[i] << 8) | data[i + 1]
        total += word
        i += 2
    
    if length % 2 == 1:
        total += data[-1] << 8
    
    while total > 0xFFFF:
        total = (total & 0xFFFF) + (total >> 16)
    
    # If all is correct, total should be 0xFFFF (all ones)
    # The complement of 0xFFFF is 0x0000
    return total == 0xFFFF or total == 0x0000
 
 
# === Demonstration ===
 
# Create a sample IP header (with checksum field set to zero)
ip_header = bytearray([
    0x45, 0x00,  # Version, IHL, DSCP, ECN
    0x00, 0x73,  # Total length: 115 bytes
    0x00, 0x00,  # Identification
    0x40, 0x00,  # Flags, Fragment offset
    0x40, 0x11,  # TTL: 64, Protocol: UDP (17)
    0x00, 0x00,  # Checksum (initially zero)
    0xc0, 0xa8, 0x00, 0x01,  # Source: 192.168.0.1
    0xc0, 0xa8, 0x00, 0xc7   # Dest: 192.168.0.199
])
 
# Compute checksum
checksum = compute_internet_checksum(ip_header)
print(f"Computed checksum: 0x{checksum:04X}")
 
# Insert checksum into header (bytes 10-11, big-endian)
ip_header[10] = (checksum >> 8) & 0xFF
ip_header[11] = checksum & 0xFF
print(f"IP header with checksum: {ip_header.hex()}")
 
# Verify
is_valid = verify_internet_checksum(bytes(ip_header))
print(f"Verification result: {is_valid}")
 
# Test error detection
corrupted = bytearray(ip_header)
corrupted[15] ^= 0x01  # Flip one bit in destination IP
is_valid_corrupted = verify_internet_checksum(bytes(corrupted))
print(f"Corrupted data verification: {is_valid_corrupted}")

Common Optimizations:

32-bit or 64-bit Accumulator: Process multiple words at once using a wider accumulator, then fold at the end. This reduces loop iterations.
Loop Unrolling: Process 4 or 8 words per iteration to reduce loop overhead.
Deferred Folding: Accumulate into a 32-bit (or 64-bit) variable without folding after each addition. Only fold once at the end. This works because overflows don't affect the final result if folded correctly.
SIMD Instructions: Use vector operations (SSE/AVX on x86, NEON on ARM) to process multiple words in parallel.
Hardware Offload: Modern NICs compute checksums in hardware, eliminating software overhead entirely.

optimized_checksum.c
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
45
46
47
48
49
50
51
52
53
54
/*
 * Optimized Internet Checksum (C/Assembly hybrid)
 * 
 * This version uses a 64-bit accumulator and processes
 * 8 bytes at a time for better performance.
 */
 
#include <stdint.h>
#include <stddef.h>
 
uint16_t fast_internet_checksum(const void* data, size_t len) {
    const uint16_t* ptr = (const uint16_t*) data;
    uint64_t sum = 0;  // Wide accumulator for deferred folding
    
    // Process 8 bytes (4 words) at a time
    while (len >= 8) {
        sum += ptr[0];
        sum += ptr[1];
        sum += ptr[2];
        sum += ptr[3];
        ptr += 4;
        len -= 8;
    }
    
    // Process remaining complete words
    while (len >= 2) {
        sum += *ptr++;
        len -= 2;
    }
    
    // Handle trailing byte
    if (len > 0) {
        sum += *(const uint8_t*)ptr << 8;  // Network byte order
    }
    
    // Fold 64-bit sum to 16 bits
    // First fold 64 -> 32
    sum = (sum >> 32) + (sum & 0xFFFFFFFF);
    sum = (sum >> 32) + (sum & 0xFFFFFFFF);
    
    // Then fold 32 -> 16
    sum = (sum >> 16) + (sum & 0xFFFF);
    sum = (sum >> 16) + (sum & 0xFFFF);
    
    return (uint16_t)(~sum);
}
 
/*
 * For maximum performance on x86-64, assembly can use:
 * - ADC (Add with Carry) instruction for end-around carry
 * - SIMD for parallel processing
 * 
 * Linux kernel uses assembly versions optimized per architecture.
 */

Real-World Performance

Incremental Checksum Update

The Problem:

When a router forwards an IPv4 packet, it decrements the TTL (Time To Live) field. If we had to recompute the entire header checksum for every packet, routers would waste enormous CPU cycles.

The Solution: Incremental Update

RFC 1624 describes how to update the checksum when specific fields change:

new_checksum = ~(~old_checksum + ~old_value + new_value)

In one's complement:

Subtract the old word contribution: add its complement
Add the new word contribution
Complement the result

This is O(1) regardless of packet size!

incremental_checksum.py
Python
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
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
"""
Incremental Checksum Update (RFC 1624)
 
When modifying a small part of checksummed data,
we can update the checksum without reprocessing all data.
"""
 
def incremental_checksum_update(
    old_checksum: int,
    old_value: int,
    new_value: int
) -> int:
    """
    Update checksum when a single 16-bit word changes.
    
    Based on RFC 1624:
    new_checksum = ~(~old_checksum + ~old_value + new_value)
    
    In one's complement arithmetic with end-around carry.
    
    Args:
        old_checksum: The current checksum value
        old_value: The 16-bit word being replaced
        new_value: The new 16-bit word value
    
    Returns:
        Updated checksum
    """
    # Convert to "sum form" by complementing the checksum
    # (checksum = ~sum, so ~checksum = sum)
    sum_val = (~old_checksum) & 0xFFFF
    
    # Subtract old value (add its complement in one's complement)
    sum_val += (~old_value) & 0xFFFF
    
    # Add new value
    sum_val += new_value
    
    # Fold overflows
    while sum_val > 0xFFFF:
        sum_val = (sum_val & 0xFFFF) + (sum_val >> 16)
    
    # Complement back to checksum form
    return (~sum_val) & 0xFFFF
 
 
def decrement_ttl_update_checksum(
    ip_header: bytearray
) -> None:
    """
    Decrement IP header TTL and update checksum in-place.
    
    This is what routers do for every forwarded packet.
    """
    # TTL is at byte 8, checksum at bytes 10-11
    old_ttl_word = (ip_header[8] << 8) | ip_header[9]  # TTL + Protocol
    old_checksum = (ip_header[10] << 8) | ip_header[11]
    
    # Decrement TTL (upper byte of the word)
    new_ttl = ip_header[8] - 1
    if new_ttl < 0:
        raise ValueError("TTL expired!")
    
    ip_header[8] = new_ttl
    new_ttl_word = (ip_header[8] << 8) | ip_header[9]
    
    # Update checksum incrementally
    new_checksum = incremental_checksum_update(
        old_checksum, old_ttl_word, new_ttl_word
    )
    
    # Write back updated checksum
    ip_header[10] = (new_checksum >> 8) & 0xFF
    ip_header[11] = new_checksum & 0xFF
 
 
# === Demonstration ===
 
# Sample IP header with valid checksum
ip_header = bytearray([
    0x45, 0x00, 0x00, 0x73,  # Version, IHL, DSCP, Total length
    0x00, 0x00, 0x40, 0x00,  # ID, Flags, Fragment
    0x40, 0x11,              # TTL=64, Protocol=UDP
    0xB8, 0x61,              # Checksum (pre-computed)
    0xC0, 0xA8, 0x00, 0x01,  # Source: 192.168.0.1
    0xC0, 0xA8, 0x00, 0xC7   # Dest: 192.168.0.199
])
 
print(f"Before:  TTL={ip_header[8]}, Checksum=0x{ip_header[10]:02X}{ip_header[11]:02X}")
 
# Decrement TTL and update checksum
decrement_ttl_update_checksum(ip_header)
 
print(f"After:   TTL={ip_header[8]}, Checksum=0x{ip_header[10]:02X}{ip_header[11]:02X}")
 
# Verify the updated checksum is correct
from typing import Union
def verify(data: bytes) -> bool:
    total = 0
    for i in range(0, len(data), 2):
        total += (data[i] << 8) | data[i + 1]
    while total > 0xFFFF:
        total = (total & 0xFFFF) + (total >> 16)
    return total == 0xFFFF
 
print(f"Checksum valid: {verify(bytes(ip_header))}")

NAT Implications

Protocol-Specific Usage

The Internet checksum is used differently in each protocol layer. Understanding these differences is essential for network programming and protocol analysis.

IPv4 Header Checksum

•Covers only the IP header (minimum 20 bytes, up to 60 with options)
•Recalculated at each hop because TTL changes
•Field position: Bytes 10-11 of IP header
•Zero if offloaded: Hardware may set to 0x0000 if checksum is computed by NIC
•Not in IPv6: Removed to speed up routing; link-layer CRC is trusted

TCP Checksum

•Mandatory — Must always be computed and verified
•Covers: Pseudo-header + TCP header + TCP payload
•Pseudo-header includes: Source IP, Dest IP, Protocol (6), TCP Length
•End-to-end: Computed by sender, verified by receiver; intermediate nodes don't modify
•Payload included: Catches corruption in application data, not just headers

UDP Checksum

•Optional in IPv4 — Can be set to 0x0000 to skip (though RFC recommends computing)
•Mandatory in IPv6 — IPv6 has no header checksum, so UDP must verify
•Covers: Pseudo-header + UDP header + UDP payload
•Zero means unused: If computed checksum is 0, transmit 0xFFFF instead (ambiguity avoidance)
•Often offloaded: NICs compute UDP checksum in hardware

Checksum Scope Comparison
Protocol	Header Protected	Payload Protected	Pseudo-Header	Recalculated Per Hop
IPv4	Yes (20-60 bytes)	No	No	Yes (TTL changes)
ICMP	Yes	Yes (data portion)	No	No
TCP	Yes	Yes	Yes	No
UDP	Yes	Yes	Yes	No

Checksum Offload Pitfalls

Error Detection Limitations

Known Weaknesses:

Undetectable Error Patterns

•Word transposition — Swapping any two 16-bit words leaves the checksum unchanged
•Byte transposition within words — Swapping bytes 2i and 2i+1 with bytes 2j and 2j+1 (for some i,j)
•Compensating single-bit errors — +1 in one position canceled by -1 in corresponding position of another word
•Zero-sum insertions — Adding 0x0000 words doesn't change the sum
•Certain burst patterns — Long bursts that happen to sum to zero

Research on Detection Rates:

Studies have measured the Internet checksum's effectiveness against real-world errors:

Stone & Partridge (2000): Analyzed TCP/IP traffic and found that 1 in 16 million to 1 in 10 billion TCP segments arrive with undetected errors (depending on the network). The checksum catches most errors, but not all.
Random bit errors: For uniformly random errors, approximately 1 in 65,536 pass undetected (as expected from a 16-bit checksum).
Burst errors: Detection depends on burst alignment and length. Short bursts (< 16 bits) are usually detected; longer bursts may escape.

Why This Is Acceptable:

Layered defense: Link-layer CRCs catch most errors before they reach IP/TCP.
Application-layer checks: Critical applications add their own integrity verification.
Error rarity: Modern fiber and Ethernet have very low bit error rates.
Cost-benefit: Stronger checksums would slow every packet on the Internet.

Defense in Depth

Summary: The Internet Checksum

The Internet checksum exemplifies elegant engineering under constraints. Let's consolidate the essential knowledge:

Key Takeaways

•One's complement arithmetic is the key — The use of end-around carry enables byte-order independence and efficient incremental updates.
•Verification is elegant — Sum everything including the checksum; if the result is all-ones, the data is valid.
•Incremental update enables routing — Routers can modify headers and update checksums in O(1) time, essential for high-speed forwarding.
•Pseudo-headers provide cross-layer protection — TCP/UDP checksums catch IP-layer corruption that might misdirect packets.
•Hardware offload is standard — Modern NICs compute and verify checksums without CPU involvement.
•Known weaknesses exist — Word transposition and certain burst patterns escape detection, but layered defenses compensate.

Looking Ahead:

Page Complete

2 / 5