 | 1 | initial version |
RFC 791 says, in section 3.1 "Internet Header Format", that the "Identification" field is "An identifying value assigned by the sender to aid in assembling the fragments of a datagram." and, in the section on "Fragmentation", says:
The identification field is used to distinguish the fragments of one
datagram from those of another. The originating protocol module of
an internet datagram sets the identification field to a value that
must be unique for that source-destination pair and protocol for the
time the datagram will be active in the internet system. The
originating protocol module of a complete datagram sets the
more-fragments flag to zero and the fragment offset to zero.
and in "An Example Reassembly Procedure", says
The choice of the Identifier for a datagram is based on the need to
provide a way to uniquely identify the fragments of a particular
datagram. The protocol module assembling fragments judges fragments
to belong to the same datagram if they have the same source,
destination, protocol, and Identifier. Thus, the sender must choose
the Identifier to be unique for this source, destination pair and
protocol for the time the datagram (or any fragment of it) could be
alive in the internet.
RFC 1812 "Requirements for IP Version 4 Routers" doens't appear to say anything about routers modifying the identifier field.RFC
RFC 6864 "Updated Specification of the IPv4 ID field" suggests that the IPv4 ID be used only for fragmentation and reassembly, allowing non-fragmented IPv4 datagrams to, for example, have an ID of 0, to reduce the number of unique IDs a sender needs to generate within a given period of time, and it notes that "Existing devices have been known to generate non-varying IDs for atomic datagrams for nearly a decade, notably some cellphones."
IPv6 doesn't even have an ID field in non-fragmented datagrams.
So my guess is that the identifier probably wasn't modified by some intermediate device, but there's no absolute guarantee.