RFC 9288

Recommendations on the Filtering of IPv6 Packets Containing IPv6 Extension Headers at Transit Routers

📅 published August 2022, from ietf

📜 RFC 9288: Recommendations on the Filtering of IPv6 Packets Containing IPv6 Extension Headers at Transit Routers 💖

okay bestie, buckle up 🎀✨ this one is all about IPv6 Extension Headers (EHs) and how transit routers should (and shouldn't) filter packets that carry them. it's literally a whole main character moment for router config 💅

The title block, the tea ☕:

  • Stream: Internet Engineering Task Force (IETF) 🌸
  • Number: RFC 9288 🦋
  • Authors: F. Gont (SI6 Networks) and W. Liu (Huawei Technologies) 👑
  • Category: Informational 🧚. not a Standards Track spec, it's published just for info 💜
  • ISSN: 2070-1721 ⭐
  • Date: August 2022 🍓
  • Obsoletes / Updates: the original title block doesn't list either, so nothing to note here 🙈

Abstract ✨

okay so the abstract is giving "here's the whole vibe in four sentences" 💖. it analyzes the security implications of IPv6 Extension Headers and their options 🔥. it also talks about the operational and interoperability fallout when you drop packets based on what EHs or options they contain 🫶. and finally, it gives advice on filtering these packets at transit routers for traffic that isn't actually addressed to them, but only in cases where that filtering is deemed necessary 🦋.

Status of This Memo 🌈

so this doc is not an Internet Standards Track specification; it's published for informational purposes 🎀. it's a product of the IETF and represents the consensus of the IETF community 💜. it got public review and was approved for publication by the Internet Engineering Steering Group (IESG) ✨. not everything the IESG approves is a candidate for any level of Internet Standard, see Section 2 of RFC 7841 😭. info about current status, errata, and how to give feedback lives at https://www.rfc-editor.org/info/rfc9288 🧚.

Copyright (c) 2022 IETF Trust and the persons identified as the document authors. All rights reserved 🌸. this doc is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) as in effect on the date of publication 🦋. please actually read those, they describe your rights and restrictions 🙈. code components pulled from this doc must include Revised BSD License text as described in Section 4.e of the Trust Legal Provisions, and they're provided without warranty as described in the Revised BSD License 🔥.

Table of Contents 🍓

1.  Introduction
2.  Terminology and Assumptions Employed in This Document
  2.1.  Terminology
  2.2.  Applicability Statement
  2.3.  Router Default Behavior and Features
3.  IPv6 Extension Headers
  3.1.  General Discussion
  3.2.  General Security Implications
  3.3.  Rationale for Our Advice on the Handling of IPv6 Packets
        with Specific IPv6 Extension Headers
  3.4.  Summary of Advice on the Handling of IPv6 Packets with
        Specific IPv6 Extension Headers
  3.5.  Advice on the Handling of IPv6 Packets with Specific IPv6
        Extension Headers
  3.6.  Advice on the Handling of Packets with Unknown IPv6
        Extension Headers
4.  IPv6 Options
  4.1.  General Discussion
  4.2.  General Security Implications of IPv6 Options
  4.3.  Summary of Advice on the Handling of IPv6 Packets with
        Specific IPv6 Options
  4.4.  Advice on the Handling of Packets with Specific IPv6
        Options
  4.5.  Advice on the Handling of Packets with Unknown IPv6 Options
5.  IANA Considerations
6.  Privacy Considerations
7.  Security Considerations
8.  References
  8.1.  Normative References
  8.2.  Informative References
Acknowledgements
Authors' Addresses

1. Introduction 🧚

okay so IPv6 Extension Headers (EHs) let the protocol grow and they hold up core stuff like IPv6 fragmentation 💖. the catch? EHs are a real headache for packet routing gear, especially when the router has to dig through the whole IPv6 header chain to enforce Access Control Lists (ACLs) or do other fancy stuff [RFC9098] 😭.

several studies ([Huston-2022], [JAMES], and [RFC7872]) suggest that IPv6 packets containing EHs get dropped all over the place 🙈. sometimes those drops happen at transit routers 🔥. some operators are known to drop EH packets on purpose, but honestly some of those measured drops might just be the result of bad advice out there 💀.

this doc looks at the general security implications of EHs, plus the security implications of specific EH and option types 🦋. it also gives advice on filtering IPv6 packets based on the EHs and options they carry 🫶. since lots of protocols use EHs (sometimes with options), dropping packets over them can wreck those protocols, so this doc also talks through the operational and interop side of those filtering policies 🌈.

here's the thing: the filtering policy usually depends on where it's enforced 💅. in a transit network, the policy usually follows a "deny-list" approach, where only packets with clear negative implications get dropped 🎀. closer to the destination systems, it usually follows an "accept-list" approach, where only expected traffic is allowed ✨. the advice here is aimed only at transit routers that may need a deny-list style filter based on EHs and options 🍓. so it's gonna be way more permissive than something you'd run at, say, the edge of an enterprise network 👑. the goal is to improve the current situation with EH packets getting dropped on the Internet [RFC7872], in cases where drops happen because of inappropriate or missing guidelines 🦋.

this doc is kinda similar to [RFC7126], which tackles the same problem for IPv4 🌸. but in IPv6 it's messier, because IPv6 defines a bunch of EHs and a bunch of options that are only valid inside certain EH types 😭.

this doc also completes and complements the considerations for protecting the control plane from packets with IP options found in [RFC6192] 💜.

quick map 🗺️: Section 2 covers terminology and conventions. Section 3 is about IPv6 EHs and filtering packets that contain them. Section 4 is about IPv6 options and filtering packets that contain those 🧚.

2. Terminology and Assumptions Employed in This Document 💅

2.1. Terminology 🎀

the terms "permit" (allow the traffic), "drop" (drop with no notification to sender), and "reject" (drop with appropriate notification to sender) are used as defined in [RFC3871] 🌸. we also use "discard" as a generic term for discarding a packet, no matter whether the sender gets notified or the action gets logged 🦋.

okay the key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this doc are to be read as described in BCP 14 [RFC2119] [RFC8174] 💖. but only when they show up in ALL CAPS like that 🫶.

2.2. Applicability Statement 🦋

this doc gives advice on filtering IPv6 packets with EHs at transit routers, for traffic that isn't explicitly destined to them 🌈. it's for cases where that filtering is deemed necessary 💅.

2.3. Router Default Behavior and Features ✨

this doc assumes nodes comply with the requirements in [RFC7045] 🎀. basically:

If a forwarding node discards a packet containing a standard IPv6 extension header, it MUST be the result of a configurable policy and not just the result of a failure to recognise such a header. This means that the discard policy for each standard type of extension header MUST be individually configurable. The default configuration SHOULD allow all standard extension headers.

ngl this is the big one 😭. a router dropping an EH has to be a deliberate, configurable choice, not an accident from not recognising the header 🔥. every standard EH type has to be individually configurable 🧚. and the default should allow all standard EHs 🌸.

