When a host transmits an IP packet sent across a channel, the size of the packet cannot exceed the maximum size supported by the local network. This size is defined by the data link and IP Maximum Transmission Units (MTUs) of the network, which is often identical. A typical modern office, home, school, or data center network connected by Ethernet will have MTUs of 1500 bytes.
As a result, some packets may have to be routed through networks with smaller MTUs before they can be delivered. If under any of these scenarios, the data packet’s minimum MTU is exceeded, the packet’s data must be divided. This indicates that it is broken up into smaller packets with a lower MTU. It’s called “Fragmentation,” and the data is usually reassembled when it gets to its final destination.
Typically, when addressing fragmentation, the language used indicates that the original packet is fractured. it is the data contained within that packet that is fragmented — the original packet is deleted.
Where Fragmentation is Used
Fragmentation enables transport layer protocols to operate independently of the underlying network architecture, hence lowering overhead.
Internet Protocol and higher-layer protocols can operate over a wide variety of network pathways and mediums without the requirement for the overhead of a path discovery procedure.
Fragmentation has a variety of disadvantages that necessitate its avoidance whenever possible. Specifically, when a dependable transmission protocol such as TCP is used, the failure of a given segment leads throughout all fragments needing to be resent.
Only the first piece has the high-layer headers, which may pose problems for firewalls, middle-boxes, and routers that rely on those headers for inspection.
Fragmentation can cause out-of-order packet transmission and the requirement for reordering, even more so if only a subset of packets is scattered or if connection consolidation or even other path splitter methods are used.
IPv4 & Utilization of Header Fields
Fragmentation and reassembly involve the setting of several IP header fields in the fragments. Fragmentation is based on three IP header fields, each of which will have significantly different values in the fragments than in the original packet:
- The Identification field is populated with an ID number that is unique for the combination of the source and destination addresses, as well as the Protocol field value of the original packet, allowing the destination to differentiate between packet pieces.
This does not imply that the same ID should be used when fragmenting packets with the same source, destination, and protocol, but that it may be used when they are not. To illustrate, consider sending three packets from host A to host B, each of which must be sliced into four fragments:- The four fragments of the initial packet will all have the same value for the Identification field.
- The four fragments of the second packet will all have the same value for the Identification field, which will be different than the value used for the fragments formed from the first packet.
- The four fragments of the third packet will have the same value for the Identification field, which will differ from the value used for the fragments formed from the first and second packets.
- Similarly, to the original packet, the first reserved bit in the Flags field will be set to 0, as will the second bit, Don’t Fragment. In contrast to the original packet, all fragments except the final one will have the third bit of the More Fragments field set to 1.
As with the original packet, the final packet will have all bits in this field set to 0. If the original packet contained the Don’t Fragment flag, then eliminates splitting and results in frames that need it all being discarded.
The sender should receive an ICMP error of type 3: ‘Destination Unreachable’, code 4: ‘Fragmentation required, and DF set’.- The Fragment Offset field is used to specify the position of the data in the fragment relative to the beginning of the data in the original packet. This data is used to reconstruct the data from all of the fragments. The offset in the first fragment is 0, indicating that the data in this packet begins at the same location as the data in the original packet.
The value in successive fragments is the offset of the data included in the fragment from the beginning of the data in the preceding fragment, in 8-byte ‘blocks’. If an 800-byte packet is divided into two equal 400-byte fragments, the first fragment’s fragment offset is 0, and the second fragment’s fragment offset is 50.
The offset value must be a multiple of eight bytes, which indicates that the data in the preceding fragment must be a multiple of eight bytes. The final fragment may contain data that is not a multiple of eight bytes because there will be no subsequent fragment with an offset that must adhere to the eight-byte rule.Additionally, the values of some header fields fluctuate, either organically at every step or as a function of fragmentation:
- The Total Length field varies in reaction to the decreased size of data in a fragment that is equivalent to and less than the MTU.
- Due to the necessity that the Fragments Offset field in the preceding pieces be a multiple of 8, the length of the fragmentation is not as high as the MTU permits. With IPv4, this field indicates the size of the overall packet, including the header.
- The Header Checksum field is computed to use the contents of all other packet headers.
- One bit is deducted form of the Time to Live field’s value
IPv6 & Utilization of Header Fields
Fragmentation with IPv6 is significantly different than with IPv4, even though the majority of the header fields stay the same and serve the same purpose.
Fragmentation can occur only on the source host, which means that a packet can only be fragmented once, and routers or other network devices do not do fragmentation. Thus, the ‘forward’ fragmentation concept of IPv4 is reversed, in which the original packet is fragmented when necessary and the data contained within is maintained and transmitted to the destination.
Thus, avoiding fragmentation is as simple as not fragmenting. There is no DF flag to be found.
As a result, fragmentation is impossible without using PMTUD, thus endpoints cannot include an MTU larger than that of the IPv6 baseline of 1280 characters without implementing PMTUD. PMTUD IPv6 operates in much the same way as IPv4 does, except the ICMP error message is changed, as illustrated in the accompanying diagram:
If a packet is too large to be transmitted along with a network, the IPv6 router responsible for it shall discard it and return to the sender an ICMPv6 error of type 2: ‘Packet Too Big’, code 0. The MTU of the ‘next hop’ link (in bytes) is included as is as much of the excessively large packet as possible without exceeding the minimum IPv6 MTU of 1280.
This reliance on ICMP and a ‘back channel’ broadcast to the originator host has several shortcomings. The most notable difference is that ICMP communications are commonly blocked or throttled at various points throughout a network for perceived security reasons.
This means that the originating host will not get any Packet Too Big ICMP notifications and will repeatedly transmit the rejected packet(s), none of which will arrive. Eventually, the connection will be deemed unusable and closed, a new one will be made, and the cycle will repeat indefinitely.
Fragmentation-related header fields are added to an extension header called the Fragment Header, which is defined with a Next Header field value of 44 in the regular IPv6 header or previous extension header.
This header, like all extension headers, is 64 bits/8 bytes in length in addition to the standard header, resulting in a larger overhead for IPv6 fragmentation than IPv4. You may argue, however, that because the IPv4 fragmentation fields, which total 32 bits, are included in the standard IPv4 header regardless of whether fragmentation occurs, IPv4’s fragmentation support has a higher overall overhead.
The IPv6 Header Fields That Are Used in Process
- The Next Header defines the type of header that will appear after this one. IPv6 extension header or protocol at the higher layer. For example, if TCP is the upper-layer protocol and this Fragment Header is the final extension header, the value would be 6.4. As with IPv4, the Fragment Offset field (13 bits) is used.
- Similar to the More Fragments (MF) field in IPv4, the M flag field (1 bit) will be set to 1 in all.
- The Identification field is analogous to the 16-bit IPv4 field in that it is populated with an ID number that is unique for the combination of the source and destination addresses. The Protocol field is not taken into account as it does with IPv4 because IPv6 lacks one.
These header field values also differ in the standard header from the unfragmented original packet:
- The Payload Length field changes in response to the reduced data size in a fragment that is equal to or less than the MTU. Due to the requirement that the Fragment Offset field in the following fragments is a multiple of 8, the fragment’s size is not always the maximum allowed by the MTU.
In IPv6, this attribute specifies this same packet’s length excluding the basic header but along with any extension headers (s).- The Next Header field’s value is set to 44 to indicate the presence of an extension header for Fragment Headers. If there are still extension headers, the Next Header valuation inside the header immediately preceding the Fragment Header will be set to 44.
Defending Against Fragmentation
A node can prevent packets from being fragmented by setting the Don’t Fragment (DF) flag to 1. Packets that require fragmentation but do not contain the DF bit are discarded. This is discussed in detail in the PMTUD section that follows.
MTU Path Discovery (PMTUD)
PMTUD prevents fragmentation by dynamically determining the MTU of a path between two hosts via ICMP messages. This relates directly to fragmentation and is worth discussing briefly so that you understand the relationship between the two.
PMTUD operates in the following manner:
- The sending host makes the assumption that the MTU of the local network interface used to reach the destination is valid along the path to the destination. If TCP is used and the destination reports an MSS that results in a smaller MTU, that MSS is assumed to be valid for the remainder of the path.
- The sending host configures all packets sent to the destination with the Don’t Fragment (DF) flag.
- If any packets require fragmentation along their path to the destination, the router involved discards them when the DF bit is set. The router should then return to the source an ICMP error message of type 3: ‘Destination Unreachable’, code 4: ‘Fragmentation required, and DF set’.
This message should include a 16-bit Next-Hop MTU field containing the maximum packet size, in bytes, that can be routed to the next-hop without fragmentation.
Additionally, it includes the IP header of the packet that required fragmentation and the first 64 bits (8 bytes) of its payload, which would normally contain the transport layer header’s source and destination port fields. In the RFC, this ICMP message is referred to as a Datagram Too Big message.- Upon receipt of the ICMP message, the sending host typically compresses the packets sent to the destination based on the message’s Next-Hop MTU field value. The host should store this path MTU information in some way, which typically takes the form of a dedicated routing table entry for the destination address.
The transport layer protocol should be informed of the reduced path MTU. The application sending the data should be informed that the original packet was discarded.- This process is repeated if a lower MTU is encountered further along the path.
A disadvantage of PMTUD is that it helps to reduce fragmentation but also generates new ones. The most typical one is that ICMP messages are stopped somewhere between the router that generated the message and the destination host by firewalls or routers or other network devices.
Sender’s ignorance of the MTU limitation leads to the retransmission of unacknowledged packets that go unacknowledged themselves until a limit is reached and the connection is “hanging” or “stalling” in the process. Known as a black hole connection, this is a type of connection Discovery in the Packetization Layer (PLPMTUD)
To circumvent the PMTUD ICMP blocking issue, PLPMTUD probes the path to a host using a transport layer protocol that supports acknowledgments. PLPMTUD operates in the following manner:
- A sequence of multiple probe packets of varying sizes is sent
- The largest value is equal to the maximum transmission unit (MTU) of the network interface used to reach the destination. The smallest value is 1024 bytes.
- Acknowledgment of probe packets that reach the destination, indicating that an MTU is supported along the entire path.
- Unacknowledged large probes result in the sending of smaller probes
- Acknowledgment of small probes results in the sending of larger probes
- The MTU of the path is set to a value between that of the largest successful small probe and that of the largest successful large probe.
Additional Considerations & Points
You should keep the following in mind:
- Fragmentation and reassembly are CPU-intensive operations that should be avoided at all costs.
- Servers and, less frequently, computer networks implicated in retransmission must allot memory for storing all pieces till they can be refitted, although they will have no way of knowing how many there are. This creates numerous security and availability concerns.
- With IPv6, reassembly must occur within 60 seconds of the initial fragment being received; otherwise, all fragments are discarded. If this occurs, an ICMP error of type 3: ‘Time Exceeded’, with the code 1: Fragment reassembly time exceeded’ should be sent to the source. No message is sent if fragment zero is not available.
With IPv4, things become more complicated; a 15-second initial timeout is recommended after the first fragment is received. The timer value is then reset using the TTL field value of each subsequent fragment received, as long as it is greater than the current value.
This allows for a time interval of up to 4.25 minutes between fragment receipts, which is absurdly long, even in modern networks.
All fragments are discarded when the timer expires. If this occurs, an ICMP error of type 11: ‘Time Exceeded’ with code 1: ‘fragment reassembly time exceeded’ should be sent to the source. No message is sent if fragment zero is not available.
- Fragmentation incurs additional bandwidth costs because each fragment requires its IP header. Because the original packet had its IP header, multiply the number of fragments minus one by the size of the header to determine the additional bandwidth consumed.
Additionally, 8 bytes per fragment are required for the Fragment Header extension headers in IPv6.- Typically, fragments are not reassembled until they arrive at their final. Considering the performance overhead, the potential delay in receiving all fragments, and the possibility of fragment loss and retransmission.
There is no benefit for the majority of router vendors to do so. Reassembly is not a task well suited for a device optimized for packet routing.- Vendors of firewalls and secure inspection devices may disassemble to inspect the entire original data payload. However, in many cases, the original fragments will be routed forward rather than the reassembled packet to avoid the possibility and costs of fragmentation recurrence along the path to the destination.
- Additionally, vendors may reassemble to eliminate overhead on downstream networks and servers and/or to improve performance.
- If fragments arrive out of sequence at a firewall or other device that inspects headers or information at layer 4 or higher, they may be blocked, dropped, or mishandled until the first fragment arrives.
- If fragmentation is used for one or more of the following reasons, the performance of encryption and decryption and/or tunneling encapsulation and decapsulation will typically be negatively impacted.
- Before operating on fragments, they may need to be reassembled, introducing the possibility of delay, reordering, and retransmission, as well as the consumption of CPU and memory resources.
- The reassembled packet may then require further fragmentation due to encryption or encapsulation overhead, thereby decreasing the effective MTU.
- Even in the absence of reassembly, further fragmentation may be necessary for the same reason.
- The software functions responsible for reassembly and/or fragmentation have not been enhanced to the extent that the primary function has been optimized.
- Reassembly and/or fragmentation are performed using different, less performant hardware.
- Fragments can be fragmented again, in which case the original fragment’s Identification field is reused within the new fragments.
- Fragmentation and improper handling of fragmentation have resulted in a plethora of security vulnerabilities
- Backup or redundant links with MTUs less than those of the primary link will cause havoc.
- Lossy or high-latency links will perform extremely poorly if fragments are discarded.
- With TCP, fragmentation and underlying MTU issues are typically not visible during connection setup, as packets are small and rarely contain data. HTTP requests are typically not an issue; it is the typically much larger responses
- ICMP notifications are only sent within reaction to inconsistencies in the ability to handle fragment zero of fragmentary data packets.
- The loss of PLPMTUD Probe packets does not affect the congestion window.
- ECMP Layer four load balancing to servers frequently results in fragmentation issues, as the first fragment containing the transport layer protocol headers can be load balanced to a different server than the remaining fragments.
- ECMP May also do something similar with the ICMP messages used by PMTUD and load balance messages to the incorrect server, as the ECMP algorithm will default to layer three hashing rather than inspecting the ICMP payload and performing layer four hashing using the port information contained therein.
Frequently Asked Questions
What is the purpose of IP fragmentation?
Why is fragmentation is a bad thing?
What are the types of fragmentation?
Conclusion
We created this IP Fragmentation tutorial for our readers in an effort to give them the finest possible information. Reading this guide will help you understand the most important aspects of the subject matter.