IP Identification why zero?
I must say that network troubleshooting is not an easy task. Especially if you need to analyze thousands of packets in packet captures or lines of flow traces. IP ID is a field I use to compare captures taken at different segments most of the time. Also it is a crucial field for me to find the right packet in the flow trace. I didn’t know that this field can be zero till I notice it in a flow trace. Following captured packet is a SYN-ACK segment from a Linux box. 
and Identification field is 0. If you have multiple SYN-ACKs from the same source your Seq,Ack numbers will also be the same which means you have literally no way to distinguish two packets apart from timing. I have searched for a way to disable this zero ID feature to make it unique in Linux but there doesn’t seem to exist any way. When I was searching some documentation to find the reason for this zero ID, I have found a very recent RFC Updated Specification of the IPv4 ID Field. Here is the text that I really didn’t like on this RFC;
>> The IPv4 ID field MUST NOT be used for purposes other than fragmentation and reassembly.
RFC doesn’t enforce anything on the value and also states that originating source MAY set the field of atomic datagrams to any value. RFC also touches on the performance impact of uniqueness of ID field for a given source/destination.
In my humble opinion, this field should never have zero value at least not for me:) and Linux should have a sysctl switch to disable this behaviour.
Especially if you have an IPSEC VPN connection and you need to take a packet capture, you have almost no way to make a comparison between packet captures. Wouldn’t it be nice temporarily copy ip identification field value to the outside header of an ESP packet or a way to let the troubleshooter match the clear text packet and encrypted one. It would be terrific!
I’m facing a similar issue, while testing a communication system, we noticed that for pings (ICMP echo requests and replies), the IP header Identifier is also set to 0, we dont’ seem to have a problem with other types of packets (ARPs, and other IP packets (UDP, haven’t tested with TCP segments yet, we get non-zero packet Identifiers. Is there any reason why pings come with IP packet identifiers of value 0? Can’t seem to find any information. Also, what other types of packets should we expect to see identifiers of 0 for? Thanks!
You have hit the nail on the head with your reference to RFC 6864 – the identification field MUST NOT be used for any purpose other than fragmentation (and reassembly). The caveat that a sender MAY set any value is to accomodate older implementations that did not follow the earlier standards properly where the ID had to be unique for each SRC-DST-Protocol tuple, which would have limited throughput to about 6.4 Mbps with standard packet lifetimes.
So, given that the IP stack on your hosts MUST NOT use the field for any purpose other than fragmentation, why should a properly optimised IP stack set this field for unfragmented packets when it is not used?
Your proposed use of it (as a defacto Sequence ID) violates RFC 6864 as you are using the field for a purpose other than fragmentation. The TCP/IP stack would also have more complexity as it would have to keep track of not only the current sequence number, but also which ones had been used for fragmentation to ensure the uniqueness requirement.
Was experiencing exactly this problem, unable to compare packets on an ipsec vpn troubleshooting at that, landed here. Good article there!