the advice in this doc is only meant to help an operator configure forwarding devices 🍓. it's not advice on default config settings for network devices 🙈. so this doc gives operational guidance but doesn't change the implementation defaults required by [RFC7045] 💜.

we RECOMMEND that configuration options be available to govern how each IPv6 EH type and each IPv6 Option Type gets processed 💖. those options should include these possible settings 👑:

  • Permit this IPv6 EH or IPv6 Option Type.
  • Drop packets containing this IPv6 EH or IPv6 Option Type.
  • Reject packets containing this IPv6 EH or IPv6 Option Type (where the packet drop is signaled with an ICMPv6 error message).
  • Rate-limit traffic containing this IPv6 EH or IPv6 Option Type.
  • Ignore this IPv6 EH or IPv6 Option Type (as if it was not present), and process the packet according to the rules for the remaining headers. heads up: if a packet carries forwarding information (for example, in an IPv6 Routing Header (RH)), this might be an inappropriate or undesirable action 😬.

note that devices need special care when they log drops and rejects 🦋. devices should count the number of packets dropped or rejected, but logging those events should be limited so it doesn't overburden device resources 🫶.

last thing 🎀: when discarding packets, it's generally desirable to signal the sender about the drop, since that helps with troubleshooting 🌸. but throughout this doc, whenever it recommends discarding packets, we just say "discard" generically, without specifying whether the sender gets signaled 🧚.

Part 1 of 7 done bestie, more parts coming 💜🌈 keep the vibes going 🫶

3. IPv6 Extension Headers 💖 (continued)

3.2. General Security Implications ✨

Okay bestie, let's talk security 🔐 In some device architectures, IPv6 packets that contain IPv6 EHs can get pushed onto the slow path 🐢. That means they can be used for Denial-of-Service (DoS) attacks 💀 [RFC9098] [Cisco-EH] [FW-Benchmark]. Scary, I know 😭

Operators are urged to consider the IPv6 EH and IPv6 options handling capabilities of their devices as they make deployment decisions in the future 🫶 Homework for the network girlies 📝

3.3. Rationale for Our Advice on the Handling of IPv6 Packets with Specific IPv6 Extension Headers 🎀

So here's how we decided what to do with each kind of packet 💅 There are four main vibes:

  • IPv6 packets with IPv6 Extension Headers (or options) that are not expected to traverse transit routers should be dropped. Bye bye 👋
  • IPv6 packets with IPv6 Extension Headers (or options) that are only expected to traverse transit routers when a specific technology is employed should be permitted (or dropped) based on the knowledge regarding the use of such technology in the transit provider in question (i.e., permit the packets if the technology is employed, or drop them). It depends on the provider, bestie 🌸
  • IPv6 packets with IPv6 Extension Headers (or options) that represent a concrete attack vector to network infrastructure devices should be dropped. No thank you 🚫
  • IPv6 packets with any other IPv6 Extension Headers (or options) should be permitted. This is an intentional trade-off made to minimize ossification 🦋 Basically, we keep the door open so the Internet can keep evolving 🌈

3.4. Summary of Advice on the Handling of IPv6 Packets with Specific IPv6 Extension Headers 📋

Here's the cheat sheet 🧚 This section sums up the advice from Section 3.5, and it points you to the exact sections where the deep dive lives 💜

       +=====================+=========================+===========+
       |       EH Type       |     Filtering Policy    | Reference |
       +=====================+=========================+===========+
       |  Hop-by-Hop Options |      Drop or Ignore     |  Section  |
       |   Header (Proto=0)  |                         |   3.5.1   |
       +---------------------+-------------------------+-----------+
       |    Routing Header   |  Drop only Routing Type |  Section  |
       |      (Proto=43)     |  0, Routing Type 1, and |   3.5.2   |
       |                     | Routing Type 3.  Permit |           |
       |                     |   other Routing Types   |           |
       +---------------------+-------------------------+-----------+
       |   Fragment Header   |          Permit         |  Section  |
       |      (Proto=44)     |                         |   3.5.3   |
       +---------------------+-------------------------+-----------+
       |    Encapsulating    |          Permit         |  Section  |
       |   Security Payload  |                         |   3.5.4   |
       |      (Proto=50)     |                         |           |
       +---------------------+-------------------------+-----------+
       |    Authentication   |          Permit         |  Section  |
       |  Header (Proto=51)  |                         |   3.5.5   |
       +---------------------+-------------------------+-----------+
       | Destination Options |          Permit         |  Section  |
       |   Header(Proto=60)  |                         |   3.5.6   |
       +---------------------+-------------------------+-----------+
       |   Mobility Header   |          Permit         |  Section  |
       |     (Proto=135)     |                         |   3.5.7   |
       +---------------------+-------------------------+-----------+
       |    Host Identity    |          Permit         |  Section  |
       |       Protocol      |                         |   3.5.8   |
       |     (Proto=139)     |                         |           |
       +---------------------+-------------------------+-----------+
       |    Shim6 Protocol   |          Permit         |  Section  |
       |     (Proto=140)     |                         |   3.5.9   |
       +---------------------+-------------------------+-----------+
       |       Use for       |           Drop          |  Section  |
       | experimentation and |                         |   3.5.10  |
       |  testing (Proto=253 |                         |           |
       |       and 254)      |                         |           |
       +---------------------+-------------------------+-----------+

             Table 1: Summary of Advice on the Handling of IPv6
                Packets with Specific IPv6 Extension Headers

3.5. Advice on the Handling of IPv6 Packets with Specific IPv6 Extension Headers 🌸

Now for the juicy stuff, one header at a time 💅

3.5.1. IPv6 Hop-by-Hop Options (Protocol Number=0) 🧚

3.5.1.1. Uses

The Hop-by-Hop (HBH) Options header carries optional info that every node along a packet's delivery path can look at 👀 Nodes are expected to examine the Hop-by-Hop Options header if they've been explicitly configured to do so ⚙️

NOTE: A previous revision of the IPv6 core specification [RFC2460] originally required all nodes to examine and process the Hop-by-Hop Options header. However, even before the publication of [RFC8200], a number of implementations already provided the option of ignoring this header unless explicitly configured to examine it. Plot twist, it used to be mandatory 😳

3.5.1.2. Specification

This EH is specified in [RFC8200]. As of May 2022, these are the options that have been specified for the Hop-by-Hop Options header:

3.5.1.3. Specific Security Implications

Legacy nodes that process this extension header might be subject to DoS attacks 💀

NOTE: While [RFC8200] has removed the requirement for all nodes to examine and process the Hop-by-Hop Options header, the deployed base may still reflect the legacy [RFC2460] behavior for a while. Hence, the potential security problems of this EH are still of concern 🙈

3.5.1.4. Operational and Interoperability Impact If Blocked

Discarding packets with a Hop-by-Hop Options header would break any protocol that relies on it for proper functioning 😬 For example, it would break RSVP [RFC2205] and multicast deployments, and it would cause IPv6 jumbograms to be discarded.

