Hi Joe, > -----Original Message----- > From: Joe Touch [mailto:[email protected]] > Sent: Friday, February 27, 2015 10:33 AM > To: Templin, Fred L; Ronald Bonica; Carlos Pignataro (cpignata) > Cc: [email protected] > Subject: Re: [Int-area] draft-ietf-intarea-gre-ipv6 > > > > On 2/27/2015 10:25 AM, Templin, Fred L wrote: > ... > >> Or pick another path. Or break. > > > > I don't see anything in the standards that would support either of those > > behaviors. A node that does not handle PTB with MTU<1280 as specified > > in Section 5 of RFC2460 is not compliant with the standards. > > Breaking is what happens when we rely on a code path we don't typically > use. Yes, it's not compliant. > > Nothing in IP REQUIRES an endpoint to "try harder" when it gets an error > message, though. It can always either give up or try another path - > that's compliant.
I agree; shooting its own foot because it does not follow the standards is something we can't do anything about. But, then it is broken and needs to get itself fixed. > >>> The tunnel ingress will then know that it is dealing > >>> with a legacy source, > >> > >> Hosts already generate atomic fragments for other reasons, so that > >> itself isn't enough to "KNOW" anything. > > > > Generation of atomic fragments for any reason is sufficient information > > for the tunnel ingress to make a determination to fragment or drop > > based on the size of the atomic fragment. > > The former is a direct violation of RFC2460. The latter is what > could/should have been done in the first place when the PTB was sent. Network fragmentation of IPv6 packets that do not include a fragment header is the behavior that is prohibited by the specs. Fragmentation of IPv6 packets that include a fragment header is already mandated for IPv6/IPv4 translators. So, given there is already one example of network fragmentation we are simply introducing another example. > >>> and will fragment the payload packet using the > >>> fragment header conveniently provided by the source. > >> > >> That's a violation of on-path fragmentation. RFC2460 gives a very > >> specific reason for those - focusing on IPv6/IPv4 translation: > >> > >> ...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. > > > > It should not be so much of a stretch to update RFC2460 to allow tunnels > > to use the supplied fragment header to fragment the original packet. > > It's a huge stretch to change IPv6 from "never fragment on-path" to > "fragment on-path". "Fragment on-path" is already mandated for IPv6/IPv4 translators. We are only asking for the same behavior for IPv6 tunnels. It will work right out of the box, so why not just do it and update RFC2460 to note the behavior? Thanks - Fred [email protected] > Joe _______________________________________________ Int-area mailing list [email protected] https://www.ietf.org/mailman/listinfo/int-area
