OS X Monterey / IP ID 0x0000

IPID

asked 2022-02-18 23:48:52 +0000

Stuart Kendrick
1 ●1 ●4 ●8

updated 2022-02-19 00:16:39 +0000

I'm analyzing a pcap capturing everything that an OS X box (running some recent flavor of Monterey) is producing ... and I notice that this stack mostly sets IP ID i to 0x0000. Sometimes, it starts incrementing by 1, e.g. 0x0000, 0x0001, 0x0002, 0x0003 ... but it generally doesn't get far before it returns to 0x0000 At the moment, I'm filtering on tcp.port==443

I haven't seen this behavior -- I'm used to seeing IP ID number increasing steadily, then wrapping at 0xFFFF and starting over

Would anyone care to speculate as to why an OS might not want to bother setting IP ID? Thinking about this, I suppose a non-zero IP ID is not essential to the success of a conversation ... it is only needed for IP fragmentation, and the Do not Fragment bit is set in these frames ... but it seems odd to me

--sk

Stuart Kendrick

edit retag flag offensive close merge delete

add a comment

answered 2022-02-19 03:23:31 +0000

Jim Aragon
7512 ●7 ●71 ●128 Fairfield, California

updated 2022-02-19 03:25:00 +0000

RFC 6864, "Updated Specification of the IPv4 ID field," in section 4 defines "atomic datagrams" as "datagrams not yet fragmented and for which further fragmentation has been inhibited." That is, further fragmentation has been inhibited by setting the Don't Fragment bit. So, they haven't been fragmented and they won't be fragmented. In section 4.1 it states "In atomic datagrams, the IPv4 ID field has no meaning; thus, it can be set to an arbitrary value...."

So, there are some IPv4 hosts that continue to increment the IP ID field in atomic datagrams, regardless of the fact that the field is meaningless in those packets, and, as you see, there are other hosts that just put zero in the IP ID field. They can put any value, but if they aren't going to increment to the next IP ID value, they generally put zero.

All IPv4 hosts are required to handle IP datagrams of at least 576 bytes, so IP datagrams that are 576 bytes or less also will not be fragmented, regardless of whether the Don't Fragment bit is set or not, so some hosts will also put zero in the IP ID field if the packet is 576 bytes or less, although that case is not discussed in RFC 6864.

Technically, an atomic datagram is defined in RFC 6864 as: The Don't Fragment bit is set, the More Fragments bit is not set, and the Fragment Offset is 0.

edit flag offensive delete link

Comments

Small correction to the following:

All IPv4 hosts are required to handle IP datagrams of at least 576 bytes, so IP datagrams that are 576 bytes or less also will not be fragmented

RFC 791 states:

All hosts must be prepared to accept datagrams of up to 576 octets (whether they arrive whole or in fragments).

So, these datagrams can be fragmented, but generally won't as the MTU of most links is large enough to pass them unfragmented.

SYN-bit ( 2022-02-20 09:33:58 +0000 )edit

I see. So since the IP Ident field is not required for frames flagged as Don't Fragment, some stacks set it to an arbitrary value, like 0x0000, disappointing network analysts like myself but nevertheless RFC-compliant

Thank you

--sk

Stuart Kendrick ( 2022-02-21 12:26:37 +0000 )edit

add a comment

OS X Monterey / IP ID 0x0000

1 Answer

Comments

Your Answer

Question Tools

Stats

OS X Monterey / IP ID 0x0000 edit

1 Answer

Comments

Your Answer

Question Tools

Stats

OS X Monterey / IP ID 0x0000