Background
A user reported being confused by the contents of a recently captured packet, where two Ethernet packets looked like two fragments of a TCP/IP payload, because it had the Ethernet identifier IPv4 (0x0800), the IP ID showed the same value, and the source/destination IP address and port were the same. However, the IPv4 headers of the two packets did not have the identifiers for IP fragments:
- Don’t Fragment Tag
- More Fragments Tags
- Fragment offset is 0
Judging from the data packet phenomenon reported by users, this is indeed a rather strange case, but network protocol analysis requires seeing is believing, after all, no one is an expert in guessing.
Problem Information
The basic information of the packet trace file is as follows:
λ capinfos "IP_Id 4958 Frag_Offset ZERO.pcapng"
File name: IP_Id 4958 Frag_Offset ZERO.pcapng
File type: Wireshark/... - pcapng
File encapsulation: Ethernet
File timestamp precision: microseconds (6)
Packet size limit: file hdr: (not set)
Number of packets: 6
File size: 2940 bytes
Data size: 2492 bytes
Capture duration: 0.098405 seconds
First packet time: 2017-07-28 02:03:15.503250
Last packet time: 2017-07-28 02:03:15.601655
Data byte rate: 25 kBps
Data bit rate: 202 kbps
Average packet size: 415.33 bytes
Average packet rate: 60 packets/s
SHA256: 08bb3b445b865e80b7b02000a002d387f3e23eaa746e8bfec3e2020d10af9a31
RIPEMD160: f3f7570c672bb7bfabcbfe006c3fc2b119237bfb
SHA1: 1ffc38d630487447cb203ac593da3f8e36835177
Strict time order: True
Capture oper-sys: 64-bit Windows 10, build 15063
Capture application: Dumpcap (Wireshark) 2.2.6 (v2.2.6-0-g32dac6a)
Number of interfaces in file: 1
Interface #0 info:
Name = \Device\NPF_{04A953BC-ADF6-4F27-9F29-205A684C378D}
Encapsulation = Ethernet (1 - ether)
Capture length = 262144
Time precision = microseconds (6)
Time ticks per second = 1000000
Time resolution = 0x06
Operating system = 64-bit Windows 10, build 15063
Number of stat entries = 0
Number of packets = 6The number of data packets is only 6, the packet capture client system is Win10, and Wireshark captures it directly. There is no alarm information in the entire data packet content, and everything is normal.
Problem Analysis
Based on the above data packet content, including Wireshark’s judgment and analysis, there is actually no problem. However, as users feedback, there is suspected IP fragmentation. The reason for judgment is the existence of the same IP ID .
Expand the IP ID information, and indeed, as the user said, packets No. 2 and No. 4 have the same IP ID value 0x135e .
IP ID and fragmentation
First of all, what is IP ID? It actually refers to IPv4 Identification . For details, see RFC 791:
Identification: 16 bits
An identifying value assigned by the sender to aid in assembling the fragments of a datagram.As RFC 791explained in , IP ID is an identification value assigned by the sender to assist in assembling datagram fragments. RFC 6864 Updated Specification of the IPv4 ID FieldRelated concepts are also defined in :
In IPv4, the Identification (ID) field is a 16-bit value that is unique for every datagram for a given source address, destination address, and protocol, such that it does not repeat within the maximum datagram lifetime (MDL) [RFC791] [RFC1122]. As currently specified, all datagrams between a source and destination of a given protocol must have unique IPv4 ID values over a period of this MDL, which is typically interpreted as two minutes and is related to the recommended reassembly timeout [RFC1122]. This uniqueness is currently specified as for all datagrams, regardless of fragmentation settings.In IPv4, the ID is unique for a given source address, destination address, and protocol, and will not be repeated within the maximum datagram lifecycle. Generally speaking, the sender often uses an incremental value, as shown below. Of course, given the source address, destination address, and protocol, different streams transmitted at the same time will share the IP ID value, so sometimes the IP ID values of the upper and lower packets in the same stream will be spaced and not continuous.
Speaking of IP fragmentation, due to the need for fragmentation and reassembly, a unique ID is required. Therefore, the same datagram will eventually generate multiple datagrams with the same IP ID due to the requirements of fragmentation. The following example takes a Ping packet of 5600 bytes as an example. Due to the MTU 1500, it is divided into 4 datagrams, whether it is an icmp request or an icmp reply.
Further analysis
In summary, the user judged that there was fragmentation based on the condition of IP ID duplication , but there were no fields that should exist for fragmentation, such as Don’t fragment, More fragments, etc., so doubts arose.
But in fact, in addition to the IP fragmentation scenario that causes IP ID duplication, duplication may also occur in some special scenarios:
- In high-speed transmission scenarios, the 16-bit value of the IP ID cannot guarantee that the IP ID in the packet tracking file will not be repeated. If it continues to increase to the end, it will be another cycle;
- Some systems do not assign IP ID values at the protocol stack level, and the datagram IP ID value will be displayed as 0x0000;
- Some intermediate devices have the ability to change IP ID values, such as NAT, security devices, proxies, or load balancers. Since they have the ability to change, they may change to the same value;
- An error at the protocol stack level may result in duplicate IP ID values being assigned, including at the sender or intermediate device.
The user’s packet trace file also illustrates this problem very well. No.1, No.2 and No.4 are actually three consecutive TCP segments. The TCP Seq Num clearly shows that they are not real IP fragments, and naturally there is no fragment field. Based on the RFC definition of the use of IP ID, its repetitiveness will not cause transmission problems, so Wireshark judges that there is nothing abnormal here.
Therefore, my personal judgment on this user’s problem is that there is an error at the protocol stack level, and duplicate IP ID values are assigned. Because of the unknown operating environment, the problem may be at the sending end or at the intermediate device.
Summary of the problem
Grasp the basic knowledge points, combine them with various scenarios, and reasonably restore the truth of the data packet.