Within the IPv4 header, three bits wield enormous influence over packet handling. These Flags bits—comprising Reserved, Don't Fragment (DF), and More Fragments (MF)—determine whether routers can break packets into pieces, whether Path MTU Discovery works, and how destination hosts know they've received all fragments.\n\nThough tiny in size (just 3 bits out of the 160-bit minimum IPv4 header), these flags are referenced in almost every packet processing decision in the modern Internet. Understanding them deeply is essential for network engineering, troubleshooting, and security analysis.

The Flags field occupies 3 bits in the IPv4 header, immediately preceding the 13-bit Fragment Offset. Together, these 16 bits form the second half of the third 32-bit word in the header.

Binary representation examples:\n\n| Flags Value | Binary | Meaning |\n|-------------|--------|---------|\n| 0x0 | 000 | Normal packet, may be fragmented, this is complete datagram |\n| 0x1 | 001 | Reserved bit set (unusual, may indicate error) |\n| 0x2 | 010 | DF set - do not fragment |\n| 0x3 | 011 | Reserved + DF (unusual) |\n| 0x4 | 100 | More fragments follow (this is a fragment, not the last) |\n| 0x6 | 110 | DF + MF - Don't fragment AND more fragments (unusual combination) |

The Don't Fragment (DF) flag is the most strategically important of the three bits. When set to 1, it instructs routers: "If this packet is too large for the next hop, do not fragment it—instead, drop it and send an ICMP error."

Why use DF flag?\n\n1. Enable Path MTU Discovery — Setting DF forces ICMP feedback when packets are too large, allowing the source to discover the optimal packet size.\n\n2. Avoid fragmentation overhead — Fragmentation adds headers, increases loss probability, and consumes router resources. DF prevents this.\n\n3. Ensure atomic delivery — Some applications require packets to arrive whole or not at all. DF guarantees no silent fragmentation.\n\n4. Security considerations — Fragmented packets can evade firewalls. DF ensures packets are inspected as complete units.\n\nDefault behavior:\n\nModern operating systems set DF=1 by default for TCP traffic (to enable PMTUD). UDP and ICMP typically have DF=0 unless explicitly set by the application.

The More Fragments (MF) flag signals whether additional fragments follow the current one. It's the mechanism that identifies the end of a fragment sequence.

How destination uses MF flag:\n\nThe receiving host uses MF to determine when reassembly is complete:\n\n1. First fragment arrives (Offset=0, MF=1):\n - Create reassembly buffer\n - Store fragment's data starting at position 0\n - Note: more fragments expected\n\n2. Middle fragments arrive (Offset>0, MF=1):\n - Add to reassembly buffer at offset × 8 position\n - More fragments still expected\n\n3. Last fragment arrives (Offset>0, MF=0):\n - Add to reassembly buffer\n - Calculate total size: offset × 8 + data_length\n - Mark reassembly as having received final fragment\n\n4. Check for completion:\n - If all bytes from 0 to total_size are present → reassemble\n - If gaps remain → wait (or timeout and discard)

Understanding all valid and invalid flag combinations helps in packet analysis and security assessment.

Analyzing suspicious combinations:\n\nDF=1 with Offset>0 or MF=1:\nThis combination means "this is a fragment, but don't fragment me." It's logically inconsistent—if DF was set when fragmentation occurred, fragmentation should have been blocked. This may indicate:\n- Packet crafting/attack tools\n- Implementation bugs\n- Tunnels that strip/add headers incorrectly\n\nReserved bit = 1:\nShould never be set in normal traffic. May indicate:\n- Network testing tools\n- Malformed packets\n- Rare experimental usage\n- The source is jokingly referencing RFC 3514's "Evil Bit"

The DF flag is the cornerstone of Path MTU Discovery (PMTUD), the mechanism by which hosts learn the optimal packet size for a given path without trial and error.

TCP MSS adjustment:\n\nWhen PMTUD discovers a smaller path MTU:\n\n1. Route cache updated: "Path to 10.0.0.50 has MTU 1400"\n2. For new TCP segments: MSS = 1400 - 40 = 1360 bytes\n3. Existing connections may retransmit in-flight data at new size\n4. Application sees no change—TCP handles transparently

The DF and MF flags have significant implications for firewall and security device operation. Understanding these is critical for security engineering.

Modern firewall approaches:\n\n1. Virtual reassembly: Firewall tracks fragment state and logically reassembles for inspection without actually storing complete datagrams (memory efficient).\n\n2. First-fragment minimum size: Require first fragment to contain complete transport header (20+ bytes of data beyond IP header). Drop tiny first fragments.\n\n3. Drop all fragments: At network perimeter, simply block all fragmented traffic. Legitimate modern traffic should use PMTUD with DF=1 and not fragment.\n\n4. Fragment rate limiting: Allow limited fragment rate to prevent DoS while permitting legitimate (rare) fragmented traffic.

Let's work through realistic scenarios showing how to interpret flags in packet captures.

The three bits of the Flags field—small in size but enormous in impact—govern critical packet handling decisions across the Internet. Let's consolidate the essential knowledge:

What's Next:\n\nWe've covered how packets are marked for fragmentation. The final piece is understanding Reassembly—how the destination host collects fragments, validates their integrity, handles errors, and reconstructs the original datagram. This completes our comprehensive examination of IP fragmentation.