skip to content

Why does TCP's checksum cover IP addresses that live in the IP header, and what does that cross-layer coupling force on devices that rewrite addresses and on IPv6?

level: seniorimportance: nice to knowfreq 18%

answer

  1. a header that is never sent
  2. protection against misrouting
  3. rewrite an address, fix a checksum
  4. IPv6 dropped the header checksum

basics

~20 s

TCP and UDP checksums include a pseudo-header of the IP source and destination addresses, protocol number and length, so a misdelivered segment fails verification. Anything rewriting IP addresses must fix transport checksums, and IPv6 needed new pseudo-headers.

solid answer

~40 s

The TCP checksum is computed over a **pseudo-header** that is never transmitted: for IPv4, the source and destination addresses, a zero byte, the protocol number and the TCP length, 96 bits in all. RFC 9293 says this protects the connection against misrouted segments, since the IPv4 header checksum covers only the IP header and IPv6 has none. UDP does the same (RFC 768). The price is that the transport layer depends on the network layer's addresses. A NAT that rewrites an address must also update the TCP or UDP checksum, so it has to parse the transport header. IPv6 forced every such transport to adopt a 320-bit pseudo-header (RFC 8200 §8.1), and made the UDP checksum mandatory, because nothing else protects the addresses.

go deeper

for a junior

Know that TCP and UDP checksums also cover the IP source and destination addresses, through a pseudo-header that is never sent.

for a middle

List the pseudo-header fields, explain that it protects against misdelivery, and why the IPv4 header checksum cannot do that end to end.

for a senior

Explain the operational fallout: NAT must fix transport checksums, IPv6 made UDP checksums mandatory, and routers leave transport checksums untouched.

for a principal

Argue the tradeoff: cheap end-to-end protection against the cost of middleboxes that must understand transports, which slows deployment of new ones.

## What the pseudo-header is A **pseudo-header** is a block of fields borrowed from the IP layer that TCP and UDP feed into their checksum calculation but never put on the wire. Both ends rebuild it from the IP header they send or receive. For IPv4, RFC 9293 §3.1 and RFC 768 define it as: | Field | Size | Taken from | |---|---|---| | Source address | 32 bits | IPv4 header | | Destination address | 32 bits | IPv4 header | | Zero | 8 bits | constant | | Protocol (`PTCL`) | 8 bits | IPv4 Protocol field (6 for TCP, 17 for UDP) | | TCP or UDP length | 16 bits | computed; not transmitted by TCP | That is **96 bits** for IPv4. For IPv6, RFC 8200 §8.1 defines a **320-bit** version: the two 128-bit addresses, a 32-bit upper-layer packet length, three zero bytes and the upper-layer protocol number, which differs from the IPv6 header's Next Header value when extension headers sit in between. ## Why reach across the layer boundary Encapsulation says TCP should not care about IP's header. The pseudo-header breaks that on purpose: - **Misdelivery protection.** RFC 9293 says including the pseudo-header gives the connection protection against misrouted segments. If an address were corrupted inside a router, after the old IPv4 header checksum was checked and before the new one was written, the recomputed header checksum would vouch for the wrong value. The transport checksum is computed only by the two ends, so it still catches the damage. - **End-to-end scope.** The IPv4 header checksum covers only the IP header and is updated at every hop. The transport checksum is the only one that runs from sender to receiver over the addresses. - **TCP never skips it.** RFC 9293 makes the TCP checksum mandatory: the sender must generate it and the receiver must check it. ## What the coupling forces 1. **Address rewriting reaches into the transport header.** A NAT that changes a source address changes the pseudo-header, so the TCP or UDP checksum is now wrong. The translator must update it, which means it must understand the transport protocol. A transport it does not recognise cannot be fixed this way. 2. **A new IP version means new transport checksums.** RFC 8200 §8.1 says any upper-layer protocol that includes IP addresses in its checksum must be modified for IPv6 to use the 128-bit addresses. TCP, UDP and every similar protocol changed. 3. **UDP's checksum stops being optional in IPv6.** Over IPv4, RFC 768 lets a sender transmit zero to mean "no checksum". IPv6 removed the IP header checksum, so RFC 8200 makes the UDP checksum mandatory: a computed zero is sent as hex FFFF, and receivers discard a zero checksum. The only exception is the zero-checksum mode for UDP tunnel encapsulations governed by RFC 6936. 4. **ICMP gained a pseudo-header.** ICMPv6 includes the pseudo-header, unlike ICMPv4, precisely because IPv6 has no internet-layer checksum left to protect the fields ICMP depends on. ## What it does not force - **Routers leave the transport checksum alone.** The TTL and the IPv4 header checksum are not in the pseudo-header, so an ordinary router that decrements the TTL updates only the IPv4 header checksum. - **Switches** touch neither: they do not rewrite the IP header at all. ## The layering lesson The pseudo-header is a small, deliberate violation of the layering that encapsulation teaches, and it shows why RFC 3439 calls strict layering a guide rather than a law: layers end up needing each other's information. For an interviewer, the strong answer names both sides: - **Benefit:** cheap end-to-end protection of the addressing that decides where data lands. - **Cost:** middleboxes that rewrite addresses must understand transports, which makes deploying a new transport harder, and every IP version change ripples into every transport that checksums addresses. ## Common mistakes - Saying the TCP checksum covers only the TCP header and data. - Saying the IPv4 header checksum protects the payload. - Believing a NAT only has to edit the IP header. - Believing routers must recompute the TCP checksum when they decrement TTL. - Assuming a zero UDP checksum is acceptable over IPv6 as it is over IPv4.

  • Why did IPv6 make the UDP checksum mandatory when IPv4 allowed zero?
    IPv6 removed the IP header checksum, so without the UDP checksum nothing end to end would protect the addresses that decide delivery. RFC 8200 requires the sender to compute it over the pseudo-header, send a computed zero as FFFF, and receivers to discard zero checksums, except in the RFC 6936 zero-checksum mode for tunnels.
  • Why does ICMPv6 include a pseudo-header in its checksum when ICMPv4 did not?
    RFC 8200 explains that it protects ICMPv6 from misdelivery or corruption of the IPv6 header fields it depends on, which, unlike in IPv4, no internet-layer checksum covers. The change follows directly from IPv6 dropping the header checksum.
  • Is the pseudo-header a layering violation, and does that matter in practice?
    Yes, deliberately. It buys end-to-end protection of addressing cheaply, but it makes address rewriters depend on transport formats and made the move to IPv6 a change in every transport. That coupling is one reason new transports struggle to cross devices that rewrite headers.

saying these in an interview costs you the question

  • The TCP checksum covers only the TCP header and its data.
  • The IPv4 header checksum also protects the transport payload.
  • A NAT only has to rewrite the IP header, never the TCP header.
  • Routers must recompute the TCP checksum every time they decrement TTL.
  • Over IPv6 a UDP sender may leave the checksum zero, just as over IPv4.