4.5 IPv4 Datagram Header Format, Flags & Fragmentation Mechanics

Back to Computer Networks Notes

📚Module 04: Network Layer: IPv4/IPv6 Addressing & SubnettingTopic 4.5⏱️18 min read

🎯High-Yield For:Semester Exams (All Universities) • Placement Technical Rounds • Engineering Foundations

💡 Core Intuition: The Oversized Moving Truck & Assembly at Destination

🍳 The Everyday Analogy: The Wide Furniture Delivery & Low Mountain Tunnels

Imagine you are moving to a new home in the mountains:

• You load a massive king-sized wooden bed into a large cross-country highway transport truck.
• On the wide 8-lane interstate highway, the entire bed travels as one complete piece.
• However, approaching the mountain pass, the truck arrives at a narrow mountain tunnel with a strict clearance limit: Maximum Clearance = 1.5 meters (The Link MTU).
• The large truck cannot physically pass through the tunnel!
• The moving crew must unpack the truck and disassemble the bed into three smaller manageable crates:
  • Each crate receives an identification tag: Shipment #8432 (so crates from other movers are never mixed up).
  • Each crate is stamped with its relative position: Crate 1 (Offset 0), Crate 2 (Offset 185), Crate 3 (Offset 370).
  • Crate 1 and Crate 2 have a sticker: More Crates Coming (MF = 1).
  • Crate 3 has a sticker: Final Crate (MF = 0).
• Intermediate toll booths do not reassemble the bed; they simply forward each crate through the tunnel.
• Only when all three crates arrive at the bedroom in your new destination home does the recipient unpack the bolts and assemble the king-sized bed back together.

💻 Bridging to Computer Science

In internetworking, Layer 3 packets are called IP Datagrams. A datagram can be up to $65,535\text{ bytes}$ long. However, physical link-layer frames (Layer 2) enforce physical hardware payload boundaries known as the Maximum Transmission Unit (MTU):

• Standard Ethernet: $\text{MTU} = 1500\text{ bytes}$
• Point-to-Point WAN / PPPoE: $\text{MTU} = 1492\text{ bytes}$

When an IP datagram's size exceeds the outgoing interface's MTU, the router splits the datagram into smaller pieces called Fragments. Each fragment travels as an independent IP packet across the network and is reassembled strictly at the final destination host.

---

📑Table of Contents

• 🔬 Field-by-Field IPv4 Datagram Header Anatomy
  • 1. Version (VER - 4 bits)
  • 2. Header Length (HLEN / IHL - 4 bits, Scaling Factor = 4)
  • 3. Type of Service / DSCP & ECN (8 bits)
  • 4. Total Length (16 bits)
  • 5. Identification (16 bits)
  • 6. Flags (3 bits)
  • 7. Fragmentation Offset (13 bits, Scaling Factor = 8)
  • 8. Time to Live (TTL - 8 bits)
  • 9. Protocol (8 bits)
  • 10. Header Checksum (16 bits)
  • 11. Source IP & Destination IP (32 bits each)
• 📊 Complete Field-by-Field Protocol Reference Matrix
• 🧩 The Mathematics of IP Fragmentation & Reassembly
  • The 4-Step Fragmentation Derivation Algorithm:
  • Why is Reassembly Performed ONLY at the Destination Host?
• 📐 Visual Blueprint: Fragmentation Pipeline Trace
• 🏭 Real-World Production Context: Path MTU Discovery (PMTUD) & The DF Bit
  • Path MTU Discovery (PMTUD - RFC 1191)
• 📐 Numerical Applications & Worked Examples
  • Example 1: Comprehensive Three-Way Fragmentation
  • Example 2: Inspecting an Incoming Fragment
  • Example 3: Decoding Raw Hexadecimal IP Header
• 🎯 Exam & Interview Pitfall Check

---

🔬 Field-by-Field IPv4 Datagram Header Anatomy

An IPv4 datagram consists of a variable-length Header ($20\text{ to }60\text{ bytes}$) followed by the transport layer Data Payload:

RFC 791 (IPv4 Standard)Total Packet: 20 to 60 Bytes (Header) • Up to 65,535 Bytes (Total Datagram)

IPv4 Datagram Header Architecture (RFC 791)

Interactive 32-bit word grid with proportional bit fields, whole-packet payload visualization, and hardware inspector

Byte 0 (Bits 0–7)Byte 1 (Bits 8–15)Byte 2 (Bits 16–23)Byte 3 (Bits 24–31)

048121620242831

