Summary

  • RFC 791 defined the IPv4 Identification field to help a receiver associate fragments belonging to one original datagram.
  • RFC 6864 withdrew that meaning from atomic datagrams, allowing any ID value and requiring devices to ignore it when fragmentation is impossible.

Two packets with the same identification

Suppose a host sends two ordinary IPv4 datagrams along a path with the Don't Fragment flag set. Neither datagram has More Fragments set, and each has a fragment offset of zero. Both carry the same value in their 16-bit Identification field.

Under the current specification, that repetition is not evidence that the host duplicated a packet, exhausted a counter or violated a uniqueness rule. Those datagrams are atomic: they are not fragments, and further fragmentation has been prohibited. Because no reassembly process can ever need to decide whether their pieces belong together, their Identification values have no protocol meaning.

The result sounds surprising only if the field's name is treated as its authority. IPv4's wire format still allocates the bits. Their presence does not guarantee that every packet receives a durable identity. RFC 6864 made the semantic boundary explicit by asking a prior question: can this datagram participate in fragmentation and reassembly?

What RFC 791 needed the field to do

RFC 791 described Identification as a sender-assigned value that aids the assembly of a datagram's fragments. When a large IPv4 datagram is divided, each fragment retains information that lets the destination reconstruct the original: source and destination addresses, the protocol number, the Identification value, the More Fragments flag and a fragment offset.

The ID matters because fragments can arrive separately and out of order. Within the same source-address, destination-address and protocol tuple, a receiver needs to distinguish pieces of one original datagram from pieces of another that remain live during the same reassembly interval. The field is therefore not an identity in the abstract. It is a correlation key inside a bounded reconstruction problem.

That original purpose encouraged a broader operational habit. Since the field appeared in every IPv4 header, implementations and tools sometimes treated it as a general packet identifier, a duplicate-suppression signal, a counter or a way to correlate observations made at different points on a path. RFC 6864 separated those practices from what fragmentation actually requires.

A 16-bit promise collided with packet rate

A 16-bit field has 65,536 possible values. Requiring every IPv4 datagram between the same endpoints and protocol to carry a non-repeating ID for an entire maximum datagram lifetime becomes difficult as transmission rates rise. RFC 6864 explains that the safe aggregate rate can become implausibly low when the uniqueness requirement is applied indiscriminately, even to datagrams that cannot be fragmented.

The pressure is structural. A sender cannot create more values by incrementing faster; faster reuse is the problem. Expanding the tuple or guessing when old fragments have disappeared does not turn a finite field into a universal identity space. Meanwhile, atomic datagrams contribute no fragments for a receiver to confuse.

The standards response was not to abolish Identification or declare fragmentation irrelevant. It was to stop spending scarce uniqueness on traffic for which reassembly can never consult it. The revised rule aligns the obligation with the dependency.

Atomic and non-atomic are wire-visible states

RFC 6864 divides IPv4 datagrams into two exhaustive classes using fields that already exist. A datagram is atomic when DF equals one, MF equals zero and Fragment Offset equals zero. It has not been fragmented, and routers are forbidden from fragmenting it later.

A datagram is non-atomic when fragmentation remains possible or fragmentation state is already present: DF is zero, MF is one, or Fragment Offset is greater than zero. In that class, the Identification field remains meaningful because pieces may need to be associated during reassembly.

The distinction does not reserve a new ID value and does not require a new header bit. Zero is not a special declaration that an ID is meaningless. The combination of DF, MF and Fragment Offset supplies the classification, which allows older wire formats and newer semantics to coexist.

Meaning was removed from one class, not weakened everywhere

For an atomic datagram, an originating source may set the IPv4 ID to any value. Every device that examines IPv4 headers must ignore the field in that class. A constant zero, a repeated value or an implementation-specific pattern cannot be interpreted as reassembly identity because reassembly is outside the possible future of that datagram.

For a non-atomic datagram, the opposite boundary applies. The sender still needs IDs suitable for distinguishing fragments within the relevant tuple and lifetime. RFC 6864 therefore preserves the field's original function exactly where ambiguity between fragments can occur.

This is more precise than saying IDs became optional. The bits are not optional in an IPv4 header, and fragmentation has not disappeared. What changed is the claim that the same bits mean the same thing in every packet state.

Why other uses lost standards authority

RFC 6864 says the IPv4 ID must not be used for purposes other than fragmentation and reassembly. That rule rejects the idea that atomic IDs can act as interoperable evidence of packet uniqueness.

Duplicate detection is one example. Two atomic datagrams with the same ID are not necessarily duplicates; two packets with different IDs are not necessarily different payloads in a sense useful to an application. Diagnostic correlation is another. A path tool may observe patterns produced by a particular implementation, but the protocol no longer promises those patterns or grants them stable meaning.

The limitation does not make every measurement impossible. It changes the evidentiary standard. A system that needs duplicate suppression or observation correlation must use stronger context, such as hashes and other packet fields, rather than assigning universal semantics to a value that compliant senders may repeat freely.

A field can outlive one of its meanings

The history of IPv4 Identification illustrates a common form of protocol maintenance. A deployed header cannot be redesigned casually, but the obligations attached to a field can be narrowed when experience shows that an old interpretation is unnecessary or unsustainable.

RFC 791 supplied a fragment association mechanism. RFC 6864 preserved that mechanism, classified the packets that can actually depend on it, and withdrew non-fragmentation interpretations. The field remained in place, but its authority became conditional.

The durable lesson is not that identification stopped mattering. It is that a protocol identifier should be unique only within the problem it is meant to solve. For IPv4, the relevant problem is reassembly. When a datagram is atomic, the field named Identification is present syntax without identifying force.

Sources