skip to content

What fields make up the 20-byte IPv4 header, and which does a router read in flight versus only the destination host?

level: middleimportance: must knowfreq 48%

answer

  1. five 32-bit words
  2. version and length lead
  3. the fragmentation trio shares word two
  4. routers want TTL, checksum, destination
  5. the payload's type is for the endpoint

basics

~20 s

The IPv4 header holds Version, IHL, DSCP/ECN, Total Length, Identification, Flags, Fragment Offset, TTL, Protocol, Header Checksum, source and destination addresses, then optional options. Routers chiefly read destination, TTL and checksum; the destination host uses Protocol and reassembly fields.

solid answer

~50 s

Five 32-bit words: `Version` (4 bits), `IHL` (4), the old Type of Service byte now `DSCP` (6) plus `ECN` (2), and `Total Length` (16); `Identification` (16), `Flags` (3: reserved, DF, MF) and `Fragment Offset` (13); `Time to Live` (8), `Protocol` (8) and `Header Checksum` (16); then the 32-bit source and destination addresses, and up to 40 bytes of options. A router validates version, lengths and checksum, looks up the destination, decrements TTL and rewrites the checksum; it reads DSCP or ECN only if it does differentiated service or congestion marking, and the DF and fragment fields only when a datagram exceeds the next link's MTU. The destination host uses `Protocol` to pick TCP (6), UDP (17) or ICMP (1), `Total Length` to find the datagram's end, and the fragment fields to reassemble. Nothing in the protocol verifies the source address.

go deeper

for a junior

Recall that the header is five 32-bit words, that addresses are 32 bits, and that routers forward on the destination address while the endpoint uses the Protocol field.

for a middle

Walk the fields word by word and name the reader of each: routers validate, decrement TTL and rewrite the checksum; the destination demultiplexes, trims padding and reassembles.

for a senior

Read a capture critically: repeated IDs on DF-set traffic are legal under RFC 6864, a source address proves nothing, and options or odd lengths point to unusual senders.

for a principal

Explain why the header puts forwarding state up front and keeps the payload's type for the endpoint, and what that layering costs when middleboxes start reading deeper than IP.

