Hi Fernando, > -----Original Message----- > From: Fernando Gont [mailto:fg...@si6networks.com] > Sent: Tuesday, December 18, 2012 12:00 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 > > Hi, Fred, > > 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). > > As to the "why not", I'd guess the reason is "only IPv6 hosts fragment > packets"
I am thinking of the case of links (e.g., tunnels) in the middle of the network that must perform link adaptation in order to meet the 1280 byte minimum IPv6 MTU. For example, if a tunnel is configured over a link that has an MTU less than (1280+HLEN), the tunnel ingress will see an MTU smaller than 1280. In that case, RFC2473 says that the tunnel ingress should perform fragmentation on the encapsulated packet and the tunnel egress gets to do the reassembly. But, that can amount to a lot of extra work for the tunnel egress. To save the egress from this burden then, it would be great if there were a way to get the source host to perform fragmentation so that the destination gets to do the reassembly. In lieu of that, it would be preferable for the tunnel ingress to perform fragmentation on the inner packet before encapsulation provided the inner packet includes an IPv6 fragment header. I talk about this in my draft on "IPv6 Path MTU Updates": http://www.ietf.org/id/draft-generic-6man-tunfrag-06.txt This document talks about taking care of packets that are in the "red zone" size between 1280 and 1500 bytes when there is a link in the path (e.g., a tunnel) that must perform link adaptation to meet the minimum size. And, it seeks to update RFC2460 by allowing the middlebox to signal the host, and to perform fragmentation on the inner packet when the packet includes an IPv6 fragment header. It would be good to get your feedback on this document. > > If so, > > then shouldn't the draft say something about the permissible > > behavior of middleboxes when forwarding an "atomic" fragment > > (e.g., "a middlebox is permitted to perform fragmentation on > > an "atomic" fragment before forwarding to the next hop")? > > Why should there be a difference between fragmenting an atomic fragment > and e.g. re-fragmenting a non-atomic fragment? Based on the above draft, a host that is clued into the link adaptation requirements will produce non-atomic fragments that are sufficiently small so that they will not trigger the link adaptation. A host that is not clued into the requirements will send atomic fragments, which the middlebox should be permitted to split into multiple fragments. Thanks - 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 --------------------------------------------------------------------
