Internet DRAFT - draft-ietf-6man-hbh-processing
draft-ietf-6man-hbh-processing
Network Working Group R. Hinden
Internet-Draft Check Point Software
Updates: 8200 (if approved) G. Fairhurst
Intended status: Standards Track University of Aberdeen
Expires: 28 August 2024 25 February 2024
IPv6 Hop-by-Hop Options Processing Procedures
draft-ietf-6man-hbh-processing-14
Abstract
This document specifies procedures for how IPv6 Hop-by-Hop options
are processed in IPv6 routers and hosts. It modifies the procedures
specified in the IPv6 Protocol Specification (RFC8200) to make
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
the Internet. When published, this document updates RFC8200.
Status of This Memo
This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
This Internet-Draft will expire on 28 August 2024.
Copyright Notice
Copyright (c) 2024 IETF Trust and the persons identified as the
document authors. All rights reserved.
Hinden & Fairhurst Expires 28 August 2024 [Page 1]
Internet-Draft HBH Options Processing February 2024
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents (https://trustee.ietf.org/
license-info) in effect on the date of publication of this document.
Please review these documents carefully, as they describe your rights
and restrictions with respect to this document. Code Components
extracted from this document must include Revised BSD License text as
described in Section 4.e of the Trust Legal Provisions and are
provided without warranty as described in the Revised BSD License.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Requirements Language . . . . . . . . . . . . . . . . . . . . 3
3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3
4. Background . . . . . . . . . . . . . . . . . . . . . . . . . 4
5. Hop-by-Hop Header Processing Procedures . . . . . . . . . . . 7
5.1. Processing the Extension Header Carrying Hop-by-Hop
Options . . . . . . . . . . . . . . . . . . . . . . . . . 7
5.1.1. Configuration Enabling Hop-by-Hop Header
Processing . . . . . . . . . . . . . . . . . . . . . 8
5.2. Hop-by-Hop Options Processing . . . . . . . . . . . . . . 8
5.2.1. Router Alert Option . . . . . . . . . . . . . . . . . 10
5.2.2. Configuration of Hop-by-Hop Option Processing . . . . 11
6. Defining New Hop-by-Hop Options . . . . . . . . . . . . . . . 12
6.1. Example of Robust Usage . . . . . . . . . . . . . . . . . 13
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13
8. Security Considerations . . . . . . . . . . . . . . . . . . . 14
9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 15
10. Change log [RFC Editor: Please remove] . . . . . . . . . . . 15
11. Normative References . . . . . . . . . . . . . . . . . . . . 18
12. Informative References . . . . . . . . . . . . . . . . . . . 19
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 21
1. Introduction
This document specifies procedures for processing IPv6 Hop-by-Hop
options in IPv6 routers and hosts. It modifies the procedures
specified in the IPv6 Protocol Specification [RFC8200] to make
processing of IPv6 Hop-by-Hop Options header practical with the goal
of making IPv6 Hop-by-Hop options useful to deploy and use at IPv6
routers and hosts.
The current list of defined Hop-by-Hop options can be found at
[IANA-HBH]. The focus for this document is to set the minimum
requirements for router processing of Hop-by-Hop options. This
document does not discuss a bound to the number of Hop-by-Hop options
that ought to be processed. That topic is discussed in
[I-D.ietf-6man-eh-limits].
Hinden & Fairhurst Expires 28 August 2024 [Page 2]
Internet-Draft HBH Options Processing February 2024
When published, this document updates [RFC8200].
2. Requirements Language
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described in BCP
14 [RFC2119] [RFC8174] when, and only when, they appear in all
capitals, as shown here.
3. Terminology
This document uses the following loosely defined terms:
* Forwarding Plane: IPv6 routers exchange user data through the
forwarding plane. Routers process fields contained in packet
headers. However, they do not process information contained in
packet payloads.
* Control Plane: IPv6 routers exchange management and routing
information with one another. Management and routing information
is processed by its recipient. Management and control information
can be forwarded by a router that process fields contained in
packet headers.
* Fast Path: A path through a router that is optimized for
forwarding packets. The Fast Path might be supported by
Application Specific Integrated Circuits (ASICs), a Network
Processor (NP), or other special purpose hardware. This is the
usual processing path within a router taken by the forwarding
plane.
* Slow Path: A path through a router that is capable of general
purpose processing and is not optimized for any particular
function. This processing path is used for packets that require
special processing or differ from assumptions made in Fast Path
heuristics or to process router control protocols used by the
control plane.
* Full Forwarding Rate: This is the rate that a router can forward
packets without adversely impacting the aggregate forwarding rate.
For example, a router could process packets with Hop-by-Hop
options at a rate that allows it to maintain the full speed on its
outgoing interfaces, which is sometimes called "wire speed".
* Source: The node originating the packet.
Hinden & Fairhurst Expires 28 August 2024 [Page 3]
Internet-Draft HBH Options Processing February 2024
NOTE: [RFC6192] is an example of how designs can separate control
plane and forwarding plane functions. The separation between
hardware and software processing described in [RFC6398] does not
apply to all router architectures. However, a router that performs
all or most processing in software might still incur more processing
cost when providing special processing for Hop-by-Hop options.
4. Background
In the first versions of the IPv6 specification [RFC1883] and
[RFC2460], Hop-by-Hop options were required to be processed by all
nodes: routers and hosts. This proved to not be practical in current
high speed routers, as observed in Section 2.2 of RFC7045: "it is to
be expected that high-performance routers will either ignore it or
assign packets containing it to a slow processing path". The reason
behind this includes:
* Inability to process Hop-by-Hop options at the full forwarding
rate can result in issues. In some cases, Hop-by-Hop options
would be sent to the control/management components that run on the
slow path. This could degrade a router's performance and also its
ability to process critical control traffic. Both of which could
be exploited as a Denial of Service attack against the router.
* If a subset of packets in a flow were to include Hop-by-Hop
options, this could introduce a potential for packets to be
delivered out of order to the destination. This might result when
the Extension Header was included in only some packets, or if a
specific Hop-by-Hop option required different processing for some
packets in a flow. Significant reordering of the packets
belonging to a flow can impact the performance of upper layer
protocols and needs to be avoided.
* Packets could include multiple Hop-by-Hop options. Too many
options could make the previous issues worse by increasing the
resources required to process them. The total size of the options
determines the number of header bytes that might need to be
processed. Measurements [Cus23a] show that the probability of
successful transmission is currently higher for packets that
include Options when it results in a short total EH Chain size
(e.g., less than 40B).
[RFC6564] specified a uniform format for new IPv6 Extension Headers.
It updated [RFC2460] and this update was incorporated into
Section 4.8 of [RFC8200].
Hinden & Fairhurst Expires 28 August 2024 [Page 4]
Internet-Draft HBH Options Processing February 2024
When the IPv6 Specification was updated and published in July 2017 as
[RFC8200], the procedures relating to Hop-by-Hop options were
specified ([RFC8200], Section 4) as follows:
The Hop-by-Hop Options header is not inserted or deleted, but may
be examined or processed by any node along a packet's delivery
path, until the packet reaches the node (or each of the set of
nodes, in the case of multicast) identified in the Destination
Address field of the IPv6 header. The Hop-by-Hop Options header,
when present, must immediately follow the IPv6 header. Its
presence is indicated by the value zero in the Next Header field
of the IPv6 header.
NOTE: While [RFC2460] required that all nodes must examine and
process the Hop-by-Hop Options header, it is now expected that
nodes along a packet's delivery path only examine and process the
Hop-by-Hop Options header if explicitly configured to do so.
The changes meant that an implementation complied with the IPv6
specification even if it did not process Hop-by-Hop options, and that
it was expected that routers would add configuration information to
control whether they process the Hop-by-Hop Options header. In
practice, routers may include configuration options to control which
Hop-by-Hop options they will process.
The text regarding processing of Hop-by-Hop options in [RFC8200] was
not intended to change the processing of these options. It
documented how they were being used in the Internet at the time
RFC8200 was published (see Appendix B of [RFC8200]). This was a
constraint on publishing the IPv6 specification as an IETF Standard.
The main issues remain:
* Routers can be configured to drop transit packets containing Hop-
by-Hop Options that would have required processing by a processor
that implements the Control Plane. This could protect against a
Denial of Service attack on the router [RFC9098].
* IPv6 Packets that include a Hop-by-Hop Options header are dropped
by some Internet paths. A survey in 2015 reported a high loss
rate in transit ASs for packets with Hop-by-Hop options [RFC7872].
The operational implications of IPv6 Packets that include
Extension Headers are discussed in [RFC9098]. Measurements in
2023 confirm to still be the case for many types network path
[Cus23b].
Hinden & Fairhurst Expires 28 August 2024 [Page 5]
Internet-Draft HBH Options Processing February 2024
* Allowing multiple Hop-by-Hop options in a single packet in some
cases consumes more router resources to process these packets. It
also adds complexity to the number of permutations that might need
to be processed/configured.
* Including larger or multiple Hop-by-Hop options in a Hop-by-Hop
Options header increases the number of bytes that need to be
processed in forwarding, which can in some designs impact the cost
of processing a packet, and in turn could increase the probability
of drop [RFC7872]. A larger Extension Header could also reduce
the probability that a router can locate all the header bytes
required to successfully process an access control list operating
on fields after the Hop-by-Hop Options header.
* Any option that can be used to force packets into the the
processor that implements the router's Control Plane can be
exploited as a Denial of Service attack on a transit router by
saturating the resources needed for router management protocols
(e.g., routing protocols, network management protocols, etc.) that
could cause adversely impact router operation. This is an issue
for the Router Alert option, which intentionally forward packets
to the Control Plane, and is discussed in [RFC6398]. This impact
could be mitigated by limiting the use of control plane resources
by a specific packet, and/or by the use of per-function rate-
limiters for packets processed by the control plane.
Section 3 of RFC 6398 includes a summary of processing the IP Router
Alert option:
"In a nutshell, the IP Router Alert option does not provide a
convenient universal mechanism to accurately and reliably
distinguish between IP Router Alert packets of interest and
unwanted IP Router Alert packets. This, in turn, creates a
security concern when the IP Router Alert option is used, because,
short of appropriate router-implementation-specific mechanisms,
the router Slow Path is at risk of being flooded by unwanted
traffic."
This is an example of the need to limit the resources that can be
consumed when a particular function is executed and to avoid
consuming control-plane resources where support for a function has
not been configured.
There has been research that has discussed the general problem with
dropping packets containing IPv6 Extension Headers, including the
Hop-by-Hop Options header. For example, [Hendriks] states that
"dropping all packets with Extension Headers, is a bad practice", and
that "The share of traffic containing more than one EH however, is
Hinden & Fairhurst Expires 28 August 2024 [Page 6]
Internet-Draft HBH Options Processing February 2024
very small. For the design of hardware able to handle the dynamic
nature of Extension Headers we therefore recommend to support at
least one EH". Operational aspects of the topics discussed in this
section are further discussed in [I-D.ietf-v6ops-hbh].
"Transmission and Processing of IPv6 Extension Headers" [RFC7045]
clarified how intermediate nodes should process Extension Headers.
This document is generally consistent with [RFC7045], and was raised
as an issue for discussion when [RFC2460] was updated and was
replaced by [RFC8200]. This document updates [RFC8200] as described
in the next section and consequently clarifies the description in
Section 2.2 of [RFC7045], using the language of BCP 14 [RFC2119]
[RFC8174].
The document defines a set of procedures for the Hop-by-Hop Options
header that are intended to make the processing of Hop-by-Hop options
practical in modern transit routers. The common cases are that some
Hop-by-Hop options will be processed across the Internet, while
others will only be processed within a limited domain [RFC8799]
(e.g., where a specific service is made available in that network
segment that relies on one or more Hop-by-Hop options).
5. Hop-by-Hop Header Processing Procedures
This section describes several changes to [RFC8200]. Section 5.1
describes processing of the Hop-by-Hop option Extension Header, and
Section 5.2 describes processing of individual 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
field of the IPv6 Header does not identify the transport protocol.
The Extension Header used to carry Hop-by-Hop options is defined in
Section 4.3 of [RFC8200] and is identified by a Next Header value of
0 in the IPv6 header. Section 4.1 of [RFC8200] requires this Hop-by-
Hop Options header to appear immediately after the IPv6 header.
[RFC8200] also requires that a Hop-by-Hop Options header can only
appear once in a packet.
The Hop-by-Hop Options Header as defined in [RFC8200] can contain one
or more Hop-by-Hop options.
Routers SHOULD process the Hop-by-Hop Options header using the method
defined in this document. If a router does not process the Hop-by-
Hop Options header, it MUST forward the packet normally based on the
remaining Extension Header after the Hop-by-Hop Option header (i.e.,
a router MUST NOT drop a packet solely because it contains an
Hinden & Fairhurst Expires 28 August 2024 [Page 7]
Internet-Draft HBH Options Processing February 2024
Extension Header carrying Hop-by-Hop options). A configuration could
control that normal processing skips any or all of the Hop-by-Hop
options carried in the Hop-by-Hop Options header.
It is expected that the Hop-by-Hop Options header will be processed
by the Destination. Hosts SHOULD process the Hop-by-Hop Options
header in received packets. A constrained host is an example of a
node that does not process Hop-by-Hop Options header. If a
Destination does not process the Hop-by-Hop Options header, it MUST
process the remainder of the packet normally. Further details on
requirements for host processing are described in
[I-D.ietf-6man-eh-limits].
5.1.1. Configuration Enabling Hop-by-Hop Header Processing
Section 4 of [RFC8200] allows a router to control its processing of
IPv6 Hop-by-Hop options by local configuration. The text is:
NOTE: While [RFC2460] required that all nodes must examine and
process the Hop-by-Hop Options header, it is now expected that
nodes along the path only examine and process the Hop-by-Hop
Options header if explicitly configured to do so.
This document clarifies that a configuration could control whether
processing skips any specific Hop-by-Hop options carried in the Hop-
by-Hop Options header. A router that does not process the contents
of the Hop-by-Hop Options header does not therefore process the
identifiers of individual Option Types to perform any specified
action.
5.2. Hop-by-Hop Options Processing
A Source creating packets with a Hop-by-Hop Options header SHOULD use
a method that is robust to network nodes processing only the first
Hop-by-Hop option that is included in the packet, or that forward
packets without the option being processed (see Section 6.1). A
Source MAY, based on local configuration, include more than one Hop-
by-Hop option [I-D.ietf-6man-eh-limits], but might wish to restrict
the size to increase the likelihood of successful transfer across a
network path. Because some routers might only process a limited
number of options in the Hop-by-Hop Option header, sources are
motivated to order the placement of Hop-by-Hop options within the
Hop-by-Hop Options header in decreasing order of importance for their
processing by nodes on the path.
A router configuration needs to avoid vulnerabilities that arise when
it cannot process the first Hop-by-Hop option at full forwarding
rate. A router SHOULD NOT therefore be configured to process the
Hinden & Fairhurst Expires 28 August 2024 [Page 8]
Internet-Draft HBH Options Processing February 2024
first Hop-by-Hop option if this adversely impacts the aggregate
forwarding rate. If configured to do so, a router SHOULD process
additional Hop-by-Hop options providing that these also do not
adversely impact the aggregate forwarding rate.
If a router is unable to process any Hop-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 bits were set to "00".
If a router is unable to process further Hop-by-Hop options (or is
not configured to do so), the router SHOULD skip the remaining
options using the "Hdr Ext Len" field in the Hop-by-Hop Options
header. This field specifies the length of the Option Header in
8-octet units. After skipping an option, the router continues
processing the remaining options in the header. Skipped options do
not need to be verified.
The Router Alert option [RFC2711] is an exception that can result in
processing in the Control Plane, see Section 5.2.1.
Section 4.2 of [RFC8200] defines the Option Type identifiers as
internally encoded such that their highest-order 2 bits specify the
action that must be taken if the processing IPv6 node does not
recognize the Option Type. The text is:
00 - skip over this option and continue processing the header.
01 - discard the packet.
10 - discard the packet and, regardless of whether or not the
packet's Destination Address was a multicast address, send an
ICMPv6 Parameter Problem, Code 2, message to the packet's
Source Address, pointing to the unrecognized Option Type.
11 - discard the packet and, only if the packet's Destination
Address was not a multicast address, send an ICMPv6 Parameter
Problem, Code 2, message to the packet's Source Address,
pointing to the unrecognized Option Type.
This document modifies this behaviour for the "01", "10", and "11"
action bits, so that if a router is unable to process any Hop-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 bits were
set to "00". It also modifies the behaviour for the "10" and "11"
values such if the packet is discarded the node MAY send an ICMP
Parameter Problem, Code 2, message to the packet's Source Address,
pointing to the unrecognized Option Type.
Hinden & Fairhurst Expires 28 August 2024 [Page 9]
Internet-Draft HBH Options Processing February 2024
The modified text for "01", "10", and "11" values is:
01 - MAY discard the packet. Nodes should not rely on routers
dropping these unrecognized Option Types.
10 - MAY discard the packet and, regardless of whether or not the
packet's Destination Address was a multicast address, and if
the packet was discarded MAY send an ICMP Parameter Problem,
Code 2, message to the packet's Source Address, pointing to
the unrecognized Option Type.
11 - MAY discard the packet and, only if the packet's Destination
Address was not a multicast address and the packet was
discarded, MAY send an ICMP Parameter Problem, Code 2,
message to the packet's Source Address, pointing to the
unrecognized Option Type.
When a node sends an ICMP message in response to a multicast packet,
this could be exploited as an amplification attack. This is
particularly problematic when the source address is not valid (which
can be mitigated when using a reverse path forwarding (RPF) check).
A node SHOULD only send ICMP messages in response to a multicast
address when this is enabled for the specific source and/or the group
destination address.
When an ICMP Parameter Problem, Code 2, message is delivered to the
source, the source can become aware that at least one node on the
path has failed to recognize the option. Generating an ICMP message
incurs additional router processing. Reception of this message is
not guaranteed, routers might be unable to be configured so that they
do not generate these messages, and they are not always forwarded to
the Source. The motivation here is to loosen the requirement to send
an ICMPv6 Parameter Problem message when a router forwards a packet
without processing the list of all options.
5.2.1. Router Alert Option
The purpose of the Router Alert option [RFC2711] is to tell a router
that the packet needs additional processing in the Control Plane.
The Router Alert option includes a two-octet Value field that
describes the protocol that is carried in the packet. The current
specified values can be found in the IANA Router Alert Value registry
[IANA-RA].
DISCUSSION
Hinden & Fairhurst Expires 28 August 2024 [Page 10]
Internet-Draft HBH Options Processing February 2024
The function of a Router Alert option results in the processing
that this specification is proposing to eliminate, that is, to
instruct a router to process the packet in the Control Plane. The
function of a Router Alert option is an instruction to a router to
process the packet in the Control Plane that results in the
concerns discussed in section 4. One approach would be to
deprecate this, because current usage beyond the local network
appears to be limited, and packets containing Hop-by-Hop options
are frequently dropped. Deprecation would allow current
implementations to continue and its use could be phased out over
time.
The Router Alert option could have a potential for use with new
functions that have to be processed in the Control Plane. Keeping
this as the single exception for processing in the Control Plane
with the following restrictions is a reasonable compromise to
allow future flexibility. These are compatible with Section 5 of
[RFC6398].
Implementations of the IP Router Alert option SHOULD offer the
configuration option to simply ignore the presence of "IP Router
Alert" in IPv4 and IPv6 packets" [RFC6398].
A node that is configured to process a Router Alert option MUST
protect itself from infrastructure attack that could result from
processing in the Control Plane. This might include some combination
of an access control list to only permit this from trusted nodes,
rate limiting of processing, or other methods [RFC6398].
As specified in [RFC2711] the top two bits of Option Type for the
Router Alert option are always set to "00" indicating the node should
skip over this option as if it does not recognize the Option Type and
continue processing the header. An implementation SHOULD verify that
a Router Alert option contains a protocol, as indicated by the Value
field in the Router Alert option, that is configured as a protocol of
interest to that router. A verified packet SHOULD be sent to the
Control Plane for further processing [RFC6398]. Otherwise, the
router implementation SHOULD forward this packet subject to all
normal policies and forwarding rules).
5.2.2. Configuration of Hop-by-Hop Option Processing
A router can be configured to process a specific Option. The set of
enabled options SHOULD be configurable by the operator of the router.
A possible approach to implementing this is to maintain a lookup
table based on Option Type of the IPv6 options that can be processed
at full forwarding rate. This would allow a router to quickly
Hinden & Fairhurst Expires 28 August 2024 [Page 11]
Internet-Draft HBH Options Processing February 2024
determine if an option is supported and can be processed. If the
option is not supported, then the router processes the option as
described inSection 5.1 of this document.
The actions of the lookup table SHOULD be configurable by the
operator of the router.
6. Defining New Hop-by-Hop Options
This section updates Section 4.8 of [RFC8200].
Any new IPv6 Hop-by-Hop option designed in the future should be
designed to be processed at full forwarding rate. New Hop-by-Hop
options should have the following characteristics:
* New Hop-by-Hop options SHOULD be designed to ensure the router can
process the options at the full forwarding rate. That is, they
should be simple to process, see Section 5.2.
* New options SHOULD be defined with the Action type (highest-order
2 bits of the Option Type) set to 00 to skip over this option and
continue processing the header if a router does not recognize the
option.
* The size of a Hop-by-Hop option SHOULD NOT extend beyond what can
be expected to be executed at full forwarding rate. A larger Hop-
by-Hop Option header can increase the likelihood that that a
packet will be dropped [Cus23b]. Limits to Hop-by-Hop options
headers are discussed in [I-D.ietf-6man-eh-limits].
* New Hop-by-Hop options SHOULD be designed expecting that a router
might be configured to only process a subset of Hop-by-Hop options
(e.g., the first) in the Hop-by-Hop Options header.
* New Hop-by-Hop options SHOULD be designed expecting that a router
may drop packets containing the new Hop-by-Hop option.
Any new Hop-by-Hop option that is standardized that does not meet
these criteria MUST include in the specification a detailed
explanation why this can not be accomplished and to show that there
is a reasonable expectation that the option can be proceed at full
forwarding rate. This is consistent with [RFC6564].
The general issue of robust operation of packets with new Hop-by-Hop
options is described in Section 6.1 below.
Hinden & Fairhurst Expires 28 August 2024 [Page 12]
Internet-Draft HBH Options Processing February 2024
6.1. Example of Robust Usage
Recent measurement surveys (e.g., [Cus23a]) show that packets that
include Extension Headers can cause the packets to be dropped by some
Internet paths. In a controlled domain, routers can be configured or
updated to provide support for any required Hop-by-Hop options.
The primary motivation of this document is to make it more practical
to use Hop-by-Hop options beyond such a single domain, with the
expectation that applications can improve the quality of or add new
features to their offered service when the path successfully forwards
packets with the required Hop-by-Hop options, and otherwise refrains
from using these options. The focus is on incremental deployability.
A protocol feature (such as using Hop-by-Hop options) is
incrementally deployable if early adopters gain some benefit on the
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
carried in the Hop-by-Hop Options header in decreasing order of
importance for processing by nodes on the path.
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 robust when the current path drops packets that contain a Hop-by-
Hop option (e.g., [RFC9098]).
For example, an application can be designed to first send a test
packet that includes the required option, or combination of options,
and sends other packets without including the option. The
application then does not send additional packets that include this
option (or set of options) until the test packet(s) is acknowledged.
The need for potential loss recovery when a path drops these test
packets can be avoided by choosing packets that do not carry
application data that needs to be reliably delivered.
Since the set of nodes forming a path can change with time, this
discovery process ought to be repeated from time-to-time. The
process of sending packets both with and without a specific header to
discover whether a path can support a specific header is sometimes
called "racing" (e.g., transport protocol racing is explained in
[I-D.ietf-taps-arch], or "A/B protocol feature testing" is described
in [Tram17]).
7. IANA Considerations
There are no actions required for IANA defined in this document.
Hinden & Fairhurst Expires 28 August 2024 [Page 13]
Internet-Draft HBH Options Processing February 2024
8. Security Considerations
Security issues with including IPv6 Hop-by-Hop options are well known
and have been documented in several places, including [RFC6398],
[RFC6192], [RFC7045] and [RFC9098]. The main issue, as noted in
Section 4, is that any mechanism that can be used to force packets
into the router's Control Plane can be exploited as a Denial of
Service attack on a transit router by saturating the resources needed
for router management (e.g., routing protocols, network management
protocols, etc.) and cause the router to fail or perform sub-
optimally.
While Hop-by-Hop options are not required to be processed in the
Control Plane, the Router Alert option is the one exception designed
to be processed in the control plane.
Some IPv6 nodes implement features that access more of the protocol
information than a typical IPv6 router (e.g., [RFC9098]). Examples
are nodes that provide DDOS mitigation, Firewall/access control,
traffic engineering, or traffic normalization. These nodes could be
configured to drop packets when they are unable to access and process
all Extension Headers, or are unable to locate and process the
higher-layer packet information. This document provides guidance on
the requirements concerning Hop-by-Hop options.
Finally, the document notes that Internet protocol processing needs
to be robust to malformed/malicious protocol fields. This
requirement is not specific to Hop-by-Hop options. It is important
that implementations fail gracefully when a malformed or malicious
Hop-by-Hop option is encountered.
This document changes the way the Hop-by-Hop Options header is
processed in several ways that significantly reduce the attack
surface. These changes include:
* Each of the enabled Hop-by-Hop (with one exception) needs be
processed at full forwarding rate. The first Hop-by-Hop option
MUST be processed and additional Hop-by-Hop options MAY be
processed based on local configuration.
* It adds criteria for the Router Alert option in Section 5.2.1 to
allow control over how the Router Alert option is processed and
that a node configured to support these options must protect
itself from attacks using the Router Alert option.
* The document defined the default number of Hop-by-Hop options that
can be included in a packet to a single Hop-by-Hop option.
Hinden & Fairhurst Expires 28 August 2024 [Page 14]
Internet-Draft HBH Options Processing February 2024
* Additional Hop-by-Hop options MAY be included, based on local
configuration. Although nodes only process these additional Hop-
by-Hop options if configured to do so.
* The document added restrictions to any future new Hop-by-Hop
option that limit their size and computational requirements.
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, Mark Heard, Tom Herbert, Cheng Li, Eric Vyncke, Greg Mirksy,
Xiao Min, Fernando Gont, Darren Dukes, Peng Shuping, Dave Thaler, Ana
Custura, Tim Winters, Fernando Gont, Jingrong Xie, Lorenzo Colitti,
Toerless Eckert, Suresh Krishnan, Mikael Abrahamsson, Adrian Farrel,
Jie Dong, Jen Linkova, and other members of the 6MAN working group.
10. Change log [RFC Editor: Please remove]
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:
Hinden & Fairhurst Expires 28 August 2024 [Page 15]
Internet-Draft HBH Options Processing February 2024
* 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".
Hinden & Fairhurst Expires 28 August 2024 [Page 16]
Internet-Draft HBH Options Processing February 2024
* 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
RFC8200.
* 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:
Hinden & Fairhurst Expires 28 August 2024 [Page 17]
Internet-Draft HBH Options Processing February 2024
* 6MAN Working Group Draft
* Reworked text to talk about processing Hop-by-Hop options at full
forwarding rates, instead of "fast path"
* Revised Section 6 "New Hop-by-Hop options" to allow variable sized
Hop-by-Hop options, remove specific length requirements, and other
clarifications.
* Editorial changes.
draft-hinden-6man-hbh-processing-01, 2021-June-2:
* Expanded terminology section to include Forwarding Plane and
Control Plane.
* Changed draft that only one Hop-by-Hop option MUST be processed
and additional Hop-by-Hop options MAY be processed based on local
configuration.
* Clarified that all Hop-by-Hop options (with one exception) must be
processed on the Fast Path.
* Kept the Router Alert option as the single exception for Slow Path
processing.
* Rewrote and expanded section on New Hop-by-Hop options.
* Removed requirement for Hop-by-Hop option size and alignment.
* Removed sections evaluating currently defined Hop-by-Hop options.
* Added content to the Security Considerations section.
* Added people to the acknowledgements section.
* Numerous editorial changes
draft-hinden-6man-hbh-processing-00, 2020-Nov-29:
* Initial draft.
11. Normative References
[IANA-HBH] "Destination Options and Hop-by-Hop Options",
<https://www.iana.org/assignments/ipv6-parameters/
ipv6-parameters.xhtml#ipv6-parameters-2>.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/info/rfc2119>.
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
May 2017, <https://www.rfc-editor.org/info/rfc8174>.
Hinden & Fairhurst Expires 28 August 2024 [Page 18]
Internet-Draft HBH Options Processing February 2024
[RFC8200] Deering, S. and R. Hinden, "Internet Protocol, Version 6
(IPv6) Specification", STD 86, RFC 8200,
DOI 10.17487/RFC8200, July 2017,
<https://www.rfc-editor.org/info/rfc8200>.
12. Informative References
[Cus23a] Custura, A. and G. Fairhurst, "Internet Measurements: IPv6
Extension Header Edition", IEPG, IETF-116 , March 2023,
<http://www.iepg.org/2023-03-26-ietf116/eh.pdf>.
[Cus23b] Custura, A., Secchi, R., Boswell, E., and G. Fairhurst,
"Is it possible to extend IPv6?", Computer
Communications X, October 2023,
<https://www.sciencedirect.com/science/article/pii/
S0140366423003705>.
[Hendriks] Hendriks, L., Velan, P., Schmidt, RO., Boer, P., and A.
Aiko, "Threats and Surprises behind IPv6 Extension
Headers", , August 2017,
<http://dl.ifip.org/db/conf/tma/tma2017/
tma2017_paper22.pdf>.
[I-D.ietf-6man-eh-limits]
Herbert, T., "Limits on Sending and Processing IPv6
Extension Headers", Work in Progress, Internet-Draft,
draft-ietf-6man-eh-limits-12, 18 December 2023,
<https://datatracker.ietf.org/doc/html/draft-ietf-6man-eh-
limits-12>.
[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
Options Header", Work in Progress, Internet-Draft, draft-
ietf-v6ops-hbh-10, 16 February 2024,
<https://datatracker.ietf.org/doc/html/draft-ietf-v6ops-
hbh-10>.
Hinden & Fairhurst Expires 28 August 2024 [Page 19]
Internet-Draft HBH Options Processing February 2024
[IANA-RA] "IPv6 Router Alert Option Values",
<https://www.iana.org/assignments/ipv6-routeralert-values/
ipv6-routeralert-values>.
[RFC1883] Deering, S. and R. Hinden, "Internet Protocol, Version 6
(IPv6) Specification", RFC 1883, DOI 10.17487/RFC1883,
December 1995, <https://www.rfc-editor.org/info/rfc1883>.
[RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6
(IPv6) Specification", RFC 2460, DOI 10.17487/RFC2460,
December 1998, <https://www.rfc-editor.org/info/rfc2460>.
[RFC2711] Partridge, C. and A. Jackson, "IPv6 Router Alert Option",
RFC 2711, DOI 10.17487/RFC2711, October 1999,
<https://www.rfc-editor.org/info/rfc2711>.
[RFC6192] Dugal, D., Pignataro, C., and R. Dunn, "Protecting the
Router Control Plane", RFC 6192, DOI 10.17487/RFC6192,
March 2011, <https://www.rfc-editor.org/info/rfc6192>.
[RFC6398] Le Faucheur, F., Ed., "IP Router Alert Considerations and
Usage", BCP 168, RFC 6398, DOI 10.17487/RFC6398, October
2011, <https://www.rfc-editor.org/info/rfc6398>.
[RFC6564] Krishnan, S., Woodyatt, J., Kline, E., Hoagland, J., and
M. Bhatia, "A Uniform Format for IPv6 Extension Headers",
RFC 6564, DOI 10.17487/RFC6564, April 2012,
<https://www.rfc-editor.org/info/rfc6564>.
[RFC7045] Carpenter, B. and S. Jiang, "Transmission and Processing
of IPv6 Extension Headers", RFC 7045,
DOI 10.17487/RFC7045, December 2013,
<https://www.rfc-editor.org/info/rfc7045>.
[RFC7872] Gont, F., Linkova, J., Chown, T., and W. Liu,
"Observations on the Dropping of Packets with IPv6
Extension Headers in the Real World", RFC 7872,
DOI 10.17487/RFC7872, June 2016,
<https://www.rfc-editor.org/info/rfc7872>.
[RFC8799] Carpenter, B. and B. Liu, "Limited Domains and Internet
Protocols", RFC 8799, DOI 10.17487/RFC8799, July 2020,
<https://www.rfc-editor.org/info/rfc8799>.
[RFC9098] Gont, F., Hilliard, N., Doering, G., Kumari, W., Huston,
G., and W. Liu, "Operational Implications of IPv6 Packets
with Extension Headers", RFC 9098, DOI 10.17487/RFC9098,
September 2021, <https://www.rfc-editor.org/info/rfc9098>.
Hinden & Fairhurst Expires 28 August 2024 [Page 20]
Internet-Draft HBH Options Processing February 2024
[RFC9268] Hinden, R. and G. Fairhurst, "IPv6 Minimum Path MTU Hop-
by-Hop Option", RFC 9268, DOI 10.17487/RFC9268, August
2022, <https://www.rfc-editor.org/info/rfc9268>.
[Tram17] Trammell, B., Kuehlewind, M., De Vaere, P., Learmonth,
IR., and G. Fairhurst, "Tracking Transport-Layer Evolution
with PATH Spider", ANRW , July 2017,
<https://irtf.org/anrw/2017/anrw17-final16.pdf>.
Authors' Addresses
Robert M. Hinden
Check Point Software
959 Skyway Road
San Carlos, CA 94070
United States of America
Email: bob.hinden@gmail.com
Godred Fairhurst
University of Aberdeen
School of Engineering
Fraser Noble Building
Aberdeen
AB24 3UE
United Kingdom
Email: gorry@erg.abdn.ac.uk
Hinden & Fairhurst Expires 28 August 2024 [Page 21]