3.5.1.5. Advice

Nodes implementing [RFC8200] would already ignore this extension header unless explicitly required to process it ✨ For legacy nodes [RFC2460], the recommended configuration for processing these packets depends on the features and capabilities of the underlying platform, the configuration of the platform, and the deployment environment of the platform. On platforms that allow forwarding packets with IPv6 HBH Options headers on the fast path, we recommend forwarding those packets as normal 🏃‍♀️ Otherwise, on platforms where packets with IPv6 HBH Options headers are processed on the slow path and an option exists to rate-limit these packets, we recommend selecting that option 🚦 Finally, when packets containing IPv6 HBH Options headers are processed on the slow path and the platform has no mitigation options for attacks based on these packets, we recommend that such platforms discard those packets 🗑️

Finally, we note that Routing Protocol for Low-Power and Lossy Networks (RPL) routers [RFC6550] must not discard packets based on the presence of an IPv6 Hop-by-Hop Options header, as this would break RPL 🚨

3.5.2. Routing Header (Protocol Number=43) 🦋

3.5.2.1. Uses

The Routing Header is how an IPv6 source lists one or more intermediate nodes to be "visited" on the way to a packet's destination 🗺️

3.5.2.2. Specification

This EH is specified in [RFC8200]. The Routing Type 0 was originally specified in [RFC2460], was later obsoleted by [RFC5095], and was therefore removed from [RFC8200] 👋

As of May 2022, these are the Routing Types that have been specified:

  • Type 0: Source Route (DEPRECATED) [RFC2460] [RFC5095]
  • Type 1: Nimrod (DEPRECATED)
  • Type 2: Type 2 Routing Header [RFC6275]
  • Type 3: RPL Source Route Header [RFC6554]
  • Type 4: Segment Routing Header (SRH) [RFC8754]
  • Types 5-252: Unassigned
  • Type 253: RFC3692-style Experiment 1 [RFC4727]
  • Type 254: RFC3692-style Experiment 2 [RFC4727]
  • Type 255: Reserved

3.5.2.3. Specific Security Implications

The security implications of Routing Headers of Routing Type 0 have been discussed in detail in [Biondi-2007] and [RFC5095]. Routing Type 1 was never widely implemented 🤷‍♀️ The security implications of Routing Headers of Routing Type 2, Routing Type 3, and Routing Type 4 (SRH) are discussed in [RFC6275], [RFC6554], and [RFC8754], respectively 📚

3.5.2.4. Operational and Interoperability Impact If Blocked

Blocking packets with Routing Headers of Routing Type 0 or Routing Type 1 has no operational implications, since both have been deprecated 🙌 Blocking packets with Routing Headers of Routing Type 2 would break Mobile IPv6 📱 Packets with Routing Headers of Routing Type 3 may be safely blocked at RPL domain boundaries, since such headers are employed within a single RPL domain 🧱 Blocking packets with Routing Headers of Routing Type 4 (SRH) will break Segment Routing (SR) deployments if the filtering policy is enforced on packets being forwarded within an SR domain 💔

3.5.2.5. Advice

Intermediate systems should discard packets with Routing Headers of Routing Type 0, Routing Type 1, or Routing Type 3. Other Routing Types should be permitted, as required by [RFC7045] 💅

3.5.3. Fragment Header (Protocol Number=44) 🧩

3.5.3.1. Uses

This EH provides the fragmentation and reassembly functionality for IPv6 ✂️🔗

3.5.3.2. Specification

This EH is specified in [RFC8200].

3.5.3.3. Specific Security Implications

The security implications of the Fragment Header range from DoS attacks (e.g., based on flooding a target with IPv6 fragments) to information leakage attacks [RFC7739]. Yikes 😭

3.5.3.4. Operational and Interoperability Impact If Blocked

Blocking packets that contain a Fragment Header will break any protocol that may rely on fragmentation (e.g., the DNS [RFC1034]). However, IP fragmentation is known to introduce fragility to Internet communication [RFC8900] 🫠

3.5.3.5. Advice

Intermediate systems should permit packets that contain a Fragment Header 🌈

3.5.4. Encapsulating Security Payload (Protocol Number=50) 🔐

3.5.4.1. Uses

This EH is employed for the IPsec suite [RFC4303] 🛡️

3.5.4.2. Specification

This EH is specified in [RFC4303].

3.5.4.3. Specific Security Implications

Okay bestie, besides the general IPv6 EH drama 💅, this EH could be used to pull off a DoS attack at the destination system by wasting CPU resources while it checks the contents of the packet 😭🔥

3.5.4.4. Operational and Interoperability Impact If Blocked

ngl, discarding packets that use this EH would break IPsec deployments 💀

3.5.4.5. Advice

Intermediate systems should permit packets containing the Encapsulating Security Payload EH 🫶

3.5.5. Authentication Header (Protocol Number=51)

3.5.5.1. Uses

The Authentication Header can be used to provide authentication services in IPv4 and IPv6 🔐

3.5.5.2. Specification

This EH is specified in [RFC4302]. 📜

3.5.5.3. Specific Security Implications

Besides the general implications of IPv6 EHs, this EH could be used to pull off a DoS attack at the destination system by wasting CPU resources while it validates the contents of the packet 😩

3.5.5.4. Operational and Interoperability Impact If Blocked

Discarding packets that use this EH would break IPsec deployments 💔

3.5.5.5. Advice

Intermediate systems should permit packets containing an Authentication Header 🌸

3.5.6. Destination Options (Protocol Number=60)

3.5.6.1. Uses

The Destination Options (DO) header carries optional information that needs be examined only by a packet's destination node(s) 🎀

3.5.6.2. Specification

This EH is specified in [RFC8200]. As of May 2022, the following options have been specified for this EH:

3.5.6.3. Specific Security Implications

No security implications are known, other than the general security implications of IPv6 EHs. For a discussion of possible security implications of specific options specified for the DO header, please see Section 4.4 🔍

3.5.6.4. Operational and Interoperability Impact If Blocked

Discarding packets that contain a Destination Options header would break protocols that rely on this EH type to convey information, such as the Identifier-Locator Network Protocol (ILNP) [RFC6740] and Mobile IPv6 [RFC6275]. It would also break IPv6 tunnels that use the Tunnel Encapsulation Limit option [RFC2473] 🥺

3.5.6.5. Advice

Intermediate systems should permit packets that contain a Destination Options header ✨

3.5.7. Mobility Header (Protocol Number=135)

3.5.7.1. Uses

The Mobility Header is an EH used by mobile nodes, correspondent nodes, and home agents in all messaging related to creating and managing bindings in Mobile IPv6 🦋

3.5.7.2. Specification

This EH is specified in [RFC6275].

3.5.7.3. Specific Security Implications

A thorough security assessment of the Mobility Header and related mechanisms can be found in Section 15 of [RFC6275] 🧐

3.5.7.4. Operational and Interoperability Impact If Blocked

