Summary

  • TCP's mandatory checksum covers its header and data plus a conceptual pseudo-header built from lower-layer addresses, protocol identity and TCP length.
  • The pseudo-header is reconstructed for calculation and is not transmitted as part of the TCP segment; its purpose is to detect corruption and some forms of misdelivery across the IP/TCP boundary.
  • This is error-detection evidence, not cryptographic authentication, route proof or authorization.

A TCP segment appears to begin with source and destination ports. Its checksum, however, begins earlier in the protocol stack. The sender takes values supplied by IP, arranges them as a small conceptual header, and includes those words in the same calculation as the TCP header and payload. The receiver builds the same values again before deciding whether the segment is acceptable.

That extra material is called a pseudo-header because it participates in the calculation without becoming another transmitted TCP header. In the IPv4 design published in RFC 793, it is 96 bits long: source address, destination address, a zero byte, the IP protocol number and TCP length. The address and protocol fields already travel in the IP header. TCP does not copy them onto the wire. It asks the lower layer to supply them at the boundary between the two protocols.

The choice solved a specific evidentiary problem. A checksum over TCP bytes alone could establish that the ports, sequence numbers and data arrived with the same arithmetic sum, yet say nothing about whether the enclosing packet's addresses or protocol identity had been corrupted. By including selected IP context, the transport calculation can fail when the segment reaches a different endpoint context from the one used by its sender. RFC 793 described the purpose plainly as protection against misrouted segments.

The arithmetic remained economical. The checksum field holds the 16-bit one's-complement of the one's-complement sum of the covered 16-bit words. During calculation, the checksum field itself is treated as zero. If the TCP header and data end on an odd octet, a zero octet is appended on the right solely to complete the final word. That pad is never sent. Like the pseudo-header, it belongs to the calculation rather than to the segment's public length.

TCP length carries the same distinction. For IPv4 it is the number of octets in the TCP header plus TCP data. It is computed rather than separately transmitted, and it does not count the pseudo-header's twelve octets. The checksum therefore covers a length value that describes the real TCP material while excluding the conceptual material used to protect it.

RFC 9293 retained the design and made its cross-layer contract explicit. The TCP checksum is never optional: the sender must generate it and the receiver must check it. Any lower-level protocol supporting TCP has to provide the source and destination addresses, protocol identity and a way to determine TCP length. The pseudo-header is not merely an IPv4 diagram preserved for nostalgia; it is part of what TCP requires from the service below it.

IPv6 changes the shape without changing the principle. Its pseudo-header is 320 bits and contains the IPv6 source and destination addresses, a 32-bit Upper-Layer Packet Length, three zero bytes and a Next Header value. If IPv6 extension headers appear before TCP, the checksum uses the value identifying TCP at the end of that chain, not necessarily the immediate Next Header value in the fixed IPv6 header. The receiver must recreate the transport context, not blindly copy one nearby field.

Source routing exposes another edge. RFC 9293 says the checksum addresses must be the originating source and ultimate destination. Intermediate routing addresses are not the connection endpoints that the transport calculation is meant to bind. The rule separates a packet's route instructions from the endpoint context whose integrity TCP is checking.

What does the checksum prove? Less than authentication, but more than a sum over payload alone. A matching value is evidence that the receiver reconstructed a compatible set of covered words. It can catch many accidental bit changes and certain delivery-context errors. Because the function is only 16 bits and is not keyed, it does not identify the sender, authorize the connection or defeat a deliberate attacker who can alter traffic and recompute the value.

The pseudo-header's task was to make ordinary transport integrity reach across a protocol boundary without duplicating the lower-layer header in every TCP segment.

The lasting design is therefore not a hidden packet. It is an agreement between layers. IP carries the addressing context, TCP selects the parts that matter to its integrity calculation, and both endpoints reconstruct the same conceptual input. The wire remains compact, while the evidence used to accept the segment extends beyond the visible TCP bytes.

Sources