Summary

  • The high bit of an IPv4 option type told a fragmenter whether the option belonged only in the first fragment or had to be copied into every fragment.
  • Fragmentation derived headers rather than cloning them. Option sets, IHL, Total Length, Fragment Offset, More Fragments and Header Checksum could legitimately differ within one reassembly group.
  • Copy 1 assigned custody; it did not guarantee processing, authentication, delivery or identical bytes at arrival. Mutable copies could diverge along different paths, while fragment zero remained authoritative for the complete non-copied state.

A fragment was not a photocopy with fewer data bytes

The familiar diagram of IP fragmentation shows a long payload divided into shorter strips. It is useful until it suggests that the header above each strip is the same. An IPv4 module that fragments an option-bearing datagram has to do more than cut and duplicate. It must interpret which network-layer meaning each derived entity needs in order to travel independently.

RFC 791 divides an option's type octet into a one-bit copied flag, a two-bit class and a five-bit number. Zero means that the option is copied into the first fragment only. One means that it is copied into all fragments.

“First” is a structural term. It is the fragment whose Fragment Offset is zero, not necessarily the fragment that reaches the destination first. That fragment carries the complete original option set. Nonzero fragments carry only the options whose Copy bit says that their context must follow the split.

Loose Source and Record Route is type 131, so its high bit is one. Record Route is type 7, so its high bit is zero. Put both in the original header and later fragments can have a shorter Internet Header Length than fragment zero. That difference does not break their common identity. It is the result the type grammar requested.

Selective custody preceded the canonical IPv4 RFC

RFC 760, dated January 1980, already distinguished options copied into every fragment from options retained only in the first. Its fragmentation procedure described selectively copying the Internet header when constructing the next fragment.

RFC 791 made the decision directly readable in the option type. The fragmenter did not need an external authority to rank the option, and it did not receive discretion to invent a local list. It could apply a deterministic bit carried by the entity itself.

The common rule was small, but its execution remained exacting. The first fragment began with the original header. A subsequent header was selectively constructed. Removing non-copied options changed IHL. The data assigned to that fragment changed Total Length. Its position changed Fragment Offset. Whether more data followed changed More Fragments. Every header change required a new Header Checksum.

The output was therefore a family of derived headers. They shared provenance and reassembly state without sharing every option byte or field value. Fragmentation was a semantic transformation constrained by a narrow specification, not a blind packet cutter.

A valid checksum could not prove valid inheritance

Header Checksum protects the header that is present. It does not remember the header that should have been derived. A fragmenter can mistakenly omit a Copy-1 option and still compute a checksum that matches the malformed result. It can also copy a first-fragment-only option into every fragment and make each checksum internally correct.

This separates two evidence questions. Is this particular header arithmetically intact? Did it descend from the original according to the Copy rule? A capture that answers only the first has not closed the second.

The same boundary applies to reassembly identity. Source, destination, protocol, Identification-related state, offsets and flags let an implementation associate pieces under the specified rules. They do not require identical IHL or identical option sets. Demanding equality where the protocol defines derivation is not stricter validation; it is validation against the wrong entity.

One did not mean important and zero did not mean expendable

Strict Source and Record Route, type 137, and Stream Identifier, type 136, have Copy 1. Timestamp, type 68, and Record Route, type 7, have Copy 0. The former Basic Security Option, type 130, also had Copy 1. The distribution is not a ranking from valuable to trivial.

Copy 0 says that the option does not need to be reproduced in each independently forwarded derivative. It remains in the zero-offset fragment, where the full original option selection is preserved. Copy 1 says that each derivative receives the option. It does not add priority, reliability, encryption, authentication, integrity or a delivery receipt.

That boundary matters for the Security Option in particular. Its separate label semantics could affect policy, but the copied flag itself supplied no security property. Calling it a security bit because one security-related option used it would confuse the container rule with the contained claim.

The IANA Internet Protocol Version 4 Parameters registry records Copy, Class, Number, Value, Name and Reference for assigned option types. It proves standardized allocation and points to documentary authority. It does not prove present traffic share, product support, successful processing or the state in which an option arrived.

Assignment, implementation, emission, transit, receipt and effect are separate rungs. The registry closes the first one, not the ladder.

Copies could acquire different histories after the cut

“Copied into all fragments” is easily shortened into “identical in every fragment.” That can describe the moment of derivation, but not necessarily arrival. RFC 815 notes that fragments of one datagram may travel over different routes. A copied source-and-record-route option may then be updated by different routers.

The option versions can arrive with different recorded paths even though they began from one original state. The Copy bit preserved each fragment's ability and obligation to carry the option. It did not freeze fields that the option semantics allowed later nodes to write.

For the reassembly behavior it describes, RFC 815 uses the return route recorded in the first fragment and ignores alternative versions in the others. It does not merge the routes or choose the most common. The rule assigns authority by provenance: use the zero-offset fragment's version.

This creates a subtle evidence problem. A collector that immediately deduplicates the option may erase proof that the fragments diverged. A collector that reports any divergence as tampering may criminalize an authorized mutation. The raw fragments, arrival order and reassembly selection have to remain distinguishable.

