On 7/19/11 2:00 AM, Florian Weimer wrote:
* Erik Nordmark:
The motivation for the fragment header insertion was to be able to
support stateless IPv6->IPv4 translators (with multi-path routing),
such as RFC 2765.
Such a translator normally sets DF (don't fragment) in the IPv4
packets. But should the IPv4 path MTU drop below 1300 (meaning that a
translated 1280 byte IPv6 packet wouldn't fit),
Stateless gateways cannot perform path MTU discovery, so they don't know
about path MTU, and need to send packets with DF=0.
It is the end hosts that perform pmtu discovery; the translator just
maps from IPv6 to IPv4 and vice versa. Look at RFC 2765 for the details.
then DF can't be set. In that case a unique IP ID field is needed. The
fragment header contains a unique ID which will be used by the
translator.
Why wouldn't the translator be able to pull a random ID out of thin air?
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 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.)
Erik
--------------------------------------------------------------------
IETF IPv6 working group mailing list
ipv6@ietf.org
Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------
