IPv6 Hop-by-Hop Options Processing Procedures
Check Point Software
959 Skyway Road
San Carlos
CA
94070
USA
bob.hinden@gmail.com
University of Aberdeen
School of Engineering
Fraser Noble Building
Aberdeen
AB24 3UE
UK
gorry@erg.abdn.ac.uk
This document specifies procedures for how IPv6 Hop-by-Hop options are
processed. It modifies the procedures specified in the IPv6
Protocol Specification (RFC8200) to make processing of IPv6 Hop-by-Hop options
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.
This document specifies procedures for how IPv6 Hop-by-Hop options are
processed. It modifies the procedures specified in the IPv6
Protocol Specification (RFC8200) to make processing of IPv6 Hop-by-Hop options
practical with the goal of making IPv6 Hop-by-Hop options useful to
deploy and use in the Internet.
When published this document updates .
The current list of defined Hop-by-Hop options can be found at .
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
when, and only when, they appear in all
capitals, as shown here.
This document uses the following loosely defined
terms:
- Forwarding Plane: IPv6 hosts exchange user data through the forwarding
plane. User data is processed by its recipient (i.e., an IPv6
host). User data can traverse intermediate nodes (i.e., routers)
between its source and its destination. These intermediate nodes
process metadata contained in packet headers. However, they do not
process information contained in packet payloads.
- Control Plane: IPv6 routers exchange management and routing
information with controllers. They also exchange routing information
with one another. Management and routing information is processed by
its recipient (i.e., an IPv6 router or controller). Management and
control information can traverse intermediate nodes (i.e., routers)
between its source and its destination. These intermediate nodes
process metadata contained in packet headers. However, they do not
process information contained in packet payloads. So, from their
perspective, this information is user data.
- Fast Path: A path through a router that is optimized for
forwarding packets without processing their payloads. The Fast Path
may be supported by Application Specific Integrated Circuits (ASICS),
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 is 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.
NOTE: This distinct separation between hardware and software processing
from 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 (aka Slow Path).
is an example of how designs can separate
control plane (Slow Path) and
forwarding plane (Fast Path) functions.
In the first version of the IPv6 specification, Hop-by-Hop options were
required to be processed by all nodes: routers and hosts. This proved
to not be practical in high speed routers due to several factors,
including:
- Inability to process the hop-by-hop options at wire speed on
the Fast Path.
- Hop-by-Hop options would be sent to the Slow Path. This could
could degrade the a router's performance and it's ability to process
important control traffic.
- A mechanism that forces packets from any source to the routers "Slow
Path" could be exploited as a Denial of Service attack against the router.
- Packets could contain multiple Hop-by-Hop options making the
previous issues worse by increasing the complexity required to process
them.
When the IPv6 Specification was updated and published in
July 2017 as
, the procedures relating to hop-by-hop options
were as follows:
- Extension headers (except for the Hop-by-Hop Options header) are not
processed, inserted, or deleted 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 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
which hop-by-hop options they would process.
Unfortunately, this did not improve the processing of Hop-by-Hop
options
and did not significantly improve deployment and use in the
Internet. Essentially, it only documented how they were being used in
the Internet at the time RFC8200 was published.
The main issues remain:
- Routers are commonly configured to drop transit packets containing
hop-by-hop options that
would have be processed in the Slow Path. This behavior is seen as
protecting against a denial of service attack on the router. This is
discussed in .
- Allowing multiple hop-by-hop options in a single packet makes it even
more expensive in router resources to process these packets.
It adds complexity to the number of permutations that might need to be
processed.
- Any mechanism that can be used to force packets into the
router's Slow Path 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 may cause the router to fail. This issue for the
Router Alert option, which intentionally places packets on the Slow Path,
is discussed in .
Section 3 of that RFC includes a good summary:
- "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."
There has been research that discussed
the general problem with dropping packets containing IPv6 extension
headers, including the Hop-by-Hop Options header.
For example states that "dropping all
packets with Extension Headers, is a bad practice", and that "The share
of traffic containing more than one EH however, is very small. For the
design of hardware able to handle the dynamic nature of EHs, we therefore
recommend to support at least one EH".
This document defines a set of procedures for the hop-by-hop option
header that make the processing of hop-by-hop options practical in modern
transit routers.
This section describes several changes to .
The Hop-by-Hop Option Header as defined in Section 4.3 of is identified by a Next Header value of 0 in the IPv6
header. Section 4.1 of requires a Hop-by-Hop
Options header to appear immediately after the IPv6 header. 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 can contain
one or more Hop-by-Hop options. This document updates
that a node MUST process the first Option in the Hop-by-Hop Header in
the Fast Path and MAY process additional Hop-by-Hop Options if
configured to do so.
The motivation for this change is to simplify the processing of Hop-by-Hop options in the
Fast Path.
Nodes creating packets with a Hop-by-Hop option headers SHOULD
include a single Hop-by-Hop Option in the packet and MAY include
more based on local configuration.
If there are more than one Hop-by-Hop options in the Hop-by-Hop
Options header, the node MAY skip the rest of the options without having
to examine these 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. The additional options do not need to be
processed or verified.
Nodes that implement a differentiation between a Fast Path and a Slow
Path MUST process all (with one exception noted below) Hop-by-Hop
options in the Fast Path. The one exception to this is the Router
Alert Option . See for
discussion of the Router Alert.
If the node can not process an option in the Fast Path, it MUST behave
as if it does not recognize the Option Type (as described in the next paragraph).
Section 4.2 of
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:
This document modifies this behaviour for the "10" and "11" values that the
node MAY send an ICMP Parameter Problem, Code 2, message to the packet's Source Address,
pointing to the unrecognized Option Type. The modified text for "10" and
11" values is:
The motivation for this change is to loosen the requirement to send
ICMPv6 Parameter Problem messages to simplify what the router needs to
do in the Fast Path when it does not recognize the Option Type.
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
patch has failed to recognize the option.
The Router Alert option purpose is to tell
the node that the packet needs additional processing on the Slow Path.
The Router Alert option includes a two octet Value field that
describes the protocol that is carried in the packet. The current values can
be found in the IANA Router Alert Value registry .
DISCUSSION
- The Router Alert Option is a problem since it's function is to do what
this specification is proposing to eliminate, that is, process the packet
in the Slow Path. One approach would be to deprecate it as it's usage
appears to be limited and packets containing Hop-by-Hop options are
frequently dropped. Deprecation would allow current implementations
to continue and it's use could be phased out over time.
- The authors current thinking is that the Router Alert function may
have reasonable potential use for new functions that have to be processed
in the Slow Path. We think that keeping it as the single exception for
Slow Path processing with the following
restrictions is a reasonable compromise to allow future flexibility.
These are compatible with Section 5 of .
A Fast Path implementation SHOULD verify that a Router Alert 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 on the Slow Path for processing
. Otherwise, the router implementation SHOULD forward within
the Fast Path (subject to all normal policies and forwarding rules).
As specified in 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 and continue processing the header in this
case.
Implementations of the IP Router Alert Option
SHOULD offer the configuration option to simply ignore the presence
of "IP Router Alert" in IPv4 and IPv6 packets" .
A node that is configured to process a Router Alert option
using the Slow Path MUST protect itself from infrastructure attack
that could result from processing on the Slow Path. This might include
some combination of access control list to only permit from trusted nodes,
rate limiting of processing, or other methods .
Section 4 of
allows for a router to control it's 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 a packet's delivery path only examine and process the
Hop-by-Hop Options header if explicitly configured to do so.
A possible approach to implementing this is to maintain a lookup table
based on Option Type of the
IPv6 options that are supported in the Fast Path. This would allow for a
node to quickly determine if an option is supported and can be
processed. If the option is not supported, then the node processes it as
described in of this document.
A node configured not to process HBH options, MUST drop the packet
if the top two bits of the Option Type field of the first HBH option is non-zero.
The actions of the lookup table SHOULD be configurable by the operator of
the router.
Any new IPv6 Hop-by-Hop option designed in the future should be designed to be processed in
the Fast Path. New options MUST NOT be defined that require Slow Path processing.
New Hop-by-Hop options SHOULD have the following characteristics:
- Straight forward to process. That is, they should be designed to keep
the time to process low.
- Fixed size in 8-octet units. Specifically any new Hop-by-Hop options
should not be variable size that could extend beyond what can be executed
in the Fast Path.
Any new Hop-by-Hop option that is standardized that does not meet
these criteria needs to explain in detail in its specification why
this can not be accomplished and that there is a reasonable expectation
that it can be proceed in most Fast Path implementations.
There are no actions required for IANA defined in this document.
Security issues with IPv6 Hop-by-Hop options are well known and have
been documented in several places, including
,
, and
. The main issue,
as noted in , is that
any mechanism that can be used to force packets into the
router's Slow Path can be exploited as a denial of service attack on a
transit router by saturating the resources need for router management
protocols (e.g., routing protocols, network management protocols, etc.)
that may cause the router to fail.
Due to this it’s common for transit routers to drop packets with Hop-by-Hop options headers.
While Hop-by-Hop options are not required to be processed in the Slow
Path, the Router Alert options is designed to do just that.
This document changes the way Hop-by-Hop options are processed in
several ways that significantly reduces the attack surface. These
changes include:
- All Hop-by-Hop options (with one exception) must be processed in
the Fast Path. Only one HBH Option MUST be processed and additional HBH Options
MAY be processed based on local configuration.
- Only the Router Alert option can be processed in the Slow Path,
and the router must be configured to do so.
- Added criteria to allow control over how Router Alert options are
processed and that a node configured to support these options must
protect itself from attacks using the Router Alert.
- Limited the default number of Hop-by-Hop options that that can be in a
packet to a single Hop-by-Hop option.
- 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.
- Added restrictions to any future new Hop-by-Hop options that
limit their size and computational requirements.
The authors believe that these changes significantly reduces the
security issues relating to IPv6 Hop-by-Hop options and will enable them
to be used safely in the Internet.
Helpful comments were received from Brian Carpenter, Ron Bonica,
Ole Troan, Mark Heard, Tom Herbert,
[your name here],
and other members of the 6MAN working group.
draft-hinden-6man-hbh-processing-01, 2021-June-2:
- Expanded terminology section to include Forwarding Plane and
Control Plane.
- Changed draft that only one HBH Option MUST be processed and
additional HBH Options MAY be processed based on local
configuration.
- Clarified that all HBH options (with one exception) must be
processed on the Fast Path.
- Kept the Router Alert options as the single exception for Slow
Path processing.
- Rewrote and expanded section on New Hop-by-Hop Options.
- Removed requirement for HBH Option size and alignment.
- Removed sections evaluating currently defined HBH 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:
Destination Options and Hop-by-Hop Options
IPv6 Router Alert Option Values
Threats and Surprises behind IPv6 Extension Headers
University of Twente
University of Twente
University of Twente
University of Twente
University of Twente