idnits 2.17.1 draft-bonica-intarea-lossless-pmtud-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 (October 31, 2019) is 1632 days in the past. Is this intentional? Checking references for intended status: Experimental ---------------------------------------------------------------------------- == Unused Reference: 'RFC5927' is defined on line 266, but no explicit reference was found in the text Summary: 0 errors (**), 0 flaws (~~), 2 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 INTAREA WG R. Bonica 3 Internet-Draft M. Nayak 4 Intended status: Experimental Juniper Networks 5 Expires: May 3, 2020 B. Newton 6 H. Alpan 7 R. Rosborough 8 M. President 9 Harvey Mudd College 10 October 31, 2019 12 Lossless Path MTU Discovery (PMTUD) 13 draft-bonica-intarea-lossless-pmtud-01 15 Abstract 17 This document describes alternative IPv4 PMTUD procedures that do not 18 prevent IP fragmentation and do no rely on the network's ability to 19 deliver ICMP Destination Unreachable messages to the source node. 20 This document also defines a new ICMP message. IPv4 nodes emit this 21 new message when they reassemble a fragmented packet. 23 Status of This Memo 25 This Internet-Draft is submitted in full conformance with the 26 provisions of BCP 78 and BCP 79. 28 Internet-Drafts are working documents of the Internet Engineering 29 Task Force (IETF). Note that other groups may also distribute 30 working documents as Internet-Drafts. The list of current Internet- 31 Drafts is at https://datatracker.ietf.org/drafts/current/. 33 Internet-Drafts are draft documents valid for a maximum of six months 34 and may be updated, replaced, or obsoleted by other documents at any 35 time. It is inappropriate to use Internet-Drafts as reference 36 material or to cite them other than as "work in progress." 38 This Internet-Draft will expire on May 3, 2020. 40 Copyright Notice 42 Copyright (c) 2019 IETF Trust and the persons identified as the 43 document authors. All rights reserved. 45 This document is subject to BCP 78 and the IETF Trust's Legal 46 Provisions Relating to IETF Documents 47 (https://trustee.ietf.org/license-info) in effect on the date of 48 publication of this document. Please review these documents 49 carefully, as they describe your rights and restrictions with respect 50 to this document. Code Components extracted from this document must 51 include Simplified BSD License text as described in Section 4.e of 52 the Trust Legal Provisions and are provided without warranty as 53 described in the Simplified BSD License. 55 Table of Contents 57 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 58 2. Requirements Language . . . . . . . . . . . . . . . . . . . . 4 59 3. The ICMP Packet Reassembly Message . . . . . . . . . . . . . 4 60 4. Security Considerations . . . . . . . . . . . . . . . . . . . 5 61 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 5 62 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 5 63 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 5 64 7.1. Normative References . . . . . . . . . . . . . . . . . . 5 65 7.2. Informative References . . . . . . . . . . . . . . . . . 6 66 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 6 68 1. Introduction 70 For reasons described in [RFC1191], IPv4 source nodes estimate the 71 Path MTU (PMTU) between themselves and destination nodes. An 72 extremely conservative source node estimates the PMTU for each path 73 to be equal to the IPv4 Minimum Link MTU (See Note 1). While such 74 conservative estimates are guaranteed to be less than or equal to the 75 actual PMTU, they are likely to be much less than the actual PMTU. 76 This may adversely affect upper-layer protocol performance. 78 By executing PMTU Discovery (PMTUD) [RFC1191] procedures, IPv4 source 79 nodes can maintain less conservative PMTU estimates. In PMTUD, the 80 source node produces an initial PMTU estimate. This initial estimate 81 is equal to the MTU of the first link along the path to the 82 destination node. It can be greater than the actual PMTU. 84 Having produced an initial PMTU estimate, the source node sends non- 85 fragmentable packets to the destination node (see NOTE 2). If one of 86 these packets is larger than the actual PMTU, a downstream router 87 will not be able to forward the packet through the next link along 88 the path. Therefore, the downstream router drops the packet and 89 sends an Internet Control Message Protocol (ICMP) [RFC0792] 90 Destination Unreachable message to the source node. The Code field 91 in the ICMP message is set to (4) "fragmentation needed". The ICMP 92 message also indicates the MTU of the link through which the packet 93 could not be forwarded. The source node uses this information to 94 refine its PMTU estimate. 96 PMTUD produces a running estimate of the PMTU between a source node 97 and a destination node. Because PMTU is dynamic, the PMTU estimate 98 can be larger than the actual PMTU. In order to detect PMTU 99 increases, PMTUD occasionally resets the PMTU estimate to its initial 100 value and repeats the procedure described above. 102 Ideally, PMTUD operates as described above. However, PMTUD relies on 103 the network's ability to deliver ICMP Destination Unreachable 104 messages to the source node. If the network cannot deliver ICMP 105 Destination Unreachable messages to the source node, PMTUD fails and 106 connectivity may be lost. 108 This document describes alternative PMTUD procedures that do no rely 109 on the network's ability to deliver ICMP Destination Unreachable 110 messages to the source node. In these procedures, the source node 111 produces an initial PMTU estimate. This initial estimate is equal to 112 the MTU of the first link along the path to the destination node. It 113 can be greater than the actual PMTU. 115 Having produced an initial PMTU estimate, the source node sends 116 fragmentable packets to the destination node. If one of these 117 packets is larger than the actual PMTU, a downstream router will not 118 be able to forward the packet, in one piece, through the next link 119 along the path. Therefore, the downstream router fragments the 120 packet and forwards each fragment to the destination node. The 121 destination node reassembles the packet and sends an informational 122 ICMP message to the source node. The informational message indicates 123 that a packet has been reassembled. It also indicates the size of 124 the largest fragment received and contains as much of the original 125 packet as possible without causing the ICMP message to exceed its 126 maximum allowable size (i.e., 576 bytes). 128 The source node should use information contained by the message to 129 refine its PMTU estimate. Having refined its PMTU estimate, the 130 source node should refrain from sending packet long enough to require 131 fragmentation. However, the message may be lost by the network or 132 ignored by the source node. In this case, the source node may 133 continue to send packets that require fragmentation and reassembly. 135 In order to detect PMTU increases, the above-mentioned PMTUD 136 procedures occasionally resets the PMTU estimate to its initial value 137 and repeat the procedure described above. 139 This document defines the new ICMP message, mentioned above. The 140 PMTUD procedures described herein are applicable to IPv4 only, 141 because [RFC8200] does not allow fragmentation by transit nodes. 143 This document does not update [RFC1191]. A source node can executed 144 the PMTUD procedures described herein in addition to [RFC1191] 145 procedures or instead of [RFC1191] procedures. 147 NOTE 1: In IPv4, every host must be capable of receiving a packet 148 whose length is equal to 576 bytes. However, the IPv4 minimum link 149 MTU is not 576. Section 3.2 of [RFC0791] states that the IPv4 150 minimum link MTU is 68 bytes. But for practical purposes, many 151 network operators consider the IPv4 minimum link MTU to be 576 bytes. 152 So, for the purposes of this document, we assume that the IPv4 153 minimum link MTU is 576 bytes. 155 NOTE 2: The DF-bit in the IPv4 header distinguishes fragmentable IPv4 156 packets from non-fragmentable IPv4 packets. If the DF-bit is equal 157 to 0, the packet is fragmentable. If the DF-bit equals 1, the packet 158 is not fragmentable. 160 2. Requirements Language 162 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 163 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 164 "OPTIONAL" in this document are to be interpreted as described in BCP 165 14 [RFC2119] [RFC8174] when, and only when, they appear in all 166 capitals, as shown here. 168 3. The ICMP Packet Reassembly Message 170 IPv4 nodes can emit an ICMP Packet Reassembly message when they 171 reassemble a packet. Figure 1 depicts the ICMP Packet Reassembly 172 message. 174 0 1 2 3 175 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 176 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 177 | Type | Code | Checksum | 178 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 179 | Unused | Length | Largest Fragment | 180 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 181 | Original Datagram | 182 | | 183 | // | 184 | | 185 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 187 Figure 1: The ICMP Packet Reassembly Message 189 o Type (8 bits) - Packet Reassembly. Value 253 (Experiment 1) 191 o Code (8-bits) - No Error (0), or Reassembly Error (1). 193 o Checksum (16 bits) - See [RFC0792]. 195 o Unused (8 bits) - SHOULD be set to zero by sender. MUST be 196 ignored by receiver. 198 o Length (8 bits) - Length of the padded "original datagram" field, 199 measured in 32-bit words. 201 o Largest Fragment (16-bits) - Size of the largest fragment 202 received, measured in bytes, 204 o Original Datagram (variable length) - As much of the original 205 packet as possible, without exceeding the maximum size of an ICMP 206 message (576 bytes). Must be padded to 32-bit boundary. If Code 207 equals Reassembly Error, this field contains the first fragment. 209 As per [RFC1812], all ICMP messages, including the ICMP Packet 210 Reassembly message, SHOULD be rate limited. 212 The Code field is included for informational purposes only. The 213 receiving node SHOULD refine its PMTU estimate, regardless of the 214 value contained by the code field. 216 4. Security Considerations 218 Security considerations for the procedures described herein are 219 identical to those described for PMTUD. See Section 8 of [RFC1191]. 220 [RFC5927]offers mitigations. 222 5. IANA Considerations 224 This document requires no IANA actions. 226 6. Acknowledgements 228 Thanks to TBD for their careful review of this document. 230 7. References 232 7.1. Normative References 234 [RFC0791] Postel, J., "Internet Protocol", STD 5, RFC 791, 235 DOI 10.17487/RFC0791, September 1981, 236 . 238 [RFC0792] Postel, J., "Internet Control Message Protocol", STD 5, 239 RFC 792, DOI 10.17487/RFC0792, September 1981, 240 . 242 [RFC1191] Mogul, J. and S. Deering, "Path MTU discovery", RFC 1191, 243 DOI 10.17487/RFC1191, November 1990, 244 . 246 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 247 Requirement Levels", BCP 14, RFC 2119, 248 DOI 10.17487/RFC2119, March 1997, 249 . 251 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 252 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 253 May 2017, . 255 [RFC8200] Deering, S. and R. Hinden, "Internet Protocol, Version 6 256 (IPv6) Specification", STD 86, RFC 8200, 257 DOI 10.17487/RFC8200, July 2017, 258 . 260 7.2. Informative References 262 [RFC1812] Baker, F., Ed., "Requirements for IP Version 4 Routers", 263 RFC 1812, DOI 10.17487/RFC1812, June 1995, 264 . 266 [RFC5927] Gont, F., "ICMP Attacks against TCP", RFC 5927, 267 DOI 10.17487/RFC5927, July 2010, 268 . 270 Authors' Addresses 272 Ron Bonica 273 Juniper Networks 274 2251 Corporate Park Drive 275 Herndon, Virginia 20171 276 USA 278 Email: rbonica@juniper.net 279 Manoj Nayak 280 Juniper Networks 281 Bangalore, KA 560103 282 India 284 Email: manojnayak@juniper.net 286 Bradley Newton 287 Harvey Mudd College 288 340 Foothill Blvd. 289 Claremont, California 91711 290 USA 292 Email: bnewton@hmc.edu 294 Hakan Alpan 295 Harvey Mudd College 296 340 Foothill Blvd. 297 Claremont, California 91711 298 USA 300 Email: halpan@hnc.edu 302 Radon Rosborough 303 Harvey Mudd College 304 340 Foothill Blvd. 305 Claremont, California 91711 306 USA 308 Email: rrosborough@hmc.edu 310 Miles President 311 Harvey Mudd College 312 340 Foothill Blvd. 313 Claremont, California 91711 314 USA 316 Email: mpresident@hmc.edu