Summary

  • An IPv4 receiver can allocate reassembly state from any fragment. Later pieces may consume memory and reveal the final length even when the zero-offset fragment never arrives.
  • RFC 1122 requires incomplete state to be discarded when its timer expires, but requires ICMP Time Exceeded Code 1 only if fragment zero was received and its original header was saved.
  • The resulting silence is ambiguous by design. It may mean fragment zero was missing, the error was suppressed or lost, or the implementation behaved differently; it cannot prove that no reassembly failed.

A buffer can know that it failed without being able to testify

Imagine that a receiver sees three pieces of one IPv4 datagram. Their source, destination, protocol and Identification values agree, so the receiver places them in one reassembly context. One piece carries the More Fragments flag cleared, revealing where the datagram should end. The offsets leave gaps. There is enough information to know that the set is incomplete, and enough data to occupy memory, but no piece begins at offset zero.

Nothing in the reassembly mechanism requires fragments to arrive in numerical order. The last can precede the first. A middle piece can be the first packet observed. Loss can remove only the beginning while every later piece reaches the destination. The receiver therefore needs two kinds of state: the bytes that have arrived and the description of what is still absent.

When the waiting interval expires, the receiver has a definite local fact: this context did not become a complete datagram in time. IPv4 does not let that fact keep memory forever. The partial entity must be destroyed. Yet destruction and notification are different operations. The first protects the receiving system. The second constructs evidence for a remote sender, and the evidence contract has a stricter precondition.

That precondition is fragment zero.

Reassembly begins with identity, not with the first byte

RFC 791 identifies a reassembly buffer by four values: source address, destination address, upper-layer protocol and the 16-bit Identification field. A fragment's offset tells the receiver where its data belongs. Offset zero marks the first fragment; a cleared More Fragments flag marks the last. Those two facts can arrive in different packets.

The example procedure is explicit. If a fragment belongs to no existing context, the receiver allocates reassembly resources. It copies the data into the position indicated by the offset and marks the corresponding blocks as present. Only when FO = 0 does it place the header into a separate header buffer. Only when a fragment has MF = 0 can it calculate the total data length. Completion requires both a known end and an unbroken set of received blocks from the beginning to that end.

This makes fragment zero special without making it chronologically first. A later fragment can open the context. The final fragment can define the target length. Neither supplies the original datagram's beginning. Reassembly state is therefore allowed to exist before the receiver possesses the material it would use to describe the original packet back to its source.

The distinction matters because partial state has real cost. RFC 791's example allocates a data buffer, header buffer, received-block table, total-length field and timer. A fragment does not merely leave a statistic. It makes a claim on finite memory until the whole arrives or the receiver gives up.

The first timer borrowed a clock from TTL

The 1981 specification tied the reassembly timer to the arriving fragments' Time to Live values. It proposed a 15-second initial lower bound. Whenever another fragment arrived, the timer became the maximum of its current value and that fragment's remaining TTL. A smaller TTL could not shorten the wait; a larger one could extend it, potentially toward the field's maximum.

The text also states the resource equation directly: data rate multiplied by timer value equals buffer capacity. That is not an implementation footnote. It reveals the policy hidden inside a timeout. A longer wait tolerates delayed fragments but lets incomplete contexts occupy memory for longer. A shorter wait releases memory faster but can destroy a datagram whose missing pieces were merely delayed.

The original design treated TTL as if it could contribute elapsed-time evidence. Deployment made that assumption increasingly weak. Routers commonly decremented TTL as a hop count, not as a precise measure of seconds spent in the network. A receiver that derived its waiting policy from the remaining field would therefore mix path length with time and obtain a value that did not reliably describe either.

ICMP made the beginning the evidence anchor

RFC 792 defined ICMP Time Exceeded Type 11. Code 0 reports TTL expiry in transit. Code 1 reports fragment reassembly time exceeded at a host. The message includes the original IP header and the first 64 bits of original data, which the specification expected would help the source associate the failure with an appropriate process.

That quote is about the original datagram's beginning, not whatever later fragment happened to arrive last. The same RFC establishes the general rule that ICMP errors concern errors in handling fragment zero. For reassembly specifically, it says a host may send Time Exceeded after missing fragments prevent completion within the time limit, but if fragment zero is unavailable no such report need be sent.

Later fragments are not anonymous. Their IPv4 headers still carry the fields needed to find the reassembly context. The rule is narrower: a nonzero fragment is not accepted as a substitute invoking packet for an ICMP error. Without fragment zero, the receiver lacks the protocol-approved original beginning and its first data bits. It can release its own state, but it is not obliged to manufacture a weaker quotation and present it as the sender's diagnostic evidence.

