Hi Ron, The document needs to talk about packet sizes for IP payload packets. For IP payload packets no larger than MINMTU bytes, the GRE tunnel MUST accommodate the packet even if a small amount of fragmentation is necessary. (Here, the mandatory MINMTU for IPv6 is 1280 and the recommended MINMTU for IPv4 is also 1280.)
Beyond MINMTU, there needs to be a balance between avoiding path MTU related black holes for the source and avoiding excessive fragmentation at the GRE tunnel egress. This balance is situation dependent. For example, if the GRE tunnel ingress is located close to the source, it should be reasonable to expect that the source would be able to receive any ICMP PTB messages sent by the ingress. Or, if the GRE tunnel egress is located close to the destination, it should be reasonable to expect that the egress can perform a small amount of reassembly. If the GRE tunnel ingress is located "far" from the source, then it must strive to ensure that packets up to 1500 bytes are accommodated even if a small amount of fragmentation is necessary, since 1500 is the MTU size configured by the vast majority of host links in the Internet. For packets larger than 1500 bytes, the GRE tunnel ingress should not allow fragmentation, as this would cause excessive reassembly for the tunnel egress. So, a suitable algorithm for the GRE tunnel ingress would be: 1) For IP payload packets no larger than MINMTU, encapsulate in the GRE delivery headers (with DF=0 in the outer IP header for IPv4). If the packet is larger than GMTU, fragment the delivery packet and send all fragments to the tunnel egress (or, for IPv4, allow the network to do the fragmentation). (If the delivery packet did not require fragmentation, then just send unfragmented.) 2) For IP payload packets larger than MINMTU but no larger than 1500, if the packet is larger than GMTU and the ingress is located near the source, drop the packet and return an ICMP PTB. Otherwise, encapsulate in the GRE delivery headers (DF=0). If the payload packet is larger than GMTU, fragment the delivery packet and send all fragments to the tunnel egress (or, for IPv4, allow the network to do the fragmentation). (If the delivery packet did not require fragmentation, then just send unfragmented.) 3) For IP payload packets larger than 1500, if the packet is larger than GMTU drop and return an ICMP PTB. If the packet is no larger than GMTU, encapsulate and send unfragmented with DF=1. In this algorithm, if IPv4 is used as the delivery protocol and there is reason to believe that some fragmentation may occur on the path, the GRE tunnel ingress MUST institute rate limiting per RFC6864 to ensure that no reassembly misassociations occur. The ingress can test to see if fragmentation is needed by sending an occasional encapsulated 1500 byte "ping" packet to the egress for which no fragmentation is permitted. If the ping succeeds, the ingress can suspend fragmentation and/or rate limiting. (This would constitute RFC4821 for tunnels.) As an added means for minimizing fragmentation, the GRE tunnel ingress can use MSS clamping to rewrite the TCP MSS size in the IP payload packet to a smaller size [RFC0879][RFC6691]. This option may not be available to all GRE tunnel ingresses however (e.g., if there are multiple nested levels of encapsulation). An underlying assumption in all of this is that sources that send IP packets larger than 1500 are expected to use RFC4821 to ensure that the larger packets are not being dropped into a black hole. This should become a BCP recommendation for the Internet even without respect to tunneling. Thanks - Fred [email protected] > -----Original Message----- > From: Int-area [mailto:[email protected]] On Behalf Of Ronald Bonica > Sent: Friday, February 14, 2014 12:26 PM > To: [email protected] > Subject: [Int-area] FW: New Version Notification for > draft-bonica-intarea-gre-mtu-04.txt > > Folks, > > Please review and comment > > Ron > > > > -----Original Message----- > From: [email protected] [mailto:[email protected]] > Sent: Friday, February 14, 2014 3:06 PM > To: Ronald Bonica; Dr. Joseph D. Touch; Joe Touch; Carlos Pignataro; Ronald > Bonica; Carlos Pignataro > Subject: New Version Notification for draft-bonica-intarea-gre-mtu-04.txt > > > A new version of I-D, draft-bonica-intarea-gre-mtu-04.txt > has been successfully submitted by Ron Bonica and posted to the IETF > repository. > > Name: draft-bonica-intarea-gre-mtu > Revision: 04 > Title: A Fragmentation Strategy for Generic Routing > Encapsulation (GRE) > Document date: 2014-02-12 > Group: Individual Submission > Pages: 11 > URL: > http://www.ietf.org/internet-drafts/draft-bonica-intarea-gre-mtu-04.txt > Status: https://datatracker.ietf.org/doc/draft-bonica-intarea-gre-mtu/ > Htmlized: http://tools.ietf.org/html/draft-bonica-intarea-gre-mtu-04 > Diff: > http://www.ietf.org/rfcdiff?url2=draft-bonica-intarea-gre-mtu-04 > > Abstract: > This memo specifies a default GRE tunnel fragmentation strategy, > which has been implemented by many vendors and widely deployed on the > Internet. > > This memo also specifies requirements for GRE implementations. > Having satisfied these requirements, a GRE implementation will > execute the default GRE tunnel fragmentation strategy, specified > herein, with minimal configuration. However, with additional > configuration, the GRE implementation can execute any of the tunnel > fragmentation strategies defined in RFC 4459. > > > > > > Please note that it may take a couple of minutes from the time of submission > until the htmlized > version and diff are available at tools.ietf.org. > > The IETF Secretariat > > > > _______________________________________________ > 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
