The IPv4 Header, Field by Field

Twenty bytes, and two of them change at every hop

Step 1 of 2 — understand the idea. Read this first and the packet trace will confirm what you already expect, instead of teaching you two things at once.

What you'll be able to do

▸Name every field in a 20-byte IPv4 header and say what reads it
▸Explain why TTL and the header checksum change at each hop while the addresses do not
▸Predict how the checksum changes when TTL is decremented

Before this lesson — it builds directly on:

Local or Remote? The Decision That Drives Everything

A header is not a list of facts about a packet. Every field exists because something, somewhere, has to read it and act on it — and the useful way to learn one is to ask who that something is. The version and header length are read by whatever parses the header at all. The addresses are read by every router on the path. The protocol number is read once, by the destination, to decide who gets the payload. TTL is read and rewritten by every router. The identification and fragment fields matter only if something along the way has to split the packet up. Nothing in those twenty bytes is decoration.

IHL: Internet Header Length, in 32-bit words. 5 means 20 bytes and no options, which is almost every packet you will see.
Total length: The whole packet including the header, in bytes. Payload is total length minus IHL × 4.
TTL: Decremented by every router; the packet is destroyed at zero. A hop limit, despite the name saying time.
Protocol: Which layer gets the payload. 1 ICMP, 6 TCP, 17 UDP, 89 OSPF. The same job EtherType does one layer down.
Identification: Identifies this datagram for reassembly. Written by the sender and unchanged for the whole journey.

✗ Common misunderstanding: The destination address is rewritten at each hop, so the packet knows where to go next.

Why that's wrong: Nothing rewrites the IP addresses in normal forwarding. What changes at each hop is the ETHERNET destination, which is the next router rather than the final target.

Correct model: The IP header names the endpoints and survives the whole path. The frame around it names the next hop and is rebuilt at every one.

The packets prove it: In this lesson the same datagram appears three times with 10.0.3.40 as its destination throughout, while the frame carrying it is different each time.

Watch these fields in the lab: ipv4.version · ipv4.ihl · ipv4.ttl · ipv4.protocol

The clearest way to see which fields matter is to look at one datagram at three points on its path and diff them.

One echo request, captured as it leaves PC1, R1 and R2:

                    at PC1     after R1   after R2
  version              4           4          4
  IHL                  5           5          5
  total length        52          52         52
  identification    1000        1000       1000
  TTL                 64          63         62   ← changes
  protocol             1           1          1
  header checksum  24240       24496      24752   ← changes
  source IP     10.0.1.10   10.0.1.10  10.0.1.10
  dest IP       10.0.3.40   10.0.3.40  10.0.3.40

Two fields out of nine, and the checksum moves by exactly 256 each time. TTL sits in the high byte of a 16-bit word, so a decrement of one changes that word by 0x0100 — which is 256.

Watch these fields in the lab: ipv4.ttl · ipv4.headerChecksum

✓ Concept check — before you open the packets

These test the idea, not the trace. You should be able to answer them from the explanation above.

A packet arrives with TTL 62 from a host that sends with TTL 64. What does that tell you?

Why must the header checksum be recomputed at every hop?

Now that you understand the concept, observe how it appears in the packet exchange.

The lab runs a real simulated capture — pause, step, click any packet, and inspect every byte.