idnits 2.17.1 draft-ietf-intarea-gre-mtu-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (October 1, 2014) is 3492 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- ** Obsolete normative reference: RFC 1981 (Obsoleted by RFC 8201) Summary: 1 error (**), 0 flaws (~~), 1 warning (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Intarea Working Group R. Bonica 3 Internet-Draft Juniper Networks 4 Intended status: Informational C. Pignataro 5 Expires: April 4, 2015 Cisco Systems 6 J. Touch 7 USC/ISI 8 October 1, 2014 10 A Widely-Deployed Solution To The Generic Routing Encapsulation (GRE) 11 Fragmentation Problem 12 draft-ietf-intarea-gre-mtu-00 14 Abstract 16 This memo describes how many vendors have solved the Generic Routing 17 Encapsulation (GRE) fragmentation problem. The solution described 18 herein is configurable. It is widely deployed on the Internet in its 19 default configuration. 21 Status of This Memo 23 This Internet-Draft is submitted in full conformance with the 24 provisions of BCP 78 and BCP 79. 26 Internet-Drafts are working documents of the Internet Engineering 27 Task Force (IETF). Note that other groups may also distribute 28 working documents as Internet-Drafts. The list of current Internet- 29 Drafts is at http://datatracker.ietf.org/drafts/current/. 31 Internet-Drafts are draft documents valid for a maximum of six months 32 and may be updated, replaced, or obsoleted by other documents at any 33 time. It is inappropriate to use Internet-Drafts as reference 34 material or to cite them other than as "work in progress." 36 This Internet-Draft will expire on April 4, 2015. 38 Copyright Notice 40 Copyright (c) 2014 IETF Trust and the persons identified as the 41 document authors. All rights reserved. 43 This document is subject to BCP 78 and the IETF Trust's Legal 44 Provisions Relating to IETF Documents 45 (http://trustee.ietf.org/license-info) in effect on the date of 46 publication of this document. Please review these documents 47 carefully, as they describe your rights and restrictions with respect 48 to this document. Code Components extracted from this document must 49 include Simplified BSD License text as described in Section 4.e of 50 the Trust Legal Provisions and are provided without warranty as 51 described in the Simplified BSD License. 53 Table of Contents 55 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 56 1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3 57 2. Solutions . . . . . . . . . . . . . . . . . . . . . . . . . . 4 58 2.1. RFC 4459 Solutions . . . . . . . . . . . . . . . . . . . 4 59 2.2. A Widely-Deployed Solution . . . . . . . . . . . . . . . 4 60 3. Implementation Details . . . . . . . . . . . . . . . . . . . 5 61 3.1. General . . . . . . . . . . . . . . . . . . . . . . . . . 5 62 3.2. GRE MTU (GMTU) Estimation and Discovery . . . . . . . . . 5 63 3.3. GRE Ingress Node Procedures . . . . . . . . . . . . . . . 6 64 3.3.1. Procedures Affecting the GRE Payload . . . . . . . . 6 65 3.3.2. Procedures Affecting The GRE Deliver Header . . . . . 7 66 3.4. GRE Egress Node Procedures . . . . . . . . . . . . . . . 7 67 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8 68 5. Security Considerations . . . . . . . . . . . . . . . . . . . 8 69 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 8 70 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 9 71 7.1. Normative References . . . . . . . . . . . . . . . . . . 9 72 7.2. Informative References . . . . . . . . . . . . . . . . . 9 73 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 9 75 1. Introduction 77 Generic Routing Encapsulation (GRE) [RFC2784] [RFC2890] can be used 78 to carry any network layer protocol over any network layer protocol. 79 GRE has been implemented by many vendors and is widely deployed in 80 the Internet. 82 The GRE specification does not describe fragmentation procedures. 83 Lacking guidance from the specification, vendors have developed 84 implementation-specific fragmentation solutions. A GRE tunnel will 85 operate correctly only if its ingress and egress nodes support 86 compatible fragmentation solutions. [RFC4459] describes several 87 fragmentation solutions and evaluates their relative merits. 89 This memo reviews the fragmentation solutions presented in [RFC4459]. 90 It also describes how many vendors have solved the GRE fragmentation 91 problem. The solution described herein is configurable, and has been 92 widely deployed in its default configuration. 94 This memo addresses point-to-point unicast GRE tunnels that carry 95 IPv4, IPv6 or MPLS payloads. All other tunnel types are beyond the 96 scope of this document. 98 1.1. Terminology 100 The following terms are specific to GRE and are taken from [RFC2784]: 102 o GRE delivery header - an IPv4 or IPv6 header whose source address 103 represents the GRE ingress node and whose destination address 104 represents the GRE egress node. The GRE delivery header 105 encapsulates a GRE header. 107 o GRE header - the GRE protocol header. The GRE header is 108 encapsulated in the GRE delivery header and encapsulates GRE 109 payload. 111 o GRE payload - a network layer packet that is encapsulated by the 112 GRE header. The GRE payload can be IPv4, IPv6 or MPLS. 113 Procedures for encapsulating IPv4 and IPv6 in GRE are described in 114 [RFC2784] and [RFC2890]. Procedures for encapsulating MPLS in GRE 115 are described in [RFC4023]. While other protocols may be 116 delivered over GRE, they are beyond the scope of this document. 118 o GRE delivery packet - A packet containing a GRE delivery header, a 119 GRE header, and GRE payload. 121 o GRE payload header - the IPv4, IPv6 or MPLS header of the GRE 122 payload 124 o GRE overhead - the combined size of the GRE delivery header and 125 the GRE header, measured in octets 127 The following terms are specific MTU discovery: 129 o link MTU (LMTU) - the maximum transmission unit, i.e., maximum 130 packet size in octets, that can be conveyed over a link. LMTU is 131 a unidirectional metric. A bidirectional link may be 132 characterized by one LMTU in the forward direction and another MTU 133 in the reverse direction. 135 o path MTU (PMTU) - the minimum LMTU of all the links in a path 136 between a source node and a destination node. If the source and 137 destination node are connected through an equal cost multipath 138 (ECMP), the PMTU is equal to the minimum LMTU of all links 139 contributing to the multipath. 141 o GRE MTU (GMTU) - the maximum transmission unit, i.e., maximum 142 packet size in octets, that can be conveyed over a GRE tunnel 143 without fragmentation of any kind. The GMTU is equal to the PMTU 144 associated with the path between the GRE ingress and the GRE 145 egress, minus the GRE overhead 147 o Path MTU Discovery (PMTUD) - A procedure for dynamically 148 discovering the PMTU between two nodes on the Internet. PMTUD 149 procedures for IPv4 are defined in [RFC1191]. PMTUD procedures 150 for IPv6 are defined in [RFC1981]. 152 The following terms are introduced by this memo: 154 o fragmentable packet - An IPv4 packet with DF-bit equal to 0 and 155 whose payload is larger than 64 bytes 157 o ICMP Packet Too Big (PTB) message - an ICMPv4 [RFC0792] 158 Destination Unreachable message with code equal to 4 159 (fragmentation needed and DF set) or an ICMPv6 [RFC4443] Packet 160 Too Big message 162 2. Solutions 164 2.1. RFC 4459 Solutions 166 Section 3 of [RFC4459] identifies several tunnel fragmentation 167 solutions. These solutions define procedures to be invoked when the 168 tunnel ingress router receives a packet so large that it cannot be 169 forwarded though the tunnel without fragmentation of any kind. When 170 applied to GRE, these procedures are: 172 1. Discard the incoming packet and send an ICMP PTB message to the 173 incoming packet's source. 175 2. Fragment the incoming packet and encapsulate each fragment within 176 a complete GRE header and GRE delivery header. 178 3. Encapsulate the incoming packet in a single GRE header and GRE 179 delivery header. Perform source fragmentation on the resulting 180 GRE delivery packet. 182 As per RFC 4459, Strategy 2) is applicable only when the incoming 183 packet is fragmentable. Also as per RFC 4459, each strategy has its 184 relative merits and costs. 186 2.2. A Widely-Deployed Solution 188 Many vendors have implemented a configurable GRE fragmentation 189 solution. In its default configuration, the solution behaves as 190 follows: 192 o When the GRE ingress node receives a fragmentable packet with 193 length greater than the GMTU, it fragments the incoming packet and 194 encapsulates each fragment within a complete GRE header and GRE 195 delivery header. 197 o When the GRE ingress node receives a non-fragmentable packet with 198 length greater than the GMTU, it discards the packet and send an 199 ICMP PTB message to the packet's source. 201 o When the GRE egress node receives a GRE delivery packet fragment, 202 it silently discards the fragment, without attempting to 203 reassemble the GRE delivery packet to which the fragment belongs. 205 In non-default configurations, the GRE ingress node can execute any 206 of the procedures defined in RFC 4459. 208 The solution described above is widely-deployed on the Internet in 209 its default configuration. 211 3. Implementation Details 213 This section describes how many vendors have implemented the solution 214 described in Section 2.2. 216 3.1. General 218 The GRE ingress nodes satisfy all of the requirements stated in 219 [RFC2784]. 221 3.2. GRE MTU (GMTU) Estimation and Discovery 223 GRE ingress nodes support a configuration option that associates a 224 GMTU with a GRE tunnel. By default, GMTU is equal to the MTU 225 associated with next-hop toward the GRE egress node minus the GRE 226 overhead. 228 Typically, GRE ingress nodes further refine their GMTU estimate by 229 executing PMTUD procedures. However, if an implementation supports 230 PMTUD for GRE tunnels, it also includes a configuration option that 231 disables PMTUD. This configuration option is required to mitigate 232 certain denial of service attacks (see Section 5). 234 The ingress node's GMTU estimate will not always reflect the actual 235 GMTU. It is only an estimate. When a tunnel's GMTU changes, the 236 tunnel ingress node will not discover that change immediately. 237 Likewise, if the ingress node performs PMTUD procedures and tunnel 238 interior nodes cannot deliver ICMP feedback to the tunnel ingress, 239 GMTU estimates may be inaccurate. 241 3.3. GRE Ingress Node Procedures 243 This section defines procedures that GRE ingress nodes execute when 244 they receive a packet whose size is greater than the relevant GMTU. 246 3.3.1. Procedures Affecting the GRE Payload 248 3.3.1.1. IPv4 Payloads 250 By default, if the payload is fragmentable, the GRE ingress node 251 fragments the incoming packet and encapsulates each fragment within a 252 complete GRE header and GRE delivery header. Therefore, the GRE 253 egress node receives several complete, non-fragmented delivery 254 packets. Each delivery packet contains a fragment of the GRE 255 payload. The GRE egress node forwards the payload fragments to their 256 ultimate destination where they are reassembled. 258 Also by default, if the payload is not fragmentable, the GRE ingress 259 node discards the packet and sends an ICMPv4 Destination Unreachable 260 message to the packet's source. The ICMPv4 Destination Unreachable 261 message code equals 4 (fragmentation needed and DF set). The ICMPv4 262 Destination Unreachable message also contains an Next-hop MTU (as 263 specified by [RFC1191]) and the next-hop MTU is equal to the GMTU 264 associated with the tunnel. 266 The GRE ingress node supports a non-default configuration option that 267 invokes an alternative behavior. If that option is configured, the 268 GRE ingress node fragments the delivery header. See Section 3.3.2 269 for details. 271 3.3.1.2. IPv6 Payloads 273 By default, the GRE ingress node discards the packet and send an 274 ICMPv6 [RFC4443] Packet Too Big message to the payload source. The 275 MTU specified in the Packet Too Big message is equal to the GMTU 276 associated with the tunnel. 278 The GRE ingress node supports a non-default configuration option that 279 invokes an alternative behavior. If that option is configured, the 280 GRE ingress node fragments the delivery header.See Section 3.3.2 for 281 details. 283 3.3.1.3. MPLS Payloads 285 By default, the GRE ingress node discards the packet. As it is 286 impossible to reliably identify the payload source, the GRE ingress 287 node does not attempt to send an ICMP PTB message to the payload 288 source. 290 The GRE ingress node supports a non-default configuration option that 291 invokes an alternative behavior. If that option is configured, the 292 GRE ingress node fragments the delivery header. See Section 3.3.2. 294 3.3.2. Procedures Affecting The GRE Deliver Header 296 3.3.2.1. Tunneling GRE Over IPv4 298 By default, the GRE ingress node does not fragment delivery packets. 299 However, the GRE ingress node includes a configuration option that 300 allows delivery packet fragmentation. 302 By default, the GRE ingress node sets the DF-bit in the delivery 303 header to 1 (Don't Fragment). However, the GRE ingress node also 304 supports a configuration option that invokes the following behavior: 306 o when the GRE payload is IPv6, the DF-bit on the delivery header is 307 set to 0 (Fragments Allowed) 309 o when the GRE payload is IPv4, the DF-bit is copied from the 310 payload header to the delivery header 312 When the DF-bit on an IPv4 delivery header is set to 0, the GRE 313 delivery packet can be fragmented by any node between the GRE ingress 314 and the GRE egress. 316 If the delivery packet is fragmented, it is reassembled by the GRE 317 egress. 319 3.3.2.2. Tunneling GRE Over IPv6 321 By default, the GRE ingress node does not fragment delivery packets. 322 However, the GRE ingress node includes a configuration option that 323 allows this. 325 If the delivery packet is fragmented, it is reassembled by the GRE 326 egress. 328 3.4. GRE Egress Node Procedures 330 By default, the GRE egress node silently discards GRE delivery packet 331 fragments, without attempting to reassemble the GRE delivery packets 332 to which the fragments belongs. 334 However, the GRE egress node supports a configuration option that 335 allows it to reassemble GRE delivery packets. 337 4. IANA Considerations 339 This document makes no request of IANA. 341 5. Security Considerations 343 In the GRE fragmentation solution described above, either the GRE 344 payload or the GRE delivery packet can be fragmented. If the GRE 345 payload is fragmented, it is typically reassembled at its ultimate 346 destination. If the GRE delivery packet is fragmented, it is 347 typically reassembled at the GRE egress node. 349 The packet reassembly process is resource intensive and vulnerable to 350 several denial of service attacks. In the simplest attack, the 351 attacker sends fragmented packets more quickly than the victim can 352 reassemble them. In a variation on that attack, the first fragment 353 of each packet is missing, so that no packet can ever be reassembled. 355 Given that the packet reassembly process is resource intensive and 356 vulnerable to denial of service attacks, operators should decide 357 where reassembly process is best performed. Having made that 358 decision, they should decide whether to fragment the GRE payload or 359 GRE delivery packet, accordingly. 361 PMTU Discovery is vulnerable to two denial of service attacks (see 362 Section 8 of [RFC1191] for details). Both attacks are based upon on 363 a malicious party sending forged ICMPv4 Destination Unreachable or 364 ICMPv6 Packet Too Big messages to a host. In the first attack, the 365 forged message indicates an inordinately small PMTU. In the second 366 attack, the forged message indicates an inordinately large MTU. In 367 both cases, throughput is adversely affected. On order to mitigate 368 such attacks, GRE implementations includes a configuration option to 369 disable PMTU discovery on GRE tunnels. Also, they can include a 370 configuration option that conditions the behavior of PMTUD to 371 establish a minimum PMTU. 373 6. Acknowledgements 375 The authors would like to thank Fred Baker, Fred Detienne, Jagadish 376 Grandhi, Jeff Haas, Vanitha Neelamegam, John Scudder, Mike 377 Sullenberger and Wen Zhang for their constructive comments. The 378 authors also express their gratitude to Vanessa Ameen, without whom 379 this memo could not have been written. 381 7. References 383 7.1. Normative References 385 [RFC0792] Postel, J., "Internet Control Message Protocol", STD 5, 386 RFC 792, September 1981. 388 [RFC1191] Mogul, J. and S. Deering, "Path MTU discovery", RFC 1191, 389 November 1990. 391 [RFC1981] McCann, J., Deering, S., and J. Mogul, "Path MTU Discovery 392 for IP version 6", RFC 1981, August 1996. 394 [RFC2784] Farinacci, D., Li, T., Hanks, S., Meyer, D., and P. 395 Traina, "Generic Routing Encapsulation (GRE)", RFC 2784, 396 March 2000. 398 [RFC2890] Dommety, G., "Key and Sequence Number Extensions to GRE", 399 RFC 2890, September 2000. 401 [RFC4023] Worster, T., Rekhter, Y., and E. Rosen, "Encapsulating 402 MPLS in IP or Generic Routing Encapsulation (GRE)", RFC 403 4023, March 2005. 405 [RFC4443] Conta, A., Deering, S., and M. Gupta, "Internet Control 406 Message Protocol (ICMPv6) for the Internet Protocol 407 Version 6 (IPv6) Specification", RFC 4443, March 2006. 409 7.2. Informative References 411 [RFC4459] Savola, P., "MTU and Fragmentation Issues with In-the- 412 Network Tunneling", RFC 4459, April 2006. 414 Authors' Addresses 416 Ron Bonica 417 Juniper Networks 418 2251 Corporate Park Drive Herndon 419 Herndon, Virginia 20170 420 USA 422 Email: rbonica@juniper.net 423 Carlos Pignataro 424 Cisco Systems 425 7200-12 Kit Creek Road 426 Research Triangle Park, North Carolina 27709 427 USA 429 Email: cpignata@cisco.com 431 Joe Touch 432 USC/ISI 433 4676 Admiralty Way 434 Marina del Rey, California 90292-6695 435 USA 437 Phone: +1 (310) 448-9151 438 Email: touch@isi.edu 439 URI: http://www.isi.edu/touch