To be constructive, one way forward would be to define a new field in the GRE header called the "fragment" field. It would be used to fragment the payload packet prior to encapsulating each fragment in a separate delivery header. This would be an example of tunnel fragmentation as suggested in Section 3.1.7 of RFC2764.
End result is that the tunnel egress still has to reassemble, but the system would not run afoul of IPv4 nor IPv6 fragmentation pitfalls since everything would look like a whole (unfragmented) packet to the underlying links inside the tunnel. 'draft-templin-aerolinlk' is one example of this; 'draft-herbert-gue-fragmentation' is a second. Thanks - Fred [email protected] > -----Original Message----- > From: Int-area [mailto:[email protected]] On Behalf Of Templin, Fred L > Sent: Wednesday, April 08, 2015 11:00 AM > To: Brian Haberman; [email protected]; [email protected] > Subject: Re: [Int-area] AD Evaluation: draft-ietf-intarea-gre-mtu > > Hi, > > Just looking now, this document is seriously messed up. It leaves open > the possibility for denial of service to IPv6 packets of 1280 bytes or > smaller which is a violation of the robustness principle. I had the same > comment regarding the other GRE document. > > If people want to see how to handle tunnel MTU, please review > Section 3.13 of draft-templin-aerolink. > > Thanks - Fred > [email protected] > > > -----Original Message----- > > From: Int-area [mailto:[email protected]] On Behalf Of Brian > > Haberman > > Sent: Wednesday, April 08, 2015 9:55 AM > > To: [email protected]; [email protected] > > Subject: [Int-area] AD Evaluation: draft-ietf-intarea-gre-mtu > > > > All, > > I have completed my AD Evaluation of draft-ietf-intarea-gre-mtu as > > a part of the publication process. I only have a few minor comments for > > the authors to address. Once that is done, I will start the IETF Last Call. > > > > * Section 1 - The 4th paragraph specifies that the techniques described > > in this document are limited on what protocols can be in the GRE > > payload, but doesn't say anything about the delivery protocol. The > > Terminology section indicates only v4 and v6 are applicable as the > > delivery protocol discussed in this document. I think it would be > > useful to expand the 4th paragraph of the intro to mention the limit on > > the delivery protocol. > > > > * Section 1.1 > > > > - s/specific MTU discovery/specific to MTU discovery/ > > > > - The definition of "fragmentable packet" should include mention of IPv6 > > > > - The definition of PTB should be consistent and indicate that IPv6 uses > > ICMPv6 Type=2 for PTB messages. > > > > * Section 2.2 - I would suggest clarifying the first bullet by saying > > that the fragmentation logic is derived from the payload protocol. > > > > Regards, > > Brian > > _______________________________________________ > Int-area mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/int-area _______________________________________________ Int-area mailing list [email protected] https://www.ietf.org/mailman/listinfo/int-area
