IP packet fragmentation is the process of breaking a data packet into smaller pieces so it can travel across a network link that can’t handle its full size. Every network link has a maximum packet size it can carry, called the Maximum Transmission Unit (MTU). When a packet exceeds that limit, it gets split into fragments that are each small enough to fit, then reassembled at the destination.
Why Fragmentation Happens
IP packets can theoretically be up to 65,535 bytes, a limit set by the 16-bit length field in the IP header. But the physical and data-link layers that actually move data between devices have much smaller size limits. Standard Ethernet, the most common networking technology, supports an MTU of 1,500 bytes. That means any IP packet larger than 1,500 bytes can’t cross an Ethernet link in one piece.
A packet might start its journey on a network with a large MTU but hit a link with a smaller one somewhere along the path. When that happens, the packet either needs to be fragmented or the sender needs to be told to send smaller packets. The mismatch between the packet size and the link’s MTU is what triggers fragmentation.
How IPv4 Fragmentation Works
In IPv4, any router along the path can fragment a packet that’s too large for the next link. The IPv4 header contains three fields specifically designed for this:
- Identification: A 16-bit number assigned by the sender that’s the same across all fragments of the original packet. The destination uses this value, along with the source and destination addresses, to figure out which fragments belong together.
- Flags: Two relevant bits here. The “Don’t Fragment” (DF) bit tells routers not to fragment the packet, instead sending an error message back to the sender if the packet is too big. The “More Fragments” (MF) bit is set on every fragment except the last one, signaling that more pieces are coming.
- Fragment Offset: Tells the destination where this fragment fits within the original packet. It’s measured in 8-byte chunks, which means all fragments (except the last) must be sized in multiples of 8 bytes.
When a router fragments a packet, it copies the original IP header into each fragment, adjusts the total length, sets the MF bit on all but the final piece, and fills in the offset so the destination knows the correct order. Each fragment then travels independently through the network. They can take different routes and arrive out of order.
Reassembly at the Destination
Fragments are only reassembled at the final destination host, not at intermediate routers. The receiving host collects all fragments that share the same identification number, source address, and destination address, then uses the fragment offset values to reconstruct the original packet in the correct order.
If any fragment is lost in transit, the entire original packet is discarded. IP does not attempt to recover missing fragments on its own. The destination host sets a reassembly timer when it receives the first fragment, and if all pieces don’t arrive before that timer expires, everything received so far gets thrown away. It’s up to higher-level protocols like TCP to detect the loss and request retransmission of the data.
How IPv6 Handles It Differently
IPv6 took a fundamentally different approach: routers along the path are not allowed to fragment packets. Only the source node can perform fragmentation. If a router receives an IPv6 packet that’s too large for the next link, it drops the packet and sends an error message back to the sender, which must then send smaller packets.
When an IPv6 source does need to fragment, it uses a separate Fragment extension header rather than fields built into the main header. The packet is divided into an “unfragmentable part” (the core IPv6 header and any routing-related extension headers that intermediate routers need to process) and a “fragmentable part” (the actual payload and any headers only the destination needs). Only the fragmentable part gets split across fragments; the unfragmentable part is copied into each one.
IPv6 also requires a minimum MTU of 1,280 bytes on any link, compared to IPv4’s minimum of 576 bytes. This higher floor reduces the chances that fragmentation is needed in the first place.
Why Fragmentation Hurts Performance
Fragmentation is bad for performance in nearly every dimension: throughput, latency, CPU usage, memory consumption, and network congestion. Even splitting a packet into just two pieces roughly doubles the per-packet overhead, since each fragment carries its own copy of the IP header. The effect scales dramatically with smaller fragment sizes. Sending 1,480 bytes of data in the smallest possible (8-byte) fragments would require 185 separate packets, each with its own 20-byte header, ballooning metadata from 20 bytes to 3,700 bytes.
Every router in the path has to process each fragment’s header individually, consuming CPU time that multiplies with the number of fragments. At the destination, the host must allocate memory to hold partial fragments while waiting for the rest to arrive, creating additional resource pressure.
Fragmentation also increases the probability of data loss. If a single fragment out of many is dropped, the entire original packet is lost and must be retransmitted. Since fragments travel independently and can take different paths, the chance that at least one goes missing rises with every additional piece. Worse, many firewalls and routers deliberately drop fragments as a security measure, because fragments beyond the first one don’t contain TCP or UDP port information, making them impossible to filter by standard firewall rules.
Path MTU Discovery: Avoiding Fragmentation
The preferred solution is to avoid fragmentation entirely by figuring out the smallest MTU along the entire path before sending data. This process is called Path MTU Discovery (PMTUD).
In classical PMTUD, the sender marks packets with the “Don’t Fragment” flag and sends them at its local MTU size. If a router along the path encounters a link with a smaller MTU, it drops the packet and sends back an ICMP “Packet Too Big” message (called “Fragmentation Needed” in IPv4) that includes the MTU of the problematic link. The sender then reduces its packet size accordingly and tries again. This continues until packets pass through without issue.
The weakness of this approach is that it depends on those ICMP error messages actually reaching the sender. Some firewalls and network configurations block ICMP traffic, creating what’s known as a “black hole” where packets silently disappear and the sender never learns why. A newer technique called Packetization Layer Path MTU Discovery (PLPMTUD) addresses this by probing with progressively larger packets and observing which sizes get through, so it doesn’t rely entirely on ICMP messages.
Real-World Symptoms of Fragmentation Problems
Fragmentation issues often show up in ways that aren’t immediately obvious. VoIP calls may become garbled or drop out, because real-time audio is especially sensitive to the latency and packet loss that fragmentation introduces. VPN connections are a common trigger, since the encapsulation they add increases packet size beyond the link MTU. Large file transfers may slow to a crawl or stall completely.
One telltale sign is a buildup of TCP retransmissions in network logs. If reassembly timers are expiring because fragments aren’t all arriving, the higher-level TCP protocol sees missing data and keeps requesting it again. You might also see connections that work fine for small requests (like loading a simple web page) but fail on larger transfers, since small packets stay under the MTU while larger ones get fragmented and lost.
A quick diagnostic test is to block ICMP type 3 code 4 messages (the “fragmentation needed” replies) and see if connections break. If they do, your network is relying on Path MTU Discovery and the ICMP messages that support it. Tracing the issue often leads to a specific link in the path, sometimes an older router or tunnel endpoint, that enforces a lower MTU than expected.