This choice avoids a tempting but harmful collapse. Knowing the source address is not the same as possessing the original context promised by the error format. Being able to address a reply is not the same as being able to support the reply's claim.

Efficient bookkeeping did not solve the evidence problem

RFC 815 showed that reassembly bookkeeping could be elegant. Instead of recording every received block, an implementation could maintain descriptors for the holes that remained. A new fragment might trim a hole, split one into two or eliminate it. When no holes remained, the datagram was complete.

The algorithm worked with out-of-order arrival. It also confronted the header problem: some IPv4 options are copied into every fragment, while others appear only in the first. Until that first fragment arrives, the receiver cannot know the final original header layout. The document suggested practical buffer arrangements, but its central contribution was efficient completion detection.

Efficiency cannot create missing evidence. RFC 1122 recommended Clark's algorithm and then added a revealing correction: contrary to RFC 815's presentation, the first fragment header needs to be saved for possible inclusion in an ICMP Time Exceeded reassembly-timeout message. The header was no longer merely material needed to deliver a successfully reconstructed datagram. It was also the retained basis for explaining a reconstruction that failed.

Host Requirements separate the clocks

RFC 1122 made the timer rule explicit and changed its source of authority. An IPv4 host must implement reassembly and must have a reassembly timeout. The value should be fixed rather than derived from remaining TTL. The document recommended between 60 and 120 seconds, explaining that too small a value could discard valid delayed traffic while too large a value would bind buffer resources unnecessarily.

The normative outcome has two clauses. When the timeout expires, the partially reassembled datagram must be discarded. An ICMP Time Exceeded message must be sent to the source if fragment zero has been received.

The parenthesis is the architecture. Memory safety does not wait for permission to report. Evidence does not become mandatory merely because memory was consumed. One obligation is unconditional at expiry; the other is conditional on possession of the proper invoking fragment.

The 60-to-120-second recommendation is historical specification evidence, not a survey of current kernels. It should not be quoted as a universal present default. Its value here is conceptual: the receiver owns a local waiting policy, and that policy cannot be delegated to a TTL field whose deployed meaning had become hop count.

A router changes roles only when the packet is for the router

Fragmentation language can make every network device sound like a reassembler. RFC 1812 keeps the role boundary precise. A router forwarding transit packets does not normally reconstruct them merely to pass them onward. If a fragmented packet is addressed to the router itself and the router reassembles it, the router is acting as an Internet host and follows the host requirements.

The router requirements also preserve the prohibition on ICMP errors in response to non-first fragments. That restriction takes precedence over other error-generation requirements. The rule is not an invitation to infer that every device along a path maintains the same fragment state. It governs the node that owns the destination-side reassembly context.

The timer also occupies an identifier horizon

Incomplete bytes are not the only state kept alive by a long wait. Fragments are associated by a finite Identification field together with source, destination and protocol. If a new datagram reuses the same tuple while old fragments remain plausible, pieces can be confused.

RFC 6864 later described the relationship between reassembly timeout, maximum datagram lifetime and the interval over which Identification values must remain unambiguous. The point is not that one timer value automatically makes reuse safe. It is that retention policy affects both memory and the duration of an identity claim in a small namespace.

This article does not repeat the broader history of IPv4 Identification. It uses the connection for one bounded consequence: extending a reassembly wait buys tolerance for delay by holding both bytes and ambiguity open for longer.

Silence is an observation, not a verdict

A sender that receives Code 1 has useful but narrow evidence. A destination-side reassembler says it retained an incomplete datagram until its timer expired and possessed fragment zero well enough to quote the original beginning. The report does not identify which fragment was lost, who lost it, whether a firewall interfered, or whether the same path will fail again.

A sender that receives nothing knows less. Fragment zero may never have reached the destination. The destination may have suppressed or rate-limited ICMP. The error may have been lost or filtered on its return path. The implementation may use a different behavior, and the observation point may simply have missed it. Silence cannot be promoted into proof that reassembly completed or that no fragments arrived.

That ambiguity is not a defect that a more confident dashboard can repair. It follows from the evidence boundary. The receiver's local disposal is reliable only inside the receiver. Remote testimony is conditional and carried by the same imperfect network that lost part of the original datagram.

Sources and evidence limits

These RFCs establish protocol rules, algorithms and stated design tradeoffs. They do not measure current implementation defaults, IPv4 fragmentation rates, Code 1 delivery, filtering or compliance. No inference about a particular vendor or live network is made from standards text alone.