RFC 9673

IPv6 Hop-by-Hop Options Processing Procedures

📅 published October 2024, from ietf

📜 RFC 9673: IPv6 Hop-by-Hop Options Processing Procedures 🎀

okay bestie, this one is a Standards Track doc from the IETF 💅 so it's basically the official rulebook. it was written by R. Hinden (Check Point Software) and G. Fairhurst (University of Aberdeen), and it came out in October 2024 🍓 it's an ISSN: 2070-1721 doc, and it updates RFC 8200 (the IPv6 Protocol Specification) ✨ it doesn't obsolete anything, it just tweaks what 8200 says about Hop-by-Hop options 🦋

the whole vibe is making Hop-by-Hop options actually practical for routers and hosts to use 🔥 right now they're kinda a headache, so this doc sets the minimum rules for how routers handle them 🧚

Status of This Memo

This is an Internet Standards Track document 💜

It's a product of the Internet Engineering Task Force (IETF) and it represents the community's consensus 🫶 it got public review and was approved by the Internet Engineering Steering Group (IESG). more info on Internet Standards is in Section 2 of RFC 7841 ✨

if you want the current status, any errata, or to give feedback, check https://www.rfc-editor.org/info/rfc9673 🌸

Copyright (c) 2024 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 they were on the publication date 📜 please actually read those, they explain your rights and restrictions. any Code Components pulled out of this doc have to include Revised BSD License text (see Section 4.e of the Trust Legal Provisions) and come without warranty, same as the Revised BSD License says 💖

Table of Contents

1.  Introduction
2.  Requirements Language
3.  Terminology
4.  Background
5.  Hop-by-Hop Header Processing Procedures
  5.1.  Processing the Extension Header Carrying Hop-by-Hop Options
    5.1.1.  Configuration Enabling Hop-by-Hop Header Processing
  5.2.  Hop-by-Hop Options Processing
    5.2.1.  Router Alert Option
    5.2.2.  Configuration of Hop-by-Hop Options Processing
6.  Defining New Hop-by-Hop Options
  6.1.  Example of Robust Usage
7.  IANA Considerations
8.  Security Considerations
9.  Normative References
10. Informative References
Acknowledgments
Authors' Addresses

1. Introduction ✨

okay so this section sets the scene 🎀 the doc spells out procedures for how IPv6 routers and hosts process Hop-by-Hop options, and it's modifying the rules from the IPv6 Protocol Specification [RFC8200] so the Hop-by-Hop Options header is actually workable 💅 the goal is to make these options useful to deploy and use at routers and hosts, no cap 🦋

quick recap: an IPv6 packet carries Hop-by-Hop options by including a Hop-by-Hop Options header 🌸 the current list of defined options lives at [IANA-HBH] 🍓

the focus here is setting the minimum requirements for router processing of Hop-by-Hop options 🧚 it also talks about how hosts use them 💜 and it does not propose any specific limit on how many Hop-by-Hop options, or how big they are, that ought to get processed 👑

and yep, this doc updates [RFC8200] 🔥

2. Requirements Language 💖

the key words in this doc are to be read as described in BCP 14 [RFC2119] [RFC8174] 🫶 but only when they show up in all capitals, like shown here 💅

the words are: "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" ✨

3. Terminology 🦋

this doc uses a few loosely defined terms, so here's the tea 🫖

Forwarding Plane: IPv6 routers move user or application data through the Forwarding Plane 🌸 routers look at fields in IPv6 packet headers, but they do not look inside packet payloads 🙈

Control Plane: this is where routers swap control information 💜 it handles the management and routing info they trade with other routers 🧚

Fast Path: a path through a router that's tuned for forwarding packets as fast as possible 🔥 it might run on ASICs, a Network Processor (NP), or other special purpose hardware 🦋 this is the typical route the Forwarding Plane takes through a router 💅

Slow Path: a path through a router that can do general purpose processing and isn't optimized for any one thing 🌈 it's used for packets that need special handling, packets that don't match the assumptions Fast Path heuristics make, or for processing router control protocols used by the Control Plane 😭

