rfc9673.original   rfc9673.txt 
Network Working Group R. Hinden Internet Engineering Task Force (IETF) R. Hinden
Internet-Draft Check Point Software Request for Comments: 9673 Check Point Software
Updates: 8200 (if approved) G. Fairhurst Updates: 8200 G. Fairhurst
Intended status: Standards Track University of Aberdeen Category: Standards Track University of Aberdeen
Expires: 7 December 2024 5 June 2024 ISSN: 2070-1721 October 2024
IPv6 Hop-by-Hop Options Processing Procedures IPv6 Hop-by-Hop Options Processing Procedures
draft-ietf-6man-hbh-processing-20
Abstract Abstract
This document specifies procedures for how IPv6 Hop-by-Hop options This document specifies procedures for processing IPv6 Hop-by-Hop
are processed in IPv6 routers and hosts. It modifies the procedures options in IPv6 routers and hosts. It modifies the procedures
specified in the IPv6 Protocol Specification (RFC 8200) to make specified in the IPv6 Protocol Specification (RFC 8200) to make
processing of the IPv6 Hop-by-Hop Options header practical with the processing of the IPv6 Hop-by-Hop Options header practical with the
goal of making IPv6 Hop-by-Hop options useful to deploy and use in goal of making IPv6 Hop-by-Hop options useful to deploy and use at
the Internet. When published, this document updates RFC 8200. IPv6 routers and hosts. This document updates RFC 8200.
Status of This Memo Status of This Memo
This Internet-Draft is submitted in full conformance with the This is an Internet Standards Track document.
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 This document is a product of the Internet Engineering Task Force
and may be updated, replaced, or obsoleted by other documents at any (IETF). It represents the consensus of the IETF community. It has
time. It is inappropriate to use Internet-Drafts as reference received public review and has been approved for publication by the
material or to cite them other than as "work in progress." Internet Engineering Steering Group (IESG). Further information on
Internet Standards is available in Section 2 of RFC 7841.
This Internet-Draft will expire on 7 December 2024. Information about the current status of this document, any errata,
and how to provide feedback on it may be obtained at
https://www.rfc-editor.org/info/rfc9673.
Copyright Notice Copyright Notice
Copyright (c) 2024 IETF Trust and the persons identified as the Copyright (c) 2024 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents (https://trustee.ietf.org/ Provisions Relating to IETF Documents
license-info) in effect on the date of publication of this document. (https://trustee.ietf.org/license-info) in effect on the date of
Please review these documents carefully, as they describe your rights publication of this document. Please review these documents
and restrictions with respect to this document. Code Components carefully, as they describe your rights and restrictions with respect
extracted from this document must include Revised BSD License text as to this document. Code Components extracted from this document must
described in Section 4.e of the Trust Legal Provisions and are include Revised BSD License text as described in Section 4.e of the
provided without warranty as described in the Revised BSD License. Trust Legal Provisions and are provided without warranty as described
in the Revised BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 1. Introduction
2. Requirements Language . . . . . . . . . . . . . . . . . . . . 3 2. Requirements Language
3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 3. Terminology
4. Background . . . . . . . . . . . . . . . . . . . . . . . . . 4 4. Background
5. Hop-by-Hop Header Processing Procedures . . . . . . . . . . . 7 5. Hop-by-Hop Header Processing Procedures
5.1. Processing the Extension Header Carrying Hop-by-Hop 5.1. Processing the Extension Header Carrying Hop-by-Hop Options
Options . . . . . . . . . . . . . . . . . . . . . . . . . 8 5.1.1. Configuration Enabling Hop-by-Hop Header Processing
5.1.1. Configuration Enabling Hop-by-Hop Header 5.2. Hop-by-Hop Options Processing
Processing . . . . . . . . . . . . . . . . . . . . . 8 5.2.1. Router Alert Option
5.2. Hop-by-Hop Options Processing . . . . . . . . . . . . . . 9 5.2.2. Configuration of Hop-by-Hop Options Processing
5.2.1. Router Alert Option . . . . . . . . . . . . . . . . . 11 6. Defining New Hop-by-Hop Options
5.2.2. Configuration of Hop-by-Hop Option Processing . . . . 12 6.1. Example of Robust Usage
6. Defining New Hop-by-Hop Options . . . . . . . . . . . . . . . 12 7. IANA Considerations
6.1. Example of Robust Usage . . . . . . . . . . . . . . . . . 13 8. Security Considerations
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14 9. Normative References
8. Security Considerations . . . . . . . . . . . . . . . . . . . 14 10. Informative References
9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 16 Acknowledgments
10. Change log [RFC Editor: Please remove] . . . . . . . . . . . 16 Authors' Addresses
11. Normative References . . . . . . . . . . . . . . . . . . . . 20
12. Informative References . . . . . . . . . . . . . . . . . . . 20
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 22
1. Introduction 1. Introduction
This document specifies procedures for processing IPv6 Hop-by-Hop This document specifies procedures for processing IPv6 Hop-by-Hop
options in IPv6 routers and hosts. It modifies the procedures options in IPv6 routers and hosts. It modifies the procedures
specified in the IPv6 Protocol Specification [RFC8200] to make specified in the IPv6 Protocol Specification [RFC8200] to make
processing of IPv6 Hop-by-Hop Options header practical with the goal processing of the IPv6 Hop-by-Hop Options header practical with the
of making IPv6 Hop-by-Hop options useful to deploy and use at IPv6 goal of making IPv6 Hop-by-Hop options useful to deploy and use at
routers and hosts. IPv6 routers and hosts.
An IPv6 packet includes Hop-by-Hop options by including a Hop-by-Hop 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 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 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 minimum requirements for router processing of Hop-by-Hop options. It
also discusses how Hop-by-Hop options are used by hosts. This 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 document does not propose a specific bound to the number or size of
Hop-by-Hop options that ought to be processed. Hop-by-Hop options that ought to be processed.
When published, this document updates [RFC8200]. This document updates [RFC8200].
2. Requirements Language 2. Requirements Language
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described in BCP "OPTIONAL" in this document are to be interpreted as described in
14 [RFC2119] [RFC8174] when, and only when, they appear in all BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all
capitals, as shown here. capitals, as shown here.
3. Terminology 3. Terminology
This document uses the following loosely defined terms: This document uses the following loosely defined terms:
* forwarding plane: IPv6 routers exchange user or applications data Forwarding Plane: IPv6 routers exchange user or applications data
through the forwarding plane. Routers process fields contained in through the Forwarding Plane. Routers process fields contained in
IPv6 packet headers. However, they do not process information IPv6 packet headers. However, they do not process information
contained in packet payloads. contained in packet payloads.
* control plane: IPv6 routers exchange control information through Control Plane: IPv6 routers exchange control information through the
the control plane. The control plane processes the management and Control Plane. The Control Plane processes the management and
routing information exchanged with other routers. routing information exchanged with other routers.
* Fast Path: A path through a router that is optimized for Fast Path: A path through a router that is optimized for forwarding
forwarding packets. The Fast Path might be supported by packets. The Fast Path might be supported by Application-Specific
Application Specific Integrated Circuits (ASICs), a Network Integrated Circuits (ASICs), a Network Processor (NP), or other
Processor (NP), or other special purpose hardware. This is the special purpose hardware. This is the typical processing path
typical processing path within a router taken by the forwarding within a router taken by the Forwarding Plane.
plane.
* Slow Path: A path through a router that is capable of general Slow Path: A path through a router that is capable of general
purpose processing and is not optimized for any particular purpose processing and is not optimized for any particular
function. This processing path is used for packets that require function. This processing path is used for packets that require
special processing or differ from assumptions made in Fast Path special processing or that differ from assumptions made in Fast
heuristics or to process router control protocols used by the Path heuristics or to process router control protocols used by the
control plane. Control Plane.
* Full Forwarding Rate: This is the rate that a router can forward Full Forwarding Rate: The rate at which a router can forward packets
packets without adversely impacting the aggregate forwarding rate. without adversely impacting the aggregate forwarding rate. For
For example, a router could process packets with Hop-by-Hop example, a router could process packets with Hop-by-Hop options at
options at a rate that allows it to maintain the full speed on its a rate that allows it to maintain the full speed on its outgoing
outgoing interfaces, which is sometimes called "wire speed". interfaces, which is sometimes called "wire speed".
* source: The node originating the packet. Source: The node originating the packet.
NOTE: [RFC6192] is an example of how designs can separate control NOTE: [RFC6192] is an example of how designs can separate Control
plane and forwarding plane functions. The separation between Plane and Forwarding Plane functions. The separation between
hardware and software processing described in [RFC6398] does not hardware and software processing described in [RFC6398] does not
apply to all router architectures. However, a router that performs apply to all router architectures. However, a router that performs
all or most processing in software might still incur more processing all or most processing in software might still incur more processing
cost when providing special processing for Hop-by-Hop options. cost when providing special processing for Hop-by-Hop options.
4. Background 4. Background
In the first versions of the IPv6 specification [RFC1883] and In early versions of the IPv6 protocol specification [RFC1883]
[RFC2460], Hop-by-Hop options were required to be processed by all [RFC2460], Hop-by-Hop options were required to be processed by all
nodes: routers and hosts. This proved to not be practical in current 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 high speed routers, as observed in Section 2.2 of [RFC7045]: "it is
be expected that high-performance routers will either ignore it or to be expected that high-performance routers will either ignore it or
assign packets containing it to a slow processing path". The reason assign packets containing it to a slow processing path". The reasons
behind this includes: behind this include the following:
* Inability to process Hop-by-Hop options at the full forwarding * The inability to process Hop-by-Hop options at the Full Forwarding
rate can result in issues. In some cases, Hop-by-Hop options Rate can result in issues. In some cases, Hop-by-Hop options
would be sent to the control/management components that run on the would be sent to the control/management components that run on the
slow path. This could degrade a router's performance and also its Slow Path. This could degrade a router's performance and also its
ability to process critical control traffic. Both of which could ability to process critical control traffic, both of which could
be exploited as a Denial-of-Service attack against the router. 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, * If a subset of packets within a flow includes Hop-by-Hop options,
this could lead to an increased number of reordered packets and it could lead to an increased number of reordered packets and
greater reordering distances for packets delivered to the greater reordering distances for packets delivered to the
destination. Such reordering could occur if the Hop-by-Hop destination. Such reordering could occur if the Hop-by-Hop
Options header is included only in some packets, or if a specific Options header is included only in some packets or if a specific
Hop-by-Hop option results in different processing for some of the Hop-by-Hop option results in different processing for some of the
packets within the flow. Significant reordering of packets within packets within the flow. Significant reordering of packets within
a flow can negatively impact the performance of upper-layer a flow can negatively impact the performance of upper-layer
protocols and should therefore be avoided. protocols and should therefore be avoided.
* Packets could include multiple Hop-by-Hop options. Too many * Packets could include multiple Hop-by-Hop options. Too many
options could make the previous issues worse by increasing the options could make the previous issues worse by increasing the
resources required to process them. The total size of the options resources required to process them. The total size of the options
determines the number of header bytes that might need to be determines the number of header bytes that might need to be
processed. Measurements [Cus23a] show that the probability of processed. Measurements [Cus23a] show that the probability of
successful transmission across the public Internet is currently successful transmission across the public Internet is currently
higher for packets that include Options when it results in a short higher for packets that include Options that result in a short
total Extension Header (EH) Chain size (i.e., less than 40 bytes). total Extension Header (EH) Chain size (i.e., less than 40 bytes).
[RFC6564] specified a uniform format for new IPv6 Extension Headers. [RFC6564] specifies a uniform format for new IPv6 Extension Headers,
It updated [RFC2460], and this update was incorporated into and this update was incorporated into Section 4.8 of [RFC8200] (note
Section 4.8 of [RFC8200]. that [RFC8200] obsoleted [RFC2460]).
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 When the IPv6 protocol specification was updated and published in
be examined or processed by any node along a packet's delivery July 2017 as [RFC8200], the procedures relating to Hop-by-Hop options
path, until the packet reaches the node (or each of the set of were specified (paragraphs 5 and 6 of Section 4 of [RFC8200]) as
nodes, in the case of multicast) identified in the Destination follows:
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 | The Hop-by-Hop Options header is not inserted or deleted, but may
process the Hop-by-Hop Options header, it is now expected that | be examined or processed by any node along a packet's delivery
nodes along a packet's delivery path only examine and process the | path, until the packet reaches the node (or each of the set of
Hop-by-Hop Options header if explicitly configured to do so. | 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 The changes meant that an implementation complied with the IPv6
specification even if it did not process Hop-by-Hop options, and that protocol specification even if it did not process Hop-by-Hop options
it was expected that routers would add configuration information to and that routers were expected to add configuration information to
control whether they process the Hop-by-Hop Options header. In control whether they process the Hop-by-Hop Options header. In
practice, routers may include configuration options to control which practice, routers may include configuration options to control which
Hop-by-Hop options they will process. Hop-by-Hop options they will process.
The text regarding processing of Hop-by-Hop options in [RFC8200] was The text regarding the processing of Hop-by-Hop options in [RFC8200]
not intended to change the processing of these options. It was not intended to change the processing of these options. It
documented how they were being used in the Internet at the time RFC documented how they were being used in the Internet at the time RFC
8200 was published (see Appendix B of [RFC8200]). This was a 8200 was published (see Appendix B of [RFC8200]). This was a
constraint on publishing the IPv6 specification as an IETF Standard. constraint on publishing the IPv6 protocol specification as an IETF
Standard.
The main issues remain: The main issues remain:
* Routers can be configured to drop transit packets containing Hop- * Routers can be configured to drop transit packets containing Hop-
by-Hop Options that would have required processing by a processor by-Hop Options that require processing by a processor that
that implements the control plane. This could be done to protect implements the Control Plane. This could be done to protect
against a Denial-of-Service attack on the router against a DoS attack on the router [RFC9098] [RFC9288].
[RFC9098][RFC9288].
* IPv6 Packets that include a Hop-by-Hop Options header are dropped * IPv6 packets that include a Hop-by-Hop Options header are dropped
by some Internet paths. A survey in 2015 reported a high loss by some Internet paths. A survey in 2015 reported a high loss
rate in transit ASs for packets with Hop-by-Hop options [RFC7872]. rate in transit Autonomous Systems (ASes) for packets that include
The operational implications of IPv6 Packets that include Hop-by-Hop options [RFC7872]. The operational implications of
Extension Headers are discussed in [RFC9098]. Measurements in IPv6 packets that include Extension Headers are discussed in
2023 confirm this to still be the case for many types of network [RFC9098]. Measurements taken in 2023 confirm this to still be
paths [Cus23b]. the case for many types of network paths [Cus23b].
* Allowing multiple Hop-by-Hop options in a single packet in some * Allowing multiple Hop-by-Hop options in a single packet in some
cases consumes more router resources to process these packets. It cases consumes more router resources to process these packets. It
also adds complexity to the number of permutations that might need also adds complexity to the number of permutations that might need
to be processed/configured. to be processed/configured.
* Including larger or multiple Hop-by-Hop options in a Hop-by-Hop * Including larger or multiple Hop-by-Hop options in a Hop-by-Hop
Options header increases the number of bytes that need to be Options header increases the number of bytes that need to be
processed in forwarding, which can in some designs impact the cost processed in forwarding, which in some designs can impact the cost
of processing a packet, and in turn could increase the probability of processing a packet, and in turn could increase the probability
of drop [RFC7872]. A larger Extension Header could also reduce of drop [RFC7872]. A larger Extension Header could also reduce
the probability that a router can locate all the header bytes the probability of a router locating all the header bytes required
required to successfully process an access control list operating to successfully process an access control list operating on fields
on fields after the Hop-by-Hop Options header. after the Hop-by-Hop Options header.
* Any option that can be used to force packets into the processor * Any option that can be used to force packets into the processor
that implements the router's control plane can be exploited as a that implements the router's Control Plane can be exploited as a
Denial-of-Service attack on a transit router by saturating the DoS attack on a transit router by saturating the resources needed
resources needed for router management protocols (routing for router management protocols (routing protocols, network
protocols, network management protocols, etc.), that could cause management protocols, etc.), which could cause adverse router
adverse router operation. This is an issue for the Router Alert operation. This is an issue for the Router Alert Option
Hop-by-Hop Option [RFC2711], which intentionally forwards packets [RFC2711], which intentionally forwards packets to the Control
to the control plane, and is discussed in [RFC6398]. This impact Plane as discussed in [RFC6398]. This impact could be mitigated
could be mitigated by limiting the use of control plane resources by limiting the use of Control Plane resources by a specific
by a specific packet, and/or by the use of per-function rate- packet and/or by using per-function rate-limiters for packets
limiters for packets processed by the control plane. processed by the Control Plane.
Section 3 of RFC 6398 includes a summary of processing the IP Router Section 3 of [RFC6398] includes a summary of processing the IP Router
Alert Option: Alert Option:
"In a nutshell, the IP Router Alert Option does not provide a | In a nutshell, the IP Router Alert Option does not provide a
convenient universal mechanism to accurately and reliably | convenient universal mechanism to accurately and reliably
distinguish between IP Router Alert packets of interest and | distinguish between IP Router Alert packets of interest and
unwanted IP Router Alert packets. This, in turn, creates a | unwanted IP Router Alert packets. This, in turn, creates a
security concern when the IP Router Alert option is used, because, | security concern when the IP Router Alert Option is used, because,
short of appropriate router-implementation-specific mechanisms, | short of appropriate router-implementation-specific mechanisms,
the router Slow Path is at risk of being flooded by unwanted | the router slow path is at risk of being flooded by unwanted
traffic." | traffic.
This is an example of the need to limit the resources that can be This is an example of the need to limit the resources that can be
consumed when a particular function is executed and to avoid consumed when a particular function is executed and to avoid
consuming control-plane resources where support for a function has consuming Control Plane resources where support for a function has
not been configured. not been configured.
There has been research that has discussed the general problem with There has been research that has discussed the general problem with
dropping packets containing IPv6 Extension Headers, including the dropping packets containing IPv6 Extension Headers, including the
Hop-by-Hop Options header. For example, [Hendriks] states that Hop-by-Hop Options header. For example, [Hendriks] states that
"dropping all packets with Extension Headers, is a bad practice", and "Dropping all packets that contain Extension Headers is a bad
that "The share of traffic containing more than one EH however, is practice" and that "The share of traffic containing more than one EH
very small. For the design of hardware able to handle the dynamic however, is very small. For the design of hardware able to handle
nature of Extension Headers we therefore recommend to support at the dynamic nature of EHs, we therefore recommend to support at least
least one EH". Operational aspects of the topics discussed in this one EH". Operational aspects of the topics discussed in this section
section are further discussed in [I-D.ietf-v6ops-hbh]. are further discussed in [HBH].
"Transmission and Processing of IPv6 Extension Headers" [RFC7045] "Transmission and Processing of IPv6 Extension Headers" [RFC7045]
clarified how intermediate nodes should process Extension Headers. clarifies how intermediate nodes should process Extension Headers.
The present document is generally consistent with [RFC7045], and This document is generally consistent with [RFC7045] and addresses an
addresses an issue that was raised for discussion when [RFC2460] was issue that was raised for discussion when [RFC2460] was updated and
updated and replaced by [RFC8200]. This document updates [RFC8200] replaced by [RFC8200]. This document updates [RFC8200] as described
as described in the next section and consequently clarifies the in the next section and consequently clarifies the description in
description in Section 2.2 of [RFC7045], using the language of BCP 14 Section 2.2 of [RFC7045], using the language of BCP 14 [RFC2119]
[RFC2119] [RFC8174]. [RFC8174].
This document defines a set of procedures for the Hop-by-Hop Options 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 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- practical in modern routers. The common cases are that some Hop-by-
Hop options will be processed across the Internet, while others will Hop options will be processed across the Internet, while others will
only be processed within a limited domain [RFC8799] (e.g., where a only be processed within a limited domain [RFC8799] (e.g., where a
specific service is made available in that network segment that specific service is made available in that network segment that
relies on one or more Hop-by-Hop options). relies on one or more Hop-by-Hop options).
5. Hop-by-Hop Header Processing Procedures 5. Hop-by-Hop Header Processing Procedures
This section describes several changes to [RFC8200]. Section 5.1 This section describes several changes to [RFC8200]. Section 5.1
describes processing of the Hop-by-Hop options Extension Header, and describes the processing of the Hop-by-Hop options Extension Header,
Section 5.2 describes processing of individual Hop-by-Hop Options. and Section 5.2 describes the processing of individual Hop-by-Hop
These sections updates the text in paragraphs 5 and 6 of Section 4 of options. These sections update the text in paragraph 6 of Section 4
[RFC8200] and as noted in Section 5.2 modifies Section 4.2 of of [RFC8200] and, as noted in Section 5.2, modify Section 4.2 of
[RFC8200]. [RFC8200].
5.1. Processing the Extension Header Carrying Hop-by-Hop Options 5.1. Processing the Extension Header Carrying Hop-by-Hop Options
When a packet includes one or more Extension Headers, the Next Header When a packet includes one or more Extension Headers, the Next Header
field of the IPv6 Header identifies the type of Extension Header. It field of the IPv6 Header identifies the type of Extension Header. It
does not identify the transport protocol. does not identify the transport protocol.
The Extension Header used to carry Hop-by-Hop options is defined in 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 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- 0 in the IPv6 header. Section 4.1 of [RFC8200] requires this Hop-by-
Hop Options header to appear immediately after the IPv6 header. Hop Options header to appear immediately after the IPv6 header.
[RFC8200] also requires that a Hop-by-Hop Options header only appear [RFC8200] also requires that a Hop-by-Hop Options header only appear
at most once in a packet. at most once in a packet.
The Hop-by-Hop Options Header as defined in [RFC8200] can contain one The Hop-by-Hop Options header as defined in [RFC8200] can contain one
or more Hop-by-Hop options. or more Hop-by-Hop options.
Routers that process the Hop-by-Hop Options header SHOULD do so using Routers that process the Hop-by-Hop Options header SHOULD do so using
the method defined in this document. Exceptions to this "SHOULD" the method defined in this document. Exceptions to this SHOULD
include routers that are configured to drop packets with a Hop-by-Hop include routers that are configured to drop packets with a Hop-by-Hop
Options header to protect downstream devices that do not comply with Options header to protect downstream devices that do not comply with
this specification (see [RFC9288]). this specification (see [RFC9288]).
Even if a router does not process the Hop-by-Hop Options header (for Even if a router does not process the Hop-by-Hop Options header (for
example, based on configuration), it MUST forward the packet normally example, when based on configuration), it MUST forward the packet
based on the remaining Extension Header(s) after the Hop-by-Hop normally based on the remaining Extension Header(s) after the Hop-by-
Options header. A router MUST NOT drop a packet solely because it Hop Options header. A router MUST NOT drop a packet solely because
contains an Extension Header carrying Hop-by-Hop options. A it contains an Extension Header carrying Hop-by-Hop options. A
configuration could control that normal processing skips any or all configuration could control whether normal processing skips any or
of the Hop-by-Hop options carried in the Hop-by-Hop Options header. 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 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 by the destination(s). Hosts SHOULD process the Hop-by-Hop Options
header in received packets. A constrained host is an example of a 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 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 destination does not process the Hop-by-Hop Options header, it MUST
process the remainder of the packet normally. process the remainder of the packet normally.
5.1.1. Configuration Enabling Hop-by-Hop Header Processing 5.1.1. Configuration Enabling Hop-by-Hop Header Processing
Section 4 of [RFC8200] allows a router to control its processing of Section 4 of [RFC8200] allows a router to control its processing of
IPv6 Hop-by-Hop options by local configuration. The text is: IPv6 Hop-by-Hop options by local configuration. The text is:
NOTE: While [RFC2460] required that all nodes must examine and | NOTE: While [RFC2460] required that all nodes must examine and
process the Hop-by-Hop Options header, it is now expected that | process the Hop-by-Hop Options header, it is now expected that
nodes along the path only examine and process the Hop-by-Hop | nodes along the path only examine and process the Hop-by-Hop
Options header if explicitly configured to do so. | Options header if explicitly configured to do so.
This document clarifies that a configuration could control whether This document clarifies that a configuration could control whether
processing skips any specific Hop-by-Hop options carried in the Hop- processing skips any specific Hop-by-Hop options carried in the Hop-
by-Hop Options header. A router that does not process the contents by-Hop Options header. A router that does not process the contents
of the Hop-by-Hop Options header does not therefore process the of the Hop-by-Hop Options header does not process any of the Option
option types of individual Option Types to perform any specified Types contained in the Hop-by-Hop Options header.
action.
5.2. Hop-by-Hop Options Processing 5.2. Hop-by-Hop Options Processing
A source creating packets with a Hop-by-Hop Options header SHOULD use A Source creating packets with a Hop-by-Hop Options header SHOULD use
a method that is robust to network nodes selectively processing only a method that is robust to network nodes selectively processing only
some of the Hop-by-Hop options that are included in the packet, or some of the Hop-by-Hop options that are included in the packet or
that forward packets without the option(s) being processed (see that forward packets without the option(s) being processed (see
Section 6.1). A source MAY, based on local configuration, allow only Section 6.1). A Source MAY, based on local configuration, allow only
one Hop-by-Hop option to be included in a packet, or could allow more one Hop-by-Hop option to be included in a packet, or it could allow
than one Hop-by-Hop options, but limit their size to increase the more than one Hop-by-Hop option but limit their size to increase the
likelihood of successful transfer across a network path. Because likelihood of successful transfer across a network path. Because
some routers might only process one or a limited number of options in some routers might only process one or a limited number of options in
the Hop-by-Hop Option header, sources are motivated to order the the Hop-by-Hop Options header, Sources are motivated to order the
placement of Hop-by-Hop options within the Hop-by-Hop Options header placement of Hop-by-Hop options within the Hop-by-Hop Options header
in decreasing order of importance for their processing by nodes on in decreasing order of importance for their processing by nodes on
the path. the path.
A router configuration needs to avoid vulnerabilities that arise when A router configuration needs to avoid vulnerabilities that arise when
it cannot process the first Hop-by-Hop option at full forwarding it cannot process the first Hop-by-Hop option at the Full Forwarding
rate. A router SHOULD NOT therefore be configured to process the Rate. Therefore, a router SHOULD NOT be configured to process the
first Hop-by-Hop option if this adversely impacts the aggregate first Hop-by-Hop option if this adversely impacts the aggregate
forwarding rate. A router SHOULD process additional Hop-by-Hop forwarding rate. A router SHOULD process additional Hop-by-Hop
options, if configured to do so, providing that these also do not options, if configured to do so, providing that these also do not
adversely impact the aggregate forwarding rate. adversely impact the aggregate forwarding rate.
If a router is unable to process a specific Hop-by-Hop option (or is If a router is unable to process a specific Hop-by-Hop option (or is
not configured to do so), it SHOULD behave in the way specified for not configured to do so), it SHOULD behave in the same way specified
an unrecognized Option Type when the action bits were set to "00" and for an unrecognized Option Type when the action bits are set to "00",
SHOULD skip the remaining options using the "Hdr Ext Len" field in and it SHOULD skip the remaining options using the "Hdr Ext Len"
the Hop-by-Hop Options header. This field specifies the length of field in the Hop-by-Hop Options header. This field specifies the
the Options Header in 8-octet units. After skipping an option, the length of the Options Header in 8-octet units. After skipping an
router continues processing the remaining options in the header. option, the router continues processing the remaining options in the
Skipped options do not need to be verified. header. Skipped options do not need to be verified.
The Router Alert Option [RFC2711] is an exception to this because it The Router Alert Option [RFC2711] is an exception to this because it
is designed to tell a router that the packet needs additional is designed to tell a router that the packet needs additional
processing, usually done in the control plane, see Section 5.2.1. 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 Section 4.2 of [RFC8200] defines the Option Type identifiers as
internally encoded such that their highest-order 2 bits specify the internally encoded such that their highest-order 2 bits specify the
action that must be taken if the processing IPv6 node does not action that must be taken if the processing IPv6 node does not
recognize the Option Type. The text is: recognize the Option Type. The text is:
00 - skip over this option and continue processing the header. 00 - skip over this option and continue processing the header.
01 - discard the packet. 01 - discard the packet.
10 - discard the packet and, regardless of whether or not the 10 - discard the packet and, regardless of whether or not the
packet's Destination Address was a multicast address, send an packet's Destination Address was a multicast address,
ICMPv6 Parameter Problem, Code 2 [RFC4443], message to the send an ICMP Parameter Problem, Code 2, message to the
packet's Source Address, pointing to the unrecognized Option packet's Source Address, pointing to the unrecognized
Type. Option Type.
11 - discard the packet and, only if the packet's Destination 11 - discard the packet and, only if the packet's Destination
Address was not a multicast address, send an ICMPv6 Parameter Address was not a multicast address, send an ICMP Parameter
Problem, Code 2, message to the packet's Source Address, Problem, Code 2, message to the packet's Source Address,
pointing to the unrecognized Option Type. pointing to the unrecognized Option Type.
This document modifies this behaviour for the "01", "10", and "11" 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- 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 in by-Hop option (or is not configured to do so), it SHOULD behave in
the way specified for an unrecognized Option Type when the action the same way specified for an unrecognized Option Type when the
bits were set to "00". It also modifies the behaviour for the "10" action bits are set to "00". It also modifies the behavior for
and "11" values for the case when the packet is discarded, the node values "10" and "11" in the case where the packet is discarded and
MAY send an ICMP Parameter Problem, Code 2 [RFC4443], message to the the node MAY send an ICMP Parameter Problem, Code 2 [RFC4443],
packet's Source Address, pointing to the unrecognized Option Type. message to the packet's Source Address, pointing to the unrecognized
Option Type.
The modified text for "01", "10", and "11" values is: The modified text for values "01", "10", and "11" is:
01 - MAY discard the packet, if so configured. Nodes should not 01 - MAY discard the packet, if so configured. Nodes should not
rely on routers dropping these unrecognized Option Types. rely on routers dropping these unrecognized Option Types.
10 - MAY discard the packet, if so configured, and, regardless of 10 - MAY discard the packet, if so configured, regardless of
whether or not the packet's Destination Address was a whether or not the packet's Destination Address was a
multicast address. If the packet was discarded, it MAY send multicast address. If the packet was discarded, an ICMP
an ICMP Parameter Problem, Code 2, message to the packet's Parameter Problem, Code 2, message MAY be sent to the
Source Address, pointing to the unrecognized Option Type. packet's Source Address, pointing to the unrecognized
Option Type.
11 - MAY discard the packet, if so configured. Only if the 11 - MAY discard the packet, if so configured. If the packet
packet was discarded and the was discarded and the packet's Destination Address was
packet's Destination Address was not a multicast address, not a multicast address, an ICMP Parameter Problem,
it MAY send an ICMP Parameter Code 2, message MAY be sent to the packet's Source
Problem, Code 2, message to the packet's Source Address, Address, pointing to the unrecognized Option Type.
pointing to the unrecognized Option Type.
When an ICMP Parameter Problem, Code 2, message is delivered to the When an ICMP Parameter Problem, Code 2, message is delivered to the
source, it indicates that at least one node on the path has failed to Source, it indicates that at least one node on the path has failed to
recognize the option [RFC4443]. Generating any ICMP message incurs recognize the option [RFC4443]. Generating any ICMP message incurs
additional router processing. Reception of this message is not additional router processing. Reception of this message is not
guaranteed, routers might be unable to be configured so that they do guaranteed; routers might be unable to be configured so that they do
not generate these messages, and they are not always forwarded to the not generate these messages, and they are not always forwarded to the
source. The motivation here is to loosen the requirement to send an Source. The motivation here is to loosen the requirement to send an
ICMPv6 Parameter Problem message when a router forwards a packet ICMPv6 Parameter Problem message when a router forwards a packet
without processing the list of all options. without processing the list of all options.
5.2.1. Router Alert Option 5.2.1. Router Alert Option
The purpose of the Router Alert Option [RFC2711] is to tell a router The purpose of the Router Alert Option [RFC2711] is to tell a router
that the packet needs additional processing in the control plane. that the packet needs additional processing in the Control Plane.
The Router Alert Option includes a two-octet Value field that The Router Alert Option includes a two-octet Value field that
describes the protocol that is carried in the packet. The current describes the protocol that is carried in the packet. The current
specified values can be found in the IANA Router Alert Value registry specified values can be found in the "IPv6 Router Alert Option
[IANA-RA]. Values" IANA registry [IANA-RA].
DISCUSSION DISCUSSION
The function of a Router Alert Option can result in the processing The function of a Router Alert Option can result in the processing
that this specification is proposing to eliminate, that is, to that this specification is proposing to eliminate, that is,
instruct a router to process the packet in the control plane. instructing a router to process the packet in the Control Plane.
This results in the concerns discussed in section 4. One approach This processing causes concerns, which are discussed in Section 4.
would be to deprecate this, because current usage beyond the local One approach would be to deprecate this, because current usage
network appears to be limited, and packets containing Hop-by-Hop beyond the local network appears to be limited, and packets
options are frequently dropped. Deprecation would allow current containing Hop-by-Hop options are frequently dropped. Deprecation
implementations to continue and its use could be phased out over would allow current implementations to continue, and its use could
time. be phased out over time.
The Router Alert Option could have a potential for use with new The Router Alert Option could potentially be used with new
functions that have to be processed in the control plane. Keeping functions that have to be processed in the Control Plane. Keeping
this as the single exception for processing in the control plane this as the single exception for processing in the Control Plane
with the following restrictions is a reasonable compromise to with the restrictions that follow is a reasonable compromise to
allow future flexibility. These restrictions are compatible with allow future flexibility. These restrictions are compatible with
Section 5 of [RFC6398]. Section 5 of [RFC6398].
As noted in [RFC6398], "Implementations of the IP Router Alert option As noted in [RFC6398], "Implementations of the IP Router Alert Option
SHOULD offer the configuration option to simply ignore the presence SHOULD offer the configuration option to simply ignore the presence
of the IP Router Alert in IPv4 and IPv6 packets." of 'IP Router Alert' in IPv4 and IPv6 packets."
A node that is configured to process a Router Alert option MUST A node that is configured to process a Router Alert Option MUST
protect itself from infrastructure attack that could result from protect itself from an infrastructure attack that could result from
processing in the control plane. This might include some combination processing in the Control Plane. This might include some combination
of an access control list to only permit this from trusted nodes, of an access control list to only permit access from trusted nodes,
rate limiting of processing, or other methods [RFC6398]. rate limiting of processing, or other methods [RFC6398].
As specified in [RFC2711] the top two bits of Option Type for the As specified in [RFC2711], the top two bits of the Option Type for
Router Alert Option are always set to "00" indicating the node should the Router Alert Option are always set to "00", indicating that the
skip over this option as if it does not recognize the Option Type and node should skip over this option as if it does not recognize the
continue processing the header. An implementation that does Option Type and continue processing the header. An implementation
recognize the Router Alert Option SHOULD verify that a Router Alert that does recognize the Router Alert Option SHOULD verify that the
Option contains a protocol, as indicated by the Value field in the Router Alert Option contains a protocol, as indicated by the Value
Router Alert Option, that is configured as a protocol of interest to field in the Router Alert Option, that is configured as a protocol of
that router. A verified packet SHOULD be sent to the control plane interest to that router. A verified packet SHOULD be sent to the
for further processing [RFC6398]. Otherwise, the router Control Plane for further processing [RFC6398]. Otherwise, the
implementation SHOULD forward this packet subject to all normal router implementation SHOULD forward this packet subject to all
policies and forwarding rules. normal policies and forwarding rules.
5.2.2. Configuration of Hop-by-Hop Option Processing 5.2.2. Configuration of Hop-by-Hop Options Processing
A router can be configured to process a specific Option. The set of A router can be configured to process a specific Option. The set of
enabled options SHOULD be configurable by the operator of the router. enabled options SHOULD be configurable by the operator of the router.
A possible approach to implementing this is to maintain a lookup A possible approach to implementing this is to maintain a lookup
table based on Option Type of the IPv6 options that can be processed table based on an Option Type of the IPv6 options that can be
at full forwarding rate. This would allow a router to quickly processed at the Full Forwarding Rate. This would allow a router to
determine if an option is supported and can be processed. If the quickly determine if an option is supported and can be processed. If
option is not supported, then the router processes the option as the option is not supported, then the router processes the option as
described in Section 5.1 of this document. described in Section 5.1 of this document.
The actions of the lookup table should be configurable by the The actions of the lookup table should be configurable by the
operator of the router. operator of the router.
6. Defining New Hop-by-Hop Options 6. Defining New Hop-by-Hop Options
This section updates Section 4.8 of [RFC8200]. This section updates Section 4.8 of [RFC8200].
Any new IPv6 Hop-by-Hop option designed in the future should be Any future new IPv6 Hop-by-Hop options should be designed to be
designed to be processed at full forwarding rate. New Hop-by-Hop processed at the Full Forwarding Rate and should have the following
options should have the following characteristics: characteristics:
* New Hop-by-Hop options should be designed to ensure the router can * New Hop-by-Hop options should be designed to ensure the router can
process the options at the full forwarding rate. That is, they process the options at the Full Forwarding Rate. That is, they
should be simple to process. should be simple to process.
* New options should be defined with the Action type (highest-order * New Hop-by-Hop options should be defined with the Action type
2 bits of the Option Type) set to 00 to skip over this option and (highest-order 2 bits of the Option Type) set to "00", which
continue processing the header if a router does not recognize the enables skipping over this option and continuing with the
processing of the header if a router does not recognize the
option. option.
* The size of a Hop-by-Hop option should not extend beyond what can * The size of Hop-by-Hop options should not extend beyond what can
be expected to be executed at full forwarding rate. A larger Hop- be expected to be executed at the Full Forwarding Rate. A larger
by-Hop Options header can increase the likelihood that that a Hop-by-Hop Options header can increase the likelihood that a
packet will be dropped [Cus23b]. packet will be dropped [Cus23b].
* New Hop-by-Hop options should be designed expecting that a router * New Hop-by-Hop options should be designed with the expectation
might be configured to only process a subset of Hop-by-Hop options that a router might be configured to only process a subset of Hop-
(e.g., the first option) in the Hop-by-Hop Options header. 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 * The design of protocols that use new Hop-by-Hop options should
consider that a router may drop packets containing the new Hop-by- consider that a router may drop packets containing the new Hop-by-
Hop option. Hop option.
Any new Hop-by-Hop option that is standardized that does not meet If a new Hop-by-Hop option does not meet these criteria, its
these criteria must include in the specification a detailed specification must include a detailed explanation why that is the
explanation why this cannot be accomplished and to show that there is case and show that there is a reasonable expectation that the option
a reasonable expectation that the option can be proceed at full can still proceed at the Full Forwarding Rate. This is consistent
forwarding rate. This is consistent with [RFC6564]. with [RFC6564]. This is consistent with [RFC6564].
The general issue of robust operation of packets with new Hop-by-Hop The general issue of robust operation of packets with new Hop-by-Hop
options is described in Section 6.1 below. options is described in Section 6.1.
6.1. Example of Robust Usage 6.1. Example of Robust Usage
Recent measurement surveys (e.g., [Cus23a]) show that packets that Recent measurement surveys (e.g., [Cus23a]) show that packets that
include Extension Headers can cause the packets to be dropped by some include Extension Headers can cause the packets to be dropped by some
Internet paths. In a limited domain, routers can be configured or Internet paths. In a limited domain, routers can be configured or
updated to provide support for any required Hop-by-Hop options. updated to provide support for any required Hop-by-Hop options.
The primary motivation of this document is to make it more practical The primary motivation of this document is to make it more practical
to use Hop-by-Hop options beyond such a limited domain, with the to use Hop-by-Hop options beyond such a limited domain, with the
expectation that applications can improve the quality of or add new expectation that applications can improve the quality of or add new
features to their offered service when the path successfully forwards features to their offered service when the path successfully forwards
packets with the required Hop-by-Hop options and otherwise refrains packets with the required Hop-by-Hop options and otherwise refrains
from using these options. The focus is on incremental deployability. from using these options. The focus is on incremental deployability.
A protocol feature (such as using Hop-by-Hop options) is A protocol feature (such as using Hop-by-Hop options) is
incrementally deployable if early adopters gain some benefit on the incrementally deployable if early adopters gain some benefit on the
paths being used, even though other paths do not support the protocol paths being used, even though other paths do not support the protocol
feature. A source ought to order the Hop-by-Hop options that are feature. A Source ought to order the Hop-by-Hop options that are
carried in the Hop-by-Hop Options header in decreasing order of carried in the Hop-by-Hop Options header in decreasing order of
importance for processing by nodes on the path. importance for processing by nodes on the path.
Methods can be developed that do not rely upon all routers to Methods can be developed that do not rely upon all routers to
implement a specific Hop-by-Hop option (e.g., [RFC9268]), and that implement a specific Hop-by-Hop option (e.g., [RFC9268]) and that are
are robust when the current path drops packets that contain a Hop-by- robust when the current path drops packets that contain a Hop-by-Hop
Hop option (e.g., [RFC9098]). option (e.g., [RFC9098]).
For example, an application can be designed to first send a test For example, an application can be designed to first send a test
packet that includes the required option or combination of options, packet that includes the required option or combination of options
and sends other packets without including the option. The and then send other packets without including the option. The
application then does not send additional packets that include this application does not send additional packets that include this option
option (or set of options) until the test packet(s) is acknowledged. (or set of options) until the test packet(s) is acknowledged. The
The need for potential loss recovery when a path drops these test need for potential loss recovery when a path drops these test packets
packets can be avoided by choosing packets that do not carry can be avoided by choosing packets that do not carry application data
application data that needs to be reliably delivered. that needs to be reliably delivered.
Since the set of nodes forming a path can change with time, this Since the set of nodes forming a path can change with time, this
discovery process ought to be repeated from time-to-time. The discovery process ought to be repeated from time to time. The
process of sending packets both with and without a specific header to process of sending packets both with and without a specific header to
discover whether a path can support a specific header is sometimes discover whether a path can support a specific header is sometimes
called "racing". Transport protocol racing is explained in called "racing". Transport protocol racing is explained in
[I-D.ietf-taps-arch], and "A/B protocol feature testing" is described [TAPS-ARCH], and A/B protocol feature testing is described in
in [Tram17]. [Tram17].
7. IANA Considerations 7. IANA Considerations
This document requires no assignment actions by IANA. This document updates the processing of Hop-by-Hop options. IANA has
added this document as an additional reference for the "Destination
The document updates the processing of Hop-by-Hop options. IANA is Options and Hop-by-Hop Options" registry in the "Internet Protocol
requested to add the published RFC as an additional reference for Version 6 (IPv6) Parameters" registry group [IANA-HBH].
"Destination Options and Hop-by-Hop Options" in the Internet Protocol
Version 6 (IPv6) Parameters Registry.
8. Security Considerations 8. Security Considerations
Security issues with including IPv6 Hop-by-Hop options are well known Security issues caused by including IPv6 Hop-by-Hop options are well
and have been documented in several places, including [RFC6398], known and have been documented in several places, including
[RFC6192], [RFC7045] and [RFC9098]. The main issue, as noted in [RFC6398], [RFC6192], [RFC7045], and [RFC9098]. The main issue, as
Section 4, is that any mechanism that can be used to force packets noted in Section 4, is that any mechanism that can be used to force
into the router's control plane or slow path can be exploited as a packets into the router's Control Plane or Slow Path can be exploited
Denial-of-Service attack on a router by saturating the resources as a DoS attack on a router by saturating the resources needed for
needed for router management (routing protocols, network management router management (routing protocols, network management protocols,
protocols, etc.) and cause the router to fail or perform sub- etc.), and this can cause the router to fail or perform suboptimally.
optimally.
While Hop-by-Hop options are not required to be processed in the 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 Control Plane, the Router Alert Option is the one exception that is
designed to be processed in the control plane. designed to be processed in the Control Plane.
Some IPv6 nodes implement features that access more of the protocol Some IPv6 nodes implement features that access more of the protocol
information than a typical IPv6 router (e.g., [RFC9098]). Examples information than a typical IPv6 router (e.g., [RFC9098]). Examples
are nodes that provide Denial-of-Service mitigation, firewall/access are nodes that provide DoS mitigation, firewall/access control,
control, traffic engineering, or traffic normalization. These nodes traffic engineering, or traffic normalization. These nodes could be
could be configured to drop packets when they are unable to access configured to drop packets when they are unable to access and process
and process all Extension Headers or are unable to locate and process all Extension Headers or are unable to locate and process the higher-
the higher-layer packet information. This document provides guidance layer packet information. This document provides guidance on the
on the requirements concerning Hop-by-Hop options. requirements concerning Hop-by-Hop options.
Finally, the document notes that Internet protocol processing needs Finally, this document notes that Internet protocol processing needs
to be robust to malformed/malicious protocol fields. For example, a to be robust for malformed/malicious protocol fields. For example, a
packet with an excessive number of options could consume significant packet with an excessive number of options could consume significant
resources; inclusion of a large extension header could potentially resources; inclusion of a large Extension Header could potentially
cause an on-path router to be unable to utilise hardware cause an on-path router to be unable to utilize hardware
optimisations to process later headers (e.g., to perform equal cost optimizations to process later headers (e.g., to perform equal cost
multipath forwarding or port filtering). This requirement is not multipath forwarding or port filtering). This requirement is not
specific to Hop-by-Hop options. It is important that implementations specific to Hop-by-Hop options. It is important that implementations
fail gracefully when a malformed or malicious Hop-by-Hop option is fail gracefully when a malformed or malicious Hop-by-Hop option is
encountered. encountered.
This document changes the way the Hop-by-Hop Options header is This document changes how the Hop-by-Hop Options header is processed,
processed in several ways that significantly reduce the attack which significantly reduces the attack surface. These changes
surface. These changes include: include the following:
* A router configuration needs to avoid vulnerabilities that arise * A router configuration needs to avoid vulnerabilities that arise
when it cannot process a Hop-by-Hop option at full forwarding rate when it cannot process a Hop-by-Hop option at the Full Forwarding
and SHOULD NOT therefore be configured to process the a Hop-by-Hop Rate; therefore, it SHOULD NOT be configured to process the Hop-
option if this adversely impacts the aggregate forwarding rate, by-Hop option if it adversely impacts the aggregate forwarding
instead it SHOULD behave in the way specified for an unrecognized rate. Instead, it SHOULD behave in the same way specified for an
Option Type when the action bits were set to "00", as specified in unrecognized Option Type when the action bits are set to "00", as
Section 5.2. specified in Section 5.2.
* It adds criteria for the Router Alert Option in Section 5.2.1 to * This document adds criteria for the Router Alert Option
allow control over how the Router Alert Option is processed and (Section 5.2.1) to allow control over how it is processed and
that a node configured to support these options must protect describes how a node configured to support these options must
itself from attacks using the Router Alert Option. protect itself from attacks by using the Router Alert Option.
* The document sets an expectation that if a packet includes a Hop- * This document sets the expectation that if a packet includes a
by-Hop Options header that the packet will be forwarded across the Hop-by-Hop Options header, the packet will be forwarded across the
network path. network path.
* A source MAY include, based on local configuration, a single Hop- * A Source MAY include a single Hop-by-Hop option (based on local
by-Hop option or may be configured to include more Hop-by-Hop configuration) or MAY be configured to include more Hop-by-Hop
options. The configuration of intermediate nodes determines options. The configuration of intermediate nodes determines
whether a node processes any of these options, and, if so, which whether a node processes any of these options, and if so, which
and how many. ones 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 * This document adds guidance for the design of any future new Hop-
control plane. by-Hop option that reduces the computational requirements and
* Changed draft that only one Hop-by-Hop option MUST be processed encourages a limit to their size.
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. 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.
11. Normative References 9. Normative References
[IANA-HBH] "Destination Options and Hop-by-Hop Options", [IANA-HBH] IANA, "Destination Options and Hop-by-Hop Options",
<https://www.iana.org/assignments/ipv6-parameters/ <https://www.iana.org/assignments/ipv6-parameters/>.
ipv6-parameters.xhtml#ipv6-parameters-2>.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997, DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/info/rfc2119>. <https://www.rfc-editor.org/info/rfc2119>.
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
May 2017, <https://www.rfc-editor.org/info/rfc8174>. May 2017, <https://www.rfc-editor.org/info/rfc8174>.
[RFC8200] Deering, S. and R. Hinden, "Internet Protocol, Version 6 [RFC8200] Deering, S. and R. Hinden, "Internet Protocol, Version 6
(IPv6) Specification", STD 86, RFC 8200, (IPv6) Specification", STD 86, RFC 8200,
DOI 10.17487/RFC8200, July 2017, DOI 10.17487/RFC8200, July 2017,
<https://www.rfc-editor.org/info/rfc8200>. <https://www.rfc-editor.org/info/rfc8200>.
12. Informative References 10. Informative References
[Cus23a] Custura, A. and G. Fairhurst, "Internet Measurements: IPv6 [Cus23a] Custura, A. and G. Fairhurst, "Internet Measurements: IPv6
Extension Header Edition", IEPG, IETF-116 , March 2023, Extension Header Edition", IEPG Meeting: IETF 116, March
<http://www.iepg.org/2023-03-26-ietf116/eh.pdf>. 2023, <http://www.iepg.org/2023-03-26-ietf116/eh.pdf>.
[Cus23b] Custura, A., Secchi, R., Boswell, E., and G. Fairhurst, [Cus23b] Custura, A., Secchi, R., Boswell, E., and G. Fairhurst,
"Is it possible to extend IPv6?", Computer "Is it possible to extend IPv6?", Computer Communications,
Communications X, October 2023, vol. 214, pp. 90-99, DOI 10.1016/j.comcom.2023.10.006,
January 2024,
<https://www.sciencedirect.com/science/article/pii/ <https://www.sciencedirect.com/science/article/pii/
S0140366423003705>. S0140366423003705>.
[Hendriks] Hendriks, L., Velan, P., Schmidt, RO., Boer, P., and A. [HBH] Peng, S., Li, Z., Xie, C., Qin, Z., and G. S. Mishra,
Aiko, "Threats and Surprises behind IPv6 Extension
Headers", , August 2017,
<http://dl.ifip.org/db/conf/tma/tma2017/
tma2017_paper22.pdf>.
[I-D.ietf-taps-arch]
Pauly, T., Trammell, B., Brunstrom, A., Fairhurst, G., and
C. Perkins, "Architecture and Requirements for Transport
Services", Work in Progress, Internet-Draft, draft-ietf-
taps-arch-19, 9 November 2023,
<https://datatracker.ietf.org/doc/html/draft-ietf-taps-
arch-19>.
[I-D.ietf-v6ops-hbh]
Peng, S., Li, Z., Xie, C., Qin, Z., and G. S. Mishra,
"Operational Issues with Processing of the Hop-by-Hop "Operational Issues with Processing of the Hop-by-Hop
Options Header", Work in Progress, Internet-Draft, draft- Options Header", Work in Progress, Internet-Draft, draft-
ietf-v6ops-hbh-10, 16 February 2024, ietf-v6ops-hbh-10, 16 February 2024,
<https://datatracker.ietf.org/doc/html/draft-ietf-v6ops- <https://datatracker.ietf.org/doc/html/draft-ietf-v6ops-
hbh-10>. hbh-10>.
[IANA-RA] "IPv6 Router Alert Option Values", [Hendriks] Hendriks, L., Velan, P., Schmidt, RO., Boer, P., and A.
<https://www.iana.org/assignments/ipv6-routeralert-values/ Aiko, "Threats and Surprises behind IPv6 Extension
ipv6-routeralert-values>. Headers", 2017 Network Traffic Measurement and Analysis
Conference (TMA), DOI 10.23919/TMA.2017.8002912, August
2017, <http://dl.ifip.org/db/conf/tma/tma2017/
tma2017_paper22.pdf>.
[IANA-RA] IANA, "IPv6 Router Alert Option Values",
<https://www.iana.org/assignments/ipv6-routeralert-
values/>.
[RFC1883] Deering, S. and R. Hinden, "Internet Protocol, Version 6 [RFC1883] Deering, S. and R. Hinden, "Internet Protocol, Version 6
(IPv6) Specification", RFC 1883, DOI 10.17487/RFC1883, (IPv6) Specification", RFC 1883, DOI 10.17487/RFC1883,
December 1995, <https://www.rfc-editor.org/info/rfc1883>. December 1995, <https://www.rfc-editor.org/info/rfc1883>.
[RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6 [RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6
(IPv6) Specification", RFC 2460, DOI 10.17487/RFC2460, (IPv6) Specification", RFC 2460, DOI 10.17487/RFC2460,
December 1998, <https://www.rfc-editor.org/info/rfc2460>. December 1998, <https://www.rfc-editor.org/info/rfc2460>.
[RFC2711] Partridge, C. and A. Jackson, "IPv6 Router Alert Option", [RFC2711] Partridge, C. and A. Jackson, "IPv6 Router Alert Option",
skipping to change at page 22, line 39 skipping to change at line 792
[RFC9268] Hinden, R. and G. Fairhurst, "IPv6 Minimum Path MTU Hop- [RFC9268] Hinden, R. and G. Fairhurst, "IPv6 Minimum Path MTU Hop-
by-Hop Option", RFC 9268, DOI 10.17487/RFC9268, August by-Hop Option", RFC 9268, DOI 10.17487/RFC9268, August
2022, <https://www.rfc-editor.org/info/rfc9268>. 2022, <https://www.rfc-editor.org/info/rfc9268>.
[RFC9288] Gont, F. and W. Liu, "Recommendations on the Filtering of [RFC9288] Gont, F. and W. Liu, "Recommendations on the Filtering of
IPv6 Packets Containing IPv6 Extension Headers at Transit IPv6 Packets Containing IPv6 Extension Headers at Transit
Routers", RFC 9288, DOI 10.17487/RFC9288, August 2022, Routers", RFC 9288, DOI 10.17487/RFC9288, August 2022,
<https://www.rfc-editor.org/info/rfc9288>. <https://www.rfc-editor.org/info/rfc9288>.
[Tram17] Trammell, B., Kuehlewind, M., De Vaere, P., Learmonth, [TAPS-ARCH]
IR., and G. Fairhurst, "Tracking Transport-Layer Evolution Pauly, T., Ed., Trammell, B., Ed., Brunstrom, A.,
with PATH Spider", ANRW , July 2017, Fairhurst, G., and C. Perkins, "Architecture and
Requirements for Transport Services", Work in Progress,
Internet-Draft, draft-ietf-taps-arch-19, 9 November 2023,
<https://datatracker.ietf.org/doc/html/draft-ietf-taps-
arch-19>.
[Tram17] Trammell, B., Kühlewind, M., De Vaere, P., Learmonth, I.,
and G. Fairhurst, "Tracking Transport-Layer Evolution with
PATHspider", ANRW '17: Proceedings of the 2017 Applied
Networking Research Workshop, DOI 10.1145/3106328.3106336,
July 2017,
<https://irtf.org/anrw/2017/anrw17-final16.pdf>. <https://irtf.org/anrw/2017/anrw17-final16.pdf>.
Acknowledgments
Helpful comments were received from 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 other members of the 6MAN Working Group.
Authors' Addresses Authors' Addresses
Robert M. Hinden Robert M. Hinden
Check Point Software Check Point Software
959 Skyway Road 100 Oracle Parkway, Suite 800
San Carlos, CA 94070 Redwood City, CA 94065
United States of America United States of America
Email: bob.hinden@gmail.com Email: bob.hinden@gmail.com
Godred Fairhurst Godred Fairhurst
University of Aberdeen University of Aberdeen
School of Engineering School of Engineering
Fraser Noble Building Fraser Noble Building
Aberdeen Aberdeen
AB24 3UE AB24 3UE
United Kingdom United Kingdom
Email: gorry@erg.abdn.ac.uk Email: gorry@erg.abdn.ac.uk
 End of changes. 115 change blocks. 
580 lines changed or deleted 391 lines changed or added

This html diff was produced by rfcdiff 1.48.