[e2e] ICMP & TCP segments with IP ID = 0?

[Jon Crowcroft]

In message <20010516195158.A3788 at fred.local>, Andi Kleen typed:

in the back of my mind there's some sort of idea that we still might
want to be able to tel the difference between an original and a
mistaken copy (loop) for cases where there are < 2^16 packets on
the net at once intentionally (note that 2^16 near MTUs worth of
packets is quite a lot actually - its not a tcp window byte size value
right:-)

but yes, i can think of lots of optimisation/implementation reasons why
zeroing out a packet template once per transport+ip session  
is faster than yet another ++ operation per packet

btw, if you look back in the ipng archives you'll find a proposal from
me and zheng to re-use the ip id field as extra address space (we
trawled all the fields that were in ip that would be freed up if we
knew we could leave out all the things people didnt think were good in
ipv4 like fragmentation, options, etc) - much cleaner than nats and
pnats:-)

of course deadbeef would be just as good a value (if it was 16 bit) as
zero:-)

 >>On Wed, May 16, 2001 at 07:20:44PM +0200, Greg Minshall wrote:
 >>> > Why are they evil? ipid is only useful for defragmentation, and perhaps 
 >>> > to recover from bugs in IP checksum ...
 >>> 
 >>> i think this is one of those "be conservative in what you send" things.  the 
 >>> conservative thing to do, i would argue, is to obey the principle of least 
 >>> surprise and send unique IDs; this is what systems expect, orthogonal from DF 
 >>> or not DF.  (of course, the rest of the world should obey the second half: "be 
 >>> liberal in what you accept", and so deal with ID == 0.)
 >>
 >>The problem is that generating them is relatively costly for various
 >>reasons in current linux (it's a longer story why that is so), and as there
 >>was no good reason found to keep them they were turned off for DF=0. 
 >>
 >>Also I generally don't believe IP IDs are very useful for anything anymore 
 >>with current network speeds, the 16bit space is simply far too small and 
 >>wraps in a jiffy on any reasonable network 
 >>(fortunately fragmentation is not too common anymore and mostly only used
 >>on low latency links, otherwise it would be surely a bigger problem). 
 >>
 >>-Andi

 cheers

   jon