Discarding packets containing this EH would break Mobile IPv6 🙈

3.5.7.5. Advice

Intermediate systems should permit packets that contain a Mobility Header 💜

3.5.8. Host Identity Protocol (Protocol Number=139)

3.5.8.1. Uses

This EH is used with the Host Identity Protocol (HIP). HIP is a protocol that lets consenting hosts securely establish and maintain shared IP-layer state. It separates the identifier and locator roles of IP addresses, which enables continuity of communications across IP address changes 🧚

3.5.8.2. Specification

This EH is specified in [RFC7401].

3.5.8.3. Specific Security Implications

The security implications of the HIP header are discussed in detail in Section 8 of [RFC7401] 🔐

3.5.8.4. Operational and Interoperability Impact If Blocked

Discarding packets that contain a HIP header would break HIP deployments 😵

3.5.8.5. Advice

Intermediate systems should permit packets that contain a HIP header 🌷

3.5.9. Shim6 Protocol (Protocol Number=140)

3.5.9.1. Uses

This EH is used by the Shim6 protocol [RFC5533] 🍓

3.5.9.2. Specification

This EH is specified in [RFC5533].

3.5.9.3. Specific Security Implications

The specific security implications are discussed in detail in Section 16 of [RFC5533] 🫣

3.5.9.4. Operational and Interoperability Impact If Blocked

Discarding packets that contain this EH will break Shim6 💥

3.5.9.5. Advice

Intermediate systems should permit packets containing this EH 🌈

3.5.10. Use for Experimentation and Testing (Protocol Numbers=253 and 254)

3.5.10.1. Uses

These IPv6 EHs are used for performing RFC3692-style experiments (see [RFC3692] for details) 🧪

3.5.10.2. Specification

These EHs are specified in [RFC3692] and [RFC4727].

3.5.10.3. Specific Security Implications

The security implications of these EHs will depend on their specific use.

3.5.10.4. Operational and Interoperability Impact If Blocked

For obvious reasons, discarding packets that contain these EHs limits the ability to perform legitimate experiments across IPv6 routers 🥹

3.5.10.5. Advice

Operators should determine, according to their own circumstances, whether to discard packets containing these EHs 👑

3.6. Advice on the Handling of Packets with Unknown IPv6 Extension Headers

We refer to IPv6 EHs that have not been assigned an Internet Protocol number by IANA (and marked as such) in [IANA-PROTOCOLS] as "unknown IPv6 Extension Headers" ("unknown IPv6 EHs") 🕵️‍♀️

3.6.1. Uses

New IPv6 EHs may be specified as part of future extensions to the IPv6 protocol 🔮

Since IPv6 EHs and upper-layer protocols use the same namespace, it is impossible to tell whether an unknown Internet Protocol number is being used for an IPv6 EH or for an upper-layer protocol 🤯

3.6.2. Specification

The processing of unknown IPv6 EHs is specified in [RFC7045].

3.6.3. Specific Security Implications

For obvious reasons, it is impossible to determine the specific security implications of unknown IPv6 EHs 🫠

3.6.4. Operational and Interoperability Impact If Blocked

As noted in [RFC7045], discarding unknown IPv6 EHs may slow down the deployment of new IPv6 EHs and transport protocols. The corresponding IANA registry, which is [IANA-PROTOCOLS], should be monitored so that filtering rules are updated as new IPv6 EHs are standardized 📋

We note that since IPv6 EHs and upper-layer protocols share the same numbering space, discarding unknown IPv6 EHs may result in packets encapsulating unknown upper-layer protocols being discarded too 😬

3.6.5. Advice

Operators should determine, according to their own circumstances, whether to discard packets containing unknown IPv6 EHs 💅

4. IPv6 Options

4.1. General Discussion

The following subsections describe specific security implications of different IPv6 options and give advice on filtering packets that contain such options 🎀

4.2. General Security Implications of IPv6 Options

The general security implications of IPv6 options are closely related to those discussed in Section 3.2 for IPv6 EHs. Essentially, packets that contain IPv6 options might need to be processed by an IPv6 router's general-purpose CPU. That means they could present a Distributed Denial-of-Service (DDoS) risk to that router's general-purpose CPU, and thus to the router itself 🚨 For some architectures, a possible mitigation would be to rate-limit the packets that are to be processed by the general-purpose CPU (see, e.g., [Cisco-EH]) 🫶

4.3. Summary of Advice on the Handling of IPv6 Packets with Specific IPv6 Options

okay so this section is basically the cheat sheet 📋✨ It sums up the advice from Section 4.4 and tells you where to find the full tea for each option. 🫶

   +===============================+======================+===========+
   |             Option            |   Filtering Policy   | Reference |
   +===============================+======================+===========+
   |        Pad1 (Type=0x00)       |        Permit        |  Section  |
   |                               |                      |   4.4.1   |
   +-------------------------------+----------------------+-----------+
   |        PadN (Type=0x01)       |        Permit        |  Section  |
   |                               |                      |   4.4.2   |
   +-------------------------------+----------------------+-----------+
   |   Tunnel Encapsulation Limit  |        Permit        |  Section  |
   |          (Type=0x04)          |                      |   4.4.3   |
   +-------------------------------+----------------------+-----------+
   |    Router Alert (Type=0x05)   |   Permit based on    |  Section  |
   |                               | needed functionality |   4.4.4   |
   +-------------------------------+----------------------+-----------+
   |      CALIPSO (Type=0x07)      |   Permit based on    |  Section  |
   |                               | needed functionality |   4.4.5   |
   +-------------------------------+----------------------+-----------+
   |      SMF_DPD (Type=0x08)      |   Permit based on    |  Section  |
   |                               | needed functionality |   4.4.6   |
   +-------------------------------+----------------------+-----------+
   |     PDM Option (Type=0x0F)    |        Permit        |  Section  |
   |                               |                      |   4.4.7   |
   +-------------------------------+----------------------+-----------+
   |     RPL Option (Type=0x23)    |        Permit        |  Section  |
   |                               |                      |   4.4.8   |
   +-------------------------------+----------------------+-----------+
   |    Quick-Start (Type=0x26)    |        Permit        |  Section  |
   |                               |                      |   4.4.9   |
   +-------------------------------+----------------------+-----------+
   |     Deprecated (Type=0x4D)    |         Drop         |  Section  |
   |                               |                      |   4.4.10  |
   +-------------------------------+----------------------+-----------+
   |     MPL Option (Type=0x6D)    |        Permit        |  Section  |
   |                               |                      |   4.4.12  |
   +-------------------------------+----------------------+-----------+
   |   Jumbo Payload (Type=0xC2)   |   Permit based on    |  Section  |
   |                               | needed functionality |   4.4.16  |
   +-------------------------------+----------------------+-----------+
   |     RPL Option (Type=0x63)    |         Drop         |  Section  |
   |                               |                      |   4.4.11  |
   +-------------------------------+----------------------+-----------+
   |    Endpoint Identification    |         Drop         |  Section  |
   |          (Type=0x8A)          |                      |   4.4.13  |
   +-------------------------------+----------------------+-----------+
   |     ILNP Nonce (Type=0x8B)    |        Permit        |  Section  |
   |                               |                      |   4.4.14  |
   +-------------------------------+----------------------+-----------+
   |   Line-Identification Option  |         Drop         |  Section  |
   |          (Type=0x8C)          |                      |   4.4.15  |
   +-------------------------------+----------------------+-----------+
   |    Home Address (Type=0xC9)   |        Permit        |  Section  |
   |                               |                      |   4.4.17  |
   +-------------------------------+----------------------+-----------+
   |       IP_DFF (Type=0xEE)      |   Permit based on    |  Section  |
   |                               | needed functionality |   4.4.18  |
   +-------------------------------+----------------------+-----------+
   |    RFC3692-style Experiment   |   Permit based on    |  Section  |
   |   (Types = 0x1E, 0x3E, 0x5E,  | needed functionality |   4.4.19  |
   | 0x7E, 0x9E, 0xBE, 0xDE, 0xFE) |                      |           |
   +-------------------------------+----------------------+-----------+

     Table 2: Summary of Advice on the Handling of IPv6 Packets with
                          Specific IPv6 Options

