Rationale for correctly decompressing the IP ID

[Carsten Bormann <cabo@Informatik.Uni-Bremen.DE>]

> If the IP ID is re-assigned the "wrong number" then
> you can end up with troubles ...

While it is clear that our charter calls for a fully transparent
solution, let's try to collect the reasons for investing work in the
IP ID.

My take:

1) For IP packets with the DF (don't fragment) bit unset, you don't
   know whether they will be fragmented at the next hop.
   You can't make up an IP ID because that might collide with one of a
   packet that happens to take a different path (i.e., you
   can't think you are in control of the whole flow).

2) For IP packets with the DF bit set or unset, the IP ID might become
   important in any ICMP packets sent back -- the source might not be
   able to correlate these to the original packet if the IP ID has
   changed.

Any other reasons?  

Does anyone have any anecdotes that underline the importance of (2)?

While talking of IP ID, I know of two good ways to mitigate the IP ID
overhead:

1) Make sure at the source that the IP ID increases in sync with the
   RTP sequence number (e.g., by using the RTP sequence number as IP ID?).
   This allows the decompressor to always have a good prediction of
   the IP ID, so no additional information is necessary to be sent.
   (Unfortunately, right now there is very little support in OS-based
   implementations for this.)

2) Switch to IPv6.  (There is no IP ID in IPv6, except for packets
   that have been fragmented at the source.)

Gruesse, Carsten