An IP Fragmentation attack is a network-layer Denial-of-Service or evasion technique that abuses the IP protocol’s packet fragmentation and reassembly mechanism — manipulating fragment offsets, sizes, or sequencing — to crash vulnerable systems, bypass security inspection, or exhaust the memory and CPU a target reserves for reassembling fragmented packets.
TL;DR: IP allows large packets to be split into fragments when they exceed a network’s Maximum Transmission Unit (MTU), and the receiving host must buffer and reassemble those fragments using the offset and More Fragments fields in the IP header. Attackers exploit this by sending malformed, overlapping, or deliberately tiny fragments that either crash naive reassembly code (the classic Teardrop attack), slip malicious payloads past firewalls that inspect only the first fragment, or flood a target with incomplete fragment sets that consume reassembly buffer memory until it exhausts. Mitigation requires strict fragment validation, minimum fragment size enforcement, reassembly timeout and memory limits, and — where the network permits it — dropping fragmented traffic entirely for protocols that don’t require it.
Last updated: 2026-08-27
IP fragmentation attacks are among the oldest documented network exploits. The original Teardrop attack, which crashed Windows 95, NT, and various Linux kernels through the mid-to-late 1990s by sending overlapping fragments that corrupted reassembly buffers, is documented in a 1997 CERT advisory (CA-1997-28) and drove much of the early hardening work in operating system network stacks. Modern kernels are largely immune to the original crash-inducing bugs, but fragmentation abuse persists today in a different form: firewall/IDS evasion and reassembly-resource exhaustion, both of which remain practical concerns for internet-facing infrastructure.
The IP Header Fields That Make Fragmentation Possible
Fragmentation is controlled entirely by three fields in the IPv4 header, defined in RFC 791:
IPv4 Header (relevant fields, 32-bit words):
0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+|Version| IHL |Type of Service| Total Length |+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+| Identification |Flags| Fragment Offset |+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+| Time to Live | Protocol | Header Checksum |+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+| Source Address |+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+| Destination Address |+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Identification: 16 bits — same value across all fragments of one original datagramFlags: 3 bits — bit 1 = Don't Fragment (DF), bit 2 = More Fragments (MF)Fragment Offset: 13 bits — offset of this fragment's data, in units of 8 bytes, from the start of the original unfragmented datagramHow reassembly uses these fields: when a packet exceeds the outgoing link’s MTU, a router or the sending host splits it into fragments. Every fragment carries the same Identification value so the receiver knows which fragments belong together. Each fragment (except the last) sets the More Fragments (MF) flag to 1; the last fragment sets MF to 0. The Fragment Offset, measured in 8-byte units, tells the receiver where in the original datagram this fragment’s payload belongs. The receiving host buffers fragments as they arrive, indexed by source/destination address, protocol, and Identification, and reassembles the full datagram once it has a contiguous run of bytes from offset 0 through the fragment with MF=0.
Original datagram (3,000 bytes of payload) fragmented for a 1,500-byte MTU path:
Fragment 1: Identification=X, MF=1, Offset=0 (bytes 0-1479 of payload)Fragment 2: Identification=X, MF=1, Offset=185 (offset unit = 8 bytes; 185*8=1480)Fragment 3: Identification=X, MF=0, Offset=370 (370*8=2960; final fragment, MF=0)
Receiver buffers all three under Identification=X, verifies no gaps,reassembles into the original 3,000-byte datagram, then hands it tothe transport layer (TCP/UDP/ICMP) for further processing.How IP Fragmentation Attacks Work
Because the receiver trusts the offset and MF values a sender provides, nothing in the base IP specification prevents a sender from providing offsets that overlap, gaps that never close, or fragments so small they carry almost no useful data. Three distinct attack patterns emerge from this trust:
1. Overlapping fragments (Teardrop-style). The attacker crafts a sequence of fragments whose offsets overlap — for example, a second fragment whose offset places its data partially inside the range already claimed by the first fragment.
Teardrop-style overlap:
Fragment A: Identification=X, MF=1, Offset=0 (claims bytes 0-1479)Fragment B: Identification=X, MF=0, Offset=100 (claims bytes 800-1579 — overlaps A at 800-1479)
Naive reassembly code (mid-1990s OS network stacks): computes buffer copy length as (Fragment B end - Fragment B start) using unsigned arithmetic that underflows when the overlap produces a negative length, writing outside the allocated buffer
Result: kernel panic or crash on vulnerable, unpatched systemsModern operating systems validate fragment boundaries and reject or safely discard overlapping fragments, so the original crash-inducing Teardrop bug is not a practical risk against current kernels. The technique persists conceptually as a way to test reassembly robustness and, in some IDS/firewall evasion scenarios, to make a sequence of fragments reassemble differently at an inspection device than at the final host — letting a first, benign-looking fragment pass inspection while a later, overlapping fragment silently overwrites the inspected portion.
2. Tiny fragment attacks. The attacker deliberately fragments a packet — often at the very start of a TCP segment — into fragments so small that the first fragment does not contain enough of the TCP header (source port, destination port, flags) for a firewall or filtering device to make an accurate decision.
Normal TCP/IP packet (SYN, dest port 22, i.e., SSH):[IP header][TCP header: src port, dst port=22, flags=SYN][data]
Tiny fragment attack:Fragment 1: [IP header][first 8 bytes of TCP header — src port only, no flags/dst port visible]Fragment 2: [IP header][remaining TCP header incl. dst port=22, flags=SYN][data]
A firewall rule matching "dst port 22, SYN flag" may fail to match Fragment 1(incomplete header) and may not correctly hold and re-inspect afterreassembly — depending on implementation, this can allow the fragmentedpacket to reach a service the firewall intended to block.RFC 1858 and its follow-up RFC 3128 document this exact evasion pattern and specify filtering rules — reject any fragment whose offset is 1 (indicating a fragment starting at byte 8, too small to contain a full TCP header) — that firewalls should implement to close the gap.
3. Fragment reassembly exhaustion (fragment flood). Rather than trying to evade inspection or crash the target, the attacker simply sends large volumes of fragments that never complete a valid datagram — for example, fragments with MF=1 that are never followed by a corresponding final fragment (MF=0) for that Identification value. Every incomplete fragment set consumes memory in the target’s reassembly buffer until the reassembly timeout expires (commonly 30–60 seconds, per RFC 791 recommendations and OS-specific defaults). At sufficient volume, new legitimate fragmented traffic cannot be buffered, and the reassembly queue itself becomes a resource-exhaustion target — similar in spirit to how a SYN Flood exhausts the TCP connection table, but at the IP layer instead of the transport layer.
Fragment flood:
Bot 1 ──Fragment (MF=1, Offset=0, ID=1001)──▶ Target [buffered, waiting for more]Bot 2 ──Fragment (MF=1, Offset=0, ID=1002)──▶ Target [buffered, waiting for more]Bot 3 ──Fragment (MF=1, Offset=0, ID=1003)──▶ Target [buffered, waiting for more]... [millions of incomplete fragment sets, no closing MF=0 fragment ever sent]
Result: reassembly buffer memory fills with incomplete fragment sets held until timeout; legitimate fragmented packets cannot be buffered; CPU spent managing the reassembly queueIP Fragmentation Attack Variants Compared
| Variant | Mechanism | Primary Target Resource | Modern Risk Level |
|---|---|---|---|
| Overlapping fragments (Teardrop-style) | Conflicting offsets corrupt reassembly logic or create inspection/reassembly mismatch | Kernel stability (historically); inspection consistency (today) | Low for crashes on patched systems; still relevant for evasion testing |
| Tiny fragment attack | First fragment too small to carry full L4 header, evading stateless filters | Firewall/IDS policy accuracy | Medium — depends on whether filtering devices implement RFC 1858/3128 rules |
| Fragment reassembly exhaustion (flood) | High volume of incomplete fragment sets held until timeout | Reassembly buffer memory, CPU | Medium-high — still an effective volumetric/state-exhaustion vector |
| Fragmented UDP/ICMP flood (cross-reference) | Oversized UDP/ICMP payloads forced into fragments to add reassembly cost to a volumetric flood | Bandwidth + reassembly memory | Medium — combines with UDP Flood or ICMP Flood |
IP Fragmentation vs. TCP Fragmentation — Critical Distinction
These two topics are frequently confused because both involve “breaking data into pieces,” but they operate at different layers with entirely different mechanisms:
| Aspect | IP Fragmentation | TCP Fragmentation (Segmentation) |
|---|---|---|
| OSI layer | Network (Layer 3) | Transport (Layer 4) |
| Who splits the data | Any router or host along the path, when a datagram exceeds link MTU | The sending TCP stack, based on the negotiated Maximum Segment Size (MSS) |
| Unit being split | A single IP datagram (which may itself contain a full TCP segment) | The TCP byte stream, into segments before IP even sees them |
| Reassembly performed by | The final destination IP stack (fragments are transparent to TCP) | The final destination TCP stack (segments are reordered/reassembled using sequence numbers, not IP fragment offsets) |
| Attack surface abused | Fragment offset, MF flag, Identification field, reassembly buffer | MSS negotiation, segment ordering, retransmission timers, segmentation-boundary evasion |
| Typical exploit goal | Crash reassembly code, evade stateless packet filters, exhaust reassembly memory | Evade deep packet inspection at TCP segment boundaries, force inefficient tiny-segment processing, exhaust reordering buffers |
In short: IP fragmentation happens below TCP/UDP and is invisible to the transport layer — a single TCP segment can be split into several IP fragments without TCP ever knowing. TCP fragmentation (more precisely called segmentation) happens within TCP itself, splitting the application’s byte stream into segments governed by MSS, independent of whether IP later also fragments those segments. An attack can exploit one without touching the other, and sophisticated evasion techniques sometimes combine both — see the dedicated TCP Fragmentation article for the segmentation-specific mechanics.
Detection Signals and Telemetry
# Kernel-level IP fragmentation and reassembly countersnstat -az | grep -iE "frag|reasm"# Key counters: IpReasmReqds (reassembly attempts), IpReasmFails (failed reassemblies),# IpReasmOKs (successful), IpFragCreates (fragments created on send)
# Current reassembly queue memory limits (Linux)sysctl net.ipv4.ipfrag_high_threshsysctl net.ipv4.ipfrag_low_threshsysctl net.ipv4.ipfrag_time
# Live capture of fragmented traffic onlytcpdump -i eth0 'ip[6:2] & 0x3fff != 0' -c 200# This BPF filter matches packets where either the MF flag or a nonzero# fragment offset is set — i.e., any fragment that isn't a complete,# unfragmented datagram
# Count fragments by source to spot flood sourcestcpdump -i eth0 'ip[6:2] & 0x3fff != 0' -c 5000 -n | awk '{print $3}' | sort | uniq -c | sort -rn | head
# nftables counter for fragment-matching rulenft add rule inet filter input ip frag-off != 0 counter| Indicator | Normal | Under IP Fragmentation Attack | Tool |
|---|---|---|---|
IpReasmReqds growth rate | Low, matches expected fragmented traffic (VPNs, jumbo-to-standard MTU transitions) | Sharp, sustained spike | nstat -az |
IpReasmFails | Near zero | High and rising — many fragment sets never complete | nstat -az |
| Fragment volume by source IP | Diverse, low per-source rate | Concentrated bursts or high diversity of spoofed, one-time sources | NetFlow, tcpdump |
| Fragments with implausibly small offset/size (tiny fragment pattern) | Rare | Recurring pattern of offset=1 or minimal-size first fragments | Packet capture, IDS signature |
| Reassembly memory usage | Stable, well below ipfrag_high_thresh | Approaching or hitting high threshold, triggering forced queue eviction | /proc/net/sockstat, kernel logs |
| Overlapping offset patterns across fragments sharing an Identification | None | Present — indicates crafted overlap attempt | Packet capture / IDS |
Mitigation Techniques
| Technique | How It Works | Effectiveness |
|---|---|---|
| Minimum fragment size enforcement (RFC 1858 / RFC 3128) | Reject any fragment with offset=1 (too small to contain a full L4 header) | High against tiny fragment evasion |
| Overlap rejection | Discard fragments whose offset/length overlaps a previously received fragment for the same Identification | High against Teardrop-style and evasion-via-overlap attempts |
| Reassembly timeout tuning | Lower the time an incomplete fragment set is held before being discarded, freeing memory faster under load | Medium — reduces exposure window without eliminating flood capacity |
| Reassembly memory/queue limits | Cap total memory or fragment-set count the kernel will buffer (ipfrag_high_thresh/ipfrag_low_thresh) | Medium-high — bounds worst-case memory exhaustion |
| Default-deny fragmented traffic for protocols that don’t need it | Drop fragments for services where legitimate traffic is never expected to fragment (e.g., short DNS/UDP responses) | High for specific, well-understood traffic profiles |
| Stateful firewall fragment reassembly before filtering | Firewall reassembles fragments itself before applying L4 rules, closing the tiny-fragment inspection gap | High — but adds firewall-side memory/CPU cost, which must itself be capacity-planned |
| BCP38 / uRPF ingress filtering (RFC 2827) | Reduces spoofed-source fragment floods at the network edge | Medium — helps with flood variant, irrelevant to evasion variants |
| Upstream scrubbing / edge filtering | Provider-side inspection and fragment validation before traffic reaches the origin | High for large-volume fragment floods |
Common Mistakes
| Mistake | Impact | Correct Solution |
|---|---|---|
| Firewall filters only the first fragment of a sequence | Tiny fragment or later fragments can carry the actual malicious/blocked content past the filter | Reassemble before filtering, or apply RFC 1858/3128 minimum-offset rejection rules |
| Blocking all fragmented traffic indiscriminately | Breaks legitimate large UDP responses (DNSSEC, some VPN/tunneling protocols) and PMTUD-dependent flows | Apply protocol-aware policies; drop fragments only for traffic classes that shouldn’t legitimately fragment |
| Assuming modern OS kernels are immune to all fragmentation attacks | Reassembly-exhaustion floods and evasion techniques remain effective even though the original Teardrop crash bugs are patched | Treat fragment flood and evasion as ongoing capacity/policy concerns, not solved historical issues |
| Setting reassembly memory limits too high | Attacker-controlled incomplete fragment sets can consume large amounts of kernel memory before limits trigger | Tune ipfrag_high_thresh/ipfrag_low_thresh conservatively for expected legitimate fragmentation volume |
No monitoring of IpReasmFails | Ongoing fragment flood or evasion attempts go unnoticed until downstream impact appears | Alert on sustained increases in reassembly failures relative to baseline |
| Confusing IP fragmentation issues with TCP segmentation issues during incident response | Misdiagnosis leads to applying the wrong mitigation layer (e.g., tuning MSS when the real issue is fragment offset abuse) | Confirm at which layer the anomaly occurs using packet capture before selecting a mitigation |
How to Implement on Azion
Azion’s distributed network can help absorb and filter anomalous IP fragmentation traffic before it reaches your origin, depending on the products enabled and how they are configured:
- DDoS Protection provides always-on detection and mitigation for volumetric and protocol-level anomalies, including abnormal fragmentation patterns, at the network edge.
- Network Shield can apply network-level rules to validate fragment structure and drop malformed or evasive fragmentation patterns before they reach application infrastructure.
- Firewall enables custom rules to filter fragmented traffic by protocol, source pattern, or fragment characteristics specific to your environment.
- WAAP combines network- and application-layer controls when fragmentation-based evasion is paired with application-layer attack attempts.
Because Azion terminates and inspects traffic at the edge before it reaches your origin, fragment reassembly for inbound requests can happen at Azion’s infrastructure rather than exposing your origin’s reassembly buffers directly to attacker-controlled fragment sequences — though the specific behavior depends on your configured products and traffic profile.
Related Resources
- What Is a DDoS Attack?
- DDoS Attack Types
- What Is DDoS Protection and Mitigation?
- What Is a TCP Fragmentation Attack?
- What Is a UDP Flood Attack?
- Azion DDoS Protection
- Azion Network Shield
Frequently Asked Questions
What is an IP fragmentation attack? An IP fragmentation attack abuses the IP protocol’s fragmentation and reassembly mechanism — the fragment offset, Identification, and More Fragments fields defined in RFC 791 — to crash vulnerable reassembly code, evade firewalls that inspect only the first fragment, or exhaust the memory a target reserves for buffering incomplete fragment sets. It operates at the network layer, below TCP and UDP.
What is the Teardrop attack and is it still a threat? Teardrop is a 1990s-era IP fragmentation attack that sends fragments with deliberately overlapping offsets, corrupting the buffer-length calculations in vulnerable reassembly code and crashing the target operating system. Modern kernels validate fragment boundaries and are not vulnerable to the original crash bug, but the overlapping-fragment technique remains relevant for firewall/IDS evasion testing.
What is a tiny fragment attack? A tiny fragment attack splits a packet so that the first fragment is too small to contain a complete transport-layer header — for example, missing the destination port or TCP flags — which can cause a stateless firewall to fail to correctly evaluate and block the packet. RFC 1858 and RFC 3128 define filtering rules, such as rejecting fragments with offset=1, specifically to close this evasion gap.
How does a fragment reassembly exhaustion attack work? An attacker sends a high volume of fragments that never complete a valid datagram — for example, always setting the More Fragments flag without ever sending the final fragment for a given Identification value. Each incomplete set consumes reassembly buffer memory until a timeout expires, and at sufficient volume this exhausts memory or CPU dedicated to fragment reassembly, denying service to legitimate fragmented traffic.
What is the difference between IP fragmentation and TCP fragmentation? IP fragmentation happens at the network layer when a datagram exceeds a link’s MTU, and it’s invisible to TCP — a single TCP segment can be split into multiple IP fragments without TCP knowing. TCP fragmentation, more accurately called segmentation, happens within the TCP layer itself, splitting the application’s byte stream into segments based on the negotiated Maximum Segment Size, entirely independent of whether IP later fragments those segments further.
Can firewalls fully defend against fragmentation attacks by inspecting each fragment individually? No. Inspecting fragments individually is precisely the weakness that tiny fragment and overlapping fragment attacks exploit, since no single fragment may contain enough information to make a correct decision. Effective defense requires the firewall to reassemble fragments (or track fragment state) before applying transport-layer filtering rules.
Why can’t I just block all fragmented IP traffic? Some legitimate traffic legitimately fragments — large DNSSEC responses over UDP, certain VPN and tunneling protocols, and any UDP traffic exceeding the path MTU. Blocking all fragments indiscriminately breaks these use cases. A better approach is to apply protocol-aware policies that drop fragmentation only for traffic classes where it isn’t expected.
What Linux kernel parameters control IP reassembly behavior? net.ipv4.ipfrag_high_thresh and net.ipv4.ipfrag_low_thresh control the memory thresholds at which the kernel starts and stops evicting incomplete fragment sets, and net.ipv4.ipfrag_time controls how long an incomplete set is held before timing out. Tuning these conservatively limits how much memory a fragment flood can consume before the kernel starts discarding old, incomplete fragment sets.
How do I detect an IP fragmentation attack in progress? Monitor kernel counters such as IpReasmReqds and IpReasmFails via nstat -az for sustained spikes and rising failure rates, and use a targeted tcpdump BPF filter (ip[6:2] & 0x3fff != 0) to isolate fragmented traffic for closer inspection. A high ratio of reassembly attempts to successful reassemblies, combined with high source IP diversity, is a strong indicator of an active flood or evasion attempt.
Does IPv6 have the same fragmentation vulnerabilities as IPv4? IPv6 moves fragmentation information into a separate Fragment extension header rather than the base header, and routers along the path are no longer permitted to fragment packets — only the originating host can, using Path MTU Discovery. This reduces some IPv4-style intermediate-fragmentation attack surface, but IPv6 hosts must still defend against reassembly-exhaustion floods and extension-header-based evasion techniques targeting the same underlying reassembly logic.
Sources
- IETF. “Internet Protocol.” RFC 791. 1981.
- IETF. “Security Considerations for IP Fragment Filtering.” RFC 1858. 1995.
- IETF. “Protection Against a Variant of the Tiny Fragment Attack.” RFC 3128. 2001.
- IETF. “IPv6 Fragment Header.” RFC 8200 (IPv6 Specification), Section 4.5. 2017.
- CERT/CC. “CERT Advisory CA-1997-28: IP Denial-of-Service Attacks.” 1997.
- CISA. “Understanding and Responding to Distributed Denial-of-Service Attacks.”
- NIST. “Guide to Intrusion Detection and Prevention Systems.” SP 800-94.