idnits 2.17.1 draft-ietf-6man-icmp-limits-07.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 (September 30, 2019) is 1670 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) ** Downref: Normative reference to an Proposed Standard RFC: RFC 7045 ** Downref: Normative reference to an Proposed Standard RFC: RFC 4884 -- Possible downref: Non-RFC (?) normative reference: ref. 'IANA-ICMPV6' -- Possible downref: Non-RFC (?) normative reference: ref. 'IANA-ICMPEXT' == Outdated reference: A later version (-26) exists of draft-ietf-6man-segment-routing-header-23 Summary: 2 errors (**), 0 flaws (~~), 2 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 INTERNET-DRAFT T. Herbert 3 Intended Status: Standard Intel 4 Expires: April 2020 6 September 30, 2019 8 ICMPv6 errors for discarding packets due to processing limits 9 draft-ietf-6man-icmp-limits-07 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 specification defines several new ICMPv6 errors that can be sent by a 18 node that discards packets because it is unable to process the 19 protocol headers. A node that receives such an ICMPv6 error may be 20 able to modify what it sends in future packets to avoid subsequent 21 packet 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 . . . . . . . . . . . . . . . . . . . . . . . . . 4 62 1.1 Extension header limits . . . . . . . . . . . . . . . . . . 4 63 1.2 Aggregate header limits . . . . . . . . . . . . . . . . . . 5 64 1.3 Requirements Language . . . . . . . . . . . . . . . . . . . 5 65 2 ICMPv6 errors for extension header limits . . . . . . . . . . . 6 66 2.1 Format . . . . . . . . . . . . . . . . . . . . . . . . . . . 6 67 2.2 Unrecognized Next Header type encountered (code 1) . . . . . 7 68 2.3 Extension header too big (code TBA) . . . . . . . . . . . . 7 69 2.4 Extension header chain too long (code TBA) . . . . . . . . . 7 70 2.5 Too many options in extension header (code TBA) . . . . . . 7 71 2.6 Option too big (code TBA) . . . . . . . . . . . . . . . . . 8 72 3 ICMPv6 error for aggregate header limits . . . . . . . . . . . 8 73 3.1 Format . . . . . . . . . . . . . . . . . . . . . . . . . . . 8 74 3.2 Usage . . . . . . . . . . . . . . . . . . . . . . . . . . . 10 75 4 Operation . . . . . . . . . . . . . . . . . . . . . . . . . . . 11 76 4.1 Priority of reporting . . . . . . . . . . . . . . . . . . . 11 77 4.2 Host response . . . . . . . . . . . . . . . . . . . . . . . 12 78 5 Applicability and use cases . . . . . . . . . . . . . . . . . . 12 79 5.1 Nonconformant packet discard . . . . . . . . . . . . . . . . 12 80 5.2 Reliability of ICMP . . . . . . . . . . . . . . . . . . . . 13 81 5.3 Processing limits . . . . . . . . . . . . . . . . . . . . . 13 82 5.3.1 Long headers and header chains . . . . . . . . . . . . . 13 83 5.3.2 At end hosts . . . . . . . . . . . . . . . . . . . . . . 14 84 5.3.3 At intermediate nodes . . . . . . . . . . . . . . . . . 14 85 6 Security Considerations . . . . . . . . . . . . . . . . . . . . 14 86 7 IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 14 87 7.1 Parameter Problem codes . . . . . . . . . . . . . . . . . . 14 88 7.2 Destination Unreachable codes . . . . . . . . . . . . . . . 15 89 7.3 ICMP Extension Object Classes and Class Sub-types . . . . . 15 90 8 Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . 15 91 9 References . . . . . . . . . . . . . . . . . . . . . . . . . . 15 92 9.1 Normative References . . . . . . . . . . . . . . . . . . . 15 93 9.2 Informative References . . . . . . . . . . . . . . . . . . 16 95 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 16 97 1 Introduction 99 This document specifies several new ICMPv6 errors that can be sent 100 when a node discards a packet due to it being unable to process the 101 necessary protocol headers because of processing constraints or 102 limits. New ICMPv6 code points are defined as an update to [RFC4443]. 103 Five of the errors are specific to processing of extension headers; 104 another error is used when the aggregate protocol headers in a packet 105 exceed the processing limits of a node. 107 1.1 Extension header limits 109 In IPv6, optional internet-layer information is carried in one or 110 more IPv6 Extension Headers [RFC8200]. Extension Headers are placed 111 between the IPv6 header and the Upper-Layer Header in a packet. The 112 term "Header Chain" refers collectively to the IPv6 header, Extension 113 Headers, and Upper-Layer Headers occurring in a packet. Individual 114 extension headers may have a maximum length of 2048 octets and must 115 fit into a single packet. Destination Options and Hop-by-Hop Options 116 contain a list of options in Type-length-value (TLV) format. Each 117 option includes a length of the data field in octets: the minimum 118 size of an option (non-pad type) is two octets and the maximum size 119 is 257 octets. The number of options in an extension header is only 120 limited by the length of the extension header and the Path MTU from 121 the source to the destination. Options may be skipped over by a 122 receiver if they are unknown and the Option Type indicates to skip 123 (first two high order bits are 00). 125 Per [RFC8200], except for Hop by Hop options, extension headers are 126 not examined or processed by intermediate nodes. Many intermediate 127 nodes, however, do examine extension header for various purposes. For 128 instance, a node may examine all extension headers to locate the 129 transport header of a packet in order to implement transport layer 130 filtering or to track connections to implement a stateful firewall. 132 Destination hosts are expected to process all extension headers and 133 options in Hop-by-Hop and Destination Options. 135 Due to the variable lengths, high maximum lengths, or potential for 136 Denial of Service attack of extension headers, many devices impose 137 operational limits on extension headers in packets they process. 138 [RFC7045] discusses the requirements of intermediate nodes that 139 discard packets because of unrecognized extension headers. [RFC8504] 140 discusses limits that may be applied to the number of options in Hop- 141 by-Hop Options or Destination Options extension headers. Both 142 intermediate nodes and end hosts may apply limits to extension header 143 processing. When a limit is exceeded, the typical behavior is to 144 silently discard the packet. 146 This specification defines four Parameter Problem codes and extends 147 the applicably of an existing code that may be sent by a node that 148 discards a packet due to processing limits of extension headers being 149 exceeded. A source host that receives an ICMPv6 error may modify its 150 use of extension headers in subsequent packets sent to the 151 destination in order to avoid further occurrences of packets being 152 discarded. 154 1.2 Aggregate header limits 156 Some hardware devices implement a parsing buffer of a fixed size to 157 process packets. The parsing buffer is expected to contain all the 158 headers (often up to a transport layer header for filtering) that a 159 device needs to examine. If the aggregate length of headers in a 160 packet exceeds the size of the parsing buffer, a device will either 161 discard the packet or defer processing to a software slow path. In 162 any case, no indication of a problem is sent back to the sender. 164 This document defines one code for ICMPv6 Destination Unreachable 165 that is sent by a node that is unable to process the headers of a 166 packet due to the aggregate size of the packet headers exceeding a 167 processing limit. A source host that receives an ICMPv6 error can 168 modify the headers used in subsequent packets to try to avoid further 169 occurrences of packets being discarded or relegated to a slow path. 171 1.3 Requirements Language 173 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 174 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 175 document are to be interpreted as described in [RFC2119]. 177 2 ICMPv6 errors for extension header limits 179 Four new codes are defined for the Parameter Problem type and 180 applicability of one existing code is extended for ICMPv6 errors for 181 extension header limits. 183 2.1 Format 185 The format of the ICMPv6 Parameter Problem message [RFC4443] for an 186 extension header limit exceeded error is: 188 0 1 2 3 189 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 190 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 191 | Type | Code | Checksum | 192 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 193 | Pointer | 194 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 195 | As much of invoking packet | 196 + as possible without the ICMPv6 packet + 197 | exceeding the minimum IPv6 MTU [RFC8200] | 199 IPv6 Fields: 201 Destination Address 202 Copied from the Source Address field of the invoking packet. 204 ICMPv6 Fields: 206 Type 207 4 (Parameter Problem type) 209 Code (pertinent to this specification) 210 1 - Unrecognized Next Header type encountered 211 TBA - Extension header too big 212 TBA - Extension header chain too long 213 TBA - Too many options in extension header 214 TBA - Option too big 216 Pointer 217 Identifies the octet offset within the invoking packet where 218 the problem occurred. 220 The pointer will point beyond the end of the ICMPv6 packet if 221 the field having a problem is beyond what can fit in the 222 maximum size of an ICMPv6 error message. 224 2.2 Unrecognized Next Header type encountered (code 1) 226 [RFC8200] specifies that a destination host should send an 227 "unrecognized next header type" when a Next Header value is 228 unrecognized in a packet. This document extends this to allow 229 intermediate nodes to send this same error for a packet that is 230 discarded because the node does not recognize a Next Header type. 232 This code SHOULD be sent by an intermediate node that discards a 233 packet because it encounters a Next Header type that is unknown in 234 its examination. The ICMPv6 Pointer field is set to the offset of the 235 unrecognized next header value within the original packet. 237 Note that when the original sender receives the ICMPv6 error it can 238 differentiate between the message being sent by a destination host, 239 per [RFC4443], and an error sent by an intermediate host based on 240 matching the source address of the ICMPv6 packet and the destination 241 address of the packet in the ICMPv6 data. 243 2.3 Extension header too big (code TBA) 245 An ICMPv6 Parameter Problem with code for "extension header too big" 246 SHOULD be sent when a node discards a packet because the size of an 247 extension header exceeds its processing limit. The ICMPv6 Pointer 248 field is set to the offset of the first octet in the extension header 249 that exceeds the limit. 251 2.4 Extension header chain too long (code TBA) 253 An ICMPv6 Parameter Problem with code for "extension header chain too 254 long" SHOULD be sent when a node discards a packet with an extension 255 header chain that exceeds its processing limits. 257 There are two different limits that might be applied: a limit on the 258 total size in octets of the header chain, and a limit on the number 259 of extension headers in the chain. This error code is used in both 260 cases. In the case that the size limit is exceeded, the ICMPv6 261 Pointer is set to first octet beyond the limit. In the case that the 262 number of extension headers is exceeded, the ICMPv6 Pointer is set to 263 the offset of first octet of the first extension header that is 264 beyond the limit. 266 2.5 Too many options in extension header (code TBA) 268 An ICMPv6 Parameter Problem with code for "too many options in 269 extension header" SHOULD be sent when a node discards a packet with 270 an extension header that has a number of options that exceed the 271 processing limits of the node. This code is applicable for 272 Destination options and Hop-by-Hop options. The ICMPv6 Pointer field 273 is set to the first octet of the first option that exceeds the limit. 275 2.6 Option too big (code TBA) 277 An ICMPv6 Parameter Problem with code for "option too big" is sent in 278 two different cases: when the length of an individual Hop-by-Hop or 279 Destination option exceeds a limit, or when the length or number of 280 consecutive Hop-by-Hop or Destination padding options exceeds a 281 limit. In the case that the length of an option exceeds a processing 282 limit, the ICMPv6 Pointer field is set to the offset of the first 283 octet of the option that exceeds the limit. In the cases that the 284 length or number of padding options exceeds a limit, the ICMPv6 285 Pointer field is set to the offset of first octet of the padding 286 option that exceeds the limit. 288 Possible limits related to padding include: 290 * The number of consecutive PAD1 options in destination options or 291 hop-by-hop options is limited to seven octets [RFC8504]. 293 * The length of a PADN options in destination options or hop-by- 294 hop options is limited seven octets [RFC8504]. 296 * The aggregate length of a set of consecutive PAD1 or PADN 297 options in destination options or hop-by-hop options is limited 298 to seven octets. 300 3 ICMPv6 error for aggregate header limits 302 One code is defined for Destination Unreachable type for aggregate 303 header limits. 305 3.1 Format 307 The error for aggregate header limits employs a multi-part ICMPv6 308 message format as defined in [RFC4884]. An ICMP extension structure 309 contains one ICMP extension object which contains a Pointer field. 311 The format of the ICMPv6 message for an aggregate header limit 312 exceeded is: 314 0 1 2 3 315 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 316 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+\ 317 | Type | Code | Checksum | | 318 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ I 319 | Length | Unused | C 320 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ M 321 | Invoking Packet | P 322 ~ As much of invoking packet as possible without the ~ | 323 | ICMPv6 packet exceeding the minimum IPv6 MTU [RFC8200] |/ 324 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+/ 325 |Version| Reserved | Checksum |\ 326 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ E 327 | Length | Class-Num | C-Type | X 328 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ T 329 | Pointer | | 330 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+/ 332 IPv6 Fields: 334 Destination Address 335 Copied from the Source Address field of the invoking packet. 337 ICMPv6 Fields: 339 Type 340 1 - Destination Unreachable type 342 Code (pertinent to this specification) 343 TBA - Headers too long 345 Length 346 Length of the padded Invoking Packet measured in 64-bit words. 347 The ICMP extension structure immediately follows the padded 348 Invoking Packet. 350 Invoking Packet 351 Contains as much of invoking packet as possible without the 352 ICMPv6 packet exceeding the minimum IPv6 MTU. The Invoking 353 Packet MUST be zero padded to the nearest 64-bit boundary 354 [RFC4884]. If the original invoking packet did not contain 128 355 octets, the Invoking Packet MUST be zero padded to 128 octets. 357 ICMP Extension Fields: 359 Version 360 2 - per [RFC4884] 362 Reserved 363 0 365 Checksum 366 The one's complement checksum of the ICMP extension [RFC4884] 368 Length 369 8 - length of the object header and Pointer field 371 Class-Num 372 TBA - Extended Information class 374 C-Type 375 TBA - Pointer sub-type 377 Pointer 378 Identifies the octet offset within the invoking packet where a 379 limit was exceeded. 381 The pointer will point beyond the end of the Invoking Packet if 382 the field exceeding the limit is beyond what can fit in the 383 maximum size of an ICMPv6 error message with the ICMP 384 extension. 386 3.2 Usage 388 An ICMPv6 Destination Unreachable error with code for "headers 389 too long" SHOULD be sent when a node discards a packet because 390 the aggregate length of headers in the packet exceeds the 391 processing limits of the node. The Pointer in the extended 392 ICMPv6 structure is set to the offset of the first octet that 393 exceeds the limit. 395 This error is sent in response to a node dropping a packet 396 because the aggregate header chain exceeds the processing 397 limits of a node. The aggregate header chain may be composed of 398 protocol headers other than an IPv6 header and IPv6 extension 399 headers. For instance, in the case of a node parsing a UDP 400 encapsulation protocol, the encapsulating UDP header would be 401 considered to be in the aggregate header chain. 403 As noted in section 4.1, the ICMPv6 Destination Unreachable 404 error with code for "headers too long" has the lowest 405 precedence of the ICMP errors discussed in this specification. 406 If a packet contains an error corresponding to a Parameter 407 Problem code then a node SHOULD send the Parameter Problem 408 error instead of sending the ICMPv6 Destination Unreachable 409 error with code for "headers too long". 411 4 Operation 413 Nodes that send or receive ICMPv6 errors due to header 414 processing limits MUST comply with ICMPv6 processing as 415 specified in [RFC4443]. 417 4.1 Priority of reporting 419 More than one ICMPv6 error may be applicable to report for a 420 packet. For instance, the number of extension headers in a 421 packet might exceed a limit and the aggregate length of 422 protocol headers might also exceed a limit. Only one ICMPv6 423 error SHOULD be sent for a packet, so a priority is defined to 424 determine which error to report. 426 The RECOMMENDED reporting priority of ICMPv6 errors for 427 processing limits is from highest to lowest priority: 429 1) Real error (existing codes) 431 2) "Unrecognized Next Header type" encountered by an intermediate 432 node 434 3) "Extension header too big" 436 4) "Option too big" for length or number of consecutive padding 437 options exceeding a limit 439 5) "Option too big" for the length of an option exceeding a limit 441 6) "Too many options in an extension header" 443 7) "Extension header chain too long" for number of extension 444 headers exceeding a limit 446 8) "Extension header chain too long" for size of an extension 447 header chain exceeding a limit 449 9) "Headers too long" 451 4.2 Host response 453 When a source host receives an ICMPv6 error for a processing limit 454 being exceeded, it SHOULD verify the ICMPv6 error is valid and take 455 appropriate action as suggested below. 457 The general validations for ICMP as described in [RFC4443] are 458 applicable. The packet in the ICMP data SHOULD be validated to match 459 the upper layer process or connection that generated the original 460 packet. Other validation checks that are specific to the upper layers 461 may be performed and are out of the scope of this specification. 463 The ICMPv6 error SHOULD be logged with sufficient detail for 464 debugging packet loss. The details of the error, including the 465 addresses and the offending extension header or data, should be 466 retained. This, for instance, would be useful for debugging when a 467 node is mis-configured and unexpectedly discarding packets, or when a 468 new extension header is being deployed. 470 A host MAY modify its usage of protocol headers in subsequent packets 471 to avoid repeated occurrences of the same error. 473 For ICMPv6 errors caused by extension header limits being exceeded: 475 * An error SHOULD be reported to an application if the application 476 enabled extension headers for its traffic. In response, the 477 application may terminate communications if extension headers 478 are required, stop using extension headers in packets to the 479 destination indicated by the ICMPv6 error, or attempt to modify 480 its use of extension headers or headers to avoid further packet 481 discards. 483 * A host system SHOULD take appropriate action if it is creating 484 packets with extension headers on behalf of the application. If 485 the offending extension header is not required for 486 communication, the host may either stop sending it or otherwise 487 modify its use in subsequent packets sent to the destination 488 indicated in the ICMPv6 error. 490 5 Applicability and use cases 492 5.1 Nonconformant packet discard 494 The ICMP errors defined in this specification may be applicable to 495 scenarios for which a node is dropping packets outside the auspices 496 of any standard specification. For instance, an intermediate node 497 might send a "Headers too long" code in the case that it drops a 498 packet because it is unable to parse deep enough to extract transport 499 layer information needed for packet filtering. Such behavior might be 500 considered nonconformant (with respect to [RFC8200] for instance). 502 This specification does not advocate behaviors that might be 503 considered nonconformant. However, packet discard does occur in real 504 deployments and the intent of this specification is provide 505 visibility as to why packets are being discarded. In the spirit that 506 providing some reason is better than silent drop, this specification 507 RECOMMENDS the sending of ICMP errors even in cases where a node 508 might be discarding packets per a nonconformant behavior. 510 5.2 Reliability of ICMP 512 ICMP is fundamentally an unreliable protocol and in real deployment 513 it may consistently fail over some paths. As with any other use of 514 ICMP, it is assumed that the errors defined in this document are only 515 best effort to be delivered. No protocol should be implemented that 516 relies on reliable delivery of ICMP messages. If necessary, 517 alternative or additional mechanisms may used to augment the 518 processes used to to deduce the reason that packets are being 519 discarded. Such alternative mechanisms are out of scope of this 520 specification. 522 5.3 Processing limits 524 This section discusses the trends and motivations of processing 525 limits that warrant ICMP errors. 527 5.3.1 Long headers and header chains 529 The trend towards longer and more complex headers and header chains 530 needing to be processed by end nodes, as well as intermediate nodes, 531 is driven by: 533 * Increasing prevalence of deep packet inspection in middleboxes. 534 In particular, many intermediate nodes now parse network layer 535 encapsulation protocols or transport layer protocols. 537 * Deployment of routing headers. For instance, [SRH] defines an 538 extension header format that includes a list of IPv6 addresses 539 which may consume a considerable number of bytes. 541 * Development of In-situ OAM headers that allow a rich set of 542 measurements to be gathered in the data path at the cost of 543 additional header overhead which may be significant [IOAM]. 545 * Other emerging use cases of Hop-by-Hop and Destination options. 547 5.3.2 At end hosts 549 End hosts may implement limits on processing extension headers as 550 described in [RFC8504]. Host implementations are usually software 551 stacks that typically don't have inherent processing limitations. 552 Limits imposed by a software stack are more likely to be for denial 553 of service mitigation or performance. 555 5.3.3 At intermediate nodes 557 Hardware devices that process packet headers may have limits as to 558 how many headers or bytes of headers they can process. For instance, 559 a middlebox hardware implementation might have a parsing buffer that 560 contains some number of bytes of packet headers to process. Parsing 561 buffers typically have a fixed size such as sixty-four, 128, or 256 562 bytes. In addition, hardware implementations (and some software 563 implementations) often don't have loop constructs. Processing of a 564 TLV list might be implemented as an unrolled loop so that the number 565 of TLVs that can be processed is limited. 567 6 Security Considerations 569 The security considerations for ICMPv6 described in [RFC4443] are 570 applicable. The ICMP errors described in this document MAY be 571 filtered by firewalls in accordance with [RFC4890]. 573 In some circumstances, the sending of ICMP errors might conceptually 574 be exploited for denial of service attack or as a means to covertly 575 deduce processing capabilities of nodes. As such, an implementation 576 SHOULD allow configurable policy to withhold sending of the ICMP 577 errors described in this specification in environments where security 578 of ICMP errors is a concern. 580 7 IANA Considerations 582 7.1 Parameter Problem codes 584 IANA is requested to assign the following codes for ICMPv6 type 4 585 "Parameter Problem" [IANA-ICMPV6]: 587 * Extension header too big 589 * Extension header chain too long 591 * Too many options in extension header 593 * Option too big 595 7.2 Destination Unreachable codes 597 IANA is requested to assign the following code for ICMPv6 type 1 598 "Destination Unreachable" [IANA-ICMPV6]: 599 * Headers too long 601 7.3 ICMP Extension Object Classes and Class Sub-types 603 IANA is requested to assign the following Class value in the "ICMP 604 Extension Object Classes and Class Sub-types" registry [IANA- 605 ICMPEXT]: 607 * Extended information 609 IANA is requested to assign the following Sub-type within the 610 aforementioned "Extended information" ICMP extension object class: 612 * Pointer 614 8 Acknowledgments 616 The author would like to thank Ron Bonica, Bob Hinden, Nick Hilliard, 617 Michael Richardson, Mark Smith, Suresh Krishnan, and Ole Tran for 618 their comments and suggestions that improved this document. 620 9 References 622 9.1 Normative References 624 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 625 Requirement Levels", BCP 14, RFC 2119, DOI 626 10.17487/RFC2119, March 1997, . 629 [RFC4443] Conta, A., Deering, S., and M. Gupta, Ed., "Internet 630 Control Message Protocol (ICMPv6) for the Internet Protocol 631 Version 6 (IPv6) Specification", RFC 4443, DOI 632 10.17487/RFC4443, March 2006, . 635 [RFC8200] Deering, S. and R. Hinden, "Internet Protocol, Version 6 636 (IPv6) Specification", STD 86, RFC 8200, DOI 637 10.17487/RFC8200, July 2017, . 640 [RFC7045] Carpenter, B. and S. Jiang, "Transmission and Processing of 641 IPv6 Extension Headers", RFC 7045, DOI 10.17487/RFC7045, 642 December 2013, . 644 [RFC4884] Bonica, R., Gan, D., Tappan, D., and C. Pignataro, 645 "Extended ICMP to Support Multi-Part Messages", RFC 4884, 646 DOI 10.17487/RFC4884, April 2007, . 649 [IANA-ICMPV6] "Internet Control Message Protocol version 6 (ICMPv6) 650 Parameters", 654 [IANA-ICMPEXT] ICMP Extension Object Classes and Class Sub-types, 655 658 9.2 Informative References 660 [RFC8504] Chown, T., Loughney, J., and T. Winters, "IPv6 Node 661 Requirements", BCP 220, RFC 8504, DOI 10.17487/RFC8504, 662 January 2019, . 664 [RFC4890] Davies, E. and J. Mohacsi, "Recommendations for Filtering 665 ICMPv6 Messages in Firewalls", RFC 4890, DOI 666 10.17487/RFC4890, May 2007, . 669 [SRH] Filsfils, C., Ed.. Dukes, D., Ed., Previdi, S., Leddy, J., 670 Matsushima, S., Voyer, D., "IPv6 Segment Routing Header 671 (SRH)", draft-ietf-6man-segment-routing-header-23, 672 September 2019. 674 [IOAM] Bhandari, S., Brockners, F., Pignataro, C., Gredler, H., 675 Leddy, J., Youell, S., Mizrahi, T., Kfir, A., Gafni, B., 676 Lpaukhov, P., Spiegel, M., Krishnan, S., Asati, R., "In- 677 situ OAM IPv6 Options", draft-ioametal-ippm-6man-ioam-ipv6- 678 options-02, March 2018 680 Author's Address 682 Tom Herbert 683 Intel 684 Santa Clara, CA 685 USA 687 Email: tom@quantonium.net