IPv4 Header Format and Fragmentation (Detailed)

In IPv4, every datagram starts with a fixed-size base header (minimum 20 bytes), followed by optional fields (if present). The header contains fields such as keyword IHL and keyword fragmentation controls like the keyword MF and keyword DF bits. Understanding these fields is essential because they govern routing, integrity checking, and whether intermediate links require splitting the datagram into smaller pieces.

Key terms

• Version
• IHL
• Identification
• Fragment Offset

Footnotes

1. RFC 791 - Internet Protocol - Original specification describing fragmentation fields (Identification, Flags, Fragment Offset) and reassembly behavior. ↩

IPv4 header diagram (32-bit word view)

The base IPv4 header is 20 bytes = 5 words. Conceptually, it is easiest to draw in 32-bit blocks. The fields that vary in size (notably Options) affect the overall header length via IHL.

32-bit layout (base header; options follow if IHL > 5):

Note: The exact “Type of Service” naming historically appears as one byte; modern interpretations map it to DSCP/ECN, but the IPv4 header still carries a single TOS/TC byte in the classic layout.2

Footnotes

1. RFC 791 - IPv4 Header Format (Version, IHL, TTL, Protocol, checksum, etc.) - Defines the IPv4 header fields and their sizes/meanings, including IHL and checksum behavior. ↩

2. IANA Protocol Numbers / IPv4 header context - Background for the “Protocol” field mapping to upper-layer protocols (e.g., TCP=6, UDP=17). ↩

Field-by-field explanation (base header)

1) Version (4 bits)

Version identifies that the packet is IPv4. For IPv4, the value is 4.

2) IHL (4 bits)

IHL indicates the header length in 32-bit words. Minimum is 5 (20 bytes). If options are included, IHL increases accordingly.

3) Type of Service (8 bits)

This field provides service/priority-related marking. The historic TOS field is described in the base IPv4 header specification and is used for QoS differentiation.

4) Total Length (16 bits)

Total Length specifies the entire IPv4 packet length (header + payload) in bytes. Hosts use this to know how much data belongs to the packet.

5) Identification (16 bits)

Identification is carried by every fragment of a datagram so the receiver can group fragments belonging to the same original packet.

6) Flags (3 bits)

Flags include:

• DF (Don’t Fragment): if set, routers should not fragment; if fragmentation is necessary to forward, the router drops the packet and typically signals an error (commonly via ICMP in standard behavior).
• MF (More Fragments): indicates whether more fragments follow. MF=1 means more fragments remain; MF=0 for the last fragment.
• (The remaining flag bit is reserved/unused in classic descriptions.)

7) Fragment Offset (13 bits)

Fragment Offset gives the offset of this fragment’s payload relative to the start of the original payload, measured in 8-byte units. This is crucial for correct reassembly ordering and placement.

8) TTL (8 bits)

TTL bounds packet lifetime. Each router decrements TTL; when TTL reaches 0, the packet is discarded.

9) Protocol (8 bits)

Protocol indicates which upper-layer protocol is encapsulated (e.g., TCP=6, UDP=17). The OS uses this to deliver the payload to the correct handler.

10) Header Checksum (16 bits)

Header Checksum is computed only over the header and is used for header integrity. Because routers decrement TTL (and may update other header fields), the checksum must be recomputed at each hop.

11) Source Address (32 bits)

Source Address identifies the originator as an IPv4 address.

12) Destination Address (32 bits)

Destination Address identifies the intended destination IPv4 address.

13) Options (variable)

Options are present only when IHL indicates a length > 5. If options exist, padding may be used to align header size.

Footnotes

1. RFC 791 - IPv4 Header Format (Version, IHL, TTL, Protocol, checksum, etc.) - Defines the IPv4 header fields and their sizes/meanings, including IHL and checksum behavior. ↩ ↩² ↩³ ↩⁴ ↩⁵ ↩⁶ ↩⁷ ↩⁸ ↩⁹ ↩¹⁰

2. RFC 791 - Internet Protocol - Original specification describing fragmentation fields (Identification, Flags, Fragment Offset) and reassembly behavior. ↩ ↩² ↩³ ↩⁴

3. RFC 1191 - Path MTU Discovery - Discusses PMTUD using DF and ICMP for avoiding fragmentation when MTU is constrained. ↩

Fragmentation in IPv4 (concept, triggers, and reassembly)

Why fragmentation exists

Fragmentation exists because different network links along the path may have different maximum transmission unit (MTU) sizes. If a router must forward an IPv4 datagram over a smaller MTU than the datagram’s size, it may fragment the packet into smaller fragments so each fragment fits the outgoing link.

What happens when fragmentation occurs

When fragmentation is needed (and allowed by the DF bit), the router:

1. Splits the payload across fragments.
2. Assigns the same Identification value to each fragment.
3. Sets Fragment Offset for each fragment to reflect its location in the original payload.
4. Sets MF/DF bits consistently per IPv4 rules.
5. Adjusts the IP Total Length for each fragment.

Footnotes

1. RFC 791 - Fragmentation rationale with MTU limitations - Explains the relationship between datagram size and network constraints leading to fragmentation. ↩

2. RFC 791 - Internet Protocol - Original specification describing fragmentation fields (Identification, Flags, Fragment Offset) and reassembly behavior. ↩

Reassembly at the destination

At the receiving host, fragments are reassembled into the original datagram using:

• Identification
• Source Address
• Destination Address
• and fragment offsets to place payload pieces in order.

If fragments do not arrive completely (or arrive too late), reassembly may fail and the datagram is discarded. Fragmentation therefore introduces loss sensitivity compared to sending a non-fragmented datagram.

Footnotes

1. RFC 791 - Internet Protocol - Original specification describing fragmentation fields (Identification, Flags, Fragment Offset) and reassembly behavior. ↩

Don’t Fragment (DF) and Path MTU Discovery (PMTUD) (why fragmentation may be avoided)

Because routers may fragment packets when MTU is smaller than the datagram size, many networks rely on keyword Path MTU Discovery (PMTUD) to avoid fragmentation. With PMTUD, a sender sets DF and uses ICMP feedback when the packet would otherwise need to be fragmented.2

Footnotes

1. RFC 1191 - Path MTU Discovery - Discusses PMTUD using DF and ICMP for avoiding fragmentation when MTU is constrained. ↩

2. RFC 791 - Fragmentation rationale with MTU limitations - Explains the relationship between datagram size and network constraints leading to fragmentation. ↩