On 7/19/11 8:51 AM, Philip Homburg wrote:
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?
Depends whether it is truly random, or pseudo-random, or random initial
value plus an monotonic increment.
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.
RFC 2460 doesn't use MUST/SHOULD/MAY RFC 2119 language, hence it is a
bit hard to gauge the strength of its text.
RFC 2460 does contain this text:
* "recently" means within the maximum likely lifetime of a packet,
including transit time from source to destination and time spent
awaiting reassembly with other fragments of the same packet.
However, it is not required that a source node know the maximum
packet lifetime. Rather, it is assumed that the requirement can
be met by maintaining the Identification value as a simple, 32-
bit, "wrap-around" counter, incremented each time a packet must
be fragmented
Erik
--------------------------------------------------------------------
IETF IPv6 working group mailing list
[email protected]
Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------
