How Are IPv4 Fragments Put Back Together? IDs, Offsets and Reassembly

Information sent by a controller does not always arrive as one complete IP datagram. Sometimes it is divided into fragments. How does the receiver recognize which pieces belong together and where each belongs? What happens if one never arrives? To understand IPv4 fragmentation, separate Ethernet switching, IP routing and receiver reassembly.

First distinguish an IP datagram from an Ethernet frame

Controllers, gateways and servers exchange data over links. An IP datagram is carried in an outer encapsulation suited to the current link; on Ethernet it travels inside an Ethernet frame. Frames pass between neighboring devices, while IP addresses help identify the network-layer destination. These layers have different headers and length limits.

An interface’s IP maximum transmission unit, or MTU, limits the size of an IP packet sent through it. A route between subnets can cross several IP interfaces with different limits. A packet that fits upstream does not necessarily fit the next hop. This guide focuses on fragment fields and reassembly, not on suggesting that every large-packet failure is caused by fragmentation.

When can fragmentation occur?

An IPv4 sender may fragment before transmission. A router that forwards IPv4 can also divide a packet into smaller fragments if the packet exceeds the next-hop MTU and fragmentation is permitted. Each fragment has its own IP header and carries part of the original IP payload.

If the original datagram has its DF, or Don’t Fragment, flag set and must pass through a smaller next-hop MTU, the router cannot simply split it. It normally drops the packet and returns an appropriate ICMP error; actual feedback depends on devices and filtering. Whether the sender adjusts its packet size depends on the protocol and implementation.

An ordinary Layer 2 industrial switch forwards Ethernet frames; it does not split an oversized IPv4 datagram into IP fragments. A device with routing capability may process IP traffic differently depending on its interfaces, configuration and actual path. The word switch or gateway on an enclosure does not establish the behavior of every port.

How does the receiver recognize related fragments?

An IPv4 fragment header includes source and destination addresses, protocol and identification. The receiver uses these fields together to associate fragments with the original datagram. The identification field primarily supports fragmentation and reassembly; do not treat it as a permanently unique global serial number for every packet.

Think of a long document divided into pages: a batch label and recipient information help group the pages. The analogy has limits. Network devices use packet fields and reassembly rules rather than understanding the document, and an ID is not authentication or a security mechanism.

Sender, router and receiver captures may show different perspectives. Do not group fragments using an ID alone or combine captures from different directions and locations without context. First establish capture point, time, IP addresses and protocol; then examine fragment fields.

What do the offset and MF flag tell us?

The fragment offset identifies where the fragment’s payload belongs in the original IP payload. It is expressed in units of eight bytes, not as an Ethernet frame byte number. The receiver uses offsets to put pieces in position rather than simply joining them in arrival order. A later fragment can arrive first.

MF means More Fragments: a non-final fragment normally has MF set to 1, while the final fragment has MF set to 0. Seeing MF = 0 reveals the end of the datagram; it does not prove all earlier pieces arrived. The receiver must still have complete coverage from the beginning to the end before passing the reassembled payload onward.

Fragmentation also follows an alignment rule: except for the final fragment, fragment payload lengths normally must be multiples of eight bytes. Operators need not calculate every binary field by hand, but should check whether a capture tool displays the raw offset field or an already converted byte position.

What if a piece is lost?

The receiver typically retains temporary reassembly state and waits for missing fragments. If the datagram remains incomplete when that state times out, it is discarded; an application normally cannot use the remaining fragments as a complete IP datagram. Buffer limits, timeout handling and security policies vary by system, so generic explanations do not establish a particular product’s values.

More fragments mean more independently transmitted pieces for one datagram. A missing piece can prevent the whole datagram from being reassembled. This makes the complete path and each fragment relevant, but a large-packet failure alone does not prove fragment loss: congestion, filtering, device load and other link problems may look similar.

Whether TCP or an application retries is a higher-layer matter and depends on the protocol and implementation. IPv4 fragmentation itself does not provide a general per-fragment reliable retransmission mechanism. An application using UDP should not assume IP will automatically replace missing payload.

What should an investigation record?

In an authorized test environment, first map the sender, Layer 2 switches, routing interfaces, tunnels and receiver. Record interface MTUs, the DF setting, protocol, capture location and time. For each suspected fragment group, inspect source and destination addresses, protocol, identification, offset and MF instead of looking only at packet length.

If the sender shows a complete datagram and the router’s outgoing interface shows several fragments, check the IP forwarding and interface MTU. If all fragments leave that interface but only some reach the receiver, investigate loss or filtering along the actual path. Mirroring configuration, network-interface offload and capture position can affect what is visible; one screenshot is not the whole network.

Also consider how security devices handle fragments. Some rules inspect transport-layer ports, yet a non-initial fragment normally does not contain the complete transport header. How a device correlates state and whether it permits fragments depend on its implementation and rules. The first fragment passing does not prove that every fragment passed. Save the existing configuration and coordinate changes with the people responsible for operational safety and security.

If reassembly repeatedly fails, investigate path MTU, packet loss and filtering before merely extending receiver wait times. Real-time and completeness-sensitive applications may have different constraints. Decide on changes using protocol design, equipment documentation and controlled tests.

For production control, have the site owner approve the test window and scope. Do not disable a firewall, enlarge frame sizes or enable routing without understanding the effect and a rollback plan. Confirm protocol support and network boundaries before testing a limited change.

Keep the stages separate

IPv4 fragmentation is a network-layer mechanism. The receiver uses addresses, protocol, identification, offsets and MF information to reassemble a datagram. Pieces may arrive out of order, but the datagram must be complete and satisfy the receiver’s rules before delivery upward. MTU, IP routing, switch frame limits and application retry belong to different stages and need separate evidence.

FCTELE industrial switches and gateways can form part of industrial Ethernet networks. Whether a specific product and firmware support IP routing, interface MTU settings or filtering must be checked against its documentation. These illustrations explain general mechanisms; they do not represent a measurement or internal circuit of a particular FCTELE model.

Translated from the Chinese technical article: Read the original Chinese article.