IPv4 DF Flag (Don't Fragment)
What it is (Definition)
The DF (Don't Fragment) flag is part of the IPv4 fragmentation control fields. When DF is set, it tells routers: do not fragment this packet. If a router needs to send the packet out of an interface with a smaller MTU and the packet is too large, the router must drop the packet and (typically) send an ICMP error back to the sender indicating that fragmentation would be required.
DF is central to modern networking because it enables Path MTU Discovery (PMTUD). Endpoints can send DF-marked packets and adjust their packet size based on ICMP feedback, rather than relying on routers to fragment packets in the middle of the network.
Where it appears in the stack
DF is an IPv4 (Layer 3) field. It matters most when the packet size approaches the effective MTU on some link along the path (including tunnels, VPNs, and encapsulation). It is often invisible in “small packet” traffic but becomes critical for larger transfers and certain protocols.
How DF affects behavior
- Sender transmits a packet with DF set.
- If all links can carry it, the packet forwards normally.
- If a link cannot carry it, the router cannot fragment it and drops it.
- Router may send ICMP “Fragmentation needed” (or similar) back to the sender.
- Sender reduces packet size (or adjusts MSS) and retries with a smaller size.
The most common operational failure is when ICMP feedback is filtered: the sender never learns the proper MTU, so larger packets fail silently while smaller ones work.
Common values (Value table)
| DF value | Meaning | Typical scenarios | Notes |
|---|---|---|---|
| DF = 1 | Do not fragment | PMTUD-enabled traffic, many TCP flows | Packet too large → drop + ICMP needed (if allowed) |
| DF = 0 | Fragmentation allowed | Legacy behaviors, some special traffic | Routers may fragment (fragmentation has downsides) |
| DF = 1 + no ICMP | Blackhole risk | VPN/tunnels, strict firewalls | Large packets fail; symptom looks like “random stalls” |
| DF toggles by size | Mixed behavior | Apps with variable payload sizes | Small requests succeed, large responses fail |
How it looks in Wireshark
Display filter example:
ip.flags.df == 1What you typically see:
- IPv4 header flags showing DF set (and fragment offset typically 0 for non-fragments).
- ICMP “fragmentation needed” style messages when a path MTU mismatch exists.
- Tunnel-related traffic where outer headers have different MTU constraints than inner flows.
Quick read tip: If small transactions work but large ones stall, check whether DF is set and whether ICMP feedback is visible. Absence of ICMP does not prove “no problem” — it can be part of the problem.
Common troubleshooting patterns
“Small works, large fails” across a VPN or tunnel
Encapsulation reduces effective MTU. If endpoints send packets sized for a normal Ethernet MTU and DF is set, a smaller tunnel MTU can cause drops. If ICMP is filtered, the failure often appears as retries/timeouts in TCP, while UDP-based apps may just look “unreliable.”
Fragmentation exists, but performance is poor
Allowing fragmentation can mask MTU problems but introduce reassembly overhead and higher loss sensitivity (losing one fragment loses the whole packet). Modern practice usually prefers PMTUD with DF, plus correct MSS/MTU tuning.
Related pages (internal links)
- Back to Fields Index
- Dictionary: IPv4 overview
- Topics Index (Path MTU discovery — Soon)
- Dictionary Index