4.4. Advice on the Handling of Packets with Specific IPv6 Options

this is the deep dive 🫧 Every IPv6 option that has been specified so far gets its own subsection. Each one covers what it's for, where it's defined, its security implications, what could go wrong if packets with it get discarded, and specific advice on whether those packets should be permitted. 💅

4.4.1. Pad1 (Type=0x00)

4.4.1.1. Uses

this one is used when it's necessary to line up the options after it and pad out the header so it's a multiple of 8 octets long. 🎀

4.4.1.2. Specification

this option is specified in [RFC8200]. 📖

4.4.1.3. Specific Security Implications

none! 🫶

4.4.1.4. Operational and Interoperability Impact If Blocked

discarding packets that contain this option would potentially break any protocol that relies on IPv6 options. 😭

4.4.1.5. Advice

intermediate systems should not discard packets based on the presence of this option. 🌸

4.4.2. PadN (Type=0x01)

4.4.2.1. Uses

same energy as Pad1 ✨ It's used when it's necessary to align the subsequent options and pad out the containing header to a multiple of 8 octets in length.

4.4.2.2. Specification

this option is specified in [RFC8200]. 📖

4.4.2.3. Specific Security Implications

okay this is the red flag 🚩 Because this option can be pretty big, it could be leveraged as a large-bandwidth covert channel. 💀

4.4.2.4. Operational and Interoperability Impact If Blocked

discarding packets that contain this option would potentially break any protocol that relies on IPv6 options. 😭

4.4.2.5. Advice

intermediate systems should not discard IPv6 packets based on the presence of this option. 🌸

4.4.3. Tunnel Encapsulation Limit (Type=0x04)

4.4.3.1. Uses

this option can be used to say how many more levels of nesting the packet is allowed to go through. 🧚

4.4.3.2. Specification

this option is specified in [RFC2473]. 📖

4.4.3.3. Specific Security Implications

these are discussed in [RFC2473]. 🔗

4.4.3.4. Operational and Interoperability Impact If Blocked

discarding packets based on the presence of this option could result in tunnel traffic being discarded. 🥺

4.4.3.5. Advice

intermediate systems should not discard packets based on the presence of this option. 🌸

4.4.4. Router Alert (Type=0x05)

4.4.4.1. Uses

the Router Alert option [RFC2711] is used by a bunch of protocols, including the Resource reSerVation Protocol (RSVP) [RFC2205], Multicast Listener Discovery (MLD) [RFC2710] [RFC3810], Multicast Router Discovery (MRD) [RFC4286], and General Internet Signaling Transport (GIST) [RFC5971]. Its usage is discussed in detail in [RFC6398]. 👑

4.4.4.2. Specification

this option is specified in [RFC2711]. 📖

4.4.4.3. Specific Security Implications

this one is a little spicy 🌶️ Since this option makes the handling device inspect the contents of the packet, it could be leveraged to perform DoS attacks. The security implications of the Router Alert option are discussed in detail in [RFC6398]. ⚠️

4.4.4.4. Operational and Interoperability Impact If Blocked

discarding packets that contain this option would break any protocols that rely on them, such as RSVP and multicast deployments. Please see Section 4.4.4.3 for further details. 🙈

4.4.4.5. Advice

packets containing this option should be permitted in environments where support for RSVP, multicast routing, or similar protocols is required. 💜

4.4.5. CALIPSO (Type=0x07)

4.4.5.1. Uses

this option is used for encoding explicit packet Sensitivity Labels on IPv6 packets. It's only meant for use within Multi-Level Secure (MLS) networking environments that are both trusted and trustworthy. 🔐

4.4.5.2. Specification

this option is specified in [RFC5570]. 📖

4.4.5.3. Specific Security Implications

the presence of this option in a packet doesn't create any specific new threat by itself 🫶 Packets with this option ought not normally be seen on the global public Internet. 🌍

4.4.5.4. Operational and Interoperability Impact If Blocked

okay this part is important, bestie 😭 If packets with this option are discarded, or if the option gets stripped from the packet on the way from source to destination, the packet itself is likely to be discarded by the receiver because it isn't properly labeled. In some cases, the receiver might get the packet but attach the wrong Sensitivity Label to the data, because the Common Architecture Label IPv6 Security Option (CALIPSO) was stripped by a middlebox (such as a packet scrubber). Attaching an incorrect Sensitivity Label can cause the received information to be handled as more sensitive than it really is ("upgrading") or as less sensitive than it really is ("downgrading"), and either one is a problem. 🚨 As noted in [RFC5570], IPsec [RFC4301] [RFC4302] [RFC4303] can be used to protect the CALIPSO. 🔒

4.4.5.5. Advice

the recommendations for handling the CALIPSO depend on the deployment environment, not on whether an intermediate system happens to be deployed as a transit device (e.g., IPv6 transit router). 🗺️

Explicit configuration is the only way an intermediate system can know whether it has been deployed within an MLS environment. In many cases, ordinary commercial intermediate systems (e.g., IPv6 routers and firewalls) make up the majority of the deployed intermediate systems inside an MLS network environment. 🏢

For intermediate systems that DO NOT implement [RFC5570], there should be a configuration option to either (a) drop packets containing the CALIPSO or (b) ignore the presence of the CALIPSO and forward the packets normally. In non-MLS environments, such intermediate systems should have this configuration option set to (a) above. In MLS environments, such intermediate systems should have this option set to (b) above. The default setting for this configuration option should be set to (a) above, because MLS environments are much less common than non-MLS environments. 🛡️