Word 0Bytes 0–3

VER4b

[0–3]

HLEN / IHL4b

[4–7]

Type of Service / DSCP & ECN8b

[8–15]6b DSCP + 2b ECN

Total Length16b

[16–31]16-Bit Integer

Word 1Bytes 4–7

Identification (ID)16b

[0–15]16-Bit Sequence

Flags3b

[16–18]

Fragment Offset13b

[19–31]x8 Scaling

Word 2Bytes 8–11

Time to Live (TTL)8b

[0–7]Hop Counter

Protocol8b

[8–15]L4 Demux ID

Header Checksum16b

[16–31]1's Complement

Word 3Bytes 12–15

Source IP Address32b

[0–31]32-Bit Dotted-Decimal

Word 4Bytes 16–19

Destination IP Address32b

[0–31]32-Bit Dotted-Decimal

Word 5+Bytes 20–59

Options & Padding (Optional: Present only if HLEN > 5)32b

[0–31]0 to 40 Bytes Variable

Whole Packet Encapsulation

📦

Data Payload (Transport Layer PDU)Carries higher-layer segments: TCP Segment / UDP Datagram / ICMP / OSPF

Variable: Total Length - (HLEN * 4) [Up to 65,515 Bytes]

4 BitsBits [0–3]Pattern: 0100 (4)VER

IP Version nibble. Strictly 4 (0100) for IPv4. Packets arriving with any other version are instantly discarded.

Hardware Rule:4-bit field. Fixed at 0100_2 in all standard IPv4 traffic.

1. Version (VER - 4 bits)

Specifies the IP protocol version. For IPv4, this 4-bit nibble is strictly 0100 ($4_{10}$). If a router receives a packet where $\text{VER} \ne 4$, the packet is discarded.

2. Header Length (HLEN / IHL - 4 bits, Scaling Factor = 4)

Specifies the length of the IP header in 4-byte (32-bit) words: $\text{Header Length in Bytes} = \text{HLEN} \times 4$

• Because HLEN is 4 bits wide, its integer value ranges from $0$ to $15$ ($1111_2$).
• Since the base IPv4 header without options is $20\text{ bytes}$, the minimum valid value of HLEN is: $\text{HLEN}_{\min} = \frac{20}{4} = \mathbf{5} \quad (0101_2)$
• The maximum possible header length (with 40 bytes of options) is: $\text{HLEN}_{\max} = 15 \implies 15 \times 4 = \mathbf{60\text{ bytes}}$
• Any datagram arriving with $\text{HLEN} < 5$ is corrupt and immediately discarded.

3. Type of Service / DSCP & ECN (8 bits)

Originally defined as Type of Service (TOS) to request delay, throughput, or reliability trade-offs. Modern networks (RFC 2474 / RFC 3168) repurpose this byte into:

• Differentiated Services Code Point (DSCP - 6 bits): Quality of Service (QoS) classification (e.g. prioritizing real-time VoIP packets over background torrents).
• Explicit Congestion Notification (ECN - 2 bits): Allows intermediate routers experiencing queue buildup to mark packets (11) warning endpoints to reduce TCP window size before packets drop.

4. Total Length (16 bits)

Specifies the total length of the datagram (Header + Data Payload) in bytes: $\text{Total Length} \in [20\text{ bytes}, \ 65,535\text{ bytes}]$ $\text{Payload Size in Bytes} = \text{Total Length} - (\text{HLEN} \times 4)$

5. Identification (16 bits)

A unique 16-bit sequence number assigned by the source host. When a datagram is fragmented into multiple pieces, every single fragment carries the exact same 16-bit Identification number, enabling the destination host to group fragments together during reassembly.

6. Flags (3 bits)

Three control bits governing fragmentation behavior:

Flag Bit Position	Name & Acronym	Value = 0 Semantics	Value = 1 Semantics
Bit 0	Reserved (R)	Strictly 0 in IPv4 standard (RFC 3514 Evil Bit joke)	Invalid in standard IPv4 transit
Bit 1	Don't Fragment (DF)	Fragmentation allowed if $L > \text{MTU}$	Do NOT Fragment: Drop packet & emit ICMP Type 3, Code 4 if $L > \text{MTU}$
Bit 2	More Fragments (MF)	Last fragment of datagram, or packet never fragmented	More fragments follow; intermediate/initial piece

