Hubbry Logo
IP fragmentationIP fragmentationMain
Open search
IP fragmentation
Community hub
IP fragmentation
logo
8 pages, 0 posts
0 subscribers
Be the first to start a discussion here.
Be the first to start a discussion here.
IP fragmentation
IP fragmentation
IP fragmentation
View on Wikipedia
from Wikipedia
An example of the fragmentation of a protocol data unit in a given layer into smaller fragments

IP fragmentation is an Internet Protocol (IP) process that breaks packets into smaller pieces (fragments), so that the resulting pieces can pass through a link with a smaller maximum transmission unit (MTU) than the original packet size. The fragments are reassembled by the receiving host.

The details of the fragmentation mechanism, as well as the overall architectural approach to fragmentation, are different between IPv4 and IPv6.

Process

[edit]

RFC 791 describes the procedure for IP fragmentation, and transmission and reassembly of IP packets.[1] RFC 815 describes a simplified reassembly algorithm.[2] The Identification field along with the foreign and local internet address and the protocol ID, and Fragment offset field along with Don't Fragment and More Fragments flags in the IP header are used for fragmentation and reassembly of IP packets.[1]: 24 [2]: 9 

If a receiving host receives a fragmented IP packet, it has to reassemble the packet and pass it to the higher protocol layer. Reassembly is intended to happen in the receiving host but in practice, it may be done by an intermediate router, for example, network address translation (NAT) may need to reassemble fragments in order to translate data streams.[3]

IPv4 and IPv6 differences

[edit]
The fragmentation algorithm in IPv4
An example of IPv4 multiple fragmentation. The fragmentation takes place on two levels: in the first one the maximum transmission unit is 4000 bytes, and in the second it is 2500 bytes.

Under IPv4, a router that receives a network packet larger than the next hop's MTU has two options: drop the packet if the Don't Fragment (DF) flag bit is set in the packet's header and send an Internet Control Message Protocol (ICMP) message which indicates the condition Fragmentation Needed (Type 3, Code 4), or fragment the packet and send it over the link with a smaller MTU. Although originators may produce fragmented packets, IPv6 routers do not have the option to fragment further. Instead, network equipment is required to deliver any IPv6 packets or packet fragments smaller than or equal to 1280 bytes and IPv6 hosts are required to determine the optimal MTU through Path MTU Discovery before sending packets.

Though the header formats are different for IPv4 and IPv6, analogous fields are used for fragmentation, so the same algorithm can be reused for IPv4 and IPv6 fragmentation and reassembly.

In IPv4, hosts must make a best-effort attempt to reassemble fragmented IP packets with a total reassembled size of up to 576 bytes. They may also attempt to reassemble fragmented IP packets larger than 576 bytes, but they are also permitted to silently discard such larger packets. Applications are recommended to refrain from sending packets larger than 576 bytes unless they have prior knowledge that the remote host is capable of accepting or reassembling them.[1]: 12 

In IPv6, hosts must make a best-effort attempt to reassemble fragmented packets with a total reassembled size of up to 1500 bytes, larger than IPv6's minimum MTU of 1280 bytes.[4] Fragmented packets with a total reassembled size larger than 1500 bytes may optionally be silently discarded. Applications relying upon IPv6 fragmentation to overcome a path MTU limitation must explicitly fragment the packet at the point of origin; however, they should not attempt to send fragmented packets with a total size larger than 1500 bytes unless they know in advance that the remote host is capable of reassembly.

Impact on network forwarding

[edit]

When a network has multiple parallel paths, technologies like LAG and CEF split traffic across the paths according to a hash algorithm. One goal of the algorithm is to ensure all packets of the same flow are sent out the same path to minimize unnecessary packet reordering.

