idnits 2.17.1 draft-ietf-opsec-ipv6-eh-filtering-05.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 (March 5, 2018) is 2241 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Unused Reference: 'RFC4304' is defined on line 1403, but no explicit reference was found in the text == Unused Reference: 'I-D.ietf-6man-hbh-header-handling' is defined on line 1546, but no explicit reference was found in the text == Outdated reference: A later version (-44) exists of draft-ietf-roll-useofrplinfo-22 ** 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: September 6, 2018 Huawei Technologies 6 March 5, 2018 8 Recommendations on the Filtering of IPv6 Packets Containing IPv6 9 Extension Headers 10 draft-ietf-opsec-ipv6-eh-filtering-05 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 http://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 September 6, 2018. 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 (http://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 . . . . . . . . . . . . . . . . . . . . . . . . . 3 60 2. Terminology and Conventions Used in This Document . . . . . . 4 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 70 IPv6 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 . . . . . . . . . . . . . . . . . . . . . . . . . 28 80 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 29 81 6. Security Considerations . . . . . . . . . . . . . . . . . . . 29 82 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 29 83 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 29 84 8.1. Normative References . . . . . . . . . . . . . . . . . . . 29 85 8.2. Informative References . . . . . . . . . . . . . . . . . . 33 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 142 2.1. Terminology 144 The terms "fast path", "slow path", and associated relative terms 145 ("faster path" and "slower path") are loosely defined as in Section 2 146 of [RFC6398]. 148 The terms "permit" (allow the traffic), "drop" (drop with no 149 notification to sender), and "reject" (drop with appropriate 150 notification to sender) are employed as defined in [RFC3871]. 151 Throughout this document we also employ the term "discard" as a 152 generic term to indicate the act of discarding a packet, irrespective 153 of whether the sender is notified of such drops, and irrespective of 154 whether the specific filtering action is logged. 156 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 157 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 158 document are to be interpreted as described in [RFC2119]. 160 2.2. Applicability Statement 162 This document provides advice on the filtering of IPv6 packets with 163 EHs at transit routers for traffic *not* explicitly destined to such 164 transit routers, for those cases in which such filtering is deemed as 165 necessary. 167 2.3. Conventions 169 This document assumes that nodes comply with the requirements in 170 [RFC7045]. Namely (from [RFC7045]), 172 o If a forwarding node discards a packet containing a standard IPv6 173 EH, it MUST be the result of a configurable policy and not just 174 the result of a failure to recognise such a header. 176 o The discard policy for each standard type of EH MUST be 177 individually configurable. 179 o The default configuration SHOULD allow all standard IPv6 EHs. 181 The advice provided in this document is only meant to guide an 182 operator in configuring forwarding devices, and is *not* to be 183 interpreted as advice regarding default configuration settings for 184 network devices. That is, this document provides advice with respect 185 to operational configurations, but does not change the implementation 186 defaults required by [RFC7045]. 188 We recommend that configuration options are made available to govern 189 the processing of each IPv6 EH type and each IPv6 option type. Such 190 configuration options may include the following possible settings: 192 o Permit this IPv6 EH or IPv6 Option type 194 o Discard (and log) packets containing this IPv6 EH or option type 196 o Reject (and log) packets containing this IPv6 EH or option type 197 (where the packet drop is signaled with an ICMPv6 error message) 199 o Rate-limit traffic containing this IPv6 EH or option type 201 o Ignore this IPv6 EH or option type (as if it was not present) and 202 forward the packet. We note that if a packet carries forwarding 203 information (e.g., in an IPv6 Routing Header) this might be an 204 inappropriate or undesirable action. 206 We note that special care needs to be taken when devices log packet 207 drops/rejects. Devices should count the number of packets dropped/ 208 rejected, but the logging of drop/reject events should be limited so 209 as to not overburden device resources. 211 Finally, we note that when discarding packets, it is generally 212 desirable that the sender be signaled of the packet drop, since this 213 is of use for trouble-shooting purposes. However, throughout this 214 document (when recommending that packets be discarded) we generically 215 refer to the action as "discard" without specifying whether the 216 sender is signaled of the packet drop. 218 3. IPv6 Extension Headers 220 3.1. General Discussion 222 IPv6 [RFC8200] EHs allow for the extension of the IPv6 protocol. 223 Since both IPv6 EHs and upper-layer protocols share the same 224 namespace ("Next Header" registry/namespace), [RFC7045] identifies 225 which of the currently assigned Internet Protocol numbers identify 226 IPv6 EHs vs. upper-layer protocols. This document discusses the 227 filtering of packets based on the IPv6 EHs (as specified by 228 [RFC7045]) they contain. 230 NOTE: [RFC7112] specifies that non-fragmented IPv6 datagrams and 231 IPv6 First-Fragments MUST contain the entire IPv6 header chain 232 [RFC7112]. Therefore, intermediate systems can enforce the 233 filtering policies discussed in this document, or resort to simply 234 discarding the offending packets when they fail to comply with the 235 requirements in [RFC7112]. We note that, in order to implement 236 filtering rules on the fast path, it may be necessary for the 237 filtering device to limit the depth into the packet that can be 238 inspected before giving up. In circumstances where there is such 239 a limitation, it is recommended that implementations discard 240 packets if, when trying to determine whether to discard or permit 241 a packet, the aforementioned limit is encountered. 243 3.2. General Security Implications 245 In some specific device architectures, IPv6 packets that contain IPv6 246 EHs may cause the corresponding packets to be processed on the slow 247 path, and hence may be leveraged for the purpose of Denial of Service 248 (DoS) attacks [I-D.gont-v6ops-ipv6-ehs-packet-drops] [Cisco-EH] 249 [FW-Benchmark]. 251 Operators are urged to consider IPv6 EH filtering and IPv6 options 252 handling capabilities of different devices as they make deployment 253 decisions in future. 255 3.3. Summary of Advice on the Handling of IPv6 Packets with Specific 256 IPv6 Extension Headers 258 This section summarizes the advice provided in Section 3.4, providing 259 references to the specific sections in which a detailed analysis can 260 be found. 262 +----------------------------+---------------------+----------------+ 263 | EH type | Filtering policy | Reference | 264 +----------------------------+---------------------+----------------+ 265 | IPv6 Hop-by-Hop Options | Drop or Ignore | Section 3.4.1 | 266 | (Proto=0) | | | 267 +----------------------------+---------------------+----------------+ 268 | Routing Header for IPv6 | Drop only RTH0, | Section 3.4.2 | 269 | (Proto=43) | Permit other RH | | 270 | | Types | | 271 +----------------------------+---------------------+----------------+ 272 | Fragment Header for IPv6 | Permit | Section 3.4.3 | 273 | (Proto=44) | | | 274 +----------------------------+---------------------+----------------+ 275 | Encapsulating Security | Permit | Section 3.4.4 | 276 | Payload (Proto=50) | | | 277 +----------------------------+---------------------+----------------+ 278 +----------------------------+---------------------+----------------+ 279 | Authentication Header | Permit | Section 3.4.5 | 280 | (Proto=51) | | | 281 +----------------------------+---------------------+----------------+ 282 | Destination Options for | Permit | Section 3.4.6 | 283 | IPv6 (Proto=60) | | | 284 +----------------------------+---------------------+----------------+ 285 | Mobility Header | Permit | Section 3.4.7 | 286 | (Proto=135) | | | 287 +----------------------------+---------------------+----------------+ 288 | Host Identity Protocol | Permit | Section 3.4.8 | 289 | (Proto=139) | | | 290 +----------------------------+---------------------+----------------+ 291 | Shim6 Protocol (Proto=140) | Permit | Section 3.4.9 | 292 +----------------------------+---------------------+----------------+ 293 | Use for experimentation | Drop | Section 3.4.10 | 294 | and testing (Proto=253 and | | | 295 | 254) | | | 296 +----------------------------+---------------------+----------------+ 298 Table 1: Summary of Advice on the Handling of IPv6 Packets with 299 Specific IPv6 Extension Headers 301 3.4. Advice on the Handling of IPv6 Packets with Specific IPv6 302 Extension Headers 304 3.4.1. IPv6 Hop-by-Hop Options (Protocol Number=0) 306 3.4.1.1. Uses 308 The Hop-by-Hop Options header is used to carry optional information 309 that may be examined by every node along a packet's delivery path. 310 It is expected that nodes will examine the Hop-by-Hop Options header 311 if explicitly configured to do so. 313 NOTE: [RFC2460] required that all nodes examined and processed the 314 Hop-by-Hop Options header. However, even before the publication of 315 [RFC8200] a number of implementations already provided the option of 316 ignoring this header unless explicitly configured to examine it. 318 3.4.1.2. Specification 320 This EH is specified in [RFC8200]. At the time of this writing, the 321 following options have been specified for the Hop-by-Hop Options EH: 323 o Type 0x00: Pad1 [RFC8200] 324 o Type 0x01: PadN [RFC8200] 326 o Type 0x05: Router Alert [RFC2711] 328 o Type 0x07: CALIPSO [RFC5570] 330 o Type 0x08: SMF_DPD [RFC6621] 332 o Type 0x23: RPL Option [I-D.ietf-roll-useofrplinfo] 334 o Type 0x26: Quick-Start [RFC4782] 336 o Type 0x4D: (Deprecated) 338 o Type 0x63: RPL Option [RFC6553] 340 o Type 0x6D: MPL Option [RFC7731] 342 o Type 0x8A: Endpoint Identification (Deprecated) 343 [draft-ietf-nimrod-eid] 345 o Type 0xC2: Jumbo Payload [RFC2675] 347 o Type 0xEE: IPv6 DFF Header [RFC6971] 349 o Type 0x1E: RFC3692-style Experiment [RFC4727] 351 o Type 0x3E: RFC3692-style Experiment [RFC4727] 353 o Type 0x5E: RFC3692-style Experiment [RFC4727] 355 o Type 0x7E: RFC3692-style Experiment [RFC4727] 357 o Type 0x9E: RFC3692-style Experiment [RFC4727] 359 o Type 0xBE: RFC3692-style Experiment [RFC4727] 361 o Type 0xDE: RFC3692-style Experiment [RFC4727] 363 o Type 0xFE: RFC3692-style Experiment [RFC4727] 365 3.4.1.3. Specific Security Implications 367 Legacy nodes that may process this extencion header could be subject 368 to Denial of Service attacks. 370 NOTE: While [RFC8200] has removed this requirement, the deployed base 371 may still reflect the traditional behavior for a while, and hence the 372 potential security problems of this EH are still of concern. 374 3.4.1.4. Operational and Interoperability Impact if Blocked 376 Discarding packets containing a Hop-by-Hop Options EH would break any 377 of the protocols that rely on it for proper functioning. For 378 example, it would break RSVP [RFC2205] and multicast deployments, and 379 would cause IPv6 jumbograms to be discarded. 381 3.4.1.5. Advice 383 Nodes implementing [RFC8200] would already ignore this extension 384 header unless explicitly required to process it. For legacy 385 ([RFC2460] nodes, the recommended configuration for the processing of 386 these packets depends on the features and capabilities of the 387 underlying platform. On platforms that allow forwarding of packets 388 with HBH Options on the fast path, we recommend that packets with a 389 HBH Options EH be forwarded as normal. Otherwise, on platforms in 390 which processing of packets with a IPv6 HBH Options EH is carried out 391 in the slow path, and an option is provided to rate-limit these 392 packets, we recommend that this option be selected. Finally, when 393 packets containing a HBH Options EH are processed in the slow-path, 394 and the underlying platform does not have any mitigation options 395 available for attacks based on these packets, we recommend that such 396 platforms discard packets containing IPv6 HBH Options EHs. 398 Finally, we note that, for obvious reasons, RPL (Routing Protocol for 399 Low-Power and Lossy Networks) [RFC6550] routers must not discard 400 packets based on the presence of an IPv6 Hop-by-Hop Options EH. 402 3.4.2. Routing Header for IPv6 (Protocol Number=43) 404 3.4.2.1. Uses 406 The Routing header is used by an IPv6 source to list one or more 407 intermediate nodes to be "visited" on the way to a packet's 408 destination. 410 3.4.2.2. Specification 412 This EH is specified in [RFC8200]. [RFC2460] had originally 413 specified the Routing Header Type 0, which was later obsoleted by 414 [RFC5095], and thus removed from [RFC8200]. 416 At the time of this writing, the following Routing Types have been 417 specified: 419 o Type 0: Source Route (DEPRECATED) [RFC2460] [RFC5095] 421 o Type 1: Nimrod (DEPRECATED) 423 o Type 2: Type 2 Routing Header [RFC6275] 425 o Type 3: RPL Source Route Header [RFC6554] 427 o Types 4-252: Unassigned 429 o Type 253: RFC3692-style Experiment 1 [RFC4727] 431 o Type 254: RFC3692-style Experiment 2 [RFC4727] 433 o Type 255: Reserved 435 3.4.2.3. Specific Security Implications 437 The security implications of RHT0 have been discussed in detail in 438 [Biondi2007] and [RFC5095]. 440 3.4.2.4. Operational and Interoperability Impact if Blocked 442 Blocking packets containing a RHT0 or RTH1 has no operational 443 implications. However, blocking packets employing other routing 444 header types will break the protocols that rely on them. 446 3.4.2.5. Advice 448 Intermediate systems should discard packets containing a RHT0 or 449 RHT1. RHT2 and RHT3 should be permitted, as required by [RFC7045]. 450 Other routing header types should be discarded. 452 3.4.3. Fragment Header for IPv6 (Protocol Number=44) 454 3.4.3.1. Uses 456 This EH provides the fragmentation functionality for IPv6. 458 3.4.3.2. Specification 460 This EH is specified in [RFC8200]. 462 3.4.3.3. Specific Security Implications 464 The security implications of the Fragment Header range from Denial of 465 Service attacks (e.g. based on flooding a target with IPv6 fragments) 466 to information leakage attacks [RFC7739]. 468 3.4.3.4. Operational and Interoperability Impact if Blocked 470 Blocking packets that contain a Fragment Header will break any 471 protocol that may rely on fragmentation (e.g., the DNS [RFC1034]). 473 3.4.3.5. Advice 475 Intermediate systems should permit packets that contain a Fragment 476 Header. 478 3.4.4. Encapsulating Security Payload (Protocol Number=50) 480 3.4.4.1. Uses 482 This EH is employed for the IPsec suite [RFC4303]. 484 3.4.4.2. Specification 486 This EH is specified in [RFC4303]. 488 3.4.4.3. Specific Security Implications 490 Besides the general implications of IPv6 EHs, this EH could be 491 employed to potentially perform a DoS attack at the destination 492 system by wasting CPU resources in validating the contents of the 493 packet. 495 3.4.4.4. Operational and Interoperability Impact if Blocked 497 Discarding packets that employ this EH would break IPsec deployments. 499 3.4.4.5. Advice 501 Intermediate systems should permit packets containing the 502 Encapsulating Security Payload EH. 504 3.4.5. Authentication Header (Protocol Number=51) 506 3.4.5.1. Uses 508 The Authentication Header can be employed for provide authentication 509 services in IPv4 and IPv6. 511 3.4.5.2. Specification 513 This EH is specified in [RFC4302]. 515 3.4.5.3. Specific Security Implications 517 Besides the general implications of IPv6 EHs, this EH could be 518 employed to potentially perform a DoS attack at the destination 519 system by wasting CPU resources in validating the contents of the 520 packet. 522 3.4.5.4. Operational and Interoperability Impact if Blocked 524 Discarding packets that employ this EH would break IPsec deployments. 526 3.4.5.5. Advice 528 Intermediate systems should permit packets containing an 529 Authentication Header. 531 3.4.6. Destination Options for IPv6 (Protocol Number=60) 533 3.4.6.1. Uses 535 The Destination Options header is used to carry optional information 536 that needs be examined only by a packet's destination node(s). 538 3.4.6.2. Specification 540 This EH is specified in [RFC8200]. At the time of this writing, the 541 following options have been specified for this EH: 543 o Type 0x00: Pad1 [RFC8200] 545 o Type 0x01: PadN [RFC8200] 547 o Type 0x04: Tunnel Encapsulation Limit [RFC2473] 549 o Type 0x4D: (Deprecated) 551 o Type 0xC9: Home Address [RFC6275] 553 o Type 0x8A: Endpoint Identification (Deprecated) 554 [draft-ietf-nimrod-eid] 556 o Type 0x8B: ILNP Nonce [RFC6744] 558 o Type 0x8C: Line-Identification Option [RFC6788] 560 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) 650 3.4.9.1. Uses 652 This EH is employed by the Shim6 [RFC5533] Protocol. 654 3.4.9.2. Specification 656 This EH is specified in [RFC5533]. 658 3.4.9.3. Specific Security Implications 660 The specific security implications are discussed in detail in Section 661 16 of [RFC5533]. 663 3.4.9.4. Operational and Interoperability Impact if Blocked 665 Discarding packets that contain this EH will break Shim6. 667 3.4.9.5. Advice 669 Intermediate systems should permit packets containing this EH. 671 3.4.10. Use for experimentation and testing (Protocol Numbers=253 and 672 254) 674 3.4.10.1. Uses 676 These IPv6 EHs are employed for performing RFC3692-Style experiments 677 (see [RFC3692] for details). 679 3.4.10.2. Specification 681 These EHs are specified in [RFC3692] and [RFC4727]. 683 3.4.10.3. Specific Security Implications 685 The security implications of these EHs will depend on their specific 686 use. 688 3.4.10.4. Operational and Interoperability Impact if Blocked 690 For obvious reasons, discarding packets that contain these EHs limits 691 the ability to perform legitimate experiments across IPv6 routers. 693 3.4.10.5. Advice 695 Intermediate systems should discard packets containing these EHs. 696 Only in specific scenarios in which RFC3692-Style experiments are to 697 be performed should these EHs be permitted. 699 3.5. Advice on the Handling of Packets with Unknown IPv6 Extension 700 Headers 702 We refer to IPv6 EHs that have not been assigned an Internet Protocol 703 Number by IANA (and marked as such) in [IANA-PROTOCOLS] as "unknown 704 IPv6 extension headers" ("unknown IPv6 EHs"). 706 3.5.1. Uses 708 New IPv6 EHs may be specified as part of future extensions to the 709 IPv6 protocol. 711 Since IPv6 EHs and Upper-layer protocols employ the same namespace, 712 it is impossible to tell whether an unknown "Internet Protocol 713 Number" is being employed for an IPv6 EH or an Upper-Layer protocol. 715 3.5.2. Specification 717 The processing of unknown IPv6 EHs is specified in [RFC8200] and 718 [RFC7045]. 720 3.5.3. Specific Security Implications 722 For obvious reasons, it is impossible to determine specific security 723 implications of unknown IPv6 EHs. However, from security standpoint, 724 a device should discard IPv6 extension headers for which the security 725 implications cannot be determined. We note that this policy is 726 allowed by [RFC7045]. 728 3.5.4. Operational and Interoperability Impact if Blocked 730 As noted in [RFC7045], discarding unknown IPv6 EHs may slow down the 731 deployment of new IPv6 EHs and transport protocols. The 732 corresponding IANA registry ([IANA-PROTOCOLS]) should be monitored 733 such that filtering rules are updated as new IPv6 EHs are 734 standardized. 736 We note that since IPv6 EHs and upper-layer protocols share the same 737 numbering space, discarding unknown IPv6 EHs may result in packets 738 encapsulating unknown upper-layer protocols being discarded. 740 3.5.5. Advice 742 Intermediate systems should discard packets containing unknown IPv6 743 EHs. 745 4. IPv6 Options 747 4.1. General Discussion 749 The following subsections describe specific security implications of 750 different IPv6 options, and provide advice regarding filtering 751 packets that contain such options. 753 4.2. General Security Implications of IPv6 Options 755 The general security implications of IPv6 options are closely related 756 to those discussed in Section 3.2 for IPv6 EHs. Essentially, packets 757 that contain IPv6 options might need to be processed by an IPv6 758 router's general-purpose CPU,and hence could present a DDoS risk to 759 that router's general-purpose CPU (and thus to the router itself). 760 For some architectures, a possible mitigation would be to rate-limit 761 the packets that are to be processed by the general-purpose CPU (see 762 e.g. [Cisco-EH]). 764 4.3. Advice on the Handling of Packets with Specific IPv6 Options 766 The following subsections contain a description of each of the IPv6 767 options that have so far been specified, a summary of the security 768 implications of each of such options, a discussion of possible 769 interoperability implications if packets containing such options are 770 discarded, and specific advice regarding whether packets containing 771 these options should be permitted. 773 4.3.1. Pad1 (Type=0x00) 775 4.3.1.1. Uses 777 This option is used when necessary to align subsequent options and to 778 pad out the containing header to a multiple of 8 octets in length. 780 4.3.1.2. Specification 782 This option is specified in [RFC8200]. 784 4.3.1.3. Specific Security Implications 786 None. 788 4.3.1.4. Operational and Interoperability Impact if Blocked 790 Discarding packets that contain this option would potentially break 791 any protocol that relies on IPv6 EHs. 793 4.3.1.5. Advice 795 Intermediate systems should not discard packets based on the presence 796 of this option. 798 4.3.2. PadN (Type=0x01) 800 4.3.2.1. Uses 802 This option is used when necessary to align subsequent options and to 803 pad out the containing header to a multiple of 8 octets in length. 805 4.3.2.2. Specification 807 This option is specified in [RFC8200]. 809 4.3.2.3. Specific Security Implications 811 Because of the possible size of this option, it could be leveraged as 812 a large-bandwidth covert channel. 814 4.3.2.4. Operational and Interoperability Impact if Blocked 816 Discarding packets that contain this option would potentially break 817 any protocol that relies on IPv6 EHs. 819 4.3.2.5. Advice 821 Intermediate systems should not discard IPv6 packets based on the 822 presence of this option. 824 4.3.3. Jumbo Payload (Type=0XC2) 826 4.3.3.1. Uses 828 The Jumbo payload option provides the means of specifying payloads 829 larger than 65535 bytes. 831 4.3.3.2. Specification 833 This option is specified in [RFC2675]. 835 4.3.3.3. Specific Security Implications 837 There are no specific issues arising from this option, except for 838 improper validity checks of the option and associated packet lengths. 840 4.3.3.4. Operational and Interoperability Impact if Blocked 842 Discarding packets based on the presence of this option will cause 843 IPv6 jumbograms to be discarded. 845 4.3.3.5. Advice 847 Intermediate systems should discard packets that contain this option. 848 An operator should permit this option only in specific scenarios in 849 which support for IPv6 jumbograms is desired. 851 4.3.4. RPL Option (Type=0x63) 853 4.3.4.1. Uses 855 The RPL Option provides a mechanism to include routing information 856 with each datagram that an RPL router forwards. 858 4.3.4.2. Specification 860 This option was originally specified in [RFC6553]. It has been 861 deprecated by [I-D.ietf-roll-useofrplinfo]. 863 4.3.4.3. Specific Security Implications 865 Those described in [RFC6553]. 867 4.3.4.4. Operational and Interoperability Impact if Blocked 869 This option is meant to be employed within an RPL instance. As a 870 result, discarding packets based on the presence of this option (e.g. 871 at an ISP) will not result in interoperability implications. 873 4.3.4.5. Advice 875 Non-RPL routers should discard packets that contain an RPL option. 877 4.3.5. RPL Option (Type=0x23) 879 4.3.5.1. Uses 881 The RPL Option provides a mechanism to include routing information 882 with each datagram that an RPL router forwards. 884 4.3.5.2. Specification 886 This option is specified in [I-D.ietf-roll-useofrplinfo]. 888 4.3.5.3. Specific Security Implications 890 Those described in [I-D.ietf-roll-useofrplinfo]. 892 4.3.5.4. Operational and Interoperability Impact if Blocked 894 This option is meant to survive outside of an RPL instance. As a 895 result, discarding packets based on the presence of this option would 896 break some use cases for RPL (see [I-D.ietf-roll-useofrplinfo]). 898 4.3.5.5. Advice 900 Intermediate systems should not discard IPv6 packets based on the 901 presence of this option. 903 4.3.6. Tunnel Encapsulation Limit (Type=0x04) 905 4.3.6.1. Uses 907 The Tunnel Encapsulation Limit option can be employed to specify how 908 many further levels of nesting the packet is permitted to undergo. 910 4.3.6.2. Specification 912 This option is specified in [RFC2473]. 914 4.3.6.3. Specific Security Implications 916 Those described in [RFC2473]. 918 4.3.6.4. Operational and Interoperability Impact if Blocked 920 Discarding packets based on the presence of this option could result 921 in tunnel traffic being discarded. 923 4.3.6.5. Advice 925 Intermediate systems should not discard packets based on the presence 926 of this option. 928 4.3.7. Router Alert (Type=0x05) 930 4.3.7.1. Uses 932 The Router Alert option [RFC2711] is typically employed for the RSVP 933 protocol [RFC2205] and the MLD protocol [RFC2710]. 935 4.3.7.2. Specification 937 This option is specified in [RFC2711]. 939 4.3.7.3. Specific Security Implications 941 Since this option causes the contents of the packet to be inspected 942 by the handling device, this option could be leveraged for performing 943 DoS attacks. 945 4.3.7.4. Operational and Interoperability Impact if Blocked 947 Discarding packets that contain this option would break RSVP and 948 multicast deployments. 950 4.3.7.5. Advice 952 Intermediate systems should discard packets that contain this option. 953 Only in specific environments where support for RSVP, multicast 954 routing, or similar protocols is desired, should this option be 955 permitted. 957 4.3.8. Quick-Start (Type=0x26) 959 4.3.8.1. Uses 961 This IP Option is used in the specification of Quick-Start for TCP 962 and IP, which is an experimental mechanism that allows transport 963 protocols, in cooperation with routers, to determine an allowed 964 sending rate at the start and, at times, in the middle of a data 965 transfer (e.g., after an idle period) [RFC4782]. 967 4.3.8.2. Specification 969 This option is specified in [RFC4782], on the "Experimental" track. 971 4.3.8.3. Specific Security Implications 973 Section 9.6 of [RFC4782] notes that Quick-Start is vulnerable to two 974 kinds of attacks: 976 o attacks to increase the routers' processing and state load, and, 978 o attacks with bogus Quick-Start Requests to temporarily tie up 979 available Quick-Start bandwidth, preventing routers from approving 980 Quick-Start Requests from other connections. 982 We note that if routers in a given environment do not implement and 983 enable the Quick-Start mechanism, only the general security 984 implications of IP options (discussed in Section 4.2) would apply. 986 4.3.8.4. Operational and Interoperability Impact if Blocked 988 The Quick-Start functionality would be disabled, and additional 989 delays in TCP's connection establishment (for example) could be 990 introduced. (Please see Section 4.7.2 of [RFC4782].) We note, 991 however, that Quick-Start has been proposed as a mechanism that could 992 be of use in controlled environments, and not as a mechanism that 993 would be intended or appropriate for ubiquitous deployment in the 994 global Internet [RFC4782]. 996 4.3.8.5. Advice 998 Intermediate systems should not discard IPv6 packets based on the 999 presence of this option. 1001 4.3.9. CALIPSO (Type=0x07) 1003 4.3.9.1. Uses 1005 This option is used for encoding explicit packet Sensitivity Labels 1006 on IPv6 packets. It is intended for use only within Multi-Level 1007 Secure (MLS) networking environments that are both trusted and 1008 trustworthy. 1010 4.3.9.2. Specification 1012 This option is specified in [RFC5570]. 1014 4.3.9.3. Specific Security Implications 1016 Presence of this option in a packet does not by itself create any 1017 specific new threat. Packets with this option ought not normally be 1018 seen on the global public Internet. 1020 4.3.9.4. Operational and Interoperability Impact if Blocked 1022 If packets with this option are discarded or if the option is 1023 stripped from the packet during transmission from source to 1024 destination, then the packet itself is likely to be discarded by the 1025 receiver because it is not properly labeled. In some cases, the 1026 receiver might receive the packet but associate an incorrect 1027 sensitivity label with the received data from the packet whose 1028 CALIPSO was stripped by an intermediate router or firewall. 1029 Associating an incorrect sensitivity label can cause the received 1030 information either to be handled as more sensitive than it really is 1031 ("upgrading") or as less sensitive than it really is ("downgrading"), 1032 either of which is problematic. 1034 4.3.9.5. Advice 1036 Intermediate systems that do not operate in Multi-Level Secure (MLS) 1037 networking environments should discard packets that contain this 1038 option. 1040 4.3.10. SMF_DPD (Type=0x08) 1042 4.3.10.1. Uses 1044 This option is employed in the (experimental) Simplified Multicast 1045 Forwarding (SMF) for unique packet identification for IPv6 I-DPD, and 1046 as a mechanism to guarantee non-collision of hash values for 1047 different packets when H-DPD is used. 1049 4.3.10.2. Specification 1051 This option is specified in [RFC6621]. 1053 4.3.10.3. Specific Security Implications 1055 None. The use of identifiers is subject to the security and privacy 1056 considerations discussed in [I-D.gont-predictable-numeric-ids]. 1058 4.3.10.4. Operational and Interoperability Impact if Blocked 1060 Dropping packets containing this option within a MANET domain would 1061 break SMF. However, dropping such packets at the border of such 1062 domain would have no negative impact. 1064 4.3.10.5. Advice 1066 Intermediate system should discard packets that contain this option. 1068 4.3.11. Home Address (Type=0xC9) 1070 4.3.11.1. Uses 1072 The Home Address option is used by a Mobile IPv6 node while away from 1073 home, to inform the recipient of the mobile node's home address. 1075 4.3.11.2. Specification 1077 This option is specified in [RFC6275]. 1079 4.3.11.3. Specific Security Implications 1081 No (known) additional security implications than those described in 1082 [RFC6275]. 1084 4.3.11.4. Operational and Interoperability Impact if Blocked 1086 Discarding IPv6 packets based on the presence of this option will 1087 break Mobile IPv6. 1089 4.3.11.5. Advice 1091 Intermediate systems should not discard IPv6 packets based on the 1092 presence of this option. 1094 4.3.12. Endpoint Identification (Type=0x8A) 1096 4.3.12.1. Uses 1098 The Endpoint Identification option was meant to be used with the 1099 Nimrod routing architecture [NIMROD-DOC], but has never seen 1100 widespread deployment. 1102 4.3.12.2. Specification 1104 This option is specified in [NIMROD-DOC]. 1106 4.3.12.3. Specific Security Implications 1108 Undetermined. 1110 4.3.12.4. Operational and Interoperability Impact if Blocked 1112 None. 1114 4.3.12.5. Advice 1116 Intermediate systems should discard packets that contain this option. 1118 4.3.13. ILNP Nonce (Type=0x8B) 1120 4.3.13.1. Uses 1122 This option is employed by Identifier-Locator Network Protocol for 1123 IPv6 (ILNPv6) for providing protection against off-path attacks for 1124 packets when ILNPv6 is in use, and as a signal during initial 1125 network-layer session creation that ILNPv6 is proposed for use with 1126 this network-layer session, rather than classic IPv6. 1128 4.3.13.2. Specification 1130 This option is specified in [RFC6744]. 1132 4.3.13.3. Specific Security Implications 1134 Those described in [RFC6744]. 1136 4.3.13.4. Operational and Interoperability Impact if Blocked 1138 Discarding packets that contain this option will break INLPv6 1139 deployments. 1141 4.3.13.5. Advice 1143 Intermediate systems should not discard packets based on the presence 1144 of this option. 1146 4.3.14. Line-Identification Option (Type=0x8C) 1148 4.3.14.1. Uses 1150 This option is used by an Edge Router to identify the subscriber 1151 premises in scenarios where several subscriber premises may be 1152 logically connected to the same interface of an Edge Router. 1154 4.3.14.2. Specification 1156 This option is specified in [RFC6788]. 1158 4.3.14.3. Specific Security Implications 1160 Those described in [RFC6788]. 1162 4.3.14.4. Operational and Interoperability Impact if Blocked 1164 Since this option is meant to be employed in Router Solicitation 1165 messages, discarding packets based on the presence of this option at 1166 intermediate systems will result in no interoperability implications. 1168 4.3.14.5. Advice 1170 Intermediate devices should discard packets that contain this option. 1172 4.3.15. Deprecated (Type=0x4D) 1173 4.3.15.1. Uses 1175 No information has been found about this option type. 1177 4.3.15.2. Specification 1179 No information has been found about this option type. 1181 4.3.15.3. Specific Security Implications 1183 No information has been found about this option type, and hence it 1184 has been impossible to perform the corresponding security assessment. 1186 4.3.15.4. Operational and Interoperability Impact if Blocked 1188 Unknown. 1190 4.3.15.5. Advice 1192 Intermediate systems should discard packets that contain this option. 1194 4.3.16. MPL Option (Type=0x6D) 1196 4.3.16.1. Uses 1198 This option is used with the Multicast Protocol for Low power and 1199 Lossy Networks (MPL), that provides IPv6 multicast forwarding in 1200 constrained networks. 1202 4.3.16.2. Specification 1204 This option is specified in [RFC7731], and is meant to be included 1205 only in Hop-by-Hop Option headers. 1207 4.3.16.3. Specific Security Implications 1209 Those described in [RFC7731]. 1211 4.3.16.4. Operational and Interoperability Impact if Blocked 1213 Dropping packets that contain an MPL option within an MPL network 1214 would break the Multicast Protocol for Low power and Lossy Networks 1215 (MPL). However, dropping such packets at the border of such networks 1216 will have no negative impact. 1218 4.3.16.5. Advice 1220 Intermediate systems should not discard packets based on the presence 1221 of this option. However, since this option has been specified for 1222 the Hop-by-Hop Options, such systems should consider the discussion 1223 in Section 3.4.1. 1225 4.3.17. IP_DFF (Type=0xEE) 1227 4.3.17.1. Uses 1229 This option is employed with the (Experimental) Depth-First 1230 Forwarding (DFF) in Unreliable Networks. 1232 4.3.17.2. Specification 1234 This option is specified in [RFC6971]. 1236 4.3.17.3. Specific Security Implications 1238 Those specified in [RFC6971]. 1240 4.3.17.4. Operational and Interoperability Impact if Blocked 1242 Dropping packets containing this option within a routing domain that 1243 is running DFF would break DFF. However, droping such packets at the 1244 border of such domains will have no security implications. 1246 4.3.17.5. Advice 1248 Intermediate systems that do not operate within a routing domain that 1249 is running DFF should discard packets containing this option. 1251 4.3.18. RFC3692-style Experiment (Types = 0x1E, 0x3E, 0x5E, 0x7E, 0x9E, 1252 0xBE, 0xDE, 0xFE) 1254 4.3.18.1. Uses 1256 These options can be employed for performing RFC3692-style 1257 experiments. It is only appropriate to use these values in 1258 explicitly configured experiments; they must not be shipped as 1259 defaults in implementations. 1261 4.3.18.2. Specification 1263 Specified in RFC 4727 [RFC4727] in the context of RFC3692-style 1264 experiments. 1266 4.3.18.3. Specific Security Implications 1268 The specific security implications will depend on the specific use of 1269 these options. 1271 4.3.18.4. Operational and Interoperability Impact if Blocked 1273 For obvious reasons, discarding packets that contain these options 1274 limits the ability to perform legitimate experiments across IPv6 1275 routers. 1277 4.3.18.5. Advice 1279 Intermediate systems should discard packets that contain these 1280 options. Only in specific environments where RFC3692-style 1281 experiments are meant to be performed should these options be 1282 permitted. 1284 4.4. Advice on the handling of Packets with Unknown IPv6 Options 1286 We refer to IPv6 options that have not been assigned an IPv6 option 1287 type in the corresponding registry ([IANA-IPV6-PARAM]) as "unknown 1288 IPv6 options". 1290 4.4.1. Uses 1292 New IPv6 options may be specified as part of future protocol work. 1294 4.4.2. Specification 1296 The processing of unknown IPv6 options is specified in [RFC8200]. 1298 4.4.3. Specific Security Implications 1300 For obvious reasons, it is impossible to determine specific security 1301 implications of unknown IPv6 options. 1303 4.4.4. Operational and Interoperability Impact if Blocked 1305 Discarding unknown IPv6 options may slow down the deployment of new 1306 IPv6 options. As noted in [draft-gont-6man-ipv6-opt-transmit], the 1307 corresponding IANA registry ([IANA-IPV6-PARAM] should be monitored 1308 such that IPv6 option filtering rules are updated as new IPv6 options 1309 are standardized. 1311 4.4.5. Advice 1313 Enterprise intermediate systems that process the contents of IPv6 EHs 1314 should discard packets that contain unknown options. Other 1315 intermediate systems that process the contents of IPv6 EHs should 1316 permit packets that contain unknown options. 1318 5. IANA Considerations 1320 This document has no actions for IANA. 1322 6. Security Considerations 1324 This document provides advice on the filtering of IPv6 packets that 1325 contain IPv6 EHs (and possibly IPv6 options) at IPv6 transit routers. 1326 It is meant to improve the current situation of widespread dropping 1327 of such IPv6 packets in those cases where the drops result from 1328 improper configuration defaults, or inappropriate advice in this 1329 area. 1331 7. Acknowledgements 1333 The authors would like to thank Ron Bonica for his work on earlier 1334 versions of this document. 1336 The authors of this document would like to thank (in alphabetical 1337 order) Mikael Abrahamsson, Brian Carpenter, Mike Heard, Bob Hinden, 1338 Jen Linkova, Carlos Pignataro, Maria Ines Robles, Donald Smith, 1339 Pascal Thubert, Ole Troan, Gunter Van De Velde, and Eric Vyncke, for 1340 providing valuable comments on earlier versions of this document. 1342 This document borrows some text and analysis from [RFC7126], authored 1343 by Fernando Gont, Randall Atkinson, and Carlos Pignataro. 1345 8. References 1347 8.1. Normative References 1349 [I-D.ietf-roll-useofrplinfo] 1350 Robles, I., Richardson, M., and P. Thubert, "When to use 1351 RFC 6553, 6554 and IPv6-in-IPv6", 1352 draft-ietf-roll-useofrplinfo-22 (work in progress), 1353 March 2018. 1355 [RFC1034] Mockapetris, P., "Domain names - concepts and facilities", 1356 STD 13, RFC 1034, DOI 10.17487/RFC1034, November 1987, 1357 . 1359 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1360 Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/ 1361 RFC2119, March 1997, 1362 . 1364 [RFC2205] Braden, R., Ed., Zhang, L., Berson, S., Herzog, S., and S. 1365 Jamin, "Resource ReSerVation Protocol (RSVP) -- Version 1 1366 Functional Specification", RFC 2205, DOI 10.17487/RFC2205, 1367 September 1997, . 1369 [RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6 1370 (IPv6) Specification", RFC 2460, DOI 10.17487/RFC2460, 1371 December 1998, . 1373 [RFC2473] Conta, A. and S. Deering, "Generic Packet Tunneling in 1374 IPv6 Specification", RFC 2473, DOI 10.17487/RFC2473, 1375 December 1998, . 1377 [RFC2675] Borman, D., Deering, S., and R. Hinden, "IPv6 Jumbograms", 1378 RFC 2675, DOI 10.17487/RFC2675, August 1999, 1379 . 1381 [RFC2710] Deering, S., Fenner, W., and B. Haberman, "Multicast 1382 Listener Discovery (MLD) for IPv6", RFC 2710, 1383 DOI 10.17487/RFC2710, October 1999, 1384 . 1386 [RFC2711] Partridge, C. and A. Jackson, "IPv6 Router Alert Option", 1387 RFC 2711, DOI 10.17487/RFC2711, October 1999, 1388 . 1390 [RFC3692] Narten, T., "Assigning Experimental and Testing Numbers 1391 Considered Useful", BCP 82, RFC 3692, DOI 10.17487/ 1392 RFC3692, January 2004, 1393 . 1395 [RFC4302] Kent, S., "IP Authentication Header", RFC 4302, 1396 DOI 10.17487/RFC4302, December 2005, 1397 . 1399 [RFC4303] Kent, S., "IP Encapsulating Security Payload (ESP)", 1400 RFC 4303, DOI 10.17487/RFC4303, December 2005, 1401 . 1403 [RFC4304] Kent, S., "Extended Sequence Number (ESN) Addendum to 1404 IPsec Domain of Interpretation (DOI) for Internet Security 1405 Association and Key Management Protocol (ISAKMP)", 1406 RFC 4304, DOI 10.17487/RFC4304, December 2005, 1407 . 1409 [RFC4727] Fenner, B., "Experimental Values In IPv4, IPv6, ICMPv4, 1410 ICMPv6, UDP, and TCP Headers", RFC 4727, DOI 10.17487/ 1411 RFC4727, November 2006, 1412 . 1414 [RFC4782] Floyd, S., Allman, M., Jain, A., and P. Sarolahti, "Quick- 1415 Start for TCP and IP", RFC 4782, DOI 10.17487/RFC4782, 1416 January 2007, . 1418 [RFC5095] Abley, J., Savola, P., and G. Neville-Neil, "Deprecation 1419 of Type 0 Routing Headers in IPv6", RFC 5095, 1420 DOI 10.17487/RFC5095, December 2007, 1421 . 1423 [RFC5201] Moskowitz, R., Nikander, P., Jokela, P., Ed., and T. 1424 Henderson, "Host Identity Protocol", RFC 5201, 1425 DOI 10.17487/RFC5201, April 2008, 1426 . 1428 [RFC5533] Nordmark, E. and M. Bagnulo, "Shim6: Level 3 Multihoming 1429 Shim Protocol for IPv6", RFC 5533, DOI 10.17487/RFC5533, 1430 June 2009, . 1432 [RFC5570] StJohns, M., Atkinson, R., and G. Thomas, "Common 1433 Architecture Label IPv6 Security Option (CALIPSO)", 1434 RFC 5570, DOI 10.17487/RFC5570, July 2009, 1435 . 1437 [RFC6275] Perkins, C., Ed., Johnson, D., and J. Arkko, "Mobility 1438 Support in IPv6", RFC 6275, DOI 10.17487/RFC6275, 1439 July 2011, . 1441 [RFC6398] Le Faucheur, F., Ed., "IP Router Alert Considerations and 1442 Usage", BCP 168, RFC 6398, DOI 10.17487/RFC6398, 1443 October 2011, . 1445 [RFC6550] Winter, T., Ed., Thubert, P., Ed., Brandt, A., Hui, J., 1446 Kelsey, R., Levis, P., Pister, K., Struik, R., Vasseur, 1447 JP., and R. Alexander, "RPL: IPv6 Routing Protocol for 1448 Low-Power and Lossy Networks", RFC 6550, DOI 10.17487/ 1449 RFC6550, March 2012, 1450 . 1452 [RFC6553] Hui, J. and JP. Vasseur, "The Routing Protocol for Low- 1453 Power and Lossy Networks (RPL) Option for Carrying RPL 1454 Information in Data-Plane Datagrams", RFC 6553, 1455 DOI 10.17487/RFC6553, March 2012, 1456 . 1458 [RFC6554] Hui, J., Vasseur, JP., Culler, D., and V. Manral, "An IPv6 1459 Routing Header for Source Routes with the Routing Protocol 1460 for Low-Power and Lossy Networks (RPL)", RFC 6554, 1461 DOI 10.17487/RFC6554, March 2012, 1462 . 1464 [RFC6621] Macker, J., Ed., "Simplified Multicast Forwarding", 1465 RFC 6621, DOI 10.17487/RFC6621, May 2012, 1466 . 1468 [RFC6740] Atkinson, RJ. and SN. Bhatti, "Identifier-Locator Network 1469 Protocol (ILNP) Architectural Description", RFC 6740, 1470 DOI 10.17487/RFC6740, November 2012, 1471 . 1473 [RFC6744] Atkinson, RJ. and SN. Bhatti, "IPv6 Nonce Destination 1474 Option for the Identifier-Locator Network Protocol for 1475 IPv6 (ILNPv6)", RFC 6744, DOI 10.17487/RFC6744, 1476 November 2012, . 1478 [RFC6788] Krishnan, S., Kavanagh, A., Varga, B., Ooghe, S., and E. 1479 Nordmark, "The Line-Identification Option", RFC 6788, 1480 DOI 10.17487/RFC6788, November 2012, 1481 . 1483 [RFC6971] Herberg, U., Ed., Cardenas, A., Iwao, T., Dow, M., and S. 1484 Cespedes, "Depth-First Forwarding (DFF) in Unreliable 1485 Networks", RFC 6971, DOI 10.17487/RFC6971, June 2013, 1486 . 1488 [RFC7045] Carpenter, B. and S. Jiang, "Transmission and Processing 1489 of IPv6 Extension Headers", RFC 7045, DOI 10.17487/ 1490 RFC7045, December 2013, 1491 . 1493 [RFC7112] Gont, F., Manral, V., and R. Bonica, "Implications of 1494 Oversized IPv6 Header Chains", RFC 7112, DOI 10.17487/ 1495 RFC7112, January 2014, 1496 . 1498 [RFC7731] Hui, J. and R. Kelsey, "Multicast Protocol for Low-Power 1499 and Lossy Networks (MPL)", RFC 7731, DOI 10.17487/RFC7731, 1500 February 2016, . 1502 [RFC8200] Deering, S. and R. Hinden, "Internet Protocol, Version 6 1503 (IPv6) Specification", STD 86, RFC 8200, DOI 10.17487/ 1504 RFC8200, July 2017, 1505 . 1507 [draft-gont-6man-ipv6-opt-transmit] 1508 Gont, F., Liu, W., and R. Bonica, "Transmission and 1509 Processing of IPv6 Options", IETF Internet Draft, work in 1510 progress, August 2014. 1512 8.2. Informative References 1514 [Biondi2007] 1515 Biondi, P. and A. Ebalard, "IPv6 Routing Header Security", 1516 CanSecWest 2007 Security Conference, 2007, 1517 . 1519 [Cisco-EH] 1520 Cisco Systems, "IPv6 Extension Headers Review and 1521 Considerations", Whitepaper. October 2006, . 1525 [FW-Benchmark] 1526 Zack, E., "Firewall Security Assessment and Benchmarking 1527 IPv6 Firewall Load Tests", IPv6 Hackers Meeting #1, 1528 Berlin, Germany. June 30, 2013, . 1533 [I-D.gont-predictable-numeric-ids] 1534 Gont, F. and I. Arce, "Security and Privacy Implications 1535 of Numeric Identifiers Employed in Network Protocols", 1536 draft-gont-predictable-numeric-ids-02 (work in progress), 1537 February 2018. 1539 [I-D.gont-v6ops-ipv6-ehs-packet-drops] 1540 Gont, F., Hilliard, N., Doering, G., (Will), S., and W. 1541 Kumari, "Operational Implications of IPv6 Packets with 1542 Extension Headers", 1543 draft-gont-v6ops-ipv6-ehs-packet-drops-03 (work in 1544 progress), March 2016. 1546 [I-D.ietf-6man-hbh-header-handling] 1547 Baker, F. and R. Bonica, "IPv6 Hop-by-Hop Options 1548 Extension Header", draft-ietf-6man-hbh-header-handling-03 1549 (work in progress), March 2016. 1551 [IANA-IPV6-PARAM] 1552 Internet Assigned Numbers Authority, "Internet Protocol 1553 Version 6 (IPv6) Parameters", December 2013, . 1557 [IANA-PROTOCOLS] 1558 Internet Assigned Numbers Authority, "Protocol Numbers", 1559 2014, . 1562 [NIMROD-DOC] 1563 Nimrod Documentation Page, 1564 "http://ana-3.lcs.mit.edu/~jnc/nimrod/". 1566 [RFC3871] Jones, G., Ed., "Operational Security Requirements for 1567 Large Internet Service Provider (ISP) IP Network 1568 Infrastructure", RFC 3871, DOI 10.17487/RFC3871, 1569 September 2004, . 1571 [RFC6192] Dugal, D., Pignataro, C., and R. Dunn, "Protecting the 1572 Router Control Plane", RFC 6192, DOI 10.17487/RFC6192, 1573 March 2011, . 1575 [RFC7126] Gont, F., Atkinson, R., and C. Pignataro, "Recommendations 1576 on Filtering of IPv4 Packets Containing IPv4 Options", 1577 BCP 186, RFC 7126, DOI 10.17487/RFC7126, February 2014, 1578 . 1580 [RFC7739] Gont, F., "Security Implications of Predictable Fragment 1581 Identification Values", RFC 7739, DOI 10.17487/RFC7739, 1582 February 2016, . 1584 [RFC7872] Gont, F., Linkova, J., Chown, T., and W. Liu, 1585 "Observations on the Dropping of Packets with IPv6 1586 Extension Headers in the Real World", RFC 7872, 1587 DOI 10.17487/RFC7872, June 2016, 1588 . 1590 [draft-ietf-nimrod-eid] 1591 Lynn, C., "Endpoint Identifier Destination Option", IETF 1592 Internet Draft, draft-ietf-nimrod-eid-00.txt, 1593 November 1995. 1595 Authors' Addresses 1597 Fernando Gont 1598 UTN-FRH / SI6 Networks 1599 Evaristo Carriego 2644 1600 Haedo, Provincia de Buenos Aires 1706 1601 Argentina 1603 Phone: +54 11 4650 8472 1604 Email: fgont@si6networks.com 1605 URI: http://www.si6networks.com 1607 Will(Shucheng) Liu 1608 Huawei Technologies 1609 Bantian, Longgang District 1610 Shenzhen 518129 1611 P.R. China 1613 Email: liushucheng@huawei.com