Hi, Philip, On 01/27/2012 02:36 PM, Philip Homburg wrote: >> (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.
There are always tradeoffs in the IP-ID generation algorithms. If you don't like any of the forementioned approaches, you may have a set of counters (say, 1024, 2048, or 65K, if you will), using an approach similar to that of algorithm 2 in my flowlabel I-D. Note, however, that if you cannot maintain a destinations cache, you may also have issues with PMTUD, etc. I'd argue that the scenario that you're describing, while not uncommon, probably does not apply for the general case. So it would not be unfair to have, at least for those scenarios, some specialized policy such as the one described above. > 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). You need to have sufficient packet loss. at which point, the IP ID gets trashed. > 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. Not sure what you mean. As long as one packet gets lost, the IP ID space will get trashed. If another packet reuses the same ID, then it's very likely that the reassembly process will fail, and it may be even possible that some of the legitimate fragments remain in the fragment reassembly buffer, trashing the IP ID space. > 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. Well, yes, there's no such a thing as a "free lunch". > 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. So... you're essentially relying on guesswork because: a) You consider that requiring the translator to send an ICMPv6 PTB is way too much, (which is already a requirement for PMTUD), and, b) You consider that processing atomic fragments as described in draft-gont-6man-ipv6-atomic-fragment is... what? I'd rather patch what needs to be patched (see OpenBSD's patch for the atomic-fragments thing), and be done with it, rather than relying on guesswork/assumptions. Thanks, -- Fernando Gont SI6 Networks e-mail: [email protected] PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492 -------------------------------------------------------------------- IETF IPv6 working group mailing list [email protected] Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 --------------------------------------------------------------------
