Introduction

A packet can be broken into smaller pieces, or fragments, at the network layer (by the IPv4 and IPv6 protocols) to fit within a specific Maximum Transmission Unit (MTU). For IPv4, a packet’s fragmentation and reassembly are managed by the IPv4 Identification Field, along with the More Fragments (MF) and Fragment Offset (FO) flags. In contrast, IPv6 handles fragmentation and reassembly using a dedicated Fragment extension header. This header is a fixed 8 bytes and contains similar fields and flags to IPv4’s, but with a larger size.

With release version 2.0, PacketSmith added the capability to detect and reassemble fragmented IPv4 and IPv6 packets. Packet reassembly is enabled by default and could be disabled by setting the command line option flag “—upd_ip_lyr ip_frag_disable”. By default, IP packet reassembly happens in-memory, where only the actual fragmented packet is reconstructed and dissected to account for the reassembled payload while the rest of the IP fragments are left intact. For IPv6 reassembled fragmented packets, even the fragmentation extension is ripped off. 

Reassembly

PacketSmith IP reassembly engine provides the capability to save reassembled and fully reconstructed packets to the output pcap. It works by deleting all the IP packets fragments for a given fragmented packet, and retaining only the reassembled and fully reconstructed and dissected packets to the output pcap.  This functionality is provided via the command line option flag “—upd_ip_lyr ip_frag_perm”. 

All incomplete and invalid fragment buckets are discarded. For IPv6 atomic fragments, PacketSmith treats them as non-fragmented packets. Additionally, duplicate/retransmitted fragments are discarded during the reassembly phase. 

Technicalities

To track IP fragmented packets, you need a map that groups related fragments together. This map uses a custom hash function to create a unique key for each set of fragments. The key is a hash of three values:

• Source IP address
• Destination IP address
• IP identification number (For IPv6, this is a 32-bit integer retrieved from the fragment extension header)

This ensures that all fragments belonging to the same packet—sharing the same source and destination IP (bi-directional) and identification number—are sorted into the same bucket by offset.

To check if a fragment bucket is complete, we need to introduce the following three definitions/conditions:

• Is first fragment?
  • MF = 1 && FO = 0 
• Is middle fragment?
  • MF = 1 && FO > 0
• Is last fragment?
  • MF = 0 && FO > 0

For IPv4, if a fragment bucket is less than 2 packets, then the bucket is discarded and treated as incomplete. If it is just 2 packets, then we enforce completeness by checking for the first and last fragments conditions. If the bucket contains more than 2 packets, then, we exercise all of the above conditions for completeness.

What happens in case of packet re-transmission (duplicate packets)? If a duplicate exists with the same FO, Fragment Length (FL) and Fragment Data (FD), then we simply discard of that packet from the bucket (or ignore it depending on the implementation).

To reassemble a packet from a bucket of fragments, the first fragment is used as the base. The data from the remaining fragments is added to it, and the resulting packet is then fully reconstructed and dissected. During this process, the IP layer is properly calibrated, and the frame’s original and captured lengths are updated to reflect the complete packet.

Incorrect IP Fragmentation/Reassembly

Some tools don’t follow the IP protocol’s standard for creating unique IP identification numbers, making it difficult to properly distinguish between fragments from different datagrams.

For example, the following hping3 command hping3 -S -p 80 <target_ip_address> -d 2000, produces different SYN IPv4 fragmented packets, all with the same IPv4 identification number. The following screenshot illustrates how the IPv4 ID number is the same for different fragment buckets.

The pcap (size: 904 bytes) is attached herein for reference.

This behavior is in violation of the RFC 791, which states the following:

• “The receiver of the fragments uses the identification field to ensure that fragments of different datagrams are not mixed.“.
• “The identification field is used to distinguish the fragments of one datagram from those of another. The originating protocol module of an internet datagram sets the identification field to a value that must be unique for that source-destination pair and protocol for the time the datagram will be active in the internet system. The originating protocol module of a complete datagram sets the more-fragments flag to zero and the fragment offset to zero.“.

Since the fragment bucket is incomplete, PacketSmith will reject the reassembly attempt. You will see the following warning printed in the console:

an incomplete fragment bucket was found and removed (key: ip.src: 192.168.2.16 -> ip.dst: 192.168.1.200 – id: 0068 – proto: 06)

We can use a heuristic approach to address this issue by grouping fragments based on their timestamps. For example, as seen in Figure 1, if fragmented packets arrive approximately every second, the parser can use this timing to sort them into separate buckets.

Another method is to process fragmented packets in the correct timestamp order as they’re read. By checking for the presence of first, middle, and last fragment definitions, the parser can accurately mark a fragment bucket as complete. PacketSmith does not implement any of those heuristics and instead follows the standard’s guidelines. We might add those heuristics to PacketSmith in future versions, if deemed necessary.

Case Study

To permanently save reassembled IPv4/IPv6 fragmented packets, use the following PacketSmith command line options:

PacketSmith.exe —infile <in_pcap>.pcap —outfile <out_pcap>.pcap —upd_ip_lyr ip_frag_perm

IPv4 Reassembly

Take the following attached pcap ipv4_icmp_fragmented_pkts which contains a fragmented IPv4 ICMPv4 packet, consisting of 3 fragments, frames 3 to 5. The ICMPv4 IPv4 reassembled packet is attached in this pcap icmpv4_ipv4_reassembled (with the checksum fixed by passing the option —checksum).

The following message is printed to the console:

total deleted frames due to “permanent” IPv6 fragmentation re-assembly: 0
total deleted frames due to “permanent” IPv4 fragmentation re-assembly: 2

the pcap “icmpv4_ipv4_reassembled.pcap” was written successfully to disk

IPv6 Reassembly

Take the following pcap “packet too big.pcap” (size: 10,628 bytes), hosted on cloudshark.org. It contains ICMPv6 fragmented packets (10 frames).

It contains 4 fragmented packets, and an “invalid” fragment bucket, consisting of one packet (packet #6). The “invalid” fragmented packet fragment header consists of the following flags, MF = 0, FO > 0 and identification number 0x5c277495. This packet will be discarded during IPv6 reassembly because it is “incomplete”.

The pcap with the reassembled IPv6/ICMPv6 fragmented packets is ipv6_icmp_reassembled (with the checksums fixed).

The following message is printed to the console:

an incomplete fragment bucket was found and removed (key: ip.src: 2001:0db8:0002:0000:0000:0000:0000:0002 -> ip.dst: 2001:0db8:0001:0000:0000:0000:0000:0001 – id: 5c277495 – proto: 3a)
total deleted frames due to “permanent” IPv6 fragmentation re-assembly: 4
total deleted frames due to “permanent” IPv4 fragmentation re-assembly: 0

Figure 3 shows the reassembled packets:

Conclusion

This article demonstrated PacketSmith’s ability to detect and reassemble IPv4/IPv6 fragmented packets using real-world examples. We also provided insight into how PacketSmith handles incomplete or invalid fragments. A key takeaway is PacketSmith’s unique feature that allows you to permanently save reassembled packets to a pcap file.

Author: Mohamad Mokbel (Netomize)

First release: August 26, 2025