IPv6 Hop-by-Hop Options Processing Procedures

Status of This Memo

This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79.¶

Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet-Drafts is at https://datatracker.ietf.org/drafts/current/.¶

Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress."¶

This Internet-Draft will expire on 7 December 2024.¶

Copyright Notice

Copyright (c) 2024 IETF Trust and the persons identified as the document authors. All rights reserved.¶

This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Revised BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Revised BSD License.¶

Table of Contents

1. Introduction

This document specifies procedures for processing IPv6 Hop-by-Hop options in IPv6 routers and hosts. It modifies the procedures specified in the IPv6 Protocol Specification [RFC8200] to make processing of IPv6 Hop-by-Hop Options header practical with the goal of making IPv6 Hop-by-Hop options useful to deploy and use at IPv6 routers and hosts.¶

An IPv6 packet includes Hop-by-Hop options by including a Hop-by-Hop Options header. The current list of defined Hop-by-Hop options can be found at [IANA-HBH]. The focus for this document is to set the minimum requirements for router processing of Hop-by-Hop options. It also discusses how Hop-by-Hop options are used by hosts. This document does not propose a specific bound to the number or size of Hop-by-Hop options that ought to be processed.¶

When published, this document updates [RFC8200].¶

3. Terminology

This document uses the following loosely defined terms:¶

• forwarding plane: IPv6 routers exchange user or applications data through the forwarding plane. Routers process fields contained in IPv6 packet headers. However, they do not process information contained in packet payloads.¶
• control plane: IPv6 routers exchange control information through the control plane. The control plane processes the management and routing information exchanged with other routers.¶
• Fast Path: A path through a router that is optimized for forwarding packets. The Fast Path might be supported by Application Specific Integrated Circuits (ASICs), a Network Processor (NP), or other special purpose hardware. This is the typical processing path within a router taken by the forwarding plane.¶
• Slow Path: A path through a router that is capable of general purpose processing and is not optimized for any particular function. This processing path is used for packets that require special processing or differ from assumptions made in Fast Path heuristics or to process router control protocols used by the control plane.¶
• Full Forwarding Rate: This is the rate that a router can forward packets without adversely impacting the aggregate forwarding rate. For example, a router could process packets with Hop-by-Hop options at a rate that allows it to maintain the full speed on its outgoing interfaces, which is sometimes called "wire speed".¶
• source: The node originating the packet.¶

NOTE: [RFC6192] is an example of how designs can separate control plane and forwarding plane functions. The separation between hardware and software processing described in [RFC6398] does not apply to all router architectures. However, a router that performs all or most processing in software might still incur more processing cost when providing special processing for Hop-by-Hop options.¶

4. Background

In the first versions of the IPv6 specification [RFC1883] and [RFC2460], Hop-by-Hop options were required to be processed by all nodes: routers and hosts. This proved to not be practical in current high speed routers, as observed in Section 2.2 of RFC7045: "it is to be expected that high-performance routers will either ignore it or assign packets containing it to a slow processing path". The reason behind this includes:¶

• 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 attack against the router.¶
• If a subset of packets within a flow includes Hop-by-Hop options, this 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 when it results in a short total Extension Header (EH) Chain size (i.e., less than 40 bytes).¶

[RFC6564] specified a uniform format for new IPv6 Extension Headers. It updated [RFC2460], and this update was incorporated into Section 4.8 of [RFC8200].¶

When the IPv6 Specification was updated and published in July 2017 as [RFC8200], the procedures relating to Hop-by-Hop options were specified ([RFC8200], Section 4) 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.¶

The changes meant that an implementation complied with the IPv6 specification even if it did not process Hop-by-Hop options, and that it was expected that routers would 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 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 specification as an IETF Standard.¶

The main issues remain:¶

