idnits 2.17.1 draft-ietf-6man-icmp-limits-08.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 (March 18, 2020) is 1499 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) -- Possible downref: Non-RFC (?) normative reference: ref. 'IANA-DESTUNREACH' -- Possible downref: Non-RFC (?) normative reference: ref. 'IANA-ICMPEXT' -- Possible downref: Non-RFC (?) normative reference: ref. 'IANA-PARAMPROB' Summary: 0 errors (**), 0 flaws (~~), 1 warning (==), 4 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group T. Herbert 3 Internet-Draft Intel 4 Intended status: Standards Track March 18, 2020 5 Expires: September 19, 2020 7 ICMPv6 errors for discarding packets due to processing limits 8 draft-ietf-6man-icmp-limits-08 10 Abstract 12 Network nodes may discard packets if they are unable to process 13 protocol headers of packets due to processing constraints or limits. 14 When such packets are dropped, the sender receives no indication so 15 it cannot take action to address the cause of discarded packets. 16 This specification defines several new ICMPv6 errors that can be sent 17 by a node that discards packets because it is unable to process the 18 protocol headers. A node that receives such an ICMPv6 error may use 19 the information to diagnose packet loss and may modify what it sends 20 in future packets to avoid subsequent packet discards. 22 Status of This Memo 24 This Internet-Draft is submitted in full conformance with the 25 provisions of BCP 78 and BCP 79. 27 Internet-Drafts are working documents of the Internet Engineering 28 Task Force (IETF). Note that other groups may also distribute 29 working documents as Internet-Drafts. The list of current Internet- 30 Drafts is at http://datatracker.ietf.org/drafts/current/. 32 Internet-Drafts are draft documents valid for a maximum of six months 33 and may be updated, replaced, or obsoleted by other documents at any 34 time. It is inappropriate to use Internet-Drafts as reference 35 material or to cite them other than as "work in progress." 37 This Internet-Draft will expire on September 19, 2020. 39 Copyright Notice 41 Copyright (c) 2020 IETF Trust and the persons identified as the 42 document authors. All rights reserved. 44 This document is subject to BCP 78 and the IETF Trust's Legal 45 Provisions Relating to IETF Documents 46 (http://trustee.ietf.org/license-info) in effect on the date of 47 publication of this document. Please review these documents 48 carefully, as they describe your rights and restrictions with respect 49 to this document. Code Components extracted from this document must 50 include Simplified BSD License text as described in Section 4.e of 51 the Trust Legal Provisions and are provided without warranty as 52 described in the Simplified BSD License. 54 Table of Contents 56 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 57 1.1. Extension header limits . . . . . . . . . . . . . . . . . 3 58 1.2. Aggregate header limits . . . . . . . . . . . . . . . . . 4 59 1.3. Nonconformant packet discard . . . . . . . . . . . . . . 4 60 1.4. Terminology . . . . . . . . . . . . . . . . . . . . . . . 5 61 2. ICMPv6 errors for extension header limits . . . . . . . . . . 5 62 2.1. Format . . . . . . . . . . . . . . . . . . . . . . . . . 5 63 2.2. Unrecognized Next Header type encountered by intermediate 64 node (code TBA1) . . . . . . . . . . . . . . . . . . . . 6 65 2.3. Extension header too big (code TBA2) . . . . . . . . . . 6 66 2.4. Extension header chain too long (code TBA3) . . . . . . . 6 67 2.5. Too many extension headers (code TBA4) . . . . . . . . . 6 68 2.6. Too many options in extension header (code TBA5) . . . . 7 69 2.7. Option too big (code TBA6) . . . . . . . . . . . . . . . 7 70 3. ICMPv6 error for aggregate header limits . . . . . . . . . . 7 71 3.1. Format . . . . . . . . . . . . . . . . . . . . . . . . . 8 72 3.2. Usage . . . . . . . . . . . . . . . . . . . . . . . . . . 9 73 4. Operation . . . . . . . . . . . . . . . . . . . . . . . . . . 10 74 4.1. Priority of reporting . . . . . . . . . . . . . . . . . . 10 75 4.2. Host response . . . . . . . . . . . . . . . . . . . . . . 11 76 5. Applicability and use cases . . . . . . . . . . . . . . . . . 11 77 5.1. Reliability of ICMP . . . . . . . . . . . . . . . . . . . 12 78 5.2. Processing limits . . . . . . . . . . . . . . . . . . . . 12 79 5.2.1. Long headers and header chains . . . . . . . . . . . 12 80 5.2.2. At end hosts . . . . . . . . . . . . . . . . . . . . 12 81 5.2.3. At intermediate nodes . . . . . . . . . . . . . . . . 13 82 6. Security Considerations . . . . . . . . . . . . . . . . . . . 13 83 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13 84 7.1. Parameter Problem codes . . . . . . . . . . . . . . . . . 13 85 7.2. Destination Unreachable codes . . . . . . . . . . . . . . 14 86 7.3. ICMP Extension Object Classes and Class Sub-types . . . . 14 87 8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 14 88 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 14 89 9.1. Normative References . . . . . . . . . . . . . . . . . . 14 90 9.2. Informative References . . . . . . . . . . . . . . . . . 15 91 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 16 93 1. Introduction 95 This document specifies several new ICMPv6 errors that can be sent 96 when a node discards a packet due to it being unable to process the 97 necessary protocol headers because of processing constraints or 98 limits. New ICMPv6 code points are defined to supplement those 99 defined in [RFC4443]. Six of the errors are specific to processing 100 of extension headers; another error is used when the aggregate 101 protocol headers in a packet exceed the processing limits of a node. 103 1.1. Extension header limits 105 In IPv6, optional internet-layer information is carried in one or 106 more IPv6 Extension Headers [RFC8200]. Extension Headers are placed 107 between the IPv6 header and the Upper-Layer Header in a packet. The 108 term "Header Chain" refers collectively to the IPv6 header, Extension 109 Headers, and Upper-Layer Headers occurring in a packet. Individual 110 extension headers may have a maximum length of 2048 octets and must 111 fit into a single packet. Destination Options and Hop-by-Hop Options 112 contain a list of options in Type-length-value (TLV) format. Each 113 option includes a length of the data field in octets: the minimum 114 size of an option (non-pad type) is two octets and the maximum size 115 is 257 octets. The number of options in an extension header is only 116 limited by the length of the extension header and the Path MTU from 117 the source to the destination. Options may be skipped over by a 118 receiver if they are unknown and the Option Type indicates to skip 119 (first two high order bits are 00). 121 Per [RFC8200], except for Hop by Hop options, extension headers are 122 not examined or processed by intermediate nodes. Many intermediate 123 nodes, however, do examine extension headers for various purposes. 124 For instance, a node may examine all extension headers to locate the 125 transport header of a packet in order to implement transport layer 126 filtering or to track connections to implement a stateful firewall. 128 Destination hosts are expected to process all extension headers and 129 options in Hop-by-Hop and Destination Options. 131 Due to the variable lengths, high maximum lengths, or potential for 132 Denial of Service attack of extension headers, many devices impose 133 operational limits on extension headers in packets they process. 134 [RFC7045] discusses the requirements of intermediate nodes that 135 discard packets because of unrecognized extension headers. [RFC8504] 136 discusses limits that may be applied to the number of options in Hop- 137 by-Hop Options or Destination Options extension headers. Both 138 intermediate nodes and end hosts may apply limits to extension header 139 processing. When a limit is exceeded, the typical behavior is to 140 silently discard the packet. 142 This specification defines six Parameter Problem codes that may be 143 sent by a node that discards a packet due to processing limits of 144 extension headers being exceeded. The information in these ICMPv6 145 errors may be used for diagnostics to determine why packets are being 146 dropped. Additionally, a source node that receives these ICMPv6 147 errors may be able to modify its use of extension headers in 148 subsequent packets sent to the destination in order to avoid further 149 occurrences of packets being discarded. 151 1.2. Aggregate header limits 153 Some hardware devices implement a parsing buffer of a fixed size to 154 process packets. The parsing buffer is expected to contain all the 155 headers (often up to a transport layer header for filtering) that a 156 device needs to examine. If the aggregate length of headers in a 157 packet exceeds the size of the parsing buffer, a device will either 158 discard the packet or will defer processing to a software slow path. 159 In any case, no indication of a problem is sent back to the sender. 161 This document defines one code for ICMPv6 Destination Unreachable 162 that is sent by a node that is unable to process the headers of a 163 packet due to the aggregate size of the packet headers exceeding a 164 processing limit. The information in this ICMPv6 error may be used 165 for diagnostics to determine why packets are being dropped. 166 Additionally, a source node that receives this ICMPv6 error may be 167 able to modify the headers used in subsequent packets to try to avoid 168 further occurrences of packets being discarded. 170 1.3. Nonconformant packet discard 172 The ICMP errors defined in this specification may be applicable to 173 scenarios for which a node is dropping packets outside the auspices 174 of any standard specification. For instance, an intermediate node 175 might send a "Headers too long" code in the case that it drops a 176 packet because it is unable to parse deep enough to extract transport 177 layer information needed for packet filtering. Such behavior might 178 be considered nonconformant (with respect to [RFC8200] for instance). 180 This specification does not advocate behaviors that might be 181 considered nonconformant. However, packet discard does occur in real 182 deployments and the intent of this specification is provide 183 visibility as to why packets are being discarded. In the spirit that 184 providing some reason is better than silent drop, the sending of ICMP 185 errors is RECOMMENDED even in cases where a node might be discarding 186 packets per a nonconformant behavior. 188 1.4. Terminology 190 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 191 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 192 document are to be interpreted as described in [RFC2119]. 194 2. ICMPv6 errors for extension header limits 196 Six new codes are defined for the Parameter Problem type. 198 2.1. Format 200 The format of the ICMPv6 Parameter Problem message [RFC4443] for an 201 extension header limit exceeded error is: 203 0 1 2 3 204 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 205 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 206 | Type | Code | Checksum | 207 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 208 | Pointer | 209 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 210 | As much of invoking packet | 211 + as possible without the ICMPv6 packet + 212 | exceeding the minimum IPv6 MTU [RFC8200] | 214 IPv6 Header Fields: 216 Destination Address 217 Copied from the Source Address field of the invoking packet. 219 ICMPv6 Fields: 221 Type 222 4 (Parameter Problem type) 224 Code (pertinent to this specification) 226 TBA1 - Unrecognized Next Header type encountered by 227 intermediate node 228 TBA2 - Extension header too big 229 TBA3 - Extension header chain too long 230 TBA4 - Too many extension headers 231 TBA5 - Too many options in extension header 232 TBA6 - Option too big 234 Pointer 235 Identifies the octet offset within the invoking packet where 236 the problem occurred. 238 The pointer will point beyond the end of the Invoking Packet if 239 the field exceeding the limit is beyond what can fit in the 240 maximum size of an ICMPv6 error message extension. If the 241 pointer is used as an offset to read the data in the invoking 242 packet then a node MUST first validate that the pointer value 243 is less than the length of the Invoking Packet data. 245 2.2. Unrecognized Next Header type encountered by intermediate node 246 (code TBA1) 248 This code SHOULD be sent by an intermediate node that discards a 249 packet because it encounters a Next Header type that is unknown in 250 its examination. The ICMPv6 Pointer field is set to the offset of 251 the unrecognized next header value within the original packet. 253 Note that this code is sent by intermediate nodes, and SHOULD NOT be 254 sent by a final destination. If a final destination node observes an 255 unrecognized header then it SHOULD send an ICMP Parameter Problem 256 message with an ICMP Code value of 1 ("unrecognized Next Header type 257 encountered") as specified in [RFC8200]. 259 2.3. Extension header too big (code TBA2) 261 An ICMPv6 Parameter Problem with code for "extension header too big" 262 SHOULD be sent when a node discards a packet because the size of an 263 extension header exceeds its processing limit. The ICMPv6 Pointer 264 field is set to the offset of the first octet in the extension header 265 that exceeds the limit. 267 2.4. Extension header chain too long (code TBA3) 269 An ICMPv6 Parameter Problem with code for "extension header chain too 270 long" SHOULD be sent when a node discards a packet with an extension 271 header chain that exceeds a limit on the total size in octets of the 272 header chain. The ICMPv6 Pointer is set to first octet beyond the 273 limit. 275 2.5. Too many extension headers (code TBA4) 277 An ICMPv6 Parameter Problem with code for "too many extension 278 headers" SHOULD be sent when a node discards a packet with an 279 extension header chain that exceeds a limit on the number of 280 extension headers in the chain. The ICMPv6 Pointer is set to the 281 offset of first octet of the first extension header that is beyond 282 the limit. 284 2.6. Too many options in extension header (code TBA5) 286 An ICMPv6 Parameter Problem with code for "too many options in 287 extension header" SHOULD be sent when a node discards a packet with 288 an extension header that has a number of options that exceed the 289 processing limits of the node. This code is applicable for 290 Destination options and Hop-by-Hop options. The ICMPv6 Pointer field 291 is set to the first octet of the first option that exceeds the limit. 293 2.7. Option too big (code TBA6) 295 An ICMPv6 Parameter Problem with code for "option too big" is sent in 296 two different cases: when the length of an individual Hop-by-Hop or 297 Destination option exceeds a limit, or when the length or number of 298 consecutive Hop-by-Hop or Destination padding options exceeds a 299 limit. In the case that the length of an option exceeds a processing 300 limit, the ICMPv6 Pointer field is set to the offset of the first 301 octet of the option that exceeds the limit. In the cases that the 302 length or number of padding options exceeds a limit, the ICMPv6 303 Pointer field is set to the offset of first octet of the padding 304 option that exceeds the limit. 306 Possible limits related to padding include: 308 * The number of consecutive PAD1 options in destination options 309 or hop-by-hop options is limited to seven octets [RFC8504]. 311 * The length of a PADN options in destination options or hop-by- 312 hop options is limited seven octets [RFC8504]. 314 * The aggregate length of a set of consecutive PAD1 or PADN 315 options in destination options or hop-by-hop options is limited 316 to seven octets. 318 3. ICMPv6 error for aggregate header limits 320 One code is defined for Destination Unreachable type for aggregate 321 header limits. 323 This ICMP error may be applied to other headers in a packet than just 324 the IPv6 header or IPv6 extension headers. Therefore, a Destination 325 Unreachable type with a multi-part ICMPv6 message format is used in 326 lieu of the Parameter Problem type which only indicates errors 327 concerning IPv6 headers. 329 3.1. Format 331 The error for aggregate header limits employs a multi-part ICMPv6 332 message format as defined in [RFC4884]. The extension object class 333 "Extended Information" is defined to contain objects for ancillary 334 information pertaining to an ICMP Destination Unreachable error. 335 Within this object class, the sub-type "Pointer" is defined which 336 contains the Pointer field with similar semantics to the Pointer 337 field in ICMP Parameter Problem errors. 339 The format of the ICMPv6 message for an aggregate header limit 340 exceeded is: 342 0 1 2 3 343 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 344 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+\ 345 | Type | Code | Checksum | | 346 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ I 347 | Length | Unused | C 348 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ M 349 | Invoking Packet | P 350 ~ As much of invoking packet as possible without the ~ | 351 | ICMPv6 packet exceeding the minimum IPv6 MTU [RFC8200] |/ 352 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+/ 353 |Version| Reserved | Checksum |\ 354 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ E 355 | Length | Class-Num | C-Type | X 356 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ T 357 | Pointer | | 358 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+/ 360 IPv6 Header Fields: 362 Destination Address 363 Copied from the Source Address field of the invoking packet. 365 ICMPv6 Fields: 367 Type 368 1 - Destination Unreachable type 370 Code (pertinent to this specification) 371 TBA7 - Headers too long 373 Length 374 Length of the padded Invoking Packet measured in 64-bit words. 375 The ICMP extension structure immediately follows the padded 376 Invoking Packet 378 Invoking Packet 379 Contains as much of invoking packet as possible without the 380 ICMPv6 packet exceeding the minimum IPv6 MTU. The Invoking 381 Packet MUST be zero padded to the nearest 64-bit boundary 382 [RFC4884]. If the original invoking packet did not contain 128 383 octets, the Invoking Packet MUST be zero padded to 128 octets. 385 ICMP Extension Fields: 387 Version 388 2 - per [RFC4884] 390 Reserved 391 0 393 Checksum 394 The one's complement checksum of the ICMP extension [RFC4884] 396 Length 397 8 - length of the object header and Pointer field 399 Class-Num 400 TBA8 - Extended Information class 402 C-Type 403 TBA9 - Pointer sub-type 405 Pointer 406 Identifies the octet offset within the invoking packet where a 407 limit was exceeded. 409 The pointer will point beyond the end of the Invoking Packet if 410 the field exceeding the limit is beyond what can fit in the 411 maximum size of an ICMPv6 error message with the ICMP 412 extension. If the pointer is used as an offset to read the 413 data in the invoking packet then a node MUST first validate 414 that the pointer value is less than the length of the Invoking 415 Packet data. 417 3.2. Usage 419 An ICMPv6 Destination Unreachable error with code for "headers too 420 long" SHOULD be sent when a node discards a packet because the 421 aggregate length of headers in the packet exceeds the processing 422 limits of the node. The Pointer in the extended ICMPv6 structure is 423 set to the offset of the first octet that exceeds the limit. 425 This error is sent in response to a node dropping a packet because 426 the aggregate header chain exceeds the processing limits of a node. 427 The aggregate header chain may be composed of protocol headers other 428 than an IPv6 header and IPv6 extension headers. For instance, in the 429 case of a node parsing a UDP encapsulation protocol, the 430 encapsulating UDP header would be considered to be in the aggregate 431 header chain. 433 As noted in section 4.1, the ICMPv6 Destination Unreachable error 434 with code for "headers too long" has the lowest precedence of the 435 ICMP errors discussed in this specification. If a packet contains an 436 error corresponding to a Parameter Problem code then a node SHOULD 437 send the Parameter Problem error instead of sending the ICMPv6 438 Destination Unreachable error with code for "headers too long". 440 4. Operation 442 Nodes that send or receive ICMPv6 errors due to header processing 443 limits MUST comply with ICMPv6 processing as specified in [RFC4443]. 445 4.1. Priority of reporting 447 More than one ICMPv6 error may be applicable to report for a packet. 448 For instance, the number of extension headers in a packet might 449 exceed a limit and the aggregate length of protocol headers might 450 also exceed a limit. Only one ICMPv6 error SHOULD be sent for a 451 packet, so a priority is defined to determine which error to report. 453 The RECOMMENDED reporting priority of ICMPv6 errors for processing 454 limits is from highest to lowest priority: 456 1) Existing ICMP errors defined in [RFC4443] 458 2) "Unrecognized Next Header type encountered by intermediate 459 node" 461 3) "Extension header too big" 463 4) "Option too big" for length or number of consecutive padding 464 options exceeding a limit 466 5) "Option too big" for the length of an option exceeding a limit 468 6) "Too many options in an extension header" 470 7) "Extension header chain too long" headers exceeding a limit 472 8) "Too many extension headers" 473 9) "Headers too long" 475 4.2. Host response 477 When a source host receives an ICMPv6 error for a processing limit 478 being exceeded, it SHOULD verify the ICMPv6 error is valid and take 479 appropriate action as suggested below. 481 The general validations for ICMP as described in [RFC4443] are 482 applicable. The packet in the ICMP data SHOULD be validated to match 483 the upper layer process or connection that generated the original 484 packet. Other validation checks that are specific to the upper 485 layers may be performed and are out of the scope of this 486 specification. 488 The ICMPv6 error SHOULD be logged with sufficient detail for 489 debugging packet loss. The details of the error, including the 490 addresses and the offending extension header or data, should be 491 retained. This, for instance, would be useful for debugging when a 492 node is mis-configured and unexpectedly discarding packets, or when a 493 new extension header is being deployed. 495 A host MAY modify its usage of protocol headers in subsequent packets 496 to avoid repeated occurrences of the same error. 498 For ICMPv6 errors caused by extension header limits being exceeded: 500 * An error SHOULD be reported to an application if the 501 application enabled extension headers for its traffic. In 502 response, the application may terminate communications if 503 extension headers are required, stop using extension headers in 504 packets to the destination indicated by the ICMPv6 error, or 505 attempt to modify its use of extension headers or headers to 506 avoid further packet discards. 508 * A host system SHOULD take appropriate action if it is creating 509 packets with extension headers on behalf of the application. 510 If the offending extension header is not required for 511 communication, the host may either stop sending it or otherwise 512 modify its use in subsequent packets sent to the destination 513 indicated in the ICMPv6 error. 515 5. Applicability and use cases 516 5.1. Reliability of ICMP 518 ICMP is fundamentally an unreliable protocol and in real deployment 519 it may consistently fail over some paths. As with any other use of 520 ICMP, it is assumed that the errors defined in this document are only 521 best effort to be delivered. No protocol should be implemented that 522 relies on reliable delivery of ICMP messages. If necessary, 523 alternative or additional mechanisms may used to augment the 524 processes used to deduce the reason that packets are being discarded. 525 For instance, the messages may be correlated with information 526 attained through Packetization Layer Path MTU Discovery (PLMTUD) 527 [RFC4821] or Happy Eyeballs for IPv6 [RFC8305]. Details of the 528 interaction with alternative mechanisms are out of scope of this 529 specification. 531 5.2. Processing limits 533 This section discusses the trends and motivations of processing 534 limits that warrant ICMP errors. 536 5.2.1. Long headers and header chains 538 The trend towards longer and more complex headers and header chains 539 needing to be processed by end nodes, as well as intermediate nodes, 540 is driven by: 542 * Increasing prevalence of deep packet inspection in middleboxes. 543 In particular, many intermediate nodes now parse network layer 544 encapsulation protocols or transport layer protocols. 546 * Deployment of routing headers. For instance, 547 [I-D.ietf-6man-segment-routing-header] defines an extension 548 header format that includes a list of IPv6 addresses which may 549 consume a considerable number of bytes. 551 * Development of In-situ OAM headers that allow a rich set of 552 measurements to be gathered in the data path at the cost of 553 additional header overhead which may be significant 554 [I-D.ioametal-ippm-6man-ioam-ipv6-options]. 556 * Other emerging use cases of Hop-by-Hop and Destination options. 558 5.2.2. At end hosts 560 End hosts may implement limits on processing extension headers as 561 described in [RFC8504]. Host implementations are usually software 562 stacks that typically don't have inherent processing limitations. 564 Limits imposed by a software stack are more likely to be for denial 565 of service mitigation or performance. 567 5.2.3. At intermediate nodes 569 Hardware devices that process packet headers may have limits as to 570 how many headers or bytes of headers they can process. For instance, 571 a middlebox hardware implementation might have a parsing buffer that 572 contains some number of bytes of packet headers to process. Parsing 573 buffers typically have a fixed size such as sixty-four, 128, or 256 574 bytes. In addition, hardware implementations (and some software 575 implementations) often don't have loop constructs. Processing of a 576 TLV list might be implemented as an unrolled loop so that the number 577 of TLVs that can be processed is limited. 579 6. Security Considerations 581 The security considerations for ICMPv6 described in [RFC4443] are 582 applicable. The ICMP errors described in this document MAY be 583 filtered by firewalls in accordance with [RFC4890]. 585 In some circumstances, the sending of ICMP errors might conceptually 586 be exploited a means to covertly deduce processing capabilities of 587 nodes. As such, an implementation SHOULD allow configurable policy 588 to withhold sending of the ICMP errors described in this 589 specification in environments where security of ICMP errors is a 590 concern. 592 7. IANA Considerations 594 7.1. Parameter Problem codes 596 IANA is requested to assign the following codes for ICMPv6 type 4 597 "Parameter Problem" [IANA-PARAMPROB]: 599 * Unrecognized Next Header type encountered by intermediate node 600 (value TBA1) 602 * Extension header too big (value TBA2) 604 * Extension header chain too long (value TBA3) 606 * Too many extension headers (value TBA4) 608 * Too many options in extension header (value TBA5) 610 * Option too big (value TBA6) 612 7.2. Destination Unreachable codes 614 IANA is requested to assign the following code for ICMPv6 type 1 615 "Destination Unreachable" [IANA-DESTUNREACH]: 617 * Headers too long (value TBA7) 619 7.3. ICMP Extension Object Classes and Class Sub-types 621 IANA is requested to assign the following Class value in the "ICMP 622 Extension Object Classes and Class Sub-types" registry [IANA- 623 ICMPEXT]: 625 * Extended information (value TBA8) 627 IANA is requested to create a Sub-type registry for the "Extended 628 information" ICMP extension object class. The registration procedure 629 for this registry shall be "Standards Action". The Sub-type value of 630 0 shall be reserved, values greater than zero may be assigned. 632 IANA is requested to assign the following Sub-type within the 633 "Extended information" ICMP extension object class: 635 * Pointer (value TBA9) 637 8. Acknowledgments 639 The author would like to thank Ron Bonica, Bob Hinden, Nick Hilliard, 640 Michael Richardson, Mark Smith, Suresh Krishnan, and Ole Tran for 641 their comments and suggestions that improved this document. 643 9. References 645 9.1. Normative References 647 [IANA-DESTUNREACH] 648 "Internet Control Message Protocol version 6 (ICMPv6) 649 Parameters, Type 1 - Destination Unreachable", 650 . 653 [IANA-ICMPEXT] 654 "ICMP Extension Object Classes and Class Sub-types", 655 . 658 [IANA-PARAMPROB] 659 "Internet Control Message Protocol version 6 (ICMPv6) 660 Parameters, Type 4 - Parameter Problem", 661 . 664 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 665 Requirement Levels", BCP 14, RFC 2119, 666 DOI 10.17487/RFC2119, March 1997, . 669 [RFC4443] Conta, A., Deering, S., and M. Gupta, Ed., "Internet 670 Control Message Protocol (ICMPv6) for the Internet 671 Protocol Version 6 (IPv6) Specification", STD 89, 672 RFC 4443, DOI 10.17487/RFC4443, March 2006, 673 . 675 [RFC4884] Bonica, R., Gan, D., Tappan, D., and C. Pignataro, 676 "Extended ICMP to Support Multi-Part Messages", RFC 4884, 677 DOI 10.17487/RFC4884, April 2007, . 680 [RFC7045] Carpenter, B. and S. Jiang, "Transmission and Processing 681 of IPv6 Extension Headers", RFC 7045, 682 DOI 10.17487/RFC7045, December 2013, . 685 [RFC8200] Deering, S. and R. Hinden, "Internet Protocol, Version 6 686 (IPv6) Specification", STD 86, RFC 8200, 687 DOI 10.17487/RFC8200, July 2017, . 690 9.2. Informative References 692 [I-D.ietf-6man-segment-routing-header] 693 Filsfils, C., Dukes, D., Previdi, S., Leddy, J., 694 Matsushima, S., and D. Voyer, "IPv6 Segment Routing Header 695 (SRH)", draft-ietf-6man-segment-routing-header-26 (work in 696 progress), October 2019. 698 [I-D.ioametal-ippm-6man-ioam-ipv6-options] 699 Bhandari, S., Brockners, F., Pignataro, C., Gredler, H., 700 Leddy, J., Youell, S., Mizrahi, T., Kfir, A., Gafni, B., 701 Lapukhov, P., Spiegel, M., Krishnan, S., and R. Asati, 702 "In-situ OAM IPv6 Options", draft-ioametal-ippm-6man-ioam- 703 ipv6-options-02 (work in progress), March 2019. 705 [RFC4821] Mathis, M. and J. Heffner, "Packetization Layer Path MTU 706 Discovery", RFC 4821, DOI 10.17487/RFC4821, March 2007, 707 . 709 [RFC4890] Davies, E. and J. Mohacsi, "Recommendations for Filtering 710 ICMPv6 Messages in Firewalls", RFC 4890, 711 DOI 10.17487/RFC4890, May 2007, . 714 [RFC8305] Schinazi, D. and T. Pauly, "Happy Eyeballs Version 2: 715 Better Connectivity Using Concurrency", RFC 8305, 716 DOI 10.17487/RFC8305, December 2017, . 719 [RFC8504] Chown, T., Loughney, J., and T. Winters, "IPv6 Node 720 Requirements", BCP 220, RFC 8504, DOI 10.17487/RFC8504, 721 January 2019, . 723 Author's Address 725 Tom Herbert 726 Intel 727 Santa Clara, CA 728 USA 730 Email: tom@quantonium.net