idnits 2.17.1 draft-ietf-opsec-ipv6-eh-filtering-09.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (2 May 2022) is 715 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 -- Obsolete informational reference (is this intentional?): RFC 2460 (Obsoleted by RFC 8200) Summary: 0 errors (**), 0 flaws (~~), 2 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 opsec F. Gont 3 Internet-Draft SI6 Networks 4 Intended status: Informational W. Liu 5 Expires: 3 November 2022 Huawei Technologies 6 2 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-09 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 3 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 Conventions Used in This Document . . . . . . 4 57 2.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 4 58 2.2. Applicability Statement . . . . . . . . . . . . . . . . . 4 59 2.3. Conventions . . . . . . . . . . . . . . . . . . . . . . . 4 60 3. IPv6 Extension Headers . . . . . . . . . . . . . . . . . . . 5 61 3.1. General Discussion . . . . . . . . . . . . . . . . . . . 5 62 3.2. General Security Implications . . . . . . . . . . . . . . 6 63 3.3. Summary of Advice on the Handling of IPv6 Packets with 64 Specific IPv6 Extension Headers . . . . . . . . . . . . . 6 65 3.4. Advice on the Handling of IPv6 Packets with Specific IPv6 66 Extension Headers . . . . . . . . . . . . . . . . . . . . 7 67 3.5. Advice on the Handling of Packets with Unknown IPv6 68 Extension Headers . . . . . . . . . . . . . . . . . . . . 16 69 4. IPv6 Options . . . . . . . . . . . . . . . . . . . . . . . . 17 70 4.1. General Discussion . . . . . . . . . . . . . . . . . . . 17 71 4.2. General Security Implications of IPv6 Options . . . . . . 17 72 4.3. Advice on the Handling of Packets with Specific IPv6 73 Options . . . . . . . . . . . . . . . . . . . . . . . . . 18 74 4.4. Advice on the handling of Packets with Unknown IPv6 75 Options . . . . . . . . . . . . . . . . . . . . . . . . . 30 76 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 30 77 6. Privacy Considerations . . . . . . . . . . . . . . . . . . . 30 78 7. Security Considerations . . . . . . . . . . . . . . . . . . . 31 79 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 31 80 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 31 81 9.1. Normative References . . . . . . . . . . . . . . . . . . 31 82 9.2. Informative References . . . . . . . . . . . . . . . . . 35 83 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 37 85 1. Introduction 87 IPv6 Extension Headers (EHs) allow for the extension of the IPv6 88 protocol, and provide support for core functionality such as IPv6 89 fragmentation. However, common implementation limitations suggest 90 that EHs present a challenge for IPv6 packet routing equipment, 91 particularly when the IPv6 header chain needs to be processed for 92 e.g. enforcing ACLs or implementing other functions [RFC9098]. 94 Recent studies (see e.g. [RFC7872]) suggest that there is widespread 95 dropping of IPv6 packets that contain IPv6 Extension Headers (EHs). 96 In some cases, such packet drops occur at transit routers. While 97 some operators "officially" drop packets that contain IPv6 EHs, it is 98 possible that some of the measured packet drops are the result of 99 improper configuration defaults, or inappropriate advice in this 100 area. 102 This document analyzes both the general security implications of IPv6 103 EHs, as well as the security implications of specific EH and Option 104 types. It also provides advice on the filtering of IPv6 packets 105 based on the IPv6 EHs and the IPv6 options they contain. Since 106 various protocols may use IPv6 EHs (possibly with IPv6 options), 107 discarding packets based on the IPv6 EHs or IPv6 options they contain 108 can have implications on the proper functioning of such protocols. 109 Thus, this document also attempts to discuss the operational and 110 interoperability implications of such filtering policies. 112 The resulting packet filtering policy typically depends on where in 113 the network such policy is enforced: when the policy is enforced in a 114 transit network, the policy typically follows a "deny-list" approach, 115 where only packets with clear negative implications are dropped. On 116 the other hand, when the policy is enforced closer to the destination 117 systems, the policy typically follows an "accept-list" approach, 118 where only traffic that is expected to be received is allowed. The 119 advice in this document is aimed only at transit routers that may 120 need to enforce a filtering policy based on the EHs and IPv6 options 121 a packet may contain, following a "deny-list" approach, and hence is 122 likely to be much more permissive that a filtering policy to be 123 employed at e.g. the edge of an enterprise network. The advice in 124 this document is meant to improve the current situation of the 125 dropping of packets with IPv6 EHs in the Internet [RFC7872] in such 126 cases where packets are being dropped due to inappropriate or missing 127 guidelines. 129 This document is similar in nature to [RFC7126], which addresses the 130 same problem for the IPv4 case. However, in IPv6, the problem space 131 is compounded by the fact that IPv6 specifies a number of IPv6 EHs, 132 and a number of IPv6 options which may be valid only when included in 133 specific EH types. 135 This document completes and complements the considerations for 136 protecting the control plane from packets containing IP options that 137 can be found in [RFC6192]. 139 Section 2 of this document specifies the terminology and conventions 140 employed throughout this document. Section 3 of this document 141 discusses IPv6 EHs and provides advice in the area of filtering IPv6 142 packets that contain such IPv6 EHs. Section 4 of this document 143 discusses IPv6 options and provides advice in the area of filtering 144 IPv6 packets that contain such options. 146 2. Terminology and Conventions Used in This Document 148 2.1. Terminology 150 The terms "permit" (allow the traffic), "drop" (drop with no 151 notification to sender), and "reject" (drop with appropriate 152 notification to sender) are employed as defined in [RFC3871]. 153 Throughout this document we also employ the term "discard" as a 154 generic term to indicate the act of discarding a packet, irrespective 155 of whether the sender is notified of such drops, and irrespective of 156 whether the specific filtering action is logged. 158 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 159 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 160 "OPTIONAL" in this document are to be interpreted as described in BCP 161 14 [RFC2119] [RFC8174] when, and only when, they appear in all 162 capitals, as shown here. 164 2.2. Applicability Statement 166 This document provides advice on the filtering of IPv6 packets with 167 EHs at transit routers for traffic *not* explicitly destined to them, 168 for cases in which such filtering is deemed as necessary. 170 2.3. Conventions 172 This document assumes that nodes comply with the requirements in 173 [RFC7045]. Namely, 175 "If a forwarding node discards a packet containing a standard IPv6 176 extension header, it MUST be the result of a configurable policy 177 and not just the result of a failure to recognise such a header. 178 This means that the discard policy for each standard type of 179 extension header MUST be individually configurable. The default 180 configuration SHOULD allow all standard extension headers." 182 The advice provided in this document is only meant to guide an 183 operator in configuring forwarding devices, and is *not* to be 184 interpreted as advice regarding default configuration settings for 185 network devices. That is, this document provides advice with respect 186 to operational configurations, but does not change the implementation 187 defaults required by [RFC7045]. 189 We recommend that configuration options are made available to govern 190 the processing of each IPv6 EH type and each IPv6 option type. Such 191 configuration options should include the following possible settings: 193 * Permit this IPv6 EH or IPv6 Option type. 195 * Drop (and log) packets containing this IPv6 EH or option type. 197 * Reject (and log) packets containing this IPv6 EH or option type 198 (where the packet drop is signaled with an ICMPv6 error message). 200 * Rate-limit traffic containing this IPv6 EH or option type. 202 * Ignore this IPv6 EH or option type (as if it was not present) and 203 process the packet according the rules for the remaining headers. 204 We note that if a packet carries forwarding information (e.g., in 205 an IPv6 Routing Header) this might be an inappropriate or 206 undesirable action. 208 We note that special care needs to be taken when devices log packet 209 drops/rejects. Devices should count the number of packets dropped/ 210 rejected, but the logging of drop/reject events should be limited so 211 as to not overburden device resources. 213 Finally, we note that when discarding packets, it is generally 214 desirable that the sender be signaled of the packet drop, since this 215 is of use for trouble-shooting purposes. However, throughout this 216 document (when recommending that packets be discarded) we generically 217 refer to the action as "discard" without specifying whether the 218 sender is signaled of the packet drop. 220 3. IPv6 Extension Headers 222 3.1. General Discussion 224 IPv6 [RFC8200] EHs allow for the extension of the IPv6 protocol. 225 Since both IPv6 EHs and upper-layer protocols share the same 226 namespace ("Next Header" registry/namespace), [RFC7045] identifies 227 which of the currently assigned Internet Protocol numbers identify 228 IPv6 EHs vs. upper-layer protocols. This document discusses the 229 filtering of packets based on the IPv6 EHs (as specified by 230 [RFC7045]) they contain. 232 NOTE: [RFC8200] specifies that non-fragmented IPv6 datagrams and 233 IPv6 First-Fragments must contain the entire IPv6 header chain 234 [RFC7112]. Therefore, intermediate systems can enforce the 235 filtering policies discussed in this document, or resort to simply 236 discarding the offending packets when they fail to comply with the 237 requirements in [RFC8200]. We note that, in order to implement 238 filtering rules on the fast path, it may be necessary for the 239 filtering device to limit the depth into the packet that can be 240 inspected before giving up. In circumstances where such a 241 limitation exists, it is recommended that implementations provide 242 a configuration option that specifies whether to discard packets 243 if the aforementioned limit is encountered. Operators may then 244 determine according to their own circumstances how such packets 245 will be handled. 247 3.2. General Security Implications 249 In some device architectures, IPv6 packets that contain IPv6 EHs can 250 cause the corresponding packets to be processed on the slow path, and 251 hence may be leveraged for the purpose of Denial of Service (DoS) 252 attacks [RFC9098] [Cisco-EH] [FW-Benchmark]. 254 Operators are urged to consider the IPv6 EH and IPv6 options handling 255 capabilities of their devices as they make deployment decisions in 256 the future. 258 3.3. Summary of Advice on the Handling of IPv6 Packets with Specific 259 IPv6 Extension Headers 261 This section summarizes the advice provided in Section 3.4, providing 262 references to the specific sections in which a detailed analysis can 263 be found. 265 +=========================+==========================+===========+ 266 | EH type | Filtering policy | Reference | 267 +=========================+==========================+===========+ 268 | IPv6 Hop-by-Hop Options | Drop or Ignore | Section | 269 | (Proto=0) | | 3.4.1 | 270 +-------------------------+--------------------------+-----------+ 271 | Routing Header for IPv6 | Drop only RHT0 and RHT1. | Section | 272 | (Proto=43) | Permit other RH Types | 3.4.2 | 273 +-------------------------+--------------------------+-----------+ 274 | Fragment Header for | Permit | Section | 275 | IPv6 (Proto=44) | | 3.4.3 | 276 +-------------------------+--------------------------+-----------+ 277 | Encapsulating Security | Permit | Section | 278 | Payload (Proto=50) | | 3.4.4 | 279 +-------------------------+--------------------------+-----------+ 280 | Authentication Header | Permit | Section | 281 | (Proto=51) | | 3.4.5 | 282 +-------------------------+--------------------------+-----------+ 283 | Destination Options for | Permit | Section | 284 | IPv6 (Proto=60) | | 3.4.6 | 285 +-------------------------+--------------------------+-----------+ 286 | Mobility Header | Permit | Section | 287 | (Proto=135) | | 3.4.7 | 288 +-------------------------+--------------------------+-----------+ 289 | Host Identity Protocol | Permit | Section | 290 | (Proto=139) | | 3.4.8 | 291 +-------------------------+--------------------------+-----------+ 292 | Shim6 Protocol | Permit | Section | 293 | (Proto=140) | | 3.4.9 | 294 +-------------------------+--------------------------+-----------+ 295 | Use for experimentation | Drop | Section | 296 | and testing (Proto=253 | | 3.4.10 | 297 | and 254) | | | 298 +-------------------------+--------------------------+-----------+ 300 Table 1: Summary of Advice on the Handling of IPv6 Packets 301 with Specific IPv6 Extension Headers 303 3.4. Advice on the Handling of IPv6 Packets with Specific IPv6 304 Extension Headers 306 3.4.1. IPv6 Hop-by-Hop Options (Protocol Number=0) 307 3.4.1.1. Uses 309 The Hop-by-Hop Options header is used to carry optional information 310 that may be examined by every node along a packet's delivery path. 311 It is expected that nodes will examine the Hop-by-Hop Options header 312 if explicitly configured to do so. 314 NOTE: A previous revision of the IPv6 core specification, [RFC2460], 315 originally required that all nodes examined and processed the Hop-by- 316 Hop Options header. However, even before the publication of 317 [RFC8200] a number of implementations already provided the option of 318 ignoring this header unless explicitly configured to examine it. 320 3.4.1.2. Specification 322 This EH is specified in [RFC8200]. At the time of this writing, the 323 following options have been specified for the Hop-by-Hop Options EH: 325 * Type 0x00: Pad1 [RFC8200] 327 * Type 0x01: PadN [RFC8200] 329 * Type 0x05: Router Alert [RFC2711] 331 * Type 0x07: CALIPSO [RFC5570] 333 * Type 0x08: SMF_DPD [RFC6621] 335 * Type 0x23: RPL Option [RFC9008] 337 * Type 0x26: Quick-Start [RFC4782] 339 * Type 0x4D: (Deprecated) 341 * Type 0x63: RPL Option [RFC6553] 343 * Type 0x6D: MPL Option [RFC7731] 345 * Type 0x8A: Endpoint Identification (Deprecated) 346 [draft-ietf-nimrod-eid] 348 * Type 0xC2: Jumbo Payload [RFC2675] 350 * Type 0xEE: IPv6 DFF Header [RFC6971] 352 * Type 0x1E: RFC3692-style Experiment [RFC4727] 354 * Type 0x3E: RFC3692-style Experiment [RFC4727] 355 * Type 0x5E: RFC3692-style Experiment [RFC4727] 357 * Type 0x7E: RFC3692-style Experiment [RFC4727] 359 * Type 0x9E: RFC3692-style Experiment [RFC4727] 361 * Type 0xBE: RFC3692-style Experiment [RFC4727] 363 * Type 0xDE: RFC3692-style Experiment [RFC4727] 365 * Type 0xFE: RFC3692-style Experiment [RFC4727] 367 3.4.1.3. Specific Security Implications 369 Legacy nodes that process this extension header might be subject to 370 Denial of Service attacks. 372 NOTE: While [RFC8200] has removed this requirement, the deployed base 373 may still reflect the classical behavior for a while, and hence the 374 potential security problems of this EH are still of concern. 376 3.4.1.4. Operational and Interoperability Impact if Blocked 378 Discarding packets containing a Hop-by-Hop Options EH would break any 379 of the protocols that rely on it for proper functioning. For 380 example, it would break RSVP [RFC2205] and multicast deployments, and 381 would cause IPv6 jumbograms to be discarded. 383 3.4.1.5. Advice 385 Nodes implementing [RFC8200] would already ignore this extension 386 header unless explicitly required to process it. For legacy 387 ([RFC2460]) nodes, the recommended configuration for the processing 388 of these packets depends on the features and capabilities of the 389 underlying platform, the configuration of the platform, and also the 390 deployment environment of the platform. On platforms that allow 391 forwarding of packets with HBH Options on the fast path, we recommend 392 that packets with a HBH Options EH be forwarded as normal. 393 Otherwise, on platforms in which processing of packets with a IPv6 394 HBH Options EH is carried out in the slow path, and an option is 395 provided to rate-limit these packets, we recommend that this option 396 be selected. Finally, when packets containing a HBH Options EH are 397 processed in the slow-path, and the underlying platform does not have 398 any mitigation options available for attacks based on these packets, 399 we recommend that such platforms discard packets containing IPv6 HBH 400 Options EHs. 402 Finally, we note that RPL (Routing Protocol for Low-Power and Lossy 403 Networks) routers [RFC6550] must not discard packets based on the 404 presence of an IPv6 Hop-by-Hop Options EH, as this would break RPL. 406 3.4.2. Routing Header for IPv6 (Protocol Number=43) 408 3.4.2.1. Uses 410 The Routing header is used by an IPv6 source to list one or more 411 intermediate nodes to be "visited" on the way to a packet's 412 destination. 414 3.4.2.2. Specification 416 This EH is specified in [RFC8200]. [RFC2460] had originally 417 specified the Routing Header Type 0, which was later obsoleted by 418 [RFC5095], and thus removed from [RFC8200]. 420 At the time of this writing, the following Routing Types have been 421 specified: 423 * Type 0: Source Route (DEPRECATED) [RFC2460] [RFC5095] 425 * Type 1: Nimrod (DEPRECATED) 427 * Type 2: Type 2 Routing Header [RFC6275] 429 * Type 3: RPL Source Route Header [RFC6554] 431 * Type 4: Segment Routing Header (SRH) [RFC8754] 433 * Types 5-252: Unassigned 435 * Type 253: RFC3692-style Experiment 1 [RFC4727] 437 * Type 254: RFC3692-style Experiment 2 [RFC4727] 439 * Type 255: Reserved 441 3.4.2.3. Specific Security Implications 443 The security implications of RHT0 have been discussed in detail in 444 [Biondi2007] and [RFC5095]. RHT1 was never widely implemented. The 445 security implications of RHT2, RHT3, and RHT4 (SRH) are discussed in 446 [RFC6275], [RFC6554], and [RFC8754], respectively. 448 3.4.2.4. Operational and Interoperability Impact if Blocked 450 Blocking packets containing a RHT0 or RHT1 has no operational 451 implications, since both have been deprecated. Blocking packets with 452 a RHT2 would break Mobile IPv6. Packets with a RHT3 may be safely 453 blocked at RPL domain boundaries, since RHT3 headers are employed 454 within a single RPL domain. Blocking packets with a RHT4 (SRH) will 455 break Segment Routing (SR) deployments, if the filtering policy is 456 enforced on packets being forwarded within an SR domain. 458 3.4.2.5. Advice 460 Intermediate systems should discard packets containing a RHT0, RHT1, 461 or RHT3. Other routing header types should be permitted, as required 462 by [RFC7045]. 464 3.4.3. Fragment Header for IPv6 (Protocol Number=44) 466 3.4.3.1. Uses 468 This EH provides the fragmentation functionality for IPv6. 470 3.4.3.2. Specification 472 This EH is specified in [RFC8200]. 474 3.4.3.3. Specific Security Implications 476 The security implications of the Fragment Header range from Denial of 477 Service attacks (e.g. based on flooding a target with IPv6 fragments) 478 to information leakage attacks [RFC7739]. 480 3.4.3.4. Operational and Interoperability Impact if Blocked 482 Blocking packets that contain a Fragment Header will break any 483 protocol that may rely on fragmentation (e.g., the DNS [RFC1034]). 484 However, IP fragmentation is known to introduce fragility to Internet 485 communication [RFC8900]. 487 3.4.3.5. Advice 489 Intermediate systems should permit packets that contain a Fragment 490 Header. 492 3.4.4. Encapsulating Security Payload (Protocol Number=50) 493 3.4.4.1. Uses 495 This EH is employed for the IPsec suite [RFC4303]. 497 3.4.4.2. Specification 499 This EH is specified in [RFC4303]. 501 3.4.4.3. Specific Security Implications 503 Besides the general implications of IPv6 EHs, this EH could be 504 employed to potentially perform a DoS attack at the destination 505 system by wasting CPU resources in validating the contents of the 506 packet. 508 3.4.4.4. Operational and Interoperability Impact if Blocked 510 Discarding packets that employ this EH would break IPsec deployments. 512 3.4.4.5. Advice 514 Intermediate systems should permit packets containing the 515 Encapsulating Security Payload EH. 517 3.4.5. Authentication Header (Protocol Number=51) 519 3.4.5.1. Uses 521 The Authentication Header can be employed for provide authentication 522 services in IPv4 and IPv6. 524 3.4.5.2. Specification 526 This EH is specified in [RFC4302]. 528 3.4.5.3. Specific Security Implications 530 Besides the general implications of IPv6 EHs, this EH could be 531 employed to potentially perform a DoS attack at the destination 532 system by wasting CPU resources in validating the contents of the 533 packet. 535 3.4.5.4. Operational and Interoperability Impact if Blocked 537 Discarding packets that employ this EH would break IPsec deployments. 539 3.4.5.5. Advice 541 Intermediate systems should permit packets containing an 542 Authentication Header. 544 3.4.6. Destination Options for IPv6 (Protocol Number=60) 546 3.4.6.1. Uses 548 The Destination Options header is used to carry optional information 549 that needs be examined only by a packet's destination node(s). 551 3.4.6.2. Specification 553 This EH is specified in [RFC8200]. At the time of this writing, the 554 following options have been specified for this EH: 556 * Type 0x00: Pad1 [RFC8200] 558 * Type 0x01: PadN [RFC8200] 560 * Type 0x04: Tunnel Encapsulation Limit [RFC2473] 562 * Type 0x4D: (Deprecated) 564 * Type 0xC9: Home Address [RFC6275] 566 * Type 0x8A: Endpoint Identification (Deprecated) 567 [draft-ietf-nimrod-eid] 569 * Type 0x8B: ILNP Nonce [RFC6744] 571 * Type 0x8C: Line-Identification Option [RFC6788] 573 * Type 0x1E: RFC3692-style Experiment [RFC4727] 575 * Type 0x3E: RFC3692-style Experiment [RFC4727] 577 * Type 0x5E: RFC3692-style Experiment [RFC4727] 579 * Type 0x7E: RFC3692-style Experiment [RFC4727] 581 * Type 0x9E: RFC3692-style Experiment [RFC4727] 583 * Type 0xBE: RFC3692-style Experiment [RFC4727] 585 * Type 0xDE: RFC3692-style Experiment [RFC4727] 586 * Type 0xFE: RFC3692-style Experiment [RFC4727] 588 3.4.6.3. Specific Security Implications 590 No security implications are known, other than the general 591 implications of IPv6 EHs. For a discussion of possible security 592 implications of specific options specified for the DO header, please 593 see the Section 4.3. 595 3.4.6.4. Operational and Interoperability Impact if Blocked 597 Discarding packets that contain a Destination Options header would 598 break protocols that rely on this EH type for conveying information, 599 including protocols such as ILNP [RFC6740] and Mobile IPv6 [RFC6275], 600 and IPv6 tunnels that employ the Tunnel Encapsulation Limit option. 602 3.4.6.5. Advice 604 Intermediate systems should permit packets that contain a Destination 605 Options Header. 607 3.4.7. Mobility Header (Protocol Number=135) 609 3.4.7.1. Uses 611 The Mobility Header is an EH used by mobile nodes, correspondent 612 nodes, and home agents in all messaging related to the creation and 613 management of bindings in Mobile IPv6. 615 3.4.7.2. Specification 617 This EH is specified in [RFC6275]. 619 3.4.7.3. Specific Security Implications 621 A thorough security assessment of the security implications of the 622 Mobility Header and related mechanisms can be found in Section 15 of 623 [RFC6275]. 625 3.4.7.4. Operational and Interoperability Impact if Blocked 627 Discarding packets containing this EH would break Mobile IPv6. 629 3.4.7.5. Advice 631 Intermediate systems should permit packets containing this EH. 633 3.4.8. Host Identity Protocol (Protocol Number=139) 635 3.4.8.1. Uses 637 This EH is employed with the Host Identity Protocol (HIP), an 638 experimental protocol that allows consenting hosts to securely 639 establish and maintain shared IP-layer state, allowing separation of 640 the identifier and locator roles of IP addresses, thereby enabling 641 continuity of communications across IP address changes. 643 3.4.8.2. Specification 645 This EH is specified in [RFC7401]. 647 3.4.8.3. Specific Security Implications 649 The security implications of the HIP header are discussed in detail 650 in Section 8 of [RFC6275]. 652 3.4.8.4. Operational and Interoperability Impact if Blocked 654 Discarding packets that contain the Host Identity Protocol would 655 break HIP deployments. 657 3.4.8.5. Advice 659 Intermediate systems should permit packets that contain a Host 660 Identity Protocol EH. 662 3.4.9. Shim6 Protocol (Protocol Number=140) 664 3.4.9.1. Uses 666 This EH is employed by the Shim6 [RFC5533] Protocol. 668 3.4.9.2. Specification 670 This EH is specified in [RFC5533]. 672 3.4.9.3. Specific Security Implications 674 The specific security implications are discussed in detail in 675 Section 16 of [RFC5533]. 677 3.4.9.4. Operational and Interoperability Impact if Blocked 679 Discarding packets that contain this EH will break Shim6. 681 3.4.9.5. Advice 683 Intermediate systems should permit packets containing this EH. 685 3.4.10. Use for experimentation and testing (Protocol Numbers=253 and 686 254) 688 3.4.10.1. Uses 690 These IPv6 EHs are employed for performing RFC3692-Style experiments 691 (see [RFC3692] for details). 693 3.4.10.2. Specification 695 These EHs are specified in [RFC3692] and [RFC4727]. 697 3.4.10.3. Specific Security Implications 699 The security implications of these EHs will depend on their specific 700 use. 702 3.4.10.4. Operational and Interoperability Impact if Blocked 704 For obvious reasons, discarding packets that contain these EHs limits 705 the ability to perform legitimate experiments across IPv6 routers. 707 3.4.10.5. Advice 709 Operators should determine according to their own circumstances 710 whether to discard packets containing these EHs. 712 3.5. Advice on the Handling of Packets with Unknown IPv6 Extension 713 Headers 715 We refer to IPv6 EHs that have not been assigned an Internet Protocol 716 Number by IANA (and marked as such) in [IANA-PROTOCOLS] as "unknown 717 IPv6 extension headers" ("unknown IPv6 EHs"). 719 3.5.1. Uses 721 New IPv6 EHs may be specified as part of future extensions to the 722 IPv6 protocol. 724 Since IPv6 EHs and Upper-layer protocols employ the same namespace, 725 it is impossible to tell whether an unknown "Internet Protocol 726 Number" is being employed for an IPv6 EH or an Upper-Layer protocol. 728 3.5.2. Specification 730 The processing of unknown IPv6 EHs is specified in [RFC7045]. 732 3.5.3. Specific Security Implications 734 For obvious reasons, it is impossible to determine specific security 735 implications of unknown IPv6 EHs. 737 3.5.4. Operational and Interoperability Impact if Blocked 739 As noted in [RFC7045], discarding unknown IPv6 EHs may slow down the 740 deployment of new IPv6 EHs and transport protocols. The 741 corresponding IANA registry ([IANA-PROTOCOLS]) should be monitored 742 such that filtering rules are updated as new IPv6 EHs are 743 standardized. 745 We note that since IPv6 EHs and upper-layer protocols share the same 746 numbering space, discarding unknown IPv6 EHs may result in packets 747 encapsulating unknown upper-layer protocols being discarded. 749 3.5.5. Advice 751 Operators should determine according to their own circumstances 752 whether to discard packets containing unknown IPv6 EHs. 754 4. IPv6 Options 756 4.1. General Discussion 758 The following subsections describe specific security implications of 759 different IPv6 options, and provide advice regarding filtering 760 packets that contain such options. 762 4.2. General Security Implications of IPv6 Options 764 The general security implications of IPv6 options are closely related 765 to those discussed in Section 3.2 for IPv6 EHs. Essentially, packets 766 that contain IPv6 options might need to be processed by an IPv6 767 router's general-purpose CPU,and hence could present a DDoS risk to 768 that router's general-purpose CPU (and thus to the router itself). 769 For some architectures, a possible mitigation would be to rate-limit 770 the packets that are to be processed by the general-purpose CPU (see 771 e.g. [Cisco-EH]). 773 4.3. Advice on the Handling of Packets with Specific IPv6 Options 775 The following subsections contain a description of each of the IPv6 776 options that have so far been specified, a summary of the security 777 implications of each of such options, a discussion of possible 778 interoperability implications if packets containing such options are 779 discarded, and specific advice regarding whether packets containing 780 these options should be permitted. 782 4.3.1. Pad1 (Type=0x00) 784 4.3.1.1. Uses 786 This option is used when necessary to align subsequent options and to 787 pad out the containing header to a multiple of 8 octets in length. 789 4.3.1.2. Specification 791 This option is specified in [RFC8200]. 793 4.3.1.3. Specific Security Implications 795 None. 797 4.3.1.4. Operational and Interoperability Impact if Blocked 799 Discarding packets that contain this option would potentially break 800 any protocol that relies on IPv6 options. 802 4.3.1.5. Advice 804 Intermediate systems should not discard packets based on the presence 805 of this option. 807 4.3.2. PadN (Type=0x01) 809 4.3.2.1. Uses 811 This option is used when necessary to align subsequent options and to 812 pad out the containing header to a multiple of 8 octets in length. 814 4.3.2.2. Specification 816 This option is specified in [RFC8200]. 818 4.3.2.3. Specific Security Implications 820 Because of the possible size of this option, it could be leveraged as 821 a large-bandwidth covert channel. 823 4.3.2.4. Operational and Interoperability Impact if Blocked 825 Discarding packets that contain this option would potentially break 826 any protocol that relies on IPv6 options. 828 4.3.2.5. Advice 830 Intermediate systems should not discard IPv6 packets based on the 831 presence of this option. 833 4.3.3. Jumbo Payload (Type=0XC2) 835 4.3.3.1. Uses 837 The Jumbo payload option provides the means of specifying payloads 838 larger than 65535 bytes. 840 4.3.3.2. Specification 842 This option is specified in [RFC2675]. 844 4.3.3.3. Specific Security Implications 846 There are no specific issues arising from this option, except for 847 improper validity checks of the option and associated packet lengths. 849 4.3.3.4. Operational and Interoperability Impact if Blocked 851 Discarding packets based on the presence of this option will cause 852 IPv6 jumbograms to be discarded. 854 4.3.3.5. Advice 856 An operator should permit this option only in specific scenarios in 857 which support for IPv6 jumbograms is desired. 859 4.3.4. RPL Option (Type=0x63) 861 4.3.4.1. Uses 863 The RPL Option provides a mechanism to include routing information 864 with each datagram that an RPL router forwards. 866 4.3.4.2. Specification 868 This option was originally specified in [RFC6553]. It has been 869 deprecated by [RFC9008]. 871 4.3.4.3. Specific Security Implications 873 Those described in [RFC9008]. 875 4.3.4.4. Operational and Interoperability Impact if Blocked 877 This option is meant to be employed within an RPL instance. As a 878 result, discarding packets based on the presence of this option 879 outside of an RPL instance will not result in interoperability 880 implications. 882 4.3.4.5. Advice 884 Non-RPL routers should discard packets that contain an RPL option. 886 4.3.5. RPL Option (Type=0x23) 888 4.3.5.1. Uses 890 The RPL Option provides a mechanism to include routing information 891 with each datagram that an RPL router forwards. 893 4.3.5.2. Specification 895 This option is specified in [RFC9008]. 897 4.3.5.3. Specific Security Implications 899 Those described in [RFC9008]. 901 4.3.5.4. Operational and Interoperability Impact if Blocked 903 This option can survive outside of an RPL instance. As a result, 904 discarding packets based on the presence of this option would break 905 some use cases for RPL (see [RFC9008]). 907 4.3.5.5. Advice 909 Intermediate systems should not discard IPv6 packets based on the 910 presence of this option. 912 4.3.6. Tunnel Encapsulation Limit (Type=0x04) 913 4.3.6.1. Uses 915 The Tunnel Encapsulation Limit option can be employed to specify how 916 many further levels of nesting the packet is permitted to undergo. 918 4.3.6.2. Specification 920 This option is specified in [RFC2473]. 922 4.3.6.3. Specific Security Implications 924 Those described in [RFC2473]. 926 4.3.6.4. Operational and Interoperability Impact if Blocked 928 Discarding packets based on the presence of this option could result 929 in tunnel traffic being discarded. 931 4.3.6.5. Advice 933 Intermediate systems should not discard packets based on the presence 934 of this option. 936 4.3.7. Router Alert (Type=0x05) 938 4.3.7.1. Uses 940 The Router Alert option [RFC2711] is employed by a number of 941 protocols, including the Resource reSerVation Protocol (RSVP) 942 [RFC2205], Multicast Listener Discovery (MLD) [RFC2710] [RFC3810], 943 Multicast Router Discovery (MRD) [RFC4286], and General Internet 944 Signaling Transport (GIST) [RFC5971]. Its usage is discussed in 945 detail in [RFC6398]. 947 4.3.7.2. Specification 949 This option is specified in [RFC2711]. 951 4.3.7.3. Specific Security Implications 953 Since this option causes the contents of the packet to be inspected 954 by the handling device, this option could be leveraged for performing 955 DoS attacks. The security implications of the Router Alert option 956 are discussed in detail in [RFC6398]. 958 4.3.7.4. Operational and Interoperability Impact if Blocked 960 Discarding packets that contain this option would break any protocols 961 that rely on them, such as RSVP and multicast deployments. Please 962 see Section 4.3.7.3 for further details. 964 4.3.7.5. Advice 966 Packets containing this option should be permitted in environments 967 where support for RSVP, multicast routing, or similar protocols is 968 desired. 970 4.3.8. Quick-Start (Type=0x26) 972 4.3.8.1. Uses 974 This IP Option is used in the specification of Quick-Start for TCP 975 and IP, which is an experimental mechanism that allows transport 976 protocols, in cooperation with routers, to determine an allowed 977 sending rate at the start and, at times, in the middle of a data 978 transfer (e.g., after an idle period) [RFC4782]. 980 4.3.8.2. Specification 982 This option is specified in [RFC4782], on the "Experimental" track. 984 4.3.8.3. Specific Security Implications 986 Section 9.6 of [RFC4782] notes that Quick-Start is vulnerable to two 987 kinds of attacks: 989 * attacks to increase the routers' processing and state load, and, 991 * attacks with bogus Quick-Start Requests to temporarily tie up 992 available Quick-Start bandwidth, preventing routers from approving 993 Quick-Start Requests from other connections. 995 We note that if routers in a given environment do not implement and 996 enable the Quick-Start mechanism, only the general security 997 implications of IP options (discussed in Section 4.2) would apply. 999 4.3.8.4. Operational and Interoperability Impact if Blocked 1001 The Quick-Start functionality would be disabled, and additional 1002 delays in TCP's connection establishment (for example) could be 1003 introduced. (Please see Section 4.7.2 of [RFC4782].) We note, 1004 however, that Quick-Start has been proposed as a mechanism that could 1005 be of use in controlled environments, and not as a mechanism that 1006 would be intended or appropriate for ubiquitous deployment in the 1007 global Internet [RFC4782]. 1009 4.3.8.5. Advice 1011 Intermediate systems should not discard IPv6 packets based on the 1012 presence of this option. 1014 4.3.9. CALIPSO (Type=0x07) 1016 4.3.9.1. Uses 1018 This option is used for encoding explicit packet Sensitivity Labels 1019 on IPv6 packets. It is intended for use only within Multi-Level 1020 Secure (MLS) networking environments that are both trusted and 1021 trustworthy. 1023 4.3.9.2. Specification 1025 This option is specified in [RFC5570]. 1027 4.3.9.3. Specific Security Implications 1029 Presence of this option in a packet does not by itself create any 1030 specific new threat. Packets with this option ought not normally be 1031 seen on the global public Internet. 1033 4.3.9.4. Operational and Interoperability Impact if Blocked 1035 If packets with this option are discarded or if the option is 1036 stripped from the packet during transmission from source to 1037 destination, then the packet itself is likely to be discarded by the 1038 receiver because it is not properly labeled. In some cases, the 1039 receiver might receive the packet but associate an incorrect 1040 sensitivity label with the received data from the packet whose 1041 CALIPSO was stripped by an intermediate router or firewall. 1042 Associating an incorrect sensitivity label can cause the received 1043 information either to be handled as more sensitive than it really is 1044 ("upgrading") or as less sensitive than it really is ("downgrading"), 1045 either of which is problematic. As noted in [RFC5570], IPsec 1046 [RFC4301] [RFC4302] [RFC4303] can be employed to protect the CALIPSO 1047 option. 1049 4.3.9.5. Advice 1051 Recommendations for handling the CALIPSO option depend on the 1052 deployment environment, rather than whether an intermediate system 1053 happens to be deployed as a transit device (e.g., IPv6 transit 1054 router). 1056 Explicit configuration is the only method via which an intermediate 1057 system can know whether that particular intermediate system has been 1058 deployed within a Multi-Level Secure (MLS) environment. In many 1059 cases, ordinary commercial intermediate systems (e.g., IPv6 routers 1060 and firewalls) are the majority of the deployed intermediate systems 1061 inside an MLS network environment. 1063 For Intermediate systems that DO NOT implement [RFC5570], there 1064 should be a configuration option to EITHER (a) drop packets 1065 containing the CALIPSO option OR (b) to ignore the presence of the 1066 CALIPSO option and forward the packets normally. In non-MLS 1067 environments, such intermediate systems should have this 1068 configuration option set to (a) above. In MLS environments, such 1069 intermediate systems should have this option set to (b) above. The 1070 default setting for this configuration option should be set to (a) 1071 above, because MLS environments are much less common than non-MLS 1072 environments. 1074 For Intermediate systems that DO implement [RFC5570], there should be 1075 configuration options (a) and (b) from the preceding paragraph and 1076 also a third configuration option (c) to process packets containing a 1077 CALIPSO option as per [RFC5570]. When deployed in non-MLS 1078 environments, such intermediate systems should have this 1079 configuration option set to (a) above. When deployed in MLS 1080 environments, such intermediate systems should have this set to (c). 1081 The default setting for this configuration option MAY be set to (a) 1082 above, because MLS environments are much less common than non-MLS 1083 environments. 1085 4.3.10. SMF_DPD (Type=0x08) 1087 4.3.10.1. Uses 1089 This option is employed in the (experimental) Simplified Multicast 1090 Forwarding (SMF) for unique packet identification for IPv6 I-DPD, and 1091 as a mechanism to guarantee non-collision of hash values for 1092 different packets when H-DPD is used. 1094 4.3.10.2. Specification 1096 This option is specified in [RFC6621]. 1098 4.3.10.3. Specific Security Implications 1100 None. The use of transient numeric identifiers is subject to the 1101 security and privacy considerations discussed in 1102 [I-D.irtf-pearg-numeric-ids-generation]. 1104 4.3.10.4. Operational and Interoperability Impact if Blocked 1106 Dropping packets containing this option within a MANET domain would 1107 break SMF. However, dropping such packets at the border of such 1108 domain would have no negative impact. 1110 4.3.10.5. Advice 1112 Intermediate systems that are not within a MANET domain should 1113 discard packets that contain this option. 1115 4.3.11. Home Address (Type=0xC9) 1117 4.3.11.1. Uses 1119 The Home Address option is used by a Mobile IPv6 node while away from 1120 home, to inform the recipient of the mobile node's home address. 1122 4.3.11.2. Specification 1124 This option is specified in [RFC6275]. 1126 4.3.11.3. Specific Security Implications 1128 No (known) additional security implications than those described in 1129 [RFC6275]. 1131 4.3.11.4. Operational and Interoperability Impact if Blocked 1133 Discarding IPv6 packets based on the presence of this option will 1134 break Mobile IPv6. 1136 4.3.11.5. Advice 1138 Intermediate systems should not discard IPv6 packets based on the 1139 presence of this option. 1141 4.3.12. Endpoint Identification (Type=0x8A) 1143 4.3.12.1. Uses 1145 The Endpoint Identification option was meant to be used with the 1146 Nimrod routing architecture [NIMROD-DOC], but has never seen 1147 widespread deployment. 1149 4.3.12.2. Specification 1151 This option is specified in [NIMROD-DOC]. 1153 4.3.12.3. Specific Security Implications 1155 Undetermined. 1157 4.3.12.4. Operational and Interoperability Impact if Blocked 1159 None. 1161 4.3.12.5. Advice 1163 Intermediate systems should discard packets that contain this option. 1165 4.3.13. ILNP Nonce (Type=0x8B) 1167 4.3.13.1. Uses 1169 This option is employed by Identifier-Locator Network Protocol for 1170 IPv6 (ILNPv6) for providing protection against off-path attacks for 1171 packets when ILNPv6 is in use, and as a signal during initial 1172 network-layer session creation that ILNPv6 is proposed for use with 1173 this network-layer session, rather than classic IPv6. 1175 4.3.13.2. Specification 1177 This option is specified in [RFC6744]. 1179 4.3.13.3. Specific Security Implications 1181 Those described in [RFC6744]. 1183 4.3.13.4. Operational and Interoperability Impact if Blocked 1185 Discarding packets that contain this option will break INLPv6 1186 deployments. 1188 4.3.13.5. Advice 1190 Intermediate systems should not discard packets based on the presence 1191 of this option. 1193 4.3.14. Line-Identification Option (Type=0x8C) 1195 4.3.14.1. Uses 1197 This option is used by an Edge Router to identify the subscriber 1198 premises in scenarios where several subscriber premises may be 1199 logically connected to the same interface of an Edge Router. 1201 4.3.14.2. Specification 1203 This option is specified in [RFC6788]. 1205 4.3.14.3. Specific Security Implications 1207 Those described in [RFC6788]. 1209 4.3.14.4. Operational and Interoperability Impact if Blocked 1211 Since this option is meant to be employed in Router Solicitation 1212 messages, discarding packets based on the presence of this option at 1213 intermediate systems will result in no interoperability implications. 1215 4.3.14.5. Advice 1217 Intermediate devices should discard packets that contain this option. 1219 4.3.15. Deprecated (Type=0x4D) 1221 4.3.15.1. Uses 1223 No information has been found about this option type. 1225 4.3.15.2. Specification 1227 No information has been found about this option type. 1229 4.3.15.3. Specific Security Implications 1231 No information has been found about this option type, and hence it 1232 has been impossible to perform the corresponding security assessment. 1234 4.3.15.4. Operational and Interoperability Impact if Blocked 1236 Unknown. 1238 4.3.15.5. Advice 1240 Intermediate systems should discard packets that contain this option. 1242 4.3.16. MPL Option (Type=0x6D) 1244 4.3.16.1. Uses 1246 This option is used with the Multicast Protocol for Low power and 1247 Lossy Networks (MPL), that provides IPv6 multicast forwarding in 1248 constrained networks. 1250 4.3.16.2. Specification 1252 This option is specified in [RFC7731], and is meant to be included 1253 only in Hop-by-Hop Option headers. 1255 4.3.16.3. Specific Security Implications 1257 Those described in [RFC7731]. 1259 4.3.16.4. Operational and Interoperability Impact if Blocked 1261 Dropping packets that contain an MPL option within an MPL network 1262 would break the Multicast Protocol for Low power and Lossy Networks 1263 (MPL). However, dropping such packets at the border of such networks 1264 will have no negative impact. 1266 4.3.16.5. Advice 1268 Intermediate systems should not discard packets based on the presence 1269 of this option. However, since this option has been specified for 1270 the Hop-by-Hop Options, such systems should consider the discussion 1271 in Section 3.4.1. 1273 4.3.17. IP_DFF (Type=0xEE) 1275 4.3.17.1. Uses 1277 This option is employed with the (Experimental) Depth-First 1278 Forwarding (DFF) in Unreliable Networks. 1280 4.3.17.2. Specification 1282 This option is specified in [RFC6971]. 1284 4.3.17.3. Specific Security Implications 1286 Those specified in [RFC6971]. 1288 4.3.17.4. Operational and Interoperability Impact if Blocked 1290 Dropping packets containing this option within a routing domain that 1291 is running DFF would break DFF. However, dropping such packets at 1292 the border of such domains will have no security implications. 1294 4.3.17.5. Advice 1296 Intermediate systems that do not operate within a routing domain that 1297 is running DFF should discard packets containing this option. 1299 4.3.18. RFC3692-style Experiment (Types = 0x1E, 0x3E, 0x5E, 0x7E, 0x9E, 1300 0xBE, 0xDE, 0xFE) 1302 4.3.18.1. Uses 1304 These options can be employed for performing RFC3692-style 1305 experiments. It is only appropriate to use these values in 1306 explicitly configured experiments; they must not be shipped as 1307 defaults in implementations. 1309 4.3.18.2. Specification 1311 Specified in RFC 4727 [RFC4727] in the context of RFC3692-style 1312 experiments. 1314 4.3.18.3. Specific Security Implications 1316 The specific security implications will depend on the specific use of 1317 these options. 1319 4.3.18.4. Operational and Interoperability Impact if Blocked 1321 For obvious reasons, discarding packets that contain these options 1322 limits the ability to perform legitimate experiments across IPv6 1323 routers. 1325 4.3.18.5. Advice 1327 Operators should determine according to their own circumstances 1328 whether to discard packets containing these IPv6 options. 1330 4.4. Advice on the handling of Packets with Unknown IPv6 Options 1332 We refer to IPv6 options that have not been assigned an IPv6 option 1333 type in the corresponding registry ([IANA-IPV6-PARAM]) as "unknown 1334 IPv6 options". 1336 4.4.1. Uses 1338 New IPv6 options may be specified as part of future protocol work. 1340 4.4.2. Specification 1342 The processing of unknown IPv6 options is specified in [RFC8200]. 1344 4.4.3. Specific Security Implications 1346 For obvious reasons, it is impossible to determine specific security 1347 implications of unknown IPv6 options. 1349 4.4.4. Operational and Interoperability Impact if Blocked 1351 Discarding unknown IPv6 options may slow down the deployment of new 1352 IPv6 options. As noted in [draft-gont-6man-ipv6-opt-transmit], the 1353 corresponding IANA registry ([IANA-IPV6-PARAM] should be monitored 1354 such that IPv6 option filtering rules are updated as new IPv6 options 1355 are standardized. 1357 4.4.5. Advice 1359 Operators should determine according to their own circumstances 1360 whether to discard packets containing unknown IPv6 options. 1362 5. IANA Considerations 1364 This document has no actions for IANA. 1366 6. Privacy Considerations 1368 There are no privacy considerations associated with this document. 1370 7. Security Considerations 1372 This document provides advice on the filtering of IPv6 packets that 1373 contain IPv6 EHs (and possibly IPv6 options) at IPv6 transit routers. 1374 It is meant to improve the current situation of widespread dropping 1375 of such IPv6 packets in those cases where the drops result from 1376 improper configuration defaults, or inappropriate advice in this 1377 area. 1379 8. Acknowledgements 1381 The authors would like to thank Ron Bonica for his work on earlier 1382 versions of this document. 1384 The authors of this document would like to thank (in alphabetical 1385 order) Mikael Abrahamsson, Brian Carpenter, Darren Dukes, Lars 1386 Eggert, David Farmer, Mike Heard, Bob Hinden, Christian Huitema, 1387 Benjamin Kaduk, Erik Kline, Jen Linkova, Carlos Pignataro, Alvaro 1388 Retana, Maria Ines Robles, Donald Smith, Pascal Thubert, Ole Troan, 1389 Gunter Van De Velde, and Eric Vyncke, for providing valuable comments 1390 on earlier versions of this document. 1392 This document borrows some text and analysis from [RFC7126], authored 1393 by Fernando Gont, Randall Atkinson, and Carlos Pignataro. 1395 The authors would like to thank Eric Vyncke for his guidance during 1396 the publication process of this document. 1398 Fernando would also like to thank Brian Carpenter and Ran Atkinson 1399 who, over the years, have answered many questions and provided 1400 valuable comments that have benefited his protocol-related work 1401 (including the present document). 1403 9. References 1405 9.1. Normative References 1407 [RFC1034] Mockapetris, P., "Domain names - concepts and facilities", 1408 STD 13, RFC 1034, DOI 10.17487/RFC1034, November 1987, 1409 . 1411 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1412 Requirement Levels", BCP 14, RFC 2119, 1413 DOI 10.17487/RFC2119, March 1997, 1414 . 1416 [RFC2205] Braden, R., Ed., Zhang, L., Berson, S., Herzog, S., and S. 1417 Jamin, "Resource ReSerVation Protocol (RSVP) -- Version 1 1418 Functional Specification", RFC 2205, DOI 10.17487/RFC2205, 1419 September 1997, . 1421 [RFC2473] Conta, A. and S. Deering, "Generic Packet Tunneling in 1422 IPv6 Specification", RFC 2473, DOI 10.17487/RFC2473, 1423 December 1998, . 1425 [RFC2675] Borman, D., Deering, S., and R. Hinden, "IPv6 Jumbograms", 1426 RFC 2675, DOI 10.17487/RFC2675, August 1999, 1427 . 1429 [RFC2710] Deering, S., Fenner, W., and B. Haberman, "Multicast 1430 Listener Discovery (MLD) for IPv6", RFC 2710, 1431 DOI 10.17487/RFC2710, October 1999, 1432 . 1434 [RFC2711] Partridge, C. and A. Jackson, "IPv6 Router Alert Option", 1435 RFC 2711, DOI 10.17487/RFC2711, October 1999, 1436 . 1438 [RFC3692] Narten, T., "Assigning Experimental and Testing Numbers 1439 Considered Useful", BCP 82, RFC 3692, 1440 DOI 10.17487/RFC3692, January 2004, 1441 . 1443 [RFC3810] Vida, R., Ed. and L. Costa, Ed., "Multicast Listener 1444 Discovery Version 2 (MLDv2) for IPv6", RFC 3810, 1445 DOI 10.17487/RFC3810, June 2004, 1446 . 1448 [RFC4286] Haberman, B. and J. Martin, "Multicast Router Discovery", 1449 RFC 4286, DOI 10.17487/RFC4286, December 2005, 1450 . 1452 [RFC4301] Kent, S. and K. Seo, "Security Architecture for the 1453 Internet Protocol", RFC 4301, DOI 10.17487/RFC4301, 1454 December 2005, . 1456 [RFC4302] Kent, S., "IP Authentication Header", RFC 4302, 1457 DOI 10.17487/RFC4302, December 2005, 1458 . 1460 [RFC4303] Kent, S., "IP Encapsulating Security Payload (ESP)", 1461 RFC 4303, DOI 10.17487/RFC4303, December 2005, 1462 . 1464 [RFC4727] Fenner, B., "Experimental Values In IPv4, IPv6, ICMPv4, 1465 ICMPv6, UDP, and TCP Headers", RFC 4727, 1466 DOI 10.17487/RFC4727, November 2006, 1467 . 1469 [RFC4782] Floyd, S., Allman, M., Jain, A., and P. Sarolahti, "Quick- 1470 Start for TCP and IP", RFC 4782, DOI 10.17487/RFC4782, 1471 January 2007, . 1473 [RFC5095] Abley, J., Savola, P., and G. Neville-Neil, "Deprecation 1474 of Type 0 Routing Headers in IPv6", RFC 5095, 1475 DOI 10.17487/RFC5095, December 2007, 1476 . 1478 [RFC5533] Nordmark, E. and M. Bagnulo, "Shim6: Level 3 Multihoming 1479 Shim Protocol for IPv6", RFC 5533, DOI 10.17487/RFC5533, 1480 June 2009, . 1482 [RFC5570] StJohns, M., Atkinson, R., and G. Thomas, "Common 1483 Architecture Label IPv6 Security Option (CALIPSO)", 1484 RFC 5570, DOI 10.17487/RFC5570, July 2009, 1485 . 1487 [RFC5971] Schulzrinne, H. and R. Hancock, "GIST: General Internet 1488 Signalling Transport", RFC 5971, DOI 10.17487/RFC5971, 1489 October 2010, . 1491 [RFC6275] Perkins, C., Ed., Johnson, D., and J. Arkko, "Mobility 1492 Support in IPv6", RFC 6275, DOI 10.17487/RFC6275, July 1493 2011, . 1495 [RFC6398] Le Faucheur, F., Ed., "IP Router Alert Considerations and 1496 Usage", BCP 168, RFC 6398, DOI 10.17487/RFC6398, October 1497 2011, . 1499 [RFC6550] Winter, T., Ed., Thubert, P., Ed., Brandt, A., Hui, J., 1500 Kelsey, R., Levis, P., Pister, K., Struik, R., Vasseur, 1501 JP., and R. Alexander, "RPL: IPv6 Routing Protocol for 1502 Low-Power and Lossy Networks", RFC 6550, 1503 DOI 10.17487/RFC6550, March 2012, 1504 . 1506 [RFC6553] Hui, J. and JP. Vasseur, "The Routing Protocol for Low- 1507 Power and Lossy Networks (RPL) Option for Carrying RPL 1508 Information in Data-Plane Datagrams", RFC 6553, 1509 DOI 10.17487/RFC6553, March 2012, 1510 . 1512 [RFC6554] Hui, J., Vasseur, JP., Culler, D., and V. Manral, "An IPv6 1513 Routing Header for Source Routes with the Routing Protocol 1514 for Low-Power and Lossy Networks (RPL)", RFC 6554, 1515 DOI 10.17487/RFC6554, March 2012, 1516 . 1518 [RFC6621] Macker, J., Ed., "Simplified Multicast Forwarding", 1519 RFC 6621, DOI 10.17487/RFC6621, May 2012, 1520 . 1522 [RFC6740] Atkinson, RJ. and SN. Bhatti, "Identifier-Locator Network 1523 Protocol (ILNP) Architectural Description", RFC 6740, 1524 DOI 10.17487/RFC6740, November 2012, 1525 . 1527 [RFC6744] Atkinson, RJ. and SN. Bhatti, "IPv6 Nonce Destination 1528 Option for the Identifier-Locator Network Protocol for 1529 IPv6 (ILNPv6)", RFC 6744, DOI 10.17487/RFC6744, November 1530 2012, . 1532 [RFC6788] Krishnan, S., Kavanagh, A., Varga, B., Ooghe, S., and E. 1533 Nordmark, "The Line-Identification Option", RFC 6788, 1534 DOI 10.17487/RFC6788, November 2012, 1535 . 1537 [RFC6971] Herberg, U., Ed., Cardenas, A., Iwao, T., Dow, M., and S. 1538 Cespedes, "Depth-First Forwarding (DFF) in Unreliable 1539 Networks", RFC 6971, DOI 10.17487/RFC6971, June 2013, 1540 . 1542 [RFC7045] Carpenter, B. and S. Jiang, "Transmission and Processing 1543 of IPv6 Extension Headers", RFC 7045, 1544 DOI 10.17487/RFC7045, December 2013, 1545 . 1547 [RFC7112] Gont, F., Manral, V., and R. Bonica, "Implications of 1548 Oversized IPv6 Header Chains", RFC 7112, 1549 DOI 10.17487/RFC7112, January 2014, 1550 . 1552 [RFC7401] Moskowitz, R., Ed., Heer, T., Jokela, P., and T. 1553 Henderson, "Host Identity Protocol Version 2 (HIPv2)", 1554 RFC 7401, DOI 10.17487/RFC7401, April 2015, 1555 . 1557 [RFC7731] Hui, J. and R. Kelsey, "Multicast Protocol for Low-Power 1558 and Lossy Networks (MPL)", RFC 7731, DOI 10.17487/RFC7731, 1559 February 2016, . 1561 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 1562 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 1563 May 2017, . 1565 [RFC8200] Deering, S. and R. Hinden, "Internet Protocol, Version 6 1566 (IPv6) Specification", STD 86, RFC 8200, 1567 DOI 10.17487/RFC8200, July 2017, 1568 . 1570 [RFC8754] Filsfils, C., Ed., Dukes, D., Ed., Previdi, S., Leddy, J., 1571 Matsushima, S., and D. Voyer, "IPv6 Segment Routing Header 1572 (SRH)", RFC 8754, DOI 10.17487/RFC8754, March 2020, 1573 . 1575 [RFC8900] Bonica, R., Baker, F., Huston, G., Hinden, R., Troan, O., 1576 and F. Gont, "IP Fragmentation Considered Fragile", 1577 BCP 230, RFC 8900, DOI 10.17487/RFC8900, September 2020, 1578 . 1580 [RFC9008] Robles, M.I., Richardson, M., and P. Thubert, "Using RPI 1581 Option Type, Routing Header for Source Routes, and IPv6- 1582 in-IPv6 Encapsulation in the RPL Data Plane", RFC 9008, 1583 DOI 10.17487/RFC9008, April 2021, 1584 . 1586 9.2. Informative References 1588 [Biondi2007] 1589 Biondi, P. and A. Ebalard, "IPv6 Routing Header Security", 1590 CanSecWest 2007 Security Conference, 2007, 1591 . 1593 [Cisco-EH] Cisco Systems, "IPv6 Extension Headers Review and 1594 Considerations", Whitepaper. October 2006, 1595 . 1598 [draft-gont-6man-ipv6-opt-transmit] 1599 Gont, F., Liu, W., and R. Bonica, "Transmission and 1600 Processing of IPv6 Options", IETF Internet Draft, work in 1601 progress, August 2014. 1603 [draft-ietf-nimrod-eid] 1604 Lynn, C.L., "Endpoint Identifier Destination 1605 Option", IETF Internet Draft, draft-ietf-nimrod-eid- 1606 00.txt, November 1995. 1608 [FW-Benchmark] 1609 Zack, E., "Firewall Security Assessment and Benchmarking 1610 IPv6 Firewall Load Tests", IPv6 Hackers Meeting #1, 1611 Berlin, Germany. June 30, 2013, 1612 . 1616 [I-D.irtf-pearg-numeric-ids-generation] 1617 Gont, F. and I. Arce, "On the Generation of Transient 1618 Numeric Identifiers", Work in Progress, Internet-Draft, 1619 draft-irtf-pearg-numeric-ids-generation-08, 31 January 1620 2022, . 1623 [IANA-IPV6-PARAM] 1624 Internet Assigned Numbers Authority, "Internet Protocol 1625 Version 6 (IPv6) Parameters", December 2013, 1626 . 1629 [IANA-PROTOCOLS] 1630 Internet Assigned Numbers Authority, "Protocol Numbers", 1631 2014, . 1634 [NIMROD-DOC] 1635 Nimrod Documentation Page, 1636 "http://ana-3.lcs.mit.edu/~jnc/nimrod/". 1638 [RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6 1639 (IPv6) Specification", RFC 2460, DOI 10.17487/RFC2460, 1640 December 1998, . 1642 [RFC3871] Jones, G., Ed., "Operational Security Requirements for 1643 Large Internet Service Provider (ISP) IP Network 1644 Infrastructure", RFC 3871, DOI 10.17487/RFC3871, September 1645 2004, . 1647 [RFC6192] Dugal, D., Pignataro, C., and R. Dunn, "Protecting the 1648 Router Control Plane", RFC 6192, DOI 10.17487/RFC6192, 1649 March 2011, . 1651 [RFC7126] Gont, F., Atkinson, R., and C. Pignataro, "Recommendations 1652 on Filtering of IPv4 Packets Containing IPv4 Options", 1653 BCP 186, RFC 7126, DOI 10.17487/RFC7126, February 2014, 1654 . 1656 [RFC7739] Gont, F., "Security Implications of Predictable Fragment 1657 Identification Values", RFC 7739, DOI 10.17487/RFC7739, 1658 February 2016, . 1660 [RFC7872] Gont, F., Linkova, J., Chown, T., and W. Liu, 1661 "Observations on the Dropping of Packets with IPv6 1662 Extension Headers in the Real World", RFC 7872, 1663 DOI 10.17487/RFC7872, June 2016, 1664 . 1666 [RFC9098] Gont, F., Hilliard, N., Doering, G., Kumari, W., Huston, 1667 G., and W. Liu, "Operational Implications of IPv6 Packets 1668 with Extension Headers", RFC 9098, DOI 10.17487/RFC9098, 1669 September 2021, . 1671 Authors' Addresses 1673 Fernando Gont 1674 SI6 Networks 1675 Segurola y Habana 4310, 7mo Piso 1676 Villa Devoto 1677 Ciudad Autonoma de Buenos Aires 1678 Argentina 1679 Email: fgont@si6networks.com 1680 URI: https://www.si6networks.com 1682 Will (Shucheng) Liu 1683 Huawei Technologies 1684 Bantian, Longgang District 1685 Shenzhen 1686 518129 1687 P.R. China 1688 Email: liushucheng@huawei.com