• Routers can be configured to drop transit packets containing Hop-by-Hop Options that would have required processing by a processor that implements the control plane. This could be done to protect against a Denial-of-Service 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 ASs for packets with Hop-by-Hop options [RFC7872]. The operational implications of IPv6 Packets that include Extension Headers are discussed in [RFC9098]. Measurements 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 can in some designs 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 that a router can locate 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 Denial-of-Service attack on a transit router by saturating the resources needed for router management protocols (routing protocols, network management protocols, etc.), that could cause adverse router operation. This is an issue for the Router Alert Hop-by-Hop Option [RFC2711], which intentionally forwards packets to the control plane, and is discussed in [RFC6398]. This impact could be mitigated by limiting the use of control plane resources by a specific packet, and/or by the use of per-function rate-limiters for packets processed by the control plane.¶

Section 3 of RFC 6398 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 with 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 Extension Headers we therefore recommend to support at least one EH". Operational aspects of the topics discussed in this section are further discussed in [I-D.ietf-v6ops-hbh].¶

"Transmission and Processing of IPv6 Extension Headers" [RFC7045] clarified how intermediate nodes should process Extension Headers. The present 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 processing of the Hop-by-Hop options Extension Header, and Section 5.2 describes processing of individual Hop-by-Hop Options. These sections updates the text in paragraphs 5 and 6 of Section 4 of [RFC8200] and as noted in Section 5.2 modifies Section 4.2 of [RFC8200].¶

   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
        ICMPv6 Parameter Problem, Code 2 [RFC4443], 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 ICMPv6 Parameter
        Problem, Code 2, message to the packet's Source Address,
        pointing to the unrecognized Option Type.

    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, and, regardless of
         whether or not the packet's Destination Address was a
         multicast address. If the packet was discarded, it MAY send
         an ICMP Parameter Problem, Code 2, message to the packet's
         Source Address, pointing to the unrecognized Option Type.

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

6. Defining New Hop-by-Hop Options

This section updates Section 4.8 of [RFC8200].¶

Any new IPv6 Hop-by-Hop option designed in the future should be designed to be processed at full forwarding rate. New Hop-by-Hop options 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 options should be defined with the Action type (highest-order 2 bits of the Option Type) set to 00 to skip over this option and continue processing the header if a router does not recognize the option.¶
• The size of a Hop-by-Hop option should not extend beyond what can be expected to be executed at full forwarding rate. A larger Hop-by-Hop Options header can increase the likelihood that that a packet will be dropped [Cus23b].¶
• New Hop-by-Hop options should be designed expecting 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.¶

Any new Hop-by-Hop option that is standardized that does not meet these criteria must include in the specification a detailed explanation why this cannot be accomplished and to show that there is a reasonable expectation that the option can be proceed at full forwarding rate. 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 below.¶

7. IANA Considerations

This document requires no assignment actions by IANA.¶

The document updates the processing of Hop-by-Hop options. IANA is requested to add the published RFC as an additional reference for "Destination Options and Hop-by-Hop Options" in the Internet Protocol Version 6 (IPv6) Parameters Registry.¶

8. Security Considerations

Security issues with including IPv6 Hop-by-Hop options are well known and have been documented 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 Denial-of-Service attack on a router by saturating the resources needed for router management (routing protocols, network management protocols, etc.) and cause the router to fail or perform sub-optimally.¶

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 Denial-of-Service mitigation, firewall/access control, traffic engineering, or traffic normalization. These nodes could be configured to drop packets when they are unable to access and process all Extension Headers or are unable to locate and process the higher-layer packet information. This document provides guidance on the requirements concerning Hop-by-Hop options.¶

Finally, the document notes that Internet protocol processing needs to be robust to malformed/malicious protocol fields. For example, a packet with an excessive number of options could consume significant resources; inclusion of a large extension header could potentially cause an on-path router to be unable to utilise hardware optimisations to process later headers (e.g., to perform equal cost multipath forwarding or port filtering). This requirement is not specific to Hop-by-Hop options. It is important that implementations fail gracefully when a malformed or malicious Hop-by-Hop option is encountered.¶

This document changes the way the Hop-by-Hop Options header is processed in several ways that significantly reduce the attack surface. These changes include:¶

