Hi Fernando,
> -----Original Message----- > From: Fernando Gont [mailto:fg...@si6networks.com] > Sent: Thursday, December 20, 2012 9:09 PM > To: Templin, Fred L > Cc: draft-ietf-6man-ipv6-atomic-fragme...@tools.ietf.org; 6man WG > Subject: Re: AD Evaluation: draft-ietf-6man-ipv6-atomic-fragments > > On 12/20/2012 03:04 PM, Templin, Fred L wrote: > >> On 12/18/2012 04:13 PM, Templin, Fred L wrote: > >>> I have a question about this document. Is a middlebox permitted > >>> to fragment an "atomic" fragment before forwarding the packet > >>> on to the next hop? If not, why not - after all, that's why the > >>> host inserted the fragment header in the first place. > >> > >> My take is that an *IPv6* middle-box is not permitted to fragment the > >> packet. The IPv6/IPv4 translator is, from an IPv6 point of view, a > >> host/end-point/end-system (that's where the v6 world ends for that > >> packet). > > > > On further thought, I don't fully accept the notion that the > > translator is a host/end-point/end-system. > > From the pov of the IPv6 network that's where the packet "ends". Right, with an asterisk next to "ends" (*). IPv6 information does carry forward beyond the translator the same as IPv4 information carries forward for IPv4 packets from a private network transiting an IPv4 translator to the public IPv4 network. > > The IPv6 host provides > > the translator with an Identification value, and that value carries > > forward into the IPv4 world. So, while the IPv6 packet itself does > > not carry forward, IPv6 information does. > > Yes and no -- e.g., you cannot use the full 32-bit Frag ID. Right, but the lower 16 bits does come from IPv6-land. > >> As to the "why not", I'd guess the reason is "only IPv6 hosts fragment > >> packets" > > > > I think there would need to be an asterisk next to that statement > > saying that IPv6/IPv4 translators are exempt from this requirement. > > And, if the translator can be exempt then so also should an IPv6 > > middlebox that connects to a link that would otherwise be obliged > > to perform burdensome link adaptation. > > This does not only apply to tunnels. One could think of some radio > devices, embedded systems, etc., for which an adaptation layer would > possible be overkill. -- So you're idea sounds, at least in principle, > sensible to me. I agree, and constrained radio links are a key area of interest. > I will review your I-D and will come back with some feedback. Thanks for the further analysis, and I look forward to your thoughts on the draft. Fred fred.l.temp...@boeing.com > Thanks! > > Best regards, > -- > Fernando Gont > SI6 Networks > e-mail: fg...@si6networks.com > PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492 > > > -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 --------------------------------------------------------------------
