In your letter dated Tue, 19 Jul 2011 08:18:40 -0700 you wrote: >Then different fragmented datagrams between the same source and dest >traveling through different translators could get the same ID, resulting >in a risk of (persistent) incorrect reassembly.
How can it be persistently incorrect? If translators generate random numbers the chance of collission depends on the number of packets being assembled at the same time. So that should be in the order of 1 in 10000 or so. Of course, this already requires a lot of reordering. Then the data will also be covered by a TCP or UDP checksum. >> How would it generate a unique 16 bit IP ID field from a unique 32 bit >> IP ID field? It can't just discard the upper 16 bits and pretend that >> they aren't required to ensure uniqueness. > >Sure it can; the assumption is that for each <source, dest, protocol> >the fragment IDs are assigned sequentially or otherwise can be truncated >to 16 bits. (I haven't checked what is in RFC on this point though.) RFC-2460 doesn't seem to require sequential. For IPv4 it is good security practice to make it random. -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 --------------------------------------------------------------------