• A router configuration needs to avoid vulnerabilities that arise when it cannot process a Hop-by-Hop option at full forwarding rate and SHOULD NOT therefore be configured to process the a Hop-by-Hop option if this adversely impacts the aggregate forwarding rate, instead it SHOULD behave in the way specified for an unrecognized Option Type when the action bits were set to "00", as specified in Section 5.2.¶
• It adds criteria for the Router Alert Option in Section 5.2.1 to allow control over how the Router Alert Option is processed and that a node configured to support these options must protect itself from attacks using the Router Alert Option.¶
• The document sets an expectation that if a packet includes a Hop-by-Hop Options header that the packet will be forwarded across the network path.¶
• A source MAY include, based on local configuration, a single Hop-by-Hop option 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 and how many.¶
• The present document adds guidance for the design of any future new Hop-by-Hop option that reduce their computational requirements and encourage a limit to their size.¶

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

9. Acknowledgments

Helpful comments were received from Brian Carpenter, Ron Bonica, Ole Troan, Mike Heard, Tom Herbert, Cheng Li, Eric Vyncke, Greg Mirksy, 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 other members of the 6MAN working group.¶

10. Change log [RFC Editor: Please remove]

draft-ietf-6man-hbh-processing-20, 2024-June 5¶

• Changes based on John Scudder's AD review.¶
• Changes based on Deb Cooley's AD review.¶
• Changes based on Jim Guichard's AD review.¶
• Changes based on Roman Danyliw's AD review.¶
• Changes based on Jim Guichard's AD review.¶
• Editorial Changes.¶

draft-ietf-6man-hbh-processing-19, 2024-June 4¶

• Changes based on Warren Kumari's AD review.¶

draft-ietf-6man-hbh-processing-18, 2024-May 29:¶

• Changes based on Éric Vyncke's AD review.¶
• Changes based on Roman Danyliw's AD review.¶

draft-ietf-6man-hbh-processing-17, 2024-May 16:¶

• Editorial changes and request to IANA, based on Bernie Volz's INTDIR review.¶

draft-ietf-6man-hbh-processing-16, 2024-April 30:¶

• Clarifications and editorial changes based on Peter Yee's SECDIR review.¶
• Editorial changes based on Behcet Sarikaya's GENART review.¶
• Clarifications based on Brian Trammell's TSVART review.¶

draft-ietf-6man-hbh-processing-15, 2024-April 13:¶

• Clarifications based on AD review by Erik Kline.¶
• Editorial Changes.¶

draft-ietf-6man-hbh-processing-14, 2024-February-25:¶

• Clarifications based on comment from Jen Linkova¶
• Editorial Changes.¶

draft-ietf-6man-hbh-processing-13, 2024-February-18:¶

• Correction based on comment by Jie Dong¶
• Clarifications based on comments from Tom Herbert¶
• Clarifications based on comments from Ole Troan¶
• Editorial Changes.¶

draft-ietf-6man-hbh-processing-12, 2023-November-21:¶

• Clarifications and text improvements based on review by Fernando Gont.¶
• Editorial Changes.¶

draft-ietf-6man-hbh-processing-11, 2023-November-5:¶

• Clarifications and text improvements based on review by Adrian Farrel.¶
• Editorial Changes.¶

draft-ietf-6man-hbh-processing-10, 2023-September-26:¶

• Clarifying changes based on comments received during the IPv6 w.g. session at IETF117 from Lorenzo Colitti, Toerless Eckert, and others.¶
• Clarifying changes based on comments received after the first w.g. last call.¶
• Editorial Changes.¶

draft-ietf-6man-hbh-processing-09, 2023-July-4:¶

• Revised text in Section 3 relating to fast/slow path and processing¶
• Restructured Section 5 to separate Hop-by-Hop Options header and Hop-by-Hop options processing and configuration.¶
• Revised MUST/SHOULD language in Section 5.2.¶
• Revised text to use consistant names for Hop-by-Hop Options header and Hop-by-Hop options.¶
• Revised Section 5.2 regarding the modified behaviour of the action bits "01", "10", and "11" to be a MAY to be consistant with text earlier in that section.¶
• Added to Section 6 that new Hop-by-Hop options SHOULD be designed expecting that routers may drop packets with the new option.¶
• Added new Section 6.1 on "Example of Robust Usage".¶
• Other editorial changes to improve readability and clarity.¶

