The UDP Pseudo-Header - UDP Checksum | OneNoughtOne

0/240

Computer NetworksUDP Protocol

UDP Checksum

LevelIntermediate

Duration60 mins

TopicUDP Protocol

1 / 5

The UDP Pseudo-Header

A Clever Solution to a Hidden Problem

When a UDP datagram travels across the Internet, it faces an invisible threat that has nothing to do with network congestion, packet loss, or malicious attacks. The threat is silent corruption—bits that flip due to electromagnetic interference, faulty hardware, cosmic rays striking memory cells, or software bugs in routers. A single corrupted bit can change a financial transaction amount, misdirect critical medical data, or crash an application expecting valid input.

The UDP header contains a checksum field designed to detect such corruption. But here's the puzzle: the UDP header is remarkably small—only 8 bytes. It contains source port, destination port, length, and checksum. Notably absent from this header are the source and destination IP addresses.

Yet if the IP addresses were corrupted during transmission—causing the datagram to arrive at the wrong host entirely—wouldn't we want to detect that as corruption? Absolutely. This is where the concept of the pseudo-header emerges as an elegant solution to a fundamental design constraint.

What You Will Learn

By the end of this page, you will understand what the pseudo-header is, why it was designed this way, exactly what fields it contains for both IPv4 and IPv6, how it integrates with the checksum calculation, and the subtle engineering tradeoffs that led to this design. You'll appreciate why this seemingly abstract construct is essential to UDP's reliability guarantees.

The Problem the Pseudo-Header Solves

To understand the pseudo-header, we must first understand the layered architecture problem it addresses. In the OSI and TCP/IP models, each layer is supposed to operate independently—encapsulating data from the layer above without concerning itself with lower-layer details. This principle of layer independence enables modular protocol design.

The UDP header's intentional minimalism:

UDP was designed to be the simplest possible transport protocol—a thin wrapper around application data that adds just enough functionality to enable multiplexing (via port numbers) and optional error detection (via checksum). The designers deliberately kept IP addresses out of the UDP header because:

Avoiding redundancy: IP addresses are already in the IP header. Duplicating them in UDP would waste bandwidth.
Layer separation: Transport protocols shouldn't need to know about network-layer details.
Flexibility: Applications could theoretically run UDP over different network protocols.

The Hidden Vulnerability

If the UDP checksum only covered the UDP header and payload, corruption in the IP header's address fields would go undetected by UDP. A datagram could arrive at Host B when it was intended for Host C—and if the UDP checksum passed (because UDP data wasn't corrupted), the receiving application would accept garbage data or data meant for someone else.

The security and correctness implications:

Consider a scenario where a banking application sends UDP datagrams containing transaction records:

Source: Payment Server (192.168.1.100:5000)
Destination: Database Server (192.168.1.200:3306)
Payload: "CREDIT account_12345 $10,000"

Now imagine a single bit flip in the IP header changes the destination address from 192.168.1.200 to 192.168.1.201 (an unauthorized server). If UDP's checksum only covered the UDP portion:

The IP header corruption goes unnoticed by UDP
The datagram arrives at the wrong server
The wrong server's UDP stack validates the checksum successfully (UDP data is intact)
Sensitive financial data is delivered to an unintended recipient

This is precisely the attack vector—or accidental failure mode—that the pseudo-header prevents.

What the Pseudo-Header Protects Against

•Source IP corruption — Datagram appears to come from wrong sender; replies would go to wrong host
•Destination IP corruption — Datagram delivered to unintended recipient; data confidentiality breach
•Protocol field corruption — Data interpreted by wrong transport protocol handler
•Length field corruption — Receiver processes wrong amount of data; buffer issues possible
•Cross-layer integrity — Ensures transport and network layer information remain consistent

What Is the Pseudo-Header?

The pseudo-header is a conceptual data structure that exists only for the purpose of checksum calculation—it is never transmitted on the network. It's a clever mechanism that allows the transport layer to incorporate network-layer information into its integrity check without violating layer boundaries in the actual packet format.

The key insight:

Both the sender and receiver can construct the pseudo-header from information available at their respective ends:

