idnits 2.17.1 draft-ietf-6man-icmp-limits-03.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 : ---------------------------------------------------------------------------- ** The document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. RFC 2119 keyword, line 216: '... This code SHOULD be sent by an inte...' RFC 2119 keyword, line 230: '... SHOULD be sent when a node discards...' RFC 2119 keyword, line 238: '... long" SHOULD be sent when a node di...' RFC 2119 keyword, line 254: '...xtension header" SHOULD be sent when a...' RFC 2119 keyword, line 268: '...rocessing limit, a node SHOULD send an...' (14 more instances...) Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (May 29, 2019) is 1793 days in the past. Is this intentional? Checking references for intended status: Full Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Missing Reference: 'IPv6' is mentioned on line 182, but not defined ** Downref: Normative reference to an Proposed Standard RFC: RFC 7045 ** Downref: Normative reference to an Proposed Standard RFC: RFC 4884 Summary: 3 errors (**), 0 flaws (~~), 2 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 INTERNET-DRAFT T. Herbert 3 Intended Status: Standard Quantonium 4 Expires: November 2019 6 May 29, 2019 8 ICMPv6 errors for discarding packets due to processing limits 9 draft-ietf-6man-icmp-limits-03 11 Abstract 13 Network nodes may discard packets if they are unable to process 14 protocol headers of packets due to processing constraints or limits. 15 When such packets are dropped, the sender receives no indication so 16 it cannot take action to address the cause of discarded packets. This 17 document defines ICMPv6 errors that can be sent by a node that 18 discards packets because it is unable to process the protocol 19 headers. A node that receives such an ICMPv6 error may be able to 20 modify what it sends in future packets to avoid subsequent packet 21 discards. 23 Status of this Memo 25 This Internet-Draft is submitted to IETF 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), its areas, and its working groups. Note that 30 other groups may also distribute working documents as 31 Internet-Drafts. 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 The list of current Internet-Drafts can be accessed at 39 http://www.ietf.org/1id-abstracts.html 41 The list of Internet-Draft Shadow Directories can be accessed at 42 http://www.ietf.org/shadow.html 44 Copyright and License Notice 46 Copyright (c) 2019 IETF Trust and the persons identified as the 47 document authors. All rights reserved. 49 This document is subject to BCP 78 and the IETF Trust's Legal 50 Provisions Relating to IETF Documents 51 (http://trustee.ietf.org/license-info) in effect on the date of 52 publication of this document. Please review these documents 53 carefully, as they describe your rights and restrictions with respect 54 to this document. Code Components extracted from this document must 55 include Simplified BSD License text as described in Section 4.e of 56 the Trust Legal Provisions and are provided without warranty as 57 described in the Simplified BSD License. 59 Table of Contents 61 1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 62 1.1 Extension header limits . . . . . . . . . . . . . . . . . . 3 63 1.2 Aggregate header limits . . . . . . . . . . . . . . . . . . 4 64 2 ICMPv6 errors for extension header limits . . . . . . . . . . . 4 65 2.1 Format . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 66 2.2 Unrecognized Next Header type encountered (code 1) . . . . . 5 67 2.3 Extension header too big (code 4) . . . . . . . . . . . . . 5 68 2.4 Extension header chain too long (code 5) . . . . . . . . . . 6 69 2.5 Too many options in extension header (code 6) . . . . . . . 6 70 2.6 Option too big (code 7) . . . . . . . . . . . . . . . . . . 6 71 3 ICMPv6 error for aggregate header limits . . . . . . . . . . . 7 72 3.1 Format . . . . . . . . . . . . . . . . . . . . . . . . . . . 7 73 3.2 Usage . . . . . . . . . . . . . . . . . . . . . . . . . . . 8 74 4 Operation . . . . . . . . . . . . . . . . . . . . . . . . . . . 8 75 4.1 Priority of reporting . . . . . . . . . . . . . . . . . . . 8 76 4.2 Host response . . . . . . . . . . . . . . . . . . . . . . . 9 77 5 Security Considerations . . . . . . . . . . . . . . . . . . . . 10 78 6 IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 11 79 6.1 Parameter Problem codes . . . . . . . . . . . . . . . . . . 11 80 6.2 Destination Unreachable codes . . . . . . . . . . . . . . . 11 81 7 Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . 11 82 8 References . . . . . . . . . . . . . . . . . . . . . . . . . . 11 83 8.1 Normative References . . . . . . . . . . . . . . . . . . . 11 84 8.2 Informative References . . . . . . . . . . . . . . . . . . 12 85 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 12 87 1 Introduction 89 This document specifies ICMPv6 errors that can be sent when a node 90 discards a packet due to it being unable to process the necessary 91 protocol headers because of processing constraints or limits. New 92 ICMPv6 code points are defined as an update to [RFC4443]. Five of the 93 errors are specific to processing limits of extension headers; 94 another error is used when the aggregate protocol headers in a packet 95 exceed the processing limits of a node. 97 1.1 Extension header limits 99 In IPv6, optional internet-layer information is carried in one or 100 more IPv6 Extension Headers [RFC8200]. Extension Headers are placed 101 between the IPv6 header and the Upper-Layer Header in a packet. The 102 term "Header Chain" refers collectively to the IPv6 header, Extension 103 Headers, and Upper-Layer Headers occurring in a packet. Individual 104 extension headers may have a length of 2048 octets and must fit into 105 one MTU. Destination Options and Hop-by-Hop Options contain a list of 106 options in Type-length-value (TLV) format. Each option includes a 107 length of the data field in octets: the minimum size of an option 108 (non-pad type) is two octets and the maximum size is 257 octets. The 109 number of options in an extension header is only limited by the 110 length of the extension header and MTU. Options may also be skipped 111 over by a receiver if they are unknown and the Option Type indicates 112 to skip (first two high order bits are 00). 114 Per [RFC8200], except for Hop by Hop options, extension headers are 115 not examined or processed by intermediate nodes. Many intermediate 116 nodes, however, do examine extension header for various purposes. For 117 instance, a node may examine all extension headers to locate the 118 transport header of a packet in order to implement transport layer 119 filtering or to track connections to implement a stateful firewall. 121 Destination hosts are expected to process all extension headers and 122 options in Hop-by-Hop and Destination Options. 124 Due to the variable lengths, high maximum lengths, or potential for 125 Denial of Service attack of extension headers, many devices impose 126 operational limits on extension headers in packets they process. 127 [RFC7045] discusses the requirements of intermediate nodes that 128 discard packets because of unrecognized extension headers. [RFC8504] 129 discusses limits that may be applied to the number of options in Hop- 130 by-Hop or Destination Options extension headers. When a limit is 131 exceeded, the typical behavior is to silently discard a packet. Both 132 intermediate nodes and end hosts may implement limits to extension 133 header processing. 135 This document defines four Parameter Problem codes and extends the 136 applicably of an existing code that may be sent by a node that 137 discards a packet due to processing limits of extension headers being 138 exceeded. A source host that receives an ICMPv6 error can modify its 139 use of extension headers in subsequent packets sent to the 140 destination in order to avoid further occurrences of packets being 141 discarded. 143 1.2 Aggregate header limits 145 Many hardware devices implement a parsing buffer of a fixed size to 146 process packets. The parsing buffer is expected to contain all the 147 headers (often up to a transport layer header for filtering) that a 148 device needs to examine. Parsing buffers have been implemented with 149 various sizes (512 bytes is common, although some devices have 150 smaller sizes). If the aggregate length of headers in a packet 151 exceeds the size of the parsing buffer, a device will either discard 152 the packet or defer processing to a software slow path. In any case, 153 no indication of a problem is sent back to the sender. 155 This document defines one code for ICMPv6 Destination Unreachable 156 that is sent by a node that is unable to process the headers of a 157 packet due to the aggregate size of the packet headers exceeding a 158 processing limit. A source host that receives an ICMPv6 error can 159 modify the headers used in subsequent packets to try to avoid further 160 occurrences of packets being discarded or relegated to a slow path. 162 2 ICMPv6 errors for extension header limits 164 Four new codes are defined for Parameter Problem types and 165 applicability of one existing code is extended for ICMPv6 errors for 166 extension header limits. 168 2.1 Format 170 The format of the ICMPv6 message for an extension header limit 171 exceeded error is: 173 0 1 2 3 174 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 175 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 176 | Type | Code | Checksum | 177 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 178 | Pointer | 179 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 180 | As much of invoking packet | 181 + as possible without the ICMPv6 packet + 182 | exceeding the minimum IPv6 MTU [IPv6] | 183 IPv6 Fields: 185 Destination Address 186 Copied from the Source Address field of the invoking packet. 188 ICMPv6 Fields: 190 Type 191 4 (Parameter Problem type) 193 Code (pertinent to this specification) 194 1 - Unrecognized Next Header type encountered 195 4 - Extension header too big 196 5 - Extension header chain too long 197 6 - Too many options in extension header 198 7 - Option too big 200 Pointer 201 Identifies the octet offset within the invoking packet where 202 the problem occurred. 204 The pointer will point beyond the end of the ICMPv6 packet if 205 the field having a problem is beyond what can fit in the 206 maximum size of an ICMPv6 error message. 208 2.2 Unrecognized Next Header type encountered (code 1) 210 [RFC8200] specifies that a destination host should send an 211 "unrecognized next header type" when a Next Header value is 212 unrecognized in a packet. This document extends this to allow 213 intermediate nodes to send this same error for a packet that is 214 discarded because the node does not recognize a Next Header type. 216 This code SHOULD be sent by an intermediate node that discards a 217 packet because it encounters a Next Header type that is unknown in 218 its examination. The ICMPv6 Pointer field is set to the offset of the 219 unrecognized value within the original packet. 221 Note that when the original sender receives the ICMPv6 error it can 222 differentiate between the message being sent by a destination host, 223 per [RFC4443], and an error sent by an intermediate host based on 224 matching the source address of the ICMPv6 packet and the destination 225 address of the packet in the ICMPv6 data. 227 2.3 Extension header too big (code 4) 229 An ICMPv6 Parameter Problem with code for "extension header too big" 230 SHOULD be sent when a node discards a packet because the size of an 231 extension header exceeds its processing limit. The ICMPv6 Pointer 232 field is set to the offset of the first octet in the extension header 233 that exceeds the limit. 235 2.4 Extension header chain too long (code 5) 237 An ICMPv6 Parameter Problem with code for "extension header chain too 238 long" SHOULD be sent when a node discards a packet with an extension 239 header chain because an extension header chain exceeds its processing 240 limit. 242 There are two different limits that might be applied: a limit on the 243 total size in octets of the header chain, and a limit on the number 244 of extension headers in the chain. This error code is used in both 245 cases. In the case that the size limit is exceeded, the ICMPv6 246 Pointer is set to first octet beyond the limit. In the case that the 247 number of extension headers is exceeded, the ICMPv6 Pointer is set to 248 the offset of first octet of the first extension header that is 249 beyond the limit. 251 2.5 Too many options in extension header (code 6) 253 An ICMPv6 Parameter Problem with code for "too many options in 254 extension header" SHOULD be sent when a node discards a packet with 255 an extension header that has a number of options that exceed the 256 processing limits of the node. This code is applicable for 257 Destination options and Hop-by-Hop options. The ICMPv6 Pointer field 258 is set to the first octet of the first option that exceeds the limit. 260 2.6 Option too big (code 7) 262 An ICMPv6 Parameter Problem with code for "option too big" is sent in 263 two different cases: when the length of an individual option exceeds 264 a limit, or when the length or number of consecutive padding options 265 exceeds a limit. 267 If a packet is discarded because the length of a Hop-by-Hop or 268 Destination option exceeds a processing limit, a node SHOULD send an 269 ICMPv6 Parameter Problem with code equal to 7. The ICMPv6 Pointer 270 field is set to the offset of the first octet in the option that 271 exceeds the limit. 273 If a packet is discarded because the length or number of consecutive 274 padding options (PAD1 and PADN) exceeds a limit, a node SHOULD send 275 and an ICMPv6 Parameter Problem with code equal to 7. The ICMPv6 276 Pointer field is set to the offset of first octet of the padding 277 option that exceeds the limit. 279 Possible limits related to padding include: 281 * The number of consecutive PAD1 options in destination options or 282 hop-by-hop options is limited to seven octets [RFC8504]. 284 * The length of a PADN options in destination options or hop-by- 285 hop options is limited seven octets [RFC8504]. 287 * The aggregate length of a set of consecutive PAD1 or PADN 288 options in destination options or hop-by-hop options is limited 289 to seven octets. 291 3 ICMPv6 error for aggregate header limits 293 One code is defined for Destination Unreachable type for aggregate 294 header limits. 296 3.1 Format 298 The error for aggregate header limits employs a multi-part ICMPv6 299 message format as defined in [RFC4884]. The extended structure 300 contains a pointer to the octet beyond the limit. 302 The format of the ICMPv6 message for an aggregate header limit 303 exceeded is: 305 0 1 2 3 306 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 307 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 308 | Type | Code | Checksum | 309 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 310 | unused | Length | unused | 311 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 312 | Internet Header + leading octets of original datagram | 313 | | 314 | // | 315 | | 316 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 317 | Pointer | 318 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 320 IPv6 Fields: 322 Destination Address 323 Copied from the Source Address field of the invoking packet. 325 ICMPv6 Fields: 327 Type 328 1 (Destination Unreachable type) 330 Code (pertinent to this specification) 331 8 - Headers too long 333 Length 334 Length of the "original datagram" measured in 64 bit words 336 Pointer 337 Identifies the octet offset within the invoking packet where a 338 limit was exceeded. 340 The pointer will point beyond the end of the original datagram 341 if the field exceeding the limit is beyond what can fit in the 342 maximum size of an ICMPv6 error message. 344 3.2 Usage 346 An ICMPv6 Destination Unreachable error with code for "headers too 347 long" SHOULD be sent when a node discards a packet because the 348 aggregate length of headers in the packet exceeds the processing 349 limits of the node. The Pointer in the extended ICMPv6 structure is 350 set to the offset of the first octet that exceeds the limit. 352 4 Operation 354 Nodes that send or receive ICMPv6 errors due to header processing 355 limits MUST generally comply with ICMPv6 processing as specified in 356 [RFC4443]. 358 4.1 Priority of reporting 360 More than one ICMPv6 error may be applicable to report for a packet. 361 For instance, the number of extension headers in a packet might 362 exceed a limit and the aggregate length of protocol headers might 363 also exceed a limit. Only one ICMPv6 error SHOULD be sent for a 364 packet, so a priority is defined to determine which error to report. 366 The RECOMMENDED reporting priority of ICMPv6 errors for processing 367 limits is from highest to lowest priority: 369 1) Real error (existing codes) 371 2) "Unrecognized Next Header type" encountered by an intermediate 372 node 374 3) "Extension header too big" 376 4) "Option too big" for length or number of consecutive padding 377 options exceeding a limit 379 5) "Option too big" for the length of an option exceeding a limit 381 6) "Too many options in an extension header" 383 7) "Extension header chain too long" for number of extension 384 headers exceeding a limit 386 8) "Extension header chain too long" for size of the extension 387 header chain exceeding a limit 389 9) "Headers too long" 391 4.2 Host response 393 When a source host receives an ICMPv6 error for a processing limit 394 being exceeded, it SHOULD verify the ICMPv6 error is valid and take 395 an appropriate action. 397 The ICMPv6 error SHOULD be logged with sufficient detail for 398 debugging packet loss. The details of the error, including the 399 addresses and the offending extension header or data, should be 400 retained. This, for instance, would be useful for debugging when a 401 node is mis-configured and unexpectedly discarding packets, or when a 402 new extension header is being deployed. 404 A host MAY modify its usage of protocol headers in subsequent packets 405 to avoid repeated occurrences of the same error. 407 For ICMPv6 errors caused by extension header limits being exceeded: 409 * An error SHOULD be reported to an application if the application 410 enabled extension headers for its traffic. In response, The 411 application MAY terminate communications if extension headers 412 are required, stop using extension headers in packets to the 413 destination indicated by the ICMPv6 error, or attempt modify its 414 use of extension headers or headers to avoid further packet 415 discards. 417 * A host system SHOULD take appropriate action if it is 418 automatically inserting extension headers into packets on behalf 419 of the application. If the offending extension header is not 420 required for communication, the host MAY either stop sending it 421 or otherwise modify its use in subsequent packets sent to the 422 destination indicated in the ICMPv6 error. 424 5 Security Considerations 426 The security considerations for ICMPv6 described in [RFC4443] are 427 applicable. The ICMP errors described in this document MAY be 428 filtered by firewalls in accordance with [RFC4890]. 430 In some circumstances, the sending of ICMP errors might conceptually 431 be exploited for denial of service attack or as a means to covertly 432 deduce processing capabilities of nodes as a precursor to denial of 433 service attack. As such, an implementation SHOULD allow configurable 434 policy to withhold sending of the ICMP errors described in this 435 specification in environments where security of ICMP errors is a 436 concern. 438 6 IANA Considerations 440 6.1 Parameter Problem codes 442 IANA is requested to assign the following codes for ICMPv6 type 4 443 "Parameter Problem": 445 4 - Extension header too big 447 5 - Extension header chain too long 449 6 - Too many options in extension header 451 7 - Option too big 453 6.2 Destination Unreachable codes 455 IANA is requested to assign the following codes for ICMPv6 type 1 456 "Destination Unreachable": 458 8 - Headers too long 460 7 Acknowledgments 462 The author would like to thank Ron Bonica, Bob Hinden, and Nick 463 Hilliard for their comments and suggestions that improved this 464 document. 466 8 References 468 8.1 Normative References 470 [RFC4443] Conta, A., Deering, S., and M. Gupta, Ed., "Internet 471 Control Message Protocol (ICMPv6) for the Internet Protocol 472 Version 6 (IPv6) Specification", RFC 4443, DOI 473 10.17487/RFC4443, March 2006, . 476 [RFC8200] Deering, S. and R. Hinden, "Internet Protocol, Version 6 477 (IPv6) Specification", STD 86, RFC 8200, DOI 478 10.17487/RFC8200, July 2017, . 481 [RFC7045] Carpenter, B. and S. Jiang, "Transmission and Processing of 482 IPv6 Extension Headers", RFC 7045, DOI 10.17487/RFC7045, 483 December 2013, . 485 [RFC4884] Bonica, R., Gan, D., Tappan, D., and C. Pignataro, 486 "Extended ICMP to Support Multi-Part Messages", RFC 4884, 487 DOI 10.17487/RFC4884, April 2007, . 490 8.2 Informative References 492 [RFC8504] Chown, T., Loughney, J., and T. Winters, "IPv6 Node 493 Requirements", BCP 220, RFC 8504, DOI 10.17487/RFC8504, 494 January 2019, . 496 [RFC4890] Davies, E. and J. Mohacsi, "Recommendations for Filtering 497 ICMPv6 Messages in Firewalls", RFC 4890, DOI 498 10.17487/RFC4890, May 2007, . 501 Author's Address 503 Tom Herbert 504 Quantonium 505 Santa Clara, CA 506 USA 508 Email: tom@quantonium.net