Full Forwarding Rate: the rate a router can forward packets without hurting the aggregate forwarding rate ✨ for example, a router could process packets with Hop-by-Hop options at a rate that keeps its outgoing interfaces at full speed, which people sometimes call "wire speed" 🍓

Source: the node that originates the packet 🫶

NOTE: [RFC6192] is an example of how designs can separate Control Plane and Forwarding Plane functions 💜 the hardware vs. software split described in [RFC6398] doesn't apply to every router architecture 🙈 still, a router that does all or most of its processing in software might end up paying more processing cost when it gives special treatment to Hop-by-Hop options 💀

Part 1 of 5. more coming up next bestie 💖 stay tuned 🦋

4. Background ✨

okay bestie, let's talk about the history 🕰️ In the early versions of the IPv6 protocol specification ([RFC1883] and [RFC2460]), Hop-by-Hop options were required to be processed by all nodes, routers and hosts alike. That turned out to be a total mess for modern high-speed routers. [RFC7045] Section 2.2 says it best: "it is to be expected that high-performance routers will either ignore it or assign packets containing it to a slow processing path" 💅 The reasons are so real:

  • The inability to process Hop-by-Hop options at the Full Forwarding Rate can result in issues. In some cases, Hop-by-Hop options would be sent to the control/management components that run on the Slow Path. This could degrade a router's performance and also its ability to process critical control traffic, both of which could be exploited as a Denial-of-Service (DoS) attack against the router. 💀
  • If a subset of packets within a flow includes Hop-by-Hop options, it could lead to an increased number of reordered packets and greater reordering distances for packets delivered to the destination. Such reordering could occur if the Hop-by-Hop Options header is included only in some packets or if a specific Hop-by-Hop option results in different processing for some of the packets within the flow. Significant reordering of packets within a flow can negatively impact the performance of upper-layer protocols and should therefore be avoided. 🌀
  • Packets could include multiple Hop-by-Hop options. Too many options could make the previous issues worse by increasing the resources required to process them. The total size of the options determines the number of header bytes that might need to be processed. Measurements [Cus23a] show that the probability of successful transmission across the public Internet is currently higher for packets that include Options that result in a short total Extension Header (EH) Chain size (i.e., less than 40 bytes). 📏

[RFC6564] specifies a uniform format for new IPv6 Extension Headers, and this update was incorporated into Section 4.8 of [RFC8200] (note that [RFC8200] obsoleted [RFC2460]). 🎀

When the IPv6 protocol specification was updated and published in July 2017 as [RFC8200], the procedures relating to Hop-by-Hop options were specified (paragraphs 5 and 6 of Section 4 of [RFC8200]) as follows:

The Hop-by-Hop Options header is not inserted or deleted, but may be examined or processed by any node along a packet's delivery path, until the packet reaches the node (or each of the set of nodes, in the case of multicast) identified in the Destination Address field of the IPv6 header. The Hop-by-Hop Options header, when present, must immediately follow the IPv6 header. Its presence is indicated by the value zero in the Next Header field of the IPv6 header. NOTE: While [RFC2460] required that all nodes must examine and process the Hop-by-Hop Options header, it is now expected that nodes along a packet's delivery path only examine and process the Hop-by-Hop Options header if explicitly configured to do so.

So the changes meant that an implementation complied with the IPv6 protocol specification even if it did not process Hop-by-Hop options, and that routers were expected to add configuration information to control whether they process the Hop-by-Hop Options header. In practice, routers may include configuration options to control which Hop-by-Hop options they will process. 🔧

The text regarding the processing of Hop-by-Hop options in [RFC8200] was not intended to change the processing of these options. It documented how they were being used in the Internet at the time RFC 8200 was published (see Appendix B of [RFC8200]). This was a constraint on publishing the IPv6 protocol specification as an IETF Standard. 🧩

