Internet Engineering Task Force (IETF) R. Bonica Request for Comments: 7588 Juniper Networks Category: Informational C. Pignataro ISSN: 2070-1721 Cisco Systems J. Touch USC/ISI July 2015 A Widely Deployed Solution to the Generic Routing Encapsulation (GRE) Fragmentation Problem
AbstractThis memo describes how many vendors have solved the Generic Routing Encapsulation (GRE) fragmentation problem. The solution described herein is configurable. It is widely deployed on the Internet in its default configuration. Status of This Memo This document is not an Internet Standards Track specification; it is published for informational purposes. This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Not all documents approved by the IESG are a candidate for any level of Internet Standard; see Section 2 of RFC 5741. Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at http://www.rfc-editor.org/info/rfc7588.
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 (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. 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3 1.2. Requirements Language . . . . . . . . . . . . . . . . . . 5 2. Solutions . . . . . . . . . . . . . . . . . . . . . . . . . . 5 2.1. RFC 4459 Solutions . . . . . . . . . . . . . . . . . . . 5 2.2. A Widely Deployed Solution . . . . . . . . . . . . . . . 5 3. Implementation Details . . . . . . . . . . . . . . . . . . . 6 3.1. General . . . . . . . . . . . . . . . . . . . . . . . . . 6 3.2. GRE MTU (GMTU) Estimation and Discovery . . . . . . . . . 6 3.3. GRE Ingress Node Procedures . . . . . . . . . . . . . . . 7 3.3.1. Procedures Affecting the GRE Payload . . . . . . . . 7 3.3.2. Procedures Affecting the GRE Deliver Header . . . . . 8 3.4. GRE Egress Node Procedures . . . . . . . . . . . . . . . 9 4. Security Considerations . . . . . . . . . . . . . . . . . . . 9 5. References . . . . . . . . . . . . . . . . . . . . . . . . . 10 5.1. Normative References . . . . . . . . . . . . . . . . . . 10 5.2. Informative References . . . . . . . . . . . . . . . . . 11 Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 12 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 12
RFC2784] [RFC2890] can be used to carry any network-layer protocol over any network-layer protocol. GRE has been implemented by many vendors and is widely deployed in the Internet. The GRE specification does not describe fragmentation procedures. Lacking guidance from the specification, vendors have developed implementation-specific fragmentation solutions. A GRE tunnel will operate correctly only if its ingress and egress nodes support compatible fragmentation solutions. [RFC4459] describes several fragmentation solutions and evaluates their relative merits. This memo reviews the fragmentation solutions presented in [RFC4459]. It also describes how many vendors have solved the GRE fragmentation problem. The solution described herein is configurable and has been widely deployed in its default configuration. This memo addresses point-to-point unicast GRE tunnels that carry IPv4, IPv6, or MPLS payloads over IPv4 or IPv6. All other tunnel types are beyond the scope of this document. RFC2784] and [RFC2890]. Procedures for encapsulating IPv6 in GRE are described in [IPv6-GRE]. Procedures for encapsulating MPLS in GRE are described in [RFC4023]. While other protocols may be delivered over GRE, they are beyond the scope of this document. o GRE delivery packet - a packet containing a GRE delivery header, a GRE header, and the GRE payload.
o GRE payload header - the IPv4, IPv6, or MPLS header of the GRE payload. o GRE overhead - the combined size of the GRE delivery header and the GRE header, measured in octets. The following terms are specific to MTU discovery: o Link MTU (LMTU) - the maximum transmission unit, i.e., maximum packet size in octets, that can be conveyed over a link. LMTU is a unidirectional metric. A bidirectional link may be characterized by one LMTU in the forward direction and another LMTU in the reverse direction. o Path MTU (PMTU) - the minimum LMTU of all the links in a path between a source node and a destination node. If the source and destination nodes are connected through an Equal-Cost Multipath (ECMP), the PMTU is equal to the minimum LMTU of all links contributing to the multipath. o GRE MTU (GMTU) - the maximum transmission unit, i.e., maximum packet size in octets, that can be conveyed over a GRE tunnel without fragmentation of any kind. The GMTU is equal to the PMTU associated with the path between the GRE ingress and the GRE egress nodes minus the GRE overhead. o Path MTU Discovery (PMTUD) - a procedure for dynamically discovering the PMTU between two nodes on the Internet. PMTUD procedures for IPv4 are defined in [RFC1191]. PMTUD procedures for IPv6 are defined in [RFC1981]. The following terms are introduced by this memo: o Fragmentable Packet - a packet that can be fragmented by the GRE ingress node before being transported over a GRE tunnel. That is, an IPv4 packet with the Don't Fragment (DF) bit equal to 0 and whose payload is larger than 64 bytes. IPv6 packets are not fragmentable. o ICMP Packet Too Big (PTB) message - an ICMPv4 [RFC792] Destination Unreachable message (Type = 3) with code equal to 4 (fragmentation needed and DF set) or an ICMPv6 [RFC4443] Packet Too Big message (Type = 2).
RFC2119]. Section 3 of [RFC4459] identifies several tunnel fragmentation solutions. These solutions define procedures to be invoked when the tunnel ingress router receives a packet so large that it cannot be forwarded through the tunnel without fragmentation of any kind. When applied to GRE, these procedures are: 1. Discard the incoming packet and send an ICMP PTB message to the incoming packet's source. 2. Fragment the incoming packet and encapsulate each fragment within a complete GRE header and GRE delivery header. 3. Encapsulate the incoming packet in a single GRE header and GRE delivery header. Perform source fragmentation on the resulting GRE delivery packet. As per RFC 4459, Strategy 2 is applicable only when the incoming packet is fragmentable. Also as per RFC 4459, each strategy has its relative merits and costs.
o When the GRE egress node receives a GRE delivery packet fragment, it silently discards the fragment without attempting to reassemble the GRE delivery packet to which the fragment belongs. In non-default configurations, the GRE ingress node can execute any of the procedures defined in RFC 4459. The solution described above is widely deployed on the Internet in its default configuration. However, the default configuration is not always appropriate for GRE tunnels that carry IPv6. IPv6 requires that every link in the Internet have an MTU of 1280 octets or greater. On any link that cannot convey a 1280-octet packet in one piece, link-specific fragmentation and reassembly must be provided at a layer below IPv6. Therefore, the default configuration is appropriate for tunnels that carry IPv6 only if the network is engineered so that the GMTU is guaranteed to be 1280 bytes or greater. In all other scenarios, a non-default configuration is required. In the non-default configuration, when the GRE ingress router receives a packet lager than the GMTU, the GRE ingress router encapsulates the entire packet in a single GRE and delivery header. It then fragments the delivery header and sends the resulting fragments to the GRE egress node, where they are reassembled. Section 2.2. RFC2784].
disables PMTUD. This configuration option is required to mitigate certain denial-of-service attacks (see Section 4). The GRE ingress node's estimate of the GMTU will not always be accurate. It is only an estimate. When the GMTU changes, the GRE ingress node will not discover that change immediately. Likewise, if the GRE ingress node performs PMTUD procedures and interior nodes cannot deliver ICMP feedback to the GRE ingress node, GMTU estimates may be inaccurate. RFC1191]), and the next-hop MTU is equal to the GMTU associated with the tunnel. The GRE ingress node supports a non-default configuration option that invokes an alternative behavior. If that option is configured, the GRE ingress node fragments the delivery packet. See Section 3.3.2 for details. RFC4443] Packet Too Big message to the payload source. The MTU specified in the Packet Too Big message is equal to the GMTU associated with the tunnel.
The GRE ingress node supports a non-default configuration option that invokes an alternative behavior. If that option is configured, the GRE ingress node fragments the delivery packet. See Section 3.3.2 for details. Section 3.3.2 for details.
RFC1858]. This vulnerability is not specific to GRE and needs to be considered in all environments where IP fragmentation is present. [RFC3128] describes a procedure by which IPv4 implementations can partially mitigate the vulnerability. [RFC5722] mandates a procedure by which IPv6-compliant implementations are required to mitigate the vulnerability. The procedure described in
RFC 5722 completely mitigates the vulnerability. Operators SHOULD ensure that the vulnerability is mitigated to their satisfaction on equipment that they deploy. PMTUD is vulnerable to two denial-of-service attacks (see Section 8 of [RFC1191] for details). Both attacks are based upon on a malicious party sending forged ICMPv4 Destination Unreachable or ICMPv6 Packet Too Big messages to a host. In the first attack, the forged message indicates an inordinately small PMTU. In the second attack, the forged message indicates an inordinately large MTU. In both cases, throughput is adversely affected. In order to mitigate such attacks, GRE implementations include a configuration option to disable PMTUD on GRE tunnels. Also, they can include a configuration option that conditions the behavior of PMTUD to establish a minimum PMTU. [RFC792] Postel, J., "Internet Control Message Protocol", STD 5, RFC 792, DOI 10.17487/RFC0792, September 1981, <http://www.rfc-editor.org/info/rfc792>. [RFC1191] Mogul, J. and S. Deering, "Path MTU discovery", RFC 1191, DOI 10.17487/RFC1191, November 1990, <http://www.rfc-editor.org/info/rfc1191>. [RFC1858] Ziemba, G., Reed, D., and P. Traina, "Security Considerations for IP Fragment Filtering", RFC 1858, DOI 10.17487/RFC1858, October 1995, <http://www.rfc-editor.org/info/rfc1858>. [RFC1981] McCann, J., Deering, S., and J. Mogul, "Path MTU Discovery for IP version 6", RFC 1981, DOI 10.17487/RFC1981, August 1996, <http://www.rfc-editor.org/info/rfc1981>. [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, <http://www.rfc-editor.org/info/rfc2119>. [RFC2784] Farinacci, D., Li, T., Hanks, S., Meyer, D., and P. Traina, "Generic Routing Encapsulation (GRE)", RFC 2784, DOI 10.17487/RFC2784, March 2000, <http://www.rfc-editor.org/info/rfc2784>.
[RFC2890] Dommety, G., "Key and Sequence Number Extensions to GRE", RFC 2890, DOI 10.17487/RFC2890, September 2000, <http://www.rfc-editor.org/info/rfc2890>. [RFC3128] Miller, I., "Protection Against a Variant of the Tiny Fragment Attack (RFC 1858)", RFC 3128, DOI 10.17487/RFC3128, June 2001, <http://www.rfc-editor.org/info/rfc3128>. [RFC4023] Worster, T., Rekhter, Y., and E. Rosen, Ed., "Encapsulating MPLS in IP or Generic Routing Encapsulation (GRE)", RFC 4023, DOI 10.17487/RFC4023, March 2005, <http://www.rfc-editor.org/info/rfc4023>. [RFC4443] Conta, A., Deering, S., and M. Gupta, Ed., "Internet Control Message Protocol (ICMPv6) for the Internet Protocol Version 6 (IPv6) Specification", RFC 4443, DOI 10.17487/RFC4443, March 2006, <http://www.rfc-editor.org/info/rfc4443>. [RFC5722] Krishnan, S., "Handling of Overlapping IPv6 Fragments", RFC 5722, DOI 10.17487/RFC5722, December 2009, <http://www.rfc-editor.org/info/rfc5722>. [IPv6-GRE] Pignataro, C., Bonica, R., and S. Krishnan, "IPv6 Support for Generic Routing Encapsulation (GRE)", Work in Progress, draft-ietf-intarea-gre-ipv6-10, June 2015. [RFC4459] Savola, P., "MTU and Fragmentation Issues with In-the- Network Tunneling", RFC 4459, DOI 10.17487/RFC4459, April 2006, <http://www.rfc-editor.org/info/rfc4459>.