For intermediate systems that DO implement [RFC5570], there should be configuration options (a) and (b) from the preceding paragraph, and also a third configuration option (c) to process packets containing a CALIPSO as per [RFC5570]. When deployed in non-MLS environments, such intermediate systems should have this configuration option set to (a) above. When deployed in MLS environments, such intermediate systems should have this configuration option set to (c). The default setting for this configuration option MAY be set to (a) above, because MLS environments are much less common than non-MLS environments. ✨

4.4.6. SMF_DPD (Type=0x08)

4.4.6.1. Uses ✨

okay so this option is used in the (experimental) Simplified Multicast Forwarding (SMF) 🦋. It gives each packet a unique ID for IPv6 Identification-based DPD (I-DPD) 🔍, and it also keeps hash values from colliding for different packets when Hash-based DPD (H-DPD) is in use 💅. Iconic.

4.4.6.2. Specification 📜

this one is specified in [RFC6621] 🌸

4.4.6.3. Specific Security Implications 🔐

none! ✨ but the use of transient numeric identifiers comes with the security and privacy considerations discussed in [NUMERIC-IDS]. don't skip that part bestie 🙈

4.4.6.4. Operational and Interoperability Impact If Blocked 🚧

dropping packets with this option inside a Mobile Ad Hoc Network (MANET) domain would break SMF 💀. BUT dropping them at the border of that domain has no negative impact at all 🫶

4.4.6.5. Advice 💡

intermediate systems that are not within a MANET domain should discard packets that contain this option.

4.4.7. PDM (Type=0x0F) 🎀

4.4.7.1. Uses 🌈

this option is used to carry sequence numbers and timing information in IPv6 packets so they can be the basis for measurements 📊 ngl that's so useful

4.4.7.2. Specification 📜

this one is specified in [RFC8250] ✨

4.4.7.3. Specific Security Implications 🔐

these are discussed in [RFC8250]. also, since this option uses transient numeric identifiers, implementations may be subject to the issues discussed in [NUMERIC-IDS] 🙈

4.4.7.4. Operational and Interoperability Impact If Blocked 🚧

dropping packets with this option will cause negative interoperability implications for any traffic that uses it as the basis for measurements 😭

4.4.7.5. Advice 💡

intermediate systems should not discard packets based on the presence of this option 🫶

4.4.8. RPL Option (Type=0x23) 🧚

4.4.8.1. Uses 🌸

the RPL Option is a way to put routing information into each datagram that an RPL router forwards 🦋

4.4.8.2. Specification 📜

this one is specified in [RFC9008] 💖

4.4.8.3. Specific Security Implications 🔐

these are discussed in [RFC9008] ✨

4.4.8.4. Operational and Interoperability Impact If Blocked 🚧

this option can survive outside of an RPL instance 👀 so discarding packets based on it would break some RPL use cases (see [RFC9008]) 😭

4.4.8.5. Advice 💡

intermediate systems should not discard IPv6 packets based on the presence of this option 💅

4.4.9. Quick-Start (Type=0x26) ⚡

4.4.9.1. Uses 🌈

this IP option shows up in the spec for Quick-Start for TCP and IP ⚡ which is an experimental mechanism. it lets transport protocols, working together with routers, figure out an allowed sending rate at the start of a data transfer and, at times, in the middle of one too (e.g., after an idle period) [RFC4782] 🦋

4.4.9.2. Specification 📜

this one is specified in [RFC4782] on the "Experimental" track 🧪

4.4.9.3. Specific Security Implications 🔐

okay the security tea ☕ Section 9.6 of [RFC4782] notes that Quick-Start is vulnerable to two kinds of attacks:

  • attacks to increase the routers' processing and state load and
  • attacks with bogus Quick-Start Requests to temporarily tie up available Quick-Start bandwidth, preventing routers from approving Quick-Start Requests from other connections
⚠️ we also note that if routers in a given environment don't implement and enable the Quick-Start mechanism, only the general security implications of IP options (discussed in Section 4.2) would apply 🛡️

4.4.9.4. Operational and Interoperability Impact If Blocked 🚧

if packets with IPv6 Quick Start options are blocked, the host trying to set up a TCP connection will fall back to not including the Quick Start option 😭 which means the feature gets disabled and connection setup takes extra time (as discussed in Section 4.7.2 of [RFC4782]). we also note that Quick-Start was proposed as something that could be useful in controlled environments, and NOT as something that would be intended or appropriate for ubiquitous deployment in the global Internet [RFC4782] 🌍

4.4.9.5. Advice 💡

intermediate systems should not discard IPv6 packets based on the presence of this option ✨

4.4.10. Deprecated (Type=0x4D) 🥀

4.4.10.1. Uses 🌫️

no information has been found about this option type 🤷‍♀️

4.4.10.2. Specification 📜

no information has been found about this option type 🤷‍♀️

4.4.10.3. Specific Security Implications 🔐

no information has been found about this option type; hence, it has been impossible to perform the corresponding security assessment 💀

4.4.10.4. Operational and Interoperability Impact If Blocked 🚧

unknown 🫠

4.4.10.5. Advice 💡

intermediate systems should discard packets that contain this option.

4.4.11. RPL Option (Type=0x63) 🧚

4.4.11.1. Uses 🌸

the RPL Option is a way to put routing information into each datagram that an RPL router forwards 🦋

4.4.11.2. Specification 📜

this option was originally specified in [RFC6553] 🕰️ and it has since been deprecated by [RFC9008] 🪦

4.4.11.3. Specific Security Implications 🔐

these are discussed in Section 5 of [RFC6553] ✨

4.4.11.4. Operational and Interoperability Impact If Blocked 🚧

this option is meant to be used inside an RPL instance 💜 so discarding packets with it outside of an RPL instance won't cause any interoperability implications 🙌

4.4.11.5. Advice 💡

intermediate systems should discard packets that contain an RPL Option.

4.4.12. MPL Option (Type=0x6D) 🌊

4.4.12.1. Uses 🌸

this option is used with the Multicast Protocol for Low power and Lossy Networks (MPL), which gives you IPv6 multicast forwarding in constrained networks 🌐

4.4.12.2. Specification 📜

this one is specified in [RFC7731] and it's meant to be included only in Hop-by-Hop Options headers 🎀

4.4.12.3. Specific Security Implications 🔐

these are discussed in [RFC7731] ✨

4.4.12.4. Operational and Interoperability Impact If Blocked 🚧

dropping packets with an MPL Option inside an MPL network would break the MPL 💀 but dropping them at the border of those networks has no negative impact 🫶

4.4.12.5. Advice 💡

intermediate systems should not discard packets based on the presence of this option. however, since this option has been specified for the Hop-by-Hop Options header, such systems should consider the discussion in Section 3.5.1 🧠

4.4.13. Endpoint Identification (Type=0x8A) 🗺️

4.4.13.1. Uses 🌸

this option was meant to be used with the Nimrod routing architecture [NIMROD-DOC] but it has never seen widespread deployment 🥲

4.4.13.2. Specification 📜

this one is specified in [NIMROD-DOC] 💖

