rfc9673v3.txt   rfc9673.txt 
skipping to change at line 101 skipping to change at line 101
"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 "OPTIONAL" in this document are to be interpreted as described in
BCP 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 the Control Plane: IPv6 routers exchange control information through 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 forwarding Fast Path: A path through a router that is optimized for forwarding
packets. The fast path might be supported by Application-Specific packets. The Fast Path might be supported by Application-Specific
Integrated Circuits (ASICs), a Network Processor (NP), or other Integrated Circuits (ASICs), a Network Processor (NP), or other
special purpose hardware. This is the typical processing path special purpose hardware. This is the typical processing path
within a router taken by the forwarding plane. within a router taken by the Forwarding 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 that differ from assumptions made in fast special processing or that differ from assumptions made in Fast
path 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: The rate at which a router can forward packets Full Forwarding Rate: The rate at which a router can forward packets
without adversely impacting the aggregate forwarding rate. For without adversely impacting the aggregate forwarding rate. For
example, a router could process packets with Hop-by-Hop options at 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 a rate that allows it to maintain the full speed on its 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 early versions of the IPv6 protocol specification [RFC1883] 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 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 to be expected that high-performance routers will either ignore it or
assign packets containing it to a slow processing path". The reasons assign packets containing it to a slow processing path". The reasons
behind this include the following: behind this include the following:
* The 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 (DoS) attack against the be exploited as a Denial-of-Service (DoS) attack against the
router. 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,
it 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
skipping to change at line 215 skipping to change at line 215
was 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 protocol specification as an IETF constraint on publishing the IPv6 protocol specification as an IETF
Standard. 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 require processing by a processor that by-Hop Options that require processing by a processor that
implements the control plane. This could be done to protect implements the Control Plane. This could be done to protect
against a DoS attack on the router [RFC9098] [RFC9288]. against a DoS attack on the router [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 Autonomous Systems (ASes) for packets that include rate in transit Autonomous Systems (ASes) for packets that include
Hop-by-Hop options [RFC7872]. The operational implications of Hop-by-Hop options [RFC7872]. The operational implications of
IPv6 packets that include Extension Headers are discussed in IPv6 packets that include Extension Headers are discussed in
[RFC9098]. Measurements taken in 2023 confirm this to still be [RFC9098]. Measurements taken in 2023 confirm this to still be
the case for many types of network paths [Cus23b]. the case for many types of network paths [Cus23b].
skipping to change at line 241 skipping to change at line 241
* 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 in some designs can 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 of a router locating all the header bytes required the probability of a router locating all the header bytes required
to successfully process an access control list operating on fields to successfully process an access control list operating 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
DoS attack on a transit router by saturating the resources needed DoS attack on a transit router by saturating the resources needed
for router management protocols (routing protocols, network for router management protocols (routing protocols, network
management protocols, etc.), which could cause adverse router management protocols, etc.), which could cause adverse router
operation. This is an issue for the Router Alert Option operation. This is an issue for the Router Alert Option
[RFC2711], which intentionally forwards packets to the control [RFC2711], which intentionally forwards packets to the Control
plane as discussed in [RFC6398]. This impact could be mitigated Plane as discussed in [RFC6398]. This impact could be mitigated
by limiting the use of control plane resources by a specific by limiting the use of Control Plane resources by a specific
packet and/or by using per-function rate-limiters for packets packet and/or by using per-function rate-limiters for packets
processed by the control plane. processed by the Control Plane.
Section 3 of [RFC6398] 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 that contain Extension Headers is a bad "Dropping all packets that contain Extension Headers is a bad
practice" and that "The share of traffic containing more than one EH practice" and that "The share of traffic containing more than one EH
however, is very small. For the design of hardware able to handle however, is very small. For the design of hardware able to handle
the dynamic nature of EHs, we therefore recommend to support at least the dynamic nature of EHs, we therefore recommend to support at least
one EH". Operational aspects of the topics discussed in this section one EH". Operational aspects of the topics discussed in this section
skipping to change at line 356 skipping to change at line 356
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 process any of the option of the Hop-by-Hop Options header does not process any of the Option
types contained in the Hop-by-Hop Options header. Types contained in the Hop-by-Hop Options header.
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 it could allow one Hop-by-Hop option to be included in a packet, or it could allow
more than one Hop-by-Hop option 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 Options 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 the full forwarding it cannot process the first Hop-by-Hop option at the Full Forwarding
rate. Therefore, a router SHOULD NOT 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 same way specified not configured to do so), it SHOULD behave in the same way specified
for an unrecognized Option Type when the action bits are set to "00", for an unrecognized Option Type when the action bits are set to "00",
and it SHOULD skip the remaining options using the "Hdr Ext Len" and it SHOULD skip the remaining options using the "Hdr Ext Len"
field in the Hop-by-Hop Options header. This field specifies the field in the Hop-by-Hop Options header. This field specifies the
length of the Options Header in 8-octet units. After skipping an length of the Options Header in 8-octet units. After skipping an
option, the router continues processing the remaining options in the option, the router continues processing the remaining options in the
header. 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, which is usually done in the control plane; see processing, which is usually done in the Control Plane; see
Section 5.2.1. 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 ICMP packet's Destination Address was a multicast address,
Parameter Problem, Code 2, message to the packet's Source Address, send an ICMP Parameter Problem, Code 2, message to the
pointing to the unrecognized Option Type. packet's Source Address, pointing to the unrecognized
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 ICMP Parameter Address was not a multicast address, send an ICMP Parameter
Problem, Code 2, message to the packet's Source Address, pointing Problem, Code 2, message to the packet's Source Address,
to the unrecognized Option Type. pointing to the unrecognized Option Type.
This document modifies this behavior 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 same way specified for an unrecognized Option Type when the the same way specified for an unrecognized Option Type when the
action bits are set to "00". It also modifies the behavior for action bits are set to "00". It also modifies the behavior for
values "10" and "11" in the case where the packet is discarded and values "10" and "11" in the case where the packet is discarded and
the node MAY send an ICMP Parameter Problem, Code 2 [RFC4443], the node MAY send an ICMP Parameter Problem, Code 2 [RFC4443],
message to the packet's Source Address, pointing to the unrecognized message to the packet's Source Address, pointing to the unrecognized
Option Type. Option Type.
The modified text for values "01", "10", and "11" 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, regardless of 10 - MAY discard the packet, if so configured, regardless of
whether or not the packet's Destination Address was a multicast whether or not the packet's Destination Address was a
address. If the packet was discarded, an ICMP Parameter Problem, multicast address. If the packet was discarded, an ICMP
Code 2, message MAY be sent to the packet's Source Address, Parameter Problem, Code 2, message MAY be sent to the
pointing to the unrecognized Option Type. packet's Source Address, pointing to the unrecognized
Option Type.
11 - MAY discard the packet, if so configured. If the packet was 11 - MAY discard the packet, if so configured. If the packet
discarded and the packet's Destination Address was not a multicast was discarded and the packet's Destination Address was
address, an ICMP Parameter Problem, Code 2, message MAY be sent to not a multicast address, an ICMP Parameter Problem,
the packet's Source Address, pointing to the unrecognized Option Code 2, message MAY be sent to the packet's Source
Type. Address, 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 "IPv6 Router Alert Option specified values can be found in the "IPv6 Router Alert Option
Values" IANA registry [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, that this specification is proposing to eliminate, that is,
instructing a router to process the packet in the control plane. instructing a router to process the packet in the Control Plane.
This processing causes concerns, which are discussed in Section 4. This processing causes concerns, which are discussed in Section 4.
One approach would be to deprecate this, because current usage One approach would be to deprecate this, because current usage
beyond the local network appears to be limited, and packets beyond the local network appears to be limited, and packets
containing Hop-by-Hop options are frequently dropped. Deprecation containing Hop-by-Hop options are frequently dropped. Deprecation
would allow current implementations to continue, and its use could would allow current implementations to continue, and its use could
be phased out over time. be phased out over time.
The Router Alert Option could potentially be used 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 restrictions that follow 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 '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 an 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 access 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 the Option Type for As specified in [RFC2711], the top two bits of the Option Type for
the Router Alert Option are always set to "00", indicating that the the Router Alert Option are always set to "00", indicating that the
node should skip over this option as if it does not recognize the node should skip over this option as if it does not recognize the
Option Type and continue processing the header. An implementation Option Type and continue processing the header. An implementation
that does recognize the Router Alert Option SHOULD verify that the that does recognize the Router Alert Option SHOULD verify that the
Router Alert Option contains a protocol, as indicated by the Value Router Alert Option contains a protocol, as indicated by the Value
field in the Router Alert Option, that is configured as a protocol of field in the Router Alert Option, that is configured as a protocol of
interest to that router. A verified packet SHOULD be sent to the interest to that router. A verified packet SHOULD be sent to the
control plane for further processing [RFC6398]. Otherwise, the Control Plane for further processing [RFC6398]. Otherwise, the
router implementation SHOULD forward this packet subject to all router implementation SHOULD forward this packet subject to all
normal policies and forwarding rules. normal policies and forwarding rules.
5.2.2. Configuration of Hop-by-Hop Options 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 an Option Type of the IPv6 options that can be table based on an Option Type of the IPv6 options that can be
processed at the full forwarding rate. This would allow a router to processed at the Full Forwarding Rate. This would allow a router to
quickly determine if an option is supported and can be processed. If quickly determine if an option is supported and can be processed. If
the 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 future new IPv6 Hop-by-Hop options should be designed to be Any future new IPv6 Hop-by-Hop options should be designed to be
processed at the full forwarding rate and should have the following processed at the Full Forwarding Rate and 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 Hop-by-Hop options should be defined with the Action type * New Hop-by-Hop options should be defined with the Action type
(highest-order 2 bits of the Option Type) set to "00", which (highest-order 2 bits of the Option Type) set to "00", which
enables skipping over this option and continuing with the enables skipping over this option and continuing with the
processing of the header if a router does not recognize the processing of the header if a router does not recognize the
option. option.
* The size of Hop-by-Hop options 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 the full forwarding rate. A larger be expected to be executed at the Full Forwarding Rate. A larger
Hop-by-Hop Options header can increase the likelihood 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 with the expectation * New Hop-by-Hop options should be designed with the expectation
that a router might be configured to only process a subset of Hop- 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 by-Hop options (e.g., the first option) in the Hop-by-Hop Options
header. 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.
If a new Hop-by-Hop option does not meet these criteria, its If a new Hop-by-Hop option does not meet these criteria, its
specification must include a detailed explanation why that is the specification must include a detailed explanation why that is the
case and show that there is a reasonable expectation that the option case and show that there is a reasonable expectation that the option
can still proceed at the full forwarding rate. This is consistent can still proceed at the Full Forwarding Rate. This is consistent
with [RFC6564]. 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. 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
skipping to change at line 576 skipping to change at line 578
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 are implement a specific Hop-by-Hop option (e.g., [RFC9268]) and that are
robust when the current path drops packets that contain a Hop-by-Hop robust when the current path drops packets that contain a Hop-by-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
skipping to change at line 615 skipping to change at line 617
added this document as an additional reference for the "Destination added this document as an additional reference for the "Destination
Options and Hop-by-Hop Options" registry in the "Internet Protocol Options and Hop-by-Hop Options" registry in the "Internet Protocol
Version 6 (IPv6) Parameters" registry group [IANA-HBH]. Version 6 (IPv6) Parameters" registry group [IANA-HBH].
8. Security Considerations 8. Security Considerations
Security issues caused by including IPv6 Hop-by-Hop options are well Security issues caused by including IPv6 Hop-by-Hop options are well
known and have been documented in several places, including known and have been documented in several places, including
[RFC6398], [RFC6192], [RFC7045], and [RFC9098]. The main issue, as [RFC6398], [RFC6192], [RFC7045], and [RFC9098]. The main issue, as
noted in Section 4, is that any mechanism that can be used to force 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 packets into the router's Control Plane or Slow Path can be exploited
as a DoS attack on a router by saturating the resources needed for as a DoS attack on a router by saturating the resources needed for
router management (routing protocols, network management protocols, router management (routing protocols, network management protocols,
etc.), and this can cause the router to fail or perform suboptimally. etc.), and this can cause the router to fail or perform suboptimally.
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 DoS mitigation, firewall/access control, are nodes that provide DoS mitigation, firewall/access control,
traffic engineering, or traffic normalization. These nodes could be traffic engineering, or traffic normalization. These nodes could be
configured to drop packets when they are unable to access and process configured to drop packets when they are unable to access and process
all Extension Headers or are unable to locate and process the higher- all Extension Headers or are unable to locate and process the higher-
layer packet information. This document provides guidance on the layer packet information. This document provides guidance on the
requirements concerning Hop-by-Hop options. requirements concerning Hop-by-Hop options.
skipping to change at line 649 skipping to change at line 651
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 how the Hop-by-Hop Options header is processed, This document changes how the Hop-by-Hop Options header is processed,
which significantly reduces the attack surface. These changes which significantly reduces the attack surface. These changes
include the following: 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 the full forwarding when it cannot process a Hop-by-Hop option at the Full Forwarding
rate; therefore, it SHOULD NOT be configured to process the Hop- Rate; therefore, it SHOULD NOT be configured to process the Hop-
by-Hop option if it adversely impacts the aggregate forwarding by-Hop option if it adversely impacts the aggregate forwarding
rate. Instead, it SHOULD behave in the same way specified for an rate. Instead, it SHOULD behave in the same way specified for an
unrecognized Option Type when the action bits are set to "00", as unrecognized Option Type when the action bits are set to "00", as
specified in Section 5.2. specified in Section 5.2.
* This document adds criteria for the Router Alert Option * This document adds criteria for the Router Alert Option
(Section 5.2.1) to allow control over how it is processed and (Section 5.2.1) to allow control over how it is processed and
describes how a node configured to support these options must describes how a node configured to support these options must
protect itself from attacks by using the Router Alert Option. protect itself from attacks by using the Router Alert Option.
* This document sets the expectation that if a packet includes a * This document sets the expectation that if a packet includes a
Hop-by-Hop Options header, 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 a single Hop-by-Hop option (based on local * A Source MAY include a single Hop-by-Hop option (based on local
configuration) 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
ones and how many. ones and how many.
* This document adds guidance for the design of any future new Hop- * This document adds guidance for the design of any future new Hop-
by-Hop option that reduces the computational requirements and by-Hop option that reduces the computational requirements and
encourages a limit to their size. encourages a limit to their size.
The intent of this document is to highlight that these changes The intent of this document is to highlight that these changes
 End of changes. 41 change blocks. 
64 lines changed or deleted 66 lines changed or added

This html diff was produced by rfcdiff 1.48.