idnits 2.17.1 draft-ietf-6man-eh-limits-00.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 Security Considerations section. ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == The document seems to lack the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). -- The document date (31 January 2022) is 813 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) == Unused Reference: 'RFC2119' is defined on line 817, but no explicit reference was found in the text -- Obsolete informational reference (is this intentional?): RFC 2460 (Obsoleted by RFC 8200) Summary: 2 errors (**), 0 flaws (~~), 3 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group T. Herbert 3 Internet-Draft SiPanda 4 Intended status: Standards Track 31 January 2022 5 Expires: 4 August 2022 7 Limits on Sending and Processing IPv6 Extension Headers 8 draft-ietf-6man-eh-limits-00 10 Abstract 12 This specification defines various limits that may be applied to 13 receiving, sending, and otherwise processing packets that contain 14 IPv6 extension headers. The need for such limits is pragmatic to 15 facilitate interoperability amongst hosts and routers in the presence 16 of extension headers and thereby increasing the feasibility of 17 deployment of extension headers. The limits described here establish 18 the minimum baseline of support for use of extension headers in the 19 Internet. If it is known that all communicating parties for a 20 particular commumication, including end hosts and any intermediate 21 nodes in the path, are capable of supporting more than the baseline 22 then these default limits may be freely exceeded. 24 Status of This Memo 26 This Internet-Draft is submitted in full conformance with the 27 provisions of BCP 78 and BCP 79. 29 Internet-Drafts are working documents of the Internet Engineering 30 Task Force (IETF). Note that other groups may also distribute 31 working documents as Internet-Drafts. The list of current Internet- 32 Drafts is at https://datatracker.ietf.org/drafts/current/. 34 Internet-Drafts are draft documents valid for a maximum of six months 35 and may be updated, replaced, or obsoleted by other documents at any 36 time. It is inappropriate to use Internet-Drafts as reference 37 material or to cite them other than as "work in progress." 39 This Internet-Draft will expire on 4 August 2022. 41 Copyright Notice 43 Copyright (c) 2022 IETF Trust and the persons identified as the 44 document authors. All rights reserved. 46 This document is subject to BCP 78 and the IETF Trust's Legal 47 Provisions Relating to IETF Documents (https://trustee.ietf.org/ 48 license-info) in effect on the date of publication of this document. 49 Please review these documents carefully, as they describe your rights 50 and restrictions with respect to this document. Code Components 51 extracted from this document must include Revised BSD License text as 52 described in Section 4.e of the Trust Legal Provisions and are 53 provided without warranty as described in the Revised BSD License. 55 Table of Contents 57 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 58 1.1. Related work . . . . . . . . . . . . . . . . . . . . . . 3 59 1.2. Adherence to the Robustness Principle . . . . . . . . . . 4 60 1.2.1. Be conservative in what you send . . . . . . . . . . 4 61 1.2.2. Be liberal in what you receive . . . . . . . . . . . 5 62 2. Overview and motivation of extension header limits . . . . . 5 63 2.1. Types of nodes . . . . . . . . . . . . . . . . . . . . . 5 64 2.2. Types of limits . . . . . . . . . . . . . . . . . . . . . 6 65 2.2.1. Limits on extension header length . . . . . . . . . . 6 66 2.2.2. Limits on option length . . . . . . . . . . . . . . . 6 67 2.2.3. Limits on number of extension headers . . . . . . . . 7 68 2.2.4. Limits on number of options . . . . . . . . . . . . . 7 69 2.2.5. Limits on padding options . . . . . . . . . . . . . . 8 70 2.2.6. Limit on IPv6 header chain length . . . . . . . . . . 8 71 3. Requirements . . . . . . . . . . . . . . . . . . . . . . . . 12 72 3.1. List of limits . . . . . . . . . . . . . . . . . . . . . 12 73 3.2. Host requirements . . . . . . . . . . . . . . . . . . . . 12 74 3.2.1. Sending extension headers . . . . . . . . . . . . . . 12 75 3.2.2. Receiving extension headers . . . . . . . . . . . . . 13 76 3.3. Intermediate node and intermediate destination 77 requirements . . . . . . . . . . . . . . . . . . . . . . 15 78 3.4. Intermediate destination requirements . . . . . . . . . . 17 79 4. References . . . . . . . . . . . . . . . . . . . . . . . . . 18 80 4.1. Normative References . . . . . . . . . . . . . . . . . . 18 81 4.2. Informative References . . . . . . . . . . . . . . . . . 18 82 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 19 84 1. Introduction 86 Extension headers are a core component of the IPv6 protocol as 87 specified in [RFC8200]. IPv6 extension headers were originally 88 defined with few restrictions. For instance, there is no specified 89 limit on the number of extension headers a packet may have, nor is 90 there a limit on the length in bytes of extension headers in a packet 91 (other than being limited by the MTU). Similarly, variable length 92 extension headers typically do not have prescribed limits such as 93 limits on the number of Hop-by-Hop or Destination options in a 94 packet. The lack of limits essentially requires implementations to 95 handle every conceivable usage of the protocol, including a myriad of 96 use cases those are obviously outside the realm of ever being 97 realistic or useful in real world deployment. 99 The lack of limits and the requirements for supporting a virtually 100 open-ended protocol have led to a significant lack of support and 101 deployment of extension headers [RFC7872]. Instead of attempting to 102 satisfy the protocol requirements concerning extension headers, some 103 router and middlebox vendors have opted to either invent and apply 104 their own ad hoc limits, relegate packets with extension headers to 105 slow path processing, or have gone so far as to summarily discard all 106 packets with extension headers [RFC9098]. The net result of this 107 situation is that deployment and use of extension headers is 108 underwhelming to the extent that they are sometimes considered 109 unusable on the Internet, and hence IPv6 extension headers have not 110 lived up to their potential as the core extensibility mechanism of 111 IPv6. 113 As an example, consider that Hop-by-Hop Options and Destination 114 Options have no limit on how many options may be placed in a packet, 115 nor any limits as to how many options a receiver must process. A 116 single 1500 byte MTU sized packet could legally contain a Hop-by-Hop 117 Options extension header with over seven hundred two byte options. 118 There is no use case for this other than being a Denial of Service 119 attack where an attacker simply creates packets with hundreds of 120 small unknown Hop-by-Hop Options with the two high order bits in the 121 option type set to 00 meaning to skip the unknown option. Any node 122 in that path that attempts to dutifully process all these options per 123 the requirements of [RFC2460] would be easily overwhelmed by the 124 processing needed to parse these options (this is true for both 125 hardware or software implementations). 127 This specification describes various limits that hosts and 128 intermediate nodes may apply to the processing of extension headers. 129 The goal of establishing limits is to narrow the requirements to 130 better match reasonable use cases thereby facilitating practical 131 implementation. Subsequently, this increases the viability of 132 extension headers as the extensibility mechanism of IPv6. 134 1.1. Related work 136 Some of the problems of unlimited extension headers have been 137 addressed in certain aspects. 139 [RFC8200] relaxed the requirement that all nodes in the path must 140 process Hop-by-Hop Options to be: 142 NOTE: While [RFC2460] required that all nodes must examine and 143 process the Hop-by-Hop Options header, it is now expected that 144 nodes along a packet's delivery path only examine and process the 145 Hop-by-Hop Options header if explicitly configured to do so. 147 Section 5.3 of [RFC8504] defines a number of limits that hosts may 148 apply to processing extensions. For instance: 150 A host MAY set a limit on the maximum number of non-padding 151 options allowed in the destination options and Hop-by-Hop 152 extension headers. If this feature is supported, the maximum 153 number SHOULD be configurable, and the default value SHOULD be set 154 to 8. 156 [RFC8883] defines a set of ICMP errors that my be sent if a limit 157 concerning extension headers is exceeded and a node discards a packet 158 as a result. This RFC allows both hosts and routers to send such 159 messages (effectively acknowledging that some routers drop packets 160 with extension headers even though such behavior is non-conformant 161 with [RFC8200]). 163 [RFC7872] presents real-world data regarding the extent to which 164 packets with IPv6 Extension Headers (EHs) are dropped in the 165 Internet, and [RFC8200] summarizes the operational implications of 166 IPv6 extension headers, and attempts to analyze reasons why packets 167 with IPv6 extension headers are often dropped in the public Internet. 169 1.2. Adherence to the Robustness Principle 171 The robustness principle, or Postel's Law, can be stated as "Be 172 conservative in what you send, liberal in what you receive". This 173 section considers the limits defined in this specification with 174 respect to the robustness principle. 176 1.2.1. Be conservative in what you send 178 The limits on sending extension headers are well aligned with the 179 send clause of the robustness principle. A sender of extension 180 headers is generally constrained in its use of extension headers. 181 Most of these limits are assumed to be the default to apply in an 182 arbitrary environment such as the public Internet, that is they can 183 be considered "baseline limits". These limits may be relaxed if a 184 sender has a priori information that all possible nodes in path will 185 properly handle packets that exceed the baseline limits. In 186 particular, if a sender is sending in a limited domain, it might be 187 known that all nodes in the limited domain have sufficient 188 capabilities to handle packets exceeding the baseline limits. 190 1.2.2. Be liberal in what you receive 192 Considering the receive clause of the robustness principle, this 193 specification recommends that receivers accept all packets with 194 extension headers, however they may ignore extension headers or 195 options within extension headers (in accordance with [RFC8200]). In 196 particular, the philosophy of this specification is that intermediate 197 nodes should not drop packets on the basis that they don't have 198 sufficient capabilities to process all the headers in a packet. As 199 such, intermediate nodes may define arbitrarily restrictive limits on 200 what they process with regards to extension headers as long as the 201 action taken when those limits are exceeded is to ignore items beyond 202 the limit. Hosts are more constrained in this regard since they 203 generally can't correctly process a packet without processing all the 204 headers, so when limits are exceeded on a host, packets should be 205 dropped. It should be noted that hosts stacks inherently have more 206 processing capabilities than intermediate nodes, so it is expected 207 that they should be able to support higher limits for processing 208 extension headers. 210 This specification does specify one hard requirement for receiving 211 nodes, namely nodes must be able to properly handle packets having an 212 IPv6 header chain length up to 104 bytes. This requirement 213 acknowledges that some intermediate nodes perform deep packet 214 inspection to extract information from transport layer headers 215 [RFC9098]. Often a node that requires parsing transport layer 216 information will have a fixed sized "parsing buffer" to contain 217 packet headers. If the transport layer headers within a packet are 218 beyond the extent of the parsing buffer then an implementation may 219 take some detrimental action such as arbitrarily dropping packets. 220 To this end, this specification requires that any intermediate node 221 that requires access to to transport layer header must minimally be 222 able to parse at least 128 bytes of headers, from which the 104 byte 223 limit for the IP header chain is derived. 225 2. Overview and motivation of extension header limits 227 This specification considers extension header limits in three 228 dimensions: 1) The types of nodes that may process extension headers 229 and the requirements specific to each type, 2) The types of limits 230 that may be applied, 3) The action taken when a limit is exceeded. 232 2.1. Types of nodes 234 For the purposes of describing handling of extension headers this 235 specification considers three types of node in an IPv6 network: 237 * Hosts: The source of an IPv6 packet, as addressed by the source 238 address, or the final destination node of a packet as addressed by 239 the destination address in a packet with no Routing header or as 240 addressed by last segment in a Routing header. 242 * Intermediate destination: An intermediate destination node in a 243 Routing header as addressed by the destination address of a packet 244 with a Routing header where the address is not the address for the 245 last segment in the Routing header 247 * Intermediate nodes: A router on the path that is not addressed by 248 the packet's destination address. 250 2.2. Types of limits 252 The limits and requirements for handling extension headers defined in 253 this specification fall in the following categories: 255 * Limits on extension header length 257 * Limits on option length 259 * Limits on number of extension headers 261 * Limits on number of options 263 * Limits on padding for extension headers with options 265 * Limits on the length of the IPv6 header chain 267 2.2.1. Limits on extension header length 269 [RFC8504] defines limits that may be defined for the length of an 270 extension header. Those limits are extended to be applicable to 271 intermediate nodes. [RFC8883] defines ICMP Parameter Problem codes 272 that may be sent when an extension header is exceeded. 274 2.2.2. Limits on option length 276 A node may establish a limit on the size Hop-by-Hop or Destination 277 options. Conceivably, such a limit could apply to all option types, 278 or length limits may be specific to individual options. [RFC8883] 279 defines ICMP Parameter Problem codes that may be sent when an option 280 length limit is exceeded. 282 2.2.3. Limits on number of extension headers 284 A node may define a limit on the number of extension headers it will 285 process. Although [RFC8200] only defines four types of extension 286 headers, it does not preclude the same type of extension header being 287 present multiple times. A limit on the number of extension headers 288 could be useful to disallow packets that contain multiple instances 289 of the same extension header. 291 2.2.4. Limits on number of options 293 Limits may be established for the number of options sent or received 294 (specifically applicable to Hop-by-Hop options and Destination 295 options). The need for this limit arises from the fact that 296 [RFC8200] does not specify a limit. Requiring nodes to process 297 packets with tens or hundreds of options has no foreseeable use cases 298 in deployment except as a denial of service attack. [RFC8504] has 299 proposed such a limit for host processing of Hop-by-Hop and 300 Destination options with a default of eight options. This 301 specification extends that limit to be applicable to intermediate 302 nodes. Specific limits may be established for number of non-padding 303 options or the number of all options including padding. 305 To derive a limit on all options, one can assume that at most one 306 padding option is used between two non-padding options (an explicit 307 limit on consecutive padding options is described below). With this 308 assumption, we can extrapolate a reasonable limit on the number of 309 all options that should be twice the limit of the number of non- 310 padding options. Per [RFC8504], the recommended default limit for 311 number of non-padding options is eight, so this specification 312 establishes a maximum default limit of sixteen options including 313 padding options. The choice of sixteen options as a default limit 314 attempts to strikes a balance between allowing extensibility and 315 maintaining reasonable expectations for node processing requirements. 317 With regards to extensibility, it is observed that in the almost 318 thirty year history of IPv6 there are only thirteen defined non- 319 deprecated Destination options and Hop-by-Hop options and three 320 temporary assigned options. Current evidence suggests that having 321 more than one Destination option or Hop-by-Hop option in a packet is 322 rare, and extrapolating that point with the rate of new options being 323 defined suggests a limit of eight non-padding options allows for 324 sufficient extensibility in the foreseeable future. 326 With regards to processing requirements, TLVs, e.g. Hop-by-Hop 327 options and Destination options, have historically been considered 328 difficult to process efficiently due to their serial processing 329 requirements and combinatorial nature. TLV processing has been a 330 particularly acute problem for Ased SIC devices. Recently, there is 331 a strong trend in programmable implementation even in high 332 performance routers using emerging programming frameworks such as 333 PANDA and P4. Programmable implementations are better equipped to 334 handle TLVs, at least for a reasonably small number. It might also 335 be pointed that the need to efficiently process TLVs exists in other 336 protocols, for instance processing TCP requires processing of TLVs 337 which are an intrinsic part of the protocol. 339 2.2.5. Limits on padding options 341 [RFC8200] defines PAD1 and PADN options that respectively provide one 342 byte or N bytes of padding in an extension header. The purpose of 343 padding is to properly align the following non-padding option to it's 344 expected alignment, or to add padding after the last Destination or 345 Hop-by-Hop option so that the length of the extension header is a 346 multiple of eight bytes as required by [RFC8200]. [RFC8504] defines 347 limits on number of bytes used for consecutive padding where the 348 amount of padding between options or at the end of the extension 349 header is no more than eight bytes; this limit is sufficient to align 350 any following data after the padding to eight bytes. These limits 351 are extended to be applicable to intermediate nodes. 353 This specification allows a receiving node to set a requirement that 354 consecutive padding options are not present in a packet; which in 355 turn requires a sender to not place consecutive padding options in a 356 packet. The rationale for this limit is that a PAD1 or PADN option 357 is able to provide one to 257 bytes of padding, so a single padding 358 option is sufficient for any expected use case of padding. When the 359 sender creates options, it can compute the amount of padding 360 necessary to satisfy the alignment requirements of the following 361 data. If one byte of padding is needed a PAD1 option is used, if 362 more than one byte of padding is needed then an appropriate PADN 363 options. 365 2.2.6. Limit on IPv6 header chain length 367 Intermediate nodes often perform deep packet inspection (DPI) in 368 order to implement various functions in the network. Routers perform 369 DPI when they inspect packets beyond the IPv6 header or beyond Hop- 370 by-Hop options if they are present. Some router implementations must 371 inspect the transport layer headers in order to process and forward 372 the packet, and if the transport layer headers are not readable a 373 packet may be dropped. Even if a transport layer header is in plain 374 text within a packet, some devices may not be capable of reading it 375 if the header is too deep in the packet. 377 Hardware devices often have constraints on how much of the headers in 378 a packet can be parsed for DPI. A typical design is that some 379 portion of the beginning of a received packet is loaded into a memory 380 buffer for header parsing (i.e. the parsing buffer). The size of 381 this parsing buffer is often fixed per device. 383 To derive a size limit on the IPv6 header chain, we need to take into 384 account headers in a packet that might be subject to DPI which 385 include the link layer header through at least the pertinent fields 386 of the transport layer header. The most common required information 387 is the transport layer port numbers which typically occupy the first 388 four bytes of the transport headers (e.g. TCP, UDP, SCTP, DCCP, 389 etc.). Inspection of port numbers may be needed for stateless load 390 balancing as well as port filtering. There are middleboxes that may 391 need to inspect more of transport layer headers or the transport 392 payload, however those can be considered specialized devices that 393 perform work beyond simple packet forwarding and filtering and hence 394 should have more capabilities for DPI. 396 In addition to limits on the length of the IP header chain, it is 397 conceivable that there could be a limit on the length of the whole 398 header chain. The whole header chain would comprise the IPv6 header 399 chain as well as any headers that are part of network encapsulation 400 that precede the innermost transport layer. The definition of such a 401 limit is out of scope for this document, however [RFC8883] defines an 402 ICMP error to send when a limit on size of an aggregate header chain 403 is exceeded. 405 This document specifies that the minimum supported limit for IPv6 406 header chains is 104 bytes. The value is derived by assuming that 407 nodes have the ability to process at least the first 128 bytes of a 408 packet (that is they have a parsing buffer that can contain at least 409 128 bytes). The 128 byte parsing buffer would be expected to at 410 least contain: 412 * 16 bytes for a Layer 2 header (e.g. Ethernet header) 414 * 40 bytes for the IPv6 header 416 * 64 bytes for the extension headers 418 * 8 bytes for the transport layer (i.e the first eight bytes of the 419 transport layer header 421 This scheme thus establishes a requirement that all Internet devices 422 are capable of correctly processing packets with up to sixty-four 423 bytes of extension headers, and subsequently it establishes a 424 requirement that a host shouldn't send packets with more than sixty- 425 four bytes of extension headers. Note that this establishes a global 426 baseline requirement across the Internet, within a limited domain 427 higher limits could be applied. 429 128 bytes is likely the minimal useful parsing buffer size in 430 deployment today. Devices performing a very narrow DPI could 431 conceptually use a smaller parsing buffer, for instance that could be 432 as small as sixty-four bytes which accommodates an L2 header, IPv6 433 header, and eight bytes of transport header; however, such a device 434 would be extremely limited in capabilities and if they do exist they 435 are likely legacy devices that will eventually be decommissioned. 436 Many routers now have the capability to perform DPI into 437 encapsulation headers which implies they already have a larger 438 parsing buffer than this baseline minimum. 440 Similar to limiting the number of options allowing in a packet, 441 setting a limit for IP header length chain is a tradeoff between 442 extensibility and feasible implementation. 444 For extensibility, the pertinent extension headers contributing to 445 the sixty-four byte limit are mostly Hop-by-Hop and Destination 446 options. The Routing Header extension header is really intended for 447 limited domains and not the Internet (e.g. SRv6 Routing Header is 448 confined to a Segment Routing Domain) and therefore would be subject 449 to a domain specific limit for IP header chain length. Encryption 450 Header may be used on the Internet, however encryption obfuscates the 451 encapsulated transport headers such that such that intermediate nodes 452 can't inspect them regardless of their position in a packet. 453 Fragmentation may be used in the Internet, however only the first 454 fragment of a fragmented packet might contain transport layer headers 455 that could be read by an Intermediate node. In any case, the 456 Fragment Header is only four bytes so that would not be a 457 particularly large portion of a sixty-four byte limit. 459 The Authentication Header is usable on the Internet and does allow 460 the transport layer headers to be in readable in plain text. 461 However, Authentication Header is relatively large, typically thirty- 462 two bytes or more, so it would contribute significantly to a limit on 463 IP header chain length. On the other hand, the use of Authentication 464 Header, without encryption, is currently rare on the Internet. 466 Individual Hop-by-Hop Destination Options may also be categorized as 467 being intended for use over the Internet or just in limited domains. 468 For instance, the IOAM Hop-by-Hop option is intended for use in 469 limited domains. 471 Paring this down, the types extension headers and Destination and 472 Hop-by-Hop options that might be used outside of limited domains are 473 fairly limited. Options that are intended for use over the public 474 Internet could be defined to be small and compact to promote not 475 exceeding a sixty-four byte limit on extension headers, whereas 476 options constrained to a limited domain could be larger since larger 477 limits can be assumed. 479 2.2.6.1. Action when limit is exceeded 481 For each limit that is defined, an action is specified for when the 482 limit is exceeded. The appropriate action depends on whether the 483 processing node is the destination host, an intermediate destination, 484 or an intermediate node. For a destination host, the typical action 485 to take when a limit is exceeded is to discard the packet. This is 486 appropriate since the destination host is required to process all of 487 the headers in a packet, and if a limit is exceeded then it cannot 488 process the packet so there is no other alternative but to discard. 490 For intermediate nodes, the typical action to take when a limit is 491 exceeded is to stop processing headers at the point the limit is 492 reached and to forward the packet on. [RFC8200] allows that an 493 intermediate may not process the Hop-by-Hop Options extension headers 494 therefore an intermediate node may ignore all of the Hop-by-Hop 495 options in a packet. This specification expands on that requirement 496 to allow an intermediate node to process some arbitrary subset of 497 consecutive Hop-by-Hop options in the TLV list and to ignore the 498 following ones. In the case of an egregious violation of a limit, 499 for instance an attacker sends three hundred options in a packet, the 500 destination host can decide if the appropriate response is to drop 501 (the destination host must process all options). Note that this 502 provision motivates the sender to place Hop-by-Hop Options in the 503 packet so that those considered more important are placed first. It 504 should also be noted that [RFC8200] sets a default limit of eight; 505 this specification adds a counterpart for sending hosts that they 506 shouldn't send more than eight Hop-by-Hop options. 508 Intermediate destinations have characteristics of both hosts and 509 intermediate modes. If a limit is exceeded related to Hop-by-Hop 510 options then the suggested action in this specification is to assume 511 the same processing of limits as intermediate nodes. If limits are 512 exceeded that affect the processing specific to an intermediate 513 destination, such as limits on Destination options before the Routing 514 header, then the action should be to discard packet. 516 3. Requirements 518 This section lists the normative requirements related to sending and 519 processing extension headers. 521 3.1. List of limits 523 The set of limits that a node may apply when processing extension 524 headers include: 526 * Too many non-padding or padding options 528 * Extension header too big 530 * Option too big 532 * Too many consecutive padding options 534 * Too many consecutive bytes of padding 536 * Extension header chain too long 538 * Aggregate header chain too long 540 * Too many extension headers 542 3.2. Host requirements 544 3.2.1. Sending extension headers 546 The requirements are: 548 * A host MUST NOT send more than 8 non-padding options in 549 Destination Options in a packet unless it has explicit knowledge 550 that the destination, or all intermediate destinations in the case 551 of Destination Options before the routing header, are able to 552 process a greater number of options. 554 * A host MUST NOT send more than 8 non-padding options in Hop-by-Hop 555 Options in a packet unless it has explicit knowledge that the 556 final destination host is able to process a greater number of 557 options. 559 * A host SHOULD NOT send more than 8 non-padding options in Hop-by- 560 Hop Options in a packet unless it has explicit knowledge that all 561 possible intermediate nodes are able to process a greater number 562 of options or will ignore options that exceeds their limit. 564 * A host MUST NOT send a packet with an extension header larger than 565 64 bytes unless it has explicit knowledge that all nodes that 566 might process the extension header are capable of processing a 567 larger header. 569 * A host MUST NOT send a packet with a Destination option or Hop-by- 570 Hop option with Data Length greater than 60 bytes unless it has 571 explicit knowledge that all nodes that might process the option 572 are capable of processing ones with a larger Data Length. 574 * A host node MUST NOT send a packet with an IPv6 header chain 575 larger than 104 bytes unless it has explicit knowledge that all 576 nodes in the path are capable of properly handling packets with 577 larger header chains. This requirements is equivalently stated as 578 a host MUST NOT send a packet with more than 64 bytes of aggregate 579 extension headers. 581 * A host MUST NOT set more than one consecutive pad option, either 582 PAD1 or PADN, in Destination options or Hop-by-Hop options. 584 * A host MUST NOT send a PadN option in Hop-by-Hop Options or 585 Destination Options with total length of more than seven bytes. 587 * A host node MUST NOT send more than 16 options (padding or non- 588 padding) Destination options in a packet unless it has explicit 589 knowledge that the destination, or all intermediate destinations 590 in the case of Destination Options before the routing header, are 591 able to process a greater number of options. Note that if the 592 above requirements on a host sending non-padding Destination 593 options and requirements on option padding are met, then this 594 requirement is implicitly satisfied. 596 * A host node MUST NOT send more than 16 options (padding or non- 597 padding) in Hop-by-Hop Options in a packet unless it has explicit 598 knowledge that the final destination host is able to process a 599 greater number of options. Note that if the above requirements on 600 a host sending non-padding Hop-by-Hop options and requirements on 601 padding are met, then this requirement is implicitly satisfied. 603 3.2.2. Receiving extension headers 605 Per [RFC8200], a host node that receives a packet with extension 606 headers must process all the extension headers in the packet before 607 accepting the payload and processing the payload. 609 As described in [RFC8504] a host may establish limits on the 610 processing of extension headers. This specification reiterates and 611 updates those requirements to allow for a host to send an RFC8883 612 error if a limit has been exceeded. 614 * A host MAY set a limit on the maximum number of non-padding 615 options allowed in the Destination Options or Hop-by-Hop Options 616 extension headers. If this limit is supported then the maximum 617 number SHOULD be configurable, the limit MUST be greater than or 618 equal to 8, and the default value SHOULD be set to 8. The limits 619 for Destination options and Hop-by-Hop options MAY be separately 620 configurable. If a packet is received and the number of 621 Destination or Hop-by-Hop options exceeds the limit, then the 622 packet SHOULD be discarded and and an ICMP Parameter Problem with 623 code 9 MAY be sent to the packet's source address. 625 * A host MAY set a limit on the maximum number of options (padding 626 or non-padding) allowed in Destination Options or Hop-by-Hop 627 Options extension headers. If this limit is supported then the 628 maximum number SHOULD be configurable and the limit MUST be 629 greater than or equal to 16. The limits for Destination options 630 and Hop-by-Hop options MAY be separately configurable. If a 631 packet is received and the number of destination or Hop-by-Hop 632 options exceeds the limit, then the packet SHOULD be discarded and 633 and an ICMP Parameter Problem with code 9 MAY be sent to the 634 packet's source address 636 * A host node MAY set a limit on the length of an extension header. 637 If this limit is supported then the limit SHOULD be configurable 638 and the limit MUST be greater than or equal to 64 bytes. The 639 length limits for different extension headers MAY be separately 640 configurable. 642 * A host node MAY set a limit on the Data Length of a Hop-by-Hop or 643 Destination option. If this limit is supported then the limit 644 SHOULD be configurable, and the limit MUST be greater than or 645 equal to 60 bytes. The limits for Destination options and Hop-by- 646 Hop options MAY be separately configurable. If a packet is 647 received and a Hop-by-Hop or destination option has a length that 648 exceeds the limit, then the packet SHOULD be discarded and an ICMP 649 Parameter Problem with code 10 MAY be sent to the packet's source 650 address. 652 * A host MAY limit the number of consecutive PAD1 options in 653 destination options or Hop-by-Hop options to 7. In this case, if 654 there are more than 7 consecutive PAD1 options present, the packet 655 SHOULD be discarded and an ICMP Parameter Problem with code 10 MAY 656 be sent to the packet's source address 658 * A host MAY limit the number of bytes in a PADN option to be less 659 than 8. In such a case, if a PADN option is present that has a 660 length greater than 7, the packet SHOULD be discarded and an ICMP 661 Parameter Problem with code 10 MAY be sent to the packet's source 662 address. 664 * A host MAY set a limit on the maximum length of Destination 665 Options or Hop-by-Hop Options extension headers. This value 666 SHOULD be configurable, and if the limit is used then the limit 667 MUST be greater than or equal to 64 bytes. If a packet is 668 received and the length of the Destination or Hop-by-Hop Options 669 extension header exceeds the length limit, then the packet SHOULD 670 be discarded and an ICMP Parameter Problem with code 6 MAY be sent 671 to the packet's source address. 673 * A host node MAY set a limit on the maximum length of the IPv6 674 header chain, or equivalently a host MAY set a limit on the 675 aggregate length of extension headers in a packet. If the limit 676 is used then it MUST be greater than or equal to 104 bytes, or, 677 equivalently, the limit on aggregate header extension length MUST 678 be greater than or equal to 64 bytes. If a packet is received and 679 the aggregate length of the IPv6 header chain exceeds the limit 680 then the packet SHOULD be discarded and an ICMP Parameter Problem 681 with code 7 MAY be sent to the packet's source address. 683 Additional host requirements for receive. 685 * A host MAY disallow consecutive padding options, either PAD1 or 686 PADN, to be present in a packet. If consecutive padding options 687 are received and disallowed by the host, the then packet SHOULD be 688 discarded and an ICMP Parameter Problem with code 9 MAY be sent to 689 the packet's source address. 691 3.3. Intermediate node and intermediate destination requirements 693 The following requirements are established for intermediate nodes and 694 intermediate destination nodes that receive and process packets with 695 extension header. 697 * An intermediate node MUST be able to correctly forward packets 698 that contain an IPv6 header chain of 104 or fewer bytes, or 699 equivalently an intermediate node MUST be able to process a packet 700 with an aggregate length of extension headers less than or equal 701 to 64 bytes. 703 * Per [RFC8200] an intermediate node MAY be configured to not 704 process Hop-by-Hop Options. If a node is configured as such and a 705 packet with Hop-by-Hop options is received, the extension header 706 MUST be be skipped and the packet MUST otherwise be properly 707 processed and forwarded. 709 * An intermediate node MAY limit the number of non-padding Hop-by- 710 Hop options that it processes. If a limit is exceeded, that is a 711 packet contains more non-padding options than are configured to 712 process, the intermediate SHOULD stop processing the Hop-by-Hop 713 Option and ignore any options in the chain beyond the limit. It 714 is NOT RECOMMENDED that an intermediate node discards the packet 715 because the limit is exceeded, however if it does so then the 716 intermediate node MAY send an ICMP Parameter Problem with code 10 717 MAY be sent to the packet's source address. 719 * An intermediate node MAY limit the number of Hop-by-Hop options 720 (padding or non-padding) that it processes. If a limit is 721 exceeded, that is a packet contains more non-padding options than 722 are configured to process, the intermediate SHOULD stop processing 723 the Hop-by-Hop options and ignore any options in the chain beyond 724 the limit. It is NOT RECOMMENDED that the intermediate node 725 discards the packet because the limit is exceeded, however if it 726 does so then the intermediate node MAY send an ICMP Parameter 727 Problem with code 10 to the packet's source address. 729 * If an intermediate node encounters an unknown Hop-by-Hop option 730 and the two high order bits are not 00 then the node SHOULD 731 immediately stop processing the option chain and ignore any 732 options in the chain beyond the unknown option. An intermediate 733 node MAY either elect to discard the packet and MAY send an ICMP 734 Parameter Problem per the requirements of [RFC8200]; or the 735 intermediate node MAY forward the packet. 737 * An intermediate node MAY set a limit on the maximum length of Hop- 738 by-Hop Options extension headers. This value SHOULD be 739 configurable. If this limit is exceeded, that is a packet has an 740 extension header larger then the limit, then the intermediate node 741 SHOULD stop processing the Hop-by-Hop Option and ignore any 742 options in the chain beyond the limit. It is NOT RECOMMENDED that 743 the intermediate node discards the packet because the limit is 744 exceeded, however if it does so then the intermediate node MAY 745 send an ICMP Parameter Problem with code 10 MAY be sent to the 746 packet's source address. 748 3.4. Intermediate destination requirements 750 The following are requirements specific to intermediate destinations 751 pertaining to the processing of Destination Options before the 752 Routing header. For processing Hop-by-Hop options at an intermediate 753 destination the requirement for processing them at an intermediate 754 node are assumed. 756 * An intermediate destination MAY set a limit on the maximum length 757 of Destination Options extension header before the Routing header. 758 This value SHOULD be configurable, and the default is to accept 759 options of any length. If a limit is defined is MUST be at least 760 64 bytes. If the limit is exceeded then the intermediate 761 destination SHOULD discard the packet and MAY send an ICMP 762 Parameter Problem with code 6 to the packet's source address. 764 * An intermediate destination node MAY limit the number of non- 765 padding options in Destination Options before the Routing header. 766 If a limit is exceeded, that is a packet contains more non-padding 767 options than are configured to process, the intermediate 768 destination node SHOULD discard the packet and MAY send an ICMP 769 Parameter Problem with code 10 to the packet's source address. 771 * An intermediate destination node MAY limit the number of options 772 (padding or non-padding) in Destination Options before the Routing 773 header. If a limit is exceeded, that is a packet contains more 774 non-padding options than are configured to process, the 775 intermediate destination node SHOULD discard the packet and MAY 776 send an ICMP Parameter Problem with code 10 to the packet's source 777 address. 779 * An intermediate destination MAY limit the total number bytes in 780 consecutive PAD1 options in Destination Options before the Routing 781 Header 7. If the limit is exceeded, that is there are more than 782 seven bytes in consecutive PAD1 or PADN options present, the 783 intermediate destination node SHOULD discard the packet and MAY 784 send an ICMP Parameter Problem with code 10 to the packet's source 785 address. 787 * A intermediate destination MAY limit the number of bytes in a PADN 788 option in Destination Options before the Routing header to be less 789 than 8. In such a case, if a PADN option is present that has a 790 length greater than 7, the packet SHOULD be discarded and the 791 intermediate destination node SHOULD discard the packet and MAY 792 send an ICMP Parameter Problem with code 10 to the packet's source 793 address. 795 * A intermediate destination MAY set a limit on the maximum number 796 of non-padding options allowed in Destination options before the 797 Routing header. If this feature is supported, the maximum number 798 SHOULD be configurable, and the default value SHOULD be set to 8. 799 If a packet is received and the number of Destination options 800 before the Routing header exceeds the limit, the intermediate 801 destination node SHOULD discard the packet and MAY send an ICMP 802 Parameter Problem with code 10 to the packet's source address. 804 * A intermediate MAY set a limit on the maximum length of 805 Destination Options extension header before the Routing header. 806 This value SHOULD be configurable, and the default is to accept 807 options of any length. If a packet is received and the length of 808 the Destination or Hop-by- Hop Options extension header exceeds 809 the length limit, the intermediate destination node SHOULD discard 810 the packet and MAY send an ICMP Parameter Problem with code 10 to 811 the packet's source address. 813 4. References 815 4.1. Normative References 817 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 818 Requirement Levels", BCP 14, RFC 2119, 819 DOI 10.17487/RFC2119, March 1997, 820 . 822 [RFC8200] Deering, S. and R. Hinden, "Internet Protocol, Version 6 823 (IPv6) Specification", STD 86, RFC 8200, 824 DOI 10.17487/RFC8200, July 2017, 825 . 827 [RFC8504] Chown, T., Loughney, J., and T. Winters, "IPv6 Node 828 Requirements", BCP 220, RFC 8504, DOI 10.17487/RFC8504, 829 January 2019, . 831 [RFC8883] Herbert, T., "ICMPv6 Errors for Discarding Packets Due to 832 Processing Limits", RFC 8883, DOI 10.17487/RFC8883, 833 September 2020, . 835 4.2. Informative References 837 [RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6 838 (IPv6) Specification", RFC 2460, DOI 10.17487/RFC2460, 839 December 1998, . 841 [RFC7872] Gont, F., Linkova, J., Chown, T., and W. Liu, 842 "Observations on the Dropping of Packets with IPv6 843 Extension Headers in the Real World", RFC 7872, 844 DOI 10.17487/RFC7872, June 2016, 845 . 847 [RFC9098] Gont, F., Hilliard, N., Doering, G., Kumari, W., Huston, 848 G., and W. Liu, "Operational Implications of IPv6 Packets 849 with Extension Headers", RFC 9098, DOI 10.17487/RFC9098, 850 September 2021, . 852 Author's Address 854 Tom Herbert 855 SiPanda 856 Santa Clara, CA, 857 United States of America 859 Email: tom@herbertland.com