IGMP v3 Ip ID [closed]
Can anyone explain why IP id 76 keeps getting reused in this packet capture https://drive.google.com/file/d/1N0hV...
Can anyone explain why IP id 76 keeps getting reused in this packet capture https://drive.google.com/file/d/1N0hV...
The IP identification being unique is only important if packets are fragmented. Multicast packets are assigned special MAC multicast and routing is layer 3 multicast. IGMP doesn't use the IP ID for membership. Per RFC 5225, it has been observed to being constant. It still works, but not conformant with RFC 791. It still works, but the Firewalls like manipulating the IP ID and other stuff to make it harder to follow the packets.
Per RFC 5225, 6.3.3. IP-ID Behavior
The IP-ID field of the IPv4 header can have different change patterns: sequential in network byte order, sequential byte-swapped, random or constant (a constant value of zero, although not conformant with [RFC0791], has been observed in practice).
The RFC (rfc6864 - Updated Specification of the IPv4 ID Field) mentions that the field has been used for various reasons in the past.
Are the MAC addresses real or was the capture modified?
It's only one vendor (example: eth.addr == 00:09:fb:c8:88:7e
) that is doing this.
The device mainly uses 76 but in frame 369 has what looks more normal - 59103.
Can you open a support ticket directly with that vendor?
$ ./tshark -r /tmp/mozilla/*BFR -T fields -e ip.id | sort | uniq -c | sort -n | tail -10 46 0x000000d0 56 0x0000006a 57 0x0000009c 58 0x00000042 105 0x00000068 205 0x0000005c 363 0x00000046 607 0x00000090 1433 0x00000000 5612 0x0000004c $
Asked: 2021-05-18 18:35:20 +0000
Seen: 562 times
Last updated: May 19 '21