idnits 2.17.1 draft-ietf-intarea-gre-mtu-01.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 (December 30, 2014) is 3403 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: July 3, 2015 Cisco Systems 6 J. Touch 7 USC/ISI 8 December 30, 2014 10 A Widely-Deployed Solution To The Generic Routing Encapsulation (GRE) 11 Fragmentation Problem 12 draft-ietf-intarea-gre-mtu-01 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 July 3, 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 in GRE are described in 114 [RFC2784] and [RFC2890]. Procedures for encapsulating IPv6 in GRE 115 are described in [I-D.pignataro-intarea-gre-ipv6]. Procedures for 116 encapsulating MPLS in GRE are described in [RFC4023]. While other 117 protocols may be delivered over GRE, they are beyond the scope of 118 this document. 120 o GRE delivery packet - A packet containing a GRE delivery header, a 121 GRE header, and GRE payload. 123 o GRE payload header - the IPv4, IPv6 or MPLS header of the GRE 124 payload 126 o GRE overhead - the combined size of the GRE delivery header and 127 the GRE header, measured in octets 129 The following terms are specific MTU discovery: 131 o link MTU (LMTU) - the maximum transmission unit, i.e., maximum 132 packet size in octets, that can be conveyed over a link. LMTU is 133 a unidirectional metric. A bidirectional link may be 134 characterized by one LMTU in the forward direction and another 135 LMTU in the reverse direction. 137 o path MTU (PMTU) - the minimum LMTU of all the links in a path 138 between a source node and a destination node. If the source and 139 destination node are connected through an equal cost multipath 140 (ECMP), the PMTU is equal to the minimum LMTU of all links 141 contributing to the multipath. 143 o GRE MTU (GMTU) - the maximum transmission unit, i.e., maximum 144 packet size in octets, that can be conveyed over a GRE tunnel 145 without fragmentation of any kind. The GMTU is equal to the PMTU 146 associated with the path between the GRE ingress and the GRE 147 egress, minus the GRE overhead 149 o Path MTU Discovery (PMTUD) - A procedure for dynamically 150 discovering the PMTU between two nodes on the Internet. PMTUD 151 procedures for IPv4 are defined in [RFC1191]. PMTUD procedures 152 for IPv6 are defined in [RFC1981]. 154 The following terms are introduced by this memo: 156 o fragmentable packet - An IPv4 packet with DF-bit equal to 0 and 157 whose payload is larger than 64 bytes 159 o ICMP Packet Too Big (PTB) message - an ICMPv4 [RFC0792] 160 Destination Unreachable message with code equal to 4 161 (fragmentation needed and DF set) or an ICMPv6 [RFC4443] Packet 162 Too Big message 164 2. Solutions 166 2.1. RFC 4459 Solutions 168 Section 3 of [RFC4459] identifies several tunnel fragmentation 169 solutions. These solutions define procedures to be invoked when the 170 tunnel ingress router receives a packet so large that it cannot be 171 forwarded though the tunnel without fragmentation of any kind. When 172 applied to GRE, these procedures are: 174 1. Discard the incoming packet and send an ICMP PTB message to the 175 incoming packet's source. 177 2. Fragment the incoming packet and encapsulate each fragment within 178 a complete GRE header and GRE delivery header. 180 3. Encapsulate the incoming packet in a single GRE header and GRE 181 delivery header. Perform source fragmentation on the resulting 182 GRE delivery packet. 184 As per RFC 4459, Strategy 2) is applicable only when the incoming 185 packet is fragmentable. Also as per RFC 4459, each strategy has its 186 relative merits and costs. 188 2.2. A Widely-Deployed Solution 190 Many vendors have implemented a configurable GRE fragmentation 191 solution. In its default configuration, the solution behaves as 192 follows: 194 o When the GRE ingress node receives a fragmentable packet with 195 length greater than the GMTU, it fragments the incoming packet and 196 encapsulates each fragment within a complete GRE header and GRE 197 delivery header. 199 o When the GRE ingress node receives a non-fragmentable packet with 200 length greater than the GMTU, it discards the packet and send an 201 ICMP PTB message to the packet's source. 203 o When the GRE egress node receives a GRE delivery packet fragment, 204 it silently discards the fragment, without attempting to 205 reassemble the GRE delivery packet to which the fragment belongs. 207 In non-default configurations, the GRE ingress node can execute any 208 of the procedures defined in RFC 4459. 210 The solution described above is widely-deployed on the Internet in 211 its default configuration. 213 3. Implementation Details 215 This section describes how many vendors have implemented the solution 216 described in Section 2.2. 218 3.1. General 220 The GRE ingress nodes satisfy all of the requirements stated in 221 [RFC2784]. 223 3.2. GRE MTU (GMTU) Estimation and Discovery 225 GRE ingress nodes support a configuration option that associates a 226 GMTU with a GRE tunnel. By default, GMTU is equal to the MTU 227 associated with next-hop toward the GRE egress node minus the GRE 228 overhead. 230 Typically, GRE ingress nodes further refine their GMTU estimate by 231 executing PMTUD procedures. However, if an implementation supports 232 PMTUD for GRE tunnels, it also includes a configuration option that 233 disables PMTUD. This configuration option is required to mitigate 234 certain denial of service attacks (see Section 5). 236 The ingress node's GMTU estimate will not always reflect the actual 237 GMTU. It is only an estimate. When a tunnel's GMTU changes, the 238 tunnel ingress node will not discover that change immediately. 239 Likewise, if the ingress node performs PMTUD procedures and tunnel 240 interior nodes cannot deliver ICMP feedback to the tunnel ingress, 241 GMTU estimates may be inaccurate. 243 3.3. GRE Ingress Node Procedures 245 This section defines procedures that GRE ingress nodes execute when 246 they receive a packet whose size is greater than the relevant GMTU. 248 3.3.1. Procedures Affecting the GRE Payload 250 3.3.1.1. IPv4 Payloads 252 By default, if the payload is fragmentable, the GRE ingress node 253 fragments the incoming packet and encapsulates each fragment within a 254 complete GRE header and GRE delivery header. Therefore, the GRE 255 egress node receives several complete, non-fragmented delivery 256 packets. Each delivery packet contains a fragment of the GRE 257 payload. The GRE egress node forwards the payload fragments to their 258 ultimate destination where they are reassembled. 260 Also by default, if the payload is not fragmentable, the GRE ingress 261 node discards the packet and sends an ICMPv4 Destination Unreachable 262 message to the packet's source. The ICMPv4 Destination Unreachable 263 message code equals 4 (fragmentation needed and DF set). The ICMPv4 264 Destination Unreachable message also contains an Next-hop MTU (as 265 specified by [RFC1191]) and the next-hop MTU is equal to the GMTU 266 associated with the tunnel. 268 The GRE ingress node supports a non-default configuration option that 269 invokes an alternative behavior. If that option is configured, the 270 GRE ingress node fragments the delivery header. See Section 3.3.2 271 for details. 273 3.3.1.2. IPv6 Payloads 275 By default, the GRE ingress node discards the packet and send an 276 ICMPv6 [RFC4443] Packet Too Big message to the payload source. The 277 MTU specified in the Packet Too Big message is equal to the GMTU 278 associated with the tunnel. 280 The GRE ingress node supports a non-default configuration option that 281 invokes an alternative behavior. If that option is configured, the 282 GRE ingress node fragments the delivery header.See Section 3.3.2 for 283 details. 285 3.3.1.3. MPLS Payloads 287 By default, the GRE ingress node discards the packet. As it is 288 impossible to reliably identify the payload source, the GRE ingress 289 node does not attempt to send an ICMP PTB message to the payload 290 source. 292 The GRE ingress node supports a non-default configuration option that 293 invokes an alternative behavior. If that option is configured, the 294 GRE ingress node fragments the delivery header. See Section 3.3.2. 296 3.3.2. Procedures Affecting The GRE Deliver Header 298 3.3.2.1. Tunneling GRE Over IPv4 300 By default, the GRE ingress node does not fragment delivery packets. 301 However, the GRE ingress node includes a configuration option that 302 allows delivery packet fragmentation. 304 By default, the GRE ingress node sets the DF-bit in the delivery 305 header to 1 (Don't Fragment). However, the GRE ingress node also 306 supports a configuration option that invokes the following behavior: 308 o when the GRE payload is IPv6, the DF-bit on the delivery header is 309 set to 0 (Fragments Allowed) 311 o when the GRE payload is IPv4, the DF-bit is copied from the 312 payload header to the delivery header 314 When the DF-bit on an IPv4 delivery header is set to 0, the GRE 315 delivery packet can be fragmented by any node between the GRE ingress 316 and the GRE egress. 318 If the delivery packet is fragmented, it is reassembled by the GRE 319 egress. 321 3.3.2.2. Tunneling GRE Over IPv6 323 By default, the GRE ingress node does not fragment delivery packets. 324 However, the GRE ingress node includes a configuration option that 325 allows this. 327 If the delivery packet is fragmented, it is reassembled by the GRE 328 egress. 330 3.4. GRE Egress Node Procedures 332 By default, the GRE egress node silently discards GRE delivery packet 333 fragments, without attempting to reassemble the GRE delivery packets 334 to which the fragments belongs. 336 However, the GRE egress node supports a configuration option that 337 allows it to reassemble GRE delivery packets. 339 4. IANA Considerations 341 This document makes no request of IANA. 343 5. Security Considerations 345 In the GRE fragmentation solution described above, either the GRE 346 payload or the GRE delivery packet can be fragmented. If the GRE 347 payload is fragmented, it is typically reassembled at its ultimate 348 destination. If the GRE delivery packet is fragmented, it is 349 typically reassembled at the GRE egress node. 351 The packet reassembly process is resource intensive and vulnerable to 352 several denial of service attacks. In the simplest attack, the 353 attacker sends fragmented packets more quickly than the victim can 354 reassemble them. In a variation on that attack, the first fragment 355 of each packet is missing, so that no packet can ever be reassembled. 357 Given that the packet reassembly process is resource intensive and 358 vulnerable to denial of service attacks, operators should decide 359 where reassembly process is best performed. Having made that 360 decision, they should decide whether to fragment the GRE payload or 361 GRE delivery packet, accordingly. 363 PMTU Discovery is vulnerable to two denial of service attacks (see 364 Section 8 of [RFC1191] for details). Both attacks are based upon on 365 a malicious party sending forged ICMPv4 Destination Unreachable or 366 ICMPv6 Packet Too Big messages to a host. In the first attack, the 367 forged message indicates an inordinately small PMTU. In the second 368 attack, the forged message indicates an inordinately large MTU. In 369 both cases, throughput is adversely affected. On order to mitigate 370 such attacks, GRE implementations includes a configuration option to 371 disable PMTU discovery on GRE tunnels. Also, they can include a 372 configuration option that conditions the behavior of PMTUD to 373 establish a minimum PMTU. 375 6. Acknowledgements 377 The authors would like to thank Fred Baker, Fred Detienne, Jagadish 378 Grandhi, Jeff Haas, Vanitha Neelamegam, John Scudder, Mike 379 Sullenberger and Wen Zhang for their constructive comments. The 380 authors also express their gratitude to Vanessa Ameen, without whom 381 this memo could not have been written. 383 7. References 385 7.1. Normative References 387 [RFC0792] Postel, J., "Internet Control Message Protocol", STD 5, 388 RFC 792, September 1981. 390 [RFC1191] Mogul, J. and S. Deering, "Path MTU discovery", RFC 1191, 391 November 1990. 393 [RFC1981] McCann, J., Deering, S., and J. Mogul, "Path MTU Discovery 394 for IP version 6", RFC 1981, August 1996. 396 [RFC2784] Farinacci, D., Li, T., Hanks, S., Meyer, D., and P. 397 Traina, "Generic Routing Encapsulation (GRE)", RFC 2784, 398 March 2000. 400 [RFC2890] Dommety, G., "Key and Sequence Number Extensions to GRE", 401 RFC 2890, September 2000. 403 [RFC4023] Worster, T., Rekhter, Y., and E. Rosen, "Encapsulating 404 MPLS in IP or Generic Routing Encapsulation (GRE)", RFC 405 4023, March 2005. 407 [RFC4443] Conta, A., Deering, S., and M. Gupta, "Internet Control 408 Message Protocol (ICMPv6) for the Internet Protocol 409 Version 6 (IPv6) Specification", RFC 4443, March 2006. 411 7.2. Informative References 413 [I-D.pignataro-intarea-gre-ipv6] 414 Pignataro, C., Bonica, R., and S. Krishnan, "IPv6 Support 415 for Generic Routing Encapsulation (GRE)", draft-pignataro- 416 intarea-gre-ipv6-01 (work in progress), October 2014. 418 [RFC4459] Savola, P., "MTU and Fragmentation Issues with In-the- 419 Network Tunneling", RFC 4459, April 2006. 421 Authors' Addresses 423 Ron Bonica 424 Juniper Networks 425 2251 Corporate Park Drive Herndon 426 Herndon, Virginia 20170 427 USA 429 Email: rbonica@juniper.net 430 Carlos Pignataro 431 Cisco Systems 432 7200-12 Kit Creek Road 433 Research Triangle Park, North Carolina 27709 434 USA 436 Email: cpignata@cisco.com 438 Joe Touch 439 USC/ISI 440 4676 Admiralty Way 441 Marina del Rey, California 90292-6695 442 USA 444 Phone: +1 (310) 448-9151 445 Email: touch@isi.edu 446 URI: http://www.isi.edu/touch