4.4.13.3. Specific Security Implications 🔐

undetermined 🤷‍♀️

4.4.13.4. Operational and Interoperability Impact If Blocked 🚧

none ✨

4.4.13.5. Advice 💡

intermediate systems should discard packets that contain this option.

4.4.14. ILNP Nonce (Type=0x8B) 🔑

4.4.14.1. Uses 🌸

this option is used by the Identifier-Locator Network Protocol for IPv6 (ILNPv6) 🦋 to protect packets against off-path attacks when ILNPv6 is in use. it also acts as a signal during initial network-layer session creation that ILNPv6 is proposed for that session, rather than classic IPv6 🙌

4.4.14.2. Specification 📜

this one is specified in [RFC6744] ✨

4.4.14.3. Specific Security Implications 🔐

these are discussed in [RFC6744] 💅

4.4.14.4. Operational and Interoperability Impact If Blocked 🚧

discarding packets that contain this option will break ILNPv6 deployments 😭

4.4.14.5. Advice 💡

intermediate systems should not discard packets based on the presence of this option 🫶

4.4.15. Line-Identification Option (Type=0x8C) 🏠

4.4.15.1. Uses 🌸

an Edge Router uses this option to identify subscriber premises in scenarios where several subscriber premises may be logically connected to the same interface of that Edge Router 🏘️

4.4.15.2. Specification 📜

this one is specified in [RFC6788] 💖

4.4.15.3. Specific Security Implications 🔐

these are discussed in [RFC6788] ✨

4.4.15.4. Operational and Interoperability Impact If Blocked 🚧

since this option is meant to be used when tunneling Neighbor Discovery messages in some broadband network deployment scenarios, discarding packets based on it at intermediate systems results in no interoperability implications 🙌

4.4.15.5. Advice 💡

intermediate systems should discard packets that contain this option.

4.4.16. Jumbo Payload (Type=0XC2) 🐘

4.4.16.1. Uses 🌸

the Jumbo Payload option gives us a way to support payloads larger than 65535 bytes 🫧

4.4.16.2. Specification 📜

this one is specified in [RFC2675] 💖

4.4.16.3. Specific Security Implications 🔐

there are no specific issues from this option, EXCEPT for improper validity checks of the option and the associated packet lengths 👀

4.4.16.4. Operational and Interoperability Impact If Blocked 🚧

discarding packets based on this option will cause IPv6 jumbograms to be discarded 😭

4.4.16.5. Advice 💡

an operator should permit this option only in specific scenarios in which support for IPv6 jumbograms is required 🎯

4.4.17. Home Address (Type=0xC9) 🏡

4.4.17.1. Uses 🌸

a Mobile IPv6 node uses the Home Address option while it's away from home, to tell the recipient what its home address is 🧳

4.4.17.2. Specification 📜

this one is specified in [RFC6275] ✨

4.4.17.3. Specific Security Implications 🔐

there are no (known) additional security implications other than those discussed in [RFC6275] 🛡️

4.4.17.4. Operational and Interoperability Impact If Blocked 🚧

discarding IPv6 packets based on this option will break Mobile IPv6 💀

4.4.17.5. Advice 💡

intermediate systems should not discard IPv6 packets based on the presence of this option 🫶

4.4.18. IP_DFF (Type=0xEE) 🌲

4.4.18.1. Uses 🌸

this option is used with the (experimental) Depth-First Forwarding (DFF) in unreliable networks 🧪

4.4.18.2. Specification 📜

this one is specified in [RFC6971] 💖

4.4.18.3. Specific Security Implications 🔐

these are specified in [RFC6971] ✨

4.4.18.4. Operational and Interoperability Impact If Blocked 🚧

dropping packets with this option inside a routing domain that's running DFF would break DFF 💀 but dropping them at the border of those domains has no operational or interoperability implications 🙌

4.4.18.5. Advice 💡

intermediate systems that do not operate within a routing domain running DFF should discard packets containing this option.

4.4.19. RFC3692-Style Experiment (Types = 0x1E, 0x3E, 0x5E, 0x7E, 0x9E, 0xBE, 0xDE, 0xFE) 🧬

4.4.19.1. Uses 🌸

these options can be used for RFC3692-style experiments. it's only appropriate to use these values in explicitly configured experiments; they must not be shipped as defaults in implementations ⚠️

4.4.19.2. Specification 📜

these options are specified in [RFC4727] in the context of RFC3692-style experiments 💖

4.4.19.3. Specific Security Implications 🔐

the specific security implications depend on the specific use of these options 🤔

4.4.19.4. Operational and Interoperability Impact If Blocked 🚧

for obvious reasons, discarding packets that contain these options limits the ability to run legitimate experiments across IPv6 routers 🧪

4.4.19.5. Advice 💡

operators should decide for themselves, based on their own circumstances, whether to discard packets containing these IPv6 options 🫶

4.5. Advice on the Handling of Packets with Unknown IPv6 Options ✨

okay so we need a name for IPv6 options that don't have an IPv6 Option Type assigned in the corresponding registry, which is [IANA-IPV6-PARAM] 🧚 bestie, those get called "unknown IPv6 options" and it's giving very mysterious energy 🔮

4.5.1. Uses

new IPv6 options may be specified as part of future protocol work 🌱 the vibe is "watch this space" 👀

4.5.2. Specification

the processing of unknown IPv6 options is specified in [RFC8200] 📜 go read that one if you want the official rules, no cap

4.5.3. Specific Security Implications

ngl this one is short and honest 💀 for obvious reasons, it is impossible to determine specific security implications of unknown IPv6 options. you can't really assess the risks of something nobody has defined yet 🙈

4.5.4. Operational and Interoperability Impact If Blocked

okay this part is important 🚨 discarding unknown IPv6 options may slow down the deployment of new IPv6 options 🐢 it's like blocking the new kid before they even get to school 🏫

as noted in [IPv6-OPTIONS], the corresponding IANA registry, which is [IANA-IPV6-PARAM], should be monitored so that IPv6 option filtering rules get updated as new IPv6 options are standardized 👀 keep an eye on that registry, periodt 💅

4.5.5. Advice

operators should determine, according to their own circumstances, whether to discard packets containing unknown IPv6 options 🎀 every network is its own little world, so this one is a judgement call for the people running it 🌸

5. IANA Considerations

this document has no IANA actions 🦋 nothing to register, nothing to update, we're chilling ✨

6. Privacy Considerations

there are no privacy considerations associated with this document 🫶 no privacy drama here, thank u next 💜

7. Security Considerations

okay, the security section is the one you really need to read, bestie 🔥 this document provides advice on the filtering of IPv6 packets that contain IPv6 EHs (and possibly IPv6 options) at IPv6 transit routers 🚦 the goal is to improve the current situation of widespread dropping of such IPv6 packets in those cases where the drops result from improper configuration defaults or inappropriate advice in this area 😭 so many networks were just dropping stuff by accident!!

