Network Working Group | F. Templin, Ed. |
Internet-Draft | Boeing Research & Technology |
Updates: RFC2784, RFC2890 (if approved) | January 26, 2016 |
Intended status: Informational | |
Expires: July 29, 2016 |
GRE Tunnel Fragmentation
draft-templin-intarea-grefrag-02.txt
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 introduces GRE tunnel fragmentation which avoids these pitfalls..
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 http://datatracker.ietf.org/drafts/current/.
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 July 29, 2016.
Copyright (c) 2016 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 (http://trustee.ietf.org/license-info) 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.
GRE is specified in the following RFCs: [RFC2784][RFC2890][RFC7676]. [RFC7588] further discusses GRE fragmentation considerations. 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].
Figure 1 shows the GRE header as specified in [RFC2784][RFC2890] but with a new optional "Fragment Header" and a new control bit "F":
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| 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].
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.
This document introduces no IANA considerations.
TBD.
TBD
[I-D.herbert-gue-fragmentation] | Herbert, T. and F. Templin, "Fragmentation option for Generic UDP Encapsulation", Internet-Draft draft-herbert-gue-fragmentation-02, October 2015. |
[I-D.templin-aerolink] | Templin, F., "Asymmetric Extended Route Optimization (AERO)", Internet-Draft draft-templin-aerolink-65, January 2016. |