GRE Tunnel Level Fragmentation

GRE is specified in the following RFCs: . GRE fragmentation considerations are further discussed in . In its current manifestation, GRE allows for fragmentation of the payload packet only if it is an IPv4 packet with the Don't Fragment (DF) bit set to 0. GRE also allows for IP fragmentation of the delivery packet, but IP fragmentation has been shown to be susceptible to reassembly errors at high data rates and IP fragments may be unconditionally dropped by some middleboxes [I-D.taylor-v6ops-fragdrop]. A third option (introduced here) is for the GRE tunnel to perform "tunnel level" fragmentation and reassembly on the payload packet at the GRE layer. In this way, the ingress can fragment the payload packet (while treating the payload packet's headers as ordinary data) and encapsulate each fragment in a separate delivery header. The GRE header requires a new fragment header field to support this. This tunnel level fragmentation method was first suggested in Section 3.1.7 of , and also appears in more recent works . provides the architectural background for tunnel fragemntation and reassembly.

shows the GRE header as specified in but with a new optional "Fragment Header" and a new control bit "F":

In this format, when the "F" bit (i.e., bit 8) is set to 1 the GRE header includes a Fragment header formatted as follows:

The fields of the option are: Fragment offset: This field indicates where in the datagram this fragment belongs. The fragment offset is measured in units of 8 octets (64 bits). The first fragment has offset zero. Res: Two bit reserved field. Must be set to zero for transmission. If set to non-zero in a received packet then the packet MUST be dropped. M: More fragments bit. Set to 1 when there are more fragments following in the datagram, set to 0 for the last fragment. Reserved(2): Eight bit reserved field. Must be set to zero for transmission. If set to non-zero in a received packet then the packet MUST be dropped. Identification: 40 bits. Identifies fragments of a fragmented packet. Note that these formats are the same as specified in with the exception that the Reserved(2) field replaces the "Original Type" field since the GRE header already includes a Protocl Type.

GRE tunnel level fragmentation treats the entire GRE payload packet (including the payload headers) as opaque data. The GRE tunnel ingress breaks the payload packet into N fragments and encapsulates each fragment in a separate GRE header and GRE delivery header. For the first fragment, the ingress writes the IEEE802 protocol number in the Protocol Type field the same as for any GRE packet. For other fragments, the ingress instead writes the length of the fragment in the Protocol Type field. This value MUST be no larger than 1500, which the egress will interpret as a length instead of a protocol type. (This implies that the maximum size for a non-initial fragment is 1500 bytes.) The GRE tunnel ingress then sends each fragment to the GRE tunnel egress. When the GRE tunnel egress receives the fragments, it reassembles the GRE payload packet by concatenating the data portions of each fragment according to their offsets. In order to support this tunnel level fragmentation and reassembly procedure, the GRE tunnel ingress must know the maximum sized packet the GRE tunnel egress is capable of reassembling, i.e., the Maximum Reassembly Unit (MRU). In order to avoid interactions with Path MTU Discovery, the GRE tunnel egress MUST configure a minimum MRU of 1500 bytes plus the GRE delivery encapsulation overhead, and MAY configure a larger MRU.

This document introduces no IANA considerations.

Security considerations for GRE apply also to this document.

The following are acknowledged for their helpful comments: Tom Herbert, Carlos Pignataro, Joe Touch.