Summary

  • IPv4's Identification field was created to let a destination associate fragments with their original datagram, but early requirements extended uniqueness to all datagrams.
  • A 16-bit namespace could not remain unique for the assumed lifetime at modern rates, while predictable values acquired diagnostic, fingerprinting and attack uses beyond reassembly.
  • RFC 6864 made the ID meaningless for atomic datagrams and ordered every device to ignore it there, while retaining strict uniqueness for traffic that can be or has been fragmented.

A number for pieces that had lost their whole

The original RFC 791 gave Internet Protocol two central jobs: addressing and fragmentation. A gateway could split a datagram to cross a network with a smaller maximum packet size. The destination then needed to decide which arriving pieces belonged together.

Four header fields supplied the answer. Identification named the original datagram, Fragment Offset placed a piece within it, MF said that more pieces followed, and DF prohibited fragmentation. Reassembly combined the source address, destination address, upper-layer protocol and Identification value into a buffer key.

The 16-bit number was therefore not an end-to-end transaction ID. It did not identify a web request, TCP segment or application event. Its necessary job was narrower: prevent fragments of contemporaneous datagrams in the same reassembly context from being confused.

Yet the field appeared in every IPv4 header, including packets that arrived whole. Presence made general meaning tempting.

Uniqueness expanded beyond necessity

The early contract required a different ID for every datagram in a source-address, destination-address and protocol tuple during the maximum datagram lifetime. RFC 1122 also recorded proposed secondary uses. A repeated number might help a congested gateway discard a duplicate, or let a retransmission reuse fragments from an earlier copy.

Those ideas converted a reassembly label into a general identity service. The sender had to coordinate a small namespace even when DF made fragmentation impossible. Routers, accelerators and diagnostic tools could begin treating the field as evidence about sameness, sequence or host behavior.

The contract looked cheap when packet rates were low. It became arithmetically impossible as the Internet accelerated.

Sixty-five thousand names were not enough time

A 16-bit field contains 65,536 values. It can wrap safely only after fragments carrying the earlier value can no longer arrive and enter the same reassembly buffer. Faster links consume the namespace sooner; they do not make old fragments expire sooner.

RFC 4963 described the resulting high-rate reassembly failure. If two fragmented datagrams reuse an ID while pieces from the first remain eligible, a receiver can associate pieces from different originals. Depending on checksums, timing and loss, the result may be discard, corruption or performance collapse.

The document was not warning that every fast unfragmented flow corrupts data. The hazard requires fragmentation and overlapping reassembly lifetimes. That condition is precisely why making every unfragmented packet consume globally meaningful identity was wasteful.

RFC 6864 later calculated that the older all-datagram uniqueness rule, with a 1,500-byte MTU and a two-minute assumed lifetime, would hold one protocol between two endpoints to roughly 6.4 Mbps. That figure belongs to the stated assumptions. Its historical force is that ordinary connections had already surpassed a requirement the field could not satisfy.

Counters became evidence the protocol never promised

One easy implementation was to increment a counter. Observers could then compare values and infer activity between probes, distinguish systems or estimate traffic. Predictability also helped off-path attackers guess fragment identifiers under particular reachability and triggering conditions.

RFC 7739 catalogued security implications of predictable fragment identifiers and possible generation strategies. The lesson is not that one random function solves every case. Random selection in a bounded space can collide too, and algorithm choice must still preserve uniqueness for fragments.

Nor did every implementation behave alike. Some sources had long emitted constant IDs for traffic that did not need fragmentation. The diversity itself proved that non-reassembly consumers could not rely interoperably on a universal sequence.

A value can be observable without being authoritative. The standards repair would eventually say so explicitly.

The decisive distinction was atomicity

RFC 6864 defined an atomic IPv4 datagram through three facts: DF=1, MF=0, and Fragment Offset zero. It is not a fragment, and a compliant transit device cannot fragment it.

For that packet, the ID has no reassembly work to perform. The originating source may set it to any value. Zero is permitted, but not privileged. A constant, changing or otherwise arbitrary value is equally outside the protocol's meaning.

The stronger rule applies to consumers: every router, destination, firewall, NAT, address-sharing device and tunnel endpoint examining an atomic datagram must ignore its Identification field. This was not merely freedom for senders. It revoked the authority of downstream systems to build a decision on the value.

The inverse category is non-atomic. A packet is non-atomic if fragmentation is allowed or has already occurred. A whole datagram with DF=0 belongs here even if no router has split it yet, because a later hop still may. Fragments with MF=1 or a nonzero offset obviously belong here as well.

The old obligation survived where pieces could meet

RFC 6864 did not declare the 16-bit limit harmless. Sources of non-atomic datagrams must still avoid repeating an ID within one maximum datagram lifetime for the same source, destination and protocol tuple. A retransmitted non-atomic copy must receive a different ID rather than mixing its fragments with the first attempt.

The obligation reaches more than end hosts. Tunnel ingresses and NATs can become datagram sources when they encapsulate or rewrite fields, so they inherit the uniqueness duty.

The network must also respect the premise. A packet with DF=1 must not be fragmented, and a transit device must not clear DF. Otherwise a middlebox would transform a packet whose arbitrary ID was safe into one whose fragments suddenly required a reliable label.

The boundary therefore has two sides: senders may withdraw meaning only by forbidding fragmentation; the path must honor that decision.

What disappeared was accidental authority

The update prohibited using IPv4 ID for duplicate detection. Diagnostic correlation had to find other evidence. Counting hosts behind address sharing from counter patterns became less dependable. Atomic IDs also contributed no promised entropy, although their unconstrained bits could themselves carry covert information.

These were not accidental compatibility losses. They were consequences of clarifying ownership. Reassembly owns the identifier because it cannot work without distinguishing live fragment sets. Other mechanisms do not acquire a claim merely because the bits are present and convenient.

The field remained in the fixed IPv4 header. Backward compatibility came from changing semantics according to existing flags, not from changing packet layout. An old wire format gained a smaller contract.

A specification can improve by meaning less

Protocol evolution is often described as adding capacity: wider fields, new options, stronger algorithms. RFC 6864 improved IPv4 by subtracting a promise it could no longer keep.

The repair did not centralize assignment of packet numbers or ask the network to track a larger ledger. It examined the condition that created shared dependence. Where fragments could coexist, uniqueness remained mandatory. Where fragmentation was impossible, local choice returned and remote interpretation ended.

That is a durable form of minimum specification. A common field should carry only the meaning required for interoperability. Otherwise incidental observers turn availability into authority, and scale eventually exposes the fiction.

Sources and evidence limits

The closed evidence set is RFC 791, RFC 1122, RFC 4963, RFC 6864 and RFC 7739. They establish the original reassembly role, older host requirements, high-rate wrap risk, the atomic/non-atomic update and predictable-ID security analysis. They do not establish current vendor behavior, present fragmentation rates, universal counter algorithms or one corruption threshold for every path.