Network Working Group F. Templin, Ed.
Internet-Draft Boeing Research & Technology
Updates: RFC2784, RFC2890 (if approved) April 8, 2015
Intended status: Informational
Expires: October 10, 2015

GRE Tunnel Fragmentation


GRE tunnels use IPv4 or IPv6 fragmentation of the delivery packet when the delivery packet exceeds the tunnel MTU, or when otherwise necessary. This can cause problems when unmitigated IPv4 fragemntation ensues, or when middleboxes drop IPv6 fragments unconditionally. This document proposes GRE tunnel fragmentation which avoids these pitfalls..

Status of This Memo

This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79.

Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet-Drafts is at

Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress."

This Internet-Draft will expire on October 10, 2015.

Copyright Notice

Copyright (c) 2015 IETF Trust and the persons identified as the document authors. All rights reserved.

This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents ( in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.

Table of Contents

1. Introduction

GRE is specified in [RFC2784] and [RFC2890]. 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 fragmentation of the delivery packet, but this can cause problems in some applications. A third option (introduced here) is for the GRE tunnel to perform tunnel fragmentation and reassembly on the payload packet.

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 fragmentation method was first suggested in Section 3.1.7 of [RFC2764], and also appears in more recent works [I-D.templin-aerolink] [I-D.herbert-gue-fragmentation].

2. GRE Fragmentation Header

Figure 1 shows the GRE header as specified in [RFC2784][RFC2890] but with a new optional "Fragment Header" and two new control bits ("F" and "D"):

    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   |C| |K|S|F|D|  Reserved0  | Ver |         Protocol Type         |
   |      Checksum (optional)      |       Reserved1 (Optional)    |
   |                         Key (optional)                        |
   |                 Sequence Number (Optional)                    |
   |                 Fragment Header (Optional)                    |
   |                                                               |

Figure 1: GRE Header with Fragment Header

In this format, when the "F" bit is set to 1 the GRE header includes a Fragment header formatted as specified in Section 4.5 of [RFC2460]. When the "D" bit is set to 1, this serves as an indicating to any further GRE encapsulations in the path (i.e., either a nested encapsulation or a re-encapsulation) that the GRE packet must not be fragmented (further).

3. GRE Tunnel Fragmentation Procedures

GRE tunnel 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. The first fragment therefore includes the GRE payload headers and first portion of the GRE payload data, while subsequent fragments include the remaining portions of the GRE payload data. The GRE tunnel ingress then sends each fragment to the GRE tunnel egress. Apart from the appearance of the Fragment Header within the GRE header, the fragmentation procedure is the same as for IPv6 fragmentation.

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. Apart from the appearance of the Fragment Header within the GRE header, the reassembly procedure is the same as for IPv6 reassembly.

In order to support this 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). The GRE tunnnel egress MUST therefore configure a minimum MRU of 2KB, and MAY configure a larger MRU.

4. IANA Considerations

This document introduces no IANA considerations.

5. Security Considerations


6. Acknowledgements


7. References

7.1. Normative References

[RFC0791] Postel, J., "Internet Protocol", STD 5, RFC 791, September 1981.
[RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6 (IPv6) Specification", RFC 2460, December 1998.
[RFC2764] Gleeson, B., Heinanen, J., Lin, A., Armitage, G. and A. Malis, "A Framework for IP Based Virtual Private Networks", RFC 2764, February 2000.
[RFC2784] Farinacci, D., Li, T., Hanks, S., Meyer, D. and P. Traina, "Generic Routing Encapsulation (GRE)", RFC 2784, March 2000.
[RFC2890] Dommety, G., "Key and Sequence Number Extensions to GRE", RFC 2890, September 2000.

7.2. Informative References

[I-D.herbert-gue-fragmentation] Herbert, T. and F. Templin, "Fragmentation option for Generic UDP Encapsulation", Internet-Draft draft-herbert-gue-fragmentation-00, March 2015.
[I-D.templin-aerolink] Templin, F., "Transmission of IP Packets over AERO Links", Internet-Draft draft-templin-aerolink-52, February 2015.

Author's Address

Fred L. Templin (editor) Boeing Research & Technology P.O. Box 3707 Seattle, WA 98124 USA EMail: