First time here? Check out the FAQ!
THIS IS A TEST INSTANCE. Feel free to ask and answer questions, but take care to avoid triggering too many notifications.
Ask Your Question
0

OS X Monterey / IP ID 0x0000

  • retag add tags

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

Stuart Kendrick's avatar
1
Stuart Kendrick
asked 2022-02-18 23:48:52 +0000, updated 2022-02-19 00:16:39 +0000
edit flag offensive 0 remove flag close merge delete

Comments

add a comment see more comments

1 Answer

0

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.

Jim Aragon's avatar
7.5k
Jim Aragon
answered 2022-02-19 03:23:31 +0000, updated 2022-02-19 03:25:00 +0000
edit flag offensive 0 remove flag delete link
more

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's avatar SYN-bit (2022-02-20 09:33:58 +0000) edit
more
  • delete

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's avatar Stuart Kendrick (2022-02-21 12:26:37 +0000) edit
more
  • delete
add a comment see more comments

Your Answer

Please start posting anonymously - your entry will be published after you log in or create a new account. This space is reserved only for answers. If you would like to engage in a discussion, please instead post a comment under the question or an answer that you would like to discuss.

Add Answer