idnits 2.17.1 draft-ietf-opsec-ipv6-eh-filtering-01.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 8, 2016) is 2849 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Unused Reference: 'RFC4304' is defined on line 1287, but no explicit reference was found in the text ** Obsolete normative reference: RFC 2460 (Obsoleted by RFC 8200) ** Obsolete normative reference: RFC 5201 (Obsoleted by RFC 7401) == Outdated reference: A later version (-04) exists of draft-gont-v6ops-ipv6-ehs-packet-drops-03 Summary: 2 errors (**), 0 flaws (~~), 3 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 9, 2017 Huawei Technologies 6 R. Bonica 7 Juniper Networks 8 July 8, 2016 10 Recommendations on Filtering of IPv6 Packets Containing IPv6 Extension 11 Headers 12 draft-ietf-opsec-ipv6-eh-filtering-01 14 Abstract 16 It is common operator practice to mitigate security risks by 17 enforcing appropriate packet filtering. This document analyzes both 18 the general security implications of IPv6 Extension Headers and the 19 specific security implications of each Extension Header and Option 20 type, and provides advice on the filtering of IPv6 packets based on 21 the IPv6 Extension Headers and the IPv6 options they contain. 22 Additionally, it discusses the operational and interoperability 23 implications of discarding packets based on the IPv6 Extension 24 Headers and IPv6 options they contain. 26 Status of This Memo 28 This Internet-Draft is submitted in full conformance with the 29 provisions of BCP 78 and BCP 79. 31 Internet-Drafts are working documents of the Internet Engineering 32 Task Force (IETF). Note that other groups may also distribute 33 working documents as Internet-Drafts. The list of current Internet- 34 Drafts is at http://datatracker.ietf.org/drafts/current/. 36 Internet-Drafts are draft documents valid for a maximum of six months 37 and may be updated, replaced, or obsoleted by other documents at any 38 time. It is inappropriate to use Internet-Drafts as reference 39 material or to cite them other than as "work in progress." 41 This Internet-Draft will expire on January 9, 2017. 43 Copyright Notice 45 Copyright (c) 2016 IETF Trust and the persons identified as the 46 document authors. All rights reserved. 48 This document is subject to BCP 78 and the IETF Trust's Legal 49 Provisions Relating to IETF Documents 50 (http://trustee.ietf.org/license-info) in effect on the date of 51 publication of this document. Please review these documents 52 carefully, as they describe your rights and restrictions with respect 53 to this document. Code Components extracted from this document must 54 include Simplified BSD License text as described in Section 4.e of 55 the Trust Legal Provisions and are provided without warranty as 56 described in the Simplified BSD License. 58 Table of Contents 60 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 61 2. Terminology and Conventions Used in This Document . . . . . . 3 62 2.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3 63 2.2. Conventions . . . . . . . . . . . . . . . . . . . . . . . 4 64 3. IPv6 Extension Headers . . . . . . . . . . . . . . . . . . . 5 65 3.1. General Discussion . . . . . . . . . . . . . . . . . . . 5 66 3.2. General Security Implications . . . . . . . . . . . . . . 5 67 3.3. Advice on the Handling of IPv6 Packets with Specific IPv6 68 Extension Headers . . . . . . . . . . . . . . . . . . . . 6 69 3.4. Advice on the Handling of Packets with Unknown IPv6 70 Extension Headers . . . . . . . . . . . . . . . . . . . . 14 71 4. IPv6 Options . . . . . . . . . . . . . . . . . . . . . . . . 15 72 4.1. General Discussion . . . . . . . . . . . . . . . . . . . 15 73 4.2. General Security Implications of IPv6 Options . . . . . . 15 74 4.3. Advice on the Handling of Packets with Specific IPv6 75 Options . . . . . . . . . . . . . . . . . . . . . . . . . 15 76 4.4. Advice on the handling of Packets with Unknown IPv6 77 Options . . . . . . . . . . . . . . . . . . . . . . . . . 26 78 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 27 79 6. Security Considerations . . . . . . . . . . . . . . . . . . . 27 80 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 27 81 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 27 82 8.1. Normative References . . . . . . . . . . . . . . . . . . 27 83 8.2. Informative References . . . . . . . . . . . . . . . . . 30 84 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 32 86 1. Introduction 88 Recent studies (see e.g. [RFC7872]) suggest that there is widespread 89 filtering of IPv6 packets that contain IPv6 Extension Headers (EHs). 90 While some operators "officially" filter packets that contain IPv6 91 EHs, it is possible that some of the measured packet drops be the 92 result of improper configuration defaults, or inappropriate advice in 93 this area. 95 This document analyzes both the general security implications of IPv6 96 EHs and the specific security implications of each EH and Option 97 type, and provides advice on the filtering of IPv6 packets based on 98 the IPv6 EHs and the IPv6 options they contain. Since various 99 protocols may use IPv6 EHs (possibly with IPv6 options), discarding 100 packets based on the IPv6 EHs or IPv6 options they contain may have 101 implications on the proper functioning of such protocols. Thus, this 102 document also attempts to discuss the operational and 103 interoperability implications of such filtering policies. This 104 document is similar in nature to [RFC7126], which addresses the same 105 problem for the IPv4 case. However, in IPv6, the problem space is 106 compounded by the fact that IPv6 specifies a number of IPv6 EHs, and 107 a number of IPv6 options which may be valid only when included in 108 specific EH types. 110 This document completes and complements the considerations for 111 protecting the control plane from packets containing IP options that 112 can be found in [RFC6192]. 114 Section 2 of this document specifies the terminology and conventions 115 employed throughout this document. Section 3 of this document 116 discusses IPv6 EHs and provides advice in the area of filtering IPv6 117 packets that contain such IPv6 EHs. Section 4 of this document 118 discusses IPv6 options and provides advice in the area of filtering 119 IPv6 packets that contain such options. 121 2. Terminology and Conventions Used in This Document 123 2.1. Terminology 125 The terms "fast path", "slow path", and associated relative terms 126 ("faster path" and "slower path") are loosely defined as in Section 2 127 of [RFC6398]. 129 The terms "permit" (allow the traffic), "drop" (drop with no 130 notification to sender), and "reject" (drop with appropriate 131 notification to sender) are employed as defined in [RFC3871]. 132 Throughout this document we also employ the term "discard" as a 133 generic term to indicate the act of discarding a packet, irrespective 134 of whether the sender is notified of such drops, and irrespective of 135 whether the specific filtering action is logged. 137 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 138 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 139 document are to be interpreted as described in [RFC2119]. 141 2.2. Conventions 143 This document assumes that nodes comply with the requirements in 144 [RFC7045]. Namely (from [RFC7045]), 146 o If a forwarding node discards a packet containing a standard IPv6 147 EH, it MUST be the result of a configurable policy and not just 148 the result of a failure to recognise such a header. 150 o The discard policy for each standard type of EH MUST be 151 individually configurable. 153 o The default configuration SHOULD allow all standard IPv6 EHs. 155 The advice provided in this document is only meant to guide an 156 operator in configuring forwarding devices, and is *not* to be 157 interpreted as advice regarding default configuration settings for 158 network devices. That is, this document provides advice with respect 159 to operational configurations, but does not change the implementation 160 defaults required by [RFC7045]. We note that the advice provided in 161 this document is *not* meant to be employed by transit routers for 162 transit traffic, since such devices should not enforce this type of 163 filtering policy on traffic not directed to them. 165 We recommend that configuration options are made available to govern 166 the processing of each IPv6 EH type and each IPv6 option type. Such 167 configuration options may include the following possible settings: 169 o Permit this IPv6 EH or IPv6 Option type 171 o Discard (and log) packets containing this IPv6 EH or option type 173 o Reject (and log) packets containing this IPv6 EH or option type 174 (where the packet drop is signaled with an ICMPv6 error message) 176 o Rate-limit traffic containing this IPv6 EH or option type 178 o Ignore this IPv6 EH or option type (as if it was not present) and 179 forward the packet. We note that if a packet carries forwarding 180 information (e.g., in an IPv6 Routing Header) this might be an 181 inappropriate or undesirable action. 183 We note that special care needs to be taken when devices log packet 184 drops/rejects. Devices should count the number of packets dropped/ 185 rejected, but the logging of drop/reject events should be limited so 186 as to not overburden device resources. 188 Finally, we note that when discarding packets, it is generally 189 desirable that the sender be signaled of the packet drop, since this 190 is of use for trouble-shooting purposes. However, throughout this 191 document (when recommending that packets be discarded) we generically 192 refer to the action as "discard" without specifying whether the 193 sender is signaled of the packet drop. 195 3. IPv6 Extension Headers 197 3.1. General Discussion 199 IPv6 [RFC2460] EHs allow for the extension of the IPv6 protocol. 200 Since both IPv6 EHs and upper-layer protocols share the same 201 namespace ("Next Header" registry/namespace), [RFC7045] identifies 202 which of the currently assigned Internet Protocol numbers identify 203 IPv6 EHs vs. upper-layer protocols. This document discusses the 204 filtering of packets based on the IPv6 EHs (as specified by 205 [RFC7045]) they contain. 207 NOTE: [RFC7112] specifies that non-fragmented IPv6 datagrams and 208 IPv6 First-Fragments MUST contain the entire IPv6 header chain 209 [RFC7112]. Therefore, intermediate systems can enforce the 210 filtering policies discussed in this document, or resort to simply 211 discarding the offending packets when they fail to comply with the 212 requirements in [RFC7112]. We note that, in order to implement 213 filtering rules on the fast path, it may be necessary for the 214 filtering device to limit the depth into the packet that can be 215 inspected before giving up. In circumstances where there is such 216 a limitation, it is recommended that implementations discard 217 packets if, when trying to determine whether to discard or permit 218 a packet, the aforementioned limit is encountered. 220 3.2. General Security Implications 222 Depending on the specific device architecture, IPv6 packets that 223 contain IPv6 EHs may cause the corresponding packets to be processed 224 on the slow path, and hence may be leveraged for the purpose of 225 Denial of Service (DoS) attacks 226 [I-D.gont-v6ops-ipv6-ehs-packet-drops] [Cisco-EH] [FW-Benchmark]. 228 Operators are urged to consider IPv6 EH filtering and IPv6 options 229 handling capabilities of different devices as they make deployment 230 decisions in future. 232 3.3. Advice on the Handling of IPv6 Packets with Specific IPv6 233 Extension Headers 235 3.3.1. IPv6 Hop-by-Hop Options (Protocol Number=0) 237 3.3.1.1. Uses 239 The Hop-by-Hop Options header is used to carry optional information 240 that should be examined by every node along a packet's delivery path. 242 3.3.1.2. Specification 244 This EH is specified in [RFC2460], and its processing rules have been 245 updated by [RFC7045]. At the time of this writing, the following 246 options have been specified for the Hop-by-Hop Options EH: 248 o Type 0x00: Pad1 [RFC2460] 250 o Type 0x01: PadN [RFC2460] 252 o Type 0x05: Router Alert [RFC2711] 254 o Type 0x07: CALIPSO [RFC5570] 256 o Type 0x08: SMF_DPD [RFC6621] 258 o Type 0x26: Quick-Start [RFC4782] 260 o Type 0x4D: (Deprecated) 262 o Type 0x63: RPL Option [RFC6553] 264 o Type 0x6D: MPL Option [RFC7731] 266 o Type 0x8A: Endpoint Identification (Deprecated) 267 [draft-ietf-nimrod-eid] 269 o Type 0xC2: Jumbo Payload [RFC2675] 271 o Type 0xEE: IPv6 DFF Header [RFC6971] 273 o Type 0x1E: RFC3692-style Experiment [RFC4727] 275 o Type 0x3E: RFC3692-style Experiment [RFC4727] 277 o Type 0x5E: RFC3692-style Experiment [RFC4727] 279 o Type 0x7E: RFC3692-style Experiment [RFC4727] 280 o Type 0x9E: RFC3692-style Experiment [RFC4727] 282 o Type 0xBE: RFC3692-style Experiment [RFC4727] 284 o Type 0xDE: RFC3692-style Experiment [RFC4727] 286 o Type 0xFE: RFC3692-style Experiment [RFC4727] 288 3.3.1.3. Specific Security Implications 290 Since this EH is required to be processed by all intermediate-systems 291 en route, it can be leveraged to perform Denial of Service attacks 292 against the network infrastructure. 294 NOTE: Ongoing work essentially aims at requiring the Hop-by-Hop 295 Option EH to be processed only in cases where the intermmediate node 296 is making use of any functionality provided by such header (see 297 [I-D.ietf-6man-hbh-header-handling]). However, the deployed base is 298 likely to reflect the traditional behavior for a while, and hence the 299 potential security problems of this EH are still of concern. 301 3.3.1.4. Operational and Interoperability Impact if Blocked 303 Discarding packets containing a Hop-by-Hop Options EH would break any 304 of the protocols that rely on it for proper functioning. For 305 example, it would break RSVP [RFC2205] and multicast deployments, and 306 would cause IPv6 jumbograms to be discarded. 308 3.3.1.5. Advice 310 The recommended configuration for the processing of these packets 311 depends on the features and capabilities of the underlying platform. 312 On platforms that allow forwarding of packets with HBH Options on the 313 fast path, we recommend that packets with a HBH Options EH be 314 forwarded as normal (for instance, [RFC7045] allows for 315 implementations to ignore the HBH Options EH when forwarding 316 packets). Otherwise, on platforms in which processing of packets 317 with a IPv6 HBH Options EH is carried out in the slow path, and an 318 option is provided to rate-limit these packets, we recommend that 319 this option be selected. Finally, when packets containing a HBH 320 Options EH are processed in the slow-path, and the underlying 321 platform does not have any mitigation options available for attacks 322 based on these packets, we recommend that such platforms discard 323 packets containing IPv6 HBH Options EHs. 325 Finally, we note that, for obvious reasons, RPL (Routing Protocol for 326 Low-Power and Lossy Networks) [RFC6550] routers must not discard 327 packets based on the presence of an IPv6 Hop-by-Hop Options EH. 329 3.3.2. Routing Header for IPv6 (Protocol Number=43) 331 3.3.2.1. Uses 333 The Routing header is used by an IPv6 source to list one or more 334 intermediate nodes to be "visited" on the way to a packet's 335 destination. 337 3.3.2.2. Specification 339 This EH is specified in [RFC2460]. [RFC2460] originally specified 340 the Routing Header Type 0, which has been later obsoleted by 341 [RFC5095]. 343 At the time of this writing, the following Routing Types have been 344 specified: 346 o Type 0: Source Route (DEPRECATED) [RFC2460] [RFC5095] 348 o Type 1: Nimrod (DEPRECATED) 350 o Type 2: Type 2 Routing Header [RFC6275] 352 o Type 3: RPL Source Route Header [RFC6554] 354 o Types 4-252: Unassigned 356 o Type 253: RFC3692-style Experiment 1 [RFC4727] 358 o Type 254: RFC3692-style Experiment 2 [RFC4727] 360 o Type 255: Reserved 362 3.3.2.3. Specific Security Implications 364 The security implications of RHT0 have been discussed in detail in 365 [Biondi2007] and [RFC5095]. 367 3.3.2.4. Operational and Interoperability Impact if Blocked 369 Blocking packets containing a RHT0 or RTH1 has no operational 370 implications. However, blocking packets employing other routing 371 header types will break the protocols that rely on them. 373 3.3.2.5. Advice 375 Intermediate systems should discard packets containing a RHT0 or 376 RHT1. RHT2 and RHT3 should be permitted, as required by [RFC7045]. 377 Other routing header types should be discarded. 379 3.3.3. Fragment Header for IPv6 (Protocol Number=44) 381 3.3.3.1. Uses 383 This EH provides the fragmentation functionality for IPv6. 385 3.3.3.2. Specification 387 This EH is specified in [RFC2460]. 389 3.3.3.3. Specific Security Implications 391 The security implications of the Fragment Header range from Denial of 392 Service attacks (e.g. based on flooding a target with IPv6 fragments) 393 to information leakage attacks [RFC7739]. 395 3.3.3.4. Operational and Interoperability Impact if Blocked 397 Blocking packets that contain a Fragment Header will break any 398 protocol that may rely on fragmentation (e.g., the DNS [RFC1034]). 400 3.3.3.5. Advice 402 Intermediate systems should permit packets that contain a Fragment 403 Header. 405 3.3.4. Encapsulating Security Payload (Protocol Number=50) 407 3.3.4.1. Uses 409 This EH is employed for the IPsec suite [RFC4303]. 411 3.3.4.2. Specification 413 This EH is specified in [RFC4303]. 415 3.3.4.3. Specific Security Implications 417 Besides the general implications of IPv6 EHs, this EH could be 418 employed to potentially perform a DoS attack at the destination 419 system by wasting CPU resources in validating the contents of the 420 packet. 422 3.3.4.4. Operational and Interoperability Impact if Blocked 424 Discarding packets that employ this EH would break IPsec deployments. 426 3.3.4.5. Advice 428 Intermediate systems should permit packets containing the 429 Encapsulating Security Payload EH. 431 3.3.5. Authentication Header (Number=51) 433 3.3.5.1. Uses 435 The Authentication Header can be employed for provide authentication 436 services in IPv4 and IPv6. 438 3.3.5.2. Specification 440 This EH is specified in [RFC4302]. 442 3.3.5.3. Specific Security Implications 444 Besides the general implications of IPv6 EHs, this EH could be 445 employed to potentially perform a DoS attack at the destination 446 system by wasting CPU resources in validating the contents of the 447 packet. 449 3.3.5.4. Operational and Interoperability Impact if Blocked 451 Discarding packets that employ this EH would break IPsec deployments. 453 3.3.5.5. Advice 455 Intermediate systems should permit packets containing an 456 Authentication Header. 458 3.3.6. Destination Options for IPv6 (Protocol Number=60) 460 3.3.6.1. Uses 462 The Destination Options header is used to carry optional information 463 that needs be examined only by a packet's destination node(s). 465 3.3.6.2. Specification 467 This EH is specified in [RFC2460]. At the time of this writing, the 468 following options have been specified for this EH: 470 o Type 0x00: Pad1 [RFC2460] 472 o Type 0x01: PadN [RFC2460] 474 o Type 0x04: Tunnel Encapsulation Limit [RFC2473] 476 o Type 0x4D: (Deprecated) 478 o Type 0xC9: Home Address [RFC6275] 480 o Type 0x8A: Endpoint Identification (Deprecated) 481 [draft-ietf-nimrod-eid] 483 o Type 0x8B: ILNP Nonce [RFC6744] 485 o Type 0x8C: Line-Identification Option [RFC6788] 487 o Type 0x1E: RFC3692-style Experiment [RFC4727] 489 o Type 0x3E: RFC3692-style Experiment [RFC4727] 491 o Type 0x5E: RFC3692-style Experiment [RFC4727] 493 o Type 0x7E: RFC3692-style Experiment [RFC4727] 495 o Type 0x9E: RFC3692-style Experiment [RFC4727] 497 o Type 0xBE: RFC3692-style Experiment [RFC4727] 499 o Type 0xDE: RFC3692-style Experiment [RFC4727] 501 o Type 0xFE: RFC3692-style Experiment [RFC4727] 503 3.3.6.3. Specific Security Implications 505 No security implications are known, other than the general 506 implications of IPv6 EHs. For a discussion of possible security 507 implications of specific options specified for the DO header, please 508 see the Section 4.3. 510 3.3.6.4. Operational and Interoperability Impact if Blocked 512 Discarding packets that contain a Destination Options header would 513 break protocols that rely on this EH type for conveying information, 514 including protocols such as ILNP [RFC6740] and Mobile IPv6 [RFC6275], 515 and IPv6 tunnels that employ the Tunnel Encapsulation Limit option. 517 3.3.6.5. Advice 519 Intermediate systems should permit packets that contain a Destination 520 Options Header. 522 3.3.7. Mobility Header (Number=135) 524 3.3.7.1. Uses 526 The Mobility Header is an EH used by mobile nodes, correspondent 527 nodes, and home agents in all messaging related to the creation and 528 management of bindings in Mobile IPv6. 530 3.3.7.2. Specification 532 This EH is specified in [RFC6275]. 534 3.3.7.3. Specific Security Implications 536 A thorough security assessment of the security implications of the 537 Mobility Header and related mechanisms can be found in Section 15 of 538 [RFC6275]. 540 3.3.7.4. Operational and Interoperability Impact if Blocked 542 Discarding packets containing this EH would break Mobile IPv6. 544 3.3.7.5. Advice 546 Intermediate systems should permit packets containing this EH. 548 3.3.8. Host Identity Protocol (Protocol Number=139) 550 3.3.8.1. Uses 552 This EH is employed with the Host Identity Protocol (HIP), an 553 experimental protocol that allows consenting hosts to securely 554 establish and maintain shared IP-layer state, allowing separation of 555 the identifier and locator roles of IP addresses, thereby enabling 556 continuity of communications across IP address changes. 558 3.3.8.2. Specification 560 This EH is specified in [RFC5201]. 562 3.3.8.3. Specific Security Implications 564 The security implications of the HIP header are discussed in detail 565 in Section 8 of [RFC6275]. 567 3.3.8.4. Operational and Interoperability Impact if Blocked 569 Discarding packets that contain the Host Identity Protocol would 570 break HIP deployments. 572 3.3.8.5. Advice 574 Intermediate systems should permit packets that contain a Host 575 Identity Protocol EH. 577 3.3.9. Shim6 Protocol (Protocol Number=140) 579 3.3.9.1. Uses 581 This EH is employed by the Shim6 [RFC5533] Protocol. 583 3.3.9.2. Specification 585 This EH is specified in [RFC5533]. 587 3.3.9.3. Specific Security Implications 589 The specific security implications are discussed in detail in 590 Section 16 of [RFC5533]. 592 3.3.9.4. Operational and Interoperability Impact if Blocked 594 Discarding packets that contain this EH will break Shim6. 596 3.3.9.5. Advice 598 Intermediate systems should permit packets containing this EH. 600 3.3.10. Use for experimentation and testing (Protocol Numbers=253 and 601 254) 603 3.3.10.1. Uses 605 These IPv6 EHs are employed for performing RFC3692-Style experiments 606 (see [RFC3692] for details). 608 3.3.10.2. Specification 610 These EHs are specified in [RFC3692] and [RFC4727]. 612 3.3.10.3. Specific Security Implications 614 The security implications of these EHs will depend on their specific 615 use. 617 3.3.10.4. Operational and Interoperability Impact if Blocked 619 For obvious reasons, discarding packets that contain these EHs limits 620 the ability to perform legitimate experiments across IPv6 routers. 622 3.3.10.5. Advice 624 Intermediate systems should discard packets containing these EHs. 625 Only in specific scenarios in which RFC3692-Style experiments are to 626 be performed should these EHs be permitted. 628 3.4. Advice on the Handling of Packets with Unknown IPv6 Extension 629 Headers 631 We refer to IPv6 EHs that have not been assigned an Internet Protocol 632 Number by IANA (and marked as such) in [IANA-PROTOCOLS] as "unknown 633 IPv6 extension headers" ("unknown IPv6 EHs"). 635 3.4.1. Uses 637 New IPv6 EHs may be specified as part of future extensions to the 638 IPv6 protocol. 640 Since IPv6 EHs and Upper-layer protocols employ the same namespace, 641 it is impossible to tell whether an unknown "Internet Protocol 642 Number" is being employed for an IPv6 EH or an Upper-Layer protocol. 644 3.4.2. Specification 646 The processing of unknown IPv6 EHs is specified in [RFC2460] and 647 [RFC7045]. 649 3.4.3. Specific Security Implications 651 For obvious reasons, it is impossible to determine specific security 652 implications of unknown IPv6 EHs. However, from security standpoint, 653 a device should discard IPv6 extension headers for which the security 654 implications cannot be determined. We note that this policy is 655 allowed by [RFC7045]. 657 3.4.4. Operational and Interoperability Impact if Blocked 659 As noted in [RFC7045], discarding unknown IPv6 EHs may slow down the 660 deployment of new IPv6 EHs and transport protocols. The 661 corresponding IANA registry ([IANA-PROTOCOLS]) should be monitored 662 such that filtering rules are updated as new IPv6 EHs are 663 standardized. 665 We note that since IPv6 EHs and upper-layer protocols share the same 666 numbering space, discarding unknown IPv6 EHs may result in packets 667 encapsulating unknown upper-layer protocols being discarded. 669 3.4.5. Advice 671 Intermediate systems should discard packets containing unknown IPv6 672 EHs. 674 4. IPv6 Options 676 4.1. General Discussion 678 The following subsections describe specific security implications of 679 different IPv6 options, and provide advice regarding filtering 680 packets that contain such options. 682 4.2. General Security Implications of IPv6 Options 684 The general security implications of IPv6 options are closely related 685 to those discussed in Section 3.2 for IPv6 EHs. Essentially, packets 686 that contain IPv6 options might need to be processed by an IPv6 687 router's general-purpose CPU,and hence could present a DDoS risk to 688 that router's general-purpose CPU (and thus to the router itself). 689 For some architectures, a possible mitigation would be to rate-limit 690 the packets that are to be processed by the general-purpose CPU (see 691 e.g. [Cisco-EH]). 693 4.3. Advice on the Handling of Packets with Specific IPv6 Options 695 The following subsections contain a description of each of the IPv6 696 options that have so far been specified, a summary of the security 697 implications of each of such options, a discussion of possible 698 interoperability implications if packets containing such options are 699 discarded, and specific advice regarding whether packets containing 700 these options should be permitted. 702 4.3.1. Pad1 (Type=0x00) 704 4.3.1.1. Uses 706 This option is used when necessary to align subsequent options and to 707 pad out the containing header to a multiple of 8 octets in length. 709 4.3.1.2. Specification 711 This option is specified in [RFC2460]. 713 4.3.1.3. Specific Security Implications 715 None. 717 4.3.1.4. Operational and Interoperability Impact if Blocked 719 Discarding packets that contain this option would potentially break 720 any protocol that relies on IPv6 EHs. 722 4.3.1.5. Advice 724 Intermediate systems should not discard packets based on the presence 725 of this option. 727 4.3.2. PadN (Type=0x01) 729 4.3.2.1. Uses 731 This option is used when necessary to align subsequent options and to 732 pad out the containing header to a multiple of 8 octets in length. 734 4.3.2.2. Specification 736 This option is specified in [RFC2460]. 738 4.3.2.3. Specific Security Implications 740 Because of the possible size of this option, it could be leveraged as 741 a large-bandwidth covert channel. 743 4.3.2.4. Operational and Interoperability Impact if Blocked 745 Discarding packets that contain this option would potentially break 746 any protocol that relies on IPv6 EHs. 748 4.3.2.5. Advice 750 Intermediate systems should not discard IPv6 packets based on the 751 presence of this option. 753 4.3.3. Jumbo Payload (Type=0XC2) 755 4.3.3.1. Uses 757 The Jumbo payload option provides the means of specifying payloads 758 larger than 65535 bytes. 760 4.3.3.2. Specification 762 This option is specified in [RFC2675]. 764 4.3.3.3. Specific Security Implications 766 There are no specific issues arising from this option, except for 767 improper validity checks of the option and associated packet lengths. 769 4.3.3.4. Operational and Interoperability Impact if Blocked 771 Discarding packets based on the presence of this option will cause 772 IPv6 jumbograms to be discarded. 774 4.3.3.5. Advice 776 Intermediate systems should discard packets that contain this option. 777 An operator should permit this option only in specific scenarios in 778 which support for IPv6 jumbograms is desired. 780 4.3.4. RPL Option (Type=0x63) 782 4.3.4.1. Uses 784 The RPL Option provides a mechanism to include routing information 785 with each datagram that an RPL router forwards. 787 4.3.4.2. Specification 789 This option is specified in [RFC6553]. 791 4.3.4.3. Specific Security Implications 793 Those described in [RFC6553]. 795 4.3.4.4. Operational and Interoperability Impact if Blocked 797 This option is meant to be employed within an RPL instance. As a 798 result, discarding packets based on the presence of this option (e.g. 799 at an ISP) will not result in interoperability implications. 801 4.3.4.5. Advice 803 Non-RPL routers should discard packets that contain an RPL option. 805 4.3.5. Tunnel Encapsulation Limit (Type=0x04) 807 4.3.5.1. Uses 809 The Tunnel Encapsulation Limit option can be employed to specify how 810 many further levels of nesting the packet is permitted to undergo. 812 4.3.5.2. Specification 814 This option is specified in [RFC2473]. 816 4.3.5.3. Specific Security Implications 818 Those described in [RFC2473]. 820 4.3.5.4. Operational and Interoperability Impact if Blocked 822 Discarding packets based on the presence of this option could result 823 in tunnel traffic being discarded. 825 4.3.5.5. Advice 827 Intermediate systems should not discard packets based on the presence 828 of this option. 830 4.3.6. Router Alert (Type=0x05) 832 4.3.6.1. Uses 834 The Router Alert option [RFC2711] is typically employed for the RSVP 835 protocol [RFC2205] and the MLD protocol [RFC2710]. 837 4.3.6.2. Specification 839 This option is specified in [RFC2711]. 841 4.3.6.3. Specific Security Implications 843 Since this option causes the contents of the packet to be inspected 844 by the handling device, this option could be leveraged for performing 845 DoS attacks. 847 4.3.6.4. Operational and Interoperability Impact if Blocked 849 Discarding packets that contain this option would break RSVP and 850 multicast deployments. 852 4.3.6.5. Advice 854 Intermediate systems should discard packets that contain this option. 855 Only in specific environments where support for RSVP, multicast 856 routing, or similar protocols is desired, should this option be 857 permitted. 859 4.3.7. Quick-Start (Type=0x26) 861 4.3.7.1. Uses 863 This IP Option is used in the specification of Quick-Start for TCP 864 and IP, which is an experimental mechanism that allows transport 865 protocols, in cooperation with routers, to determine an allowed 866 sending rate at the start and, at times, in the middle of a data 867 transfer (e.g., after an idle period) [RFC4782]. 869 4.3.7.2. Specification 871 This option is specified in [RFC4782], on the "Experimental" track. 873 4.3.7.3. Specific Security Implications 875 Section 9.6 of [RFC4782] notes that Quick-Start is vulnerable to two 876 kinds of attacks: 878 o attacks to increase the routers' processing and state load, and, 880 o attacks with bogus Quick-Start Requests to temporarily tie up 881 available Quick-Start bandwidth, preventing routers from approving 882 Quick-Start Requests from other connections. 884 We note that if routers in a given environment do not implement and 885 enable the Quick-Start mechanism, only the general security 886 implications of IP options (discussed in Section 4.2) would apply. 888 4.3.7.4. Operational and Interoperability Impact if Blocked 890 The Quick-Start functionality would be disabled, and additional 891 delays in TCP's connection establishment (for example) could be 892 introduced. (Please see Section 4.7.2 of [RFC4782].) We note, 893 however, that Quick-Start has been proposed as a mechanism that could 894 be of use in controlled environments, and not as a mechanism that 895 would be intended or appropriate for ubiquitous deployment in the 896 global Internet [RFC4782]. 898 4.3.7.5. Advice 900 Intermediate systems should not discard IPv6 packets based on the 901 presence of this option. 903 4.3.8. CALIPSO (Type=0x07) 905 4.3.8.1. Uses 907 This option is used for encoding explicit packet Sensitivity Labels 908 on IPv6 packets. It is intended for use only within Multi-Level 909 Secure (MLS) networking environments that are both trusted and 910 trustworthy. 912 4.3.8.2. Specification 914 This option is specified in [RFC5570]. 916 4.3.8.3. Specific Security Implications 918 Presence of this option in a packet does not by itself create any 919 specific new threat. Packets with this option ought not normally be 920 seen on the global public Internet. 922 4.3.8.4. Operational and Interoperability Impact if Blocked 924 If packets with this option are discarded or if the option is 925 stripped from the packet during transmission from source to 926 destination, then the packet itself is likely to be discarded by the 927 receiver because it is not properly labeled. In some cases, the 928 receiver might receive the packet but associate an incorrect 929 sensitivity label with the received data from the packet whose 930 CALIPSO was stripped by an intermediate router or firewall. 931 Associating an incorrect sensitivity label can cause the received 932 information either to be handled as more sensitive than it really is 933 ("upgrading") or as less sensitive than it really is ("downgrading"), 934 either of which is problematic. 936 4.3.8.5. Advice 938 Intermediate systems that do not operate in Multi-Level Secure (MLS) 939 networking environments should discard packets that contain this 940 option. 942 4.3.9. SMF_DPD (Type=0x08) 944 4.3.9.1. Uses 946 This option is employed in the (experimental) Simplified Multicast 947 Forwarding (SMF) for unique packet identification for IPv6 I-DPD, and 948 as a mechanism to guarantee non-collision of hash values for 949 different packets when H-DPD is used. 951 4.3.9.2. Specification 953 This option is specified in [RFC6621]. 955 4.3.9.3. Specific Security Implications 957 TBD. 959 4.3.9.4. Operational and Interoperability Impact if Blocked 961 TBD. 963 4.3.9.5. Advice 965 TBD. 967 4.3.10. Home Address (Type=0xC9) 969 4.3.10.1. Uses 971 The Home Address option is used by a Mobile IPv6 node while away from 972 home, to inform the recipient of the mobile node's home address. 974 4.3.10.2. Specification 976 This option is specified in [RFC6275]. 978 4.3.10.3. Specific Security Implications 980 No (known) additional security implications than those described in 981 [RFC6275]. 983 4.3.10.4. Operational and Interoperability Impact if Blocked 985 Discarding IPv6 packets based on the presence of this option will 986 break Mobile IPv6. 988 4.3.10.5. Advice 990 Intermediate systems should not discard IPv6 packets based on the 991 presence of this option. 993 4.3.11. Endpoint Identification (Type=0x8A) 995 4.3.11.1. Uses 997 The Endpoint Identification option was meant to be used with the 998 Nimrod routing architecture [NIMROD-DOC], but has never seen 999 widespread deployment. 1001 4.3.11.2. Specification 1003 This option is specified in [NIMROD-DOC]. 1005 4.3.11.3. Specific Security Implications 1007 TBD. 1009 4.3.11.4. Operational and Interoperability Impact if Blocked 1011 None. 1013 4.3.11.5. Advice 1015 Intermediate systems should discard packets that contain this option. 1017 4.3.12. ILNP Nonce (Type=0x8B) 1019 4.3.12.1. Uses 1021 This option is employed by Identifier-Locator Network Protocol for 1022 IPv6 (ILNPv6) for providing protection against off-path attacks for 1023 packets when ILNPv6 is in use, and as a signal during initial 1024 network-layer session creation that ILNPv6 is proposed for use with 1025 this network-layer session, rather than classic IPv6. 1027 4.3.12.2. Specification 1029 This option is specified in [RFC6744]. 1031 4.3.12.3. Specific Security Implications 1033 Those described in [RFC6744]. 1035 4.3.12.4. Operational and Interoperability Impact if Blocked 1037 Discarding packets that contain this option will break INLPv6 1038 deployments. 1040 4.3.12.5. Advice 1042 Intermediate systems should not discard packets based on the presence 1043 of this option. 1045 4.3.13. Line-Identification Option (Type=0x8C) 1047 4.3.13.1. Uses 1049 This option is used by an Edge Router to identify the subscriber 1050 premises in scenarios where several subscriber premises may be 1051 logically connected to the same interface of an Edge Router. 1053 4.3.13.2. Specification 1055 This option is specified in [RFC6788]. 1057 4.3.13.3. Specific Security Implications 1059 Those described in [RFC6788]. 1061 4.3.13.4. Operational and Interoperability Impact if Blocked 1063 Since this option is meant to be employed in Router Solicitation 1064 messages, discarding packets based on the presence of this option at 1065 intermediate systems will result in no interoperability implications. 1067 4.3.13.5. Advice 1069 Intermediate devices should discard packets that contain this option. 1071 4.3.14. Deprecated (Type=0x4D) 1073 4.3.14.1. Uses 1075 No information has been found about this option type. 1077 4.3.14.2. Specification 1079 No information has been found about this option type. 1081 4.3.14.3. Specific Security Implications 1083 No information has been found about this option type, and hence it 1084 has been impossible to perform the corresponding security assessment. 1086 4.3.14.4. Operational and Interoperability Impact if Blocked 1088 Unknown. 1090 4.3.14.5. Advice 1092 Intermediate systems should discard packets that contain this option. 1094 4.3.15. MPL Option (Type=0x6D) 1096 4.3.15.1. Uses 1098 This option is used with the Multicast Protocol for Low power and 1099 Lossy Networks (MPL), that provides IPv6 multicast forwarding in 1100 constrained networks. 1102 4.3.15.2. Specification 1104 This option is specified in [RFC7731], and is meant to be included 1105 only in Hop-by-Hop Option headers. 1107 4.3.15.3. Specific Security Implications 1109 Those described in [RFC7731]. 1111 4.3.15.4. Operational and Interoperability Impact if Blocked 1113 TBD. 1115 4.3.15.5. Advice 1117 TBD. 1119 4.3.16. IP_DFF (Type=0xEE) 1121 4.3.16.1. Uses 1123 This option is employed with the (Experimental) Depth-First 1124 Forwarding (DFF) in Unreliable Networks. 1126 4.3.16.2. Specification 1128 This option is specified in [RFC6971]. 1130 4.3.16.3. Specific Security Implications 1132 Those specified in [RFC6971]. 1134 4.3.16.4. Operational and Interoperability Impact if Blocked 1136 TBD. 1138 4.3.16.5. Advice 1140 TBD. 1142 4.3.17. RFC3692-style Experiment (Types = 0x1E, 0x3E, 0x5E, 0x7E, 0x9E, 1143 0xBE, 0xDE, 0xFE) 1145 4.3.17.1. Uses 1147 These options can be employed for performing RFC3692-style 1148 experiments. It is only appropriate to use these values in 1149 explicitly configured experiments; they must not be shipped as 1150 defaults in implementations. 1152 4.3.17.2. Specification 1154 Specified in RFC 4727 [RFC4727] in the context of RFC3692-style 1155 experiments. 1157 4.3.17.3. Specific Security Implications 1159 The specific security implications will depend on the specific use of 1160 these options. 1162 4.3.17.4. Operational and Interoperability Impact if Blocked 1164 For obvious reasons, discarding packets that contain these options 1165 limits the ability to perform legitimate experiments across IPv6 1166 routers. 1168 4.3.17.5. Advice 1170 Intermediate systems should discard packets that contain these 1171 options. Only in specific environments where RFC3692-style 1172 experiments are meant to be performed should these options be 1173 permitted. 1175 4.4. Advice on the handling of Packets with Unknown IPv6 Options 1177 We refer to IPv6 options that have not been assigned an IPv6 option 1178 type in the corresponding registry ([IANA-IPV6-PARAM]) as "unknown 1179 IPv6 options". 1181 4.4.1. Uses 1183 New IPv6 options may be specified as part of future protocol work. 1185 4.4.2. Specification 1187 The processing of unknown IPv6 options is specified in [RFC2460]. 1189 4.4.3. Specific Security Implications 1191 For obvious reasons, it is impossible to determine specific security 1192 implications of unknown IPv6 options. 1194 4.4.4. Operational and Interoperability Impact if Blocked 1196 Discarding unknown IPv6 options may slow down the deployment of new 1197 IPv6 options. As noted in [draft-gont-6man-ipv6-opt-transmit], the 1198 corresponding IANA registry ([IANA-IPV6-PARAM] should be monitored 1199 such that IPv6 option filtering rules are updated as new IPv6 options 1200 are standardized. 1202 4.4.5. Advice 1204 Enterprise intermediate systems that process the contents of IPv6 EHs 1205 should discard packets that contain unknown options. Other 1206 intermediate systems that process the contents of IPv6 EHs should 1207 permit packets that contain unknown options. 1209 5. IANA Considerations 1211 This document has no actions for IANA. 1213 6. Security Considerations 1215 This document provides advice on the filtering of IPv6 packets that 1216 contain IPv6 EHs (and possibly IPv6 options). Discarding such 1217 packets can help to mitigate the security issues that arise from the 1218 use of different IPv6 EHs and options. 1220 7. Acknowledgements 1222 The authors of this document would like to thank (in alphabetical 1223 order) Mikael Abrahamsson, Brian Carpenter, Mike Heard, Jen Linkova, 1224 Carlos Pignataro, Donald Smith, and Gunter Van De Velde, for 1225 providing valuable comments on earlier versions of this document. 1227 This document borrows some text an analysis from [RFC7126], authored 1228 by Fernando Gont, Randall Atkinson, and Carlos Pignataro. 1230 8. References 1232 8.1. Normative References 1234 [draft-gont-6man-ipv6-opt-transmit] 1235 Gont, F., Liu, W., and R. Bonica, "Transmission and 1236 Processing of IPv6 Options", IETF Internet Draft, work in 1237 progress, August 2014. 1239 [RFC1034] Mockapetris, P., "Domain names - concepts and facilities", 1240 STD 13, RFC 1034, DOI 10.17487/RFC1034, November 1987, 1241 . 1243 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1244 Requirement Levels", BCP 14, RFC 2119, 1245 DOI 10.17487/RFC2119, March 1997, 1246 . 1248 [RFC2205] Braden, R., Ed., Zhang, L., Berson, S., Herzog, S., and S. 1249 Jamin, "Resource ReSerVation Protocol (RSVP) -- Version 1 1250 Functional Specification", RFC 2205, DOI 10.17487/RFC2205, 1251 September 1997, . 1253 [RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6 1254 (IPv6) Specification", RFC 2460, DOI 10.17487/RFC2460, 1255 December 1998, . 1257 [RFC2473] Conta, A. and S. Deering, "Generic Packet Tunneling in 1258 IPv6 Specification", RFC 2473, DOI 10.17487/RFC2473, 1259 December 1998, . 1261 [RFC2675] Borman, D., Deering, S., and R. Hinden, "IPv6 Jumbograms", 1262 RFC 2675, DOI 10.17487/RFC2675, August 1999, 1263 . 1265 [RFC2710] Deering, S., Fenner, W., and B. Haberman, "Multicast 1266 Listener Discovery (MLD) for IPv6", RFC 2710, 1267 DOI 10.17487/RFC2710, October 1999, 1268 . 1270 [RFC2711] Partridge, C. and A. Jackson, "IPv6 Router Alert Option", 1271 RFC 2711, DOI 10.17487/RFC2711, October 1999, 1272 . 1274 [RFC3692] Narten, T., "Assigning Experimental and Testing Numbers 1275 Considered Useful", BCP 82, RFC 3692, 1276 DOI 10.17487/RFC3692, January 2004, 1277 . 1279 [RFC4302] Kent, S., "IP Authentication Header", RFC 4302, 1280 DOI 10.17487/RFC4302, December 2005, 1281 . 1283 [RFC4303] Kent, S., "IP Encapsulating Security Payload (ESP)", 1284 RFC 4303, DOI 10.17487/RFC4303, December 2005, 1285 . 1287 [RFC4304] Kent, S., "Extended Sequence Number (ESN) Addendum to 1288 IPsec Domain of Interpretation (DOI) for Internet Security 1289 Association and Key Management Protocol (ISAKMP)", 1290 RFC 4304, DOI 10.17487/RFC4304, December 2005, 1291 . 1293 [RFC4727] Fenner, B., "Experimental Values In IPv4, IPv6, ICMPv4, 1294 ICMPv6, UDP, and TCP Headers", RFC 4727, 1295 DOI 10.17487/RFC4727, November 2006, 1296 . 1298 [RFC4782] Floyd, S., Allman, M., Jain, A., and P. Sarolahti, "Quick- 1299 Start for TCP and IP", RFC 4782, DOI 10.17487/RFC4782, 1300 January 2007, . 1302 [RFC5095] Abley, J., Savola, P., and G. Neville-Neil, "Deprecation 1303 of Type 0 Routing Headers in IPv6", RFC 5095, 1304 DOI 10.17487/RFC5095, December 2007, 1305 . 1307 [RFC5201] Moskowitz, R., Nikander, P., Jokela, P., Ed., and T. 1308 Henderson, "Host Identity Protocol", RFC 5201, 1309 DOI 10.17487/RFC5201, April 2008, 1310 . 1312 [RFC5533] Nordmark, E. and M. Bagnulo, "Shim6: Level 3 Multihoming 1313 Shim Protocol for IPv6", RFC 5533, DOI 10.17487/RFC5533, 1314 June 2009, . 1316 [RFC5570] StJohns, M., Atkinson, R., and G. Thomas, "Common 1317 Architecture Label IPv6 Security Option (CALIPSO)", 1318 RFC 5570, DOI 10.17487/RFC5570, July 2009, 1319 . 1321 [RFC6275] Perkins, C., Ed., Johnson, D., and J. Arkko, "Mobility 1322 Support in IPv6", RFC 6275, DOI 10.17487/RFC6275, July 1323 2011, . 1325 [RFC6398] Le Faucheur, F., Ed., "IP Router Alert Considerations and 1326 Usage", BCP 168, RFC 6398, DOI 10.17487/RFC6398, October 1327 2011, . 1329 [RFC6550] Winter, T., Ed., Thubert, P., Ed., Brandt, A., Hui, J., 1330 Kelsey, R., Levis, P., Pister, K., Struik, R., Vasseur, 1331 JP., and R. Alexander, "RPL: IPv6 Routing Protocol for 1332 Low-Power and Lossy Networks", RFC 6550, 1333 DOI 10.17487/RFC6550, March 2012, 1334 . 1336 [RFC6553] Hui, J. and JP. Vasseur, "The Routing Protocol for Low- 1337 Power and Lossy Networks (RPL) Option for Carrying RPL 1338 Information in Data-Plane Datagrams", RFC 6553, 1339 DOI 10.17487/RFC6553, March 2012, 1340 . 1342 [RFC6554] Hui, J., Vasseur, JP., Culler, D., and V. Manral, "An IPv6 1343 Routing Header for Source Routes with the Routing Protocol 1344 for Low-Power and Lossy Networks (RPL)", RFC 6554, 1345 DOI 10.17487/RFC6554, March 2012, 1346 . 1348 [RFC6621] Macker, J., Ed., "Simplified Multicast Forwarding", 1349 RFC 6621, DOI 10.17487/RFC6621, May 2012, 1350 . 1352 [RFC6740] Atkinson, RJ. and SN. Bhatti, "Identifier-Locator Network 1353 Protocol (ILNP) Architectural Description", RFC 6740, 1354 DOI 10.17487/RFC6740, November 2012, 1355 . 1357 [RFC6744] Atkinson, RJ. and SN. Bhatti, "IPv6 Nonce Destination 1358 Option for the Identifier-Locator Network Protocol for 1359 IPv6 (ILNPv6)", RFC 6744, DOI 10.17487/RFC6744, November 1360 2012, . 1362 [RFC6788] Krishnan, S., Kavanagh, A., Varga, B., Ooghe, S., and E. 1363 Nordmark, "The Line-Identification Option", RFC 6788, 1364 DOI 10.17487/RFC6788, November 2012, 1365 . 1367 [RFC6971] Herberg, U., Ed., Cardenas, A., Iwao, T., Dow, M., and S. 1368 Cespedes, "Depth-First Forwarding (DFF) in Unreliable 1369 Networks", RFC 6971, DOI 10.17487/RFC6971, June 2013, 1370 . 1372 [RFC7045] Carpenter, B. and S. Jiang, "Transmission and Processing 1373 of IPv6 Extension Headers", RFC 7045, 1374 DOI 10.17487/RFC7045, December 2013, 1375 . 1377 [RFC7112] Gont, F., Manral, V., and R. Bonica, "Implications of 1378 Oversized IPv6 Header Chains", RFC 7112, 1379 DOI 10.17487/RFC7112, January 2014, 1380 . 1382 [RFC7731] Hui, J. and R. Kelsey, "Multicast Protocol for Low-Power 1383 and Lossy Networks (MPL)", RFC 7731, DOI 10.17487/RFC7731, 1384 February 2016, . 1386 8.2. Informative References 1388 [Biondi2007] 1389 Biondi, P. and A. Ebalard, "IPv6 Routing Header Security", 1390 CanSecWest 2007 Security Conference, 2007, 1391 . 1393 [Cisco-EH] 1394 Cisco Systems, , "IPv6 Extension Headers Review and 1395 Considerations", Whitepaper. October 2006, 1396 . 1399 [draft-ietf-nimrod-eid] 1400 Lynn, C., "Endpoint Identifier Destination Option", IETF 1401 Internet Draft, draft-ietf-nimrod-eid-00.txt, November 1402 1995. 1404 [FW-Benchmark] 1405 Zack, E., "Firewall Security Assessment and Benchmarking 1406 IPv6 Firewall Load Tests", IPv6 Hackers Meeting #1, 1407 Berlin, Germany. June 30, 2013, 1408 . 1412 [I-D.gont-v6ops-ipv6-ehs-packet-drops] 1413 Gont, F., Hilliard, N., Doering, G., (Will), S., and W. 1414 Kumari, "Operational Implications of IPv6 Packets with 1415 Extension Headers", draft-gont-v6ops-ipv6-ehs-packet- 1416 drops-03 (work in progress), March 2016. 1418 [I-D.ietf-6man-hbh-header-handling] 1419 Baker, F. and R. Bonica, "IPv6 Hop-by-Hop Options 1420 Extension Header", draft-ietf-6man-hbh-header-handling-03 1421 (work in progress), March 2016. 1423 [IANA-IPV6-PARAM] 1424 Internet Assigned Numbers Authority, "Internet Protocol 1425 Version 6 (IPv6) Parameters", December 2013, 1426 . 1429 [IANA-PROTOCOLS] 1430 Internet Assigned Numbers Authority, "Protocol Numbers", 1431 2014, . 1434 [NIMROD-DOC] 1435 Nimrod Documentation Page, , 1436 "http://ana-3.lcs.mit.edu/~jnc/nimrod/". 1438 [RFC3871] Jones, G., Ed., "Operational Security Requirements for 1439 Large Internet Service Provider (ISP) IP Network 1440 Infrastructure", RFC 3871, DOI 10.17487/RFC3871, September 1441 2004, . 1443 [RFC6192] Dugal, D., Pignataro, C., and R. Dunn, "Protecting the 1444 Router Control Plane", RFC 6192, DOI 10.17487/RFC6192, 1445 March 2011, . 1447 [RFC7126] Gont, F., Atkinson, R., and C. Pignataro, "Recommendations 1448 on Filtering of IPv4 Packets Containing IPv4 Options", 1449 BCP 186, RFC 7126, DOI 10.17487/RFC7126, February 2014, 1450 . 1452 [RFC7739] Gont, F., "Security Implications of Predictable Fragment 1453 Identification Values", RFC 7739, DOI 10.17487/RFC7739, 1454 February 2016, . 1456 [RFC7872] Gont, F., Linkova, J., Chown, T., and W. Liu, 1457 "Observations on the Dropping of Packets with IPv6 1458 Extension Headers in the Real World", RFC 7872, 1459 DOI 10.17487/RFC7872, June 2016, 1460 . 1462 Authors' Addresses 1464 Fernando Gont 1465 UTN-FRH / SI6 Networks 1466 Evaristo Carriego 2644 1467 Haedo, Provincia de Buenos Aires 1706 1468 Argentina 1470 Phone: +54 11 4650 8472 1471 Email: fgont@si6networks.com 1472 URI: http://www.si6networks.com 1474 Will(Shucheng) Liu 1475 Huawei Technologies 1476 Bantian, Longgang District 1477 Shenzhen 518129 1478 P.R. China 1480 Email: liushucheng@huawei.com 1481 Ronald P. Bonica 1482 Juniper Networks 1483 2251 Corporate Park Drive 1484 Herndon, VA 20171 1485 US 1487 Phone: 571 250 5819 1488 Email: rbonica@juniper.net