## The layout, word by word RFC 791 defines the IPv4 header as **five 32-bit words (20 bytes)** followed by optional options. Field names below are RFC 791's, with the old Type of Service byte shown as RFC 2474 and RFC 3168 redefined it. | Word | Field | Bits | What it carries | |---|---|---|---| | 1 | `Version` | 4 | always 4 for IPv4 | | 1 | `IHL` | 4 | header length in 32-bit words (5-15) | | 1 | `DSCP` + `ECN` | 6 + 2 | per-hop behaviour selector; congestion codepoint | | 1 | `Total Length` | 16 | whole datagram in bytes, header included | | 2 | `Identification` | 16 | groups the fragments of one datagram | | 2 | `Flags` | 3 | reserved (zero), DF, MF | | 2 | `Fragment Offset` | 13 | fragment position in 8-byte units | | 3 | `Time to Live` | 8 | hop budget | | 3 | `Protocol` | 8 | what the payload is: 1 ICMP, 6 TCP, 17 UDP | | 3 | `Header Checksum` | 16 | covers the header only | | 4 | `Source Address` | 32 | sender's address | | 5 | `Destination Address` | 32 | final recipient's address | | 6+ | `Options` + padding | 0-320 | optional, padded to a word boundary | The sums check out: 4+4+8+16, 16+3+13 and 8+8+16 are each 32 bits, and the two addresses take one word each. ## Who reads which field The useful way to learn the header is by **reader**. A router forwarding the datagram and the host receiving it care about different fields. | Field | Router forwarding it | Destination host | |---|---|---| | `Version`, `IHL`, `Total Length` | validates them (RFC 1812 section 5.2.2) | finds where payload starts and datagram ends | | `Header Checksum` | verifies, then rewrites after the TTL change | verifies; silently discards a bad one | | `Time to Live` | decrements; zero means discard | ignores it | | `Destination Address` | the key for the route lookup | confirms the datagram is for this host | | `Source Address` | where any ICMP error it generates is sent | where replies go | | `Protocol` | not needed to forward | hands the payload to TCP, UDP or ICMP | | `Identification`, `MF`, `Fragment Offset` | used only if it must fragment | used to reassemble | | `DF` | read only when the datagram exceeds the next link's MTU | rarely matters | | `DSCP` | selects a per-hop behaviour if the router implements differentiated services | rarely acts on it | | `ECN` | a congested ECN-capable router may set CE | passes CE up to the transport | Three points interviewers listen for: - **Forwarding is a destination lookup.** A router needs the destination address, the TTL and a valid header; it does not need `Protocol` or anything above IP. A router that filters on protocol or ports is doing policy on top of forwarding. - **The fragment fields sleep until they are needed.** `Identification`, `MF` and `Fragment Offset` mean something only for a datagram that has been or may be fragmented, and `DF` matters only when a datagram is too big for the next link. How fragmentation itself works is a separate subject. - **`Protocol` is the endpoint's switchboard.** It names the next header, using the same numbers IPv6's Next Header field uses (RFC 8200). ## The source address is a claim The sender writes `Source Address`; nothing in IPv4 checks it. Routers forward on the destination and use the source only to address error messages. Any validation is a filtering policy an operator adds, not part of the header's semantics. ## The Identification field today RFC 791 describes `Identification` as a value "to aid in assembling the fragments of a datagram". RFC 6864 (2013) tightened that: 1. The field **MUST NOT be used for anything other than fragmentation and reassembly.** 2. For an **atomic datagram** — DF set, MF clear, offset zero — the source MAY put any value in it. 3. Every device that examines IPv4 headers **MUST ignore** the field of atomic datagrams. So a capture full of repeated or zero IDs on DF-set traffic is normal, not a bug. ## Options The header can grow past 20 bytes. Because `IHL` is 4 bits, it tops out at 15 words, 60 bytes, leaving **at most 40 bytes of options**. RFC 791 requires every IP module to implement options; what is optional is whether a given datagram carries any. ## A quick mental model - Word 1: *what am I and how big* — version, lengths, service bits. - Word 2: *how was I cut* — ID, flags, offset. - Word 3: *how far, what inside, am I intact* — TTL, protocol, checksum. - Words 4-5: *from and to*.

  • Can a middlebox use the IPv4 Identification field to spot duplicate packets?
    Not legitimately. RFC 6864 says the IPv4 ID MUST NOT be used for anything but fragmentation and reassembly, lets a source put any value in an atomic datagram's ID (DF set, MF clear, offset zero), and requires every device to ignore the ID of atomic datagrams. Sixteen bits also repeat quickly at high rates; duplicate detection has to hash the packet instead.
  • Why does an IPv4 router not need the Protocol field to forward a datagram?
    Forwarding depends only on the destination address, checked against the routing table, plus a valid header and a live TTL. `Protocol` names what the payload is, which only the endpoint parses. A router reads it when the datagram is addressed to the router itself or when a filter looks deeper — extra functions on top of forwarding, not forwarding.
  • Why does an IPv4 receiver need Total Length when the link layer already knows the frame length?
    The frame may carry more than the datagram. An Ethernet data field must be at least 46 bytes, so a small datagram is padded with zeros, and RFC 894 says that padding is not part of the IP packet and is not counted in Total Length. Total Length is the reliable end marker, and RFC 1812 requires it to be at least the header length.

saying these in an interview costs you the question

  • Every IPv4 header is exactly 20 bytes; options live in the payload.
  • A router reads the Protocol field to decide where to forward a datagram.
  • The IPv4 header carries the source and destination port numbers.
  • The IPv4 header checksum protects the payload as well as the header.
  • Identification is a unique serial number routers use to drop duplicates.
  • The IPv4 header carries proof that its source address is genuine.