idnits 2.17.1 draft-ietf-opsec-ipv6-eh-filtering-10.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: ---------------------------------------------------------------------------- == There is 1 instance of lines with non-ascii characters in the document. 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 (3 May 2022) is 717 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Outdated reference: A later version (-12) exists of draft-irtf-pearg-numeric-ids-generation-08 == Outdated reference: A later version (-03) exists of draft-vyncke-v6ops-james-01 -- Obsolete informational reference (is this intentional?): RFC 2460 (Obsoleted by RFC 8200) Summary: 0 errors (**), 0 flaws (~~), 4 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 opsec F. Gont 3 Internet-Draft EdgeUno 4 Intended status: Informational W. Liu 5 Expires: 4 November 2022 Huawei Technologies 6 3 May 2022 8 Recommendations on the Filtering of IPv6 Packets Containing IPv6 9 Extension Headers at Transit Routers 10 draft-ietf-opsec-ipv6-eh-filtering-10 12 Abstract 14 This document analyzes the security implications of IPv6 Extension 15 Headers and associated IPv6 options. Additionally, it discusses the 16 operational and interoperability implications of discarding packets 17 based on the IPv6 Extension Headers and IPv6 options they contain. 18 Finally, it provides advice on the filtering of such IPv6 packets at 19 transit routers for traffic not directed to them, for those cases 20 where such filtering is deemed as necessary. 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 https://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 4 November 2022. 39 Copyright Notice 41 Copyright (c) 2022 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 (https://trustee.ietf.org/ 46 license-info) in effect on the date of publication of this document. 47 Please review these documents carefully, as they describe your rights 48 and restrictions with respect to this document. Code Components 49 extracted from this document must include Revised BSD License text as 50 described in Section 4.e of the Trust Legal Provisions and are 51 provided without warranty as described in the Revised BSD License. 53 Table of Contents 55 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 56 2. Terminology and Assumptions Employed in This Document . . . . 4 57 2.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 4 58 2.2. Applicability Statement . . . . . . . . . . . . . . . . . 4 59 2.3. Router Default Behavior and Features . . . . . . . . . . 4 60 3. IPv6 Extension Headers . . . . . . . . . . . . . . . . . . . 5 61 3.1. General Discussion . . . . . . . . . . . . . . . . . . . 5 62 3.2. General Security Implications . . . . . . . . . . . . . . 6 63 3.3. Rationale for Our Advice on the Handling of IPv6 Packets 64 with Specific IPv6 Extension Headers . . . . . . . . . . 6 65 3.4. Summary of Advice on the Handling of IPv6 Packets with 66 Specific IPv6 Extension Headers . . . . . . . . . . . . . 6 67 3.5. Advice on the Handling of IPv6 Packets with Specific IPv6 68 Extension Headers . . . . . . . . . . . . . . . . . . . . 7 69 3.6. Advice on the Handling of Packets with Unknown IPv6 70 Extension Headers . . . . . . . . . . . . . . . . . . . . 16 71 4. IPv6 Options . . . . . . . . . . . . . . . . . . . . . . . . 17 72 4.1. General Discussion . . . . . . . . . . . . . . . . . . . 17 73 4.2. General Security Implications of IPv6 Options . . . . . . 17 74 4.3. Summary of Advice on the Handling of IPv6 Packets with 75 Specific IPv6 Extension Headers . . . . . . . . . . . . . 18 76 4.4. Advice on the Handling of Packets with Specific IPv6 77 Options . . . . . . . . . . . . . . . . . . . . . . . . . 19 78 4.5. Advice on the handling of Packets with Unknown IPv6 79 Options . . . . . . . . . . . . . . . . . . . . . . . . . 32 80 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 32 81 6. Privacy Considerations . . . . . . . . . . . . . . . . . . . 32 82 7. Security Considerations . . . . . . . . . . . . . . . . . . . 32 83 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 33 84 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 33 85 9.1. Normative References . . . . . . . . . . . . . . . . . . 33 86 9.2. Informative References . . . . . . . . . . . . . . . . . 37 87 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 39 89 1. Introduction 91 IPv6 Extension Headers (EHs) allow for the extension of the IPv6 92 protocol, and provide support for core functionality such as IPv6 93 fragmentation. However, common implementation limitations suggest 94 that EHs present a challenge for IPv6 packet routing equipment, 95 particularly when the IPv6 header chain needs to be processed for 96 e.g. enforcing ACLs or implementing other functions [RFC9098]. 98 Several studies (e.g. [Huston-2022], [I-D.vyncke-v6ops-james], and 99 [RFC7872]) suggest that there is widespread dropping of IPv6 packets 100 that contain IPv6 Extension Headers (EHs). In some cases, such 101 packet drops occur at transit routers. While some operators are 102 known to intentionally drop packets that contain IPv6 EHs, it is 103 possible that some of the measured packet drops are the result of 104 inappropriate advice in this area. 106 This document analyzes both the general security implications of IPv6 107 EHs, as well as the security implications of specific EH and Option 108 types. It also provides advice on the filtering of IPv6 packets 109 based on the IPv6 EHs and the IPv6 options they contain. Since 110 various protocols may use IPv6 EHs (possibly with IPv6 options), 111 discarding packets based on the IPv6 EHs or IPv6 options they contain 112 can have implications on the proper functioning of such protocols. 113 Thus, this document also attempts to discuss the operational and 114 interoperability implications of such filtering policies. 116 The resulting packet filtering policy typically depends on where in 117 the network such policy is enforced: when the policy is enforced in a 118 transit network, the policy typically follows a "deny-list" approach, 119 where only packets with clear negative implications are dropped. On 120 the other hand, when the policy is enforced closer to the destination 121 systems, the policy typically follows an "accept-list" approach, 122 where only traffic that is expected to be received is allowed. The 123 advice in this document is aimed only at transit routers that may 124 need to enforce a filtering policy based on the EHs and IPv6 options 125 a packet may contain, following a "deny-list" approach, and hence is 126 likely to be much more permissive than a filtering policy to be 127 employed at e.g. the edge of an enterprise network. The advice in 128 this document is meant to improve the current situation of the 129 dropping of packets with IPv6 EHs in the Internet [RFC7872] in such 130 cases where packets are being dropped due to inappropriate or missing 131 guidelines. 133 This document is similar in nature to [RFC7126], which addresses the 134 same problem for the IPv4 case. However, in IPv6, the problem space 135 is compounded by the fact that IPv6 specifies a number of IPv6 EHs, 136 and a number of IPv6 options which may be valid only when included in 137 specific EH types. 139 This document completes and complements the considerations for 140 protecting the control plane from packets containing IP options that 141 can be found in [RFC6192]. 143 Section 2 specifies the terminology and conventions employed 144 throughout this document. Section 3 discusses IPv6 EHs and provides 145 advice in the area of filtering IPv6 packets that contain such IPv6 146 EHs. Section 4 discusses IPv6 options and provides advice in the 147 area of filtering IPv6 packets that contain such options. 149 2. Terminology and Assumptions Employed in This Document 151 2.1. Terminology 153 The terms "permit" (allow the traffic), "drop" (drop with no 154 notification to sender), and "reject" (drop with appropriate 155 notification to sender) are employed as defined in [RFC3871]. 156 Throughout this document we also employ the term "discard" as a 157 generic term to indicate the act of discarding a packet, irrespective 158 of whether the sender is notified of such drops, and irrespective of 159 whether the specific filtering action is logged. 161 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 162 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 163 "OPTIONAL" in this document are to be interpreted as described in BCP 164 14 [RFC2119] [RFC8174] when, and only when, they appear in all 165 capitals, as shown here. 167 2.2. Applicability Statement 169 This document provides advice on the filtering of IPv6 packets with 170 EHs at transit routers for traffic not explicitly destined to them, 171 for cases in which such filtering is deemed as necessary. 173 2.3. Router Default Behavior and Features 175 This document assumes that nodes comply with the requirements in 176 [RFC7045]. Namely, 178 "If a forwarding node discards a packet containing a standard IPv6 179 extension header, it MUST be the result of a configurable policy 180 and not just the result of a failure to recognise such a header. 181 This means that the discard policy for each standard type of 182 extension header MUST be individually configurable. The default 183 configuration SHOULD allow all standard extension headers." 185 The advice provided in this document is only meant to guide an 186 operator in configuring forwarding devices, and is not to be 187 interpreted as advice regarding default configuration settings for 188 network devices. That is, this document provides advice with respect 189 to operational policies, but does not change the implementation 190 defaults required by [RFC7045]. 192 We recommend that configuration options are made available to govern 193 the processing of each IPv6 EH type and each IPv6 option type. Such 194 configuration options should include the following possible settings: 196 * Permit this IPv6 EH or IPv6 Option type. 198 * Drop packets containing this IPv6 EH or option type. 200 * Reject packets containing this IPv6 EH or option type (where the 201 packet drop is signaled with an ICMPv6 error message). 203 * Rate-limit traffic containing this IPv6 EH or option type. 205 * Ignore this IPv6 EH or option type (as if it was not present) and 206 process the packet according the rules for the remaining headers. 207 We note that if a packet carries forwarding information (e.g., in 208 an IPv6 Routing Header) this might be an inappropriate or 209 undesirable action. 211 We note that special care needs to be taken when devices log packet 212 drops/rejects. Devices should count the number of packets dropped/ 213 rejected, but the logging of drop/reject events should be limited so 214 as to not overburden device resources. 216 Finally, we note that when discarding packets, it is generally 217 desirable that the sender be signaled of the packet drop, since this 218 is of use for trouble-shooting purposes. However, throughout this 219 document (when recommending that packets be discarded) we generically 220 refer to the action as "discard" without specifying whether the 221 sender is signaled of the packet drop. 223 3. IPv6 Extension Headers 225 3.1. General Discussion 227 IPv6 [RFC8200] EHs allow for the extension of the IPv6 protocol. 228 Since both IPv6 EHs and upper-layer protocols share the same 229 namespace ("Next Header" registry/namespace), [RFC7045] identifies 230 which of the currently assigned Internet Protocol numbers identify 231 IPv6 EHs vs. upper-layer protocols. This document discusses the 232 filtering of packets based on the IPv6 EHs (as specified by 233 [RFC7045]) they contain. 235 NOTE: [RFC8200] specifies that non-fragmented IPv6 datagrams and 236 IPv6 First-Fragments must contain the entire IPv6 header chain 237 [RFC7112]. Therefore, intermediate systems can enforce the 238 filtering policies discussed in this document, or resort to simply 239 discarding the offending packets when they fail to comply with the 240 requirements in [RFC8200]. We note that, in order to implement 241 filtering rules on the fast path, it may be necessary for the 242 filtering device to limit the depth into the packet that can be 243 inspected before giving up. In circumstances where such a 244 limitation exists, it is recommended that implementations provide 245 a configuration option that specifies whether to discard packets 246 if the aforementioned limit is encountered. Operators may then 247 determine according to their own circumstances how such packets 248 will be handled. 250 3.2. General Security Implications 252 In some device architectures, IPv6 packets that contain IPv6 EHs can 253 cause the corresponding packets to be processed on the slow path, and 254 hence may be leveraged for the purpose of Denial of Service (DoS) 255 attacks [RFC9098] [Cisco-EH] [FW-Benchmark]. 257 Operators are urged to consider the IPv6 EH and IPv6 options handling 258 capabilities of their devices as they make deployment decisions in 259 the future. 261 3.3. Rationale for Our Advice on the Handling of IPv6 Packets with 262 Specific IPv6 Extension Headers 264 * IPv6 Packets with IPv6 Extension Headers (or options) that are not 265 expected to traverse transit routers should be dropped. 267 * IPv6 Packets with IPv6 Extension Headers (or options) that are 268 only expected to traverse transit routers when a specific 269 technology is employed, should be permitted (or dropped) based on 270 the knowledge regarding the use of such technology in transit 271 provider in question (i.e. permit the packets if the technology is 272 employed, or drop them) 274 * IPv6 Packets with IPv6 Extension Headers (or options) that 275 represent a concrete attack vector to network infrastructure 276 devices should be dropped. 278 * IPv6 packets with any other IPv6 Extension headers (or options) 279 should be permitted. This is an intentional trade-off made to 280 minimize ossification. 282 3.4. Summary of Advice on the Handling of IPv6 Packets with Specific 283 IPv6 Extension Headers 285 This section summarizes the advice provided in Section 3.5, providing 286 references to the specific sections in which a detailed analysis can 287 be found. 289 +=========================+==========================+===========+ 290 | EH type | Filtering policy | Reference | 291 +=========================+==========================+===========+ 292 | IPv6 Hop-by-Hop Options | Drop or Ignore | Section | 293 | (Proto=0) | | 3.5.1 | 294 +-------------------------+--------------------------+-----------+ 295 | Routing Header for IPv6 | Drop only RHT0 and RHT1. | Section | 296 | (Proto=43) | Permit other RH Types | 3.5.2 | 297 +-------------------------+--------------------------+-----------+ 298 | Fragment Header for | Permit | Section | 299 | IPv6 (Proto=44) | | 3.5.3 | 300 +-------------------------+--------------------------+-----------+ 301 | Encapsulating Security | Permit | Section | 302 | Payload (Proto=50) | | 3.5.4 | 303 +-------------------------+--------------------------+-----------+ 304 | Authentication Header | Permit | Section | 305 | (Proto=51) | | 3.5.5 | 306 +-------------------------+--------------------------+-----------+ 307 | Destination Options for | Permit | Section | 308 | IPv6 (Proto=60) | | 3.5.6 | 309 +-------------------------+--------------------------+-----------+ 310 | Mobility Header | Permit | Section | 311 | (Proto=135) | | 3.5.7 | 312 +-------------------------+--------------------------+-----------+ 313 | Host Identity Protocol | Permit | Section | 314 | (Proto=139) | | 3.5.8 | 315 +-------------------------+--------------------------+-----------+ 316 | Shim6 Protocol | Permit | Section | 317 | (Proto=140) | | 3.5.9 | 318 +-------------------------+--------------------------+-----------+ 319 | Use for experimentation | Drop | Section | 320 | and testing (Proto=253 | | 3.5.10 | 321 | and 254) | | | 322 +-------------------------+--------------------------+-----------+ 324 Table 1: Summary of Advice on the Handling of IPv6 Packets 325 with Specific IPv6 Extension Headers 327 3.5. Advice on the Handling of IPv6 Packets with Specific IPv6 328 Extension Headers 330 3.5.1. IPv6 Hop-by-Hop Options (Protocol Number=0) 331 3.5.1.1. Uses 333 The Hop-by-Hop Options header is used to carry optional information 334 that may be examined by every node along a packet's delivery path. 335 It is expected that nodes will examine the Hop-by-Hop Options header 336 if explicitly configured to do so. 338 NOTE: A previous revision of the IPv6 core specification, [RFC2460], 339 originally required that all nodes examined and processed the Hop-by- 340 Hop Options header. However, even before the publication of 341 [RFC8200] a number of implementations already provided the option of 342 ignoring this header unless explicitly configured to examine it. 344 3.5.1.2. Specification 346 This EH is specified in [RFC8200]. As of May 2022, the following 347 options have been specified for the Hop-by-Hop Options EH: 349 * Type 0x00: Pad1 [RFC8200] 351 * Type 0x01: PadN [RFC8200] 353 * Type 0x05: Router Alert [RFC2711] 355 * Type 0x07: CALIPSO [RFC5570] 357 * Type 0x08: SMF_DPD [RFC6621] 359 * Type 0x23: RPL Option [RFC9008] 361 * Type 0x26: Quick-Start [RFC4782] 363 * Type 0x4D: (Deprecated) 365 * Type 0x63: RPL Option [RFC6553] 367 * Type 0x6D: MPL Option [RFC7731] 369 * Type 0x8A: Endpoint Identification (Deprecated) 370 [draft-ietf-nimrod-eid] 372 * Type 0xC2: Jumbo Payload [RFC2675] 374 * Type 0xEE: IPv6 DFF Header [RFC6971] 376 * Type 0x1E: RFC3692-style Experiment [RFC4727] 378 * Type 0x3E: RFC3692-style Experiment [RFC4727] 379 * Type 0x5E: RFC3692-style Experiment [RFC4727] 381 * Type 0x7E: RFC3692-style Experiment [RFC4727] 383 * Type 0x9E: RFC3692-style Experiment [RFC4727] 385 * Type 0xBE: RFC3692-style Experiment [RFC4727] 387 * Type 0xDE: RFC3692-style Experiment [RFC4727] 389 * Type 0xFE: RFC3692-style Experiment [RFC4727] 391 3.5.1.3. Specific Security Implications 393 Legacy nodes that process this extension header might be subject to 394 Denial of Service attacks. 396 NOTE: While [RFC8200] has removed this requirement, the deployed base 397 may still reflect the classical behavior for a while, and hence the 398 potential security problems of this EH are still of concern. 400 3.5.1.4. Operational and Interoperability Impact if Blocked 402 Discarding packets containing a Hop-by-Hop Options EH would break any 403 of the protocols that rely on it for proper functioning. For 404 example, it would break RSVP [RFC2205] and multicast deployments, and 405 would cause IPv6 jumbograms to be discarded. 407 3.5.1.5. Advice 409 Nodes implementing [RFC8200] would already ignore this extension 410 header unless explicitly required to process it. For legacy 411 ([RFC2460]) nodes, the recommended configuration for the processing 412 of these packets depends on the features and capabilities of the 413 underlying platform, the configuration of the platform, and also the 414 deployment environment of the platform. On platforms that allow 415 forwarding of packets with HBH Options on the fast path, we recommend 416 that packets with a HBH Options EH be forwarded as normal. 417 Otherwise, on platforms in which processing of packets with a IPv6 418 HBH Options EH is carried out in the slow path, and an option is 419 provided to rate-limit these packets, we recommend that this option 420 be selected. Finally, when packets containing a HBH Options EH are 421 processed in the slow-path, and the underlying platform does not have 422 any mitigation options available for attacks based on these packets, 423 we recommend that such platforms discard packets containing IPv6 HBH 424 Options EHs. 426 Finally, we note that RPL (Routing Protocol for Low-Power and Lossy 427 Networks) routers [RFC6550] must not discard packets based on the 428 presence of an IPv6 Hop-by-Hop Options EH, as this would break RPL. 430 3.5.2. Routing Header for IPv6 (Protocol Number=43) 432 3.5.2.1. Uses 434 The Routing header is used by an IPv6 source to list one or more 435 intermediate nodes to be "visited" on the way to a packet's 436 destination. 438 3.5.2.2. Specification 440 This EH is specified in [RFC8200]. [RFC2460] had originally 441 specified the Routing Header Type 0, which was later obsoleted by 442 [RFC5095], and thus removed from [RFC8200]. 444 At of May 2022, the following Routing Types have been specified: 446 * Type 0: Source Route (DEPRECATED) [RFC2460] [RFC5095] 448 * Type 1: Nimrod (DEPRECATED) 450 * Type 2: Type 2 Routing Header [RFC6275] 452 * Type 3: RPL Source Route Header [RFC6554] 454 * Type 4: Segment Routing Header (SRH) [RFC8754] 456 * Types 5-252: Unassigned 458 * Type 253: RFC3692-style Experiment 1 [RFC4727] 460 * Type 254: RFC3692-style Experiment 2 [RFC4727] 462 * Type 255: Reserved 464 3.5.2.3. Specific Security Implications 466 The security implications of RHT0 have been discussed in detail in 467 [Biondi2007] and [RFC5095]. RHT1 was never widely implemented. The 468 security implications of RHT2, RHT3, and RHT4 (SRH) are discussed in 469 [RFC6275], [RFC6554], and [RFC8754], respectively. 471 3.5.2.4. Operational and Interoperability Impact if Blocked 473 Blocking packets containing a RHT0 or RHT1 has no operational 474 implications, since both have been deprecated. Blocking packets with 475 a RHT2 would break Mobile IPv6. Packets with a RHT3 may be safely 476 blocked at RPL domain boundaries, since RHT3 headers are employed 477 within a single RPL domain. Blocking packets with a RHT4 (SRH) will 478 break Segment Routing (SR) deployments, if the filtering policy is 479 enforced on packets being forwarded within an SR domain. 481 3.5.2.5. Advice 483 Intermediate systems should discard packets containing a RHT0, RHT1, 484 or RHT3. Other routing header types should be permitted, as required 485 by [RFC7045]. 487 3.5.3. Fragment Header for IPv6 (Protocol Number=44) 489 3.5.3.1. Uses 491 This EH provides the fragmentation functionality for IPv6. 493 3.5.3.2. Specification 495 This EH is specified in [RFC8200]. 497 3.5.3.3. Specific Security Implications 499 The security implications of the Fragment Header range from Denial of 500 Service attacks (e.g. based on flooding a target with IPv6 fragments) 501 to information leakage attacks [RFC7739]. 503 3.5.3.4. Operational and Interoperability Impact if Blocked 505 Blocking packets that contain a Fragment Header will break any 506 protocol that may rely on fragmentation (e.g., the DNS [RFC1034]). 507 However, IP fragmentation is known to introduce fragility to Internet 508 communication [RFC8900]. 510 3.5.3.5. Advice 512 Intermediate systems should permit packets that contain a Fragment 513 Header. 515 3.5.4. Encapsulating Security Payload (Protocol Number=50) 516 3.5.4.1. Uses 518 This EH is employed for the IPsec suite [RFC4303]. 520 3.5.4.2. Specification 522 This EH is specified in [RFC4303]. 524 3.5.4.3. Specific Security Implications 526 Besides the general implications of IPv6 EHs, this EH could be 527 employed to potentially perform a DoS attack at the destination 528 system by wasting CPU resources in validating the contents of the 529 packet. 531 3.5.4.4. Operational and Interoperability Impact if Blocked 533 Discarding packets that employ this EH would break IPsec deployments. 535 3.5.4.5. Advice 537 Intermediate systems should permit packets containing the 538 Encapsulating Security Payload EH. 540 3.5.5. Authentication Header (Protocol Number=51) 542 3.5.5.1. Uses 544 The Authentication Header can be employed for provide authentication 545 services in IPv4 and IPv6. 547 3.5.5.2. Specification 549 This EH is specified in [RFC4302]. 551 3.5.5.3. Specific Security Implications 553 Besides the general implications of IPv6 EHs, this EH could be 554 employed to potentially perform a DoS attack at the destination 555 system by wasting CPU resources in validating the contents of the 556 packet. 558 3.5.5.4. Operational and Interoperability Impact if Blocked 560 Discarding packets that employ this EH would break IPsec deployments. 562 3.5.5.5. Advice 564 Intermediate systems should permit packets containing an 565 Authentication Header. 567 3.5.6. Destination Options for IPv6 (Protocol Number=60) 569 3.5.6.1. Uses 571 The Destination Options header is used to carry optional information 572 that needs be examined only by a packet's destination node(s). 574 3.5.6.2. Specification 576 This EH is specified in [RFC8200]. As of May 2022, the following 577 options have been specified for this EH: 579 * Type 0x00: Pad1 [RFC8200] 581 * Type 0x01: PadN [RFC8200] 583 * Type 0x04: Tunnel Encapsulation Limit [RFC2473] 585 * Type 0x0F: IPv6 Performance and Diagnostic Metrics (PDM) [RFC8250] 587 * Type 0x4D: (Deprecated) 589 * Type 0xC9: Home Address [RFC6275] 591 * Type 0x8A: Endpoint Identification (Deprecated) 592 [draft-ietf-nimrod-eid] 594 * Type 0x8B: ILNP Nonce [RFC6744] 596 * Type 0x8C: Line-Identification Option [RFC6788] 598 * Type 0x1E: RFC3692-style Experiment [RFC4727] 600 * Type 0x3E: RFC3692-style Experiment [RFC4727] 602 * Type 0x5E: RFC3692-style Experiment [RFC4727] 604 * Type 0x7E: RFC3692-style Experiment [RFC4727] 606 * Type 0x9E: RFC3692-style Experiment [RFC4727] 608 * Type 0xBE: RFC3692-style Experiment [RFC4727] 609 * Type 0xDE: RFC3692-style Experiment [RFC4727] 611 * Type 0xFE: RFC3692-style Experiment [RFC4727] 613 3.5.6.3. Specific Security Implications 615 No security implications are known, other than the general 616 implications of IPv6 EHs. For a discussion of possible security 617 implications of specific options specified for the DO header, please 618 see the Section 4.4. 620 3.5.6.4. Operational and Interoperability Impact if Blocked 622 Discarding packets that contain a Destination Options header would 623 break protocols that rely on this EH type for conveying information, 624 including protocols such as ILNP [RFC6740] and Mobile IPv6 [RFC6275], 625 and IPv6 tunnels that employ the Tunnel Encapsulation Limit option. 627 3.5.6.5. Advice 629 Intermediate systems should permit packets that contain a Destination 630 Options Header. 632 3.5.7. Mobility Header (Protocol Number=135) 634 3.5.7.1. Uses 636 The Mobility Header is an EH used by mobile nodes, correspondent 637 nodes, and home agents in all messaging related to the creation and 638 management of bindings in Mobile IPv6. 640 3.5.7.2. Specification 642 This EH is specified in [RFC6275]. 644 3.5.7.3. Specific Security Implications 646 A thorough security assessment of the security implications of the 647 Mobility Header and related mechanisms can be found in Section 15 of 648 [RFC6275]. 650 3.5.7.4. Operational and Interoperability Impact if Blocked 652 Discarding packets containing this EH would break Mobile IPv6. 654 3.5.7.5. Advice 656 Intermediate systems should permit packets containing this EH. 658 3.5.8. Host Identity Protocol (Protocol Number=139) 660 3.5.8.1. Uses 662 This EH is employed with the Host Identity Protocol (HIP), a protocol 663 that allows consenting hosts to securely establish and maintain 664 shared IP-layer state, allowing separation of the identifier and 665 locator roles of IP addresses, thereby enabling continuity of 666 communications across IP address changes. 668 3.5.8.2. Specification 670 This EH is specified in [RFC7401]. 672 3.5.8.3. Specific Security Implications 674 The security implications of the HIP header are discussed in detail 675 in Section 8 of [RFC6275]. 677 3.5.8.4. Operational and Interoperability Impact if Blocked 679 Discarding packets that contain the Host Identity Protocol would 680 break HIP deployments. 682 3.5.8.5. Advice 684 Intermediate systems should permit packets that contain a Host 685 Identity Protocol EH. 687 3.5.9. Shim6 Protocol (Protocol Number=140) 689 3.5.9.1. Uses 691 This EH is employed by the Shim6 [RFC5533] Protocol. 693 3.5.9.2. Specification 695 This EH is specified in [RFC5533]. 697 3.5.9.3. Specific Security Implications 699 The specific security implications are discussed in detail in 700 Section 16 of [RFC5533]. 702 3.5.9.4. Operational and Interoperability Impact if Blocked 704 Discarding packets that contain this EH will break Shim6. 706 3.5.9.5. Advice 708 Intermediate systems should permit packets containing this EH. 710 3.5.10. Use for experimentation and testing (Protocol Numbers=253 and 711 254) 713 3.5.10.1. Uses 715 These IPv6 EHs are employed for performing RFC3692-Style experiments 716 (see [RFC3692] for details). 718 3.5.10.2. Specification 720 These EHs are specified in [RFC3692] and [RFC4727]. 722 3.5.10.3. Specific Security Implications 724 The security implications of these EHs will depend on their specific 725 use. 727 3.5.10.4. Operational and Interoperability Impact if Blocked 729 For obvious reasons, discarding packets that contain these EHs limits 730 the ability to perform legitimate experiments across IPv6 routers. 732 3.5.10.5. Advice 734 Operators should determine according to their own circumstances 735 whether to discard packets containing these EHs. 737 3.6. Advice on the Handling of Packets with Unknown IPv6 Extension 738 Headers 740 We refer to IPv6 EHs that have not been assigned an Internet Protocol 741 Number by IANA (and marked as such) in [IANA-PROTOCOLS] as "unknown 742 IPv6 extension headers" ("unknown IPv6 EHs"). 744 3.6.1. Uses 746 New IPv6 EHs may be specified as part of future extensions to the 747 IPv6 protocol. 749 Since IPv6 EHs and Upper-layer protocols employ the same namespace, 750 it is impossible to tell whether an unknown "Internet Protocol 751 Number" is being employed for an IPv6 EH or an Upper-Layer protocol. 753 3.6.2. Specification 755 The processing of unknown IPv6 EHs is specified in [RFC7045]. 757 3.6.3. Specific Security Implications 759 For obvious reasons, it is impossible to determine specific security 760 implications of unknown IPv6 EHs. 762 3.6.4. Operational and Interoperability Impact if Blocked 764 As noted in [RFC7045], discarding unknown IPv6 EHs may slow down the 765 deployment of new IPv6 EHs and transport protocols. The 766 corresponding IANA registry ([IANA-PROTOCOLS]) should be monitored 767 such that filtering rules are updated as new IPv6 EHs are 768 standardized. 770 We note that since IPv6 EHs and upper-layer protocols share the same 771 numbering space, discarding unknown IPv6 EHs may result in packets 772 encapsulating unknown upper-layer protocols being discarded. 774 3.6.5. Advice 776 Operators should determine according to their own circumstances 777 whether to discard packets containing unknown IPv6 EHs. 779 4. IPv6 Options 781 4.1. General Discussion 783 The following subsections describe specific security implications of 784 different IPv6 options, and provide advice regarding filtering 785 packets that contain such options. 787 4.2. General Security Implications of IPv6 Options 789 The general security implications of IPv6 options are closely related 790 to those discussed in Section 3.2 for IPv6 EHs. Essentially, packets 791 that contain IPv6 options might need to be processed by an IPv6 792 router's general-purpose CPU,and hence could present a DDoS risk to 793 that router's general-purpose CPU (and thus to the router itself). 794 For some architectures, a possible mitigation would be to rate-limit 795 the packets that are to be processed by the general-purpose CPU (see 796 e.g. [Cisco-EH]). 798 4.3. Summary of Advice on the Handling of IPv6 Packets with Specific 799 IPv6 Extension Headers 801 This section summarizes the advice provided in Section 3.5, providing 802 references to the specific sections in which a detailed analysis can 803 be found. 805 +===============================+======================+===========+ 806 | Option | Filtering policy | Reference | 807 +===============================+======================+===========+ 808 | Pad1 (Type=0x00) | Permit | Section | 809 | | | 4.4.1 | 810 +-------------------------------+----------------------+-----------+ 811 | PadN (Type=0x01) | Permit | Section | 812 | | | 4.4.2 | 813 +-------------------------------+----------------------+-----------+ 814 | Tunnel Encapsulation Limit | Permit | Section | 815 | (Type=0x04) | | 4.4.3 | 816 +-------------------------------+----------------------+-----------+ 817 | Router Alert (Type=0x05) | Permit based on | Section | 818 | | needed functionality | 4.4.4 | 819 +-------------------------------+----------------------+-----------+ 820 | CALIPSO (Type=0x07) | Permit based on | Section | 821 | | needed functionality | 4.4.5 | 822 +-------------------------------+----------------------+-----------+ 823 | SMF_DPD (Type=0x08) | Permit based on | Section | 824 | | needed functionality | 4.4.6 | 825 +-------------------------------+----------------------+-----------+ 826 | PDM Option (Type=0x0F) | Permit | Section | 827 | | | 4.4.7 | 828 +-------------------------------+----------------------+-----------+ 829 | RPL Option (Type=0x23) | Permit | Section | 830 | | | 4.4.8 | 831 +-------------------------------+----------------------+-----------+ 832 | Quick-Start (Type=0x26) | Permit | Section | 833 | | | 4.4.9 | 834 +-------------------------------+----------------------+-----------+ 835 | Deprecated (Type=0x4D) | Drop | Section | 836 | | | 4.4.10 | 837 +-------------------------------+----------------------+-----------+ 838 | MPL Option (Type=0x6D) | Permit | Section | 839 | | | 4.4.12 | 840 +-------------------------------+----------------------+-----------+ 841 | Jumbo Payload (Type=0C2) | Permit based on | Section | 842 | | needed functionality | 4.4.16 | 843 +-------------------------------+----------------------+-----------+ 844 | RPL Option (Type=0x63) | Drop in non-RPL | Section | 845 | | routers | 4.4.11 | 846 +-------------------------------+----------------------+-----------+ 847 | Endpoint Identification | Drop | Section | 848 | (Type=0x8A) | | 4.4.13 | 849 +-------------------------------+----------------------+-----------+ 850 | ILNP Nonce (Type=0x8B) | Permit | Section | 851 | | | 4.4.14 | 852 +-------------------------------+----------------------+-----------+ 853 | Line-Identification Option | Drop | Section | 854 | (Type=0x8C) | | 4.4.15 | 855 +-------------------------------+----------------------+-----------+ 856 | Home Address (Type=0xC9) | Permit | Section | 857 | | | 4.4.17 | 858 +-------------------------------+----------------------+-----------+ 859 | IP_DFF (Type=0xEE) | Permit based on | Section | 860 | | needed functionality | 4.4.18 | 861 +-------------------------------+----------------------+-----------+ 862 | RFC3692-style Experiment | Permit based on | Section | 863 | (Types = 0x1E, 0x3E, 0x5E, | needed functionality | 4.4.19 | 864 | 0x7E, 0x9E, 0xBE, 0xDE, 0xFE) | | | 865 +-------------------------------+----------------------+-----------+ 867 Table 2: Summary of Advice on the Handling of IPv6 Packets with 868 Specific IPv6 options 870 4.4. Advice on the Handling of Packets with Specific IPv6 Options 872 The following subsections contain a description of each of the IPv6 873 options that have so far been specified, a summary of the security 874 implications of each of such options, a discussion of possible 875 interoperability implications if packets containing such options are 876 discarded, and specific advice regarding whether packets containing 877 these options should be permitted. 879 4.4.1. Pad1 (Type=0x00) 881 4.4.1.1. Uses 883 This option is used when necessary to align subsequent options and to 884 pad out the containing header to a multiple of 8 octets in length. 886 4.4.1.2. Specification 888 This option is specified in [RFC8200]. 890 4.4.1.3. Specific Security Implications 892 None. 894 4.4.1.4. Operational and Interoperability Impact if Blocked 896 Discarding packets that contain this option would potentially break 897 any protocol that relies on IPv6 options. 899 4.4.1.5. Advice 901 Intermediate systems should not discard packets based on the presence 902 of this option. 904 4.4.2. PadN (Type=0x01) 906 4.4.2.1. Uses 908 This option is used when necessary to align subsequent options and to 909 pad out the containing header to a multiple of 8 octets in length. 911 4.4.2.2. Specification 913 This option is specified in [RFC8200]. 915 4.4.2.3. Specific Security Implications 917 Because of the possible size of this option, it could be leveraged as 918 a large-bandwidth covert channel. 920 4.4.2.4. Operational and Interoperability Impact if Blocked 922 Discarding packets that contain this option would potentially break 923 any protocol that relies on IPv6 options. 925 4.4.2.5. Advice 927 Intermediate systems should not discard IPv6 packets based on the 928 presence of this option. 930 4.4.3. Tunnel Encapsulation Limit (Type=0x04) 932 4.4.3.1. Uses 934 The Tunnel Encapsulation Limit option can be employed to specify how 935 many further levels of nesting the packet is permitted to undergo. 937 4.4.3.2. Specification 939 This option is specified in [RFC2473]. 941 4.4.3.3. Specific Security Implications 943 Those described in [RFC2473]. 945 4.4.3.4. Operational and Interoperability Impact if Blocked 947 Discarding packets based on the presence of this option could result 948 in tunnel traffic being discarded. 950 4.4.3.5. Advice 952 Intermediate systems should not discard packets based on the presence 953 of this option. 955 4.4.4. Router Alert (Type=0x05) 957 4.4.4.1. Uses 959 The Router Alert option [RFC2711] is employed by a number of 960 protocols, including the Resource reSerVation Protocol (RSVP) 961 [RFC2205], Multicast Listener Discovery (MLD) [RFC2710] [RFC3810], 962 Multicast Router Discovery (MRD) [RFC4286], and General Internet 963 Signaling Transport (GIST) [RFC5971]. Its usage is discussed in 964 detail in [RFC6398]. 966 4.4.4.2. Specification 968 This option is specified in [RFC2711]. 970 4.4.4.3. Specific Security Implications 972 Since this option causes the contents of the packet to be inspected 973 by the handling device, this option could be leveraged for performing 974 DoS attacks. The security implications of the Router Alert option 975 are discussed in detail in [RFC6398]. 977 4.4.4.4. Operational and Interoperability Impact if Blocked 979 Discarding packets that contain this option would break any protocols 980 that rely on them, such as RSVP and multicast deployments. Please 981 see Section 4.4.4.3 for further details. 983 4.4.4.5. Advice 985 Packets containing this option should be permitted in environments 986 where support for RSVP, multicast routing, or similar protocols is 987 desired. 989 4.4.5. CALIPSO (Type=0x07) 991 4.4.5.1. Uses 993 This option is used for encoding explicit packet Sensitivity Labels 994 on IPv6 packets. It is intended for use only within Multi-Level 995 Secure (MLS) networking environments that are both trusted and 996 trustworthy. 998 4.4.5.2. Specification 1000 This option is specified in [RFC5570]. 1002 4.4.5.3. Specific Security Implications 1004 Presence of this option in a packet does not by itself create any 1005 specific new threat. Packets with this option ought not normally be 1006 seen on the global public Internet. 1008 4.4.5.4. Operational and Interoperability Impact if Blocked 1010 If packets with this option are discarded or if the option is 1011 stripped from the packet during transmission from source to 1012 destination, then the packet itself is likely to be discarded by the 1013 receiver because it is not properly labeled. In some cases, the 1014 receiver might receive the packet but associate an incorrect 1015 sensitivity label with the received data from the packet whose 1016 CALIPSO was stripped by a middle-box (such as a packet-scrubber). 1017 Associating an incorrect sensitivity label can cause the received 1018 information either to be handled as more sensitive than it really is 1019 ("upgrading") or as less sensitive than it really is ("downgrading"), 1020 either of which is problematic. As noted in [RFC5570], IPsec 1021 [RFC4301] [RFC4302] [RFC4303] can be employed to protect the CALIPSO 1022 option. 1024 4.4.5.5. Advice 1026 Recommendations for handling the CALIPSO option depend on the 1027 deployment environment, rather than whether an intermediate system 1028 happens to be deployed as a transit device (e.g., IPv6 transit 1029 router). 1031 Explicit configuration is the only method via which an intermediate 1032 system can know whether that particular intermediate system has been 1033 deployed within a Multi-Level Secure (MLS) environment. In many 1034 cases, ordinary commercial intermediate systems (e.g., IPv6 routers 1035 and firewalls) are the majority of the deployed intermediate systems 1036 inside an MLS network environment. 1038 For Intermediate systems that DO NOT implement [RFC5570], there 1039 should be a configuration option to EITHER (a) drop packets 1040 containing the CALIPSO option OR (b) to ignore the presence of the 1041 CALIPSO option and forward the packets normally. In non-MLS 1042 environments, such intermediate systems should have this 1043 configuration option set to (a) above. In MLS environments, such 1044 intermediate systems should have this option set to (b) above. The 1045 default setting for this configuration option should be set to (a) 1046 above, because MLS environments are much less common than non-MLS 1047 environments. 1049 For Intermediate systems that DO implement [RFC5570], there should be 1050 configuration options (a) and (b) from the preceding paragraph and 1051 also a third configuration option (c) to process packets containing a 1052 CALIPSO option as per [RFC5570]. When deployed in non-MLS 1053 environments, such intermediate systems should have this 1054 configuration option set to (a) above. When deployed in MLS 1055 environments, such intermediate systems should have this set to (c). 1056 The default setting for this configuration option MAY be set to (a) 1057 above, because MLS environments are much less common than non-MLS 1058 environments. 1060 4.4.6. SMF_DPD (Type=0x08) 1062 4.4.6.1. Uses 1064 This option is employed in the (experimental) Simplified Multicast 1065 Forwarding (SMF) for unique packet identification for IPv6 I-DPD, and 1066 as a mechanism to guarantee non-collision of hash values for 1067 different packets when H-DPD is used. 1069 4.4.6.2. Specification 1071 This option is specified in [RFC6621]. 1073 4.4.6.3. Specific Security Implications 1075 None. The use of transient numeric identifiers is subject to the 1076 security and privacy considerations discussed in 1077 [I-D.irtf-pearg-numeric-ids-generation]. 1079 4.4.6.4. Operational and Interoperability Impact if Blocked 1081 Dropping packets containing this option within a MANET domain would 1082 break SMF. However, dropping such packets at the border of such 1083 domain would have no negative impact. 1085 4.4.6.5. Advice 1087 Intermediate systems that are not within a MANET domain should 1088 discard packets that contain this option. 1090 4.4.7. PDM (Type=0x0F) 1092 4.4.7.1. Uses 1094 This option is employed to convey sequence numbers and timing 1095 information in IPv6 packets as a basis for measurements. 1097 4.4.7.2. Specification 1099 This option is specified in [RFC8250]. 1101 4.4.7.3. Specific Security Implications 1103 Those specified in [RFC8250]. Additionally, since the options 1104 employs transient numeric identifiers, implementations may be subject 1105 to the issues discussed in [I-D.irtf-pearg-numeric-ids-generation]. 1107 4.4.7.4. Operational and Interoperability Impact if Blocked 1109 Dropping packets containing this option will result in negative 1110 interoperaiblity implications for traffic employing this option as a 1111 basis for measurements. 1113 4.4.7.5. Advice 1115 Intermediate systems should not discard packets based on the presence 1116 of this option. 1118 4.4.8. RPL Option (Type=0x23) 1120 4.4.8.1. Uses 1122 The RPL Option provides a mechanism to include routing information 1123 with each datagram that an RPL router forwards. 1125 4.4.8.2. Specification 1127 This option is specified in [RFC9008]. 1129 4.4.8.3. Specific Security Implications 1131 Those described in [RFC9008]. 1133 4.4.8.4. Operational and Interoperability Impact if Blocked 1135 This option can survive outside of an RPL instance. As a result, 1136 discarding packets based on the presence of this option would break 1137 some use cases for RPL (see [RFC9008]). 1139 4.4.8.5. Advice 1141 Intermediate systems should not discard IPv6 packets based on the 1142 presence of this option. 1144 4.4.9. Quick-Start (Type=0x26) 1146 4.4.9.1. Uses 1148 This IP Option is used in the specification of Quick-Start for TCP 1149 and IP, which is an experimental mechanism that allows transport 1150 protocols, in cooperation with routers, to determine an allowed 1151 sending rate at the start and, at times, in the middle of a data 1152 transfer (e.g., after an idle period) [RFC4782]. 1154 4.4.9.2. Specification 1156 This option is specified in [RFC4782], on the "Experimental" track. 1158 4.4.9.3. Specific Security Implications 1160 Section 9.6 of [RFC4782] notes that Quick-Start is vulnerable to two 1161 kinds of attacks: 1163 * attacks to increase the routers' processing and state load, and, 1165 * attacks with bogus Quick-Start Requests to temporarily tie up 1166 available Quick-Start bandwidth, preventing routers from approving 1167 Quick-Start Requests from other connections. 1169 We note that if routers in a given environment do not implement and 1170 enable the Quick-Start mechanism, only the general security 1171 implications of IP options (discussed in Section 4.2) would apply. 1173 4.4.9.4. Operational and Interoperability Impact if Blocked 1175 The Quick-Start functionality would be disabled, and additional 1176 delays in TCP's connection establishment (for example) could be 1177 introduced. (Please see Section 4.7.2 of [RFC4782].) We note, 1178 however, that Quick-Start has been proposed as a mechanism that could 1179 be of use in controlled environments, and not as a mechanism that 1180 would be intended or appropriate for ubiquitous deployment in the 1181 global Internet [RFC4782]. 1183 4.4.9.5. Advice 1185 Intermediate systems should not discard IPv6 packets based on the 1186 presence of this option. 1188 4.4.10. Deprecated (Type=0x4D) 1190 4.4.10.1. Uses 1192 No information has been found about this option type. 1194 4.4.10.2. Specification 1196 No information has been found about this option type. 1198 4.4.10.3. Specific Security Implications 1200 No information has been found about this option type, and hence it 1201 has been impossible to perform the corresponding security assessment. 1203 4.4.10.4. Operational and Interoperability Impact if Blocked 1205 Unknown. 1207 4.4.10.5. Advice 1209 Intermediate systems should discard packets that contain this option. 1211 4.4.11. RPL Option (Type=0x63) 1213 4.4.11.1. Uses 1215 The RPL Option provides a mechanism to include routing information 1216 with each datagram that an RPL router forwards. 1218 4.4.11.2. Specification 1220 This option was originally specified in [RFC6553]. It has been 1221 deprecated by [RFC9008]. 1223 4.4.11.3. Specific Security Implications 1225 Those described in [RFC9008]. 1227 4.4.11.4. Operational and Interoperability Impact if Blocked 1229 This option is meant to be employed within an RPL instance. As a 1230 result, discarding packets based on the presence of this option 1231 outside of an RPL instance will not result in interoperability 1232 implications. 1234 4.4.11.5. Advice 1236 Non-RPL routers should discard packets that contain an RPL option. 1238 4.4.12. MPL Option (Type=0x6D) 1240 4.4.12.1. Uses 1242 This option is used with the Multicast Protocol for Low power and 1243 Lossy Networks (MPL), that provides IPv6 multicast forwarding in 1244 constrained networks. 1246 4.4.12.2. Specification 1248 This option is specified in [RFC7731], and is meant to be included 1249 only in Hop-by-Hop Option headers. 1251 4.4.12.3. Specific Security Implications 1253 Those described in [RFC7731]. 1255 4.4.12.4. Operational and Interoperability Impact if Blocked 1257 Dropping packets that contain an MPL option within an MPL network 1258 would break the Multicast Protocol for Low power and Lossy Networks 1259 (MPL). However, dropping such packets at the border of such networks 1260 will have no negative impact. 1262 4.4.12.5. Advice 1264 Intermediate systems should not discard packets based on the presence 1265 of this option. However, since this option has been specified for 1266 the Hop-by-Hop Options, such systems should consider the discussion 1267 in Section 3.5.1. 1269 4.4.13. Endpoint Identification (Type=0x8A) 1270 4.4.13.1. Uses 1272 The Endpoint Identification option was meant to be used with the 1273 Nimrod routing architecture [NIMROD-DOC], but has never seen 1274 widespread deployment. 1276 4.4.13.2. Specification 1278 This option is specified in [NIMROD-DOC]. 1280 4.4.13.3. Specific Security Implications 1282 Undetermined. 1284 4.4.13.4. Operational and Interoperability Impact if Blocked 1286 None. 1288 4.4.13.5. Advice 1290 Intermediate systems should discard packets that contain this option. 1292 4.4.14. ILNP Nonce (Type=0x8B) 1294 4.4.14.1. Uses 1296 This option is employed by Identifier-Locator Network Protocol for 1297 IPv6 (ILNPv6) for providing protection against off-path attacks for 1298 packets when ILNPv6 is in use, and as a signal during initial 1299 network-layer session creation that ILNPv6 is proposed for use with 1300 this network-layer session, rather than classic IPv6. 1302 4.4.14.2. Specification 1304 This option is specified in [RFC6744]. 1306 4.4.14.3. Specific Security Implications 1308 Those described in [RFC6744]. 1310 4.4.14.4. Operational and Interoperability Impact if Blocked 1312 Discarding packets that contain this option will break INLPv6 1313 deployments. 1315 4.4.14.5. Advice 1317 Intermediate systems should not discard packets based on the presence 1318 of this option. 1320 4.4.15. Line-Identification Option (Type=0x8C) 1322 4.4.15.1. Uses 1324 This option is used by an Edge Router to identify the subscriber 1325 premises in scenarios where several subscriber premises may be 1326 logically connected to the same interface of an Edge Router. 1328 4.4.15.2. Specification 1330 This option is specified in [RFC6788]. 1332 4.4.15.3. Specific Security Implications 1334 Those described in [RFC6788]. 1336 4.4.15.4. Operational and Interoperability Impact if Blocked 1338 Since this option is meant to be employed in Router Solicitation 1339 messages, discarding packets based on the presence of this option at 1340 intermediate systems will result in no interoperability implications. 1342 4.4.15.5. Advice 1344 Intermediate devices should discard packets that contain this option. 1346 4.4.16. Jumbo Payload (Type=0XC2) 1348 4.4.16.1. Uses 1350 The Jumbo payload option provides the means of specifying payloads 1351 larger than 65535 bytes. 1353 4.4.16.2. Specification 1355 This option is specified in [RFC2675]. 1357 4.4.16.3. Specific Security Implications 1359 There are no specific issues arising from this option, except for 1360 improper validity checks of the option and associated packet lengths. 1362 4.4.16.4. Operational and Interoperability Impact if Blocked 1364 Discarding packets based on the presence of this option will cause 1365 IPv6 jumbograms to be discarded. 1367 4.4.16.5. Advice 1369 An operator should permit this option only in specific scenarios in 1370 which support for IPv6 jumbograms is desired. 1372 4.4.17. Home Address (Type=0xC9) 1374 4.4.17.1. Uses 1376 The Home Address option is used by a Mobile IPv6 node while away from 1377 home, to inform the recipient of the mobile node's home address. 1379 4.4.17.2. Specification 1381 This option is specified in [RFC6275]. 1383 4.4.17.3. Specific Security Implications 1385 No (known) additional security implications than those described in 1386 [RFC6275]. 1388 4.4.17.4. Operational and Interoperability Impact if Blocked 1390 Discarding IPv6 packets based on the presence of this option will 1391 break Mobile IPv6. 1393 4.4.17.5. Advice 1395 Intermediate systems should not discard IPv6 packets based on the 1396 presence of this option. 1398 4.4.18. IP_DFF (Type=0xEE) 1400 4.4.18.1. Uses 1402 This option is employed with the (Experimental) Depth-First 1403 Forwarding (DFF) in Unreliable Networks. 1405 4.4.18.2. Specification 1407 This option is specified in [RFC6971]. 1409 4.4.18.3. Specific Security Implications 1411 Those specified in [RFC6971]. 1413 4.4.18.4. Operational and Interoperability Impact if Blocked 1415 Dropping packets containing this option within a routing domain that 1416 is running DFF would break DFF. However, dropping such packets at 1417 the border of such domains will have no security implications. 1419 4.4.18.5. Advice 1421 Intermediate systems that do not operate within a routing domain that 1422 is running DFF should discard packets containing this option. 1424 4.4.19. RFC3692-style Experiment (Types = 0x1E, 0x3E, 0x5E, 0x7E, 0x9E, 1425 0xBE, 0xDE, 0xFE) 1427 4.4.19.1. Uses 1429 These options can be employed for performing RFC3692-style 1430 experiments. It is only appropriate to use these values in 1431 explicitly configured experiments; they must not be shipped as 1432 defaults in implementations. 1434 4.4.19.2. Specification 1436 Specified in RFC 4727 [RFC4727] in the context of RFC3692-style 1437 experiments. 1439 4.4.19.3. Specific Security Implications 1441 The specific security implications will depend on the specific use of 1442 these options. 1444 4.4.19.4. Operational and Interoperability Impact if Blocked 1446 For obvious reasons, discarding packets that contain these options 1447 limits the ability to perform legitimate experiments across IPv6 1448 routers. 1450 4.4.19.5. Advice 1452 Operators should determine according to their own circumstances 1453 whether to discard packets containing these IPv6 options. 1455 4.5. Advice on the handling of Packets with Unknown IPv6 Options 1457 We refer to IPv6 options that have not been assigned an IPv6 option 1458 type in the corresponding registry ([IANA-IPV6-PARAM]) as "unknown 1459 IPv6 options". 1461 4.5.1. Uses 1463 New IPv6 options may be specified as part of future protocol work. 1465 4.5.2. Specification 1467 The processing of unknown IPv6 options is specified in [RFC8200]. 1469 4.5.3. Specific Security Implications 1471 For obvious reasons, it is impossible to determine specific security 1472 implications of unknown IPv6 options. 1474 4.5.4. Operational and Interoperability Impact if Blocked 1476 Discarding unknown IPv6 options may slow down the deployment of new 1477 IPv6 options. As noted in [draft-gont-6man-ipv6-opt-transmit], the 1478 corresponding IANA registry ([IANA-IPV6-PARAM] should be monitored 1479 such that IPv6 option filtering rules are updated as new IPv6 options 1480 are standardized. 1482 4.5.5. Advice 1484 Operators should determine according to their own circumstances 1485 whether to discard packets containing unknown IPv6 options. 1487 5. IANA Considerations 1489 This document has no actions for IANA. 1491 6. Privacy Considerations 1493 There are no privacy considerations associated with this document. 1495 7. Security Considerations 1497 This document provides advice on the filtering of IPv6 packets that 1498 contain IPv6 EHs (and possibly IPv6 options) at IPv6 transit routers. 1499 It is meant to improve the current situation of widespread dropping 1500 of such IPv6 packets in those cases where the drops result from 1501 improper configuration defaults, or inappropriate advice in this 1502 area. 1504 As discussed in Section Section 3.3 of this document, one of the 1505 underlying principles for the advice provided in this document is 1506 that IPv6 packets with specific EHs or options which may represent an 1507 attack vector for infrastructure devices should be dropped. While 1508 this policy helps mitigate some specific attack vectors, the 1509 recommendations in this document will not help to mitigate 1510 vulnerabilities based on implementation errors [RFC9098]. 1512 We also note that depending on the router architecture, attempts to 1513 filter packets ased on the presence of IPv6 EHs or options might 1514 itself represent an attack vector to network infrastructure devices 1515 [RFC9098]. 1517 8. Acknowledgements 1519 The authors would like to thank Ron Bonica for his work on earlier 1520 versions of this document. 1522 The authors of this document would like to thank (in alphabetical 1523 order) Mikael Abrahamsson, Brian Carpenter, Tim Chown, Roman Danyliw, 1524 Darren Dukes, Lars Eggert, David Farmer, Mike Heard, Bob Hinden, 1525 Christian Huitema, Benjamin Kaduk, Erik Kline, Murray Kucherawy, Jen 1526 Linkova, Carlos Pignataro, Alvaro Retana, Maria Ines Robles, 1527 Zaheduzzaman Sarker, Donald Smith, Pascal Thubert, Ole Troan, Gunter 1528 Van De Velde, Eric Vyncke, and Robert Wilton, for providing valuable 1529 comments on earlier versions of this document. 1531 This document borrows some text and analysis from [RFC7126], authored 1532 by Fernando Gont, Randall Atkinson, and Carlos Pignataro. 1534 The authors would like to thank Warren Kumari and Eric Vyncke for 1535 their guidance during the publication process of this document. 1537 Fernando would also like to thank Brian Carpenter and Ran Atkinson 1538 who, over the years, have answered many questions and provided 1539 valuable comments that have benefited his protocol-related work 1540 (including the present document). 1542 9. References 1544 9.1. Normative References 1546 [RFC1034] Mockapetris, P., "Domain names - concepts and facilities", 1547 STD 13, RFC 1034, DOI 10.17487/RFC1034, November 1987, 1548 . 1550 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1551 Requirement Levels", BCP 14, RFC 2119, 1552 DOI 10.17487/RFC2119, March 1997, 1553 . 1555 [RFC2205] Braden, R., Ed., Zhang, L., Berson, S., Herzog, S., and S. 1556 Jamin, "Resource ReSerVation Protocol (RSVP) -- Version 1 1557 Functional Specification", RFC 2205, DOI 10.17487/RFC2205, 1558 September 1997, . 1560 [RFC2473] Conta, A. and S. Deering, "Generic Packet Tunneling in 1561 IPv6 Specification", RFC 2473, DOI 10.17487/RFC2473, 1562 December 1998, . 1564 [RFC2675] Borman, D., Deering, S., and R. Hinden, "IPv6 Jumbograms", 1565 RFC 2675, DOI 10.17487/RFC2675, August 1999, 1566 . 1568 [RFC2710] Deering, S., Fenner, W., and B. Haberman, "Multicast 1569 Listener Discovery (MLD) for IPv6", RFC 2710, 1570 DOI 10.17487/RFC2710, October 1999, 1571 . 1573 [RFC2711] Partridge, C. and A. Jackson, "IPv6 Router Alert Option", 1574 RFC 2711, DOI 10.17487/RFC2711, October 1999, 1575 . 1577 [RFC3692] Narten, T., "Assigning Experimental and Testing Numbers 1578 Considered Useful", BCP 82, RFC 3692, 1579 DOI 10.17487/RFC3692, January 2004, 1580 . 1582 [RFC3810] Vida, R., Ed. and L. Costa, Ed., "Multicast Listener 1583 Discovery Version 2 (MLDv2) for IPv6", RFC 3810, 1584 DOI 10.17487/RFC3810, June 2004, 1585 . 1587 [RFC4286] Haberman, B. and J. Martin, "Multicast Router Discovery", 1588 RFC 4286, DOI 10.17487/RFC4286, December 2005, 1589 . 1591 [RFC4301] Kent, S. and K. Seo, "Security Architecture for the 1592 Internet Protocol", RFC 4301, DOI 10.17487/RFC4301, 1593 December 2005, . 1595 [RFC4302] Kent, S., "IP Authentication Header", RFC 4302, 1596 DOI 10.17487/RFC4302, December 2005, 1597 . 1599 [RFC4303] Kent, S., "IP Encapsulating Security Payload (ESP)", 1600 RFC 4303, DOI 10.17487/RFC4303, December 2005, 1601 . 1603 [RFC4727] Fenner, B., "Experimental Values In IPv4, IPv6, ICMPv4, 1604 ICMPv6, UDP, and TCP Headers", RFC 4727, 1605 DOI 10.17487/RFC4727, November 2006, 1606 . 1608 [RFC4782] Floyd, S., Allman, M., Jain, A., and P. Sarolahti, "Quick- 1609 Start for TCP and IP", RFC 4782, DOI 10.17487/RFC4782, 1610 January 2007, . 1612 [RFC5095] Abley, J., Savola, P., and G. Neville-Neil, "Deprecation 1613 of Type 0 Routing Headers in IPv6", RFC 5095, 1614 DOI 10.17487/RFC5095, December 2007, 1615 . 1617 [RFC5533] Nordmark, E. and M. Bagnulo, "Shim6: Level 3 Multihoming 1618 Shim Protocol for IPv6", RFC 5533, DOI 10.17487/RFC5533, 1619 June 2009, . 1621 [RFC5570] StJohns, M., Atkinson, R., and G. Thomas, "Common 1622 Architecture Label IPv6 Security Option (CALIPSO)", 1623 RFC 5570, DOI 10.17487/RFC5570, July 2009, 1624 . 1626 [RFC5971] Schulzrinne, H. and R. Hancock, "GIST: General Internet 1627 Signalling Transport", RFC 5971, DOI 10.17487/RFC5971, 1628 October 2010, . 1630 [RFC6275] Perkins, C., Ed., Johnson, D., and J. Arkko, "Mobility 1631 Support in IPv6", RFC 6275, DOI 10.17487/RFC6275, July 1632 2011, . 1634 [RFC6398] Le Faucheur, F., Ed., "IP Router Alert Considerations and 1635 Usage", BCP 168, RFC 6398, DOI 10.17487/RFC6398, October 1636 2011, . 1638 [RFC6550] Winter, T., Ed., Thubert, P., Ed., Brandt, A., Hui, J., 1639 Kelsey, R., Levis, P., Pister, K., Struik, R., Vasseur, 1640 JP., and R. Alexander, "RPL: IPv6 Routing Protocol for 1641 Low-Power and Lossy Networks", RFC 6550, 1642 DOI 10.17487/RFC6550, March 2012, 1643 . 1645 [RFC6553] Hui, J. and JP. Vasseur, "The Routing Protocol for Low- 1646 Power and Lossy Networks (RPL) Option for Carrying RPL 1647 Information in Data-Plane Datagrams", RFC 6553, 1648 DOI 10.17487/RFC6553, March 2012, 1649 . 1651 [RFC6554] Hui, J., Vasseur, JP., Culler, D., and V. Manral, "An IPv6 1652 Routing Header for Source Routes with the Routing Protocol 1653 for Low-Power and Lossy Networks (RPL)", RFC 6554, 1654 DOI 10.17487/RFC6554, March 2012, 1655 . 1657 [RFC6621] Macker, J., Ed., "Simplified Multicast Forwarding", 1658 RFC 6621, DOI 10.17487/RFC6621, May 2012, 1659 . 1661 [RFC6740] Atkinson, RJ. and SN. Bhatti, "Identifier-Locator Network 1662 Protocol (ILNP) Architectural Description", RFC 6740, 1663 DOI 10.17487/RFC6740, November 2012, 1664 . 1666 [RFC6744] Atkinson, RJ. and SN. Bhatti, "IPv6 Nonce Destination 1667 Option for the Identifier-Locator Network Protocol for 1668 IPv6 (ILNPv6)", RFC 6744, DOI 10.17487/RFC6744, November 1669 2012, . 1671 [RFC6788] Krishnan, S., Kavanagh, A., Varga, B., Ooghe, S., and E. 1672 Nordmark, "The Line-Identification Option", RFC 6788, 1673 DOI 10.17487/RFC6788, November 2012, 1674 . 1676 [RFC6971] Herberg, U., Ed., Cardenas, A., Iwao, T., Dow, M., and S. 1677 Cespedes, "Depth-First Forwarding (DFF) in Unreliable 1678 Networks", RFC 6971, DOI 10.17487/RFC6971, June 2013, 1679 . 1681 [RFC7045] Carpenter, B. and S. Jiang, "Transmission and Processing 1682 of IPv6 Extension Headers", RFC 7045, 1683 DOI 10.17487/RFC7045, December 2013, 1684 . 1686 [RFC7112] Gont, F., Manral, V., and R. Bonica, "Implications of 1687 Oversized IPv6 Header Chains", RFC 7112, 1688 DOI 10.17487/RFC7112, January 2014, 1689 . 1691 [RFC7401] Moskowitz, R., Ed., Heer, T., Jokela, P., and T. 1692 Henderson, "Host Identity Protocol Version 2 (HIPv2)", 1693 RFC 7401, DOI 10.17487/RFC7401, April 2015, 1694 . 1696 [RFC7731] Hui, J. and R. Kelsey, "Multicast Protocol for Low-Power 1697 and Lossy Networks (MPL)", RFC 7731, DOI 10.17487/RFC7731, 1698 February 2016, . 1700 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 1701 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 1702 May 2017, . 1704 [RFC8200] Deering, S. and R. Hinden, "Internet Protocol, Version 6 1705 (IPv6) Specification", STD 86, RFC 8200, 1706 DOI 10.17487/RFC8200, July 2017, 1707 . 1709 [RFC8250] Elkins, N., Hamilton, R., and M. Ackermann, "IPv6 1710 Performance and Diagnostic Metrics (PDM) Destination 1711 Option", RFC 8250, DOI 10.17487/RFC8250, September 2017, 1712 . 1714 [RFC8754] Filsfils, C., Ed., Dukes, D., Ed., Previdi, S., Leddy, J., 1715 Matsushima, S., and D. Voyer, "IPv6 Segment Routing Header 1716 (SRH)", RFC 8754, DOI 10.17487/RFC8754, March 2020, 1717 . 1719 [RFC8900] Bonica, R., Baker, F., Huston, G., Hinden, R., Troan, O., 1720 and F. Gont, "IP Fragmentation Considered Fragile", 1721 BCP 230, RFC 8900, DOI 10.17487/RFC8900, September 2020, 1722 . 1724 [RFC9008] Robles, M.I., Richardson, M., and P. Thubert, "Using RPI 1725 Option Type, Routing Header for Source Routes, and IPv6- 1726 in-IPv6 Encapsulation in the RPL Data Plane", RFC 9008, 1727 DOI 10.17487/RFC9008, April 2021, 1728 . 1730 9.2. Informative References 1732 [Biondi2007] 1733 Biondi, P. and A. Ebalard, "IPv6 Routing Header Security", 1734 CanSecWest 2007 Security Conference, 2007, 1735 . 1737 [Cisco-EH] Cisco Systems, "IPv6 Extension Headers Review and 1738 Considerations", Whitepaper. October 2006, 1739 . 1742 [draft-gont-6man-ipv6-opt-transmit] 1743 Gont, F., Liu, W., and R. Bonica, "Transmission and 1744 Processing of IPv6 Options", IETF Internet Draft, work in 1745 progress, August 2014. 1747 [draft-ietf-nimrod-eid] 1748 Lynn, C.L., "Endpoint Identifier Destination 1749 Option", IETF Internet Draft, draft-ietf-nimrod-eid- 1750 00.txt, November 1995. 1752 [FW-Benchmark] 1753 Zack, E., "Firewall Security Assessment and Benchmarking 1754 IPv6 Firewall Load Tests", IPv6 Hackers Meeting #1, 1755 Berlin, Germany. June 30, 2013, 1756 . 1760 [Huston-2022] 1761 Huston, G. and J. Damas, "IPv6 Fragmentation and EH 1762 Behaviours", IEPG Meeting - March 2022 @ IETF 113, March 1763 2022, 1764 . 1766 [I-D.irtf-pearg-numeric-ids-generation] 1767 Gont, F. and I. Arce, "On the Generation of Transient 1768 Numeric Identifiers", Work in Progress, Internet-Draft, 1769 draft-irtf-pearg-numeric-ids-generation-08, 31 January 1770 2022, . 1773 [I-D.vyncke-v6ops-james] 1774 Vyncke, É., Léas, R., and J. Iurman, "Just Another 1775 Measurement of Extension header Survivability (JAMES)", 1776 Work in Progress, Internet-Draft, draft-vyncke-v6ops- 1777 james-01, 19 March 2022, . 1780 [IANA-IPV6-PARAM] 1781 Internet Assigned Numbers Authority, "Internet Protocol 1782 Version 6 (IPv6) Parameters", December 2013, 1783 . 1786 [IANA-PROTOCOLS] 1787 Internet Assigned Numbers Authority, "Protocol Numbers", 1788 2014, . 1791 [NIMROD-DOC] 1792 Nimrod Documentation Page, 1793 "http://ana-3.lcs.mit.edu/~jnc/nimrod/". 1795 [RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6 1796 (IPv6) Specification", RFC 2460, DOI 10.17487/RFC2460, 1797 December 1998, . 1799 [RFC3871] Jones, G., Ed., "Operational Security Requirements for 1800 Large Internet Service Provider (ISP) IP Network 1801 Infrastructure", RFC 3871, DOI 10.17487/RFC3871, September 1802 2004, . 1804 [RFC6192] Dugal, D., Pignataro, C., and R. Dunn, "Protecting the 1805 Router Control Plane", RFC 6192, DOI 10.17487/RFC6192, 1806 March 2011, . 1808 [RFC7126] Gont, F., Atkinson, R., and C. Pignataro, "Recommendations 1809 on Filtering of IPv4 Packets Containing IPv4 Options", 1810 BCP 186, RFC 7126, DOI 10.17487/RFC7126, February 2014, 1811 . 1813 [RFC7739] Gont, F., "Security Implications of Predictable Fragment 1814 Identification Values", RFC 7739, DOI 10.17487/RFC7739, 1815 February 2016, . 1817 [RFC7872] Gont, F., Linkova, J., Chown, T., and W. Liu, 1818 "Observations on the Dropping of Packets with IPv6 1819 Extension Headers in the Real World", RFC 7872, 1820 DOI 10.17487/RFC7872, June 2016, 1821 . 1823 [RFC9098] Gont, F., Hilliard, N., Doering, G., Kumari, W., Huston, 1824 G., and W. Liu, "Operational Implications of IPv6 Packets 1825 with Extension Headers", RFC 9098, DOI 10.17487/RFC9098, 1826 September 2021, . 1828 Authors' Addresses 1829 Fernando Gont 1830 EdgeUno 1831 Segurola y Habana 4310, 7mo Piso 1832 Villa Devoto 1833 Ciudad Autonoma de Buenos Aires 1834 Argentina 1835 Email: fernando.gont@edgeuno.com 1836 URI: https://www.edgeuno.com 1838 Will (Shucheng) Liu 1839 Huawei Technologies 1840 Bantian, Longgang District 1841 Shenzhen 1842 518129 1843 P.R. China 1844 Email: liushucheng@huawei.com