Guys,
I would like to suggest that this discussion is beyond the scope of
draft-ietf-intarea-gre-ipv6. The chairs may correct me, but it might even be
outside the scope of this WG.
Ron
> -----Original Message-----
> From: Templin, Fred L [mailto:[email protected]]
> Sent: Friday, February 27, 2015 6:51 PM
> To: Joe Touch; Ronald Bonica; Carlos Pignataro (cpignata)
> Cc: [email protected]
> Subject: RE: [Int-area] draft-ietf-intarea-gre-ipv6
>
> Hi Joe,
>
> > -----Original Message-----
> > From: Joe Touch [mailto:[email protected]]
> > Sent: Friday, February 27, 2015 3:35 PM
> > 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 3:22 PM, Templin, Fred L wrote:
> > > Hi Joe,
> > ...
> > >> I.e., this is consistent with IPv4 allowing on-path fragmentation,
> > >> and consistent with IPv6 never fragmenting on-path.
> > >
> > > You are being dogmatic for no good reason.
> >
> > RFC2460 forbids it *explicitly*.
> >
> > That's a good reason.
>
> You are still being too dogmatic. For atomic fragments, the situation is no
> different than for an IPv6/IPv4 translator. In fact, it is even better because
> the IPv6 tunnel ingress knows that the final destination is required to
> reassemble at least 1500. For an IPv6/IPv4 translator on the other hand, all
> the translator is assured is 576.
>
> I do not see any "MUST NOTs" in RFC2460, nor any dire consequences for
> allowing a tunnel ingress to fragment atomic fragments. So, if we update the
> final paragraph of Section 5 of RFC2460 we should be good to go.
>
> Thanks - Fred
> [email protected]
>
> > Joe
_______________________________________________
Int-area mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/int-area
