Re: [rohc] Rationale for correctly decompressing the IP ID

[Erik Nordmark <Erik.Nordmark@eng.sun.com>]

> 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).

Also, packets with the DF bit set might already be fragmented (by the source).
Thus independent of DF fragments must have their IP ID preserved.

> 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)?

I don't have any.
However, one could envision an implementation that checks that an
IP ID was recently used when sending packets before accepting an
ICMP error with that IP ID in the "packet in error".
I have no idea if anybody has built such a "paranoid" implementation.

   Erik