Re: [Int-area] draft-ietf-intarea-gre-ipv6

["Templin, Fred L" <[e-mail]>]

Hi Joe,

> -----Original Message-----
> From: Joe Touch [mailto:[e-mail]]
> Sent: Friday, February 27, 2015 10:05 AM
> To: Templin, Fred L; Ronald Bonica; Carlos Pignataro (cpignata)
> Cc: [e-mail]
> Subject: Re: [Int-area] draft-ietf-intarea-gre-ipv6
> 
> 
> 
> On 2/26/2015 3:32 PM, Templin, Fred L wrote:
> > Hi Joe,
> >
> >> -----Original Message-----
> >> From: Joe Touch [mailto:[e-mail]]
> >> Sent: Thursday, February 26, 2015 3:11 PM
> >> To: Templin, Fred L; Ronald Bonica; Carlos Pignataro (cpignata)
> >> Cc: [e-mail]
> >> Subject: Re: [Int-area] draft-ietf-intarea-gre-ipv6
> >>
> >>
> >>
> >> On 2/26/2015 3:00 PM, Templin, Fred L wrote:
> >>> Hi Joe,
> >>>
> >>>> -----Original Message-----
> >>>> From: Joe Touch [mailto:[e-mail]]
> >>>> Sent: Thursday, February 26, 2015 2:11 PM
> >>>> To: Templin, Fred L; Ronald Bonica; Carlos Pignataro (cpignata)
> >>>> Cc: [e-mail]
> >>>> Subject: Re: [Int-area] draft-ietf-intarea-gre-ipv6
> >>>>
> >>>>
> >>>>
> >>>> On 2/25/2015 4:01 PM, Templin, Fred L wrote:
> >>>> ...
> >>>>> I have proposed  sending PTB with MTU less than 1280 before as well:
> >>>>>
> >>>>>      http://www.ietf.org/archive/id/draft-templin-6man-linkadapt-01.txt
> >>>>>
> >>>>> The idea is to enlist the original source’s aid in easing the frag/reass
> >>>>> burdens from the tunnel ingress and egress.
> >>>>
> >>>> IMO, PTB is the wrong message for that.
> >>>
> >>> What we have today is a "Type 0" PTB message.
> >>
> >> There are may types for both IPv4 and IPv6.
> >>
> >> For IPv4, e.g., PTB is type 3, code 4.
> >>
> >> For IPv6, it would be type 2, code 0.
> >
> > "type 2, code 0" is what I meant when I said "Type 0", yes.
> >
> >>> What I proposed was a "Type 1" PTB message.
> >>
> >> For IPv6, did you mean type 2, code 1?
> >
> > Yes; "type 2, code 1" is what I meant when I said "Type 1".
> >
> >> The problem is that legacy receivers will interpret type 2 and ignore
> >> the code.
> >
> > Yes, but I do not see a problem. If the size reported in the PTB is less than
> > 1280 the source will send subsequent messages as "atomic fragments" per
> > Section 5 of RFC2460.
> 
> 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.

> That's a code path that isn't commonly exercised.

If that code path is exercised, then the node is shooting itself in the foot
because it is not standards-compliant.

> > 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. If the atomic fragment is no
larger than the tunnel MTU, encapsulate  and send unfragmented. Else,
if the atomic fragment is no larger than 1500, fragment to the tunnel
MTU size. Else, drop and send PTB with code=0.

> > 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.
After all, it was the original source itself that supplied the fragment
header including an Identification value of the source's own choosing.

> We could argue that this should apply to how fragments tunneled to guide
> fragmentation and reassembly in the encapsulating layer (e.g., the
> "outer" header), but not to fragment the packet that arrives.

Why not? The original source included a good fragment header with
a good Identification value. Having the tunnel ingress fragment it would
be exactly the same as if the original source had fragmented it on its own
behalf.

Thanks - Fred
[e-mail]

> However, all of this is out of scope of the doc we're currently discussing.
> 
> Joe