The main issues remain:

  • Routers can be configured to drop transit packets containing Hop-by-Hop Options that require processing by a processor that implements the Control Plane. This could be done to protect against a DoS attack on the router [RFC9098] [RFC9288]. 🚧
  • IPv6 packets that include a Hop-by-Hop Options header are dropped by some Internet paths. A survey in 2015 reported a high loss rate in transit Autonomous Systems (ASes) for packets that include Hop-by-Hop options [RFC7872]. The operational implications of IPv6 packets that include Extension Headers are discussed in [RFC9098]. Measurements taken in 2023 confirm this to still be the case for many types of network paths [Cus23b]. 😭
  • Allowing multiple Hop-by-Hop options in a single packet in some cases consumes more router resources to process these packets. It also adds complexity to the number of permutations that might need to be processed/configured. 🌪️
  • Including larger or multiple Hop-by-Hop options in a Hop-by-Hop Options header increases the number of bytes that need to be processed in forwarding, which in some designs can impact the cost of processing a packet, and in turn could increase the probability of drop [RFC7872]. A larger Extension Header could also reduce the probability of a router locating all the header bytes required to successfully process an access control list operating on fields after the Hop-by-Hop Options header. 🫠
  • Any option that can be used to force packets into the processor that implements the router's Control Plane can be exploited as a DoS attack on a transit router by saturating the resources needed for router management protocols (routing protocols, network management protocols, etc.), which could cause adverse router operation. This is an issue for the Router Alert Option [RFC2711], which intentionally forwards packets to the Control Plane as discussed in [RFC6398]. This impact could be mitigated by limiting the use of Control Plane resources by a specific packet and/or by using per-function rate-limiters for packets processed by the Control Plane. 🚨

Section 3 of [RFC6398] includes a summary of processing the IP Router Alert Option:

In a nutshell, the IP Router Alert Option does not provide a convenient universal mechanism to accurately and reliably distinguish between IP Router Alert packets of interest and unwanted IP Router Alert packets. This, in turn, creates a security concern when the IP Router Alert Option is used, because, short of appropriate router-implementation-specific mechanisms, the router slow path is at risk of being flooded by unwanted traffic.

This is an example of the need to limit the resources that can be consumed when a particular function is executed and to avoid consuming Control Plane resources where support for a function has not been configured. 🛑

There has been research that has discussed the general problem with dropping packets containing IPv6 Extension Headers, including the Hop-by-Hop Options header. For example, [Hendriks] states that "Dropping all packets that contain Extension Headers is a bad practice" and that "The share of traffic containing more than one EH however, is very small. For the design of hardware able to handle the dynamic nature of EHs, we therefore recommend to support at least one EH". Operational aspects of the topics discussed in this section are further discussed in [HBH]. 📚

"Transmission and Processing of IPv6 Extension Headers" [RFC7045] clarifies how intermediate nodes should process Extension Headers. This document is generally consistent with [RFC7045] and addresses an issue that was raised for discussion when [RFC2460] was updated and replaced by [RFC8200]. This document updates [RFC8200] as described in the next section and consequently clarifies the description in Section 2.2 of [RFC7045], using the language of BCP 14 [RFC2119] [RFC8174]. 🔑

This document defines a set of procedures for the Hop-by-Hop Options header that are intended to make the processing of Hop-by-Hop options practical in modern routers. The common cases are that some Hop-by-Hop options will be processed across the Internet, while others will only be processed within a limited domain [RFC8799] (e.g., where a specific service is made available in that network segment that relies on one or more Hop-by-Hop options). 🌐

5. Hop-by-Hop Header Processing Procedures 💖

This section describes several changes to [RFC8200]. Section 5.1 describes the processing of the Hop-by-Hop options Extension Header, and Section 5.2 describes the processing of individual Hop-by-Hop options. These sections update the text in paragraph 6 of Section 4 of [RFC8200] and, as noted in Section 5.2, modify Section 4.2 of [RFC8200]. 🎯

5.1. Processing the Extension Header Carrying Hop-by-Hop Options

When a packet includes one or more Extension Headers, the Next Header field of the IPv6 Header identifies the type of Extension Header. It does not identify the transport protocol. 🧠

