idnits 2.17.1 draft-ietf-opsec-ipv6-eh-filtering-08.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (June 3, 2021) is 1055 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Outdated reference: A later version (-08) exists of draft-ietf-v6ops-ipv6-ehs-packet-drops-06 == Outdated reference: A later version (-12) exists of draft-irtf-pearg-numeric-ids-generation-07 -- Obsolete informational reference (is this intentional?): RFC 2460 (Obsoleted by RFC 8200) Summary: 0 errors (**), 0 flaws (~~), 3 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: December 5, 2021 Huawei Technologies 6 June 3, 2021 8 Recommendations on the Filtering of IPv6 Packets Containing IPv6 9 Extension Headers at Transit Routers 10 draft-ietf-opsec-ipv6-eh-filtering-08 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 December 5, 2021. 39 Copyright Notice 41 Copyright (c) 2021 IETF Trust and the persons identified as the 42 document authors. All rights reserved. 44 This document is subject to BCP 78 and the IETF Trust's Legal 45 Provisions Relating to IETF Documents 46 (https://trustee.ietf.org/license-info) in effect on the date of 47 publication of this document. Please review these documents 48 carefully, as they describe your rights and restrictions with respect 49 to this document. Code Components extracted from this document must 50 include Simplified BSD License text as described in Section 4.e of 51 the Trust Legal Provisions and are provided without warranty as 52 described in the Simplified BSD License. 54 Table of Contents 56 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 57 2. Terminology and Conventions Used in This Document . . . . . . 4 58 2.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 4 59 2.2. Applicability Statement . . . . . . . . . . . . . . . . . 4 60 2.3. Conventions . . . . . . . . . . . . . . . . . . . . . . . 4 61 3. IPv6 Extension Headers . . . . . . . . . . . . . . . . . . . 5 62 3.1. General Discussion . . . . . . . . . . . . . . . . . . . 5 63 3.2. General Security Implications . . . . . . . . . . . . . . 6 64 3.3. Summary of Advice on the Handling of IPv6 Packets with 65 Specific IPv6 Extension Headers . . . . . . . . . . . . . 6 66 3.4. Advice on the Handling of IPv6 Packets with Specific IPv6 67 Extension Headers . . . . . . . . . . . . . . . . . . . . 7 68 3.5. Advice on the Handling of Packets with Unknown IPv6 69 Extension Headers . . . . . . . . . . . . . . . . . . . . 16 70 4. IPv6 Options . . . . . . . . . . . . . . . . . . . . . . . . 17 71 4.1. General Discussion . . . . . . . . . . . . . . . . . . . 17 72 4.2. General Security Implications of IPv6 Options . . . . . . 17 73 4.3. Advice on the Handling of Packets with Specific IPv6 74 Options . . . . . . . . . . . . . . . . . . . . . . . . . 17 75 4.4. Advice on the handling of Packets with Unknown IPv6 76 Options . . . . . . . . . . . . . . . . . . . . . . . . . 30 77 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 30 78 6. Privacy Considerations . . . . . . . . . . . . . . . . . . . 30 79 7. Security Considerations . . . . . . . . . . . . . . . . . . . 30 80 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 31 81 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 31 82 9.1. Normative References . . . . . . . . . . . . . . . . . . 31 83 9.2. Informative References . . . . . . . . . . . . . . . . . 35 84 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 37 86 1. Introduction 88 IPv6 Extension Headers (EHs) allow for the extension of the IPv6 89 protocol, and provide support for core functionality such as IPv6 90 fragmentation. However, common implementation limitations suggest 91 that EHs present a challenge for IPv6 packet routing equipment, 92 particularly when the IPv6 header chain needs to be processed for 93 e.g. enforcing ACLs or implementing other functions 94 [I-D.ietf-v6ops-ipv6-ehs-packet-drops]. 96 Recent studies (see e.g. [RFC7872]) suggest that there is widespread 97 dropping of IPv6 packets that contain IPv6 Extension Headers (EHs). 98 In some cases, such packet drops occur at transit routers. While 99 some operators "officially" drop packets that contain IPv6 EHs, it is 100 possible that some of the measured packet drops be the result of 101 improper configuration defaults, or inappropriate advice in this 102 area. 104 This document analyzes both the general security implications of IPv6 105 EHs, as well as the security implications of specific EH and Option 106 types. It also provides advice on the filtering of IPv6 packets 107 based on the IPv6 EHs and the IPv6 options they contain. Since 108 various protocols may use IPv6 EHs (possibly with IPv6 options), 109 discarding packets based on the IPv6 EHs or IPv6 options they contain 110 can have implications on the proper functioning of such protocols. 111 Thus, this document also attempts to discuss the operational and 112 interoperability implications of such filtering policies. 114 The resulting packet filtering policy typically depends on where in 115 the network such policy is enforced: when the policy is enforced in a 116 transit network, the policy typically follows a "deny-list" approach, 117 where only packets with clear negative implications are dropped. On 118 the other hand, when the policy is enforced closer to the destination 119 systems, the policy typically follows an "accept-list" approach, 120 where only traffic that is expected to be received is allowed. The 121 advice in this document is aimed only at transit routers that may 122 need to enforce a filtering policy based on the EHs and IPv6 options 123 a packet may contain, following a "deny-list" approach, and hence is 124 likely to be much more permissive that a filtering policy to be 125 employed at e.g. the edge of an enterprise network. The advice in 126 this document is meant to improve the current situation of the 127 dropping of packets with IPv6 EHs in the Internet [RFC7872] in such 128 cases where packets are being dropped due to inappropriate or missing 129 guidelines. 131 This document is similar in nature to [RFC7126], which addresses the 132 same problem for the IPv4 case. However, in IPv6, the problem space 133 is compounded by the fact that IPv6 specifies a number of IPv6 EHs, 134 and a number of IPv6 options which may be valid only when included in 135 specific EH types. 137 This document completes and complements the considerations for 138 protecting the control plane from packets containing IP options that 139 can be found in [RFC6192]. 141 Section 2 of this document specifies the terminology and conventions 142 employed throughout this document. Section 3 of this document 143 discusses IPv6 EHs and provides advice in the area of filtering IPv6 144 packets that contain such IPv6 EHs. Section 4 of this document 145 discusses IPv6 options and provides advice in the area of filtering 146 IPv6 packets that contain such options. 148 2. Terminology and Conventions Used in This Document 150 2.1. Terminology 152 The terms "permit" (allow the traffic), "drop" (drop with no 153 notification to sender), and "reject" (drop with appropriate 154 notification to sender) are employed as defined in [RFC3871]. 155 Throughout this document we also employ the term "discard" as a 156 generic term to indicate the act of discarding a packet, irrespective 157 of whether the sender is notified of such drops, and irrespective of 158 whether the specific filtering action is logged. 160 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 161 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 162 "OPTIONAL" in this document are to be interpreted as described in BCP 163 14 [RFC2119] [RFC8174] when, and only when, they appear in all 164 capitals, as shown here. 166 2.2. Applicability Statement 168 This document provides advice on the filtering of IPv6 packets with 169 EHs at transit routers for traffic *not* explicitly destined to them, 170 for cases in which such filtering is deemed as necessary. 172 2.3. Conventions 174 This document assumes that nodes comply with the requirements in 175 [RFC7045]. Namely, 177 o If a forwarding node discards a packet containing a standard IPv6 178 EH, it MUST be the result of a configurable policy and not just 179 the result of a failure to recognize such a header. 181 o The discard policy for each standard type of EH MUST be 182 individually configurable. 184 o The default configuration should allow all standard IPv6 EHs. 186 The advice provided in this document is only meant to guide an 187 operator in configuring forwarding devices, and is *not* to be 188 interpreted as advice regarding default configuration settings for 189 network devices. That is, this document provides advice with respect 190 to operational configurations, but does not change the implementation 191 defaults required by [RFC7045]. 193 We recommend that configuration options are made available to govern 194 the processing of each IPv6 EH type and each IPv6 option type. Such 195 configuration options should include the following possible settings: 197 o Permit this IPv6 EH or IPv6 Option type. 199 o Discard (and log) packets containing this IPv6 EH or option type. 201 o Reject (and log) packets containing this IPv6 EH or option type 202 (where the packet drop is signaled with an ICMPv6 error message). 204 o Rate-limit traffic containing this IPv6 EH or option type. 206 o Ignore this IPv6 EH or option type (as if it was not present) and 207 forward the packet. We note that if a packet carries forwarding 208 information (e.g., in an IPv6 Routing Header) this might be an 209 inappropriate or 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 [I-D.ietf-v6ops-ipv6-ehs-packet-drops] [Cisco-EH] 256 [FW-Benchmark]. 258 Operators are urged to consider the IPv6 EH and IPv6 options handling 259 capabilities of their devices as they make deployment decisions in 260 future. 262 3.3. Summary of Advice on the Handling of IPv6 Packets with Specific 263 IPv6 Extension Headers 265 This section summarizes the advice provided in Section 3.4, providing 266 references to the specific sections in which a detailed analysis can 267 be found. 269 +----------------------------+--------------------------+-----------+ 270 | EH type | Filtering policy | Reference | 271 +----------------------------+--------------------------+-----------+ 272 | IPv6 Hop-by-Hop Options | Drop or Ignore | Section 3 | 273 | (Proto=0) | | .4.1 | 274 +----------------------------+--------------------------+-----------+ 275 | Routing Header for IPv6 | Drop only RHT0 and RHT1. | Section 3 | 276 | (Proto=43) | Permit other RH Types | .4.2 | 277 +----------------------------+--------------------------+-----------+ 278 | Fragment Header for IPv6 | Permit | Section 3 | 279 | (Proto=44) | | .4.3 | 280 +----------------------------+--------------------------+-----------+ 281 | Encapsulating Security | Permit | Section 3 | 282 | Payload (Proto=50) | | .4.4 | 283 +----------------------------+--------------------------+-----------+ 284 | Authentication Header | Permit | Section 3 | 285 | (Proto=51) | | .4.5 | 286 +----------------------------+--------------------------+-----------+ 287 | Destination Options for | Permit | Section 3 | 288 | IPv6 (Proto=60) | | .4.6 | 289 +----------------------------+--------------------------+-----------+ 290 | Mobility Header | Permit | Section 3 | 291 | (Proto=135) | | .4.7 | 292 +----------------------------+--------------------------+-----------+ 293 | Host Identity Protocol | Permit | Section 3 | 294 | (Proto=139) | | .4.8 | 295 +----------------------------+--------------------------+-----------+ 296 | Shim6 Protocol (Proto=140) | Permit | Section 3 | 297 | | | .4.9 | 298 +----------------------------+--------------------------+-----------+ 299 | Use for experimentation | Drop | Section 3 | 300 | and testing (Proto=253 and | | .4.10 | 301 | 254) | | | 302 +----------------------------+--------------------------+-----------+ 304 Table 1: Summary of Advice on the Handling of IPv6 Packets with 305 Specific IPv6 Extension Headers 307 3.4. Advice on the Handling of IPv6 Packets with Specific IPv6 308 Extension Headers 310 3.4.1. IPv6 Hop-by-Hop Options (Protocol Number=0) 312 3.4.1.1. Uses 314 The Hop-by-Hop Options header is used to carry optional information 315 that may be examined by every node along a packet's delivery path. 317 It is expected that nodes will examine the Hop-by-Hop Options header 318 if explicitly configured to do so. 320 NOTE: A previous revision of the IPv6 core specification, [RFC2460], 321 originally required that all nodes examined and processed the Hop-by- 322 Hop Options header. However, even before the publication of 323 [RFC8200] a number of implementations already provided the option of 324 ignoring this header unless explicitly configured to examine it. 326 3.4.1.2. Specification 328 This EH is specified in [RFC8200]. At the time of this writing, the 329 following options have been specified for the Hop-by-Hop Options EH: 331 o Type 0x00: Pad1 [RFC8200] 333 o Type 0x01: PadN [RFC8200] 335 o Type 0x05: Router Alert [RFC2711] 337 o Type 0x07: CALIPSO [RFC5570] 339 o Type 0x08: SMF_DPD [RFC6621] 341 o Type 0x23: RPL Option [RFC9008] 343 o Type 0x26: Quick-Start [RFC4782] 345 o Type 0x4D: (Deprecated) 347 o Type 0x63: RPL Option [RFC6553] 349 o Type 0x6D: MPL Option [RFC7731] 351 o Type 0x8A: Endpoint Identification (Deprecated) 352 [draft-ietf-nimrod-eid] 354 o Type 0xC2: Jumbo Payload [RFC2675] 356 o Type 0xEE: IPv6 DFF Header [RFC6971] 358 o Type 0x1E: RFC3692-style Experiment [RFC4727] 360 o Type 0x3E: RFC3692-style Experiment [RFC4727] 362 o Type 0x5E: RFC3692-style Experiment [RFC4727] 364 o Type 0x7E: RFC3692-style Experiment [RFC4727] 365 o Type 0x9E: RFC3692-style Experiment [RFC4727] 367 o Type 0xBE: RFC3692-style Experiment [RFC4727] 369 o Type 0xDE: RFC3692-style Experiment [RFC4727] 371 o Type 0xFE: RFC3692-style Experiment [RFC4727] 373 3.4.1.3. Specific Security Implications 375 Legacy nodes that process this extension header might be subject to 376 Denial of Service attacks. 378 NOTE: While [RFC8200] has removed this requirement, the deployed base 379 may still reflect the traditional behavior for a while, and hence the 380 potential security problems of this EH are still of concern. 382 3.4.1.4. Operational and Interoperability Impact if Blocked 384 Discarding packets containing a Hop-by-Hop Options EH would break any 385 of the protocols that rely on it for proper functioning. For 386 example, it would break RSVP [RFC2205] and multicast deployments, and 387 would cause IPv6 jumbograms to be discarded. 389 3.4.1.5. Advice 391 Nodes implementing [RFC8200] would already ignore this extension 392 header unless explicitly required to process it. For legacy 393 ([RFC2460]) nodes, the recommended configuration for the processing 394 of these packets depends on the features and capabilities of the 395 underlying platform, the configuration of the platform, and also the 396 deployment environment of the platform. On platforms that allow 397 forwarding of packets with HBH Options on the fast path, we recommend 398 that packets with a HBH Options EH be forwarded as normal. 399 Otherwise, on platforms in which processing of packets with a IPv6 400 HBH Options EH is carried out in the slow path, and an option is 401 provided to rate-limit these packets, we recommend that this option 402 be selected. Finally, when packets containing a HBH Options EH are 403 processed in the slow-path, and the underlying platform does not have 404 any mitigation options available for attacks based on these packets, 405 we recommend that such platforms discard packets containing IPv6 HBH 406 Options EHs. 408 Finally, we note that, for obvious reasons, RPL (Routing Protocol for 409 Low-Power and Lossy Networks) [RFC6550] routers must not discard 410 packets based on the presence of an IPv6 Hop-by-Hop Options EH. 412 3.4.2. Routing Header for IPv6 (Protocol Number=43) 414 3.4.2.1. Uses 416 The Routing header is used by an IPv6 source to list one or more 417 intermediate nodes to be "visited" on the way to a packet's 418 destination. 420 3.4.2.2. Specification 422 This EH is specified in [RFC8200]. [RFC2460] had originally 423 specified the Routing Header Type 0, which was later obsoleted by 424 [RFC5095], and thus removed from [RFC8200]. 426 At the time of this writing, the following Routing Types have been 427 specified: 429 o Type 0: Source Route (DEPRECATED) [RFC2460] [RFC5095] 431 o Type 1: Nimrod (DEPRECATED) 433 o Type 2: Type 2 Routing Header [RFC6275] 435 o Type 3: RPL Source Route Header [RFC6554] 437 o Type 4: Segment Routing Header (SRH) [RFC8754] 439 o Types 5-252: Unassigned 441 o Type 253: RFC3692-style Experiment 1 [RFC4727] 443 o Type 254: RFC3692-style Experiment 2 [RFC4727] 445 o Type 255: Reserved 447 3.4.2.3. Specific Security Implications 449 The security implications of RHT0 have been discussed in detail in 450 [Biondi2007] and [RFC5095]. The security implications of RHT4 (SRH) 451 are discussed in [RFC8754]. 453 3.4.2.4. Operational and Interoperability Impact if Blocked 455 Blocking packets containing a RHT0 or RHT1 has no operational 456 implications, since both have been deprecated. Blocking packets with 457 a RHT4 (SRH) will break Segment Routing (SR) deployments, if the 458 filtering policy is enforced on packets being forwarded within an SR 459 domain. 461 3.4.2.5. Advice 463 Intermediate systems should discard packets containing a RHT0 or 464 RHT1. Other routing header types should be permitted, as required by 465 [RFC7045]. 467 3.4.3. Fragment Header for IPv6 (Protocol Number=44) 469 3.4.3.1. Uses 471 This EH provides the fragmentation functionality for IPv6. 473 3.4.3.2. Specification 475 This EH is specified in [RFC8200]. 477 3.4.3.3. Specific Security Implications 479 The security implications of the Fragment Header range from Denial of 480 Service attacks (e.g. based on flooding a target with IPv6 fragments) 481 to information leakage attacks [RFC7739]. 483 3.4.3.4. Operational and Interoperability Impact if Blocked 485 Blocking packets that contain a Fragment Header will break any 486 protocol that may rely on fragmentation (e.g., the DNS [RFC1034]). 487 However, IP fragmentation is known to introduce fragility to Internet 488 communication [RFC8900]. 490 3.4.3.5. Advice 492 Intermediate systems should permit packets that contain a Fragment 493 Header. 495 3.4.4. Encapsulating Security Payload (Protocol Number=50) 497 3.4.4.1. Uses 499 This EH is employed for the IPsec suite [RFC4303]. 501 3.4.4.2. Specification 503 This EH is specified in [RFC4303]. 505 3.4.4.3. Specific Security Implications 507 Besides the general implications of IPv6 EHs, this EH could be 508 employed to potentially perform a DoS attack at the destination 509 system by wasting CPU resources in validating the contents of the 510 packet. 512 3.4.4.4. Operational and Interoperability Impact if Blocked 514 Discarding packets that employ this EH would break IPsec deployments. 516 3.4.4.5. Advice 518 Intermediate systems should permit packets containing the 519 Encapsulating Security Payload EH. 521 3.4.5. Authentication Header (Protocol Number=51) 523 3.4.5.1. Uses 525 The Authentication Header can be employed for provide authentication 526 services in IPv4 and IPv6. 528 3.4.5.2. Specification 530 This EH is specified in [RFC4302]. 532 3.4.5.3. Specific Security Implications 534 Besides the general implications of IPv6 EHs, this EH could be 535 employed to potentially perform a DoS attack at the destination 536 system by wasting CPU resources in validating the contents of the 537 packet. 539 3.4.5.4. Operational and Interoperability Impact if Blocked 541 Discarding packets that employ this EH would break IPsec deployments. 543 3.4.5.5. Advice 545 Intermediate systems should permit packets containing an 546 Authentication Header. 548 3.4.6. Destination Options for IPv6 (Protocol Number=60) 549 3.4.6.1. Uses 551 The Destination Options header is used to carry optional information 552 that needs be examined only by a packet's destination node(s). 554 3.4.6.2. Specification 556 This EH is specified in [RFC8200]. At the time of this writing, the 557 following options have been specified for this EH: 559 o Type 0x00: Pad1 [RFC8200] 561 o Type 0x01: PadN [RFC8200] 563 o Type 0x04: Tunnel Encapsulation Limit [RFC2473] 565 o Type 0x4D: (Deprecated) 567 o Type 0xC9: Home Address [RFC6275] 569 o Type 0x8A: Endpoint Identification (Deprecated) 570 [draft-ietf-nimrod-eid] 572 o Type 0x8B: ILNP Nonce [RFC6744] 574 o Type 0x8C: Line-Identification Option [RFC6788] 576 o Type 0x1E: RFC3692-style Experiment [RFC4727] 578 o Type 0x3E: RFC3692-style Experiment [RFC4727] 580 o Type 0x5E: RFC3692-style Experiment [RFC4727] 582 o Type 0x7E: RFC3692-style Experiment [RFC4727] 584 o Type 0x9E: RFC3692-style Experiment [RFC4727] 586 o Type 0xBE: RFC3692-style Experiment [RFC4727] 588 o Type 0xDE: RFC3692-style Experiment [RFC4727] 590 o Type 0xFE: RFC3692-style Experiment [RFC4727] 592 3.4.6.3. Specific Security Implications 594 No security implications are known, other than the general 595 implications of IPv6 EHs. For a discussion of possible security 596 implications of specific options specified for the DO header, please 597 see the Section 4.3. 599 3.4.6.4. Operational and Interoperability Impact if Blocked 601 Discarding packets that contain a Destination Options header would 602 break protocols that rely on this EH type for conveying information, 603 including protocols such as ILNP [RFC6740] and Mobile IPv6 [RFC6275], 604 and IPv6 tunnels that employ the Tunnel Encapsulation Limit option. 606 3.4.6.5. Advice 608 Intermediate systems should permit packets that contain a Destination 609 Options Header. 611 3.4.7. Mobility Header (Protocol Number=135) 613 3.4.7.1. Uses 615 The Mobility Header is an EH used by mobile nodes, correspondent 616 nodes, and home agents in all messaging related to the creation and 617 management of bindings in Mobile IPv6. 619 3.4.7.2. Specification 621 This EH is specified in [RFC6275]. 623 3.4.7.3. Specific Security Implications 625 A thorough security assessment of the security implications of the 626 Mobility Header and related mechanisms can be found in Section 15 of 627 [RFC6275]. 629 3.4.7.4. Operational and Interoperability Impact if Blocked 631 Discarding packets containing this EH would break Mobile IPv6. 633 3.4.7.5. Advice 635 Intermediate systems should permit packets containing this EH. 637 3.4.8. Host Identity Protocol (Protocol Number=139) 639 3.4.8.1. Uses 641 This EH is employed with the Host Identity Protocol (HIP), an 642 experimental protocol that allows consenting hosts to securely 643 establish and maintain shared IP-layer state, allowing separation of 644 the identifier and locator roles of IP addresses, thereby enabling 645 continuity of communications across IP address changes. 647 3.4.8.2. Specification 649 This EH is specified in [RFC7401]. 651 3.4.8.3. Specific Security Implications 653 The security implications of the HIP header are discussed in detail 654 in Section 8 of [RFC6275]. 656 3.4.8.4. Operational and Interoperability Impact if Blocked 658 Discarding packets that contain the Host Identity Protocol would 659 break HIP deployments. 661 3.4.8.5. Advice 663 Intermediate systems should permit packets that contain a Host 664 Identity Protocol EH. 666 3.4.9. Shim6 Protocol (Protocol Number=140) 668 3.4.9.1. Uses 670 This EH is employed by the Shim6 [RFC5533] Protocol. 672 3.4.9.2. Specification 674 This EH is specified in [RFC5533]. 676 3.4.9.3. Specific Security Implications 678 The specific security implications are discussed in detail in 679 Section 16 of [RFC5533]. 681 3.4.9.4. Operational and Interoperability Impact if Blocked 683 Discarding packets that contain this EH will break Shim6. 685 3.4.9.5. Advice 687 Intermediate systems should permit packets containing this EH. 689 3.4.10. Use for experimentation and testing (Protocol Numbers=253 and 690 254) 692 3.4.10.1. Uses 694 These IPv6 EHs are employed for performing RFC3692-Style experiments 695 (see [RFC3692] for details). 697 3.4.10.2. Specification 699 These EHs are specified in [RFC3692] and [RFC4727]. 701 3.4.10.3. Specific Security Implications 703 The security implications of these EHs will depend on their specific 704 use. 706 3.4.10.4. Operational and Interoperability Impact if Blocked 708 For obvious reasons, discarding packets that contain these EHs limits 709 the ability to perform legitimate experiments across IPv6 routers. 711 3.4.10.5. Advice 713 Operators should determine according to their own circumstances 714 whether to discard packets containing these EHs. 716 3.5. Advice on the Handling of Packets with Unknown IPv6 Extension 717 Headers 719 We refer to IPv6 EHs that have not been assigned an Internet Protocol 720 Number by IANA (and marked as such) in [IANA-PROTOCOLS] as "unknown 721 IPv6 extension headers" ("unknown IPv6 EHs"). 723 3.5.1. Uses 725 New IPv6 EHs may be specified as part of future extensions to the 726 IPv6 protocol. 728 Since IPv6 EHs and Upper-layer protocols employ the same namespace, 729 it is impossible to tell whether an unknown "Internet Protocol 730 Number" is being employed for an IPv6 EH or an Upper-Layer protocol. 732 3.5.2. Specification 734 The processing of unknown IPv6 EHs is specified in [RFC7045]. 736 3.5.3. Specific Security Implications 738 For obvious reasons, it is impossible to determine specific security 739 implications of unknown IPv6 EHs. 741 3.5.4. Operational and Interoperability Impact if Blocked 743 As noted in [RFC7045], discarding unknown IPv6 EHs may slow down the 744 deployment of new IPv6 EHs and transport protocols. The 745 corresponding IANA registry ([IANA-PROTOCOLS]) should be monitored 746 such that filtering rules are updated as new IPv6 EHs are 747 standardized. 749 We note that since IPv6 EHs and upper-layer protocols share the same 750 numbering space, discarding unknown IPv6 EHs may result in packets 751 encapsulating unknown upper-layer protocols being discarded. 753 3.5.5. Advice 755 Operators should determine according to their own circumstances 756 whether to discard packets containing unknown IPv6 EHs. 758 4. IPv6 Options 760 4.1. General Discussion 762 The following subsections describe specific security implications of 763 different IPv6 options, and provide advice regarding filtering 764 packets that contain such options. 766 4.2. General Security Implications of IPv6 Options 768 The general security implications of IPv6 options are closely related 769 to those discussed in Section 3.2 for IPv6 EHs. Essentially, packets 770 that contain IPv6 options might need to be processed by an IPv6 771 router's general-purpose CPU,and hence could present a DDoS risk to 772 that router's general-purpose CPU (and thus to the router itself). 773 For some architectures, a possible mitigation would be to rate-limit 774 the packets that are to be processed by the general-purpose CPU (see 775 e.g. [Cisco-EH]). 777 4.3. Advice on the Handling of Packets with Specific IPv6 Options 779 The following subsections contain a description of each of the IPv6 780 options that have so far been specified, a summary of the security 781 implications of each of such options, a discussion of possible 782 interoperability implications if packets containing such options are 783 discarded, and specific advice regarding whether packets containing 784 these options should be permitted. 786 4.3.1. Pad1 (Type=0x00) 788 4.3.1.1. Uses 790 This option is used when necessary to align subsequent options and to 791 pad out the containing header to a multiple of 8 octets in length. 793 4.3.1.2. Specification 795 This option is specified in [RFC8200]. 797 4.3.1.3. Specific Security Implications 799 None. 801 4.3.1.4. Operational and Interoperability Impact if Blocked 803 Discarding packets that contain this option would potentially break 804 any protocol that relies on IPv6 options. 806 4.3.1.5. Advice 808 Intermediate systems should not discard packets based on the presence 809 of this option. 811 4.3.2. PadN (Type=0x01) 813 4.3.2.1. Uses 815 This option is used when necessary to align subsequent options and to 816 pad out the containing header to a multiple of 8 octets in length. 818 4.3.2.2. Specification 820 This option is specified in [RFC8200]. 822 4.3.2.3. Specific Security Implications 824 Because of the possible size of this option, it could be leveraged as 825 a large-bandwidth covert channel. 827 4.3.2.4. Operational and Interoperability Impact if Blocked 829 Discarding packets that contain this option would potentially break 830 any protocol that relies on IPv6 options. 832 4.3.2.5. Advice 834 Intermediate systems should not discard IPv6 packets based on the 835 presence of this option. 837 4.3.3. Jumbo Payload (Type=0XC2) 839 4.3.3.1. Uses 841 The Jumbo payload option provides the means of specifying payloads 842 larger than 65535 bytes. 844 4.3.3.2. Specification 846 This option is specified in [RFC2675]. 848 4.3.3.3. Specific Security Implications 850 There are no specific issues arising from this option, except for 851 improper validity checks of the option and associated packet lengths. 853 4.3.3.4. Operational and Interoperability Impact if Blocked 855 Discarding packets based on the presence of this option will cause 856 IPv6 jumbograms to be discarded. 858 4.3.3.5. Advice 860 Intermediate systems should discard packets that contain this option. 861 An operator should permit this option only in specific scenarios in 862 which support for IPv6 jumbograms is desired. 864 4.3.4. RPL Option (Type=0x63) 866 4.3.4.1. Uses 868 The RPL Option provides a mechanism to include routing information 869 with each datagram that an RPL router forwards. 871 4.3.4.2. Specification 873 This option was originally specified in [RFC6553]. It has been 874 deprecated by [RFC9008]. 876 4.3.4.3. Specific Security Implications 878 Those described in [RFC6553]. 880 4.3.4.4. Operational and Interoperability Impact if Blocked 882 This option is meant to be employed within an RPL instance. As a 883 result, discarding packets based on the presence of this option (e.g. 884 at an ISP) will not result in interoperability implications. 886 4.3.4.5. Advice 888 Non-RPL routers should discard packets that contain an RPL option. 890 4.3.5. RPL Option (Type=0x23) 892 4.3.5.1. Uses 894 The RPL Option provides a mechanism to include routing information 895 with each datagram that an RPL router forwards. 897 4.3.5.2. Specification 899 This option is specified in [RFC9008]. 901 4.3.5.3. Specific Security Implications 903 Those described in [RFC9008]. 905 4.3.5.4. Operational and Interoperability Impact if Blocked 907 This option is meant to survive outside of an RPL instance. As a 908 result, discarding packets based on the presence of this option would 909 break some use cases for RPL (see [RFC9008]). 911 4.3.5.5. Advice 913 Intermediate systems should not discard IPv6 packets based on the 914 presence of this option. 916 4.3.6. Tunnel Encapsulation Limit (Type=0x04) 918 4.3.6.1. Uses 920 The Tunnel Encapsulation Limit option can be employed to specify how 921 many further levels of nesting the packet is permitted to undergo. 923 4.3.6.2. Specification 925 This option is specified in [RFC2473]. 927 4.3.6.3. Specific Security Implications 929 Those described in [RFC2473]. 931 4.3.6.4. Operational and Interoperability Impact if Blocked 933 Discarding packets based on the presence of this option could result 934 in tunnel traffic being discarded. 936 4.3.6.5. Advice 938 Intermediate systems should not discard packets based on the presence 939 of this option. 941 4.3.7. Router Alert (Type=0x05) 943 4.3.7.1. Uses 945 The Router Alert option [RFC2711] is employed by a number of 946 protocols, including the Resource reSerVation Protocol (RSVP) 947 [RFC2205], Multicast Listener Discovery (MLD) [RFC2710] [RFC3810], 948 Multicast Router Discovery (MRD) [RFC4286], and General Internet 949 Signaling Transport (GIST) [RFC5971]. Its usage is discussed in 950 detail in [RFC6398]. 952 4.3.7.2. Specification 954 This option is specified in [RFC2711]. 956 4.3.7.3. Specific Security Implications 958 Since this option causes the contents of the packet to be inspected 959 by the handling device, this option could be leveraged for performing 960 DoS attacks. The security implications of the Router Alert option 961 are discussed in detail in [RFC6398]. 963 4.3.7.4. Operational and Interoperability Impact if Blocked 965 Discarding packets that contain this option would break any protocols 966 that rely on them, such as RSVP and multicast deployments. Please 967 see Section 4.3.7.3 for further details. 969 4.3.7.5. Advice 971 Packets containing this option should be permitted in environments 972 where support for RSVP, multicast routing, or similar protocols is 973 desired. 975 4.3.8. Quick-Start (Type=0x26) 977 4.3.8.1. Uses 979 This IP Option is used in the specification of Quick-Start for TCP 980 and IP, which is an experimental mechanism that allows transport 981 protocols, in cooperation with routers, to determine an allowed 982 sending rate at the start and, at times, in the middle of a data 983 transfer (e.g., after an idle period) [RFC4782]. 985 4.3.8.2. Specification 987 This option is specified in [RFC4782], on the "Experimental" track. 989 4.3.8.3. Specific Security Implications 991 Section 9.6 of [RFC4782] notes that Quick-Start is vulnerable to two 992 kinds of attacks: 994 o attacks to increase the routers' processing and state load, and, 996 o attacks with bogus Quick-Start Requests to temporarily tie up 997 available Quick-Start bandwidth, preventing routers from approving 998 Quick-Start Requests from other connections. 1000 We note that if routers in a given environment do not implement and 1001 enable the Quick-Start mechanism, only the general security 1002 implications of IP options (discussed in Section 4.2) would apply. 1004 4.3.8.4. Operational and Interoperability Impact if Blocked 1006 The Quick-Start functionality would be disabled, and additional 1007 delays in TCP's connection establishment (for example) could be 1008 introduced. (Please see Section 4.7.2 of [RFC4782].) We note, 1009 however, that Quick-Start has been proposed as a mechanism that could 1010 be of use in controlled environments, and not as a mechanism that 1011 would be intended or appropriate for ubiquitous deployment in the 1012 global Internet [RFC4782]. 1014 4.3.8.5. Advice 1016 Intermediate systems should not discard IPv6 packets based on the 1017 presence of this option. 1019 4.3.9. CALIPSO (Type=0x07) 1021 4.3.9.1. Uses 1023 This option is used for encoding explicit packet Sensitivity Labels 1024 on IPv6 packets. It is intended for use only within Multi-Level 1025 Secure (MLS) networking environments that are both trusted and 1026 trustworthy. 1028 4.3.9.2. Specification 1030 This option is specified in [RFC5570]. 1032 4.3.9.3. Specific Security Implications 1034 Presence of this option in a packet does not by itself create any 1035 specific new threat. Packets with this option ought not normally be 1036 seen on the global public Internet. 1038 4.3.9.4. Operational and Interoperability Impact if Blocked 1040 If packets with this option are discarded or if the option is 1041 stripped from the packet during transmission from source to 1042 destination, then the packet itself is likely to be discarded by the 1043 receiver because it is not properly labeled. In some cases, the 1044 receiver might receive the packet but associate an incorrect 1045 sensitivity label with the received data from the packet whose 1046 CALIPSO was stripped by an intermediate router or firewall. 1047 Associating an incorrect sensitivity label can cause the received 1048 information either to be handled as more sensitive than it really is 1049 ("upgrading") or as less sensitive than it really is ("downgrading"), 1050 either of which is problematic. 1052 4.3.9.5. Advice 1054 Recommendations for handling the CALIPSO option depend on the 1055 deployment environment, rather than whether an intermediate system 1056 happens to be deployed as a transit device (e.g., IPv6 transit 1057 router). 1059 Explicit configuration is the only method via which an intermediate 1060 system can know whether or not that particular intermediate system 1061 has been deployed within a Multi-Level Secure (MLS) environment. In 1062 many cases, ordinary commercial intermediate systems (e.g., IPv6 1063 routers and firewalls) are the majority of the deployed intermediate 1064 systems inside an MLS network environment. 1066 For Intermediate systems that DO NOT implement RFC-5570, there should 1067 be a configuration option to EITHER (a) drop packets containing the 1068 CALIPSO option OR (b) to ignore the presence of the CALIPSO option 1069 and forward the packets normally. In non-MLS environments, such 1070 intermediate systems should have this configuration option set to (a) 1071 above. In MLS environments, such intermediate systems should have 1072 this option set to (b) above. The default setting for this 1073 configuration option should be set to (a) above, because MLS 1074 environments are much less common than non-MLS environments. 1076 For Intermediate systems that DO implement RFC-5570, there should be 1077 configuration options (a) and (b) from the preceding paragraph and 1078 also a third configuration option (c) to process packets containing a 1079 CALIPSO option as per RFC-5570. When deployed in non-MLS 1080 environments, such intermediate systems should have this 1081 configuration option set to (a) above. When deployed in MLS 1082 environments, such intermediate systems should have this set to (c). 1083 The default setting for this configuration option MAY be set to (a) 1084 above, because MLS environments are much less common than non-MLS 1085 environments. 1087 4.3.10. SMF_DPD (Type=0x08) 1089 4.3.10.1. Uses 1091 This option is employed in the (experimental) Simplified Multicast 1092 Forwarding (SMF) for unique packet identification for IPv6 I-DPD, and 1093 as a mechanism to guarantee non-collision of hash values for 1094 different packets when H-DPD is used. 1096 4.3.10.2. Specification 1098 This option is specified in [RFC6621]. 1100 4.3.10.3. Specific Security Implications 1102 None. The use of transient numeric identifiers is subject to the 1103 security and privacy considerations discussed in 1104 [I-D.irtf-pearg-numeric-ids-generation]. 1106 4.3.10.4. Operational and Interoperability Impact if Blocked 1108 Dropping packets containing this option within a MANET domain would 1109 break SMF. However, dropping such packets at the border of such 1110 domain would have no negative impact. 1112 4.3.10.5. Advice 1114 Intermediate systems that are not within a MANET domain should 1115 discard packets that contain this option. 1117 4.3.11. Home Address (Type=0xC9) 1119 4.3.11.1. Uses 1121 The Home Address option is used by a Mobile IPv6 node while away from 1122 home, to inform the recipient of the mobile node's home address. 1124 4.3.11.2. Specification 1126 This option is specified in [RFC6275]. 1128 4.3.11.3. Specific Security Implications 1130 No (known) additional security implications than those described in 1131 [RFC6275]. 1133 4.3.11.4. Operational and Interoperability Impact if Blocked 1135 Discarding IPv6 packets based on the presence of this option will 1136 break Mobile IPv6. 1138 4.3.11.5. Advice 1140 Intermediate systems should not discard IPv6 packets based on the 1141 presence of this option. 1143 4.3.12. Endpoint Identification (Type=0x8A) 1145 4.3.12.1. Uses 1147 The Endpoint Identification option was meant to be used with the 1148 Nimrod routing architecture [NIMROD-DOC], but has never seen 1149 widespread deployment. 1151 4.3.12.2. Specification 1153 This option is specified in [NIMROD-DOC]. 1155 4.3.12.3. Specific Security Implications 1157 Undetermined. 1159 4.3.12.4. Operational and Interoperability Impact if Blocked 1161 None. 1163 4.3.12.5. Advice 1165 Intermediate systems should discard packets that contain this option. 1167 4.3.13. ILNP Nonce (Type=0x8B) 1169 4.3.13.1. Uses 1171 This option is employed by Identifier-Locator Network Protocol for 1172 IPv6 (ILNPv6) for providing protection against off-path attacks for 1173 packets when ILNPv6 is in use, and as a signal during initial 1174 network-layer session creation that ILNPv6 is proposed for use with 1175 this network-layer session, rather than classic IPv6. 1177 4.3.13.2. Specification 1179 This option is specified in [RFC6744]. 1181 4.3.13.3. Specific Security Implications 1183 Those described in [RFC6744]. 1185 4.3.13.4. Operational and Interoperability Impact if Blocked 1187 Discarding packets that contain this option will break INLPv6 1188 deployments. 1190 4.3.13.5. Advice 1192 Intermediate systems should not discard packets based on the presence 1193 of this option. 1195 4.3.14. Line-Identification Option (Type=0x8C) 1197 4.3.14.1. Uses 1199 This option is used by an Edge Router to identify the subscriber 1200 premises in scenarios where several subscriber premises may be 1201 logically connected to the same interface of an Edge Router. 1203 4.3.14.2. Specification 1205 This option is specified in [RFC6788]. 1207 4.3.14.3. Specific Security Implications 1209 Those described in [RFC6788]. 1211 4.3.14.4. Operational and Interoperability Impact if Blocked 1213 Since this option is meant to be employed in Router Solicitation 1214 messages, discarding packets based on the presence of this option at 1215 intermediate systems will result in no interoperability implications. 1217 4.3.14.5. Advice 1219 Intermediate devices should discard packets that contain this option. 1221 4.3.15. Deprecated (Type=0x4D) 1223 4.3.15.1. Uses 1225 No information has been found about this option type. 1227 4.3.15.2. Specification 1229 No information has been found about this option type. 1231 4.3.15.3. Specific Security Implications 1233 No information has been found about this option type, and hence it 1234 has been impossible to perform the corresponding security assessment. 1236 4.3.15.4. Operational and Interoperability Impact if Blocked 1238 Unknown. 1240 4.3.15.5. Advice 1242 Intermediate systems should discard packets that contain this option. 1244 4.3.16. MPL Option (Type=0x6D) 1246 4.3.16.1. Uses 1248 This option is used with the Multicast Protocol for Low power and 1249 Lossy Networks (MPL), that provides IPv6 multicast forwarding in 1250 constrained networks. 1252 4.3.16.2. Specification 1254 This option is specified in [RFC7731], and is meant to be included 1255 only in Hop-by-Hop Option headers. 1257 4.3.16.3. Specific Security Implications 1259 Those described in [RFC7731]. 1261 4.3.16.4. Operational and Interoperability Impact if Blocked 1263 Dropping packets that contain an MPL option within an MPL network 1264 would break the Multicast Protocol for Low power and Lossy Networks 1265 (MPL). However, dropping such packets at the border of such networks 1266 will have no negative impact. 1268 4.3.16.5. Advice 1270 Intermediate systems should not discard packets based on the presence 1271 of this option. However, since this option has been specified for 1272 the Hop-by-Hop Options, such systems should consider the discussion 1273 in Section 3.4.1. 1275 4.3.17. IP_DFF (Type=0xEE) 1277 4.3.17.1. Uses 1279 This option is employed with the (Experimental) Depth-First 1280 Forwarding (DFF) in Unreliable Networks. 1282 4.3.17.2. Specification 1284 This option is specified in [RFC6971]. 1286 4.3.17.3. Specific Security Implications 1288 Those specified in [RFC6971]. 1290 4.3.17.4. Operational and Interoperability Impact if Blocked 1292 Dropping packets containing this option within a routing domain that 1293 is running DFF would break DFF. However, dropping such packets at 1294 the border of such domains will have no security implications. 1296 4.3.17.5. Advice 1298 Intermediate systems that do not operate within a routing domain that 1299 is running DFF should discard packets containing this option. 1301 4.3.18. RFC3692-style Experiment (Types = 0x1E, 0x3E, 0x5E, 0x7E, 0x9E, 1302 0xBE, 0xDE, 0xFE) 1304 4.3.18.1. Uses 1306 These options can be employed for performing RFC3692-style 1307 experiments. It is only appropriate to use these values in 1308 explicitly configured experiments; they must not be shipped as 1309 defaults in implementations. 1311 4.3.18.2. Specification 1313 Specified in RFC 4727 [RFC4727] in the context of RFC3692-style 1314 experiments. 1316 4.3.18.3. Specific Security Implications 1318 The specific security implications will depend on the specific use of 1319 these options. 1321 4.3.18.4. Operational and Interoperability Impact if Blocked 1323 For obvious reasons, discarding packets that contain these options 1324 limits the ability to perform legitimate experiments across IPv6 1325 routers. 1327 4.3.18.5. Advice 1329 Operators should determine according to their own circumstances 1330 whether to discard packets containing these IPv6 options. 1332 4.4. Advice on the handling of Packets with Unknown IPv6 Options 1334 We refer to IPv6 options that have not been assigned an IPv6 option 1335 type in the corresponding registry ([IANA-IPV6-PARAM]) as "unknown 1336 IPv6 options". 1338 4.4.1. Uses 1340 New IPv6 options may be specified as part of future protocol work. 1342 4.4.2. Specification 1344 The processing of unknown IPv6 options is specified in [RFC8200]. 1346 4.4.3. Specific Security Implications 1348 For obvious reasons, it is impossible to determine specific security 1349 implications of unknown IPv6 options. 1351 4.4.4. Operational and Interoperability Impact if Blocked 1353 Discarding unknown IPv6 options may slow down the deployment of new 1354 IPv6 options. As noted in [draft-gont-6man-ipv6-opt-transmit], the 1355 corresponding IANA registry ([IANA-IPV6-PARAM] should be monitored 1356 such that IPv6 option filtering rules are updated as new IPv6 options 1357 are standardized. 1359 4.4.5. Advice 1361 Operators should determine according to their own circumstances 1362 whether to discard packets containing unknown IPv6 options. 1364 5. IANA Considerations 1366 This document has no actions for IANA. 1368 6. Privacy Considerations 1370 There are no privacy considerations associated with this document. 1372 7. Security Considerations 1374 This document provides advice on the filtering of IPv6 packets that 1375 contain IPv6 EHs (and possibly IPv6 options) at IPv6 transit routers. 1376 It is meant to improve the current situation of widespread dropping 1377 of such IPv6 packets in those cases where the drops result from 1378 improper configuration defaults, or inappropriate advice in this 1379 area. 1381 8. Acknowledgements 1383 The authors would like to thank Ron Bonica for his work on earlier 1384 versions of this document. 1386 The authors of this document would like to thank (in alphabetical 1387 order) Mikael Abrahamsson, Brian Carpenter, Darren Dukes, David 1388 Farmer, Mike Heard, Bob Hinden, Christian Huitema, Jen Linkova, 1389 Carlos Pignataro, Maria Ines Robles, Donald Smith, Pascal Thubert, 1390 Ole Troan, Gunter Van De Velde, and Eric Vyncke, for providing 1391 valuable comments on earlier versions of this document. 1393 This document borrows some text and analysis from [RFC7126], authored 1394 by Fernando Gont, Randall Atkinson, and Carlos Pignataro. 1396 The authors would like to thank Eric Vyncke for his guidance during 1397 the publication process of this document. 1399 Fernando would also like to thank Brian Carpenter and Ran Atkinson 1400 who, over the years, have answered many questions and provided 1401 valuable comments that have benefited his protocol-related work 1402 (including the present document). 1404 9. References 1406 9.1. Normative References 1408 [RFC1034] Mockapetris, P., "Domain names - concepts and facilities", 1409 STD 13, RFC 1034, DOI 10.17487/RFC1034, November 1987, 1410 . 1412 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1413 Requirement Levels", BCP 14, RFC 2119, 1414 DOI 10.17487/RFC2119, March 1997, 1415 . 1417 [RFC2205] Braden, R., Ed., Zhang, L., Berson, S., Herzog, S., and S. 1418 Jamin, "Resource ReSerVation Protocol (RSVP) -- Version 1 1419 Functional Specification", RFC 2205, DOI 10.17487/RFC2205, 1420 September 1997, . 1422 [RFC2473] Conta, A. and S. Deering, "Generic Packet Tunneling in 1423 IPv6 Specification", RFC 2473, DOI 10.17487/RFC2473, 1424 December 1998, . 1426 [RFC2675] Borman, D., Deering, S., and R. Hinden, "IPv6 Jumbograms", 1427 RFC 2675, DOI 10.17487/RFC2675, August 1999, 1428 . 1430 [RFC2710] Deering, S., Fenner, W., and B. Haberman, "Multicast 1431 Listener Discovery (MLD) for IPv6", RFC 2710, 1432 DOI 10.17487/RFC2710, October 1999, 1433 . 1435 [RFC2711] Partridge, C. and A. Jackson, "IPv6 Router Alert Option", 1436 RFC 2711, DOI 10.17487/RFC2711, October 1999, 1437 . 1439 [RFC3692] Narten, T., "Assigning Experimental and Testing Numbers 1440 Considered Useful", BCP 82, RFC 3692, 1441 DOI 10.17487/RFC3692, January 2004, 1442 . 1444 [RFC3810] Vida, R., Ed. and L. Costa, Ed., "Multicast Listener 1445 Discovery Version 2 (MLDv2) for IPv6", RFC 3810, 1446 DOI 10.17487/RFC3810, June 2004, 1447 . 1449 [RFC4286] Haberman, B. and J. Martin, "Multicast Router Discovery", 1450 RFC 4286, DOI 10.17487/RFC4286, December 2005, 1451 . 1453 [RFC4302] Kent, S., "IP Authentication Header", RFC 4302, 1454 DOI 10.17487/RFC4302, December 2005, 1455 . 1457 [RFC4303] Kent, S., "IP Encapsulating Security Payload (ESP)", 1458 RFC 4303, DOI 10.17487/RFC4303, December 2005, 1459 . 1461 [RFC4727] Fenner, B., "Experimental Values In IPv4, IPv6, ICMPv4, 1462 ICMPv6, UDP, and TCP Headers", RFC 4727, 1463 DOI 10.17487/RFC4727, November 2006, 1464 . 1466 [RFC4782] Floyd, S., Allman, M., Jain, A., and P. Sarolahti, "Quick- 1467 Start for TCP and IP", RFC 4782, DOI 10.17487/RFC4782, 1468 January 2007, . 1470 [RFC5095] Abley, J., Savola, P., and G. Neville-Neil, "Deprecation 1471 of Type 0 Routing Headers in IPv6", RFC 5095, 1472 DOI 10.17487/RFC5095, December 2007, 1473 . 1475 [RFC5533] Nordmark, E. and M. Bagnulo, "Shim6: Level 3 Multihoming 1476 Shim Protocol for IPv6", RFC 5533, DOI 10.17487/RFC5533, 1477 June 2009, . 1479 [RFC5570] StJohns, M., Atkinson, R., and G. Thomas, "Common 1480 Architecture Label IPv6 Security Option (CALIPSO)", 1481 RFC 5570, DOI 10.17487/RFC5570, July 2009, 1482 . 1484 [RFC5971] Schulzrinne, H. and R. Hancock, "GIST: General Internet 1485 Signalling Transport", RFC 5971, DOI 10.17487/RFC5971, 1486 October 2010, . 1488 [RFC6275] Perkins, C., Ed., Johnson, D., and J. Arkko, "Mobility 1489 Support in IPv6", RFC 6275, DOI 10.17487/RFC6275, July 1490 2011, . 1492 [RFC6398] Le Faucheur, F., Ed., "IP Router Alert Considerations and 1493 Usage", BCP 168, RFC 6398, DOI 10.17487/RFC6398, October 1494 2011, . 1496 [RFC6550] Winter, T., Ed., Thubert, P., Ed., Brandt, A., Hui, J., 1497 Kelsey, R., Levis, P., Pister, K., Struik, R., Vasseur, 1498 JP., and R. Alexander, "RPL: IPv6 Routing Protocol for 1499 Low-Power and Lossy Networks", RFC 6550, 1500 DOI 10.17487/RFC6550, March 2012, 1501 . 1503 [RFC6553] Hui, J. and JP. Vasseur, "The Routing Protocol for Low- 1504 Power and Lossy Networks (RPL) Option for Carrying RPL 1505 Information in Data-Plane Datagrams", RFC 6553, 1506 DOI 10.17487/RFC6553, March 2012, 1507 . 1509 [RFC6554] Hui, J., Vasseur, JP., Culler, D., and V. Manral, "An IPv6 1510 Routing Header for Source Routes with the Routing Protocol 1511 for Low-Power and Lossy Networks (RPL)", RFC 6554, 1512 DOI 10.17487/RFC6554, March 2012, 1513 . 1515 [RFC6621] Macker, J., Ed., "Simplified Multicast Forwarding", 1516 RFC 6621, DOI 10.17487/RFC6621, May 2012, 1517 . 1519 [RFC6740] Atkinson, RJ. and SN. Bhatti, "Identifier-Locator Network 1520 Protocol (ILNP) Architectural Description", RFC 6740, 1521 DOI 10.17487/RFC6740, November 2012, 1522 . 1524 [RFC6744] Atkinson, RJ. and SN. Bhatti, "IPv6 Nonce Destination 1525 Option for the Identifier-Locator Network Protocol for 1526 IPv6 (ILNPv6)", RFC 6744, DOI 10.17487/RFC6744, November 1527 2012, . 1529 [RFC6788] Krishnan, S., Kavanagh, A., Varga, B., Ooghe, S., and E. 1530 Nordmark, "The Line-Identification Option", RFC 6788, 1531 DOI 10.17487/RFC6788, November 2012, 1532 . 1534 [RFC6971] Herberg, U., Ed., Cardenas, A., Iwao, T., Dow, M., and S. 1535 Cespedes, "Depth-First Forwarding (DFF) in Unreliable 1536 Networks", RFC 6971, DOI 10.17487/RFC6971, June 2013, 1537 . 1539 [RFC7045] Carpenter, B. and S. Jiang, "Transmission and Processing 1540 of IPv6 Extension Headers", RFC 7045, 1541 DOI 10.17487/RFC7045, December 2013, 1542 . 1544 [RFC7112] Gont, F., Manral, V., and R. Bonica, "Implications of 1545 Oversized IPv6 Header Chains", RFC 7112, 1546 DOI 10.17487/RFC7112, January 2014, 1547 . 1549 [RFC7401] Moskowitz, R., Ed., Heer, T., Jokela, P., and T. 1550 Henderson, "Host Identity Protocol Version 2 (HIPv2)", 1551 RFC 7401, DOI 10.17487/RFC7401, April 2015, 1552 . 1554 [RFC7731] Hui, J. and R. Kelsey, "Multicast Protocol for Low-Power 1555 and Lossy Networks (MPL)", RFC 7731, DOI 10.17487/RFC7731, 1556 February 2016, . 1558 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 1559 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 1560 May 2017, . 1562 [RFC8200] Deering, S. and R. Hinden, "Internet Protocol, Version 6 1563 (IPv6) Specification", STD 86, RFC 8200, 1564 DOI 10.17487/RFC8200, July 2017, 1565 . 1567 [RFC8754] Filsfils, C., Ed., Dukes, D., Ed., Previdi, S., Leddy, J., 1568 Matsushima, S., and D. Voyer, "IPv6 Segment Routing Header 1569 (SRH)", RFC 8754, DOI 10.17487/RFC8754, March 2020, 1570 . 1572 [RFC8900] Bonica, R., Baker, F., Huston, G., Hinden, R., Troan, O., 1573 and F. Gont, "IP Fragmentation Considered Fragile", 1574 BCP 230, RFC 8900, DOI 10.17487/RFC8900, September 2020, 1575 . 1577 [RFC9008] Robles, M., Richardson, M., and P. Thubert, "Using RPI 1578 Option Type, Routing Header for Source Routes, and IPv6- 1579 in-IPv6 Encapsulation in the RPL Data Plane", RFC 9008, 1580 DOI 10.17487/RFC9008, April 2021, 1581 . 1583 9.2. Informative References 1585 [Biondi2007] 1586 Biondi, P. and A. Ebalard, "IPv6 Routing Header Security", 1587 CanSecWest 2007 Security Conference, 2007, 1588 . 1590 [Cisco-EH] 1591 Cisco Systems, "IPv6 Extension Headers Review and 1592 Considerations", Whitepaper. October 2006, 1593 . 1596 [draft-gont-6man-ipv6-opt-transmit] 1597 Gont, F., Liu, W., and R. Bonica, "Transmission and 1598 Processing of IPv6 Options", IETF Internet Draft, work in 1599 progress, August 2014. 1601 [draft-ietf-nimrod-eid] 1602 Lynn, C., "Endpoint Identifier Destination Option", IETF 1603 Internet Draft, draft-ietf-nimrod-eid-00.txt, November 1604 1995. 1606 [FW-Benchmark] 1607 Zack, E., "Firewall Security Assessment and Benchmarking 1608 IPv6 Firewall Load Tests", IPv6 Hackers Meeting #1, 1609 Berlin, Germany. June 30, 2013, 1610 . 1614 [I-D.ietf-v6ops-ipv6-ehs-packet-drops] 1615 Gont, F., Hilliard, N., Doering, G., Kumari, W., Huston, 1616 G., and W. (. Liu, "Operational Implications of IPv6 1617 Packets with Extension Headers", draft-ietf-v6ops-ipv6- 1618 ehs-packet-drops-06 (work in progress), April 2021. 1620 [I-D.irtf-pearg-numeric-ids-generation] 1621 Gont, F. and I. Arce, "On the Generation of Transient 1622 Numeric Identifiers", draft-irtf-pearg-numeric-ids- 1623 generation-07 (work in progress), February 2021. 1625 [IANA-IPV6-PARAM] 1626 Internet Assigned Numbers Authority, "Internet Protocol 1627 Version 6 (IPv6) Parameters", December 2013, 1628 . 1631 [IANA-PROTOCOLS] 1632 Internet Assigned Numbers Authority, "Protocol Numbers", 1633 2014, . 1636 [NIMROD-DOC] 1637 Nimrod Documentation Page, 1638 "http://ana-3.lcs.mit.edu/~jnc/nimrod/". 1640 [RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6 1641 (IPv6) Specification", RFC 2460, DOI 10.17487/RFC2460, 1642 December 1998, . 1644 [RFC3871] Jones, G., Ed., "Operational Security Requirements for 1645 Large Internet Service Provider (ISP) IP Network 1646 Infrastructure", RFC 3871, DOI 10.17487/RFC3871, September 1647 2004, . 1649 [RFC6192] Dugal, D., Pignataro, C., and R. Dunn, "Protecting the 1650 Router Control Plane", RFC 6192, DOI 10.17487/RFC6192, 1651 March 2011, . 1653 [RFC7126] Gont, F., Atkinson, R., and C. Pignataro, "Recommendations 1654 on Filtering of IPv4 Packets Containing IPv4 Options", 1655 BCP 186, RFC 7126, DOI 10.17487/RFC7126, February 2014, 1656 . 1658 [RFC7739] Gont, F., "Security Implications of Predictable Fragment 1659 Identification Values", RFC 7739, DOI 10.17487/RFC7739, 1660 February 2016, . 1662 [RFC7872] Gont, F., Linkova, J., Chown, T., and W. Liu, 1663 "Observations on the Dropping of Packets with IPv6 1664 Extension Headers in the Real World", RFC 7872, 1665 DOI 10.17487/RFC7872, June 2016, 1666 . 1668 Authors' Addresses 1670 Fernando Gont 1671 SI6 Networks 1672 Segurola y Habana 4310, 7mo Piso 1673 Villa Devoto, Ciudad Autonoma de Buenos Aires 1674 Argentina 1676 Email: fgont@si6networks.com 1677 URI: https://www.si6networks.com 1679 Will (Shucheng) Liu 1680 Huawei Technologies 1681 Bantian, Longgang District 1682 Shenzhen 518129 1683 P.R. China 1685 Email: liushucheng@huawei.com