Skip to main content

4. Updates to the IPv4 ID Specification

This document updates the specification of the IPv4 ID field in three distinct ways, as discussed in subsequent subsections:

  • Using the IPv4 ID field only for fragmentation
  • Encouraging safe operation when the IPv4 ID field is used
  • Avoiding a performance impact when the IPv4 ID field is used

There are two kinds of datagrams, which are defined below and used in the following discussion:

  • Atomic datagrams are datagrams not yet fragmented and for which further fragmentation has been inhibited.
  • Non-atomic datagrams are datagrams either that already have been fragmented or for which fragmentation remains possible.

This same definition can be expressed in pseudo code, using common logical operators (equals is ==, logical 'and' is &&, logical 'or' is ||, greater than is >, and the parenthesis function is used typically) as follows:

  • Atomic datagrams: (DF==1)&&(MF==0)&&(frag_offset==0)
  • Non-atomic datagrams: (DF==0)||(MF==1)||(frag_offset>0)

The test for non-atomic datagrams is the logical negative of the test for atomic datagrams; thus, all possibilities are considered.

4.1. IPv4 ID Used Only for Fragmentation​

Although RFC 1122 suggests that the IPv4 ID field has other uses, including datagram de-duplication, such uses are already not interoperable with known implementations of sources that do not vary their ID. This document thus defines this field's value only for fragmentation and reassembly:

The IPv4 ID field MUST NOT be used for purposes other than fragmentation and reassembly.

Datagram de-duplication can still be accomplished using hash-based duplicate detection for cases where the ID field is absent (IPv6 unfragmented datagrams), which can also be applied to IPv4 atomic datagrams without utilizing the ID field [RFC6621].

In atomic datagrams, the IPv4 ID field has no meaning; thus, it can be set to an arbitrary value, i.e., the requirement for non-repeating IDs within the source address/destination address/protocol tuple is no longer required for atomic datagrams:

Originating sources MAY set the IPv4 ID field of atomic datagrams to any value.

Second, all network nodes, whether at intermediate routers, destination hosts, or other devices (e.g., NATs and other address- sharing mechanisms, firewalls, tunnel egresses), cannot rely on the field of atomic datagrams:

All devices that examine IPv4 headers MUST ignore the IPv4 ID field of atomic datagrams.

The IPv4 ID field is thus meaningful only for non-atomic datagrams -- either those datagrams that have already been fragmented or those for which fragmentation remains permitted. Atomic datagrams are detected by their DF, MF, and fragmentation offset fields as explained in Section 4, because such a test is completely backward compatible; thus, this document does not reserve any IPv4 ID values, including 0, as distinguished.

Deprecating the use of the IPv4 ID field for non-reassembly uses should have little -- if any -- impact. IPv4 IDs are already frequently repeated, e.g., over even moderately fast connections and from some sources that do not vary the ID at all, and no adverse impact has been observed. Duplicate suppression was suggested [RFC1122] and has been implemented in some protocol accelerators, but no impacts of IPv4 ID reuse have been noted to date. Routers are not required to issue ICMPs on any particular timescale, and so IPv4 ID repetition should not have been used for validation purposes; this scenario has not been observed. Besides, repetition already occurs and would have been noticed [RFC1812]. ICMP relaying at tunnel ingresses is specified to use soft state rather than a datagram cache; for similar reasons, if the latter is used, this should have been noticed [RFC2003]. These and other legacy issues are discussed further in Section 5.1.

4.2. Encouraging Safe IPv4 ID Use​

This document also changes the specification of the IPv4 ID field to encourage its safe use.

As discussed in RFC 1122, if TCP retransmits a segment, it may be possible to reuse the IPv4 ID (see Section 6.2). This can make it difficult for a source to avoid IPv4 ID repetition for received fragments. RFC 1122 concludes that this behavior "is not useful"; this document formalizes that conclusion as follows:

The IPv4 ID of non-atomic datagrams MUST NOT be reused when sending a copy of an earlier non-atomic datagram.

RFC 1122 also suggests that fragments can overlap. Such overlap can occur if successive retransmissions are fragmented in different ways but with the same reassembly IPv4 ID. This overlap is noted as the result of reusing IPv4 IDs when retransmitting datagrams, which this document deprecates. However, it is also the result of in-network datagram duplication, which can still occur. As a result, this document does not change the need for receivers to support overlapping fragments.

4.3. IPv4 ID Requirements That Persist​

This document does not relax the IPv4 ID field uniqueness requirements of [RFC791] for non-atomic datagrams, that is:

Sources emitting non-atomic datagrams MUST NOT repeat IPv4 ID values within one MDL for a given source address/destination address/protocol tuple.

Such sources include originating hosts, tunnel ingresses, and NATs (including other address-sharing mechanisms) (see Section 5.3).

This document does not relax the requirement that all network devices honor the DF bit, that is:

IPv4 datagrams whose DF=1 MUST NOT be fragmented.

IPv4 datagram transit devices MUST NOT clear the DF bit.

Specifically, DF=1 prevents fragmenting atomic datagrams. DF=1 also prevents further fragmenting received fragments. In-network fragmentation is permitted only when DF=0; this document does not change that requirement.