The Extension Header used to carry Hop-by-Hop options is defined in Section 4.3 of [RFC8200] and is identified by a Next Header value of 0 in the IPv6 header. Section 4.1 of [RFC8200] requires this Hop-by-Hop Options header to appear immediately after the IPv6 header. [RFC8200] also requires that a Hop-by-Hop Options header only appear at most once in a packet. 📌

The Hop-by-Hop Options header as defined in [RFC8200] can contain one or more Hop-by-Hop options. 🫧

Routers that process the Hop-by-Hop Options header SHOULD do so using the method defined in this document. Exceptions to this SHOULD include routers that are configured to drop packets with a Hop-by-Hop Options header to protect downstream devices that do not comply with this specification (see [RFC9288]). 🛡️

Even if a router does not process the Hop-by-Hop Options header (for example, when based on configuration), it MUST forward the packet normally based on the remaining Extension Header(s) after the Hop-by-Hop Options header. A router MUST NOT drop a packet solely because it contains an Extension Header carrying Hop-by-Hop options. A configuration could control whether normal processing skips any or all of the Hop-by-Hop options carried in the Hop-by-Hop Options header. 🚀

It is expected that the Hop-by-Hop Options header will be processed by the destination(s). Hosts SHOULD process the Hop-by-Hop Options header in received packets. A constrained host is an example of a node that does not process the Hop-by-Hop Options header. If a destination does not process the Hop-by-Hop Options header, it MUST process the remainder of the packet normally. 🎀

5.1.1. Configuration Enabling Hop-by-Hop Header Processing

Section 4 of [RFC8200] allows a router to control its processing of IPv6 Hop-by-Hop options by local configuration. The text is:

NOTE: While [RFC2460] required that all nodes must examine and process the Hop-by-Hop Options header, it is now expected that nodes along the path only examine and process the Hop-by-Hop Options header if explicitly configured to do so.

This document clarifies that a configuration could control whether processing skips any specific Hop-by-Hop options carried in the Hop-by-Hop Options header. A router that does not process the contents of the Hop-by-Hop Options header does not process any of the Option Types contained in the Hop-by-Hop Options header. 🔧💜

5.2. Hop-by-Hop Options Processing 💖

Okay bestie, so a Source making packets with a Hop-by-Hop Options header SHOULD use a method that's robust to network nodes that only process some of the Hop-by-Hop options in the packet, or that forward packets without processing the option(s) at all (see Section 6.1). A Source MAY, based on local configuration, allow only one Hop-by-Hop option in a packet, or it could allow more than one but cap their size so the packet is more likely to make it across the network path 🧚. Since some routers might only process one or a few options in the header, Sources are motivated to order their Hop-by-Hop options in decreasing order of importance for processing by nodes on the path 👑.

A router config needs to avoid vulnerabilities that show up when it can't process the first Hop-by-Hop option at the Full Forwarding Rate 🚨. So a router SHOULD NOT be configured to process the first Hop-by-Hop option if that hurts the aggregate forwarding rate. A router SHOULD process additional Hop-by-Hop options, if it's configured to, as long as those also don't hurt the aggregate forwarding rate 💅.

