In your letter dated Fri, 27 Jan 2012 13:19:24 -0300 you wrote: >On 01/27/2012 08:13 AM, Philip Homburg wrote: >> Given the current trends, just a random number would be good enough. But the >> old RFCs assumed that a sequence number was used to maintain uniqueness. > >May I ask what the "current trends" are? And no, just a random number is >not good enough, particularly if you're talking about the IPv4 IP ID. >(talk about collisions). > >(For IPv6, I suggest that you talk with davem@, which noted that we >would not even want such a scheme for the IPv6 (i.e., 32-bit long) >fragment ID).
For avoiding collissions, a single global counter is optimal. To avoid traffic analysis, a counter per destination is proposed. But how do you initialize that counter? From a random number. So any system that is too busy to keep destination cache entries for a long time will effectively send fragments with a random number. Now for IPv4, to get a reasonable chance of a collision, you have to have 256 fragmented packets in flight at the same time between a source/destination pair (ignoring protocol for the moment). Then you also need those packets to either suffer the loss of a fragment (all at the same time) or you need sufficient reordering that 256 packets somehow overlap during fragmentation. And when that happens, the normal TCP/UDP checksum is likely to throw out all but one in 65535 packets. And anythingh encrypted will just see a loss of a connection. To improve on that, an IPv6 fragment header has to have a counter in the lower 16 bits (the part that gets copied to the IPv4 header). That means that if the sender deletes to destination cache entry before all unassembled packets have been deleted or in flight packet have arrive, you are back in trouble. And that also assumes that the IPv4/IPv6 translator will never map two IPv6 source addresses to one IPv4 source address, because then the whole thing also falls over. So, as far as I can tell, the risk that something goes wrong if you don't send the fragment header is something very close to zero. The chance that sending the fragment header is actually beneficial is also very small. -------------------------------------------------------------------- IETF IPv6 working group mailing list [email protected] Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 --------------------------------------------------------------------