Copying creates more instances. It does not, by itself, create a reconciliation policy. That policy must come from the applicable specification and remain visible in the audit trail.

The complete header could arrive last

RFC 815 identifies another consequence of selective copying: until the first fragment arrives, the receiver may not know the final header size. A nonzero fragment can legitimately omit all Copy-0 options and expose a shorter IHL.

If that fragment arrives first in time, its header is complete for that fragment and incomplete as evidence of the original. Treating the earliest observed IHL as final promotes network scheduling into an authority rule.

RFC 6274 carries this boundary into a security check. Determining whether the reassembled packet can contain the claimed transport header requires the first fragment's IHL. If fragment zero is unavailable, an implementation can perform only a preliminary test and must apply the full test once the authoritative header arrives.

The provisional state is useful because it is reversible. It allows an implementation to make bounded progress without pretending that missing evidence does not matter. The dangerous optimization is not preliminary computation; it is discarding the condition that would cause the computation to be revisited.

A reassembly queue thus holds more than payload intervals. It also holds an unresolved claim about the original header's shape.

End and alignment made the operation grammatical

End of Option List and No Operation do not fit a crude story in which every option is an indivisible business record with its own Copy choice. They terminate or align the option area. When non-copied options disappear from a later header, the fragmenter may have to reconstruct the ending and padding so that the derived header still ends on a 32-bit boundary.

A correct implementation cannot search for arbitrary bytes with a zero high bit and delete them. It has to parse option boundaries and lengths, avoid cutting a multioctet option, close the area, update IHL and then recalculate the checksum.

An unknown option still has syntax. An implementation may not understand every operational consequence, but ignorance does not confer permission to reinterpret it freely. The common format provides enough structure to traverse, copy according to type or fail explicitly.

This is what a minimum common layer looks like when it is disciplined. It decides only what must be shared, but it defines those decisions tightly enough for independent code to verify them locally.

A fragile mechanism was not a mechanism that never existed

RFC 8900 states the option consequence directly: all IPv4 options appear in the first fragment, and only options with Copy 1 appear in subsequent fragments. It also documents why IP fragmentation is fragile in deployed networks, including loss, middlebox behavior, filters that cannot see the upper-layer header and pressure on reassembly resources.

Those are mechanisms and operational observations, not a universal failure census. The document does not prove that every fragmented flow fails, that every middlebox behaves alike or that any particular historical option remains common. Architectural caution cannot be expanded into deployment facts the source did not measure.

RFC 8200 provides a later contrast. IPv6 leaves fragmentation to the source and separates the per-fragment material from headers carried with the first fragmentable part in a different way. The comparison shows that the control boundary moved. It does not make IPv4's copied flag retrospectively pointless.

IPv4 had to solve a particular problem: a source or an intermediate router might divide an option-bearing datagram, and every derivative still needed enough network-layer meaning to be forwarded under the original rules. The Copy bit was its compact answer.

The fragmenter did not become the owner of the meaning

The opening uses a router because an intermediate transformation makes the custody question vivid. IPv4 fragmentation can also occur at the source, depending on the packet, path MTU and Don't Fragment state. It would be inaccurate to make the router universal.

Whoever performs the cut receives narrow authority. It may divide the payload, maintain reassembly fields, derive the option set from Copy, restore alignment and recalculate the header checksum. It may not declare a Copy-0 option meaningless, certify the truth of a Copy-1 option or promise that the downstream path will process it.

The original sender owns the option selection subject to the protocol. The fragmenter owns a specified transformation. Routers on the later paths own only the processing their option formats permit. The receiver owns reassembly under the defined provenance rules.

This separation avoids two extremes. The common layer does not have to copy every possible state into every fragment, and each implementation does not get discretionary power to decide what survives. A thin deterministic rule sits between them.

A capture has to preserve legitimate inequality

A useful investigation correlates source, destination, protocol, Identification, Fragment Offset, MF, IHL, option types, Copy values and arrival order. It asks precise questions. Did a Copy-0 option appear in a nonzero fragment? Did a required Copy-1 option disappear? Was an option truncated? Did alignment fail? Was a preliminary check rerun after offset zero arrived?

“The headers differ” is not a sufficient alert. Neither is “all checksums pass” a sufficient clearance. The expected entity is a constrained derivation whose legal differences can be stated in advance.

When fragment zero is absent, the report should retain that absence as an evidence limit. It cannot convert “the complete option set was not observed” into “the original had no non-copied options.” When mutable copied options differ, the analyst must first test whether the option authorized path writing.

The strongest record keeps the leaves and the tree. It preserves each received fragment, the relationship that groups it with the original datagram, and the version selected for reassembly. A normalized synthetic header may be convenient for downstream analysis, but it should not replace the evidence from which it was derived.

Sources and evidence boundary

The source set comprises RFC 760, RFC 791, RFC 815, RFC 1122, RFC 1812, RFC 6274, RFC 8900, RFC 8200 and the IANA IPv4 registry. These establish specifications, history and bounded operational consequences. They do not establish current option prevalence, universal implementation conformity, attack incidence, successful delivery or the behavior of every real path.