as discussed in Section 3.3, one of the underlying principles for the advice provided in this document is that IPv6 packets with specific EHs or options that may represent an attack vector for infrastructure devices should be dropped 🛡️ this policy helps mitigate some specific attack vectors, but the recommendations in this document will not help to mitigate vulnerabilities based on implementation errors [RFC9098] ⚠️ this is not a magic shield, so don't treat it like one 🙅‍♀️

we also need to flag this one: depending on the router architecture, attempts to filter packets based on the presence of IPv6 EHs or options might itself represent an attack vector to network infrastructure devices [RFC9098] 💀 filtering can be a double-edged sword, so be careful out there 🗡️

8. References

8.1. Normative References

8.2. Informative References ✨

okay so the informative refs are giving bibliography realness 📚💅 here's the whole lineup, no cap:

[Biondi-2007]: Biondi, P. and A. Ebalard, "IPv6 Routing Header Security", CanSecWest Security Conference, April 2007, http://www.secdev.org/conf/IPv6_RH_security-csw07.pdf.

[Cisco-EH]: Cisco Systems, "IPv6 Extension Headers Review and Considerations", Whitepaper, October 2006, https://www.cisco.com/en/US/technologies/tk648/tk872/technologies_white_paper0900aecd8054d37d.pdf.

[FW-Benchmark]: Zack, E., "Firewall Security Assessment and Benchmarking IPv6 Firewall Load Tests", IPv6 Hackers Meeting #1, Berlin, Germany, June 2013, https://www.ipv6hackers.org/files/meetings/ipv6-hackers-1/zack-ipv6hackers1-firewall-security-assessment-and-benchmarking.pdf.

[Huston-2022]: Huston, G. and J. Damas, "IPv6 Fragmentation and EH Behaviours", IEPG Meeting at IETF 113", March 2022, https://iepg.org/2022-03-20-ietf113/huston-v6frag.pdf.

[IANA-IPV6-PARAM]: IANA, "Internet Protocol Version 6 (IPv6) Parameters", https://www.iana.org/assignments/ipv6-parameters.

[IANA-PROTOCOLS]: IANA, "Protocol Numbers", https://www.iana.org/assignments/protocol-numbers.

[IPv6-OPTIONS]: Gont, F., Liu, W., and R. P. Bonica, "Transmission and Processing of IPv6 Options", Work in Progress, Internet-Draft, draft-gont-6man-ipv6-opt-transmit-02, 21 August 2015, https://datatracker.ietf.org/doc/html/draft-gont-6man-ipv6-opt-transmit-02.

[JAMES]: Iurman, J., "Just Another Measurement of Extension header Survivability (JAMES)", Work in Progress, Internet-Draft, draft-vyncke-v6ops-james-02, 11 July 2022, https://datatracker.ietf.org/doc/html/draft-vyncke-v6ops-james-02.

[NIMROD-DOC]: "Nimrod Documentation", http://ana-3.lcs.mit.edu/~jnc/nimrod.

[NIMROD-EID]: Lynn, C., "Endpoint Identifier Destination Option", Work in Progress, Internet-Draft, draft-ietf-nimrod-eid-00, 2 March 1996, https://datatracker.ietf.org/doc/html/draft-ietf-nimrod-eid-00.

[NUMERIC-IDS]: Gont, F. and I. Arce, "On the Generation of Transient Numeric Identifiers", Work in Progress, Internet-Draft, draft-irtf-pearg-numeric-ids-generation-11, 11 July 2022, https://datatracker.ietf.org/doc/html/draft-irtf-pearg-numeric-ids-generation-11.

[RFC2460]: Deering, S. and R. Hinden, "Internet Protocol, Version 6 (IPv6) Specification", RFC 2460, DOI 10.17487/RFC2460, December 1998, https://www.rfc-editor.org/info/rfc2460.

[RFC3871]: Jones, G., Ed., "Operational Security Requirements for Large Internet Service Provider (ISP) IP Network Infrastructure", RFC 3871, DOI 10.17487/RFC3871, September 2004, https://www.rfc-editor.org/info/rfc3871.

[RFC6192]: Dugal, D., Pignataro, C., and R. Dunn, "Protecting the Router Control Plane", RFC 6192, DOI 10.17487/RFC6192, March 2011, https://www.rfc-editor.org/info/rfc6192.

[RFC7126]: Gont, F., Atkinson, R., and C. Pignataro, "Recommendations on Filtering of IPv4 Packets Containing IPv4 Options", BCP 186, RFC 7126, DOI 10.17487/RFC7126, February 2014, https://www.rfc-editor.org/info/rfc7126.

[RFC7739]: Gont, F., "Security Implications of Predictable Fragment Identification Values", RFC 7739, DOI 10.17487/RFC7739, February 2016, https://www.rfc-editor.org/info/rfc7739.

[RFC7872]: Gont, F., Linkova, J., Chown, T., and W. Liu, "Observations on the Dropping of Packets with IPv6 Extension Headers in the Real World", RFC 7872, DOI 10.17487/RFC7872, June 2016, https://www.rfc-editor.org/info/rfc7872.

[RFC9098]: Gont, F., Hilliard, N., Doering, G., Kumari, W., Huston, G., and W. Liu, "Operational Implications of IPv6 Packets with Extension Headers", RFC 9098, DOI 10.17487/RFC9098, September 2021, https://www.rfc-editor.org/info/rfc9098.

Acknowledgements 🫶

The authors wanna give mad props to Ron Bonica for his work on the earlier draft versions of this doc 🙌

The authors would like to thank (in alphabetical order) Mikael Abrahamsson, Brian Carpenter, Tim Chown, Roman Danyliw, Darren Dukes, Lars Eggert, David Farmer, Mike Heard, Bob Hinden, Christian Huitema, Benjamin Kaduk, Erik Kline, Murray Kucherawy, Jen Linkova, Carlos Pignataro, Alvaro Retana, Maria Ines Robles, Zaheduzzaman Sarker, Donald Smith, Pascal Thubert, Ole Troan, Gunter Van de Velde, Éric Vyncke, and Robert Wilton for providing valuable comments on earlier draft versions of this document. the whole squad showed up 🌈✨

This document borrows some text and analysis from [RFC7126], which is authored by Fernando Gont, Randall Atkinson, and Carlos Pignataro. big credit to that one 💜

The authors would like to thank Warren Kumari and Éric Vyncke for their guidance during the publication process for this document. literal mentors 🧚

Fernando would also like to thank Brian Carpenter and Ran Atkinson who, over the years, have answered many questions and provided valuable comments that have benefited his protocol-related work (including the present document). they're the OGs 👑

Authors' Addresses 💌

Fernando Gont SI6 Networks Segurola y Habana 4310 7mo piso Ciudad Autonoma de Buenos Aires Argentina Email: fgont@si6networks.com URI: https://www.si6networks.com

Will (Shucheng) Liu Huawei Technologies Bantian, Longgang District Shenzhen 518129 China Email: liushucheng@huawei.com

📦 where this page comes from