Ask Your Question
0

Is it only the source that can write to Identification field?

asked 2021-10-30 11:44:10 +0000

theUseless gravatar image

I have a strange problem with duplicate UPD telegrams that i am trying to understand. I have found in my log that the duplicate telegrams have different Identification number in the packet header. Can a device, switch or access point write to the Identification number or is it safe to assume that its the original source that is the cause for the duplicate telegrams?

edit retag flag offensive close merge delete

2 Answers

Sort by ยป oldest newest most voted
0

answered 2021-10-31 20:53:10 +0000

Guy Harris gravatar image

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.

edit flag offensive delete link more

Comments

Thank you for your detailed answer! I will add more logs closer to the sources in order to determine if it is the source that is indeed the cause but at this point that's most likely. Its very strange there are a lot of telegrams going back and forth and all of a sudden always around 16sec later a duplicate packet with a different identification number appears. Its a local system with several identical clients communicating over Wifi to the host. So there are no routers involved only clients,access points switches and the source and host itself.

theUseless gravatar imagetheUseless ( 2021-11-01 08:50:17 +0000 )edit
0

answered 2021-11-01 20:22:40 +0000

BigFatCat gravatar image

The RFC doesn't specify that the IP-ID has to be unique. The only exception is for fragmentation. Cisco sends pings with the IP-ID 0x0000, and it works without any issues. IPv6 doesn't have IP-ID, which means to me that the upper protocols don't care. In my opinion, the only device that would work to change the IP-ID is a firewall.

edit flag offensive delete link more

Your Answer

Please start posting anonymously - your entry will be published after you log in or create a new account.

Add Answer

Question Tools

1 follower

Stats

Asked: 2021-10-30 11:44:10 +0000

Seen: 592 times

Last updated: Nov 01 '21