Updated Specification of the IPv4 ID Field
updates
Extracted elements (24)
No IPv4 ID values, including 0, are reserved as distinguished. Atomic datagrams are identified by testing the DF, MF, and fragment offset fields, making the approach fully backward compatible without requiring special ID values.
Strict enforcement of IPv4 ID uniqueness within the MDL would limit aggregate throughput between two endpoints to 6.4 Mbps at typical 1500-byte MTUs, far below common link speeds. Because high-speed devices already violate this uniqueness in practice, the specification is updated to reflect reality rather than mandate an unenforceable constraint.
The IPv4 ID field is redefined to have meaning only for fragmented or fragmentable datagrams, mirroring IPv6 where the fragment header (and its ID) is absent for non-fragmented datagrams. This eliminates non-fragmentation uses such as duplicate detection and diagnostic correlation, which are already non-interoperable with implementations that generate non-varying IDs.
Tunnel ingresses act as originating sources for the outermost IPv4 header and therefore control the uniqueness of the outer IPv4 ID independently of the inner header. This means tunnel ingresses can always fragment as originating sources without violating the inner datagram's ID constraints.
Header compression algorithms (ROHC, ECRTP, cRTP) already accommodate non-changing IPv4 IDs. When compression assumes a changing ID by default, a non-changing ID reduces efficiency; algorithms that allow non-changing IDs explicitly (ROHC, ECRTP) can increase efficiency when sources use constant IDs.
IPv6 unfragmented datagrams carry no ID field at all; diagnostic tools and duplicate-detection mechanisms that rely on the IPv4 ID field are already non-functional for IPv6 and must be updated to use IPv6-compatible methods such as hash-based duplicate detection (RFC 6621).
Legacy devices including some cellphones have generated non-varying (constant zero) IPv4 IDs for atomic datagrams for many years, predating this specification. ROHC already accommodates non-changing IDs as an optimization, and IP/ICMP translation standards also describe constant-zero IDs.
NATs and other address-sharing mechanisms present a particularly challenging situation for fragmentation because they overwrite portions of the reassembly tuple, potentially destroying its uniqueness. Reassembly followed by re-fragmentation at the NAT is the recommended approach to maintain ID uniqueness on the outgoing side.
Some devices ignore the Don't Fragment (DF) bit and fragment datagrams regardless. Such DF-ignoring devices do not comply with existing standards; if fragments with reused IDs arrive interleaved at a destination, reassembly fails and traffic is silently dropped. This document does not make such devices compliant.
Address-sharing or rewriting devices (NATs, NAPTs, ASMs, tunnel ingresses) MUST ensure that the IPv4 ID field of datagrams whose addresses or protocols are translated complies with these requirements as if the datagram were sourced by that device.
All devices that examine IPv4 headers MUST ignore the IPv4 ID field of atomic datagrams. This applies to intermediate routers, destination hosts, NATs, firewalls, and tunnel egresses.
Higher-layer protocols SHOULD verify the integrity of IPv4 datagrams using a checksum or hash that can detect reassembly errors, since UDP and TCP checksums are weak. Tunnels with strong integrity (IPsec, SCTP, SEAL) provide stronger reassembly error detection.
IPv4 datagrams whose DF=1 MUST NOT be fragmented. IPv4 datagram transit devices MUST NOT clear the DF bit. DF=1 prevents fragmenting atomic datagrams and prevents further fragmenting received fragments.
Originating sources MAY set the IPv4 ID field of atomic datagrams to any value, since the field has no meaning for such datagrams. The previous uniqueness requirement no longer applies to atomic datagrams.
Sources emitting non-atomic datagrams MUST NOT repeat IPv4 ID values within one MDL for a given source address/destination address/protocol tuple. This requirement from RFC 791 is preserved for non-atomic datagrams.
Sources of non-atomic IPv4 datagrams MUST rate-limit their output to comply with the ID uniqueness requirements. This applies especially to DNS over UDP, which generates non-atomic datagrams.
Sources of non-atomic IPv4 datagrams using strong integrity checks MAY reuse the ID within intervals smaller than typical MDL values. Such reuse can still result in corrupted reassembly but will not propagate errors to higher-layer protocols.
The IPv4 ID field MUST NOT be used for purposes other than fragmentation and reassembly. Non-fragmentation uses such as duplicate detection and diagnostic correlation are deprecated.
The IPv4 ID of non-atomic datagrams MUST NOT be reused when sending a copy of an earlier non-atomic datagram. This deprecates the RFC 1122 allowance for retransmitted segments to carry the same ID.
Atomic datagrams are those not yet fragmented and for which further fragmentation has been inhibited, identified by the condition (DF==1)&&(MF==0)&&(frag_offset==0). The IPv4 ID field carries no meaning for atomic datagrams and may be set to any value.
Non-atomic datagrams are those that have already been fragmented or for which fragmentation remains possible, identified by (DF==0)||(MF==1)||(frag_offset>0). The IPv4 ID field MUST be unique within one MDL per source/destination/protocol tuple for non-atomic datagrams.
Allowing non-unique IPv4 IDs for atomic datagrams defeats techniques that count devices behind a NAT/ASM/rewriter by exploiting ID uniqueness patterns. This side effect is acknowledged but not intended as a security feature.
The IPv4 ID field of atomic datagrams is no longer required to be unique, so it contributes no entropy to the header. Previously, the ID (though weakly) added uniqueness per source/destination/protocol within one MDL; this is now gone for atomic datagrams and should not be used as input to cryptographic algorithms or pseudorandom generators.
When the IPv4 ID field is ignored on receipt for atomic datagrams, its value becomes unconstrained and can more easily be used as a covert channel. It may be desirable for middleboxes to rewrite the ID field of atomic datagrams to prevent this, though rewriting is prohibited for datagrams protected by the IPsec Authentication Header (AH).