• Bit 0: Reserved. Must strictly be 0.
• Bit 1 - DF (Don't Fragment):
  • DF = 0: Fragmentation is permitted if required by link MTU.
  • DF = 1: Do NOT fragment this datagram. If the datagram exceeds a router's outgoing link MTU, the router drops the packet and returns an ICMP Type 3, Code 4 error message ("Destination Unreachable: Fragmentation Needed but DF Set"). This mechanism powers Path MTU Discovery (PMTUD).
• Bit 2 - MF (More Fragments):
  • MF = 1: More fragments follow. This is an intermediate or initial fragment.
  • MF = 0: No more fragments follow. This is either the very last fragment of a sequence, or an original datagram that was never fragmented at all.

7. Fragmentation Offset (13 bits, Scaling Factor = 8)

Indicates the relative position of this fragment's data payload within the original unfragmented datagram: $\mathbf{\text{Offset}} = \frac{\mathbf{\text{Byte Number of First Data Byte in this Fragment}}}{\mathbf{8}}$

⚠️ CRITICAL ARCHITECTURAL RULE:
Because the offset field is measured in units of 8-byte blocks, the amount of data carried in every fragment (except possibly the final fragment) MUST BE AN EXACT MULTIPLE OF 8 BYTES!

8. Time to Live (TTL - 8 bits)

An 8-bit counter preventing lost packets from circulating in routing loops indefinitely:

• Initialized by source OS (typically 64 in Linux, 128 in Windows, 255 in Cisco routers).
• Every router that processes the datagram decrements TTL by 1.
• When TTL == 0, the router drops the datagram and dispatches an ICMP Time Exceeded packet (Type 11, Code 0) back to the sender. This behavior is utilized by the traceroute diagnostic tool.

9. Protocol (8 bits)

Identifies the higher-layer transport protocol whose payload is encapsulated:

• 1 = ICMP (Internet Control Message Protocol)
• 2 = IGMP (Internet Group Management Protocol)
• 6 = TCP (Transmission Control Protocol)
• 17 = UDP (User Datagram Protocol)
• 89 = OSPF (Open Shortest Path First)

10. Header Checksum (16 bits)

Protects the integrity of the IP header against bit flips:

• Computed using 16-bit One's Complement Addition.
• Because every router decrements the TTL field at every hop, every router MUST recompute and rewrite the Header Checksum at every hop.

11. Source IP & Destination IP (32 bits each)

The globally unique logical IPv4 addresses of the original transmitter and final recipient.

---

📊 Complete Field-by-Field Protocol Reference Matrix

Below is the definitive reference table compiling all 12 IPv4 header fields, bit allocations, scaling factors, and common exam traps:

Header Field Name	Bit Width	Byte Position	Scaling Multiplier	Operational Purpose & Crucial Exam Traps
Version (VER)	4 bits	Byte 0 (Bits 0–3)	None	Fixed at 4 (0100). Discards non-IPv4 packets immediately.
Header Length (HLEN)	4 bits	Byte 0 (Bits 4–7)	$\\times 4$	Measured in 4-byte words. Range $[5, 15] \\implies 20\\text{ to }60\\text{ bytes}$.
DSCP / ECN	8 bits	Byte 1	None	6-bit DiffServ QoS class + 2-bit Explicit Congestion Notification (11 = congestion).
Total Length	16 bits	Bytes 2–3	None	Datagram size in bytes (Header + Payload). Max $= 65,535\\text{ B}$.
Identification (ID)	16 bits	Bytes 4–5	None	Sequence tag copied into every fragment for reassembly matching.
Flags	3 bits	Byte 6 (Bits 0–2)	None	Bit 0: Reserved (0), Bit 1: DF (Don't Fragment), Bit 2: MF (More Fragments).
Fragment Offset	13 bits	Bytes 6–7 (Bits 3–15)	$\\times 8$	Offset of fragment payload $\\div 8$. Payloads must be multiples of 8 bytes.
Time to Live (TTL)	8 bits	Byte 8	None	Decremented by 1 at every hop. Dropped at 0 $\\implies$ ICMP Time Exceeded.
Protocol	8 bits	Byte 9	None	Demux identifier: 1 (ICMP), 6 (TCP), 17 (UDP), 89 (OSPF).
Header Checksum	16 bits	Bytes 10–11	None	1's complement over header only. Must be recalculated at every router hop.
Source IP Address	32 bits	Bytes 12–15	None	Originating sender IPv4 address. Unmodified in transit (except NAT).
Destination IP Address	32 bits	Bytes 16–19	None	Target destination IPv4 address. Used for Longest Prefix Match (LPM).
Options & Padding	0–40 B	Bytes 20–59	None	Diagnostics/Security. Padded with zero-bits to maintain 32-bit word alignment.

---

🧩 The Mathematics of IP Fragmentation & Reassembly

When an incoming datagram of size $L_{\text{total}}$ arrives at a router whose next-hop interface has an MTU of $M$, and $L_{\text{total}} > M$:

Fragment Role	Header Size	Data Payload ($D$)	MF Flag	Fragment Offset Value
Original Datagram	$20\text{ B}$	Full payload $D$	0	$0$ (Unfragmented)
Fragment 1 (Initial)	$20\text{ B}$	$D_{\max} = \lfloor \frac{M - 20}{8} \rfloor \times 8$	1	0 (First byte is byte 0)
Intermediate ($i$)	$20\text{ B}$	$D_{\max}$ (Multiple of 8)	1	$\sum_{j=1}^{i-1} D_j \div 8$
Fragment $k$ (Last)	$20\text{ B}$	Remaining bytes $D_{\text{rem}} \le D_{\max}$	0	Total preceding bytes $\div 8$

The 4-Step Fragmentation Derivation Algorithm:

1. Calculate Maximum Payload Capacity per Fragment ($D_{\max}$): $D_{\text{raw}} = M - \text{Header Size} = M - 20$ Because every fragment's data payload (except the last) must be a multiple of 8 bytes: $D_{\max} = \left\lfloor \frac{M - 20}{8} \right\rfloor \times 8$
2. Determine Total Number of Fragments: $k = \left\lceil \frac{\text{Original Payload Data}}{D_{\max}} \right\rceil$
3. Compute per-Fragment Parameters:
   • For Fragment $i$ ($i = 0, 1, \dots, k - 2$):
     • Data Size: $D_{\max}$
     • Total Length: $D_{\max} + 20$
     • $\text{MF} = 1$
     • $\text{Offset} = \frac{i \times D_{\max}}{8}$
   • For Final Fragment ($i = k - 1$):
     • Data Size: Remaining residual bytes
     • Total Length: $\text{Residual} + 20$
     • $\text{MF} = 0$
     • $\text{Offset} = \frac{\text{Byte index of first remaining byte}}{8}$

Why is Reassembly Performed ONLY at the Destination Host?

1. Dynamic Multipath Routing: In a datagram network, Fragment 1 might traverse Path A while Fragment 2 traverses Path B. An intermediate router may never see all fragments!
2. Router Memory Exhaustion: If intermediate routers had to buffer and hold fragments until the entire packet arrived, a burst of traffic would exhaust router RAM, crashing the transit core.
3. Processing Overhead: Defragmenting and re-fragmenting at every hop would destroy router throughput.

---

📐 Visual Blueprint: Fragmentation Pipeline Trace

Below is an interactive flow diagram tracing the fragmentation of a 4000-byte IP datagram as it crosses an Ethernet link ($\text{MTU} = 1500\text{ bytes}$):

Architecture Flow

Step 1 of 4

End-to-End MTU Fragmentation Pipeline Trace

Decomposing a 4000-byte datagram into three 1500-byte and 1060-byte MTU-compliant fragments

📦FDDI Token Ring (MTU = 4352)

🔀Intermediate Boundary Router

⚡Ethernet LAN (MTU = 1500)

1Packet Arrival

2AEmit Frag 1

2BEmit Frag 2

2CEmit Frag 3

📦ID: 4125

Original Datagram

Total: 4000B (Data: 3980B)

🔀MTU: 1500B

Router Fragmentation Engine

MTU = 1500B (Payload Max: 1480B)

📄1500B (MF=1)

Fragment 1

Offset: 0 • 1480B Payload

📄1500B (MF=1)

Fragment 2

Offset: 185 • 1480B Payload

📄1040B (MF=0)

Fragment 3 (Last)

Offset: 370 • 1020B Payload

💡Click or hover any card or transition arrow above to inspect deep-dive operational mechanics

---

🏭 Real-World Production Context: Path MTU Discovery (PMTUD) & The DF Bit

In high-speed production systems (Netflix streaming, Google Cloud, AWS), IP fragmentation is considered an operational anti-pattern:

• If an IP datagram is split into 4 fragments, and link noise corrupts even a single bit in Fragment 3, the destination host drops the entire 4-fragment datagram.
• TCP does not know about IP fragments; TCP retransmits the entire original segment, amplifying network congestion.

📤DF = 1

1. Server Transmit

Web server sends 1500B packet with DF=1 flag set

→

🛑MTU = 1400B Exceeded

2. Bottleneck Link Encounter

Edge router egress MTU is 1400B; DF=1 forbids fragmentation

→

⚠️ICMP Unreachable

3. ICMP Packet Drop Notification

Router discards packet and returns ICMP Type 3, Code 4 ('Frag Needed, MTU=1400')

→

⚡Zero-Fragmentation Path

4. Dynamic TCP MSS Tuning

Server detects path MTU = 1400B and locks TCP MSS to 1360B (1400 - 40B headers)

Path MTU Discovery (PMTUD - RFC 1191)

To eliminate fragmentation entirely, modern operating systems use Path MTU Discovery:

1. The server transmits all packets with the DF (Don't Fragment) bit set to 1.
2. If an intermediate router has an MTU smaller than the packet size, it is forbidden from fragmenting. It drops the packet and transmits an ICMP Type 3 Code 4 message back to the server indicating the next-hop MTU.
3. The server inspects the ICMP notification and dynamically reduces its TCP Maximum Segment Size (MSS) to match the bottleneck link.
4. From that moment forward, every packet travels across the entire Internet without a single fragment!

---

📐 Numerical Applications & Worked Examples

Example 1: Comprehensive Three-Way Fragmentation

Problem Statement: An IPv4 datagram of size $4500\text{ bytes}$ arrives at a router. The datagram includes a $20\text{ byte}$ header and $4480\text{ bytes}$ of data payload. The router must forward this packet over a link with $\text{MTU} = 1500\text{ bytes}$. Determine for each fragment:

1. Total Length
2. Data Payload Size
3. Value of the MF flag
4. Value of the Fragmentation Offset

Step-by-Step Solution:

1. Determine Maximum Data per Fragment ($D_{\max}$):

   • $\text{MTU} = 1500\text{ bytes}$.
   • Available for payload: $1500 - 20 = 1480\text{ bytes}$.
   • Check divisibility by 8: $\frac{1480}{8} = 185 \quad (\text{Exact integer! Multiple of 8})$
   • Thus, $D_{\max} = 1480\text{ bytes}$.

2. Calculate Number of Fragments: $\text{Total Data} = 4480\text{ bytes}$ $\text{Number of Fragments} = \left\lceil \frac{4480}{1480} \right\rceil = \lceil 3.027 \rceil = \mathbf{4\text{ fragments}}$

   • Fragment 1 Data: $1480\text{ bytes}$ (Bytes $0$ to $1479$)
   • Fragment 2 Data: $1480\text{ bytes}$ (Bytes $1480$ to $2959$)
   • Fragment 3 Data: $1480\text{ bytes}$ (Bytes $2960$ to $4439$)
   • Fragment 4 Data: $4480 - (3 \times 1480) = 4480 - 4440 = \mathbf{40\text{ bytes}}$ (Bytes $4440$ to $4479$)

3. Tabulate Fragment Parameters:

Fragment Number	Data Bytes	Data Size	Header Size	Total Length	MF Bit	Starting Byte	Offset ($\text{Byte} / 8$)
Fragment 1	$0 - 1479$	$1480\text{ B}$	$20\text{ B}$	$1500\text{ B}$	1	0	$0 / 8 = \mathbf{0}$
Fragment 2	$1480 - 2959$	$1480\text{ B}$	$20\text{ B}$	$1500\text{ B}$	1	1480	$1480 / 8 = \mathbf{185}$
Fragment 3	$2960 - 4439$	$1480\text{ B}$	$20\text{ B}$	$1500\text{ B}$	1	2960	$2960 / 8 = \mathbf{370}$
Fragment 4	$4440 - 4479$	$40\text{ B}$	$20\text{ B}$	$60\text{ B}$	0	4440	$4440 / 8 = \mathbf{555}$

---

Example 2: Inspecting an Incoming Fragment

Problem Statement: An IPv4 packet arrives at a destination host with the following header fields:

• HLEN = 5
• Total Length = 400
• MF = 0
• Fragmentation Offset = 100

Answer the following questions:

1. Is this a fragment, or an unfragmented datagram?
2. If it is a fragment, is it the first, middle, or last fragment?
3. What is the byte number of the first and last byte of data carried in this packet?

Step-by-Step Solution:

1. Analyze Offset and MF:

   • $\text{Offset} = 100 \ne 0 \implies$ Data is shifted from the start. Therefore, it is definitely a fragment.
   • $\text{MF} = 0 \implies$ No more fragments follow.
   • Because $\text{Offset} > 0$ and $\text{MF} = 0$, this is strictly the LAST fragment.

2. Calculate Data Payload Size:

   • Header size $= \text{HLEN} \times 4 = 5 \times 4 = 20\text{ bytes}$.
   • $\text{Data Size} = \text{Total Length} - 20 = 400 - 20 = \mathbf{380\text{ bytes}}$.

3. Determine Data Byte Range:

   • First byte number $= \text{Offset} \times 8 = 100 \times 8 = \mathbf{800}$.
   • Last byte number $= \text{First Byte} + \text{Data Size} - 1 = 800 + 380 - 1 = \mathbf{1179}$.
   • The packet carries user payload bytes from 800 through 1179.

---

Example 3: Decoding Raw Hexadecimal IP Header

Problem Statement: An IPv4 packet arrives with the following hexadecimal string representing its first 20 bytes: 45 00 00 3C 1C 46 40 00 40 06 B1 E6 C0 A8 01 0A C0 A8 01 01

Extract and interpret the following fields:

1. IP Version and Header Length in bytes
2. Total Length of the datagram
3. DF and MF Flags
4. Time to Live (TTL)
5. Transport Layer Protocol

Step-by-Step Solution:

1. Byte 1: 45
   • High nibble 4 $\implies \mathbf{\text{Version 4}}$.
   • Low nibble 5 $\implies \text{HLEN} = 5 \implies 5 \times 4 = \mathbf{20\text{ bytes header}}$.
2. Bytes 3-4: 00 3C (Total Length)
   • Hex $003C_{16} = 3 \times 16 + 12 = \mathbf{60\text{ bytes}}$.
   • Payload $= 60 - 20 = 40\text{ bytes}$.
3. Byte 7: 40 (Flags and High Offset Bits)
   • Hex 40 in binary = 0100 0000.
   • Bit 0 = 0 (Reserved).
   • Bit 1 = 1 $\implies \mathbf{DF = 1}$ (Don't Fragment is set!).
   • Bit 2 = 0 $\implies \mathbf{MF = 0}$ (No more fragments).
4. Byte 9: 40 (Time to Live)
   • Hex 40 $= 4 \times 16 = \mathbf{64\text{ hops}}$.
5. Byte 10: 06 (Protocol)
   • Value is $6 \implies \mathbf{\text{TCP Protocol}}$ (Carrying a TCP SYN packet).

---

🎯 Exam & Interview Pitfall Check

Core Conceptual Questions

• Why is the Fragmentation Offset scaled by 8, while HLEN is scaled by 4?

  • HLEN (4 bits) must represent header sizes from $20\text{ to }60\text{ bytes}$. Multiplying by 4 allows a 4-bit field ($0 - 15$) to span up to $15 \times 4 = 60\text{ bytes}$.
  • Fragmentation Offset (13 bits) must be able to represent byte positions in a datagram up to $65,535\text{ bytes}$. A 13-bit number can only count up to $2^{13} - 1 = 8191$. Multiplying by 8 allows $8191 \times 8 = 65,528\text{ bytes}$, cleanly covering the entire 65,535-byte IPv4 address space!

• What happens if an IP fragment is lost during transmission across the Internet?
  Because reassembly happens exclusively at the destination, the destination's IP layer starts a reassembly timer upon receiving the first fragment. If the timer expires before all fragments arrive, the destination drops all received fragments of that datagram and sends an ICMP Time Exceeded (Type 11, Code 1: Fragment Reassembly Time Exceeded) back to the source. The sender's transport layer (TCP) must retransmit the entire segment.

Common Interview Traps

• Trap: Believing intermediate routers can reassemble fragments if the next link has a larger MTU.
  Debunked: Routers never reassemble fragments. Even if a packet is fragmented to cross a 576-byte MTU link and subsequently enters a 9000-byte Jumbo Frame link, the fragments remain separate packets until they reach the final destination host.

• Trap: Forgetting that the last fragment has MF = 0.
  Debunked: If $\text{MF} = 0$, that does NOT mean the packet was never fragmented! If $\text{Offset} > 0$ and $\text{MF} = 0$, it is the last fragment of a fragmented sequence. Only when $\text{Offset} = 0$ AND $\text{MF} = 0$ is the datagram completely unfragmented.

---

🗺️View Complete Computer Networks Roadmap & Syllabus

← Previous Topic4.4 Variable Length Subnet Masking (VLSM) & Route AggregationNext Topic →4.6 Network Address Translation (NAT) & IPv6 Header Architecture