Re: [PATCH net-next-2.6] ipv6: make fragment identifications less predictable

[Rick Jones <rick.jones2@hp.com>]

On 07/21/2011 04:37 PM, Fernando Gont wrote:
> On 07/21/2011 07:17 PM, David Miller wrote:
>>> Does it make sense to go in this direction rather than simply randomize
>>> the IPv6 Fragment Identification?
>>
>> We could, but that's actually a bit more work.
>>
>> You have to avoid recycling IDs to the same destination host otherwise
>> a retransmit could use the same ID and overlap with a previous set of
>> frags, causing corruption.
>>
>> This means if you go the "pure random" route, you have to make sure
>> that the 32-bit series produced by the random number generator is
>> maximally long.  This is why openbsd uses an ID generator based upon
>> skip32 etc.
>
> That scenario assumes packet reordering and/or packet loss.

Isn't that a given?  I mean if there were no packet reordering or packet 
loss then the size of the ID space wouldn't matter right? The fragments 
would be sent, in order and without loss and all would be happiness and 
joy.  It is only because there is packet reordering and/or packet loss 
that we care about the size of the ID space and the time to reuse of a 
given ID.

And indeed, fragmentation is considered bad, and was considered bad 
enough that the "revenge of the router guys" that is IPv6 punted it to 
the end systems, and yes, one should use PMTUD. Which is all well and 
good when 999 times out of 1 traffic is flowing over a transport that 
does its own segmentation and reassembly.  And when IPv6 got spec'ed it 
looked to all the world that UDP was on the way out - NFS was migrating 
over to TCP, and DNS was "never" more than 512 byte messages. No problem 
right?  But since then we've gotten things like EDNS which will be 
sending DNS messages in UDP datagrams that will have to be fragmented, 
PMTUD notwithstanding.

rick jones
almost certainly fumbled a TLA in there somewhere :)