If a router is unable to process a specific Hop-by-Hop option (or isn't configured to), it SHOULD behave the same way specified for an unrecognized Option Type when the action bits are set to "00", and it SHOULD skip the remaining options using the Hdr Ext Len field in the Hop-by-Hop Options header. This field specifies the length of the Options Header in 8-octet units. After skipping an option, the router continues processing the remaining options in the header. Skipped options do not need to be verified ✨.

The Router Alert Option [RFC2711] is an exception to this, because it's designed to tell a router that the packet needs additional processing, which is usually done in the Control Plane; see Section 5.2.1 🦋.

Section 4.2 of [RFC8200] defines the Option Type identifiers as internally encoded so that their highest-order 2 bits specify the action that must be taken if the processing IPv6 node does not recognize the Option Type. The text is:

00 - skip over this option and continue processing the header.

01 - discard the packet.

10 - discard the packet and, regardless of whether or not the
     packet's Destination Address was a multicast address,
     send an ICMP Parameter Problem, Code 2, message to the
     packet's Source Address, pointing to the unrecognized
     Option Type.

11 - discard the packet and, only if the packet's Destination
     Address was not a multicast address, send an ICMP Parameter
     Problem, Code 2, message to the packet's Source Address,
     pointing to the unrecognized Option Type.

This document modifies this behavior for the "01", "10", and "11" action bits, so that if a router is unable to process a specific Hop-by-Hop option (or is not configured to do so), it SHOULD behave the same way specified for an unrecognized Option Type when the action bits are set to "00". It also modifies the behavior for values "10" and "11" in the case where the packet is discarded, and the node MAY send an ICMP Parameter Problem, Code 2 [RFC4443], message to the packet's Source Address, pointing to the unrecognized Option Type 🌸.

The modified text for values "01", "10", and "11" is:

01 - MAY discard the packet, if so configured. Nodes should not
     rely on routers dropping these unrecognized Option Types.

10 - MAY discard the packet, if so configured, regardless of
     whether or not the packet's Destination Address was a
     multicast address. If the packet was discarded, an ICMP
     Parameter Problem, Code 2, message MAY be sent to the
     packet's Source Address, pointing to the unrecognized
     Option Type.

11 - MAY discard the packet, if so configured. If the packet
     was discarded and the packet's Destination Address was
     not a multicast address, an ICMP Parameter Problem,
     Code 2, message MAY be sent to the packet's Source
     Address, pointing to the unrecognized Option Type.

When an ICMP Parameter Problem, Code 2, message is delivered to the Source, it means at least one node on the path failed to recognize the option [RFC4443]. Generating any ICMP message adds extra router processing 🙈. Reception of this message is not guaranteed: routers might be unable to be configured so that they don't generate these messages, and they aren't always forwarded to the Source. The motivation here is to loosen the requirement to send an ICMPv6 Parameter Problem message when a router forwards a packet without processing the list of all options 🫶.

5.2.1. Router Alert Option 🔥

The purpose of the Router Alert Option [RFC2711] is to tell a router that the packet needs additional processing in the Control Plane.

The Router Alert Option includes a two-octet Value field that describes the protocol carried in the packet. The current specified values can be found in the "IPv6 Router Alert Option Values" IANA registry [IANA-RA].

DISCUSSION 🧠 The function of a Router Alert Option can result in the processing that this specification is proposing to eliminate, that is, instructing a router to process the packet in the Control Plane. This processing causes concerns, which are discussed in Section 4. One approach would be to deprecate this, because current usage beyond the local network appears to be limited, and packets containing Hop-by-Hop options are frequently dropped. Deprecation would allow current implementations to continue, and its use could be phased out over time. The Router Alert Option could potentially be used with new functions that have to be processed in the Control Plane. Keeping this as the single exception for processing in the Control Plane, with the restrictions that follow, is a reasonable compromise to allow future flexibility. These restrictions are compatible with Section 5 of [RFC6398].

As noted in [RFC6398], "Implementations of the IP Router Alert Option SHOULD offer the configuration option to simply ignore the presence of 'IP Router Alert' in IPv4 and IPv6 packets."

A node that is configured to process a Router Alert Option MUST protect itself from an infrastructure attack that could result from processing in the Control Plane. This might include some combination of an access control list to only permit access from trusted nodes, rate limiting of processing, or other methods [RFC6398] 🛡️.

As specified in [RFC2711], the top two bits of the Option Type for the Router Alert Option are always set to "00", indicating that the node should skip over this option as if it does not recognize the Option Type and continue processing the header. An implementation that does recognize the Router Alert Option SHOULD verify that the Router Alert Option contains a protocol, as indicated by the Value field in the Router Alert Option, that is configured as a protocol of interest to that router. A verified packet SHOULD be sent to the Control Plane for further processing [RFC6398]. Otherwise, the router implementation SHOULD forward this packet subject to all normal policies and forwarding rules 🌈.

5.2.2. Configuration of Hop-by-Hop Options Processing 🎀

A router can be configured to process a specific Option. The set of enabled options SHOULD be configurable by the operator of the router.

A possible approach to implementing this is to maintain a lookup table based on an Option Type of the IPv6 options that can be processed at the Full Forwarding Rate. This would allow a router to quickly determine if an option is supported and can be processed. If the option is not supported, then the router processes the option as described in Section 5.1 of this document 🔍.

The actions of the lookup table should be configurable by the operator of the router.

6. Defining New Hop-by-Hop Options 🌟

This section updates Section 4.8 of [RFC8200].

Any future new IPv6 Hop-by-Hop options should be designed to be processed at the Full Forwarding Rate, and should have the following characteristics:

  • New Hop-by-Hop options should be designed to ensure the router can process the options at the Full Forwarding Rate. That is, they should be simple to process 🧩.
  • New Hop-by-Hop options should be defined with the Action type (highest-order 2 bits of the Option Type) set to "00", which enables skipping over this option and continuing with the processing of the header if a router does not recognize the option 🦋.
  • The size of Hop-by-Hop options should not extend beyond what can be expected to be executed at the Full Forwarding Rate. A larger Hop-by-Hop Options header can increase the likelihood that a packet will be dropped [Cus23b] 📦.
  • New Hop-by-Hop options should be designed with the expectation that a router might be configured to only process a subset of Hop-by-Hop options (e.g., the first option) in the Hop-by-Hop Options header 🍓.
  • The design of protocols that use new Hop-by-Hop options should consider that a router may drop packets containing the new Hop-by-Hop option 💀.

If a new Hop-by-Hop option does not meet these criteria, its specification must include a detailed explanation why that is the case, and show that there is a reasonable expectation that the option can still proceed at the Full Forwarding Rate. This is consistent with [RFC6564]. This is consistent with [RFC6564].

The general issue of robust operation of packets with new Hop-by-Hop options is described in Section 6.1 🧚‍♀️.

6.1. Example of Robust Usage 🦋

okay so bestie, recent measurement surveys (e.g., [Cus23a]) show that packets with Extension Headers can get dropped by some Internet paths 😭 in a limited domain, routers can be configured or updated to support any Hop-by-Hop options they need, so that part's fine 💅

the main goal of this doc is to make Hop-by-Hop options practical beyond that limited domain ✨ the idea is apps can level up their service (better quality, new features) when the path actually forwards packets with the required options, and otherwise they just chill and don't use them 🌸 this is all about incremental deployability, which means early adopters get some perks on the paths that support it, even if other paths don't 🎀 a Source ought to order the Hop-by-Hop options in its Hop-by-Hop Options header in decreasing order of importance for processing by nodes on the path 🧚

methods can also be built that don't need every router to implement a specific option (e.g., [RFC9268]) and that stay robust when the current path drops packets carrying a Hop-by-Hop option (e.g., [RFC9098]) 💜

here's an example of how that could look 👑 an app first sends a test packet that includes the required option (or combo of options), and then sends other packets without it. the app does NOT send more packets with that option (or set) until the test packet(s) get acknowledged 🙈 and the need for loss recovery when a path drops these test packets can be avoided by picking packets that don't carry application data that has to be reliably delivered 🫶

since the set of nodes on a path can change over time, this discovery process ought to be repeated from time to time ⭐ sending packets both with and without a specific header to figure out whether a path supports that header is sometimes called "racing" 🏁 transport protocol racing is explained in [TAPS-ARCH], and A/B protocol feature testing is described in [Tram17] ✨

7. IANA Considerations 🧚

this document updates the processing of Hop-by-Hop options 💖 IANA has added this document as an additional reference for the "Destination Options and Hop-by-Hop Options" registry in the "Internet Protocol Version 6 (IPv6) Parameters" registry group [IANA-HBH] 📚

8. Security Considerations 💀

okay this section is SERIOUS bestie, but also iconic 😭🔥

security issues caused by including IPv6 Hop-by-Hop options are well known and have been written up in several places, including [RFC6398], [RFC6192], [RFC7045], and [RFC9098] 📖 the main issue, as noted in Section 4, is that any mechanism that can be used to force packets into the router's Control Plane or Slow Path can be exploited as a DoS attack on a router 🚨 it does this by saturating the resources needed for router management (routing protocols, network management protocols, etc.), and that can make the router fail or perform suboptimally 💔

while Hop-by-Hop options are not required to be processed in the Control Plane, the Router Alert Option is the one exception that is designed to be processed in the Control Plane 👑

some IPv6 nodes implement features that access more of the protocol information than a typical IPv6 router (e.g., [RFC9098]) 👀 examples are nodes that provide DoS mitigation, firewall/access control, traffic engineering, or traffic normalization 🛡️ these nodes could be configured to drop packets when they can't access and process all Extension Headers, or when they can't locate and process the higher-layer packet information 🙅‍♀️ this document gives guidance on the requirements concerning Hop-by-Hop options 🎀

finally, this document notes that Internet protocol processing needs to be robust for malformed or malicious protocol fields 🥺 for example, a packet with an excessive number of options could eat up significant resources, and including a large Extension Header could potentially stop an on-path router from using hardware optimizations to process later headers (e.g., to perform equal cost multipath forwarding or port filtering) 😱 this requirement isn't specific to Hop-by-Hop options 💅 it's important that implementations fail gracefully when a malformed or malicious Hop-by-Hop option is encountered ✨

this document changes how the Hop-by-Hop Options header is processed, which significantly reduces the attack surface 🔥 the changes include the following:
  • a router configuration needs to avoid vulnerabilities that arise when it cannot process a Hop-by-Hop option at the Full Forwarding Rate 🚦 so it SHOULD NOT be configured to process the Hop-by-Hop option if that adversely impacts the aggregate forwarding rate 🙅‍♀️ instead, it SHOULD behave in the same way specified for an unrecognized Option Type when the action bits are set to "00", as specified in Section 5.2 🌸
  • this document adds criteria for the Router Alert Option (Section 5.2.1) to allow control over how it is processed, and describes how a node configured to support these options MUST protect itself from attacks by using the Router Alert Option 🛡️
  • this document sets the expectation that if a packet includes a Hop-by-Hop Options header, the packet will be forwarded across the network path 🦋
  • a Source MAY include a single Hop-by-Hop option (based on local configuration) or MAY be configured to include more Hop-by-Hop options 🎀 the configuration of intermediate nodes determines whether a node processes any of these options, and if so, which ones and how many 🧠
  • this document adds guidance for the design of any future new Hop-by-Hop option that reduces the computational requirements and encourages a limit to their size 💜

the intent of this document is to highlight that these changes significantly reduce the security issues relating to processing the IPv6 Hop-by-Hop Options header, and enable Hop-by-Hop options to be safely used in the Internet 🌈✨

9. Normative References 📚

10. Informative References ✨

Okay bestie, here are the receipts 📚 These are the extra reads that back everything up. Every title, author, date, and link is exactly as the original has it.

Acknowledgments 🫶

Huge thank-yous to everyone who gave helpful comments: Brian Carpenter, Ron Bonica, Ole Troan, Mike Heard, Tom Herbert, Cheng Li, Éric Vyncke, Greg Mirsky, Xiao Min, Fernando Gont, Darren Dukes, Peng Shuping, Dave Thaler, Ana Custura, Tim Winters, Jingrong Xie, Lorenzo Colitti, Toerless Eckert, Suresh Krishnan, Mikael Abrahamsson, Adrian Farrel, Jie Dong, Jen Linkova, Erik Kline, and the rest of the 6MAN Working Group. Y'all are iconic 👑✨

Authors' Addresses 💅

Here's who wrote it and how to reach them 🦋

Robert M. Hinden
Check Point Software
100 Oracle Parkway, Suite 800
Redwood City, CA 94065
United States of America
Email: bob.hinden@gmail.com
Godred Fairhurst
University of Aberdeen
School of Engineering
Fraser Noble Building
Aberdeen
AB24 3UE
United Kingdom
Email: gorry@erg.abdn.ac.uk
📦 where this page comes from