draft-ietf-6man-hbh-processing-08, 2023-April-30:¶

• Changed document that is no longer updates [RFC7045], it now clarifies it using the language of BCP 14.¶
• Added additional clarification to Section 4.¶
• Editorial changes¶

draft-ietf-6man-hbh-processing-07, 2023-April-6:¶

• Changed text to clarify how hosts and routers process the Hop-by-Hop Options header based on comments at 6MAN session at IETF 116.¶
• Editorial changes¶

draft-ietf-6man-hbh-processing-06, 2023-March-11:¶

• Added reference to RFC6564.¶
• Editorial changes¶

draft-ietf-6man-hbh-processing-05, 2023-February-23:¶

• Clarified text in Section 6 about processing complexity and time to process.¶
• Added a definition to Section 3 for "Full Forwarding Rate".¶
• Added text to Section 5.1 about nodes that do not process the Hop-by-Hop Options header.¶
• Added text to Section 4 about slow path processing can cause packets to be deliver out of order to the destination.¶
• Editorial changes¶

draft-ietf-6man-hbh-processing-04, 2022-October-21:¶

• Add a paragraph to Section 4 that describes the relationship to [RFC7045] "Transmission and Processing of IPv6 Extension Headers".¶
• Change that this draft updates section 2.2 of [RFC7045].¶

draft-ietf-6man-hbh-processing-03, 2022-October-12:¶

• Changed in Section 5.1 to have router skip over options if can't process at full forwarding rate.¶
• Added to Section 6 that new options should be defined with action type set to 00.¶

draft-ietf-6man-hbh-processing-02, 2022-August-23:¶

• Several clarification and editorial changes suggested by a review by Peng Shuping.¶
• Editorial changes.¶
• Revised text relating to fast/slow path and processing rates.¶
• Revised the third paragraph in Section 5.1.1 to be clearer.¶
• Revised text in Security section based on comments from Fernando Gont.¶

draft-ietf-6man-hbh-processing-01, 2022-June-15:¶

• Fixed typo in last paragraph of Section 5.1¶
• Revised text in Section 4 to reflect constraints on publishing RFC 8200.¶
• Changed text in Section 6 that new options SHOULD NOT (from MUST NOT) be defined that require that are not expected to be excepted at full forwarding rates.¶
• Added reference to RFC7872 in Section 4.¶
• Added text to Section 1 that the focus of this document is to set a minimum bound on the number of Hop-by-Hop options a node should process.¶
• Added text to Section 4 that the authors some Hop-by-Hop options will be supported Internet wide, and others only in limited domains.¶
• Editorial changes.¶

draft-ietf-6man-hbh-processing-00, 2022-January-29:¶

• 6MAN Working Group Draft¶
• Reworked text to talk about processing Hop-by-Hop options at full forwarding rates, instead of "fast path"¶
• Revised Section 6 "New Hop-by-Hop options" to allow variable sized Hop-by-Hop options, remove specific length requirements, and other clarifications.¶
• Editorial changes.¶

draft-hinden-6man-hbh-processing-01, 2021-June-2:¶

• Expanded terminology section to include forwarding plane and control plane.¶
• Changed draft that only one Hop-by-Hop option MUST be processed and additional Hop-by-Hop options MAY be processed based on local configuration.¶
• Clarified that all Hop-by-Hop options (with one exception) must be processed on the Fast Path.¶
• Kept the Router Alert Option as the single exception for Slow Path processing.¶
• Rewrote and expanded section on New Hop-by-Hop options.¶
• Removed requirement for Hop-by-Hop option size and alignment.¶
• Removed sections evaluating currently defined Hop-by-Hop options.¶
• Added content to the Security Considerations section.¶
• Added people to the acknowledgements section.¶
• Numerous editorial changes¶

draft-hinden-6man-hbh-processing-00, 2020-Nov-29:¶

• Initial draft.¶

Authors' Addresses