Internet DRAFT - draft-ietf-6man-hbh-processing
draft-ietf-6man-hbh-processing
Network Working Group R. Hinden
Internet-Draft Check Point Software
Updates: 8200, 7045 (if approved) G. Fairhurst
Intended status: Standards Track University of Aberdeen
Expires: 8 October 2023 6 April 2023
IPv6 Hop-by-Hop Options Processing Procedures
draft-ietf-6man-hbh-processing-07
Abstract
This document specifies procedures for how IPv6 Hop-by-Hop options
are processed at routers and hosts. 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 and RFC7045.
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 8 October 2023.
Copyright Notice
Copyright (c) 2023 IETF Trust and the persons identified as the
document authors. All rights reserved.
Hinden & Fairhurst Expires 8 October 2023 [Page 1]
Internet-Draft HBH Options Processing April 2023
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. Hop-by-Hop Options Per Packet . . . . . . . . . . . . . . 7
5.2. Hop-by-Hop Options Header Processing . . . . . . . . . . 7
5.3. Router Alert Option . . . . . . . . . . . . . . . . . . . 9
5.4. Configuration . . . . . . . . . . . . . . . . . . . . . . 10
6. New Hop-by-Hop Options . . . . . . . . . . . . . . . . . . . 10
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11
8. Security Considerations . . . . . . . . . . . . . . . . . . . 11
9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 12
10. Change log [RFC Editor: Please remove] . . . . . . . . . . . 12
11. Normative References . . . . . . . . . . . . . . . . . . . . 14
12. Informative References . . . . . . . . . . . . . . . . . . . 15
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 16
1. Introduction
This document specifies procedures for how IPv6 Hop-by-Hop options
are processed at routers and IPv6 hosts. 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.
The focus for this document is to set a lower bound for the minimum
number of hop-by-hop options that ought to be processed. This
document does not discuss an upper bound. That topic is discussed in
[I-D.ietf-6man-eh-limits].
When published, this document updates [RFC8200] and updates section
2.2 of [RFC7045].
The current list of defined Hop-by-Hop options can be found at
[IANA-HBH].
Hinden & Fairhurst Expires 8 October 2023 [Page 2]
Internet-Draft HBH Options Processing April 2023
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 hosts exchange user data through the
forwarding plane. User data is processed by its recipient (i.e.,
an IPv6 host). User data can traverse routers between its source
and its destination. These 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 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
router that process fields contained in packet headers. However,
they do not process information contained in packet payloads.
* Fast Path: A path through a router that is optimized for
forwarding packets without processing their payloads. The Fast
Path might 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 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 and keep the aggregate data rate for it's outgoing
interfaces full (for example, the maximum speed the interface can
support). This is sometimes call "wire speed". When used in this
document, it means that the router can process packets with HBH
Options at the rate that allows it to maintain the full speed on
its outgoing interfaces.
Hinden & Fairhurst Expires 8 October 2023 [Page 3]
Internet-Draft HBH Options Processing April 2023
NOTE: [RFC6192] is an example of how designs can separate control
plane (Slow Path) and forwarding plane (Fast Path) 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 (aka
Slow Path).
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 due to several factors, including:
* Inability to process the hop-by-hop options at the full forwarding
rate (e.g., routers with no support on the Fast Path).
* Hop-by-Hop options would be sent to the Slow Path. This could
degrade a router's performance and its ability to process
important control traffic.
* It was recognised that 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.
* If a subset of packets in a flow include Hop-by-Hop options that
require "Slow Path" forwarding, it introduces the potential for
packets to be delivered out of order to the destination.
Significant reordering of the packets belonging to a flow can
significantly impact the performance of upper layer protocols and
needs to be avoided.
* Packets could contain multiple Hop-by-Hop options making the
previous issues worse by increasing the complexity required to
process them, or requiring access to more bytes of protocol
header.
[RFC6564] specified a uniform format for new IPv6 Extension Headers.
It updated [RFC2460] and this update was incorporated into
Section 4.8 of [RFC8200].
When the IPv6 Specification was updated and published in July 2017 as
[RFC8200], the procedures relating to hop-by-hop options were as
follows:
Hinden & Fairhurst Expires 8 October 2023 [Page 4]
Internet-Draft HBH Options Processing April 2023
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.
The text regarding processing Hop-by Hop Options in [RFC8200] was not
intended to change the processing of Hop-by-Hop options. It only
documented how they were being used in the Internet at the time
RFC8200 was published. This was a constraint on publishing the IPv6
specification as an IETF Standard.
The main issues remain:
* Routers are commonly configured to drop transit packets containing
hop-by-hop options that would have required processing in the Slow
Path. This could be to protect against a denial of service attack
on the router.
* A survey in 2015 reported a high loss rate in transit ASs for
packets with HBH options [RFC7872]. The operational implications
of IPv6 Packets that set extension headers are discussed in
[RFC9098].
* 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.
Hinden & Fairhurst Expires 8 October 2023 [Page 5]
Internet-Draft HBH Options Processing April 2023
* 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 could cause the router to fail. This is an
issue for the Router Alert option, which intentionally places
packets on the Slow Path, is discussed in [RFC6398]. 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 [Hendriks] states that
"dropping all packets with Extension Headers, is a bad practice", and
that "The share of traffic containing more than one EH however, is
very small. For the design of hardware able to handle the dynamic
nature of Extension Headers we therefore recommend to support at
least one EH".
The topic discussed in this section is 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
considered when [RFC2460] was updated and was itself replaced by
[RFC8200]. This document updates [RFC8200] as described in the next
section and consequently updates the description in Section 2.2 of
[RFC7045].
This document defines a set of procedures for the Hop-by-Hop Option
header that are intended to make the processing of hop-by-hop options
practical in modern transit routers. The authors expectations are
that some hop-by-hop options will be processed across the Internet
while others will only be processed in a limited domain (e.g., where
there is a specific service made available in that network segment
that relies on one or more hop-by-hop options).
Hinden & Fairhurst Expires 8 October 2023 [Page 6]
Internet-Draft HBH Options Processing April 2023
5. Hop-by-Hop Header Processing Procedures
This section describes several changes to [RFC8200].
5.1. Hop-by-Hop Options Per Packet
The Hop-by-Hop Option Header as defined in Section 4.3 of [RFC8200]
is identified by a Next Header value of 0 in the IPv6 header.
Section 4.1 of [RFC8200] requires a 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. This document updates [RFC8200] to
specify that a router MUST process the first Option in the Hop-by-Hop
Header at full forwarding rate (e.g. on the router's 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 as a part of normal forwarding.
Nodes creating packets with a Hop-by-Hop option header SHOULD by
default only include a single Hop-by-Hop Option in the packet and
based on local configuration MAY include more Hop-by-Hop Options.
5.2. Hop-by-Hop Options Header Processing
Hop-by-Hop Option headers can be designed to expect processing by the
Destination host. Hosts SHOULD process the Hop-by-Hop Option header
in received packets. Further details on requirements for host
processing are described in [I-D.ietf-6man-eh-limits]. If a
Destination host does not process the Hop-by-Hop Option header, it
MUST process the remainder of the packet normally.
Routers SHOULD process the Hop-by-Hop Option header. If the router
does not process the Hop-by-Hop Option header, it MUST forward the
packet normally.
Routers MUST process all Hop-by-Hop options at full forwarding rates.
The one exception to this is the Router Alert Option [RFC2711]. See
Section 5.3 for discussion of the Router Alert Option.
If the router is unable to process an option at the full forwarding
rate, it MUST behave in the way specified for an unrecognized Option
Type when the action bits were set to "00". That is, it must skip
over this option and continue processing the header (as described in
the next paragraph).
Hinden & Fairhurst Expires 8 October 2023 [Page 7]
Internet-Draft HBH Options Processing April 2023
If there are more than one Hop-by-Hop options in the Hop-by-Hop
Options header, the router 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.
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 "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:
10 - discard the packet and, regardless of whether or not the
packet's Destination Address was a multicast address, MAY
send an ICMP 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, MAY send an ICMP
Parameter Problem, Code 2, message to the packet's Source
Address, pointing to the unrecognized Option Type.
The motivation for this change is to loosen the requirement to send
ICMPv6 Parameter Problem messages by simplifying what the router
needs to do when it performs forwarding of an Option Type it does not
recognize.
Hinden & Fairhurst Expires 8 October 2023 [Page 8]
Internet-Draft HBH Options Processing April 2023
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.
5.3. Router Alert Option
The Router Alert option [RFC2711] 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
[IANA-RA].
DISCUSSION
The Router Alert Option is a problem since its function is to do
what this specification is proposing to eliminate, that is, to
instruct a router to process the packet in the Slow Path. One
approach would be to deprecate because current usage 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 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 [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 and continue processing the header in this
case. 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 [RFC6398]. Otherwise, the router implementation SHOULD
forward within the Fast Path (subject to all normal policies and
forwarding rules).
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].
Hinden & Fairhurst Expires 8 October 2023 [Page 9]
Internet-Draft HBH Options Processing April 2023
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 [RFC6398].
5.4. Configuration
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 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 router to quickly determine if
an option is supported and can be processed. If the option is not
supported, then the router processes it as described in Section 5.2
of this document.
This requires the router to examine the first two bits of the option
even if it does not support the specific option. A router MUST drop
the packet if the top two bits of the Option Type field of the first
HBH option is non-zero as specified in Section 5.2.
The actions of the lookup table SHOULD be configurable by the
operator of the router.
6. 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 (e.g., on a router's
Fast Path, or at least without slowing processing of other packets).
New options SHOULD NOT be defined that are not expected to be
executed at full forwarding rate. New Hop-by-Hop options should have
the following characteristics:
* Straight forward to process. That is, new Hop-by-Hop options
SHOULD be designed to ensure the router can process the options at
the full forwarding rate (e.g., on the router's Fast Path). See
Section 5.1.
Hinden & Fairhurst Expires 8 October 2023 [Page 10]
Internet-Draft HBH Options Processing April 2023
* 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.
* New Hop-by-Hop options SHOULD be designed to be the first option
in a Hop-by-Hop options header.
* The size of an option SHOULD NOT extend beyond what can be
expected to be executed at full forwarding rate (e.g., forwarded
on a router's 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 at full forwarding rate. This is
consistent with [RFC6564].
7. IANA Considerations
There are no actions required for IANA defined in this document.
8. Security Considerations
Security issues with 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 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 or perform sub-
optimally. Due to this it’s common for transit routers to drop
packets with a Hop-by-Hop options header.
While Hop-by-Hop options are not required to be processed in the Slow
Path, the Router Alert option is designed to do just that.
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 virus-scanning, 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.
Hinden & Fairhurst Expires 8 October 2023 [Page 11]
Internet-Draft HBH Options Processing April 2023
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 Hop-by-Hop options are processed in
several ways that significantly reduce the attack surface. These
changes include:
* All Hop-by-Hop options (with one exception) must be processed at
full forwarding rate. 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.
* The document 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.
* The document limited the default number of Hop-by-Hop options that
can be included 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.
* The document added restrictions to any future new Hop-by-Hop
options that limit their size and computational requirements.
The authors intent is that these changes significantly reduce the
security issues relating to IPv6 Hop-by-Hop options and will enable
them to be used safely 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, [your name here], and other
members of the 6MAN working group.
10. Change log [RFC Editor: Please remove]
draft-ietf-6man-hbh-processing-07, 2023-April-6:
Hinden & Fairhurst Expires 8 October 2023 [Page 12]
Internet-Draft HBH Options Processing April 2023
* Changed text to clarify how hosts and routers process Hop-by-Hop
option headers based on comments at 6MAN session at IETF 116.
* Editorial changes
draft-ietf-6man-hbh-processing-06, 2023-March-11:
* Added reference to RFC6564.
* Editorial changes
draft-ietf-6man-hbh-processing-05, 2023-February-23:
* Clarified text in Section 6 about processing complexity and time
to process.
* Added a definition to Section 3 for "Full Forwarding Rate".
* Added text to Section 5.2 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.2 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.4 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.2
* Revised text in Section 4 to reflect constraints on publishing
RFC8200.
Hinden & Fairhurst Expires 8 October 2023 [Page 13]
Internet-Draft HBH Options Processing April 2023
* Changed text in Section 6 that new options SHOULD NOT (from MUST
NOT) be defined that require that are not expected to be excepted
at full forwarding rates.
* Added reference to RFC7872 in Section 4.
* Added text to Section 1 that the focus of this document is to set
a minimum bound on the number of Hop-by-Hop Options a node should
process.
* Added text to Section 4 that the authors some Hop-by-Hop options
will be supported Internet wide, and others only in limited
domains.
* Editorial changes.
draft-ietf-6man-hbh-processing-00, 2022-January-29:
* 6MAN Working Group Draft
* Reworked text to talk about processing HBH options at full
forwarding rates, instead of "fast path"
* Revised Section 6 "New Hop-by-Hop Options" to allow variable sized
HBH 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 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:
* Initial draft.
11. Normative References
Hinden & Fairhurst Expires 8 October 2023 [Page 14]
Internet-Draft HBH Options Processing April 2023
[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>.
[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
[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-02, 28 February 2023,
<https://datatracker.ietf.org/doc/html/draft-ietf-6man-eh-
limits-02>.
[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-04, 9 March 2023,
<https://datatracker.ietf.org/doc/html/draft-ietf-v6ops-
hbh-04>.
[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>.
Hinden & Fairhurst Expires 8 October 2023 [Page 15]
Internet-Draft HBH Options Processing April 2023
[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>.
[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>.
Authors' Addresses
Robert M. Hinden
Check Point Software
959 Skyway Road
San Carlos, CA 94070
United States of America
Email: bob.hinden@gmail.com
Hinden & Fairhurst Expires 8 October 2023 [Page 16]
Internet-Draft HBH Options Processing April 2023
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 8 October 2023 [Page 17]