IP fragmentation can cause excessive retransmissions when fragments encounter packet loss and reliable protocols such as TCP must retransmit all of the fragments in order to recover from the loss of a single fragment.[5] Thus, senders typically use two approaches to decide the size of IP packets to send over the network. The first is for the sending host to send an IP packet of size equal to the MTU of the first hop of the source-destination pair. The second is to run the Path MTU Discovery algorithm[6] to determine the path MTU between two IP hosts so that IP fragmentation can be avoided.

As of 2020, IP fragmentation is considered fragile and often undesired due to its security impact.[7]

See also

[edit]

References

[edit]
[edit]
Revisions and contributorsEdit on WikipediaRead on Wikipedia

IP fragmentation

View on Grokipedia
from Grokipedia
IP fragmentation is a mechanism in the (IP) suite that enables the division of oversized datagrams into smaller fragments for transmission across networks with varying (MTU) sizes, followed by reassembly at the destination host to reconstruct the original packet. This process addresses the challenge of heterogeneous network links, where a source may generate packets exceeding the MTU of intermediate links, ensuring end-to-end delivery without requiring all networks to support arbitrarily large packets. Defined initially for IPv4 in 1981, fragmentation relies on specific header fields to identify and order fragments correctly during reassembly. In IPv4, fragmentation can occur at both the source and intermediate routers (gateways), with fragments carrying modified IP headers that include an Identification field for matching fragments from the same datagram, Flags (such as Don't Fragment and More Fragments), and a Fragment Offset to indicate the position of the fragment's data in the original datagram, measured in 8-octet units. Reassembly happens exclusively at the destination, using a timer (recommended at 15 seconds) to discard incomplete sets, and hosts must support a minimum reassembly buffer of 576 octets. For IPv6, introduced in 1998 and updated in 2017, fragmentation is performed only by the source host—routers do not fragment—using a separate Fragment Header (Next Header value 44) inserted after the base IPv6 header, which contains analogous fields like Fragment Offset, More Fragments flag (M), and Identification, while the minimum path MTU is 1280 octets and reassembly timeout is 60 seconds. This design shift in IPv6 promotes Path MTU Discovery (PMTUD) to avoid fragmentation proactively, as intermediate fragmentation was deemed inefficient and error-prone. Despite its foundational role, IP fragmentation is considered fragile in modern networks due to issues like packet blackholing from lost ICMP "Packet Too Big" messages, reassembly failures under high load, interoperability problems with firewalls and NAT, and security vulnerabilities such as overlapping fragment attacks that can bypass filters or cause denial-of-service. As of 2016–2017, studies indicated that 28% of sampled paths dropped packets with IPv6 Fragment Headers, and 37% of sampled IPv6-capable DNS resolvers could not receive fragmented IPv6 responses, exacerbating reliability concerns. Subsequent measurements have shown improvements, with the global average drop rate for IPv6 fragments declining to 17.6% as of November 2025. As a result, contemporary protocols and applications are encouraged to mitigate fragmentation through transport-layer adjustments (e.g., TCP's ) or variants like Packetization Layer PMTUD, rendering reliance on fragmentation increasingly obsolete for new implementations.

Fundamentals

Definition and Purpose

IP fragmentation is the process of dividing an (IP) into smaller fragments when its size exceeds the (MTU) of a network link, allowing transmission across diverse network paths with varying size constraints. This mechanism ensures that oversized datagrams can be forwarded without requiring the sender to know the MTU of every link along the route, thereby preventing packet drops due to size limitations. The primary purpose of IP fragmentation is to support in heterogeneous environments, where networks may impose different maximum packet sizes, enabling seamless data transmission across interconnected packet-switched systems. By permitting intermediate routers to fragment datagrams as needed, it promotes the scalability and robustness of the early , avoiding the need for uniform packet sizes across all networks. Introduced in the IPv4 specification as part of the Program in , IP fragmentation was essential for the protocol's design to handle "small packet" networks within larger internetworks. For instance, a 2000-byte originating on a network supporting larger packets would be fragmented into multiple smaller pieces—each no larger than 1500 bytes—to traverse a link with that MTU, with reassembly occurring at the destination.

Maximum Transmission Unit (MTU)

The (MTU) is defined as the largest size of an IP datagram, measured in bytes, that can be transmitted over a specific without requiring fragmentation at the IP layer. This limit is enforced by the underlying physical and protocols, ensuring that packets fit within the capabilities of network interfaces and transmission media. In network design, the MTU serves as a foundational constraint that influences packet sizing decisions to optimize efficiency and avoid unnecessary processing overhead. There are two primary types of MTU relevant to IP networks: the link MTU, which represents the hardware-imposed maximum packet size for a single network interface or link, and the path MTU, which is the smallest link MTU among all segments in an end-to-end path between source and destination. The link MTU is a static property determined by the link , while the path MTU accounts for variations across heterogeneous networks, often requiring dynamic determination to prevent issues. Standard link MTU values include 1500 bytes for classic Ethernet networks, as established for IP datagram transmission over Ethernet. Jumbo frames extend this to up to 9000 bytes on supported Ethernet implementations to reduce overhead in high-speed environments, though this is not universally standardized. For protocol compliance, IPv4 specifies a minimum link MTU of 68 bytes to accommodate the smallest viable , including header and minimal payload, while mandates a minimum link MTU of 1280 bytes across all links to simplify processing and ensure interoperability. Exceeding the MTU on a link triggers IP fragmentation if permitted by the packet's Don't Fragment (DF) flag, dividing the into smaller pieces for transmission, or results in packet discard accompanied by an ICMP "Fragmentation Needed" if DF is set, informing the sender to reduce packet size. These outcomes can degrade by increasing latency due to reassembly delays at the destination and reducing throughput from the additional overhead of fragment headers and potential retransmissions. In path scenarios, mismatches amplify these effects, underscoring the MTU's role in balancing packet efficiency with reliable delivery across diverse network topologies.

IPv4 Fragmentation

Header Fields and Identification

The IPv4 header includes several fields dedicated to fragmentation identification and control, enabling routers to divide oversized s and endpoints to reassemble them correctly. The Identification field is a 16-bit value assigned by the originating host to uniquely label all fragments belonging to the same original . This field, combined with the source address, destination address, and protocol fields, allows receiving hosts to match and group fragments accurately during reassembly, preventing intermixing with fragments from other s. Adjacent to the Identification field are the Flags (3 bits) and Fragment Offset (13 bits), which together manage fragmentation behavior and positioning. The Flags consist of three bits: bit 0 (reserved, always set to 0), bit 1 for the Don't Fragment (DF) flag, and bit 2 for the More Fragments (MF) flag. The DF flag, when set to 1, instructs routers not to fragment the ; if fragmentation is required along the path, the router discards the packet and sends an ICMP "Fragmentation Needed" message (Type 3, Code 4) back to the sender. The MF flag is set to 1 in all fragments except the last one, signaling that additional fragments follow; it is 0 for the final fragment. The Fragment Offset field specifies the position of the fragment's data relative to the start of the original 's data, measured in units of 8 bytes (64 bits), with the first fragment always having an offset of 0 and subsequent fragments using cumulative offsets that are multiples of 8. Identification and these fields work in tandem to ensure reliable reassembly: all fragments share the same Identification value, while the Fragment Offset provides the exact byte offset (when multiplied by 8) for ordering, and the MF flag indicates completion. For instance, consider an original with 2000 bytes of total length (including a 20-byte header, so 1980 bytes of ) that must be fragmented due to a 1500-byte MTU path; assuming no IP options, the first fragment might carry 1480 bytes of (offset 0, MF=1), the second 496 bytes of (offset 185, since 1480/8=185, MF=1), and the third the remainder of 4 bytes (offset 247, since (1480+496)/8=247, MF=0), all sharing the same 16-bit Identification value. This mechanism, defined in the IPv4 specification, supports efficient handling of variable network conditions without requiring changes to upper-layer protocols.

Fragmentation Process

The fragmentation process in IPv4 occurs when a 's total length exceeds the (MTU) of the outgoing network interface, requiring the sender (source host) or an intermediate router to divide it into smaller fragments that can be transmitted. This division happens only if the Don't Fragment (DF) flag in the IPv4 header is not set; if DF is set, the datagram is discarded, and an ICMP "Fragmentation Needed" message is sent back to the source with the MTU of the next hop. Intermediate routers perform fragmentation as needed to forward the , while end hosts typically avoid it by employing to determine and use the smallest MTU along the path beforehand. The process begins by copying the original IPv4 header to each fragment, adjusting specific fields as necessary. The Internet Header Length (IHL) field may change if options are present, but the header size is at least 20 bytes. IP options are included in the first fragment; those with the "copied" flag set in their type octet (e.g., or options) are duplicated in all subsequent fragments, while others (e.g., record route or ) appear only in the first. The (data portion) of the original is then divided into chunks, ensuring that the data length of all fragments except the last is a multiple of 8 bytes to align with the fragment offset field's 8-byte unit scaling. To determine fragment sizes, the maximum data payload per fragment is calculated as ⌊(MTU−H)/8⌋×8\lfloor (MTU - H) / 8 \rfloor \times 8, where HH is the header length in bytes (minimum 20). The number of full-sized fragments is ⌊(L−H)/D⌋\lfloor (L - H) / D \rfloor, where LL is the original datagram's total length and DD is the maximum data size per fragment; the remainder forms the last fragment. For each fragment, the Fragment Offset field is set to the cumulative data length of prior fragments divided by 8 (in 13-bit units), the More Fragments (MF) flag is set to 1 for all but the last fragment, and the Total Length field is updated to header size plus the fragment's data length. The Header is recalculated for each fragment due to these changes. For example, consider a 3000-byte (20-byte header, 2980-byte ) traversing a link with 1500-byte MTU. The maximum data per fragment is 1480 bytes (⌊(1500−20)/8⌋×8=1480\lfloor (1500 - 20) / 8 \rfloor \times 8 = 1480). The first fragment carries 1480 bytes of data (offset 0, MF=1, total length 1500), the second carries another 1480 bytes (offset 185, since 1480/8=1851480 / 8 = 185, MF=1, total length 1500), and the last carries the remaining 20 bytes (offset 370, MF=0, total length 40).

Reassembly Process

In IPv4, reassembly of fragmented s is performed exclusively by the destination end host, while intermediate routers forward individual fragments without attempting reconstruction. The receiving host identifies fragments belonging to the same original using the Identification field in the , which must match across all fragments from a given source-destination pair with the same protocol. Fragments are ordered and positioned based on the Fragment Offset field, expressed in units of 8 octets, and the More Fragments (MF) flag, which is set to 1 for all but the last fragment. The reassembly process begins when the first fragment arrives, prompting the host to allocate a buffer for the . Subsequent fragments are buffered and inserted into this space according to their offset values, with the host checking for gaps, overlaps, or duplicates. Overlapping fragments are resolved by retaining the most recent data in case of conflicts, and any detected errors, such as offsets or mismatched identifications, result in discarding the entire set. Reassembly proceeds incrementally until the MF flag is 0 on the final fragment, signaling completeness; at this point, the payloads are concatenated in offset order to form the original , and the IP header's is recomputed over the reassembled header before passing the to the upper-layer protocol. If reassembly is incomplete due to lost fragments, the process waits until a timeout expires, after which all buffered fragments for that are discarded. Hosts must implement a reassembly , with a recommended duration between 60 and 120 seconds starting from the arrival of the first fragment, to accommodate potential delays in fragment delivery. This timeout ensures resource reclamation but introduces the risk that partial datagrams are dropped entirely upon expiration, without partial delivery to higher layers. The process demands significant memory at the receiver, as all fragments must be held simultaneously until reassembly completes or times out, potentially straining hosts under high fragmentation loads. For example, consider three fragments sharing Identification value 12345: the first with offset 0 and MF=1 (carrying the initial 1480 octets of data), the second with offset 185 (1480 octets, MF=1), and the third with offset 370 (740 octets, MF=0). The receiver buffers these, verifies sequential offsets without gaps (0 to 185, then 185 to 370), and upon the last fragment's arrival, concatenates the data into a 3700-octet original before recomputing the .

IPv6 Fragmentation

Key Differences from IPv4

IPv6 fragmentation adheres to the more strictly than IPv4 by discouraging fragmentation at intermediate routers, instead requiring senders to perform fragmentation at the source or utilize to avoid it altogether. In contrast to IPv4, where routers can fragment packets using fields in the base header, IPv6 places no fragmentation-related fields in its fixed 40-byte base header; fragmentation information is instead carried in a dedicated Fragment Header extension, identified by a Next Header value of 44. A key structural difference is 's enforcement of a minimum link MTU of 1280 bytes, which minimizes the occurrence of fragmentation for small packets compared to IPv4's more variable MTU handling without such a universal minimum. Unlike IPv4's Don't Fragment (DF) flag, which signals routers to drop oversized packets and send ICMP messages, lacks an equivalent flag in its headers; oversized packets are either dropped silently by routers or, if supported, trigger an "Packet Too Big" message to inform the sender. These mechanisms were first specified in RFC 2460 in December 1998, with updates and clarifications provided in RFC 8200 in July 2017 to address errata and improve interoperability. For instance, in IPv6, if the path MTU is unknown, the sender must proactively fragment the original packet into pieces no larger than 1280 bytes before transmission, ensuring end-to-end delivery without relying on router intervention.

Extension Headers and Processing

In IPv6, fragmentation is facilitated by the Fragment Header, an extension header that allows source nodes to divide oversized packets into smaller fragments for transmission across networks with varying maximum transmission unit (MTU) sizes. This header is inserted only by the originating source, as intermediate routers do not perform fragmentation; instead, they drop oversized packets and notify the source via an ICMPv6 Packet Too Big message (Type 2). Unlike IPv4, where fragmentation can occur at any router, IPv6 enforces end-to-end fragmentation and reassembly to simplify routing and improve efficiency. The Fragment Header consists of 8 octets and follows the base header or any preceding extension headers, with its presence indicated by a Next Header value of 44 in the previous header. Its structure is as follows:
FieldSize (bits)Description
Next Header8Identifies the type of the initial header of the Fragmentable Part (upper-layer or subsequent extension header).
Reserved8Set to zero by the sender and ignored by the receiver.
Fragment Offset13Indicates the offset of this fragment from the start of the original Fragmentable Part, measured in units of 8 octets (thus supporting offsets up to 65,528 octets).
Reserved2 (Res)2Set to zero by the sender and ignored by the receiver.
M Flag1More Fragments flag; set to 1 if additional fragments follow, or 0 for the last fragment.
Identification32A for the original packet, shared across all fragments with the same source and destination addresses to enable reassembly.
The Fragment Offset is always a multiple of 8, ensuring alignment, and the first fragment typically has an offset of 0 while including the full upper-layer protocol header in its Fragmentable Part. When processing an IPv6 packet containing a Fragment Header, intermediate routers that do not need to fragment simply forward the fragment without alteration, treating it as an atomic unit. Destination hosts, however, must reassemble the fragments using the Identification field to group them and the Fragment Offset and M Flag to order and combine the Fragmentable Parts. Reassembly supports atomic fragment processing, where overlapping fragments are discarded if they do not match exactly, preventing inconsistencies; the process times out after 60 seconds, discarding incomplete sets. This reassembly is end-to-end only, similar to IPv4 but without intermediate involvement, and errors such as invalid offsets or lengths trigger ICMPv6 Parameter Problem messages (Type 4, various codes). For example, in an datagram that requires fragmentation, the first fragment would include the Fragment Header with Fragment Offset set to 0 and M Flag set to 1, carrying the initial portion of the payload (including the upper-layer header) up to the link MTU minus the header overhead, while subsequent fragments would have increasing offsets and the same Identification value until the final one with M Flag 0.

Network and Performance Implications

Path MTU Discovery

Path MTU Discovery (PMTUD) is a technique used by IP hosts to dynamically determine the (MTU) size along a network path, allowing them to transmit packets without requiring fragmentation at intermediate routers. By identifying the smallest MTU on the path—known as the path MTU (PMTU)—senders can adjust packet sizes to avoid fragmentation, which incurs processing overhead and potential . The process relies on the sender setting the Don't Fragment (DF) flag in IP headers and responding to feedback from routers that encounter size constraints. The core mechanism begins with the sender assuming an initial PMTU, often the MTU of the first-hop interface, such as 1500 bytes for Ethernet links. Packets are transmitted with the DF flag set, preventing intermediate fragmentation. If a router receives a packet exceeding its outgoing link MTU, it discards the packet and returns an to the sender, specifying a suggested lower MTU value. The sender then iteratively reduces the packet size based on this feedback until packets traverse the path successfully, effectively converging on the PMTU defined as the minimum of all MTU values reported along the path: Effective PMTU=min⁡(received MTU feedbacks along path)\text{Effective PMTU} = \min(\text{received MTU feedbacks along path}) This iterative approach ensures optimal sizing without exhaustive probing of every link. In IPv4, the process uses ICMP "Destination Unreachable" messages with code 4 ("Fragmentation Needed and DF Set"), which include the next-hop MTU in the message's unused field. Hosts cache the discovered PMTU per destination in their tables, updating it only if a lower value is received, and age out stale entries (e.g., after 10 minutes) to handle path changes. To address "" scenarios where ICMP messages are lost or filtered—leading to stalled connections—implementations include detection algorithms that timeout and revert to a conservative PMTU, such as the minimum IPv4 MTU of 68 bytes, before retrying. These details are specified in RFC 1191, published in 1990, which outlines the algorithm including plateau-based search tables for efficient reduction steps. For IPv6, PMTUD is mandatory for senders, as routers do not fragment packets. The mechanism employs Type 2 "Packet Too Big" messages, which carry the MTU of the link that caused the issue and include the original packet for verification. Hosts start with the first-hop MTU and lower the PMTU estimate upon receiving these messages, ensuring it never drops below the minimum link MTU of 1280 bytes to maintain . Caching and updates follow similar principles to IPv4, with detection critical due to potential filtering; implementations probe periodically or use timeouts to recover. This is detailed in RFC 8201 from 2017, which updates earlier guidance and emphasizes robust handling of feedback loss. By enabling hosts to avoid fragmentation, PMTUD reduces CPU and bandwidth overhead associated with splitting and reassembling packets, thereby improving overall network efficiency and throughput, particularly in diverse topologies with varying link MTUs.

Forwarding and Performance Impacts

In IP networks, fragmentation introduces forwarding challenges because each fragment is routed independently as a separate , potentially leading to reordering if paths diverge due to load balancing or policy routing. This reordering necessitates buffering at the destination during reassembly, which can amplify queueing delays, especially in congested networks where fragments arrive out of sequence. Such independent handling also increases the risk of fragments being dropped by intermediate devices, as many firewalls and routers discard fragments to mitigate risks, further complicating reliable delivery. The performance costs of fragmentation are multifaceted, beginning with elevated CPU overhead at both fragmentation and reassembly points. Fragmenting a requires routers to parse, split, and encapsulate payloads into new headers, while reassembly demands the endpoint to allocate buffers and match fragments via identification fields—a process that can consume significant processing resources, particularly in software-based routers striving for line-rate performance. If any fragment is lost, protocols like TCP must retransmit the entire original rather than individual fragments, exacerbating inefficiency in lossy environments. Additionally, bandwidth is wasted due to repeated headers; each IPv4 fragment incurs at least 20 bytes of overhead, plus potential options, reducing effective throughput— for instance, fragmenting a 1500-byte into fragments with only 8 bytes of data each would require approximately 185 fragments, each incurring at least 20 bytes of overhead, resulting in over 3700 bytes of metadata—far more than doubling the load—compared to a single unfragmented packet. Empirical observations highlight these impacts in specific scenarios, such as VPNs and tunnels, where MTU mismatches are prevalent due to encapsulation overhead (e.g., 24 bytes for GRE or 50-73 bytes for ). In such cases, fragmentation can significantly degrade performance; reassembly delays from out-of-order arrivals or losses may extend latency by factors proportional to the number of fragments, with worst-case buffering needs leading to throughput reductions and connection stalls. Studies indicate that 28% to 37% of paths drop fragments outright, compounding these effects in tunneled traffic. Mitigations like (PMTUD) help reduce fragmentation occurrences by enabling sources to probe and adjust to the smallest MTU along the path, avoiding the need for in-network splitting. IPv6's design further minimizes router involvement by prohibiting intermediate fragmentation, shifting the burden to endpoints via extension headers and feedback, which streamlines forwarding at the cost of potential discovery failures if messages are filtered. Historically, IP fragmentation contributed to early bottlenecks by enabling across diverse link technologies but introducing inefficiencies at scale, such as reassembly errors from the 16-bit identification field wrapping at high data rates (e.g., >100 Mbps), leading to corruption and resource waste. These issues were addressed in modern RFCs, including RFC 4459 (2006), which outlines tunneling-specific solutions to curb fragmentation-related delays and overhead in router-to-router deployments.

Security Considerations

IP fragmentation introduces several security vulnerabilities that attackers exploit to bypass network defenses and disrupt services. One prominent example is the Teardrop attack, discovered in 1997, which sends overlapping IP fragments with manipulated offset and size fields to confuse the reassembly process at the target, potentially causing system crashes or denial of service. This technique allows attackers to evade firewalls by splitting packets in ways that prevent proper inspection of the full , as many security devices process fragments individually without reassembly. Attackers also use fragmentation for evasion techniques against intrusion detection systems (IDS) and intrusion prevention systems (IPS), by distributing malicious payloads across multiple fragments, which reassemble only at the destination to form an undetectable attack. For instance, a tiny fragment attack variant involves sending small initial fragments (e.g., 8 bytes) that overlap or manipulate headers, enabling unauthorized access or filter bypass, such as altering TCP ports to permit restricted traffic. Fragmentation poses denial-of-service (DoS) risks through resource exhaustion, where incomplete or excessive fragments consume reassembly buffers and CPU cycles at endpoints or intermediate devices. is particularly vulnerable, as routers can fragment packets en route, amplifying the compared to , where fragmentation occurs only at the source. A classic example is the attack, which uses oversized ICMP packets fragmented into segments that reassemble to exceed buffer limits (over 65,535 bytes), leading to overflows and system instability on unpatched devices. In , the attack surface is reduced due to end-to-end fragmentation and larger minimum MTU, but vulnerabilities persist, including identification field (ID) collisions that can drop legitimate fragments during reassembly and abuse of extension headers to chain malicious payloads. Atomic fragments, generated for , can be forged via spoofed "Packet Too Big" messages to trigger unnecessary fragmentation and enable DoS against protocols like BGP. Mitigations include disabling IP fragmentation at routers where feasible to prevent intermediate reassembly burdens, enforcing fragment size limits to avoid tiny or oversized pieces, and implementing to detect overlaps or anomalies during reassembly. Specific filters, such as dropping fragments with offset 1 or those too small for full headers, address tiny fragment variants as outlined in RFC 3128.
Add your contribution
Related Hubs
User Avatar
No comments yet.