Re: transmech MTU comments

["Chirayu Patel" <chirayu@chirayu.org>]

On Wed, 19 Nov 2003 17:33:05 -0800, "Fred Templin"
<ftemplin@iprg.nokia.com> said:
> As to the setting of the fragment ID field, my suggested text above
> reflects my best understanding of the normative ref's, but I believe we
> have the following problem. What if the original IPv6 source wanted to
> do host-based IPv6 fragmentation (e.g., for large UDP packets) even
> though the IPv6 path MTU was less than 1280 bytes?
>
> The source would send a series of N IPv6 fragments, each of which would
> have the same value in  the fragment ID field. But then, the tunnel
> encapsulator would use IPv4 fragmentation to split each of the N IPv6
> fragments into M IPv4 fragments again using the *same* fragment ID
> value! We would then have a collision in the decapsulator's

See the text below from 2460. The word used is "suitable", and not
"same".

   In response to an IPv6 packet that is sent to an IPv4 destination
   (i.e., a packet that undergoes translation from IPv6 to IPv4), the
   originating IPv6 node may receive an ICMP Packet Too Big message
   reporting a Next-Hop MTU less than 1280.  In that case, the IPv6 node
   is not required to reduce the size of subsequent packets to less than
   1280, but must include a Fragment header in those packets so that the
   IPv6-to-IPv4 translating router can obtain a suitable Identification
   value to use in resulting IPv4 fragments.  Note that this means the
   payload may have to be reduced to 1232 octets (1280 minus 40 for the
   IPv6 header and 8 for the Fragment header), and smaller still if
   additional extension headers are used.

> IPv4 reassembly buffer, since there would be no way of knowing to which
> one of the N IPv6 fragments a particular IPv4 fragment belonged!