Fragmentation represents a legitimate and expected artifact of IP traffic traversing heterogeneous network segments with differing MTU constraints. In forensic examination, the theoretical framework and compositional characteristics of normal fragmentation are first established to define the baseline against which anomalous or evasive fragmentation patterns may be differentiated.
IP fragmentation remains forensically relevant, but its presence is not, by itself, an indicator of malicious activity. On well-configured networks, fragmentation is often reduced through path MTU discovery (PMTUD), appropriate TCP maximum segment size (MSS) adjustment, and conservative UDP message sizing. These mechanisms do not eliminate fragmentation. It can still occur when the path MTU is smaller than expected, PMTUD fails, encapsulation introduces additional overhead, or an application generates a datagram that exceeds the available transmission size. TCP MSS clamping affects TCP segment sizing; it does not generally prevent fragmentation of UDP datagrams or other IP traffic.
The forensic significance of fragmentation depends on its context: the affected hosts, network topology, protocol, packet characteristics, observed frequency, and relationship to other events. An unexpected fragment sequence warrants investigation, but rarity alone does not establish malicious intent. A useful initial classification considers three hypotheses: evasion, exploitation, and benign network or application behavior. These categories guide the investigation; they are not exhaustive, mutually exclusive explanations.
Fragmentation can be abused to create discrepancies between what a network security sensor inspects and what the destination host ultimately processes. If an inspection device and an endpoint differ in their handling of overlapping fragments, fragment timeouts, incomplete datagrams, or malformed packet sequences, the sensor's reconstructed representation may differ from the endpoint's interpretation. Ptacek and Newsham described this broader class of network intrusion detection system (NIDS) evasion techniques in 1998. Their work remains relevant because inspection accuracy depends not only on the packets captured but also on how the monitoring system models the destination's protocol behavior. Out-of-order arrival alone is not evidence of evasion. IP fragments may arrive out of order during ordinary network transmission and can be reassembled successfully. The more significant question is whether the fragments are inconsistent, malformed, overlapping, incomplete, or interpreted differently by the sensor and endpoint.
IPv6 reduces one important source of ambiguity. RFC 5722 requires a receiver to discard the entire reassembled datagram when overlapping IPv6 fragments are detected. This requirement does not eliminate all fragmentation-related security risks, however. Resource exhaustion, incomplete inspection, implementation defects, and discrepancies elsewhere in the packet-processing path remain relevant.
Forensic indicators to examine include:
- Overlapping fragment ranges or conflicting payload bytes.
- Missing fragments, unusual offsets, inconsistent lengths, or malformed fragment sequences.
- Differences between the sensor's reassembled representation and the endpoint's observed behavior.
- Repeated fragmentation patterns associated with suspicious sessions, alerts, or exploitation attempts.
- Disagreement between network monitoring tools and endpoint telemetry about the contents or outcome of a connection.
An evasion hypothesis should be supported by packet-level evidence and, where possible, by validating the behavior of the relevant sensor and endpoint implementations. Fragmentation alone does not establish an attempt to bypass detection.
IP fragmentation requires network stacks and intermediate systems to process fragment metadata, maintain reassembly state, and allocate resources before a complete datagram is available. Defects in these operations can expose systems to denial of service and, in certain vulnerabilities, remote code execution. Whether exploitation is possible depends on the affected implementation, its configuration, the vulnerability's triggering conditions, and any applicable security updates. The following vulnerabilities illustrate distinct failure modes in network packet processing. They should not be treated as interchangeable examples of a single fragmentation vulnerability.
- CVE-2021-24074—Microsoft Windows IPv4 source-routing vulnerability: This vulnerability concerns the handling of IPv4 source-routing options and was disclosed as part of Microsoft's February 2021 TCP/IP security updates. It is associated with remote code execution under the relevant vulnerable conditions. Source routing is disabled by default, but the stack must still parse the IP options in the packet header, so the default setting does not remove exposure. Mitigate with
netsh int ipv4 set global sourceroutingbehavior=dropand by discarding source-routed packets at the perimeter. It should not be described as a generic vulnerability affecting all fragmented IPv4 packets. Microsoft's documented mitigations and the applicable security update should be consulted when assessing exposure. Source-routing configuration and perimeter filtering are relevant defensive considerations, but the exact mitigation should be validated against the Windows version and Microsoft advisory rather than inferred from the presence of fragmentation. - CVE-2021-24094— Microsoft Windows IPv6 vulnerability: This vulnerability was also disclosed in Microsoft's February 2021 TCP/IP security updates and was associated with remote code execution. Its inclusion in a fragmentation-focused investigation should be accompanied by the precise trigger and affected-platform details from Microsoft's advisory. It should not be taken to mean that IPv6 fragmentation itself permits remote code execution.
- CVE-2018-5391 (FragmentSmack): This Linux kernel vulnerability concerns inefficient processing of IP fragments and can cause excessive CPU consumption, resulting in denial of service. It illustrates how fragment processing can become a resource-exhaustion vector even when the attacker does not obtain code execution. Investigation should correlate abnormal fragment traffic with host resource utilization, kernel versions, and patch status.
- CVE-2020-36516— Linux IP identification assignment flaw: This vulnerability concerns IP ID assignment and can facilitate off-path attacks, including TCP-session injection or termination, under applicable conditions. The original vulnerability description identifies affected Linux kernel versions through 5.16.11. That version range should not be interpreted without considering vendor-specific fixes, backported patches, and the actual kernel build deployed on the examined host. This case is relevant to IP-layer identification and packet-injection analysis, but it is not simply a conventional fragment-reassembly defect.. It carries a 2020 identifier but was published in 2022.
- CVE-2021-3905— Open vSwitch userspace fragment handling: This vulnerability concerns memory exhaustion associated with IP-fragment processing in Open vSwitch userspace components. It demonstrates that fragmentation-related exposure is not confined to endpoint operating-system kernels: virtual switching and other network infrastructure components may also be affected. The relevant Open vSwitch release, vendor packaging, and patch status must be established before attributing exposure.
Related but distinct: CVE-2018-5390 (SegmentSmack) - SegmentSmack targets TCP segment processing and can cause denial of service. TCP segmentation and IP fragmentation operate at different layers: TCP segments are transport-layer units, whereas IP fragments are network-layer units. SegmentSmack should therefore be excluded from a narrowly defined set of IP-fragmentation vulnerabilities, although it may be discussed separately in a broader investigation of packet-processing and reassembly attacks.
For each suspected exploitation event, distinguish vulnerability exposure from evidence of exploitation. An affected software version establishes potential susceptibility, not proof that an attack succeeded. A defensible assessment should correlate packet evidence with system logs, resource metrics, process activity, security alerts, patch history, and the vulnerability's documented triggering conditions.
Benign Causes: Path-MTU Problems and Application Behavior
When outbound IP fragments are observed, a path-MTU mismatch is one plausible explanation. Potential causes include tunnel encapsulation, misconfigured MTU values, failed PMTUD, and application-generated UDP datagrams that exceed the usable path size. Encapsulation protocols such as IPsec, GRE, and VXLAN add headers that consume part of the underlying path MTU. A packet that fits on the inner network may exceed the available size on the encapsulating path. Depending on the encapsulation mode, configuration, and network path, this may result in fragmentation, packet drops, or other transmission failures. PMTUD failures are particularly relevant when the network blocks or mishandles the messages needed to signal that a packet is too large. For IPv4, ICMP Destination Unreachable, Type 3 Code 4, traditionally communicates that fragmentation is needed but prohibited. For IPv6, ICMPv6 Packet Too Big messages provide the corresponding path-MTU feedback. Filtering these messages can cause black-hole behavior or repeated retransmission attempts rather than necessarily producing fragments. The observed outcome depends on the protocol, packet size, DF behavior, and implementation. UDP applications can also generate datagrams that exceed the available path MTU. Protocols and services that may warrant examination include IKE, NFS, and DNS, depending on the deployment and traffic pattern. EDNS0 is relevant to DNS message sizing, but it should not be treated as a universal or dominant cause of fragmentation without supporting evidence.
The investigation should distinguish fragmentation at the source, fragmentation at an intermediate device, and fragmentation observed only at a particular capture point. A packet trace taken before tunnel encapsulation may differ substantially from one collected after encapsulation. Host network offloads and capture mechanisms can also affect the apparent packet boundaries. The analyst should therefore document the capture interface, topology, tunnel state, and any relevant offload or preprocessing behavior before drawing conclusions.
DNS, EDNS0, and UDP Fragmentation
DNS is a useful case study because EDNS0 permits DNS messages to exceed the original 512-byte UDP message-size limit. However, an advertised EDNS0 UDP payload size is a statement about the maximum UDP payload a participant indicates it can accept; it is not a measurement of the path MTU and does not guarantee that a response can traverse the network without fragmentation. On a conventional 1500-byte IPv4 path with a 20-byte IPv4 header and an 8-byte UDP header, the theoretical maximum UDP payload that fits in one unfragmented IP packet is 1472 bytes. This calculation assumes no IP options, additional encapsulation, or smaller effective path MTU. IPv6 and tunneled paths have different header and overhead considerations. Large DNSSEC-signed responses and substantial record sets can exceed a safe UDP message size. Whether fragmentation occurs depends on the actual response size, EDNS0 negotiation, DNS implementation, network path, and fallback behavior. A response that exceeds the available path MTU may be fragmented, dropped, or handled through another mechanism, depending on the conditions. DNS role and configuration also matter:
- Recursive resolver: The advertised receive capacity in an upstream query affects the response size the resolver indicates it can accept. The resolver's own outbound query behavior, response handling, and downstream response generation are separate considerations.
- Authoritative server: Response sizing depends on the requester's advertised capacity, server implementation and configuration, and applicable protocol limits. Do not assume every server applies the same response-sizing rule.
- Stub resolver: Behavior depends on the operating system, resolver implementation, configuration, and application path. Attribute defaults to a specific build only when supported by reliable documentation or direct verification.
A claim that Windows DNS Server universally advertises an EDNS0 UDP payload size of 4000 bytes should not be made without verifying the relevant Windows Server version, role, and configuration. A configured or observed buffer size is not proof that a DNS response was fragmented. To establish fragmentation, examine the IP packets and their fragment metadata.
DNS fragmentation also has a security history. Research by Herzberg and Shulman documented risks associated with DNS cache poisoning and IP fragmentation, illustrating how fragmentation behavior can affect the assumptions on which DNS security mechanisms rely. These findings support careful investigation of suspicious fragmented DNS traffic; they do not establish that every fragmented DNS response is malicious. DNS Flag Day 2020 reinforced the use of conservative UDP response sizing, commonly associated with a 1232-byte DNS message-size target, to reduce fragmentation risk across a broad range of network paths, particularly those constrained by IPv6's minimum MTU. This is a risk-reduction measure, not a guarantee against fragmentation or packet loss. Implementations must also handle truncation and TCP fallback appropriately.
From a forensic perspective, DNS analysis should establish the advertised EDNS0 size, actual DNS message length, IP packet length, fragment offsets, response flags, transport fallback, and the behavior of the relevant resolver or authoritative server. These observations should be interpreted together rather than treating EDNS0 configuration as direct evidence of fragmentation.
Fragmentation complicates packet filtering, flow reconstruction, and protocol attribution. Only the initial IP fragment normally contains the transport-layer header. Subsequent fragments do not carry a complete TCP or UDP header and therefore cannot independently supply transport ports. As a result, a Wireshark display filter such as udp.port == 53 may omit non-initial fragments belonging to a fragmented DNS datagram. Their absence from a port-filtered view does not establish that those packets are unrelated to DNS. Analysts should examine the unfiltered capture and use IP-layer attributes to identify and correlate the fragments.
For IPv4, relevant attributes include source and destination addresses, the upper-layer protocol identifier, the IP Identification field, fragment offset, the More Fragments flag, packet length, and capture timing. For IPv6, use the source and destination addresses, the Fragment extension header's Identification field, fragment offset, the M flag, and the surrounding extension-header context. Identification values alone are insufficient to prove that packets belong to the same datagram; they must be interpreted alongside addresses, protocol context, offsets, timing, and other available evidence.
Preserve the original captured packets alongside any reassembled representation produced by the analysis tool. Reassembly is a reconstruction performed by the sensor or analyst's software; it is not a substitute for the original wire-level evidence. Document the tool and version used, relevant reassembly settings, capture limitations, and any discrepancies between alternative reconstructions. The capture vantage point must also be recorded. Sensors on opposite sides of a tunnel endpoint may observe different packet sizes, encapsulation headers, and fragmentation patterns for the same logical traffic. Host captures may additionally reflect segmentation or receive offloads, depending on the operating system and capture mechanism. Apparent fragmentation should therefore be assessed against the topology and collection method before it is attributed to an endpoint or intermediary.A sound forensic workflow should:
- Preserve the original packet capture and document its provenance, capture point, timestamp context, and known limitations.
- Identify fragment sequences using IP-layer metadata rather than relying exclusively on transport-port filters.
- Reconstruct the datagram using documented tool behavior and retain the original fragments for independent verification.
- Compare packet-level evidence with endpoint telemetry, security alerts, resource utilization, configuration, and patch history.
- Evaluate competing explanations, including evasion, exploitation, path-MTU failure, encapsulation overhead, application behavior, and capture artifacts.
- State the conclusion at the level supported by the evidence, distinguishing observed facts from hypotheses and unresolved uncertainties.
Fragmentation is a defined IP-layer mechanism, but RFC 8900 documents its operational fragility. Its presence should prompt contextual analysis rather than an automatic inference of malicious intent. Fragmentation can facilitate inspection evasion when a sensor does not reassemble packets or reconstructs them differently from the destination host. Relevant discrepancies include overlapping fragment ranges, inconsistent payload bytes, differences in timeout and queue-handling policies, and initial fragments that provide insufficient transport-header data for reliable inspection. Out-of-order arrival, incomplete fragment trains, and unusual offsets are not independently proof of evasion. The analyst should establish whether the fragments form a valid datagram, determine how the relevant sensor and endpoint handle the sequence, and correlate the packet evidence with network configuration and endpoint telemetry. Conclusions should distinguish observed behavior from hypotheses about intent.
IPv4 fragments retain the original datagram's source address, destination address, protocol identifier, and Identification value. However, not every header field remains identical across the fragment train. Each fragment has its own Total Length, Fragment Offset, flag values, and Header Checksum. The Identification field is retained from the original datagram, while the Time to Live (TTL) is decremented during forwarding. Consequently, fragments captured at the same observation point may exhibit different TTL values if they traversed different paths or experienced different forwarding behavior. IPv4 options can also differ between the initial fragment and subsequent fragments because only options marked for copying are carried into non-initial fragments. Three IPv4 header fields define the principal fragmentation semantics: Identification, Fragment Offset, and the More Fragments (MF) flag. These fields support fragment association and reconstruction, but they do not independently establish that a datagram is complete, valid, or benign.
The fragmented portion is the original IP payload. For TCP and UDP traffic, this includes the transport header and application data. The transport header normally begins in the first fragment, identified by an offset of zero. Subsequent fragments do not carry a new transport header, so their transport ports and TCP flags cannot be read directly from those fragments. This limitation affects port-based filtering, protocol attribution, and flow reconstruction.
The receiving stack associates fragments by the tuple of source address, destination address, protocol identifier, and the 16-bit IP Identification field. In IPv6 the equivalent is the source, destination, and 32-bit identification in the Fragment extension header. The IPv4 Identification field is assigned by the sender and has a limited 16-bit value space. Depending on the implementation, traffic rate, and identification-generation strategy, values can be reused or collide while earlier datagrams remain relevant to reassembly. A forged fragment that matches a live tuple within the reassembly timeout can be spliced into a legitimate train. That is the premise of fragment-injection attacks. Successful injection is not established by a tuple match alone: timing, fragment offsets, payload coverage, overlap handling, validation rules, and the receiving implementation's behavior all matter. Reassembly contexts are subject to implementation-specific timeouts and resource limits. There is no single timeout that applies universally across operating systems, network devices, and protocol implementations. Investigators should establish the relevant implementation and configuration before interpreting the timing of fragment arrival or expiration. RFC 6864 distinguishes atomic IPv4 datagrams—those with DF set, MF clear, and Fragment Offset zero—from datagrams that are actually fragmented. For atomic datagrams, the Identification field has no fragmentation-related significance and may contain an arbitrary value, including zero. Accordingly, IP ID patterns in atomic datagrams should not be interpreted as reliable evidence of fragment association or sequence behavior.
Fragment Offset gives each fragment’s position within the original payload, in 8-byte units. It carries no information about sending time or order, and fragments may traverse different paths, arrive out of sequence, be duplicated, or be lost. The MF flag indicates whether more fragments of the original datagram follow. An MF value of one indicates that the current fragment is not the terminal fragment; an MF value of zero indicates that no further fragment is expected beyond its payload. When MF is zero and the offset is nonzero, the fragment provides the terminal boundary of a fragmented datagram. When MF is zero and the offset is zero, the packet is an unfragmented IPv4 datagram. Because fragment offsets use eight-byte units, the payload of every non-final IPv4 fragment must have a length divisible by eight. The final fragment may have a payload length that is not divisible by eight. A terminal fragment establishes the expected end of the original payload, but its presence does not prove that the datagram has been fully captured or reassembled. Completeness requires sufficient payload coverage from offset zero through the terminal boundary, with no uncovered ranges. Overlaps must be assessed separately because their interpretation may depend on the receiving stack's validation and reassembly policy. A packet capture can also be incomplete even when the observed fragments appear internally consistent.
Treat each candidate fragment train as a unit of evidence, while retaining the individual packets as the primary observations. Examine the following characteristics:
- Missing or duplicated fragments: Identify gaps in payload coverage and repeated fragments, distinguishing genuine network duplication from capture artifacts.
- Overlapping offsets: Determine whether fragment payload ranges overlap and, where they do, whether the overlapping bytes agree.
- Conflicting payload content: Record contradictory bytes in overlap regions and assess how the relevant endpoint or inspection device handles them.
- Missing terminal fragment: Determine whether a fragment with MF clear establishes the expected end of the datagram. Its absence leaves the total payload boundary unconfirmed.
- Insufficient initial-fragment data: Check whether the first fragment contains enough transport-header information for reliable inspection. Very small initial fragments may divide transport-header fields across fragments and challenge devices that do not reassemble before applying policy
- TTL variation: Compare TTL values within the candidate train. Differences may reflect distinct paths or forwarding behavior, but are not independently proof of evasion.
- Inconsistent lengths and alignment: Validate fragment offsets, payload lengths, header lengths, and non-final fragment alignment against the applicable protocol requirements.
- Reassembly and capture limitations: Account for packet loss, capture truncation, offload behavior, filtering, and implementation-specific reassembly limits before concluding that a fragment is absent or malformed.
Preserve the original packets alongside any reconstructed datagram. A reassembled view represents the interpretation produced by a particular host or analysis tool, not an independent substitute for the captured evidence. Document the tool version, relevant reassembly settings, capture vantage point, and any discrepancies between available reconstructions. The forensic conclusion should distinguish directly observed packet properties from inferred reassembly behavior and suspected intent. Fragment overlap, anomalous TTL variation, missing fragments, or unusual Identification values may justify further investigation, but none alone establishes successful injection or deliberate evasion.
Interpreting the More Fragments Flag
The IPv4 More Fragments (MF) flag indicates whether a fragment is terminal within its original datagram. When MF=1, the fragment is not the final fragment; its payload ends before the terminal boundary of the original IP payload. MF describes fragment position, not transmission time or arrival order. It does not establish that subsequent fragments have already been transmitted or remain in flight. Fragments may traverse different paths, arrive out of order, be delayed, duplicated, or be lost. Lower-offset fragments may likewise remain outstanding when a higher-offset fragment arrives.
An IPv4 datagram is identified as a fragment when MF=1 or the Fragment Offset is nonzero. These fields produce three combinations for fragmented datagrams:
MF=1, offset=0: The initial fragment. It contains the beginning of the original IP payload and normally the transport-layer header.
MF=1, offset greater than zero: A non-initial, non-terminal fragment.
MF=0, offset greater than zero: A terminal fragment. Its offset and payload length establish the end boundary of the original IP payload, assuming the fragment train is valid. It may arrive before any other fragment.
The combination MF=0 and offset=0 identifies an unfragmented IPv4 datagram. Consequently, filtering on MF alone excludes terminal fragments and cannot capture every member of a fragment train. In Wireshark, use the following display filter to select IPv4 fragments, including terminal fragments:
ip.flags.mf == 1 || ip.frag_offset > 0For classic BPF, the following expression selects IPv4 packets with MF set or a nonzero Fragment Offset:
ip[6:2] & 0x3fff != 0The mask selects the MF flag and Fragment Offset while excluding the DF and reserved flags. IPv6 uses a different header structure: fragmentation is indicated by the presence of an IPv6 Fragment extension header, which contains an offset and an M flag. The IPv6 M flag indicates whether more fragments follow in the original datagram.
For a valid, non-overlapping IPv4 fragment train, all non-terminal fragments have MF=1, and the terminal fragment has MF=0. In practice, overlapping, duplicated, or malformed fragments can violate this pattern, so assess each observed fragment against the entire candidate train rather than treating this rule as proof of validity. The following conditions warrant investigation:
Multiple terminal fragments: More than one distinct terminal fragment associated with the same candidate reassembly context, particularly when their end boundaries differ, may indicate contradictory claims about the datagram's total payload length. Examine duplicates and overlapping fragments before concluding that the claims are inconsistent.
Invalid fragment alignment: Every non-terminal IPv4 fragment must have a payload length divisible by eight bytes, because subsequent Fragment Offsets are expressed in eight-byte units. A violation indicates malformed traffic or a capture or interpretation issue that requires validation.
Excessive reconstructed length: The end boundary implied by a fragment's offset and payload length must be consistent with IPv4's maximum datagram size. The 16-bit Total Length field limits the complete IPv4 datagram, including its header, to 65,535 bytes. Therefore, the maximum permitted payload length depends on the original datagram's header length; 65,535 bytes is not an unconditional payload limit.
Contradictory DF and fragmentation fields: DF=1 combined with MF=1 or a nonzero Fragment Offset is inconsistent with the intended IPv4 semantics of the Don't Fragment flag. Record the packet as anomalous and consider the capture point, packet origin, and relevant implementation behavior before attributing intent.
These conditions are indicators of malformed traffic or potential reassembly ambiguity, not conclusive evidence of evasion or denial of service. Similar patterns may arise from deliberate manipulation, implementation-specific behavior, or collection artifacts. Record each anomaly against the candidate fragment train, preserve the original packets, and retain any reassembled representation separately. The resulting assessment should distinguish observed protocol violations from hypotheses about attacker intent.
Don't Fragment, Path MTU Discovery, and Forensic Interpretation
The IPv4 Don't Fragment (DF) flag prohibits routers from fragmenting a datagram during forwarding. If a router must forward a DF-set datagram onto a link whose MTU is smaller than the datagram, it discards the packet and should return an ICMP Destination Unreachable message, Type 3 Code 4 (Fragmentation Needed and DF Set). Under RFC 1191, the message includes a 16-bit Next-Hop MTU field, along with the original IP header and at least the first eight bytes of the original datagram's payload. Older implementations that predate RFC 1191 may report a zero MTU field. For TCP traffic, the quoted payload normally contains the source and destination ports and the beginning of the TCP sequence number. This information helps correlate the ICMP error with a captured connection, but the quoted header must be checked against observed traffic rather than accepted as proof of authenticity.
Path MTU Discovery (PMTUD) uses these errors to estimate the largest IP packet that can traverse a path without fragmentation. The source initially uses an estimate based on the outgoing interface and available path information. When it receives a valid ICMP Fragmentation Needed message, it reduces its path MTU estimate and adjusts packetization accordingly. The resulting estimate may be cached, but its lifetime and update behavior depend on the implementation and network conditions; there is no universal cache-expiration interval.
TCP Maximum Segment Size (MSS) is related to, but distinct from, the path MTU. The MSS advertised in a TCP SYN indicates the maximum TCP data payload the advertising endpoint is prepared to receive. The sender must respect the peer's advertised MSS while also ensuring that the resulting IP packet fits the applicable path MTU. TCP MSS clamping can reduce the MSS advertised in connection-establishment traffic to accommodate a constrained path, but it does not replace PMTUD and does not generally prevent fragmentation of UDP or other non-TCP traffic.
Avoiding IP fragmentation improves reliability because IP does not independently retransmit lost fragments. If any required fragment is lost, the complete original datagram cannot be reconstructed, and recovery depends on the upper-layer protocol or application. TCP can retransmit data; UDP itself provides no equivalent retransmission mechanism. DF also requires careful interpretation in security investigations. An IPv4 datagram with DF=1, MF=0, and Fragment Offset zero is an atomic datagram: it is not fragmented. Under RFC 6864, its IP Identification value has no fragmentation-related significance and may contain an arbitrary value, including zero. However, DF does not make traffic immune to all packet-processing attacks, and it does not eliminate vulnerabilities unrelated to actual IP fragmentation.
IPv6 has no DF flag. Routers do not fragment packets in transit; only the source node can fragment an IPv6 packet, using the Fragment extension header. When a router cannot forward a packet because it exceeds the outgoing link MTU, it discards the packet and returns an ICMPv6 Type 2 (Packet Too Big) message containing the MTU of the constraining link.
RFC 8201 specifies IPv6 PMTUD. A source uses the reported MTU to revise its path estimate and reduce the size of subsequent packets or upper-layer messages. Nodes that do not implement PMTUD must use the IPv6 minimum link MTU of 1280 bytes as their maximum packet size, as specified by the standard. Implementations and applications may also use Packetization Layer PMTUD (PLPMTUD), which probes packet sizes at the transport or packetization layer rather than relying exclusively on ICMP delivery. Filtering ICMPv6 Packet Too Big messages can cause connectivity failures for traffic whose packet sizes exceed the actual path MTU. A TCP handshake may complete successfully while subsequent data transfer stalls because larger packets are discarded without the source receiving the necessary feedback.
PMTUD depends on receiving valid ICMP feedback unless another mechanism detects the packet-size constraint. When intermediate devices filter, suppress, or fail to deliver ICMP errors, oversized packets may be silently discarded. This condition is commonly described as a PMTUD black hole. For TCP, the symptoms may include repeated retransmissions, stalled data transfer, and a successful handshake followed by apparent loss of larger packets. These symptoms are suggestive, not conclusive: congestion, filtering, routing failures, and other packet-loss conditions can produce similar observations. Several mechanisms can mitigate these failures:
TCP MSS clamping: A gateway adjusts the MSS advertised in TCP connection-establishment packets to accommodate a known or conservatively estimated path constraint. This affects TCP packetization and does not solve general UDP PMTUD failures.
Packetization Layer PMTUD: PLPMTUD uses packet-size probes and transport-level evidence to discover usable packet sizes without depending exclusively on ICMP errors.
Implementation-specific TCP probing: Linux exposes
tcp_mtu_probing, which can enable TCP PLPMTUD when an ICMP black hole is detected or enable probing continuously, depending on its configured value. Its behavior should be verified against the deployed kernel and configuration.
These mechanisms do not justify assuming that every connection automatically discovers the correct MTU. Record the observed behavior, the available configuration, and the evidence supporting any attribution. The following observations may be consistent with normal PMTUD operation:
TCP SYN packets with DF set. This is common on modern systems but is not universal. Interpret the flag in the context of the operating system, network stack, and capture point.
ICMP Type 3 Code 4 or ICMPv6 Type 2 messages. Inspect the quoted packet, verify that it corresponds to traffic actually observed, and assess whether the reported MTU is plausible for the network path.
Reduced packet sizes after a valid error. A source that honors the revised PMTU should reduce packet sizes or adjust upper-layer packetization. The exact response depends on the protocol and implementation.
ICMP source addresses. The source address can help identify the reporting router or network segment. It does not necessarily establish the precise physical interface or hop responsible for the MTU constraint; verify the address against routing information and the capture vantage point.
Cached path-MTU behavior. Subsequent packets may remain smaller after the initial error because the source has retained a lower path estimate. The duration and scope of this behavior depend on the implementation.
The following observations warrant further investigation for a PMTUD failure, forged error, or inconsistent packet-processing behavior:
Successful handshake followed by repeated retransmissions of larger segments without visible ICMP feedback. This is consistent with a PMTUD black hole, but other causes of packet loss must be considered.
ICMP errors that quote no corresponding observed traffic. A mismatch may indicate spoofing, an incomplete capture, a different observation point, or a packet that was not captured. The absence of a matching packet is not, by itself, proof of forgery.
Implausible or unexpectedly low MTU values. Assess the reported value against the route, encapsulation overhead, interface MTUs, protocol requirements, and host-specific lower bounds. For example, Linux documents a default
min_pmtuvalue of 552 bytes in relevant kernel configurations; this is an implementation setting, not a universal IPv4 protocol minimum.Unexpected fragmentation after a Packet Too Big or Fragmentation Needed message. Determine whether the fragments were generated by the source, introduced elsewhere, associated with a different flow, or observed at a capture point affected by encapsulation or offloads. The sequence alone does not establish malicious activity.
Inconsistent PMTU behavior across repeated transmissions. Compare packet sizes, error messages, route changes, retransmissions, and endpoint configuration to distinguish path changes from implementation faults or potentially forged feedback.
Host-based packet captures may display packets larger than the interface MTU when segmentation or receive offloads are enabled. TCP Segmentation Offload (TSO), Generic Segmentation Offload (GSO), and Generic Receive Offload (GRO) can affect the packet boundaries visible to capture tools. Such observations do not, by themselves, establish an MTU violation or actual on-wire fragmentation. Document the capture interface, whether packets were captured before or after relevant processing, the tunnel state, and the applicable offload settings. Where necessary, compare host captures with an independent network-side capture to establish the packet sizes and fragmentation behavior present on the wire.
The forensic objective is to determine whether the observed packet-size behavior is consistent with the path MTU, whether the source responds appropriately to valid feedback, and whether any discrepancies can be explained by configuration, packet loss, capture artifacts, or manipulation. Anomalies should be recorded as observations first and attributed to a cause only when corroborating evidence supports that conclusion.
Fragment Offset and Payload-Range Validation
The IPv4 Fragment Offset field is 13 bits wide and expresses a fragment's starting position in units of eight bytes. The corresponding byte offset is calculated as:
Byte Offset = Fragment Offset * 8Because subsequent fragment offsets must be expressed in eight-byte units, the payload length of every non-final fragment must be divisible by eight. The final fragment is exempt from this alignment requirement and may carry a payload whose length is not a multiple of eight bytes.
The largest representable offset is 8191, corresponding to byte position 65,528. However, representability does not establish validity. The fragment's ending position, calculated as its byte offset plus payload length, must be consistent with the maximum size of the original datagram. For IPv4, the Total Length field limits the complete datagram to 65,535 bytes, including the original IP header. Therefore, the reconstructed payload must not exceed (65,535-H), where (H) is the original IPv4 header length in bytes. The offset is measured from the first byte of the original IP payload, immediately following the original IPv4 header, including any options. This payload is the fragmentable portion of the datagram and includes the transport header and application data. The first fragment has an offset of zero and ordinarily begins with the transport header. However, IP fragmentation operates independently of transport-header boundaries. A fragment can therefore contain only part of a TCP or UDP header, preventing a monitoring device from inspecting fields that fall outside the fragment's available bytes.
IPv6 also expresses the Fragment Offset in eight-byte units, but its offset is measured from the beginning of the fragmentable part of the original packet. The Fragment extension header precedes that data in each fragment. Extension headers that belong to the fragmentable part are carried within the fragment data, whereas headers preceding the Fragment header remain part of the unfragmentable portion. IPv6's extension-header structure must therefore be considered when reconstructing fragment boundaries and interpreting upper-layer protocol data.
Group fragments into a train by source, destination, protocol, and IP ID (IPv6: source, destination, and Fragment header identification). Derive each fragment’s payload length from header fields (IPv4: Total Length minus IHL × 4), never from frame length, since Ethernet padding and snaplen truncation distort it. For each fragment, calculate the byte range it claims to occupy:
Start = Fragment Offset x 8
End = Start + Payload Length Here, End is an exclusive boundary: a fragment covering bytes 0 through 7 has a start of 0 and an end of 8. Compare the resulting ranges across the candidate fragment train and validate them against the applicable protocol limits. Investigate the following conditions:
Gaps: Missing byte ranges indicate that the observed fragments do not provide complete payload coverage. A gap may reflect packet loss, incomplete capture, filtering, or an intentionally incomplete fragment sequence. A receiver cannot reconstruct the complete datagram while required bytes remain missing.
Overlapping ranges: Multiple fragments claim some or all of the same payload bytes. Record the exact intersection of their byte ranges and compare payload bytes within that itersection. Identical bytes usually indicate retransmission or duplicate capture (SPAN or tap mirroring) and are not by themselves anomalous. Differing bytes are the indicator, because implementations resolve them under different policies. This is a recognized class of evasion and malformed-packet behavior; the historical Teardrop attacks are an example of exploitation involving inconsistent fragment offsets and overlapping ranges.
Excessive reconstructed extent: The calculated ending position exceeds the payload size permitted by the applicable IP datagram limits. The calculated end exceeds the permitted payload size. For IPv4, subtract the original header length (including options) from the 65,535-byte Total Length limit. For IPv6, the unfragmentable extension headers plus the fragmentable part must fit within the 16-bit Payload Length (65,535). Jumbograms cannot be fragmented (RFC 2675), so a fragmented IPv6 packet with an apparent extent beyond that limit is malformed.
Invalid alignment: A fragment with MF=1 has a payload length that is not divisible by eight bytes. This violates the IPv4 fragment-alignment requirement and warrants validation of the raw packet and parser output.
Insufficient initial-fragment data: The first fragment contains too little of the transport header for a monitoring device to inspect the fields required by its filtering or detection rules. Tiny fragments can split transport-header fields across multiple fragments, creating opportunities for inspection evasion when a sensor does not reassemble the packet before applying policy.
Offset-one fragments: An IPv4 Fragment Offset of 1 means that the fragment begins at byte 8 of the original IP payload. This can split a TCP header across fragments and undermine simplistic filtering that assumes the initial fragment contains all relevant TCP fields. Offset 1 is valid and non-overlapping if the first fragment’s payload is exactly 8 bytes (the tiny-fragment case, which pushes the TCP flags byte into the second fragment). If the first fragment carries more than 8 bytes, the fragments overlap on bytes 8 onward (the RFC 1858 overlap case), and the reassembled flags depend on overlap policy.
The investigation should distinguish protocol violations from unusual but valid packetization and from artifacts introduced by incomplete capture or parsing. An anomalous fragment train is evidence of a packet-level condition, not proof of malicious intent. Preserve the raw fragments alongside any reconstructed datagram. Record the offset convention, payload-length interpretation, and reassembly behavior of the analysis tool. A reconstructed datagram represents the result of a particular implementation's processing policy; it does not independently establish how the destination host reassembled the traffic or what the destination ultimately received.
The IPv4 Total Length field is 16 bits wide, allowing a maximum datagram size of 65,535 bytes, including the IP header. The Fragment Offset field is only 13 bits wide because it shares a 16-bit word with three flag bits: the reserved flag, Don't Fragment (DF), and More Fragments (MF). Thirteen bits provide 8,192 possible values, from 0 to 8191, which would be insufficient to represent every byte position in a datagram of this size if the field counted individual bytes. IPv4 resolves this limitation by expressing the Fragment Offset in units of eight bytes. The fragment's starting byte position within the original IP payload is therefore Start = Fragment Offset * 8:
Equivalently, the encoded offset represents a byte position whose three least significant bits are implicitly zero. Converting the field to a byte offset is equivalent to shifting its value left by three bits. The largest representable starting position is 8191 * 8 = 65,528 bytes. This is the largest encodable position, not a guarantee that a fragment beginning there can form part of a valid IPv4 datagram. The original datagram's maximum payload depends on its header length, because the 65,535-byte Total Length limit includes the original IP header. The encoding has several consequences for forensic analysis.
- First, non-final fragments require eight-byte alignment. Every fragment with MF=1 must have a payload length that is a nonzero multiple of eight bytes. This ensures that the next fragment's starting position can be represented in the offset field. The final fragment, identified by MF=0 and a nonzero offset, is exempt from this alignment requirement and may contain a shorter payload, including a single byte, provided the complete datagram otherwise satisfies the protocol's constraints.
- Second, the representable offset range exceeds the valid datagram range. With a 20-byte original IPv4 header, the maximum original payload is 65,515 bytes. An offset of 8190 corresponds to byte position 65,520, beyond that limit. Therefore, offsets of 8190 and 8191 cannot identify valid payload positions in an ordinary IPv4 datagram. The offset field's numerical range must not be confused with the range permitted by the datagram-size limit.
- Third, offsets count payload bytes, not IP-header bytes. Offset zero identifies the beginning of the original IP payload, immediately after the original IP header, including any options. The payload includes the transport header and application data. Fragment boundaries are determined at the IP layer, independently of transport-header boundaries, so the initial fragment may contain insufficient bytes for a monitoring device to inspect the complete TCP or UDP header.
For each captured IPv4 fragment, calculate its payload length from its own IP header:
Payload Length = Total Length - (IHL * 4)Here, IHL is the Internet Header Length field, expressed in 32-bit words. Use the IP Total Length field rather than the captured Ethernet frame length, which may include link-layer headers, padding, or other bytes outside the IP datagram. Then calculate the fragment's claimed payload range:
Start = Fragment Offset x 8
End = Start + Payload LengthTreat End as an exclusive boundary. For example, a fragment starting at byte 16 with a payload length of 8 covers bytes 16 through 23 and has an ending boundary of 24. Validate the resulting ranges against the maximum permitted size of the original datagram. For a complete original IPv4 datagram, the reconstructed payload length cannot exceed (65,535 - H), where (H) is the original datagram's IP header length. Use the initial fragment's header length when establishing this limit; individual fragments can have different header lengths because IPv4 options that are not marked for copying need not appear in subsequent fragments. The following conditions warrant investigation:
Excessive fragment extent: The fragment's ending boundary exceeds the maximum permitted original payload length.
Invalid alignment: A fragment with MF=1 has a payload length that is zero or not divisible by eight.
Oversized reconstructed datagram: A terminal fragment implies an original datagram whose total size, including the original IP header, exceeds 65,535 bytes.
Inconsistent fragment coverage: Gaps, overlaps, or contradictory terminal boundaries prevent straightforward reconstruction and may indicate malformed traffic or implementation-dependent ambiguity.
Offset interpretation mismatch: The analysis tool reports an offset in eight-byte units while another tool or report interprets it as a byte position, or vice versa.
These findings should be documented as protocol anomalies or validation failures rather than automatically attributed to deliberate crafting. Incomplete captures, parser defects, malformed traffic, and deliberate evasion can produce overlapping investigative symptoms. Preserve the raw packets alongside any reconstructed datagram. Record the tool and version, the offset convention used in the output, and the header fields used to calculate each payload length. The resulting range analysis should be reproducible from the original capture and should distinguish representational limits from actual protocol violations.
Decoding IPv4 Fragmentation Fields
The IPv4 fragmentation fields occupy bytes 6 and 7 of the header, using zero-based byte offsets. Together, they form a 16-bit word in network byte order. The three most significant bits of byte 6 are the flags: 0x80 is the reserved flag, 0x40 is Don’t Fragment (DF), and 0x20 is More Fragments (MF). The remaining five bits of byte 6, selected by mask 0x1F, contain the five most significant bits of the 13-bit Fragment Offset; byte 7 contains its remaining eight bits. The raw offset is calculated as:
offset = ((byte6 & 0x1F) << 8) | byte7;This value is expressed in 8-byte units, so the fragment’s starting byte position within the original IP payload is offset × 8.
An IPv4 datagram is classified as a fragment when either MF is set, or the Fragment Offset is nonzero. In bitwise terms, the test is:
(word & 0x3FFF) != 0The mask excludes the reserved and DF bits while retaining MF and all 13 Fragment Offset bits. Equivalent filters include:
BPF capture filter:
ip[6:2] & 0x3fff != 0Wireshark display filter:
ip.flags.mf == 1 || ip.frag_offset > 0
A packet with MF cleared and offset zero is unfragmented, regardless of the DF setting. When DF is set and both MF and the offset are zero, the packet is often called an atomic or non-fragmented datagram in this context. This is common in PMTUD-aware IPv4 traffic, although DF alone does not prove that PMTUD is operating correctly. For a valid IPv4 fragment, MF and the Fragment Offset provide a basic positional classification:
| MF | Offset | Classification | Example word |
|---|---|---|---|
| 1 | 0 | Initial fragment | 0x2000 |
| 1 | Greater than 0 | Non-initial, non-final fragment | 0x20B9 (offset 185) |
| 0 | Greater than 0 | Terminal fragment | 0x0172 (offset 370) |
These examples illustrate the three positional categories. If they correspond to a particular worked example, verify each word against that example's fragment offsets and flag settings. This classification is positional, not temporal. MF indicates that the fragment is not the terminal fragment; it does not indicate whether another fragment has arrived or whether fragments are travelling in order. The terminal fragment may arrive before the initial fragment.
The two-byte field alone cannot establish whether fragments belong to the same original datagram or whether reassembly is complete. Correlate candidates using the source address, destination address, Protocol field, and Identification field. Then calculate each fragment's byte range using its offset and payload length, and check for missing ranges, overlaps, inconsistent terminal lengths, and other reassembly anomalies. A complete-looking set of ranges is not, by itself, proof that the receiver accepted or reassembled the datagram.
Anomalies to investigate
Reserved flag set (
0x80): RFC 791 specifies that this bit is reserved and must be zero. Its presence is a protocol anomaly that may result from malformed traffic, a faulty implementation, packet manipulation, or deliberate probing. It does not independently establish malicious intent.DF combined with fragmentation: DF set alongside MF or a nonzero Fragment Offset is contradictory under IPv4 fragmentation semantics and should be investigated as malformed or nonconforming traffic.
Inconsistent lengths: Compare the IPv4 Total Length with the header length and the bytes actually captured. If the captured frame is shorter than the IP datagram claims, determine whether the capture was truncated before concluding that the packet itself is malformed.
Inconsistent fragment sets: Gaps, overlaps, conflicting terminal-fragment information, or ranges extending beyond the maximum legal IPv4 datagram size can indicate malformed traffic or differences in how monitoring and endpoint systems handle reassembly.
IPv6 does not include IPv4-style fragmentation fields in its base header. Instead, fragmentation is indicated by the presence of a Fragment extension header, identified by Next Header value 44 in the preceding header. The Fragment header contains a 16-bit field comprising a 13-bit Fragment Offset, two reserved bits, and the M flag. The offset is also expressed in 8-byte units, and M serves a role analogous to IPv4 MF: M=1 indicates that more fragments follow, while M=0 identifies a terminal fragment. However, IPv6 fragmentation follows different rules: routers do not fragment packets in transit, and IPv6 reassembly behavior must be evaluated under IPv6-specific requirements. Apply the analogous positional logic without assuming that IPv4 validation rules transfer unchanged.
The output below represents the first packet in ipv4frags.pcap. The options suppress name resolution (-n) and timestamps (-t), print packet data in hexadecimal starting at the IP header (-x), and provide verbose IP-header details (-v). The verbose output reports IP Identification 46544, fragment offset 0, flags [+] (More Fragments set), protocol ICMP, and an IP total length of 996 bytes. The hexadecimal data supports the verbose interpretation:
Total Length: Bytes 2–3 contain
0x03e4, or 996 bytes. With a 20-byte IPv4 header, the fragment carries 976 bytes of IP payload.Flags and Fragment Offset: Bytes 6–7 contain
0x2000. The reserved and DF bits are clear, MF is set, and the offset is zero.Fragment position: MF=1 with offset zero identifies an initial fragment. It begins at byte zero of the original IP payload and ordinarily contains the beginning of the ICMP message, including its header.
ICMP fields: The ICMP header identifies an Echo Request with identifier
5058and sequence number1.Payload alignment: The 976-byte IP payload is divisible by eight (
976 / 8 = 122), satisfying the alignment requirement for a non-final IPv4 fragment.Checksums: The IPv4 header checksum can be validated independently for this fragment. The ICMP checksum covers the complete ICMP message, so it generally cannot be validated from this fragment alone when the message continues in subsequent fragments.
The observed IP datagram is 996 bytes, substantially smaller than the usual 1500-byte Ethernet MTU. This is worth investigating, but the size alone does not establish that a constrained link forced fragmentation. Possible explanations include:
The sending host or packet-generation tool deliberately selected a fragment size of 996 bytes.
The outgoing interface or path has an MTU smaller than 1500 bytes.
Encapsulation or tunneling reduces the effective packet size available to the inner datagram.
A device or implementation applied a fragmentation policy that produced this size.
Because MF is set, this fragment is not the terminal fragment. The original IP payload therefore extends beyond the 976 bytes carried here, but its total size cannot be determined from this packet alone.
If the next fragment continues immediately after this fragment's payload, its Fragment Offset should be 122, corresponding to byte position 122 × 8 = 976. If it is also non-final, its flags-and-offset word should be 0x207A:
MF remains set (
0x2000).Offset 122 is encoded as
0x007A.Combined word:
0x207A.
The subsequent packet should also have IP Identification 46544 and matching source address, destination address, and protocol to be a candidate for the same datagram. These fields should be checked together because the Identification field is not globally unique and may be reused. Consistent non-final fragment sizes can suggest a fixed fragment-size policy, but do not by themselves establish where fragmentation occurred. Different sizes may reflect sender behavior, a terminal fragment, or re-fragmentation along the path. Compare offsets, payload lengths, and byte ranges before drawing conclusions. TTL differences can provide additional context. Different values may be consistent with fragments taking different paths or originating from different sources, but they are not conclusive evidence of either. Account for capture location, routing, and packet-generation behavior before treating TTL divergence as suspicious.
Filter packets by IPv4 Identification:
tcpdump -nttvx -r ipv4frags.pcap 'ip[4:2] = 46544'This selects packets whose IPv4 Identification field equals 46544. It may also match unrelated datagrams that reuse that ID, so correlate the source, destination, and protocol fields when reconstructing the train.
Select all IPv4 fragments, including initial fragments and terminal fragments:
tcpdump -nttvx -r ipv4frags.pcap 'ip[6:2] & 0x3fff != 0'The mask selects packets with MF set or a nonzero Fragment Offset, excluding the reserved and DF bits. It therefore includes terminal fragments that would be missed by an MF-only filter.
This record represents the second fragment in the IPv4 fragment train. The Total Length field is 0x01c4, or 452 bytes. With a 20-byte IPv4 header, the fragment carries 432 bytes of IP payload. The flags-and-offset word is 0x007A. The MF flag is clear, and the Fragment Offset is 122 in decimal. Because the offset is measured in 8-byte units, the fragment begins at byte position:
122 × 8 = 976
A nonzero offset combined with MF=0 identifies this as a terminal fragment. Its payload covers byte positions 976 through 1407 of the original IP payload, giving an end position of 1408 bytes. If this fragment immediately follows the first fragment, which carried 976 bytes of payload, the two fragments account for the complete 1408-byte IP payload. This size is smaller than the maximum payload that can fit in a standard 1500-byte IPv4 MTU with a 20-byte header: 1480 bytes. Therefore, fragmentation was not required solely by a 1500-byte MTU constraint. A smaller effective MTU could explain the fragmentation, but so could a sender or packet-generation tool that deliberately selected a 976-byte first-fragment payload. The fragment sizes alone cannot distinguish these possibilities or establish that the traffic was crafted maliciously.
Because this is a non-initial fragment, it does not begin with the ICMP header. The IP Protocol field still identifies the payload as ICMP (1), but tcpdump may display ip-proto-1 rather than decoding ICMP message fields because the fragment does not contain the beginning of the ICMP message. The absence of a visible ICMP header here is expected and is not, by itself, an anomaly. To complete the analysis, correlate this packet with the first fragment using the source address, destination address, protocol, and Identification field. Then verify that the payload ranges are contiguous, that the terminal fragment's end position is consistent with the reconstructed datagram, and that no additional fragments or conflicting ranges are present.
This capture contains two IPv4 fragments with Identification 242, source address 10.1.1.1, destination address 129.111.30.27, and protocol UDP (17). The first fragment has offset 0 and MF set, while the second has offset 24 and MF clear.
The first IP datagram has a total length of 56 bytes. Subtracting its 20-byte IPv4 header gives a payload length of 36 bytes, covering byte positions 0–35 of the original IP payload. The second datagram has a total length of 24 bytes, leaving 4 bytes of payload after its IPv4 header. Its Fragment Offset is 24, which corresponds to byte position 24 × 8 = 192? No—the tcpdump output reports offset 24 in bytes or offset units depending on its display convention, so confirm the tool's exact output semantics before calculating the range. In standard tcpdump IPv4 fragment output, offset 24 denotes a byte offset, giving a range of bytes 24–27.
These ranges overlap: the second fragment covers bytes 24–27, which are already covered by the first fragment's bytes 0–35. The second fragment also has MF clear, marking it as the terminal fragment, even though its claimed end position is earlier than the end of the first fragment. This is an overlapping and inconsistent IPv4 fragment set. It should be treated as malformed or suspicious traffic and investigated in context. The capture alone does not establish whether the overlap was intentionally crafted or resulted from a faulty packet generator or network implementation. The pattern is historically associated with the Teardrop attack, which exploited flaws in some IP reassembly implementations. Such flaws could cause crashes when implementations handled overlapping fragment ranges incorrectly. Modern systems may reject or handle these fragments differently, so the presence of an overlap does not prove that a particular host is vulnerable or that a crash occurred. Overlapping fragments can also create an inspection-evasion risk. If a network sensor and the destination host resolve overlapping ranges differently, the sensor's reconstructed payload may differ from the payload processed by the endpoint. This can undermine IDS/IPS inspection and make packet-level evidence particularly important.
IPv6 has an explicit rule against overlapping fragments: under RFC 5722, a receiver must discard the entire reassembled packet when it detects overlap. IPv4 behavior has historically varied among implementations, so analysts should document the target operating system, reassembly behavior, and sensor configuration rather than assume all systems resolve overlaps in the same way.
For forensic validation, preserve the original capture, record each fragment's byte range, and compare the sensor's reassembly with the endpoint's behavior where possible. Correlate fragments using source, destination, protocol, and Identification, and avoid attributing malicious intent based solely on an overlap.
This walkthrough examines an ICMP Echo Request fragmented by the sending host's IPv4 layer. The original IP datagram is 4028 bytes: a 20-byte IPv4 header, an 8-byte ICMP header, and 4000 bytes of ICMP data. The original IP payload is therefore 4008 bytes. The egress interface has an MTU of 1500 bytes. The MTU limits the IP packet, including its IP header, and excludes the Ethernet header. Assuming a 20-byte IPv4 header with no options, each full-sized fragment can carry up to 1480 bytes of IP payload. Because 1480 is divisible by eight, it satisfies the alignment requirement for non-final fragments, whose payload lengths must be nonzero multiples of eight bytes.
The 4008-byte IP payload is divided into three fragments. All three share the same IPv4 Identification value and the same source address, destination address, and Protocol field.
Fragment 1: Initial fragment
Fragment Offset: 0
MF flag: Set
IP Total Length: 1500 bytes
IP payload: 1480 bytes
The payload contains the 8-byte ICMP header followed by the first 1472 bytes of ICMP data. Because this is the initial fragment, it contains the beginning of the ICMP message, including its Type, Code, Checksum, Identifier, and Sequence Number fields.
Fragment 2: Middle fragment
Fragment Offset: 1480 bytes, encoded as 185
MF flag: Set
IP Total Length: 1500 bytes
IP payload: 1480 bytes
The Fragment Offset field stores the offset in 8-byte units, so the encoded value is (1480 / 8 = 185). This fragment carries ICMP data bytes 1472–2951, inclusive. It does not contain the ICMP header because that header is at the beginning of the original IP payload.
Fragment 3: Terminal fragment
Fragment Offset: 2960 bytes, encoded as 370
MF flag: Clear
IP Total Length: 1068 bytes
IP payload: 1048 bytes
This fragment begins at byte 2960 of the original IP payload and carries the remaining ICMP data, bytes 2952–3999, inclusive. With MF cleared, it identifies itself as the terminal fragment. The resulting fragment layout is:
| Fragment | Payload offset | IP payload length | IP Total Length | MF |
|---|---|---|---|---|
| 1 | 0 | 1480 | 1500 | 1 |
| 2 | 1480 | 1480 | 1500 | 1 |
| 3 | 2960 | 1048 | 1068 | 0 |
| Total | — | 4008 | 4068 | — |
The three IP datagrams total 4068 bytes, which is 40 bytes larger than the original 4028-byte datagram. The difference comes from the two additional 20-byte IPv4 headers introduced by fragmentation. The ICMP checksum covers the entire ICMP message, including its header and data. It generally cannot be validated from an individual fragment; the complete ICMP message must first be reconstructed. IPv4 reassembly uses the source address, destination address, Protocol field, and Identification field to associate fragments with a datagram, while also validating their offsets and lengths.
This is a useful baseline for fragmentation under a 1500-byte MTU: two full-sized non-final fragments, a shorter terminal fragment, contiguous payload ranges, and no overlaps or gaps. These properties are consistent with straightforward fragmentation, but they do not prove that the traffic is benign. Investigate deviations in context. Examples include non-final fragments with payload lengths that are not multiples of eight, overlapping ranges, inconsistent terminal lengths, or gaps that prevent complete reassembly. Unequal non-final fragment sizes may reflect different fragmentation policies or re-fragmentation along the path; they are not, by themselves, evidence of malicious crafting. Likewise, fragmentation of a datagram that could fit within the observed interface MTU may result from sender configuration or fragmentation performed earlier on the path.
Generating a test packet
A 4000-byte ICMP data payload is larger than a typical ping and is used here to make the fragment train easy to observe. On Windows, the following command requests a 4000-byte ICMP data payload:
ping -l 4000 192.168.11.3The Windows -f option sets the Don't Fragment (DF) flag. If the packet exceeds the usable path MTU, it will generally fail rather than be fragmented by an intermediate router.
On Linux and macOS, the corresponding payload-size option is typically:
ping -s 4000 192.168.11.3However, fragmentation behavior depends on the operating system, ping implementation, socket settings, and path-MTU-discovery configuration. Verify the actual flags and fragment train in the capture rather than assuming that the command will necessarily produce three fragments.
IPv4 fragmentation occurs in the sending host's IP networking stack or at another point along the path where fragmentation is permitted. A capture taken on the sending host may show the original large packet, the resulting fragments, or a representation affected by capture placement and offload behavior. NIC offloads and packet-capture mechanisms can therefore affect what appears in the trace. When validating this example, compare the observed IP Total Length, Fragment Offset, MF flag, and payload ranges rather than relying on the ping command alone.
The output above contains two candidate fragments of an IPv4 datagram with Identification 46544, from 2.1.1.2 to 2.1.1.1. Confirm that both packets share the same source address, destination address, protocol, and Identification value before treating them as one fragment train.
The first fragment has offset 0 and flags [+], indicating that More Fragments (MF) is set. Its IP Total Length is 996 bytes: a 20-byte IPv4 header and 976 bytes of IP payload. Because this is the initial fragment, it contains the beginning of the ICMP message. tcpdump can therefore decode the ICMP Echo Request fields: Type 8, Code 0, identifier 5058, and sequence number 1. The displayed length 976 refers to the ICMP message carried in this fragment, including the 8-byte ICMP header. Consequently, the fragment contains 968 bytes of ICMP data. The remaining ICMP data is carried by the subsequent fragment.
The second fragment has a displayed offset of 976 and flags [none]. Neither MF nor DF is set. Because the offset is nonzero and MF is clear, this packet is identified as a terminal fragment. Its IP Total Length is 452 bytes: a 20-byte IPv4 header and 432 bytes of IP payload. It does not begin with the ICMP header, so tcpdump cannot decode it as an independent ICMP Echo Request. Instead, it displays the IP protocol as ip-proto-1, indicating ICMP (IP Protocol number 1). tcpdump displays the fragment offset in bytes. On the wire, the 13-bit IPv4 Fragment Offset field stores units of eight bytes. The displayed byte offset of 976 corresponds to the encoded value:
976 / 8 = 122 (0x007a)
This places the second fragment immediately after the first fragment's 976-byte IP payload, assuming the two packets belong to the same datagram. The two payload lengths add up to:
First fragment: 976 bytes
Second fragment: 432 bytes
Reconstructed IP payload: 1408 bytes
Subtracting the 8-byte ICMP header leaves 1400 bytes of ICMP data. Adding the original 20-byte IPv4 header gives a reconstructed IPv4 datagram size of 1428 bytes.
That size fits within a 1500-byte Ethernet MTU, so a 1500-byte MTU alone would not require this datagram to be fragmented. However, the observation does not establish why fragmentation occurred. Possible explanations include a smaller effective MTU elsewhere along the path, intentional fragmentation by the sender or a packet-generation tool, or deliberately crafted traffic. To distinguish these possibilities, examine the complete fragment set, confirm the capture location, and review the sender's interface MTU and fragmentation configuration. Also account for capture placement and offload behavior. The two records are consistent with a 1408-byte IP payload, but the capture alone does not prove the cause of fragmentation or guarantee that the receiver successfully reassembled the datagram.
Wireshark displays the same fragment train with IP Identification 0xb5d0 (decimal 46544). With IPv4 reassembly enabled by default, Wireshark associates the fragments and presents the reassembled ICMP message in the frame where reassembly completes. Frame 1 contains the initial fragment, with offset zero and MF set. Wireshark identifies it as:
Fragmented IP protocol (proto=ICMP 1, off=0, ID=b5d0)
It also provides a reference to the frame where reassembly completes. Frame 2 contains the terminal fragment. Wireshark labels this frame as an Echo (ping) request because the complete ICMP message becomes available after this fragment arrives and reassembly succeeds. This display can be misleading if the analyst assumes that the frame carrying the ICMP label must physically contain the ICMP header. In this example, the ICMP header is physically present in frame 1, while Wireshark presents the decoded, reassembled ICMP message in frame 2. The frame associated with the reassembled message is the frame that completes reassembly—not necessarily the frame with the highest offset or the terminal fragment in every capture. If fragments arrive out of order, whichever required fragment arrives last may complete reassembly. Consequently, the timestamp associated with the decoded message corresponds to the completion frame's capture timestamp, not the arrival time of the initial fragment.
Within frame 2, the IPv4 layer describes the fragment itself:
Total Length: 452 bytes
Identification:
0xb5d0(46544)Flags:
0x00, with MF clear and DF clearFragment Offset: 976 bytes, as displayed by Wireshark
The raw Fragment Offset field stores the offset in 8-byte units. The displayed byte offset of 976 corresponds to a raw field value of 122 decimal, or 0x007a.
Wireshark also displays an entry similar to:
[2 IPv4 Fragments (1408 bytes): #1(976), #2(432)]
This summarizes the reassembly: two fragments contribute 1408 bytes of IP payload, with 976 bytes from frame 1 and 432 bytes from frame 2. The ICMP protocol details shown below the reassembled IPv4 information are decoded from this reconstructed payload. The packet-list Length column reports the captured frame length, including the 14-byte Ethernet header in this example. Therefore, the displayed length of 466 bytes is consistent with a 452-byte IPv4 datagram plus a 14-byte Ethernet header, assuming no additional captured link-layer bytes such as an FCS.
Wireshark and tcpdump present different views of the same packet data. Wireshark can reassemble fragments and decode the resulting ICMP message, whereas the tcpdump output used in this walkthrough reports individual fragment details without presenting the same reassembled protocol view. To inspect individual fragments in Wireshark, disable Reassemble fragmented IPv4 datagrams in the IPv4 protocol preferences. The corresponding preference setting is named ip.defragment. For forensic work, distinguish three things:
Captured frame: The bytes recorded for an individual packet.
Fragment interpretation: The offsets, flags, lengths, and relationships inferred from the IPv4 headers.
Reassembled datagram: The reconstructed payload produced by the analysis tool.
Neither tool's decoded view should automatically be treated as ground truth for the destination host's behavior. Reassembly implementations can differ, particularly when fragments overlap, conflict, or arrive incomplete. When fragment structure is important, inspect the raw packet bytes and validate the header fields, payload ranges, and reassembly assumptions.
IPv4 fragmentation changes a small set of IP header fields while preserving the original IP payload. Understanding which fields change—and which remain consistent—is essential when validating fragments and reconstructing datagrams during a forensic investigation.
IP header fields that change
Total Length describes the size of an individual IP datagram, including its IP header and payload. During fragmentation, each fragment receives its own Total Length value, calculated as its header length (IHL × 4) plus the payload bytes carried by that fragment.
The Flags and Fragment Offset fields describe the fragment's position within the original IP payload. The More Fragments (MF) flag is set on non-terminal fragments and cleared on the terminal fragment. The Fragment Offset is expressed in 8-byte units relative to the beginning of the original IP payload.
Because fragmentation changes header fields, the IPv4 Header Checksum must be recalculated for each fragment. It covers the IPv4 header only, not the payload. The checksum is also updated at each router hop that changes a covered header field, such as TTL.
The Identification value is normally copied into every fragment of the original datagram. It helps the receiver associate fragments during reassembly, but it is not unique across all traffic and must be considered alongside the source address, destination address, and Protocol field.
IPv4 options and header length
IPv4 options introduce an additional detail. Options whose copy flag is set are copied into all fragments; options whose copy flag is clear are included only in the initial fragment. Consequently, fragment headers can have different lengths. When calculating a fragment's payload length, use that fragment's own header length:
IP payload length = Total Length − (IHL × 4)
Do not automatically subtract 20 bytes unless the fragment's IHL confirms a header without options.
Fragmentation does not, by itself, alter the original TCP, UDP, or ICMP message. Therefore, the transport checksum carried in the original message retains its value, provided no other operation modifies the message or its checksum-covered fields. The transport header normally begins in the initial fragment, whose Fragment Offset is zero. In ordinary fragmentation, the complete transport header is present there. However, IP does not guarantee that a fragment boundary aligns with the end of the transport header. Deliberately small initial fragments can split a TCP, UDP, or ICMP header across fragments, a technique associated with tiny-fragment evasion.
Transport checksums cover the relevant transport message, including data distributed across subsequent fragments. They generally cannot be validated independently from one fragment; the complete message must first be reassembled. A checksum that appears invalid when only an individual fragment is examined is not, by itself, evidence of an anomaly. If the checksum still fails after reassembly, investigate possible causes before drawing conclusions. These include incomplete or incorrect reassembly, packet corruption, capture artifacts associated with checksum offload, and legitimate rewriting by NAT or another middlebox. The effect of rewriting depends on the protocol and the fields changed: for example, changing an IPv4 address affects the TCP and UDP checksum because their pseudo-header includes IP addresses.
When analyzing fragmented IPv4 traffic:
Compare Identification, source address, destination address, and Protocol to identify candidate fragments.
Calculate each fragment's payload length from Total Length and its own IHL.
Convert each Fragment Offset from 8-byte units to a byte position.
Verify fragment ranges, alignment requirements, terminal-fragment consistency, and any gaps or overlaps.
Validate each IPv4 header checksum independently, accounting for capture artifacts where relevant.
Reassemble the complete transport message before evaluating its checksum.
Corroborate checksum failures with raw packet bytes, capture location, offload settings, and any known network rewriting.
These checks help distinguish normal fragmentation from malformed traffic and avoid treating limitations of a packet analyzer as proof of malicious activity.
Fragmentation can occur even when a packet fits within the MTU of the hosts' apparent network path. A common example is an IPsec VPN tunnel, where encapsulation adds overhead that increases the size of the packet transmitted across the underlying network. Consider a server-side VPN gateway forwarding traffic to a user's workstation. The gateway receives a 1500-byte IPv4 packet and encapsulates it using IPsec ESP in tunnel mode. The encapsulated packet includes an outer IP header, an ESP header, an initialization vector or nonce as required by the selected algorithm, padding, an ESP trailer, and an integrity check value when authentication is provided by the selected ESP transform. The added overhead depends on the IP version, cryptographic algorithms, alignment requirements, and tunnel configuration. NAT traversal adds further overhead because ESP is encapsulated in UDP. As a result, the outer packet can exceed the 1500-byte MTU of the underlying link even though the original inner packet was 1500 bytes.
How the gateway handles the oversized packet
The outcome depends on the outer packet's Don't Fragment (DF) setting, the gateway's configuration, and the applicable IPsec processing rules. Under RFC 4301, an IPsec implementation must support configuring whether the outer IPv4 DF bit is set, cleared, or copied from the inner packet for a tunnel-mode security association. The implementation's behavior therefore matters when diagnosing fragmentation. Two principal fragmentation approaches are possible:
Fragment before encapsulation: The gateway divides the inner IP packet into smaller fragments before applying IPsec. Each fragment is then encapsulated separately, producing its own outer IP header and ESP packet.
Fragment after encapsulation: The gateway first creates the outer ESP packet and then fragments that outer IP packet to fit the outgoing link. Only the first outer fragment contains the beginning of the ESP payload; the receiving gateway must reassemble the outer packet before processing the complete ESP packet.
These approaches produce different packet-capture evidence. When fragmentation occurs before encapsulation, the inner fragments are protected separately. When fragmentation occurs after encapsulation, the outer fragments must be reassembled before the ESP payload can be processed. If the gateway cannot forward an oversized packet because DF is set, it should return an appropriate ICMP error when required. For IPv4, this is Destination Unreachable, Type 3, Code 4 (fragmentation needed and DF set). If the necessary ICMP feedback is filtered or otherwise fails to reach the sender, Path MTU Discovery (PMTUD) can fail. This is known as a PMTUD black hole: small exchanges may succeed while larger transfers stall or repeatedly retransmit.
Why fragmentation can reduce reliability
IP fragmentation introduces additional failure points. If a required fragment is lost, the receiver cannot reconstruct the original IP datagram. IP itself does not retransmit individual fragments; recovery, when available, must occur at a higher layer, such as TCP, or through application-level retry logic.
Fragmentation can also complicate packet filtering. Non-initial IPv4 fragments do not contain the beginning of the transport header, so they do not independently expose TCP or UDP port numbers. Stateless filters and some NAT or firewall implementations may therefore drop fragments they cannot associate with an existing flow. Stateful devices may handle them correctly, but behavior varies by implementation and configuration.
Mitigations
1. Reduce the effective MTU
A network administrator can configure a smaller interface MTU or advertise an appropriate MTU to hosts. DHCPv4 option 26 communicates an interface MTU to supporting clients, while IPv6 Router Advertisements can advertise a link MTU. This can help hosts generate packets that fit the tunnel's effective capacity, but it is not a universal solution: clients may not honor the setting, and a value that is too conservative wastes capacity on traffic that does not traverse the tunnel. The appropriate value depends on the encapsulation overhead and the actual path MTU.
2. Use TCP MSS clamping
A VPN gateway can adjust the Maximum Segment Size (MSS) option in TCP SYN packets that pass through it, including the SYN-ACK direction where appropriate. This encourages the endpoints to send smaller TCP segments. MSS specifies the maximum TCP data payload in a segment, excluding the IP and TCP headers. The clamp value should account for the effective path MTU and the relevant header sizes. The technique depends on the gateway seeing and correctly processing the TCP handshake, and it does not automatically solve every PMTUD problem. MSS clamping applies to TCP only. It does not directly constrain UDP datagrams used by applications such as DNS or UDP-based NFS, and it does not directly control QUIC's UDP datagram size.
What about QUIC?
QUIC operates over UDP and has its own packetization and path-MTU mechanisms. RFC 9000 specifies that QUIC UDP datagrams must not be fragmented at the IP layer and requires support for a maximum datagram size of at least 1200 bytes. QUIC implementations can use PMTUD or Datagram Packetization Layer PMTU Discovery (DPLPMTUD) to determine whether larger datagrams can traverse a path without fragmentation. In IPv4, QUIC implementations are required to set DF when possible to prevent IP-layer fragmentation. Therefore, an MTU problem can manifest as lost datagrams, retransmissions at the QUIC packet level, reduced throughput, or a connection that stalls or fails if no usable path can be found. It does not necessarily produce visible IP fragments.
When investigating suspected fragmentation caused by VPN encapsulation, compare captures from both sides of the tunnel where available. Look for differences between inner and outer packet sizes, the presence of ESP or UDP-encapsulated ESP, fragment offsets and flags, ICMP fragmentation-needed messages, and repeated transport-level retransmissions. Also establish whether fragmentation occurred before or after encapsulation. That distinction determines which headers are visible in each fragment and where reassembly must occur. A capture from only one side of the tunnel may not reveal the complete sequence, so correlate packet sizes, timing, tunnel configuration, and MTU settings before attributing the behavior to a specific device.
Post a Comment