idnits 2.17.1 draft-ietf-opsec-ipv6-eh-filtering-06.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 (July 2, 2018) is 2124 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Unused Reference: 'RFC4304' is defined on line 1412, but no explicit reference was found in the text == Unused Reference: 'I-D.ietf-6man-hbh-header-handling' is defined on line 1554, but no explicit reference was found in the text == Outdated reference: A later version (-44) exists of draft-ietf-roll-useofrplinfo-23 ** Obsolete normative reference: RFC 2460 (Obsoleted by RFC 8200) ** Obsolete normative reference: RFC 5201 (Obsoleted by RFC 7401) == Outdated reference: A later version (-03) exists of draft-gont-predictable-numeric-ids-02 == Outdated reference: A later version (-04) exists of draft-gont-v6ops-ipv6-ehs-packet-drops-03 Summary: 2 errors (**), 0 flaws (~~), 6 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 opsec F. Gont 3 Internet-Draft UTN-FRH / SI6 Networks 4 Intended status: Informational W. Liu 5 Expires: January 3, 2019 Huawei Technologies 6 July 2, 2018 8 Recommendations on the Filtering of IPv6 Packets Containing IPv6 9 Extension Headers 10 draft-ietf-opsec-ipv6-eh-filtering-06 12 Abstract 14 It is common operator practice to mitigate security risks by 15 enforcing appropriate packet filtering. This document analyzes both 16 the general security implications of IPv6 Extension Headers and the 17 specific security implications of each Extension Header and Option 18 type. Additionally, it discusses the operational and 19 interoperability implications of discarding packets based on the IPv6 20 Extension Headers and IPv6 options they contain. Finally, it 21 provides advice on the filtering of such IPv6 packets at transit 22 routers for traffic *not* directed to them, for those cases in which 23 such filtering is deemed as necessary. 25 Status of This Memo 27 This Internet-Draft is submitted in full conformance with the 28 provisions of BCP 78 and BCP 79. 30 Internet-Drafts are working documents of the Internet Engineering 31 Task Force (IETF). Note that other groups may also distribute 32 working documents as Internet-Drafts. The list of current Internet- 33 Drafts is at https://datatracker.ietf.org/drafts/current/. 35 Internet-Drafts are draft documents valid for a maximum of six months 36 and may be updated, replaced, or obsoleted by other documents at any 37 time. It is inappropriate to use Internet-Drafts as reference 38 material or to cite them other than as "work in progress." 40 This Internet-Draft will expire on January 3, 2019. 42 Copyright Notice 44 Copyright (c) 2018 IETF Trust and the persons identified as the 45 document authors. All rights reserved. 47 This document is subject to BCP 78 and the IETF Trust's Legal 48 Provisions Relating to IETF Documents 49 (https://trustee.ietf.org/license-info) in effect on the date of 50 publication of this document. Please review these documents 51 carefully, as they describe your rights and restrictions with respect 52 to this document. Code Components extracted from this document must 53 include Simplified BSD License text as described in Section 4.e of 54 the Trust Legal Provisions and are provided without warranty as 55 described in the Simplified BSD License. 57 Table of Contents 59 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 60 2. Terminology and Conventions Used in This Document . . . . . . 3 61 2.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 4 62 2.2. Applicability Statement . . . . . . . . . . . . . . . . . 4 63 2.3. Conventions . . . . . . . . . . . . . . . . . . . . . . . 4 64 3. IPv6 Extension Headers . . . . . . . . . . . . . . . . . . . 5 65 3.1. General Discussion . . . . . . . . . . . . . . . . . . . 5 66 3.2. General Security Implications . . . . . . . . . . . . . . 6 67 3.3. Summary of Advice on the Handling of IPv6 Packets with 68 Specific IPv6 Extension Headers . . . . . . . . . . . . . 6 69 3.4. Advice on the Handling of IPv6 Packets with Specific IPv6 70 Extension Headers . . . . . . . . . . . . . . . . . . . . 7 71 3.5. Advice on the Handling of Packets with Unknown IPv6 72 Extension Headers . . . . . . . . . . . . . . . . . . . . 16 73 4. IPv6 Options . . . . . . . . . . . . . . . . . . . . . . . . 17 74 4.1. General Discussion . . . . . . . . . . . . . . . . . . . 17 75 4.2. General Security Implications of IPv6 Options . . . . . . 17 76 4.3. Advice on the Handling of Packets with Specific IPv6 77 Options . . . . . . . . . . . . . . . . . . . . . . . . . 17 78 4.4. Advice on the handling of Packets with Unknown IPv6 79 Options . . . . . . . . . . . . . . . . . . . . . . . . . 29 80 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 29 81 6. Security Considerations . . . . . . . . . . . . . . . . . . . 30 82 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 30 83 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 30 84 8.1. Normative References . . . . . . . . . . . . . . . . . . 30 85 8.2. Informative References . . . . . . . . . . . . . . . . . 34 86 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 35 88 1. Introduction 90 Recent studies (see e.g. [RFC7872]) suggest that there is widespread 91 dropping of IPv6 packets that contain IPv6 Extension Headers (EHs). 92 In some cases, such packet drops occur at transit routers. While 93 some operators "officially" drop packets that contain IPv6 EHs, it is 94 possible that some of the measured packet drops be the result of 95 improper configuration defaults, or inappropriate advice in this 96 area. 98 This document analyzes both the general security implications of IPv6 99 EHs and the specific security implications of each EH and Option 100 type, and provides advice on the filtering of IPv6 packets based on 101 the IPv6 EHs and the IPv6 options they contain. Since various 102 protocols may use IPv6 EHs (possibly with IPv6 options), discarding 103 packets based on the IPv6 EHs or IPv6 options they contain may have 104 implications on the proper functioning of such protocols. Thus, this 105 document also attempts to discuss the operational and 106 interoperability implications of such filtering policies. 108 The filtering policy typically depends on where in the network such 109 policy is enforced: when the policy is enforced in a transit network, 110 the policy typically follows a "black-list" approach, where only 111 packets with clear negative implications are dropped. On the other 112 hand, when the policy is enforced closer to the destination systems, 113 the policy typically follows a "white-list" approach, where only 114 traffic that is expected to be received is allowed. The advice in 115 this document is aimed only at transit routers that may need to 116 enforce a filtering policy based on the EHs and IPv6 options a packet 117 may contain, following a "black-list" approach, and hence is likely 118 to be much more permissive that a filtering policy to be employed 119 e.g. at the edge of an enterprise network. The advice in this 120 document is meant to improve the current situation of the dropping of 121 packets with IPv6 EHs in the Internet [RFC7872]. 123 This document is similar in nature to [RFC7126], which addresses the 124 same problem for the IPv4 case. However, in IPv6, the problem space 125 is compounded by the fact that IPv6 specifies a number of IPv6 EHs, 126 and a number of IPv6 options which may be valid only when included in 127 specific EH types. 129 This document completes and complements the considerations for 130 protecting the control plane from packets containing IP options that 131 can be found in [RFC6192]. 133 Section 2 of this document specifies the terminology and conventions 134 employed throughout this document. Section 3 of this document 135 discusses IPv6 EHs and provides advice in the area of filtering IPv6 136 packets that contain such IPv6 EHs. Section 4 of this document 137 discusses IPv6 options and provides advice in the area of filtering 138 IPv6 packets that contain such options. 140 2. Terminology and Conventions Used in This Document 141 2.1. Terminology 143 The terms "fast path", "slow path", and associated relative terms 144 ("faster path" and "slower path") are loosely defined as in Section 2 145 of [RFC6398]. 147 The terms "permit" (allow the traffic), "drop" (drop with no 148 notification to sender), and "reject" (drop with appropriate 149 notification to sender) are employed as defined in [RFC3871]. 150 Throughout this document we also employ the term "discard" as a 151 generic term to indicate the act of discarding a packet, irrespective 152 of whether the sender is notified of such drops, and irrespective of 153 whether the specific filtering action is logged. 155 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 156 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 157 document are to be interpreted as described in [RFC2119]. 159 2.2. Applicability Statement 161 This document provides advice on the filtering of IPv6 packets with 162 EHs at transit routers for traffic *not* explicitly destined to such 163 transit routers, for those cases in which such filtering is deemed as 164 necessary. 166 2.3. Conventions 168 This document assumes that nodes comply with the requirements in 169 [RFC7045]. Namely (from [RFC7045]), 171 o If a forwarding node discards a packet containing a standard IPv6 172 EH, it MUST be the result of a configurable policy and not just 173 the result of a failure to recognise such a header. 175 o The discard policy for each standard type of EH MUST be 176 individually configurable. 178 o The default configuration SHOULD allow all standard IPv6 EHs. 180 The advice provided in this document is only meant to guide an 181 operator in configuring forwarding devices, and is *not* to be 182 interpreted as advice regarding default configuration settings for 183 network devices. That is, this document provides advice with respect 184 to operational configurations, but does not change the implementation 185 defaults required by [RFC7045]. 187 We recommend that configuration options are made available to govern 188 the processing of each IPv6 EH type and each IPv6 option type. Such 189 configuration options may include the following possible settings: 191 o Permit this IPv6 EH or IPv6 Option type 193 o Discard (and log) packets containing this IPv6 EH or option type 195 o Reject (and log) packets containing this IPv6 EH or option type 196 (where the packet drop is signaled with an ICMPv6 error message) 198 o Rate-limit traffic containing this IPv6 EH or option type 200 o Ignore this IPv6 EH or option type (as if it was not present) and 201 forward the packet. We note that if a packet carries forwarding 202 information (e.g., in an IPv6 Routing Header) this might be an 203 inappropriate or undesirable action. 205 We note that special care needs to be taken when devices log packet 206 drops/rejects. Devices should count the number of packets dropped/ 207 rejected, but the logging of drop/reject events should be limited so 208 as to not overburden device resources. 210 Finally, we note that when discarding packets, it is generally 211 desirable that the sender be signaled of the packet drop, since this 212 is of use for trouble-shooting purposes. However, throughout this 213 document (when recommending that packets be discarded) we generically 214 refer to the action as "discard" without specifying whether the 215 sender is signaled of the packet drop. 217 3. IPv6 Extension Headers 219 3.1. General Discussion 221 IPv6 [RFC8200] EHs allow for the extension of the IPv6 protocol. 222 Since both IPv6 EHs and upper-layer protocols share the same 223 namespace ("Next Header" registry/namespace), [RFC7045] identifies 224 which of the currently assigned Internet Protocol numbers identify 225 IPv6 EHs vs. upper-layer protocols. This document discusses the 226 filtering of packets based on the IPv6 EHs (as specified by 227 [RFC7045]) they contain. 229 NOTE: [RFC7112] specifies that non-fragmented IPv6 datagrams and 230 IPv6 First-Fragments MUST contain the entire IPv6 header chain 231 [RFC7112]. Therefore, intermediate systems can enforce the 232 filtering policies discussed in this document, or resort to simply 233 discarding the offending packets when they fail to comply with the 234 requirements in [RFC7112]. We note that, in order to implement 235 filtering rules on the fast path, it may be necessary for the 236 filtering device to limit the depth into the packet that can be 237 inspected before giving up. In circumstances where there is such 238 a limitation, it is recommended that implementations discard 239 packets if, when trying to determine whether to discard or permit 240 a packet, the aforementioned limit is encountered. 242 3.2. General Security Implications 244 In some specific device architectures, IPv6 packets that contain IPv6 245 EHs may cause the corresponding packets to be processed on the slow 246 path, and hence may be leveraged for the purpose of Denial of Service 247 (DoS) attacks [I-D.gont-v6ops-ipv6-ehs-packet-drops] [Cisco-EH] 248 [FW-Benchmark]. 250 Operators are urged to consider IPv6 EH filtering and IPv6 options 251 handling capabilities of different devices as they make deployment 252 decisions in future. 254 3.3. Summary of Advice on the Handling of IPv6 Packets with Specific 255 IPv6 Extension Headers 257 This section summarizes the advice provided in Section 3.4, providing 258 references to the specific sections in which a detailed analysis can 259 be found. 261 +--------------------------+-----------------------+----------------+ 262 | EH type | Filtering policy | Reference | 263 +--------------------------+-----------------------+----------------+ 264 | IPv6 Hop-by-Hop Options | Drop or Ignore | Section 3.4.1 | 265 | (Proto=0) | | | 266 +--------------------------+-----------------------+----------------+ 267 | Routing Header for IPv6 | Drop only RTH0 and | Section 3.4.2 | 268 | (Proto=43) | RTH1. Permit other RH | | 269 | | Types | | 270 +--------------------------+-----------------------+----------------+ 271 | Fragment Header for IPv6 | Permit | Section 3.4.3 | 272 | (Proto=44) | | | 273 +--------------------------+-----------------------+----------------+ 274 | Encapsulating Security | Permit | Section 3.4.4 | 275 | Payload (Proto=50) | | | 276 +--------------------------+-----------------------+----------------+ 277 | Authentication Header | Permit | Section 3.4.5 | 278 | (Proto=51) | | | 279 +--------------------------+-----------------------+----------------+ 280 | Destination Options for | Permit | Section 3.4.6 | 281 | IPv6 (Proto=60) | | | 282 +--------------------------+-----------------------+----------------+ 283 | Mobility Header | Permit | Section 3.4.7 | 284 | (Proto=135) | | | 285 +--------------------------+-----------------------+----------------+ 286 | Host Identity Protocol | Permit | Section 3.4.8 | 287 | (Proto=139) | | | 288 +--------------------------+-----------------------+----------------+ 289 | Shim6 Protocol | Permit | Section 3.4.9 | 290 | (Proto=140) | | | 291 +--------------------------+-----------------------+----------------+ 292 | Use for experimentation | Drop | Section 3.4.10 | 293 | and testing (Proto=253 | | | 294 | and 254) | | | 295 +--------------------------+-----------------------+----------------+ 297 Table 1: Summary of Advice on the Handling of IPv6 Packets with 298 Specific IPv6 Extension Headers 300 3.4. Advice on the Handling of IPv6 Packets with Specific IPv6 301 Extension Headers 303 3.4.1. IPv6 Hop-by-Hop Options (Protocol Number=0) 304 3.4.1.1. Uses 306 The Hop-by-Hop Options header is used to carry optional information 307 that may be examined by every node along a packet's delivery path. 308 It is expected that nodes will examine the Hop-by-Hop Options header 309 if explicitly configured to do so. 311 NOTE: [RFC2460] required that all nodes examined and processed the 312 Hop-by-Hop Options header. However, even before the publication of 313 [RFC8200] a number of implementations already provided the option of 314 ignoring this header unless explicitly configured to examine it. 316 3.4.1.2. Specification 318 This EH is specified in [RFC8200]. At the time of this writing, the 319 following options have been specified for the Hop-by-Hop Options EH: 321 o Type 0x00: Pad1 [RFC8200] 323 o Type 0x01: PadN [RFC8200] 325 o Type 0x05: Router Alert [RFC2711] 327 o Type 0x07: CALIPSO [RFC5570] 329 o Type 0x08: SMF_DPD [RFC6621] 331 o Type 0x23: RPL Option [I-D.ietf-roll-useofrplinfo] 333 o Type 0x26: Quick-Start [RFC4782] 335 o Type 0x4D: (Deprecated) 337 o Type 0x63: RPL Option [RFC6553] 339 o Type 0x6D: MPL Option [RFC7731] 341 o Type 0x8A: Endpoint Identification (Deprecated) 342 [draft-ietf-nimrod-eid] 344 o Type 0xC2: Jumbo Payload [RFC2675] 346 o Type 0xEE: IPv6 DFF Header [RFC6971] 348 o Type 0x1E: RFC3692-style Experiment [RFC4727] 350 o Type 0x3E: RFC3692-style Experiment [RFC4727] 351 o Type 0x5E: RFC3692-style Experiment [RFC4727] 353 o Type 0x7E: RFC3692-style Experiment [RFC4727] 355 o Type 0x9E: RFC3692-style Experiment [RFC4727] 357 o Type 0xBE: RFC3692-style Experiment [RFC4727] 359 o Type 0xDE: RFC3692-style Experiment [RFC4727] 361 o Type 0xFE: RFC3692-style Experiment [RFC4727] 363 3.4.1.3. Specific Security Implications 365 Legacy nodes that may process this extencion header could be subject 366 to Denial of Service attacks. 368 NOTE: While [RFC8200] has removed this requirement, the deployed base 369 may still reflect the traditional behavior for a while, and hence the 370 potential security problems of this EH are still of concern. 372 3.4.1.4. Operational and Interoperability Impact if Blocked 374 Discarding packets containing a Hop-by-Hop Options EH would break any 375 of the protocols that rely on it for proper functioning. For 376 example, it would break RSVP [RFC2205] and multicast deployments, and 377 would cause IPv6 jumbograms to be discarded. 379 3.4.1.5. Advice 381 Nodes implementing [RFC8200] would already ignore this extension 382 header unless explicitly required to process it. For legacy 383 ([RFC2460] nodes, the recommended configuration for the processing of 384 these packets depends on the features and capabilities of the 385 underlying platform. On platforms that allow forwarding of packets 386 with HBH Options on the fast path, we recommend that packets with a 387 HBH Options EH be forwarded as normal. Otherwise, on platforms in 388 which processing of packets with a IPv6 HBH Options EH is carried out 389 in the slow path, and an option is provided to rate-limit these 390 packets, we recommend that this option be selected. Finally, when 391 packets containing a HBH Options EH are processed in the slow-path, 392 and the underlying platform does not have any mitigation options 393 available for attacks based on these packets, we recommend that such 394 platforms discard packets containing IPv6 HBH Options EHs. 396 Finally, we note that, for obvious reasons, RPL (Routing Protocol for 397 Low-Power and Lossy Networks) [RFC6550] routers must not discard 398 packets based on the presence of an IPv6 Hop-by-Hop Options EH. 400 3.4.2. Routing Header for IPv6 (Protocol Number=43) 402 3.4.2.1. Uses 404 The Routing header is used by an IPv6 source to list one or more 405 intermediate nodes to be "visited" on the way to a packet's 406 destination. 408 3.4.2.2. Specification 410 This EH is specified in [RFC8200]. [RFC2460] had originally 411 specified the Routing Header Type 0, which was later obsoleted by 412 [RFC5095], and thus removed from [RFC8200]. 414 At the time of this writing, the following Routing Types have been 415 specified: 417 o Type 0: Source Route (DEPRECATED) [RFC2460] [RFC5095] 419 o Type 1: Nimrod (DEPRECATED) 421 o Type 2: Type 2 Routing Header [RFC6275] 423 o Type 3: RPL Source Route Header [RFC6554] 425 o Types 4-252: Unassigned 427 o Type 253: RFC3692-style Experiment 1 [RFC4727] 429 o Type 254: RFC3692-style Experiment 2 [RFC4727] 431 o Type 255: Reserved 433 3.4.2.3. Specific Security Implications 435 The security implications of RHT0 have been discussed in detail in 436 [Biondi2007] and [RFC5095]. 438 3.4.2.4. Operational and Interoperability Impact if Blocked 440 Blocking packets containing a RHT0 or RTH1 has no operational 441 implications, since both have been deprecated. However, blocking 442 packets employing other routing header types will break the protocols 443 that rely on them. 445 3.4.2.5. Advice 447 Intermediate systems should discard packets containing a RHT0 or 448 RHT1. Other routing header types should be permitted, as required by 449 [RFC7045]. 451 3.4.3. Fragment Header for IPv6 (Protocol Number=44) 453 3.4.3.1. Uses 455 This EH provides the fragmentation functionality for IPv6. 457 3.4.3.2. Specification 459 This EH is specified in [RFC8200]. 461 3.4.3.3. Specific Security Implications 463 The security implications of the Fragment Header range from Denial of 464 Service attacks (e.g. based on flooding a target with IPv6 fragments) 465 to information leakage attacks [RFC7739]. 467 3.4.3.4. Operational and Interoperability Impact if Blocked 469 Blocking packets that contain a Fragment Header will break any 470 protocol that may rely on fragmentation (e.g., the DNS [RFC1034]). 472 3.4.3.5. Advice 474 Intermediate systems should permit packets that contain a Fragment 475 Header. 477 3.4.4. Encapsulating Security Payload (Protocol Number=50) 479 3.4.4.1. Uses 481 This EH is employed for the IPsec suite [RFC4303]. 483 3.4.4.2. Specification 485 This EH is specified in [RFC4303]. 487 3.4.4.3. Specific Security Implications 489 Besides the general implications of IPv6 EHs, this EH could be 490 employed to potentially perform a DoS attack at the destination 491 system by wasting CPU resources in validating the contents of the 492 packet. 494 3.4.4.4. Operational and Interoperability Impact if Blocked 496 Discarding packets that employ this EH would break IPsec deployments. 498 3.4.4.5. Advice 500 Intermediate systems should permit packets containing the 501 Encapsulating Security Payload EH. 503 3.4.5. Authentication Header (Protocol Number=51) 505 3.4.5.1. Uses 507 The Authentication Header can be employed for provide authentication 508 services in IPv4 and IPv6. 510 3.4.5.2. Specification 512 This EH is specified in [RFC4302]. 514 3.4.5.3. Specific Security Implications 516 Besides the general implications of IPv6 EHs, this EH could be 517 employed to potentially perform a DoS attack at the destination 518 system by wasting CPU resources in validating the contents of the 519 packet. 521 3.4.5.4. Operational and Interoperability Impact if Blocked 523 Discarding packets that employ this EH would break IPsec deployments. 525 3.4.5.5. Advice 527 Intermediate systems should permit packets containing an 528 Authentication Header. 530 3.4.6. Destination Options for IPv6 (Protocol Number=60) 532 3.4.6.1. Uses 534 The Destination Options header is used to carry optional information 535 that needs be examined only by a packet's destination node(s). 537 3.4.6.2. Specification 539 This EH is specified in [RFC8200]. At the time of this writing, the 540 following options have been specified for this EH: 542 o Type 0x00: Pad1 [RFC8200] 544 o Type 0x01: PadN [RFC8200] 546 o Type 0x04: Tunnel Encapsulation Limit [RFC2473] 548 o Type 0x4D: (Deprecated) 550 o Type 0xC9: Home Address [RFC6275] 552 o Type 0x8A: Endpoint Identification (Deprecated) 553 [draft-ietf-nimrod-eid] 555 o Type 0x8B: ILNP Nonce [RFC6744] 557 o Type 0x8C: Line-Identification Option [RFC6788] 559 o Type 0x1E: RFC3692-style Experiment [RFC4727] 561 o Type 0x3E: RFC3692-style Experiment [RFC4727] 563 o Type 0x5E: RFC3692-style Experiment [RFC4727] 565 o Type 0x7E: RFC3692-style Experiment [RFC4727] 567 o Type 0x9E: RFC3692-style Experiment [RFC4727] 569 o Type 0xBE: RFC3692-style Experiment [RFC4727] 571 o Type 0xDE: RFC3692-style Experiment [RFC4727] 573 o Type 0xFE: RFC3692-style Experiment [RFC4727] 575 3.4.6.3. Specific Security Implications 577 No security implications are known, other than the general 578 implications of IPv6 EHs. For a discussion of possible security 579 implications of specific options specified for the DO header, please 580 see the Section 4.3. 582 3.4.6.4. Operational and Interoperability Impact if Blocked 584 Discarding packets that contain a Destination Options header would 585 break protocols that rely on this EH type for conveying information, 586 including protocols such as ILNP [RFC6740] and Mobile IPv6 [RFC6275], 587 and IPv6 tunnels that employ the Tunnel Encapsulation Limit option. 589 3.4.6.5. Advice 591 Intermediate systems should permit packets that contain a Destination 592 Options Header. 594 3.4.7. Mobility Header (Protocol Number=135) 596 3.4.7.1. Uses 598 The Mobility Header is an EH used by mobile nodes, correspondent 599 nodes, and home agents in all messaging related to the creation and 600 management of bindings in Mobile IPv6. 602 3.4.7.2. Specification 604 This EH is specified in [RFC6275]. 606 3.4.7.3. Specific Security Implications 608 A thorough security assessment of the security implications of the 609 Mobility Header and related mechanisms can be found in Section 15 of 610 [RFC6275]. 612 3.4.7.4. Operational and Interoperability Impact if Blocked 614 Discarding packets containing this EH would break Mobile IPv6. 616 3.4.7.5. Advice 618 Intermediate systems should permit packets containing this EH. 620 3.4.8. Host Identity Protocol (Protocol Number=139) 622 3.4.8.1. Uses 624 This EH is employed with the Host Identity Protocol (HIP), an 625 experimental protocol that allows consenting hosts to securely 626 establish and maintain shared IP-layer state, allowing separation of 627 the identifier and locator roles of IP addresses, thereby enabling 628 continuity of communications across IP address changes. 630 3.4.8.2. Specification 632 This EH is specified in [RFC5201]. 634 3.4.8.3. Specific Security Implications 636 The security implications of the HIP header are discussed in detail 637 in Section 8 of [RFC6275]. 639 3.4.8.4. Operational and Interoperability Impact if Blocked 641 Discarding packets that contain the Host Identity Protocol would 642 break HIP deployments. 644 3.4.8.5. Advice 646 Intermediate systems should permit packets that contain a Host 647 Identity Protocol EH. 649 3.4.9. Shim6 Protocol (Protocol Number=140) 651 3.4.9.1. Uses 653 This EH is employed by the Shim6 [RFC5533] Protocol. 655 3.4.9.2. Specification 657 This EH is specified in [RFC5533]. 659 3.4.9.3. Specific Security Implications 661 The specific security implications are discussed in detail in 662 Section 16 of [RFC5533]. 664 3.4.9.4. Operational and Interoperability Impact if Blocked 666 Discarding packets that contain this EH will break Shim6. 668 3.4.9.5. Advice 670 Intermediate systems should permit packets containing this EH. 672 3.4.10. Use for experimentation and testing (Protocol Numbers=253 and 673 254) 675 3.4.10.1. Uses 677 These IPv6 EHs are employed for performing RFC3692-Style experiments 678 (see [RFC3692] for details). 680 3.4.10.2. Specification 682 These EHs are specified in [RFC3692] and [RFC4727]. 684 3.4.10.3. Specific Security Implications 686 The security implications of these EHs will depend on their specific 687 use. 689 3.4.10.4. Operational and Interoperability Impact if Blocked 691 For obvious reasons, discarding packets that contain these EHs limits 692 the ability to perform legitimate experiments across IPv6 routers. 694 3.4.10.5. Advice 696 Intermediate systems should discard packets containing these EHs. 697 Only in specific scenarios in which RFC3692-Style experiments are to 698 be performed should these EHs be permitted. 700 3.5. Advice on the Handling of Packets with Unknown IPv6 Extension 701 Headers 703 We refer to IPv6 EHs that have not been assigned an Internet Protocol 704 Number by IANA (and marked as such) in [IANA-PROTOCOLS] as "unknown 705 IPv6 extension headers" ("unknown IPv6 EHs"). 707 3.5.1. Uses 709 New IPv6 EHs may be specified as part of future extensions to the 710 IPv6 protocol. 712 Since IPv6 EHs and Upper-layer protocols employ the same namespace, 713 it is impossible to tell whether an unknown "Internet Protocol 714 Number" is being employed for an IPv6 EH or an Upper-Layer protocol. 716 3.5.2. Specification 718 The processing of unknown IPv6 EHs is specified in [RFC8200] and 719 [RFC7045]. 721 3.5.3. Specific Security Implications 723 For obvious reasons, it is impossible to determine specific security 724 implications of unknown IPv6 EHs. However, from security standpoint, 725 a device should discard IPv6 extension headers for which the security 726 implications cannot be determined. We note that this policy is 727 allowed by [RFC7045]. 729 3.5.4. Operational and Interoperability Impact if Blocked 731 As noted in [RFC7045], discarding unknown IPv6 EHs may slow down the 732 deployment of new IPv6 EHs and transport protocols. The 733 corresponding IANA registry ([IANA-PROTOCOLS]) should be monitored 734 such that filtering rules are updated as new IPv6 EHs are 735 standardized. 737 We note that since IPv6 EHs and upper-layer protocols share the same 738 numbering space, discarding unknown IPv6 EHs may result in packets 739 encapsulating unknown upper-layer protocols being discarded. 741 3.5.5. Advice 743 Intermediate systems should discard packets containing unknown IPv6 744 EHs. 746 4. IPv6 Options 748 4.1. General Discussion 750 The following subsections describe specific security implications of 751 different IPv6 options, and provide advice regarding filtering 752 packets that contain such options. 754 4.2. General Security Implications of IPv6 Options 756 The general security implications of IPv6 options are closely related 757 to those discussed in Section 3.2 for IPv6 EHs. Essentially, packets 758 that contain IPv6 options might need to be processed by an IPv6 759 router's general-purpose CPU,and hence could present a DDoS risk to 760 that router's general-purpose CPU (and thus to the router itself). 761 For some architectures, a possible mitigation would be to rate-limit 762 the packets that are to be processed by the general-purpose CPU (see 763 e.g. [Cisco-EH]). 765 4.3. Advice on the Handling of Packets with Specific IPv6 Options 767 The following subsections contain a description of each of the IPv6 768 options that have so far been specified, a summary of the security 769 implications of each of such options, a discussion of possible 770 interoperability implications if packets containing such options are 771 discarded, and specific advice regarding whether packets containing 772 these options should be permitted. 774 4.3.1. Pad1 (Type=0x00) 776 4.3.1.1. Uses 778 This option is used when necessary to align subsequent options and to 779 pad out the containing header to a multiple of 8 octets in length. 781 4.3.1.2. Specification 783 This option is specified in [RFC8200]. 785 4.3.1.3. Specific Security Implications 787 None. 789 4.3.1.4. Operational and Interoperability Impact if Blocked 791 Discarding packets that contain this option would potentially break 792 any protocol that relies on IPv6 EHs. 794 4.3.1.5. Advice 796 Intermediate systems should not discard packets based on the presence 797 of this option. 799 4.3.2. PadN (Type=0x01) 801 4.3.2.1. Uses 803 This option is used when necessary to align subsequent options and to 804 pad out the containing header to a multiple of 8 octets in length. 806 4.3.2.2. Specification 808 This option is specified in [RFC8200]. 810 4.3.2.3. Specific Security Implications 812 Because of the possible size of this option, it could be leveraged as 813 a large-bandwidth covert channel. 815 4.3.2.4. Operational and Interoperability Impact if Blocked 817 Discarding packets that contain this option would potentially break 818 any protocol that relies on IPv6 EHs. 820 4.3.2.5. Advice 822 Intermediate systems should not discard IPv6 packets based on the 823 presence of this option. 825 4.3.3. Jumbo Payload (Type=0XC2) 827 4.3.3.1. Uses 829 The Jumbo payload option provides the means of specifying payloads 830 larger than 65535 bytes. 832 4.3.3.2. Specification 834 This option is specified in [RFC2675]. 836 4.3.3.3. Specific Security Implications 838 There are no specific issues arising from this option, except for 839 improper validity checks of the option and associated packet lengths. 841 4.3.3.4. Operational and Interoperability Impact if Blocked 843 Discarding packets based on the presence of this option will cause 844 IPv6 jumbograms to be discarded. 846 4.3.3.5. Advice 848 Intermediate systems should discard packets that contain this option. 849 An operator should permit this option only in specific scenarios in 850 which support for IPv6 jumbograms is desired. 852 4.3.4. RPL Option (Type=0x63) 854 4.3.4.1. Uses 856 The RPL Option provides a mechanism to include routing information 857 with each datagram that an RPL router forwards. 859 4.3.4.2. Specification 861 This option was originally specified in [RFC6553]. It has been 862 deprecated by [I-D.ietf-roll-useofrplinfo]. 864 4.3.4.3. Specific Security Implications 866 Those described in [RFC6553]. 868 4.3.4.4. Operational and Interoperability Impact if Blocked 870 This option is meant to be employed within an RPL instance. As a 871 result, discarding packets based on the presence of this option (e.g. 872 at an ISP) will not result in interoperability implications. 874 4.3.4.5. Advice 876 Non-RPL routers should discard packets that contain an RPL option. 878 4.3.5. RPL Option (Type=0x23) 880 4.3.5.1. Uses 882 The RPL Option provides a mechanism to include routing information 883 with each datagram that an RPL router forwards. 885 4.3.5.2. Specification 887 This option is specified in [I-D.ietf-roll-useofrplinfo]. 889 4.3.5.3. Specific Security Implications 891 Those described in [I-D.ietf-roll-useofrplinfo]. 893 4.3.5.4. Operational and Interoperability Impact if Blocked 895 This option is meant to survive outside of an RPL instance. As a 896 result, discarding packets based on the presence of this option would 897 break some use cases for RPL (see [I-D.ietf-roll-useofrplinfo]). 899 4.3.5.5. Advice 901 Intermediate systems should not discard IPv6 packets based on the 902 presence of this option. 904 4.3.6. Tunnel Encapsulation Limit (Type=0x04) 906 4.3.6.1. Uses 908 The Tunnel Encapsulation Limit option can be employed to specify how 909 many further levels of nesting the packet is permitted to undergo. 911 4.3.6.2. Specification 913 This option is specified in [RFC2473]. 915 4.3.6.3. Specific Security Implications 917 Those described in [RFC2473]. 919 4.3.6.4. Operational and Interoperability Impact if Blocked 921 Discarding packets based on the presence of this option could result 922 in tunnel traffic being discarded. 924 4.3.6.5. Advice 926 Intermediate systems should not discard packets based on the presence 927 of this option. 929 4.3.7. Router Alert (Type=0x05) 931 4.3.7.1. Uses 933 The Router Alert option [RFC2711] is typically employed for the RSVP 934 protocol [RFC2205] and the MLD protocol [RFC2710]. 936 4.3.7.2. Specification 938 This option is specified in [RFC2711]. 940 4.3.7.3. Specific Security Implications 942 Since this option causes the contents of the packet to be inspected 943 by the handling device, this option could be leveraged for performing 944 DoS attacks. 946 4.3.7.4. Operational and Interoperability Impact if Blocked 948 Discarding packets that contain this option would break RSVP and 949 multicast deployments. 951 4.3.7.5. Advice 953 Intermediate systems should discard packets that contain this option. 954 Only in specific environments where support for RSVP, multicast 955 routing, or similar protocols is desired, should this option be 956 permitted. 958 4.3.8. Quick-Start (Type=0x26) 960 4.3.8.1. Uses 962 This IP Option is used in the specification of Quick-Start for TCP 963 and IP, which is an experimental mechanism that allows transport 964 protocols, in cooperation with routers, to determine an allowed 965 sending rate at the start and, at times, in the middle of a data 966 transfer (e.g., after an idle period) [RFC4782]. 968 4.3.8.2. Specification 970 This option is specified in [RFC4782], on the "Experimental" track. 972 4.3.8.3. Specific Security Implications 974 Section 9.6 of [RFC4782] notes that Quick-Start is vulnerable to two 975 kinds of attacks: 977 o attacks to increase the routers' processing and state load, and, 979 o attacks with bogus Quick-Start Requests to temporarily tie up 980 available Quick-Start bandwidth, preventing routers from approving 981 Quick-Start Requests from other connections. 983 We note that if routers in a given environment do not implement and 984 enable the Quick-Start mechanism, only the general security 985 implications of IP options (discussed in Section 4.2) would apply. 987 4.3.8.4. Operational and Interoperability Impact if Blocked 989 The Quick-Start functionality would be disabled, and additional 990 delays in TCP's connection establishment (for example) could be 991 introduced. (Please see Section 4.7.2 of [RFC4782].) We note, 992 however, that Quick-Start has been proposed as a mechanism that could 993 be of use in controlled environments, and not as a mechanism that 994 would be intended or appropriate for ubiquitous deployment in the 995 global Internet [RFC4782]. 997 4.3.8.5. Advice 999 Intermediate systems should not discard IPv6 packets based on the 1000 presence of this option. 1002 4.3.9. CALIPSO (Type=0x07) 1004 4.3.9.1. Uses 1006 This option is used for encoding explicit packet Sensitivity Labels 1007 on IPv6 packets. It is intended for use only within Multi-Level 1008 Secure (MLS) networking environments that are both trusted and 1009 trustworthy. 1011 4.3.9.2. Specification 1013 This option is specified in [RFC5570]. 1015 4.3.9.3. Specific Security Implications 1017 Presence of this option in a packet does not by itself create any 1018 specific new threat. Packets with this option ought not normally be 1019 seen on the global public Internet. 1021 4.3.9.4. Operational and Interoperability Impact if Blocked 1023 If packets with this option are discarded or if the option is 1024 stripped from the packet during transmission from source to 1025 destination, then the packet itself is likely to be discarded by the 1026 receiver because it is not properly labeled. In some cases, the 1027 receiver might receive the packet but associate an incorrect 1028 sensitivity label with the received data from the packet whose 1029 CALIPSO was stripped by an intermediate router or firewall. 1030 Associating an incorrect sensitivity label can cause the received 1031 information either to be handled as more sensitive than it really is 1032 ("upgrading") or as less sensitive than it really is ("downgrading"), 1033 either of which is problematic. 1035 4.3.9.5. Advice 1037 Intermediate systems that do not operate in Multi-Level Secure (MLS) 1038 networking environments should discard packets that contain this 1039 option. 1041 4.3.10. SMF_DPD (Type=0x08) 1043 4.3.10.1. Uses 1045 This option is employed in the (experimental) Simplified Multicast 1046 Forwarding (SMF) for unique packet identification for IPv6 I-DPD, and 1047 as a mechanism to guarantee non-collision of hash values for 1048 different packets when H-DPD is used. 1050 4.3.10.2. Specification 1052 This option is specified in [RFC6621]. 1054 4.3.10.3. Specific Security Implications 1056 None. The use of identifiers is subject to the security and privacy 1057 considerations discussed in [I-D.gont-predictable-numeric-ids]. 1059 4.3.10.4. Operational and Interoperability Impact if Blocked 1061 Dropping packets containing this option within a MANET domain would 1062 break SMF. However, dropping such packets at the border of such 1063 domain would have no negative impact. 1065 4.3.10.5. Advice 1067 Intermediate system should discard packets that contain this option. 1069 4.3.11. Home Address (Type=0xC9) 1071 4.3.11.1. Uses 1073 The Home Address option is used by a Mobile IPv6 node while away from 1074 home, to inform the recipient of the mobile node's home address. 1076 4.3.11.2. Specification 1078 This option is specified in [RFC6275]. 1080 4.3.11.3. Specific Security Implications 1082 No (known) additional security implications than those described in 1083 [RFC6275]. 1085 4.3.11.4. Operational and Interoperability Impact if Blocked 1087 Discarding IPv6 packets based on the presence of this option will 1088 break Mobile IPv6. 1090 4.3.11.5. Advice 1092 Intermediate systems should not discard IPv6 packets based on the 1093 presence of this option. 1095 4.3.12. Endpoint Identification (Type=0x8A) 1097 4.3.12.1. Uses 1099 The Endpoint Identification option was meant to be used with the 1100 Nimrod routing architecture [NIMROD-DOC], but has never seen 1101 widespread deployment. 1103 4.3.12.2. Specification 1105 This option is specified in [NIMROD-DOC]. 1107 4.3.12.3. Specific Security Implications 1109 Undetermined. 1111 4.3.12.4. Operational and Interoperability Impact if Blocked 1113 None. 1115 4.3.12.5. Advice 1117 Intermediate systems should discard packets that contain this option. 1119 4.3.13. ILNP Nonce (Type=0x8B) 1121 4.3.13.1. Uses 1123 This option is employed by Identifier-Locator Network Protocol for 1124 IPv6 (ILNPv6) for providing protection against off-path attacks for 1125 packets when ILNPv6 is in use, and as a signal during initial 1126 network-layer session creation that ILNPv6 is proposed for use with 1127 this network-layer session, rather than classic IPv6. 1129 4.3.13.2. Specification 1131 This option is specified in [RFC6744]. 1133 4.3.13.3. Specific Security Implications 1135 Those described in [RFC6744]. 1137 4.3.13.4. Operational and Interoperability Impact if Blocked 1139 Discarding packets that contain this option will break INLPv6 1140 deployments. 1142 4.3.13.5. Advice 1144 Intermediate systems should not discard packets based on the presence 1145 of this option. 1147 4.3.14. Line-Identification Option (Type=0x8C) 1149 4.3.14.1. Uses 1151 This option is used by an Edge Router to identify the subscriber 1152 premises in scenarios where several subscriber premises may be 1153 logically connected to the same interface of an Edge Router. 1155 4.3.14.2. Specification 1157 This option is specified in [RFC6788]. 1159 4.3.14.3. Specific Security Implications 1161 Those described in [RFC6788]. 1163 4.3.14.4. Operational and Interoperability Impact if Blocked 1165 Since this option is meant to be employed in Router Solicitation 1166 messages, discarding packets based on the presence of this option at 1167 intermediate systems will result in no interoperability implications. 1169 4.3.14.5. Advice 1171 Intermediate devices should discard packets that contain this option. 1173 4.3.15. Deprecated (Type=0x4D) 1175 4.3.15.1. Uses 1177 No information has been found about this option type. 1179 4.3.15.2. Specification 1181 No information has been found about this option type. 1183 4.3.15.3. Specific Security Implications 1185 No information has been found about this option type, and hence it 1186 has been impossible to perform the corresponding security assessment. 1188 4.3.15.4. Operational and Interoperability Impact if Blocked 1190 Unknown. 1192 4.3.15.5. Advice 1194 Intermediate systems should discard packets that contain this option. 1196 4.3.16. MPL Option (Type=0x6D) 1198 4.3.16.1. Uses 1200 This option is used with the Multicast Protocol for Low power and 1201 Lossy Networks (MPL), that provides IPv6 multicast forwarding in 1202 constrained networks. 1204 4.3.16.2. Specification 1206 This option is specified in [RFC7731], and is meant to be included 1207 only in Hop-by-Hop Option headers. 1209 4.3.16.3. Specific Security Implications 1211 Those described in [RFC7731]. 1213 4.3.16.4. Operational and Interoperability Impact if Blocked 1215 Dropping packets that contain an MPL option within an MPL network 1216 would break the Multicast Protocol for Low power and Lossy Networks 1217 (MPL). However, dropping such packets at the border of such networks 1218 will have no negative impact. 1220 4.3.16.5. Advice 1222 Intermediate systems should not discard packets based on the presence 1223 of this option. However, since this option has been specified for 1224 the Hop-by-Hop Options, such systems should consider the discussion 1225 in Section 3.4.1. 1227 4.3.17. IP_DFF (Type=0xEE) 1229 4.3.17.1. Uses 1231 This option is employed with the (Experimental) Depth-First 1232 Forwarding (DFF) in Unreliable Networks. 1234 4.3.17.2. Specification 1236 This option is specified in [RFC6971]. 1238 4.3.17.3. Specific Security Implications 1240 Those specified in [RFC6971]. 1242 4.3.17.4. Operational and Interoperability Impact if Blocked 1244 Dropping packets containing this option within a routing domain that 1245 is running DFF would break DFF. However, droping such packets at the 1246 border of such domains will have no security implications. 1248 4.3.17.5. Advice 1250 Intermediate systems that do not operate within a routing domain that 1251 is running DFF should discard packets containing this option. 1253 4.3.18. RFC3692-style Experiment (Types = 0x1E, 0x3E, 0x5E, 0x7E, 0x9E, 1254 0xBE, 0xDE, 0xFE) 1256 4.3.18.1. Uses 1258 These options can be employed for performing RFC3692-style 1259 experiments. It is only appropriate to use these values in 1260 explicitly configured experiments; they must not be shipped as 1261 defaults in implementations. 1263 4.3.18.2. Specification 1265 Specified in RFC 4727 [RFC4727] in the context of RFC3692-style 1266 experiments. 1268 4.3.18.3. Specific Security Implications 1270 The specific security implications will depend on the specific use of 1271 these options. 1273 4.3.18.4. Operational and Interoperability Impact if Blocked 1275 For obvious reasons, discarding packets that contain these options 1276 limits the ability to perform legitimate experiments across IPv6 1277 routers. 1279 4.3.18.5. Advice 1281 Intermediate systems should discard packets that contain these 1282 options. Only in specific environments where RFC3692-style 1283 experiments are meant to be performed should these options be 1284 permitted. 1286 4.4. Advice on the handling of Packets with Unknown IPv6 Options 1288 We refer to IPv6 options that have not been assigned an IPv6 option 1289 type in the corresponding registry ([IANA-IPV6-PARAM]) as "unknown 1290 IPv6 options". 1292 4.4.1. Uses 1294 New IPv6 options may be specified as part of future protocol work. 1296 4.4.2. Specification 1298 The processing of unknown IPv6 options is specified in [RFC8200]. 1300 4.4.3. Specific Security Implications 1302 For obvious reasons, it is impossible to determine specific security 1303 implications of unknown IPv6 options. 1305 4.4.4. Operational and Interoperability Impact if Blocked 1307 Discarding unknown IPv6 options may slow down the deployment of new 1308 IPv6 options. As noted in [draft-gont-6man-ipv6-opt-transmit], the 1309 corresponding IANA registry ([IANA-IPV6-PARAM] should be monitored 1310 such that IPv6 option filtering rules are updated as new IPv6 options 1311 are standardized. 1313 4.4.5. Advice 1315 Enterprise intermediate systems that process the contents of IPv6 EHs 1316 should discard packets that contain unknown options. Other 1317 intermediate systems that process the contents of IPv6 EHs should 1318 permit packets that contain unknown options. 1320 5. IANA Considerations 1322 This document has no actions for IANA. 1324 6. Security Considerations 1326 This document provides advice on the filtering of IPv6 packets that 1327 contain IPv6 EHs (and possibly IPv6 options) at IPv6 transit routers. 1328 It is meant to improve the current situation of widespread dropping 1329 of such IPv6 packets in those cases where the drops result from 1330 improper configuration defaults, or inappropriate advice in this 1331 area. 1333 7. Acknowledgements 1335 The authors would like to thank Ron Bonica for his work on earlier 1336 versions of this document. 1338 The authors of this document would like to thank (in alphabetical 1339 order) Mikael Abrahamsson, Brian Carpenter, Darren Dukes, Mike Heard, 1340 Bob Hinden, Jen Linkova, Carlos Pignataro, Maria Ines Robles, Donald 1341 Smith, Pascal Thubert, Ole Troan, Gunter Van De Velde, and Eric 1342 Vyncke, for providing valuable comments on earlier versions of this 1343 document. 1345 This document borrows some text and analysis from [RFC7126], authored 1346 by Fernando Gont, Randall Atkinson, and Carlos Pignataro. 1348 Fernando Gont would like to thank Eric Vyncke for his guidance. 1350 8. References 1352 8.1. Normative References 1354 [draft-gont-6man-ipv6-opt-transmit] 1355 Gont, F., Liu, W., and R. Bonica, "Transmission and 1356 Processing of IPv6 Options", IETF Internet Draft, work in 1357 progress, August 2014. 1359 [I-D.ietf-roll-useofrplinfo] 1360 Robles, I., Richardson, M., and P. Thubert, "When to use 1361 RFC 6553, 6554 and IPv6-in-IPv6", draft-ietf-roll- 1362 useofrplinfo-23 (work in progress), May 2018. 1364 [RFC1034] Mockapetris, P., "Domain names - concepts and facilities", 1365 STD 13, RFC 1034, DOI 10.17487/RFC1034, November 1987, 1366 . 1368 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1369 Requirement Levels", BCP 14, RFC 2119, 1370 DOI 10.17487/RFC2119, March 1997, 1371 . 1373 [RFC2205] Braden, R., Ed., Zhang, L., Berson, S., Herzog, S., and S. 1374 Jamin, "Resource ReSerVation Protocol (RSVP) -- Version 1 1375 Functional Specification", RFC 2205, DOI 10.17487/RFC2205, 1376 September 1997, . 1378 [RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6 1379 (IPv6) Specification", RFC 2460, DOI 10.17487/RFC2460, 1380 December 1998, . 1382 [RFC2473] Conta, A. and S. Deering, "Generic Packet Tunneling in 1383 IPv6 Specification", RFC 2473, DOI 10.17487/RFC2473, 1384 December 1998, . 1386 [RFC2675] Borman, D., Deering, S., and R. Hinden, "IPv6 Jumbograms", 1387 RFC 2675, DOI 10.17487/RFC2675, August 1999, 1388 . 1390 [RFC2710] Deering, S., Fenner, W., and B. Haberman, "Multicast 1391 Listener Discovery (MLD) for IPv6", RFC 2710, 1392 DOI 10.17487/RFC2710, October 1999, 1393 . 1395 [RFC2711] Partridge, C. and A. Jackson, "IPv6 Router Alert Option", 1396 RFC 2711, DOI 10.17487/RFC2711, October 1999, 1397 . 1399 [RFC3692] Narten, T., "Assigning Experimental and Testing Numbers 1400 Considered Useful", BCP 82, RFC 3692, 1401 DOI 10.17487/RFC3692, January 2004, 1402 . 1404 [RFC4302] Kent, S., "IP Authentication Header", RFC 4302, 1405 DOI 10.17487/RFC4302, December 2005, 1406 . 1408 [RFC4303] Kent, S., "IP Encapsulating Security Payload (ESP)", 1409 RFC 4303, DOI 10.17487/RFC4303, December 2005, 1410 . 1412 [RFC4304] Kent, S., "Extended Sequence Number (ESN) Addendum to 1413 IPsec Domain of Interpretation (DOI) for Internet Security 1414 Association and Key Management Protocol (ISAKMP)", 1415 RFC 4304, DOI 10.17487/RFC4304, December 2005, 1416 . 1418 [RFC4727] Fenner, B., "Experimental Values In IPv4, IPv6, ICMPv4, 1419 ICMPv6, UDP, and TCP Headers", RFC 4727, 1420 DOI 10.17487/RFC4727, November 2006, 1421 . 1423 [RFC4782] Floyd, S., Allman, M., Jain, A., and P. Sarolahti, "Quick- 1424 Start for TCP and IP", RFC 4782, DOI 10.17487/RFC4782, 1425 January 2007, . 1427 [RFC5095] Abley, J., Savola, P., and G. Neville-Neil, "Deprecation 1428 of Type 0 Routing Headers in IPv6", RFC 5095, 1429 DOI 10.17487/RFC5095, December 2007, 1430 . 1432 [RFC5201] Moskowitz, R., Nikander, P., Jokela, P., Ed., and T. 1433 Henderson, "Host Identity Protocol", RFC 5201, 1434 DOI 10.17487/RFC5201, April 2008, 1435 . 1437 [RFC5533] Nordmark, E. and M. Bagnulo, "Shim6: Level 3 Multihoming 1438 Shim Protocol for IPv6", RFC 5533, DOI 10.17487/RFC5533, 1439 June 2009, . 1441 [RFC5570] StJohns, M., Atkinson, R., and G. Thomas, "Common 1442 Architecture Label IPv6 Security Option (CALIPSO)", 1443 RFC 5570, DOI 10.17487/RFC5570, July 2009, 1444 . 1446 [RFC6275] Perkins, C., Ed., Johnson, D., and J. Arkko, "Mobility 1447 Support in IPv6", RFC 6275, DOI 10.17487/RFC6275, July 1448 2011, . 1450 [RFC6398] Le Faucheur, F., Ed., "IP Router Alert Considerations and 1451 Usage", BCP 168, RFC 6398, DOI 10.17487/RFC6398, October 1452 2011, . 1454 [RFC6550] Winter, T., Ed., Thubert, P., Ed., Brandt, A., Hui, J., 1455 Kelsey, R., Levis, P., Pister, K., Struik, R., Vasseur, 1456 JP., and R. Alexander, "RPL: IPv6 Routing Protocol for 1457 Low-Power and Lossy Networks", RFC 6550, 1458 DOI 10.17487/RFC6550, March 2012, 1459 . 1461 [RFC6553] Hui, J. and JP. Vasseur, "The Routing Protocol for Low- 1462 Power and Lossy Networks (RPL) Option for Carrying RPL 1463 Information in Data-Plane Datagrams", RFC 6553, 1464 DOI 10.17487/RFC6553, March 2012, 1465 . 1467 [RFC6554] Hui, J., Vasseur, JP., Culler, D., and V. Manral, "An IPv6 1468 Routing Header for Source Routes with the Routing Protocol 1469 for Low-Power and Lossy Networks (RPL)", RFC 6554, 1470 DOI 10.17487/RFC6554, March 2012, 1471 . 1473 [RFC6621] Macker, J., Ed., "Simplified Multicast Forwarding", 1474 RFC 6621, DOI 10.17487/RFC6621, May 2012, 1475 . 1477 [RFC6740] Atkinson, RJ. and SN. Bhatti, "Identifier-Locator Network 1478 Protocol (ILNP) Architectural Description", RFC 6740, 1479 DOI 10.17487/RFC6740, November 2012, 1480 . 1482 [RFC6744] Atkinson, RJ. and SN. Bhatti, "IPv6 Nonce Destination 1483 Option for the Identifier-Locator Network Protocol for 1484 IPv6 (ILNPv6)", RFC 6744, DOI 10.17487/RFC6744, November 1485 2012, . 1487 [RFC6788] Krishnan, S., Kavanagh, A., Varga, B., Ooghe, S., and E. 1488 Nordmark, "The Line-Identification Option", RFC 6788, 1489 DOI 10.17487/RFC6788, November 2012, 1490 . 1492 [RFC6971] Herberg, U., Ed., Cardenas, A., Iwao, T., Dow, M., and S. 1493 Cespedes, "Depth-First Forwarding (DFF) in Unreliable 1494 Networks", RFC 6971, DOI 10.17487/RFC6971, June 2013, 1495 . 1497 [RFC7045] Carpenter, B. and S. Jiang, "Transmission and Processing 1498 of IPv6 Extension Headers", RFC 7045, 1499 DOI 10.17487/RFC7045, December 2013, 1500 . 1502 [RFC7112] Gont, F., Manral, V., and R. Bonica, "Implications of 1503 Oversized IPv6 Header Chains", RFC 7112, 1504 DOI 10.17487/RFC7112, January 2014, 1505 . 1507 [RFC7731] Hui, J. and R. Kelsey, "Multicast Protocol for Low-Power 1508 and Lossy Networks (MPL)", RFC 7731, DOI 10.17487/RFC7731, 1509 February 2016, . 1511 [RFC8200] Deering, S. and R. Hinden, "Internet Protocol, Version 6 1512 (IPv6) Specification", STD 86, RFC 8200, 1513 DOI 10.17487/RFC8200, July 2017, 1514 . 1516 8.2. Informative References 1518 [Biondi2007] 1519 Biondi, P. and A. Ebalard, "IPv6 Routing Header Security", 1520 CanSecWest 2007 Security Conference, 2007, 1521 . 1523 [Cisco-EH] 1524 Cisco Systems, "IPv6 Extension Headers Review and 1525 Considerations", Whitepaper. October 2006, 1526 . 1529 [draft-ietf-nimrod-eid] 1530 Lynn, C., "Endpoint Identifier Destination Option", IETF 1531 Internet Draft, draft-ietf-nimrod-eid-00.txt, November 1532 1995. 1534 [FW-Benchmark] 1535 Zack, E., "Firewall Security Assessment and Benchmarking 1536 IPv6 Firewall Load Tests", IPv6 Hackers Meeting #1, 1537 Berlin, Germany. June 30, 2013, 1538 . 1542 [I-D.gont-predictable-numeric-ids] 1543 Gont, F. and I. Arce, "Security and Privacy Implications 1544 of Numeric Identifiers Employed in Network Protocols", 1545 draft-gont-predictable-numeric-ids-02 (work in progress), 1546 February 2018. 1548 [I-D.gont-v6ops-ipv6-ehs-packet-drops] 1549 Gont, F., Hilliard, N., Doering, G., (Will), S., and W. 1550 Kumari, "Operational Implications of IPv6 Packets with 1551 Extension Headers", draft-gont-v6ops-ipv6-ehs-packet- 1552 drops-03 (work in progress), March 2016. 1554 [I-D.ietf-6man-hbh-header-handling] 1555 Baker, F. and R. Bonica, "IPv6 Hop-by-Hop Options 1556 Extension Header", draft-ietf-6man-hbh-header-handling-03 1557 (work in progress), March 2016. 1559 [IANA-IPV6-PARAM] 1560 Internet Assigned Numbers Authority, "Internet Protocol 1561 Version 6 (IPv6) Parameters", December 2013, 1562 . 1565 [IANA-PROTOCOLS] 1566 Internet Assigned Numbers Authority, "Protocol Numbers", 1567 2014, . 1570 [NIMROD-DOC] 1571 Nimrod Documentation Page, 1572 "http://ana-3.lcs.mit.edu/~jnc/nimrod/". 1574 [RFC3871] Jones, G., Ed., "Operational Security Requirements for 1575 Large Internet Service Provider (ISP) IP Network 1576 Infrastructure", RFC 3871, DOI 10.17487/RFC3871, September 1577 2004, . 1579 [RFC6192] Dugal, D., Pignataro, C., and R. Dunn, "Protecting the 1580 Router Control Plane", RFC 6192, DOI 10.17487/RFC6192, 1581 March 2011, . 1583 [RFC7126] Gont, F., Atkinson, R., and C. Pignataro, "Recommendations 1584 on Filtering of IPv4 Packets Containing IPv4 Options", 1585 BCP 186, RFC 7126, DOI 10.17487/RFC7126, February 2014, 1586 . 1588 [RFC7739] Gont, F., "Security Implications of Predictable Fragment 1589 Identification Values", RFC 7739, DOI 10.17487/RFC7739, 1590 February 2016, . 1592 [RFC7872] Gont, F., Linkova, J., Chown, T., and W. Liu, 1593 "Observations on the Dropping of Packets with IPv6 1594 Extension Headers in the Real World", RFC 7872, 1595 DOI 10.17487/RFC7872, June 2016, 1596 . 1598 Authors' Addresses 1600 Fernando Gont 1601 UTN-FRH / SI6 Networks 1602 Evaristo Carriego 2644 1603 Haedo, Provincia de Buenos Aires 1706 1604 Argentina 1606 Phone: +54 11 4650 8472 1607 Email: fgont@si6networks.com 1608 URI: http://www.si6networks.com 1609 Will(Shucheng) Liu 1610 Huawei Technologies 1611 Bantian, Longgang District 1612 Shenzhen 518129 1613 P.R. China 1615 Email: liushucheng@huawei.com