The sender knows the source and destination IP addresses (it's sending the packet)
The receiver knows these addresses (they're in the IP header it just processed)

By agreeing on a pseudo-header format and including it in checksum calculation, both sides can verify that the critical routing information hasn't been corrupted—without actually transmitting this redundant data.

The 'Pseudo' in Pseudo-Header

The term 'pseudo' (from Greek 'pseudēs' meaning false) indicates this header is not real in the sense of being transmitted. It's a computational artifact—assembled temporarily, fed into the checksum algorithm, and then discarded. Think of it as a 'virtual header' that exists only in the mathematical calculation, like a variable that's computed but never stored.

The pseudo-header concept applies to both UDP and TCP:

Both transport protocols use this technique because both face the same architectural challenge. The pseudo-header format differs slightly between protocols (the 'Protocol' field value differs), but the principle is identical. This unified approach means that the integrity guarantees are consistent across connection-oriented and connectionless transport.

Conceptual flow of checksum calculation:

┌─────────────────────────────────────────────────────────────────┐
│                    CHECKSUM CALCULATION INPUT                    │
├─────────────────────────────────────────────────────────────────┤
│                                                                  │
│   ┌──────────────────┐   ┌──────────────┐   ┌────────────────┐  │
│   │  Pseudo-Header   │ + │  UDP Header  │ + │   UDP Payload  │  │
│   │ (never sent)     │   │ (8 bytes)    │   │ (variable)     │  │
│   └──────────────────┘   └──────────────┘   └────────────────┘  │
│                                                                  │
│                              ↓                                   │
│                    ┌─────────────────────┐                      │
│                    │  Checksum Algorithm │                      │
│                    │  (1's complement)   │                      │
│                    └─────────────────────┘                      │
│                              ↓                                   │
│                    ┌─────────────────────┐                      │
│                    │  16-bit Checksum    │                      │
│                    │  (stored in header) │                      │
│                    └─────────────────────┘                      │
│                                                                  │
└─────────────────────────────────────────────────────────────────┘

IPv4 Pseudo-Header Structure

When UDP operates over IPv4, the pseudo-header contains exactly 12 bytes of information extracted from or derived from the IP header. Understanding each field and its purpose is essential for implementing checksum calculation correctly.

IPv4 Pseudo-Header Layout:

 0                   1                   2                   3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                       Source IP Address                       |  Bytes 0-3
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                    Destination IP Address                     |  Bytes 4-7
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|     Zero      |   Protocol    |          UDP Length           |  Bytes 8-11
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

IPv4 Pseudo-Header Fields Detailed Analysis
Field	Size	Value/Source	Purpose
Source IP Address	32 bits (4 bytes)	Copied from IPv4 header	Ensures sender identity is verified; prevents source spoofing from causing undetected delivery
Destination IP Address	32 bits (4 bytes)	Copied from IPv4 header	Ensures datagram reached intended recipient; prevents misdelivery due to address corruption
Zero	8 bits (1 byte)	Always 0x00	Padding for alignment; reserved for future use; ensures consistent pseudo-header size
Protocol	8 bits (1 byte)	17 (0x11) for UDP	Confirms correct transport protocol handling; prevents TCP data being processed by UDP handler
UDP Length	16 bits (2 bytes)	Copied from UDP header	Validates payload boundary; prevents buffer over-read or truncation attacks

Why Include the Protocol Field?

The protocol field (17 for UDP, 6 for TCP) ensures that if a bit flip corrupts the IP header's protocol field, causing the wrong transport handler to receive the data, the checksum will fail. Without this, UDP data could be misinterpreted as TCP data or vice versa—potentially causing protocol state corruption or security vulnerabilities.

Byte-by-byte construction example:

Let's construct a pseudo-header for a UDP datagram with these parameters:

Source IP: 192.168.1.100 (0xC0.A8.01.64)
Destination IP: 10.0.0.50 (0x0A.00.00.32)
UDP Length: 28 bytes (8-byte header + 20-byte payload)

Byte Position:  [0]  [1]  [2]  [3]  [4]  [5]  [6]  [7]  [8]  [9]  [10] [11]
Hex Values:     C0   A8   01   64   0A   00   00   32   00   11   00   1C
                └── Source IP ──┘   └── Dest IP ───┘   │    │    └ Length ┘
                192.168.1.100       10.0.0.50          Zero Protocol  28
                                                            (UDP=17)

This 12-byte pseudo-header is prepended (conceptually) to the UDP header and payload before checksum calculation. The result is that any corruption to these critical fields—source IP, destination IP, protocol type, or UDP length—will cause the checksum to fail at the receiver.

ipv4_pseudo_header.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
import struct
import socket
 
def construct_ipv4_pseudo_header(src_ip: str, dst_ip: str, udp_length: int) -> bytes:
    """
    Constructs the IPv4 pseudo-header for UDP checksum calculation.
    
    Args:
        src_ip: Source IPv4 address as dotted-decimal string
        dst_ip: Destination IPv4 address as dotted-decimal string  
        udp_length: Total UDP segment length (header + payload)
    
    Returns:
        12-byte pseudo-header as bytes object
    """
    # Convert IP addresses from string to packed binary format
    src_ip_bytes = socket.inet_aton(src_ip)  # 4 bytes
    dst_ip_bytes = socket.inet_aton(dst_ip)  # 4 bytes
    
    # Protocol number for UDP is 17 (0x11)
    UDP_PROTOCOL = 17
    
    # Zero padding (reserved byte)
    zero_padding = 0
    
    # Pack the pseudo-header:
    # '!' = network byte order (big-endian)
    # '4s' = 4-byte string (source IP)
    # '4s' = 4-byte string (destination IP)  
    # 'B' = unsigned char (zero padding)
    # 'B' = unsigned char (protocol)
    # 'H' = unsigned short (UDP length)
    pseudo_header = struct.pack(
        '!4s4sBBH',
        src_ip_bytes,
        dst_ip_bytes,
        zero_padding,
        UDP_PROTOCOL,
        udp_length
    )
    
    return pseudo_header
 
# Example usage
if __name__ == "__main__":
    pseudo = construct_ipv4_pseudo_header(
        src_ip="192.168.1.100",
        dst_ip="10.0.0.50",
        udp_length=28
    )
    
    print(f"Pseudo-header length: {len(pseudo)} bytes")
    print(f"Pseudo-header (hex): {pseudo.hex()}")
    # Output: c0a80164 0a000032 00 11 001c
    #         (src IP)  (dst IP)  0 UDP len

IPv6 Pseudo-Header Structure

IPv6 introduced a significantly larger address space (128-bit addresses versus IPv4's 32-bit), which necessitated redesigning the pseudo-header. The IPv6 pseudo-header is 40 bytes—more than three times larger than the IPv4 version—primarily due to the expanded address fields.

IPv6 Pseudo-Header Layout:

 0                   1                   2                   3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                                                               |
+                                                               +
|                                                               |
+                       Source IPv6 Address                     +
|                                                               |
+                                                               +
|                                                               |  Bytes 0-15
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                                                               |
+                                                               +
|                                                               |
+                    Destination IPv6 Address                   +
|                                                               |
+                                                               +
|                                                               |  Bytes 16-31
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                   Upper-Layer Packet Length                   |  Bytes 32-35
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                      Zero (24 bits)           | Next Header   |  Bytes 36-39
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

IPv6 Pseudo-Header Fields Detailed Analysis
Field	Size	Value/Source	Purpose
Source IPv6 Address	128 bits (16 bytes)	From IPv6 header	Extended address verification; essential given IPv6's larger address space
Destination IPv6 Address	128 bits (16 bytes)	From IPv6 header	Ensures delivery to intended recipient across global IPv6 network
Upper-Layer Packet Length	32 bits (4 bytes)	UDP segment length	Supports jumbograms (packets > 64KB); expanded from IPv4's 16-bit field
Zero	24 bits (3 bytes)	Always 0x000000	Padding and reserved space; ensures 32-bit alignment
Next Header	8 bits (1 byte)	17 (0x11) for UDP	Equivalent to IPv4's Protocol field; identifies upper-layer protocol

Key Differences from IPv4

Beyond the larger addresses, note that IPv6 uses 'Upper-Layer Packet Length' (32 bits) instead of IPv4's 16-bit UDP Length. This enables UDP to support IPv6 jumbograms—packets larger than 65,535 bytes. Also, 'Next Header' replaces 'Protocol' to align with IPv6 extension header terminology.

Practical implications of the larger pseudo-header:

The IPv6 pseudo-header's 40-byte size means more data enters the checksum calculation. This has several implications:

Slightly increased computation: More bytes to process, though modern CPUs handle this trivially
Better protection: 128-bit addresses mean corruption is less likely to accidentally produce a valid different address
Consistency with IPv6 design: The elongated fields match IPv6's philosophy of generous field sizes

IPv6 pseudo-header construction example:

For a UDP datagram with:

Source: 2001:db8::1
Destination: 2001:db8::2
UDP Length: 28 bytes

Bytes 0-15:   20 01 0d b8 00 00 00 00 00 00 00 00 00 00 00 01  (Source)
Bytes 16-31:  20 01 0d b8 00 00 00 00 00 00 00 00 00 00 00 02  (Destination)
Bytes 32-35:  00 00 00 1C                                      (Length = 28)
Bytes 36-39:  00 00 00 11                                      (Zero + Next Header = 17)

Total: 40 bytes of pseudo-header feeding into the checksum algorithm.

ipv6_pseudo_header.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
import struct
import socket
 
def construct_ipv6_pseudo_header(src_ip: str, dst_ip: str, udp_length: int) -> bytes:
    """
    Constructs the IPv6 pseudo-header for UDP checksum calculation.
    
    Args:
        src_ip: Source IPv6 address as string (e.g., '2001:db8::1')
        dst_ip: Destination IPv6 address as string
        udp_length: Total UDP segment length (header + payload)
    
    Returns:
        40-byte pseudo-header as bytes object
    """
    # Convert IPv6 addresses to packed 16-byte format
    src_ip_bytes = socket.inet_pton(socket.AF_INET6, src_ip)  # 16 bytes
    dst_ip_bytes = socket.inet_pton(socket.AF_INET6, dst_ip)  # 16 bytes
    
    # Next Header value for UDP is 17 (0x11)
    UDP_NEXT_HEADER = 17
    
    # Pack the pseudo-header:
    # '!' = network byte order (big-endian)
    # '16s' = 16-byte string (IPv6 source address)
    # '16s' = 16-byte string (IPv6 destination address)
    # 'I' = unsigned int (32-bit upper-layer packet length)
    # '3x' = 3 bytes of zero padding
    # 'B' = unsigned char (next header)
    pseudo_header = struct.pack(
        '!16s16sI3xB',
        src_ip_bytes,
        dst_ip_bytes,
        udp_length,
        UDP_NEXT_HEADER
    )
    
    return pseudo_header
 
# Example usage
if __name__ == "__main__":
    pseudo = construct_ipv6_pseudo_header(
        src_ip="2001:db8::1",
        dst_ip="2001:db8::2",
        udp_length=28
    )
    
    print(f"Pseudo-header length: {len(pseudo)} bytes")
    print(f"Pseudo-header (hex): {pseudo.hex()}")
    # Source:      2001 0db8 0000 0000 0000 0000 0000 0001
    # Destination: 2001 0db8 0000 0000 0000 0000 0000 0002
    # Length:      0000001c (28)
    # Zero+Next:   000011

Design Rationale and Engineering Trade-offs

The pseudo-header represents a careful balance between several competing engineering concerns. Understanding these trade-offs reveals the thoughtful design behind what might seem like a simple mechanism.

Trade-off 1: Layer purity vs. end-to-end integrity

Strict layer separation would dictate that UDP knows nothing about IP addresses—that's the network layer's concern. But the pseudo-header deliberately 'leaks' network layer information upward to provide stronger end-to-end guarantees.

The designers decided that integrity trumps architectural purity. A packet that arrives at the wrong destination due to address corruption is worse than a slightly impure layer design.

Trade-off 2: Bandwidth efficiency vs. redundancy

An alternative design could embed IP addresses directly in the UDP header. This would:

Increase UDP header size from 8 to 16 bytes (IPv4) or 40 bytes (IPv6)
Enable independent verification without reconstructing pseudo-headers
Waste bandwidth with redundant information on every packet

The pseudo-header avoids this bandwidth waste while maintaining equivalent protection—a elegant solution that uses computation instead of transmission.

Advantages of Pseudo-Header Design

•Zero transmission overhead — No extra bytes sent on the wire
•Cross-layer protection — Verifies network layer info at transport layer
•Symmetric computation — Sender and receiver use identical logic
•Protocol agnostic — Same technique works for UDP and TCP
•Backward compatible — Doesn't change packet format

Limitations and Considerations

•Layer boundary violation — Transport depends on network layer details
•NAT complexity — NAT devices must recalculate checksums when changing IPs
•Implementation requirement — Every UDP implementation must handle this correctly
•No encryption — Pseudo-header provides integrity, not confidentiality
•Reconstruction requirement — Receiver must construct identical pseudo-header

NAT and Checksum Implications

When a NAT device modifies the source IP address in a packet's IP header, it MUST also recalculate the UDP checksum. Since the pseudo-header includes the source IP, changing it without updating the checksum would cause the receiver to reject the packet. This adds processing overhead to NAT devices and is one reason some implementations set the UDP checksum to zero when transmitting over trusted networks.

Historical context and RFC evolution:

The pseudo-header concept was established in the original UDP specification (RFC 768, 1980) and has remained stable for over four decades. When IPv6 was developed, the concept was preserved and extended in RFC 2460 (1998) and updated specifications. This longevity speaks to the fundamental correctness of the design.

Why not just trust IP header checksum?

IPv4 has its own header checksum, so one might ask: if IP verifies its header integrity, why does UDP need to include IP fields in its checksum?

Routers don't check full integrity: IP header checksum is recalculated at each hop (TTL decrements), but intermediate routers don't verify end-to-end
IP checksum only covers header: It doesn't protect the relationship between addresses and the data they route
IPv6 removed IP header checksum: In IPv6, upper layers must provide their own integrity checks—making UDP checksum even more critical
Defense in depth: Multiple layers of protection catch different failure modes

Implementation Considerations

Implementing pseudo-header handling correctly is essential for any UDP stack. Here we examine the practical considerations and common pitfalls.

Order of operations:

The checksum calculation must follow a precise sequence:

Construct pseudo-header from IP addresses, protocol, and UDP length
Assemble complete data = pseudo-header + UDP header (with checksum field zeroed) + payload
Calculate checksum using one's complement sum
Store checksum in the UDP header's checksum field
Transmit only the IP header + UDP header + payload (pseudo-header is not sent)

At the receiver:

Extract IP addresses from received IP header
Reconstruct pseudo-header identically to sender
Calculate checksum over pseudo-header + received UDP segment
Verify result equals 0xFFFF (all ones) if valid

complete_checksum_calculation.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
import struct
import socket
 
def ones_complement_sum(data: bytes) -> int:
    """
    Calculate the one's complement sum of 16-bit words.
    Handles odd-length data by padding with zero.
    """
    if len(data) % 2 == 1:
        data += b'\x00'  # Pad with zero byte if odd length
    
    total = 0
    for i in range(0, len(data), 2):
        word = (data[i] << 8) + data[i + 1]
        total += word
        # Fold 32-bit overflow back into 16 bits
        total = (total & 0xFFFF) + (total >> 16)
    
    return total
 
def calculate_udp_checksum(
    src_ip: str,
    dst_ip: str,
    src_port: int,
    dst_port: int,
    payload: bytes
) -> int:
    """
    Calculate the complete UDP checksum including pseudo-header.
    
    Returns:
        16-bit checksum value, or 0xFFFF if computed checksum is 0
    """
    udp_length = 8 + len(payload)  # 8-byte header + payload
    
    # Step 1: Construct pseudo-header (IPv4)
    pseudo_header = struct.pack(
        '!4s4sBBH',
        socket.inet_aton(src_ip),
        socket.inet_aton(dst_ip),
        0,           # Zero padding
        17,          # Protocol (UDP)
        udp_length
    )
    
    # Step 2: Construct UDP header with checksum = 0
    udp_header = struct.pack(
        '!HHHH',
        src_port,
        dst_port,
        udp_length,
        0            # Checksum placeholder
    )
    
    # Step 3: Combine for checksum calculation
    complete_data = pseudo_header + udp_header + payload
    
    # Step 4: Calculate one's complement sum
    checksum = ones_complement_sum(complete_data)
    
    # Step 5: Take one's complement of the sum
    checksum = ~checksum & 0xFFFF
    
    # Step 6: Per RFC 768, if checksum is 0, use 0xFFFF
    # (because 0 means "no checksum computed")
    if checksum == 0:
        checksum = 0xFFFF
    
    return checksum
 
# Example
checksum = calculate_udp_checksum(
    src_ip="192.168.1.100",
    dst_ip="10.0.0.50",
    src_port=12345,
    dst_port=53,
    payload=b"Hello, UDP!"
)
print(f"Computed checksum: 0x{checksum:04X}")

Critical: The Zeroed Checksum Field

When calculating the checksum, the UDP header's checksum field MUST be set to zero, not its eventual value. This is a common implementation bug. The checksum calculation produces the value that goes in this field—using any other value during calculation will produce incorrect results.

Common Implementation Mistakes

•Byte order errors — Failing to use network byte order (big-endian) for multi-byte values
•Forgetting padding — Not handling odd-length payloads with zero-padding
•Wrong pseudo-header size — Using IPv4 pseudo-header for IPv6 or vice versa
•Including checksum in calculation — Not zeroing the checksum field before computing
•Off-by-one length — Using payload length instead of total UDP segment length
•Missing final complement — Forgetting the final one's complement of the sum
•Zero handling — Not converting 0x0000 to 0xFFFF (IPv4 only)

Pseudo-Header in Protocol Analysis

Understanding the pseudo-header is essential when analyzing network traffic or debugging protocol issues. Tools like Wireshark automatically handle pseudo-header construction, but knowing what's happening enables deeper analysis.

What Wireshark shows:

When you capture a UDP packet in Wireshark and examine the checksum, you'll see:

User Datagram Protocol, Src Port: 12345, Dst Port: 53
    Source Port: 12345
    Destination Port: 53
    Length: 19
    Checksum: 0x7a3b [correct]
        [Checksum Status: Good]
        [Calculated Checksum: 0x7a3b]

Wireshark reconstructs the pseudo-header from the IP header, combines it with the UDP segment, and verifies the checksum. If there's a mismatch, you'll see:

    Checksum: 0x7a3b [incorrect, should be 0x8c4f]
        [Checksum Status: Bad]

Debugging Checksum Failures

If you see checksum failures in captures: (1) Check if checksum offloading is enabled—modern NICs calculate checksums in hardware, so captures before transmission may show placeholder values. (2) Verify NAT isn't modifying addresses without recalculating checksums. (3) Check for MTU issues causing fragmentation where checksums can't be validated until reassembly.

Checksum offloading and capture artifacts:

Modern network interface cards (NICs) support checksum offloading—the NIC calculates checksums in hardware just before transmission. This creates a confusing situation when capturing packets:

Packets captured on the sending host may show incorrect or zero checksums
The NIC hasn't calculated the real checksum yet when the capture occurs
This is normal and expected—the packets on the wire have correct checksums

To see accurate checksums, capture on the receiving host or on an intermediate device (switch mirror port, network tap).

Manual verification example:

If you need to verify a UDP checksum manually:

Extract source and destination IP from IP header
Note the protocol (17) and UDP length
Construct the pseudo-header
Concatenate with the UDP segment (including the received checksum)
Calculate the one's complement sum
If result is 0xFFFF, checksum is valid; otherwise, corruption occurred

Summary: The Pseudo-Header Unveiled

We've explored the UDP pseudo-header in depth—from its conceptual origins to practical implementation. Let's consolidate the key insights:

Key Takeaways

•The pseudo-header is a checksum calculation construct — It exists only at computation time, never transmitted on the network
•It provides cross-layer integrity protection — UDP can verify IP address integrity without embedding addresses in its header
•IPv4 pseudo-header is 12 bytes — Contains source/destination IP (8 bytes), zero padding, protocol (1 byte), and UDP length (2 bytes)
•IPv6 pseudo-header is 40 bytes — Accommodates 128-bit addresses and 32-bit length for jumbogram support
•Both sender and receiver construct identical pseudo-headers — Enabling symmetric verification without extra transmission
•NAT devices must recalculate checksums — Because changing IP addresses changes the pseudo-header and thus the expected checksum
•The design trades layer purity for integrity — A deliberate decision that end-to-end correctness justifies
•Correct implementation requires attention to detail — Byte order, field zeroing, padding, and complement operations must be precise

What's next:

Now that we understand the pseudo-header and why it exists, we'll examine the complete checksum calculation process. The next page covers the mathematical algorithm—the one's complement arithmetic, handling of odd-length data, and the specific steps to produce a valid UDP checksum.

Page Complete

You now understand the UDP pseudo-header: its purpose, structure for both IPv4 and IPv6, design rationale, and implementation requirements. This foundation is essential for the checksum calculation we'll explore next.