diff options
Diffstat (limited to 'doc/rfc/rfc7588.txt')
| -rw-r--r-- | doc/rfc/rfc7588.txt | 675 |
1 files changed, 675 insertions, 0 deletions
diff --git a/doc/rfc/rfc7588.txt b/doc/rfc/rfc7588.txt new file mode 100644 index 0000000..3780b64 --- /dev/null +++ b/doc/rfc/rfc7588.txt @@ -0,0 +1,675 @@ + + + + + + +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 + +Abstract + + This 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. + + + + + + + + + + + + + + + + + +Bonica, et al. Informational [Page 1] + +RFC 7588 GRE Fragmentation July 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 + (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. + +Table of Contents + + 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 + + + + + + + + + + + + + + + +Bonica, et al. Informational [Page 2] + +RFC 7588 GRE Fragmentation July 2015 + + +1. Introduction + + Generic Routing Encapsulation (GRE) [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. + +1.1. Terminology + + The following terms are specific to GRE: + + o GRE delivery header - an IPv4 or IPv6 header whose source address + represents the GRE ingress node and whose destination address + represents the GRE egress node. The GRE delivery header + encapsulates a GRE header. + + o GRE header - the GRE protocol header. The GRE header is + encapsulated in the GRE delivery header and encapsulates the GRE + payload. + + o GRE payload - a network-layer packet that is encapsulated by the + GRE header. The GRE payload can be IPv4, IPv6, or MPLS. + Procedures for encapsulating IPv4 in GRE are described in + [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. + + + + + +Bonica, et al. Informational [Page 3] + +RFC 7588 GRE Fragmentation July 2015 + + + 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). + + + + + + + + +Bonica, et al. Informational [Page 4] + +RFC 7588 GRE Fragmentation July 2015 + + +1.2. Requirements Language + + The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", + "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this + document are to be interpreted as described in RFC 2119 [RFC2119]. + +2. Solutions + +2.1. RFC 4459 Solutions + + 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. + +2.2. A Widely Deployed Solution + + Many vendors have implemented a configurable GRE fragmentation + solution. In its default configuration, the solution behaves as + follows: + + o When the GRE ingress node receives a fragmentable packet with + length greater than the GMTU, it fragments the incoming packet and + encapsulates each fragment within a complete GRE header and GRE + delivery header. Fragmentation logic is as specified by the + payload protocol. + + o When the GRE ingress node receives a non-fragmentable packet with + length greater than the GMTU, it discards the packet and sends an + ICMP PTB message to the packet's source. + + + + + + +Bonica, et al. Informational [Page 5] + +RFC 7588 GRE Fragmentation July 2015 + + + 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. + +3. Implementation Details + + This section describes how many vendors have implemented the solution + described in Section 2.2. + +3.1. General + + The GRE ingress nodes satisfy all of the requirements stated in + [RFC2784]. + +3.2. GRE MTU (GMTU) Estimation and Discovery + + GRE ingress nodes support a configuration option that associates a + GMTU with a GRE tunnel. By default, GMTU is equal to the MTU + associated with the next hop toward the GRE egress node minus the GRE + overhead. + + Typically, GRE ingress nodes further refine their GMTU estimate by + executing PMTUD procedures. However, if an implementation supports + PMTUD for GRE tunnels, it also includes a configuration option that + + + + +Bonica, et al. Informational [Page 6] + +RFC 7588 GRE Fragmentation July 2015 + + + 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. + +3.3. GRE Ingress Node Procedures + + This section defines procedures that GRE ingress nodes execute when + they receive a packet whose size is greater than the relevant GMTU. + +3.3.1. Procedures Affecting the GRE Payload + +3.3.1.1. IPv4 Payloads + + By default, if the payload is fragmentable, the GRE ingress node + fragments the incoming packet and encapsulates each fragment within a + complete GRE header and GRE delivery header. Therefore, the GRE + egress node receives several complete, non-fragmented delivery + packets. Each delivery packet contains a fragment of the GRE + payload. The GRE egress node forwards the payload fragments to their + ultimate destination where they are reassembled. + + Also by default, if the payload is not fragmentable, the GRE ingress + node discards the packet and sends an ICMPv4 Destination Unreachable + message to the packet's source. The ICMPv4 Destination Unreachable + message code equals 4 (fragmentation needed and DF set). The ICMPv4 + Destination Unreachable message also contains a next-hop MTU (as + specified by [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. + +3.3.1.2. IPv6 Payloads + + By default, the GRE ingress node discards the packet and sends an + ICMPv6 [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. + + + + + +Bonica, et al. Informational [Page 7] + +RFC 7588 GRE Fragmentation July 2015 + + + 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. + +3.3.1.3. MPLS Payloads + + By default, the GRE ingress node discards the packet. As it is + impossible to reliably identify the payload source, the GRE ingress + node does not attempt to send an ICMP PTB message to the payload + source. + + 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. + +3.3.2. Procedures Affecting the GRE Deliver Header + +3.3.2.1. Tunneling GRE over IPv4 + + By default, the GRE ingress node does not fragment delivery packets. + However, the GRE ingress node includes a configuration option that + allows delivery packet fragmentation. + + By default, the GRE ingress node sets the DF bit in the delivery + header to 1 (Don't Fragment). However, the GRE ingress node also + supports a configuration option that invokes the following behavior: + + o When the GRE payload is IPv6, the DF bit on the delivery header is + set to 0 (Fragments Allowed). + + o When the GRE payload is IPv4, the DF bit is copied from the + payload header to the delivery header. + + When the DF bit on an IPv4 delivery header is set to 0, the GRE + delivery packet can be fragmented by any router between the GRE + ingress and egress nodes. + + If the GRE egress node is configured to support reassembly, it will + reassemble fragmented delivery packets. Otherwise, the GRE egress + node will discard delivery packet fragments. + + + + + + + + + +Bonica, et al. Informational [Page 8] + +RFC 7588 GRE Fragmentation July 2015 + + +3.3.2.2. Tunneling GRE over IPv6 + + By default, the GRE ingress node does not fragment delivery packets. + However, the GRE ingress node includes a configuration option that + allows this. + + If the GRE egress node is configured to support reassembly, it will + reassemble fragmented delivery packets. Otherwise, the GRE egress + node will discard delivery packet fragments. + +3.4. GRE Egress Node Procedures + + By default, the GRE egress node silently discards GRE delivery packet + fragments without attempting to reassemble the GRE delivery packets + to which the fragments belongs. + + However, the GRE egress node supports a configuration option that + allows it to reassemble GRE delivery packets. + +4. Security Considerations + + In the GRE fragmentation solution described above, either the GRE + payload or the GRE delivery packet can be fragmented. If the GRE + payload is fragmented, it is typically reassembled at its ultimate + destination. If the GRE delivery packet is fragmented, it is + typically reassembled at the GRE egress node. + + The packet reassembly process is resource intensive and vulnerable to + several denial-of-service attacks. In the simplest attack, the + attacker sends fragmented packets more quickly than the victim can + reassemble them. In a variation on that attack, the first fragment + of each packet is missing so that no packet can ever be reassembled. + + Given that the packet reassembly process is resource intensive and + vulnerable to denial-of-service attacks, operators should decide + where the reassembly process is best performed. Having made that + decision, they should decide whether to fragment the GRE payload or + GRE delivery packet accordingly. + + Some IP implementations are vulnerable to the Overlapping Fragment + Attack [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 + + + + + +Bonica, et al. Informational [Page 9] + +RFC 7588 GRE Fragmentation July 2015 + + + 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. + +5. References + +5.1. Normative References + + [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>. + + + + + +Bonica, et al. Informational [Page 10] + +RFC 7588 GRE Fragmentation July 2015 + + + [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>. + +5.2. Informative References + + [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>. + + + + + + + + + + + + + + + + + + +Bonica, et al. Informational [Page 11] + +RFC 7588 GRE Fragmentation July 2015 + + +Acknowledgements + + The authors would like to thank Fred Baker, Fred Detienne, Jagadish + Grandhi, Jeff Haas, Brian Haberman, Vanitha Neelamegam, Masataka + Ohta, John Scudder, Mike Sullenberger, Tom Taylor, and Wen Zhang for + their constructive comments. The authors also express their + gratitude to Vanessa Ameen, without whom this memo could not have + been written. + +Authors' Addresses + + Ron Bonica + Juniper Networks + 2251 Corporate Park Drive + Herndon, Virginia 20170 + United States + + Email: rbonica@juniper.net + + + Carlos Pignataro + Cisco Systems + 7200-12 Kit Creek Road + Research Triangle Park, North Carolina 27709 + United States + + Email: cpignata@cisco.com + + + Joe Touch + USC/ISI + 4676 Admiralty Way + Marina del Rey, California 90292-6695 + United States + + Phone: +1 (310) 448-9151 + Email: touch@isi.edu + URI: http://www.isi.edu/touch + + + + + + + + + + + + + +Bonica, et al. Informational [Page 12] + |