Diff: rfc9673.original.xml

	rfc9673.original.xml	rfc9673.xml

	<?xml version='1.0' encoding='utf-8'?>	<?xml version='1.0' encoding='UTF-8'?>
	<!DOCTYPE rfc SYSTEM "rfc2629-xhtml.ent">
	<?xml-stylesheet type="text/xsl" href="rfc2629.xslt" ?>
	<?rfc strict="yes" ?>
	<?rfc toc="yes"?>
	<?rfc tocdepth="4"?>
	<?rfc symrefs="yes"?>
	<?rfc sortrefs="yes" ?>
	<?rfc compact="yes" ?>
	<?rfc subcompact="no" ?>


	<rfc	<!DOCTYPE rfc [
	xmlns:xi="http://www.w3.org/2001/XInclude"	<!ENTITY nbsp " ">
	category="std"	<!ENTITY zwsp "">
	docName="draft-ietf-6man-hbh-processing-20"	<!ENTITY nbhy "‑">
	ipr="trust200902"	<!ENTITY wj "⁠">
	updates="8200"	]>
	obsoletes=""
	consensus="true"
	submissionType="IETF"
	tocInclude="true"
	tocDepth="4"
	symRefs="true"
	sortRefs="true"
	version="3">


	<front>	<rfc xmlns:xi="http://www.w3.org/2001/XInclude" category="std" docName="draft-ie tf-6man-hbh-processing-20" number="9673" ipr="trust200902" updates="8200" obsole tes="" consensus="true" submissionType="IETF" tocInclude="true" tocDepth="4" sym Refs="true" sortRefs="true" version="3" xml:lang="en">


	<title abbrev="HBH Options Processing">IPv6 Hop-by-Hop Options Processing Pr	<front>
	ocedures</title>
	<seriesInfo name="Internet-Draft" value="draft-ietf-6man-hbh-processing-20"/
	>


		<title abbrev="HBH Options Processing">IPv6 Hop-by-Hop Options Processing Pr
		ocedures</title>
		<seriesInfo name="RFC" value="9673"/>
	<author fullname="Robert M. Hinden" initials="R" surname="Hinden">	<author fullname="Robert M. Hinden" initials="R" surname="Hinden">
	<organization>Check Point Software</organization>	<organization>Check Point Software</organization>
	<address>	<address>
	<postal>	<postal>

	<street>959 Skyway Road</street>	<street>100 Oracle Parkway, Suite 800</street>
	<!-- Reorder these if your country does things differently -->	<city>Redwood City</city>
	<city>San Carlos</city>
	<region>CA</region>	<region>CA</region>

	<code>94070</code>	<code>94065</code>
	<country>USA</country>	<country>United States of America</country>
	</postal>	</postal>

	<phone/>
	<email>bob.hinden@gmail.com</email>	<email>bob.hinden@gmail.com</email>
	</address>	</address>
	</author>	</author>
	<author fullname="Godred Fairhurst" initials="G" surname="Fairhurst">	<author fullname="Godred Fairhurst" initials="G" surname="Fairhurst">
	<organization>University of Aberdeen</organization>	<organization>University of Aberdeen</organization>
	<address>	<address>
	<postal>	<postal>
	<street>School of Engineering</street>	<street>School of Engineering</street>
	<street>Fraser Noble Building</street>	<street>Fraser Noble Building</street>
	<city>Aberdeen</city>	<city>Aberdeen</city>

	<region/>
	<code>AB24 3UE</code>	<code>AB24 3UE</code>

	<country>UK</country>	<country>United Kingdom</country>
	</postal>	</postal>
	<email>gorry@erg.abdn.ac.uk</email>	<email>gorry@erg.abdn.ac.uk</email>
	</address>	</address>
	</author>	</author>

		<date month="October" year="2024"/>
	<!--	<area>INT</area>
	<date day="" month="" -->	<workgroup>6man</workgroup>

	<abstract>	<abstract>


	<t>This document specifies procedures for how IPv6 Hop-by-Hop options are	<t>This document specifies procedures for processing IPv6 Hop-by-Hop
	processed in IPv6 routers and hosts. It modifies the procedures specified in	options in IPv6 routers and hosts. It modifies the procedures specified
	the IPv6	in the IPv6 Protocol Specification (RFC 8200) to make processing of the IPv6
	Protocol Specification (RFC 8200) to make processing of the IPv6 Hop-by-Hop Op	Hop-by-Hop Options header practical with the goal of making IPv6
	tions header	Hop-by-Hop options useful to deploy and use at IPv6 routers and hosts.
	practical with the goal of making IPv6 Hop-by-Hop options useful to	This document updates RFC 8200.</t>
	deploy and use in the Internet. When published, this document updates
	RFC 8200.</t>

	</abstract>	</abstract>

	</front>	</front>

	<middle>	<middle>


	<section title=" Introduction" anchor="INTRO">	<section anchor="INTRO">
		<name>Introduction</name>
	<t>This document specifies procedures for processing IPv6 Hop-by-Hop	<t>This document specifies procedures for processing IPv6 Hop-by-Hop
	options in IPv6 routers and hosts.	options in IPv6 routers and hosts.
	It modifies the procedures specified in the IPv6	It modifies the procedures specified in the IPv6
	Protocol Specification <xref	Protocol Specification <xref

	target="RFC8200"/> to make processing of IPv6 Hop-by-Hop Options header	target="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	practical with the goal of making IPv6 Hop-by-Hop options useful to
	deploy and use at IPv6 routers and hosts.</t>	deploy and use at IPv6 routers and hosts.</t>

	<t>An IPv6 packet includes Hop-by-Hop	<t>An IPv6 packet includes Hop-by-Hop
	options by including a Hop-by-Hop	options by including a Hop-by-Hop
	Options header. The current list of defined Hop-by-Hop options can be found at <xref	Options header. The current list of defined Hop-by-Hop options can be found at <xref
	target="IANA-HBH"/>.	target="IANA-HBH"/>.
	The focus for this document is to set the minimum requirements	The focus for this document is to set the minimum requirements
	for router processing of Hop-by-Hop options. It also discusses	for router processing of Hop-by-Hop options. It also discusses
	how Hop-by-Hop options are used by hosts.	how Hop-by-Hop options are used by hosts.
	This document	This document
	does not propose a specific bound to the number or size of Hop-by-Hop options	does not propose a specific bound to the number or size of Hop-by-Hop options
	that ought to be processed.</t>	that ought to be processed.</t>


	<t>When published, this document updates <xref target="RFC8200"/>.</t>	<t>This document updates <xref target="RFC8200"/>.</t>

	</section>	</section>


	<section title="Requirements Language">	<section>
		<name>Requirements Language</name>
	<t>The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",	<t>
	"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and	The key words "<bcp14>MUST</bcp14>", "<bcp14>MUST NOT</bcp14>",
	"OPTIONAL" in this document are to be interpreted as described in	"<bcp14>REQUIRED</bcp14>", "<bcp14>SHALL</bcp14>", "<bcp14>SHALL NOT</bcp14>
	BCP 14	",
	<xref target="RFC2119"/>	"<bcp14>SHOULD</bcp14>", "<bcp14>SHOULD NOT</bcp14>",
	<xref target="RFC8174"/>	"<bcp14>RECOMMENDED</bcp14>", "<bcp14>NOT RECOMMENDED</bcp14>",
	when, and only when, they appear in all	"<bcp14>MAY</bcp14>", and "<bcp14>OPTIONAL</bcp14>" in this document are to
	capitals, as shown here.</t>	be
		interpreted as described in BCP 14 <xref target="RFC2119"/> <xref
		target="RFC8174"/> when, and only when, they appear in all capitals, as
		shown here.
		</t>
	</section>	</section>


	<section title="Terminology" anchor="TERM">	<section anchor="TERM">
		<name>Terminology</name>
	<t>This document uses the following loosely defined	<t>This document uses the following loosely defined
	terms:</t>	terms:</t>


	<ul spacing="normal">	<dl spacing="normal">
	<li>forwarding plane: IPv6 routers exchange user or applications data thr
	ough the	<dt>Forwarding Plane:</dt><dd>IPv6 routers exchange user or applications
	forwarding plane. Routers process fields contained in IPv6 packet	data through the
		Forwarding Plane. Routers process fields contained in IPv6 packet
	headers. However, they do not process information contained in packet	headers. However, they do not process information contained in packet

	payloads.</li>	payloads.</dd>


	<li>control plane: IPv6 routers exchange control	<dt>Control Plane:</dt><dd>IPv6 routers exchange control
	information through the	information through the

	control plane. The control plane processes the management and routing	Control Plane. The Control Plane processes the management and routing
	information exchanged with other routers.</li>	information exchanged with other routers.</dd>


	<li>Fast Path: A path through a router that is optimized for	<dt>Fast Path:</dt><dd>A path through a router that is optimized for
	forwarding packets. The Fast Path	forwarding packets. The Fast Path

	might be supported by Application Specific Integrated Circuits (ASICs),	might be supported by Application-Specific Integrated Circuits (ASICs),
	a Network Processor (NP),	a Network Processor (NP),
	or other special purpose hardware. This is the typical processing path	or other special purpose hardware. This is the typical processing path

	within a router taken by the forwarding plane.</li>	within a router taken by the Forwarding Plane.</dd>


	<li>Slow Path: A path through a router that is capable of general	<dt>Slow Path:</dt><dd>A path through a router that is capable of
	purpose processing and is not optimized for any particular	general purpose processing and is not optimized for any particular
	function.	function. This processing path is used for packets that require
	This processing path is used for packets that require special	special processing or that differ from assumptions made in Fast Path
	processing or differ from assumptions made in Fast Path heuristics	heuristics or to process router control protocols used by the Control
	or to process router control protocols used by the control	Plane.</dd>
	plane.</li>


	<li>Full Forwarding Rate: This is the rate that a router can	<dt>Full Forwarding Rate:</dt><dd>The rate at which a router can
	forward packets without adversely impacting the aggregate	forward packets without adversely impacting the aggregate
	forwarding rate. For example, a router could process packets	forwarding rate. For example, a router could process packets
	with Hop-by-Hop options at a rate that allows it to maintain the full	with Hop-by-Hop options at a rate that allows it to maintain the full
	speed on its outgoing interfaces, which is sometimes called	speed on its outgoing interfaces, which is sometimes called

	"wire speed".</li>	"wire speed".</dd>

	<li>source: The node originating the packet.</li>


	</ul>	<dt>Source:</dt><dd>The node originating the packet.</dd>
		</dl>

	<t>NOTE: <xref target="RFC6192"/> is an example of how designs can	<t>NOTE: <xref target="RFC6192"/> is an example of how designs can

	separate control plane and forwarding plane	separate Control Plane and Forwarding Plane
	functions. The separation between hardware and software processing	functions. The separation between hardware and software processing
	described in <xref target="RFC6398"/> does not apply to all router	described in <xref target="RFC6398"/> does not apply to all router
	architectures. However, a router that performs all or most processing	architectures. However, a router that performs all or most processing
	in software might still incur more processing cost when providing	in software might still incur more processing cost when providing
	special processing for Hop-by-Hop options.</t>	special processing for Hop-by-Hop options.</t>

	</section>	</section>


	<section title="Background" anchor="BACKGROUND">	<section anchor="BACKGROUND">
		<name>Background</name>

	<t>	<t>

	In the first versions of the IPv6 specification	In early versions of the IPv6 protocol specification
	<xref target="RFC1883"/> and	<xref target="RFC1883"/>
	<xref target="RFC2460"/>,	<xref target="RFC2460"/>,
	Hop-by-Hop options were	Hop-by-Hop options were
	required to be processed by all nodes: routers and hosts. This proved to	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	not be practical in current high speed routers, as observed in <xref target=
	2.2 of RFC7045: "it is to be expected that high-performance routers will	"RFC7045" sectionFormat="of" section="2.2"/>: "it is to be expected that high-pe
		rformance routers will
	either ignore it or assign packets containing it to a slow processing	either ignore it or assign packets containing it to a slow processing

	path". The reason behind this includes:</t>	path". The reasons behind this include the following:</t>

	<ul spacing="normal">	<ul spacing="normal">


	<li>Inability to process Hop-by-Hop options at the full forwarding	<li>The inability to process Hop-by-Hop options at the Full Forwarding
	rate can result in issues.	Rate can result in issues.
	In some cases, Hop-by-Hop options would be sent to the	In some cases, Hop-by-Hop options would be sent to the

	control/management components that run on the slow path.	control/management components that run on the Slow Path.
	This could degrade a router's performance and also its ability to proces s	This could degrade a router's performance and also its ability to proces s

	critical control traffic.	critical control traffic, both of which could be exploited as a
	Both of which could be exploited as a	Denial-of-Service (DoS) attack against the router.</li>
	Denial-of-Service attack against the router.</li>

	<li>If a subset of packets within a flow includes Hop-by-Hop	<li>If a subset of packets within a flow includes Hop-by-Hop

	options, this could lead to an increased number of reordered	options, it could lead to an increased number of reordered
	packets and greater reordering distances for packets delivered to	packets and greater reordering distances for packets delivered to
	the destination.	the destination.
	Such reordering could occur if the Hop-by-Hop	Such reordering could occur if the Hop-by-Hop
	Options header is included	Options header is included

	only in some packets, or if a specific Hop-by-Hop option results	only in some packets or if a specific Hop-by-Hop option results
	in different processing for some of the packets within the	in different processing for some of the packets within the
	flow. Significant reordering of packets within a flow can	flow. Significant reordering of packets within a flow can
	negatively impact the performance of upper-layer protocols and	negatively impact the performance of upper-layer protocols and
	should therefore be avoided.	should therefore be avoided.
	</li>	</li>

	<li>Packets could include multiple Hop-by-Hop options. Too many	<li>Packets could include multiple Hop-by-Hop options. Too many
	options could make the	options could make the
	previous issues worse by increasing the resources required to process	previous issues worse by increasing the resources required to process
	them. The total size of the options determines the number of header byte s	them. The total size of the options determines the number of header byte s

	that might need to be processed.	that might need to be processed. Measurements <xref target="Cus23a"/> sh
	Measurements <xref target="Cus23a"/> show	ow
	that the probability of successful transmission across the	that the probability of successful transmission across the
	public Internet is currently	public Internet is currently

	higher for packets that include Options when it results in a	higher for packets that include Options that result in a short
	short total Extension Header (EH) Chain size (i.e., less than 40 bytes).	total Extension Header (EH) Chain size (i.e., less than 40 bytes).</li>
	</li>

	</ul>	</ul>


	<t>	<t><xref target="RFC6564"/> specifies a uniform format for new IPv6 Extensio
	<xref target="RFC6564"/> specified a uniform format for new IPv6 Extension H	n
	eaders. It updated	Headers, and this update was incorporated into
	<xref target="RFC2460"/>, and this update was incorporated into Section 4.8	<xref target="RFC8200" sectionFormat="of" section="4.8"/> (note that
	of	<xref target="RFC8200"/> obsoleted <xref target="RFC2460"/>).</t>
	<xref target="RFC8200"/>.
	</t>


	<t>When the IPv6 Specification was updated and published in	<t>When the IPv6 protocol specification was updated and published in
	July 2017 as	July 2017 as
	<xref target="RFC8200"/>, the procedures relating to Hop-by-Hop options	<xref target="RFC8200"/>, the procedures relating to Hop-by-Hop options

	were specified (<xref target="RFC8200"/>, Section 4) as follows:</t>	were specified (paragraphs 5 and 6 of <xref target="RFC8200" sectionFormat="
		of" section="4"/>) as follows:</t>
	<ul empty="true">


	<li>The Hop-by-Hop Options header is not inserted or deleted, but may be	<blockquote><t>
		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,	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	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 case of multicast) identified in the Destination Address field of
	the IPv6 header. The Hop-by-Hop Options header, when present, must	the IPv6 header. The Hop-by-Hop Options header, when present, must
	immediately follow the IPv6 header. Its presence is indicated by the	immediately follow the IPv6 header. Its presence is indicated by the

	value zero in the Next Header field of the IPv6 header.</li>	value zero in the Next Header field of the IPv6 header.</t>
		<t>
	<li>NOTE: While <xref target="RFC2460"/> required that all nodes	NOTE: While <xref target="RFC2460"/> required that all nodes
	must examine and process the Hop-by-Hop Options header, it is now	must examine and process the Hop-by-Hop Options header, it is now
	expected that nodes along a packet's delivery path only examine	expected that nodes along a packet's delivery path only examine
	and process the Hop-by-Hop Options header if explicitly configured	and process the Hop-by-Hop Options header if explicitly configured

	to do so.</li>	to do so.</t>
	</ul>	</blockquote>

	<t>	<t>

	The changes meant that an implementation complied with the IPv6	The changes meant that an implementation complied with the IPv6 protocol
	specification even if it did not process Hop-by-Hop options, and that	specification even if it did not process Hop-by-Hop options and that
	it was expected that routers would add configuration information to	routers were expected to add configuration information to
	control whether they process the Hop-by-Hop Options header.	control whether they process the Hop-by-Hop Options header.
	In practice, routers may include configuration options to control	In practice, routers may include configuration options to control
	which Hop-by-Hop options they will process.</t>	which Hop-by-Hop options they will process.</t>


	<t>The text regarding processing of Hop-by-Hop options in <xref	<t>The text regarding the processing of Hop-by-Hop options in <xref
	target="RFC8200"/> was not intended to change the processing of these	target="RFC8200"/> was not intended to change the processing of these
	options. It documented how they were being used in	options. It documented how they were being used in

	the Internet at the time RFC 8200 was published (see Appendix B of <xref	the Internet at the time RFC 8200 was published (see <xref
	target="RFC8200"/>). This was a constraint on	target="RFC8200" sectionFormat="of" section="B"/>). This was a constraint o
	publishing the IPv6 specification as an IETF Standard.</t>	n
		publishing the IPv6 protocol specification as an IETF Standard.</t>

	<t>The main issues remain:</t>	<t>The main issues remain:</t>

	<ul spacing="normal">	<ul spacing="normal">
	<li>Routers can be configured	<li>Routers can be configured

	to drop transit packets containing Hop-by-Hop Options that would	to drop transit packets containing Hop-by-Hop Options that
	have required processing by a processor that implements the control plan	require processing by a processor that implements the Control Plane.
	e.	This could be done to protect against a DoS attack on the
	This could be done to protect against a Denial-of-Service attack on the	router <xref target="RFC9098"/> <xref target="RFC9288"/>.</li>
	router <xref target="RFC9098"/><xref target="RFC9288"/>.</li>


	<li>IPv6 Packets that include a Hop-by-Hop Options header are dropped	<li>IPv6 packets that include a Hop-by-Hop Options header are dropped
	by some Internet paths.	by some Internet paths.

	A survey in 2015 reported a high loss rate in transit ASs for packets	A survey in 2015 reported a high loss rate in transit Autonomous Systems
	with Hop-by-Hop options <xref target="RFC7872"/>.	(ASes) for packets that include
	The operational implications of IPv6 Packets that include	Hop-by-Hop options <xref target="RFC7872"/>.
		The operational implications of IPv6 packets that include
	Extension Headers are discussed in <xref target="RFC9098"/>.	Extension Headers are discussed in <xref target="RFC9098"/>.

	Measurements in 2023 confirm this to still be the case for many types of
		Measurements taken in 2023 confirm this to still be the case for many ty
		pes of
	network paths <xref target="Cus23b"/>. </li>	network paths <xref target="Cus23b"/>. </li>

	<li>Allowing multiple Hop-by-Hop options in a single packet in some case s	<li>Allowing multiple Hop-by-Hop options in a single packet in some case s
	consumes more router resources to process these packets. It also adds	consumes more router resources to process these packets. It also adds
	complexity to the number of permutations that might need to be	complexity to the number of permutations that might need to be
	processed/configured.</li>	processed/configured.</li>

	<li>Including larger or multiple Hop-by-Hop options in a	<li>Including larger or multiple Hop-by-Hop options in a
	Hop-by-Hop Options header increases	Hop-by-Hop Options header increases
	the number of bytes that need to be processed in forwarding,	the number of bytes that need to be processed in forwarding,

	which can in some designs impact	which in some designs can impact
	the cost of processing a packet, and in turn could increase the probabil ity of	the cost of processing a packet, and in turn could increase the probabil ity of
	drop <xref target="RFC7872"/>. A larger Extension Header	drop <xref target="RFC7872"/>. A larger Extension Header

	could also reduce the probability that a router can locate all	could also reduce the probability of a router locating all
	the header bytes required to successfully process	the header bytes required to successfully process
	an access control list operating on fields after the Hop-by-Hop	an access control list operating on fields after the Hop-by-Hop
	Options header.</li>	Options header.</li>

	<li>Any option that can be used to force packets into the	<li>Any option that can be used to force packets into the

	processor that implements the router's control plane can be	processor that implements the router's Control Plane can be
	exploited as a Denial-of-Service	exploited as a DoS
	attack on a transit router by saturating the resources needed for	attack on a transit router by saturating the resources needed for
	router management protocols (routing protocols, network management	router management protocols (routing protocols, network management

	protocols, etc.), that could cause adverse router operation.	protocols, etc.), which could cause adverse router operation.

	This is an issue for the	This is an issue for the

	Router Alert Hop-by-Hop Option <xref target="RFC2711"/>, which	Router Alert Option <xref target="RFC2711"/>, which
	intentionally forwards packets to the control plane,	intentionally forwards packets to the Control Plane
	and is discussed in <xref target="RFC6398"/>.	as discussed in <xref target="RFC6398"/>.
	This impact could be mitigated by limiting	This impact could be mitigated by limiting

	the use of control plane resources by a specific packet, and/or	the use of Control Plane resources by a specific packet and/or
	by the use of per-function rate-limiters for packets processed	by using per-function rate-limiters for packets processed
	by the control plane.	by the Control Plane.
	</li>	</li>

	</ul>	</ul>


	<t> Section 3 of RFC 6398 includes a summary of processing the IP Router Ale rt Option:</t>	<t><xref target="RFC6398" sectionFormat="of" section="3"/> includes a summar y of processing the IP Router Alert Option:</t>


	<ul empty="true" spacing="normal">	<blockquote>
	<li>"In a nutshell, the IP Router Alert Option does not provide a	In a nutshell, the IP Router Alert Option does not provide a
	convenient universal mechanism to accurately and reliably distinguish	convenient universal mechanism to accurately and reliably distinguish
	between IP Router Alert packets of interest and unwanted IP Router	between IP Router Alert packets of interest and unwanted IP Router
	Alert packets. This, in turn, creates a security concern when the IP	Alert packets. This, in turn, creates a security concern when the IP

	Router Alert option is used, because, short of appropriate	Router Alert Option is used, because, short of appropriate
	router-implementation-specific mechanisms, the router Slow Path is at ri	router-implementation-specific mechanisms, the router slow path is at ri
	sk	sk
	of being flooded by unwanted traffic."	of being flooded by unwanted traffic.
	</li>	</blockquote>
	</ul>

	<t>This is an example of the need to limit the resources that can	<t>This is an example of the need to limit the resources that can
	be consumed when a particular function is executed and to avoid consumin g	be consumed when a particular function is executed and to avoid consumin g

	control-plane resources	Control Plane resources
	where support for a function has not been configured.</t>	where support for a function has not been configured.</t>

	<t>There has been research that has discussed	<t>There has been research that has discussed
	the general problem with dropping packets containing IPv6 Extension	the general problem with dropping packets containing IPv6 Extension
	Headers, including the Hop-by-Hop Options header.	Headers, including the Hop-by-Hop Options header.

	For example, <xref target="Hendriks"/> states that "dropping all	For example, <xref target="Hendriks"/> states that "Dropping all
	packets with Extension Headers, is a bad practice", and that "The share	packets that contain Extension Headers is a bad practice" and that "The shar
		e
	of traffic containing more than one EH however, is very small. For the	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	design of hardware able to handle the dynamic nature of EHs, we therefore
	recommend to support at least one EH". Operational aspects of the topics	recommend to support at least one EH". Operational aspects of the topics
	discussed in this section are further discussed in <xref target="I-D.ietf-v6 ops-hbh"/>.</t>	discussed in this section are further discussed in <xref target="I-D.ietf-v6 ops-hbh"/>.</t>

	<t>"Transmission and Processing of IPv6 Extension Headers" <xref	<t>"Transmission and Processing of IPv6 Extension Headers" <xref

	target="RFC7045"/> clarified how intermediate nodes should process	target="RFC7045"/> clarifies how intermediate nodes should process
	Extension Headers. The present document is generally consistent with	Extension Headers. This document is generally consistent with
	<xref target="RFC7045"/>, and addresses an issue that was raised for	<xref target="RFC7045"/> and addresses an issue that was raised for
	discussion when <xref target="RFC2460"/> was updated and replaced by	discussion when <xref target="RFC2460"/> was updated and replaced by
	<xref target="RFC8200"/>. This document updates <xref	<xref target="RFC8200"/>. This document updates <xref
	target="RFC8200"/> as described in the next section and consequently	target="RFC8200"/> as described in the next section and consequently

	clarifies the description in Section 2.2 of <xref target="RFC7045"/>,	clarifies the description in <xref target="RFC7045" sectionFormat="of" secti on="2.2"/>,
	using the language of BCP 14 <xref target="RFC2119"/> <xref	using the language of BCP 14 <xref target="RFC2119"/> <xref
	target="RFC8174"/>.</t>	target="RFC8174"/>.</t>

	<t>This document defines a set of procedures for the Hop-by-Hop	<t>This document defines a set of procedures for the Hop-by-Hop
	Options header that are intended to make the processing of Hop-by-Hop	Options header that are intended to make the processing of Hop-by-Hop
	options practical in modern routers. The common cases are	options practical in modern routers. The common cases are
	that some Hop-by-Hop options will be processed across the Internet,	that some Hop-by-Hop options will be processed across the Internet,
	while others will only be processed within a limited domain <xref	while others will only be processed within a limited domain <xref
	target="RFC8799"/> (e.g., where a specific service is made available	target="RFC8799"/> (e.g., where a specific service is made available
	in that network segment that relies on one or more Hop-by-Hop	in that network segment that relies on one or more Hop-by-Hop
	options).</t>	options).</t>


	</section> <!-- BACKGRUND -->	</section>


	<section anchor="HBH" title="Hop-by-Hop Header Processing Procedures">	<section anchor="HBH">
		<name>Hop-by-Hop Header Processing Procedures</name>

	<t>This section describes several changes to <xref	<t>This section describes several changes to <xref

	target="RFC8200"/>. <xref target="FAST"/> describes processing of the	target="RFC8200"/>. <xref target="FAST"/> describes the processing of
	Hop-by-Hop options Extension	the Hop-by-Hop options Extension Header, and <xref target="ONE"/> describes
	Header, and <xref target="ONE"/> describes	the processing of individual Hop-by-Hop options.
	processing of individual Hop-by-Hop Options.	These sections update the text in paragraph 6 of
	These sections updates the text in paragraphs 5 and 6 of Section 4 of	<xref target="RFC8200" sectionFormat="of" section="4"/> and, as noted in <xre
	<xref target="RFC8200"/> and as noted in <xref target="ONE"/> modifies Sectio	f target="ONE"/>, modify
	n 4.2 of	<xref target="RFC8200" sectionFormat="of" section="4.2"/>.</t>
	<xref target="RFC8200"/>.</t>


	<section anchor="FAST" title="Processing the Extension Header Carrying Hop-b	<section anchor="FAST">
	y-Hop Options">	<name>Processing the Extension Header Carrying Hop-by-Hop Options</name>

	<t>When a packet includes one or more Extension Headers, the Next Header	<t>When a packet includes one or more Extension Headers, the Next Header
	field of the IPv6 Header identifies the type of Extension Header.	field of the IPv6 Header identifies the type of Extension Header.
	It does not identify the transport protocol.</t>	It does not identify the transport protocol.</t>

	<t>The Extension Header used to carry Hop-by-Hop options	<t>The Extension Header used to carry Hop-by-Hop options

	is defined in Section 4.3 of <xref target="RFC8200"/> and is identified	is defined in <xref target="RFC8200" sectionFormat="of" section="4.3"/> a nd is identified
	by a Next Header value of 0 in the IPv6	by a Next Header value of 0 in the IPv6

	header. Section 4.1 of <xref target="RFC8200"/> requires this Hop-by-Ho p	header. <xref target="RFC8200" sectionFormat="of" section="4.1"/> requi res this Hop-by-Hop
	Options header to appear immediately after the IPv6 header. <xref	Options header to appear immediately after the IPv6 header. <xref
	target="RFC8200"/> also requires that a Hop-by-Hop Options header	target="RFC8200"/> also requires that a Hop-by-Hop Options header
	only appear at most once in a packet.</t>	only appear at most once in a packet.</t>


	<t>The Hop-by-Hop Options Header as defined in	<t>The Hop-by-Hop Options header as defined in
	<xref target="RFC8200"/> can contain	<xref target="RFC8200"/> can contain
	one or more Hop-by-Hop options.</t>	one or more Hop-by-Hop options.</t>


	<t>Routers that process the Hop-by-Hop Options header SHOULD do	<t>Routers that process the Hop-by-Hop Options header <bcp14>SHOULD</bcp 14> do
	so using the method defined in this document.	so using the method defined in this document.

	Exceptions to this "SHOULD" include routers that are configured to	Exceptions to this <bcp14>SHOULD</bcp14> include routers that are configu red to
	drop packets with a Hop-by-Hop Options header to protect	drop packets with a Hop-by-Hop Options header to protect
	downstream devices that do not comply with this	downstream devices that do not comply with this
	specification (see <xref target="RFC9288"/>).</t>	specification (see <xref target="RFC9288"/>).</t>

	<t>Even if a router does not process the Hop-by-Hop Options	<t>Even if a router does not process the Hop-by-Hop Options

	header (for example, based on configuration), it MUST forward the	header (for example, when based on configuration), it <bcp14>MUST</bcp14 > forward the
	packet normally based on the remaining Extension Header(s) after	packet normally based on the remaining Extension Header(s) after

	the Hop-by-Hop Options header. A router MUST NOT drop a packet	the Hop-by-Hop Options header. A router <bcp14>MUST NOT</bcp14> drop a packet
	solely because it contains an Extension Header carrying	solely because it contains an Extension Header carrying

	Hop-by-Hop options. A configuration could control that normal	Hop-by-Hop options. A configuration could control whether normal
	processing skips any or all of the Hop-by-Hop options carried in	processing skips any or all of the Hop-by-Hop options carried in
	the Hop-by-Hop Options header.</t>	the Hop-by-Hop Options header.</t>

	<t>It is expected that the Hop-by-Hop Options header will be	<t>It is expected that the Hop-by-Hop Options header will be
	processed by the destination(s).	processed by the destination(s).

	Hosts SHOULD process the Hop-by-Hop Options header in	Hosts <bcp14>SHOULD</bcp14> process the Hop-by-Hop Options header in
	received packets. A constrained host is an example of a node	received packets. A constrained host is an example of a node
	that does not process the Hop-by-Hop Options header.	that does not process the Hop-by-Hop Options header.
	If a destination does not process the 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.	it <bcp14>MUST</bcp14> process the remainder of the packet normally.
	<!--
	Additional recommendations for host processing are described in
	<xref target="I-D.ietf-6man-eh-limits"/>.
	-->
	</t>	</t>


	<section anchor="CONFIG" title="Configuration Enabling Hop-by-Hop Header Pro	<section anchor="CONFIG">
	cessing">	<name>Configuration Enabling Hop-by-Hop Header Processing</name>


	<t> Section 4 of	<t><xref target="RFC8200" sectionFormat="of" section="4"/> allows a rout
	<xref target="RFC8200"/> allows a router to control its processing	er to control its processing
	of IPv6 Hop-by-Hop options by local configuration. The text is:</t>	of IPv6 Hop-by-Hop options by local configuration. The text is:</t>

		<blockquote>
	<ul empty="true">	NOTE: While <xref target="RFC2460"/> required that all nodes must exa
	<li>NOTE: While <xref target="RFC2460"/> required that all nodes must	mine and
	examine and
	process the Hop-by-Hop Options header, it is now expected that nodes	process the Hop-by-Hop Options header, it is now expected that nodes
	along the path only examine and process the	along the path only examine and process the

	Hop-by-Hop Options header if explicitly configured to do so.</li>	Hop-by-Hop Options header if explicitly configured to do so.
	</ul>	</blockquote>


	<t>This document clarifies that a configuration could control	<t>
	whether processing skips	This document clarifies that a configuration could control whether
	any specific Hop-by-Hop options	processing skips any specific Hop-by-Hop options carried in the Hop-
	carried in the Hop-by-Hop	by-Hop Options header. A router that does not process the contents
	Options header. A router that does not process the contents of	of the Hop-by-Hop Options header does not process any of the
		option types contained in the Hop-by-Hop Options header.
		</t>
		<!--
		Original text:
		A router that does not process the contents of
	the Hop-by-Hop Options header does not therefore process the	the Hop-by-Hop Options header does not therefore process the
	option types of individual Option Types to perform any specified	option types of individual Option Types to perform any specified

	action.</t>	action.
		-->


	</section> <!-- CONFIG -->	</section>
	</section> <!-- FAST -->	</section>


	<section anchor="ONE" title="Hop-by-Hop Options Processing">	<section anchor="ONE">
		<name>Hop-by-Hop Options Processing</name>


	<t>A source creating packets with a Hop-by-Hop Options header SHOULD use	<t>A Source creating packets with a Hop-by-Hop Options header <bcp14>SHO ULD</bcp14> use
	a method that is robust to network nodes selectively processing only	a method that is robust to network nodes selectively processing only

	some of the	some of the Hop-by-Hop options that are included in the packet or tha
	Hop-by-Hop options that are included in the packet, or that forward	t forward
	packets without the option(s) being processed (see <xref target="HOW" />).	packets without the option(s) being processed (see <xref target="HOW" />).


	A source MAY, based on local configuration,	A Source <bcp14>MAY</bcp14>, based on local configuration,
	allow only one Hop-by-Hop option to be included in a packet,	allow only one Hop-by-Hop option to be included in a packet,

	or could allow more than one Hop-by-Hop options,	or it could allow more than one Hop-by-Hop option
	<!--
	<xref target="I-D.ietf-6man-eh-limits"/>
	-->
	but limit their size to increase the likelihood of successful	but limit their size to increase the likelihood of successful
	transfer across a network path.	transfer across a network path.
	Because some routers might only process one or a limited number of	Because some routers might only process one or a limited number of

	options in the Hop-by-Hop Option header, sources are motivated to	options in the Hop-by-Hop Options header, Sources are motivated to
	order the placement of Hop-by-Hop options within the Hop-by-Hop	order the placement of Hop-by-Hop options within the Hop-by-Hop
	Options header in decreasing order of importance for their	Options header in decreasing order of importance for their
	processing by nodes on the path.	processing by nodes on the path.
	</t>	</t>

	<t>A router configuration needs to avoid vulnerabilities that	<t>A router configuration needs to avoid vulnerabilities that

	arise when it cannot process the first Hop-by-Hop option at full	arise when it cannot process the first Hop-by-Hop option at the Full
	forwarding rate. A router SHOULD NOT therefore be configured to	Forwarding Rate. Therefore, a router <bcp14>SHOULD NOT</bcp14> be confi
		gured to
	process the first Hop-by-Hop option if this adversely impacts the	process the first Hop-by-Hop option if this adversely impacts the

	aggregate forwarding rate. A router SHOULD process additional	aggregate forwarding rate. A router <bcp14>SHOULD</bcp14> process addit ional
	Hop-by-Hop options, if configured to do so, providing that these	Hop-by-Hop options, if configured to do so, providing that these
	also do not adversely impact the aggregate forwarding rate.</t>	also do not adversely impact the aggregate forwarding rate.</t>


	<!--
	<t>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 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 whether these also do not
	adversely impact the aggregate forwarding rate.</t>

	<t>If a router is unable to process a specific Hop-by-Hop option	<t>If a router is unable to process a specific Hop-by-Hop option
	(or is not configured to do so), it	(or is not configured to do so), it

	SHOULD behave in the way specified for an unrecognized Option Type when	<bcp14>SHOULD</bcp14> behave in the same way specified for an unrecogniz
	the	ed Option Type when the
	action bits were set to "00" and	action bits are set to "00", and it
	SHOULD skip the remaining options	<bcp14>SHOULD</bcp14> skip the remaining options
	using the "Hdr Ext Len" field in the	using the "Hdr Ext Len" field in the
	Hop-by-Hop Options header. This field specifies the length of the Optio ns	Hop-by-Hop Options header. This field specifies the length of the Optio ns
	Header in 8-octet units. After skipping an option, the router continues	Header in 8-octet units. After skipping an option, the router continues
	processing the remaining options in the header.	processing the remaining options in the header.
	Skipped options do not need to be verified.</t>	Skipped options do not need to be verified.</t>

	<t>The Router	<t>The Router
	Alert Option <xref target="RFC2711"/> is an exception	Alert Option <xref target="RFC2711"/> is an exception
	to this because it is designed to tell a router	to this because it is designed to tell a router

	that the packet needs additional processing, usually done	that the packet needs additional processing, which is usually done
	in the control plane, see <xref target="RTRALERT"/>.	in the Control Plane; see <xref target="RTRALERT"/>.
	</t>	</t>


	<t>Section 4.2 of <xref target="RFC8200"/>	<t><xref target="RFC8200" sectionFormat="of" section="4.2"/>
	defines the Option Type identifiers as internally encoded such that thei r	defines the Option Type identifiers as internally encoded such that thei r
	highest-order 2 bits specify the action that must be taken if the	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:</	processing IPv6 node does not recognize the Option Type. The text is:</t
	t>	>

		<!--NOTE: authors requested that the quoted text below not be in <blockquote>. I
		t should exactly match the formatting in RFC 8200.
		-->

	<artwork align="left" name="" type="" alt=""><![CDATA[	<artwork align="left" name="" type="" alt=""><![CDATA[
	00 - skip over this option and continue processing the header.	00 - skip over this option and continue processing the header.

	01 - discard the packet.	01 - discard the packet.

	10 - discard the packet and, regardless of whether or not the	10 - discard the packet and, regardless of whether or not the

	packet's Destination Address was a multicast address, send an	packet's Destination Address was a multicast address,
	ICMPv6 Parameter Problem, Code 2 [RFC4443], message to the	send an ICMP Parameter Problem, Code 2, message to the
	packet's Source Address, pointing to the unrecognized Option	packet's Source Address, pointing to the unrecognized
	Type.	Option Type.

	11 - discard the packet and, only if the packet's Destination	11 - discard the packet and, only if the packet's Destination

	Address was not a multicast address, send an ICMPv6 Parameter	Address was not a multicast address, send an ICMP Parameter
	Problem, Code 2, message to the packet's Source Address,	Problem, Code 2, message to the packet's Source Address,
	pointing to the unrecognized Option Type.	pointing to the unrecognized Option Type.
	]]></artwork>	]]></artwork>


	<t>This document modifies this behaviour for the "01", "10", and	<t>This document modifies this behavior for the "01", "10", and
	"11" action bits, so that if a router is unable to process a specific Hop	"11" action bits so that if a router is unable to process a specific Hop-
	-by-Hop option	by-Hop option
	(or is not configured to do so), it SHOULD behave in the way	(or is not configured to do so), it <bcp14>SHOULD</bcp14> behave in the
		same way
	specified for an unrecognized Option Type when the	specified for an unrecognized Option Type when the

	action bits were set to "00".	action bits are set to "00".


	It also modifies the behaviour for the "10" and "11" values for	It also modifies the behavior for values "10" and "11" in the case where
	the case when the packet is discarded, the	the packet is discarded and the
	node MAY send an ICMP Parameter Problem, Code 2 <xref target="RFC4443"/>	node <bcp14>MAY</bcp14> send an ICMP Parameter Problem, Code 2 <xref tar
	, message to the	get="RFC4443"/>,
	packet's Source Address,	message to the packet's Source Address, pointing to the unrecognized Opti
	pointing to the unrecognized Option Type.</t>	on Type.</t>


	<t>The modified text for "01", "10", and "11" values is:</t>	<t>The modified text for values "01", "10", and "11" is:</t>

	<artwork align="left" name="" type="" alt=""><![CDATA[	<artwork align="left" name="" type="" alt=""><![CDATA[

	01 - MAY discard the packet, if so configured. Nodes should not	01 - MAY discard the packet, if so configured. Nodes should not
	rely on routers dropping these unrecognized Option Types.	rely on routers dropping these unrecognized Option Types.

	10 - MAY discard the packet, if so configured, and, regardless of
	whether or not the packet's Destination Address was a
	multicast address. If the packet was discarded, it 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, if so configured. Only if the
	packet was discarded and the
	packet's Destination Address was not a multicast address,
	it MAY send an ICMP Parameter
	Problem, Code 2, message to the packet's Source Address,
	pointing to the unrecognized Option Type.


	]]></artwork>	10 - MAY discard the packet, if so configured, regardless of
		whether or not the packet's Destination Address was a
		multicast address. If the packet was discarded, an ICMP
		Parameter Problem, Code 2, message MAY be sent to the
		packet's Source Address, pointing to the unrecognized
		Option Type.


	<!--	11 - MAY discard the packet, if so configured. If the packet
	<t>When a node sends an ICMP message in response to a packet with	was discarded and the packet's Destination Address was
	a multicast destination address, this could be exploited as an	not a multicast address, an ICMP Parameter Problem,
	amplification attack. This is particularly problematic when the	Code 2, message MAY be sent to the packet's Source
	Source Address is not valid (which can be mitigated to varying	Address, pointing to the unrecognized Option Type.
	degrees by using a reverse path forwarding (RPF) check). A node	]]></artwork>
	SHOULD NOT send ICMP messages in response to a packet with a
	multicast destination address unless this is enabled for the
	specific Source Address and/or the group Destination Address.</t>

	<t>When an ICMP Parameter Problem, Code 2, message is delivered to the	<t>When an ICMP Parameter Problem, Code 2, message is delivered to the

	source, it	Source, it
	indicates that at least one node on the	indicates that at least one node on the
	path has failed to recognize the option <xref target="RFC4443"/>.	path has failed to recognize the option <xref target="RFC4443"/>.
	Generating any ICMP message	Generating any ICMP message
	incurs additional router processing.	incurs additional router processing.
	Reception of this message is	Reception of this message is

	not guaranteed,	not guaranteed;
	routers might be unable to be configured so that they do not generate	routers might be unable to be configured so that they do not generate
	these messages,	these messages,

	and they are not always forwarded to the source.	and they are not always forwarded to the Source.
	The motivation here is to loosen	The motivation here is to loosen
	the requirement to send an ICMPv6 Parameter Problem message when a route r	the requirement to send an ICMPv6 Parameter Problem message when a route r
	forwards a packet without processing the list of all options.</t>	forwards a packet without processing the list of all options.</t>


	<section anchor="RTRALERT" title="Router Alert Option">	<section anchor="RTRALERT">
		<name>Router Alert Option</name>

	<t>The purpose of the Router Alert Option <xref target="RFC2711"/> is to tell	<t>The purpose of the Router Alert Option <xref target="RFC2711"/> is to tell

	a router that the packet needs additional processing in the control plan e.	a router that the packet needs additional processing in the Control Plan e.
	</t>	</t>


	<t>The Router Alert Option includes a two-octet Value field that	<t>The Router Alert Option includes a two-octet Value field that

	describes the protocol that is carried in the packet. The	describes the protocol that is carried in the packet.
		The
	current specified values can	current specified values can

	be found in the IANA Router Alert Value registry <xref	be found in the "IPv6 Router Alert Option Values" IANA registry <xref
	target="IANA-RA"/>.</t>	target="IANA-RA"/>.</t>

	<t>DISCUSSION</t>	<t>DISCUSSION</t>

		<t indent="3">The function of a Router Alert Option can result in the pr
		ocessing
		that this specification is proposing to eliminate, that is,
		instructing a router to process the packet in the Control Plane.
		This processing causes concerns, which are discussed in <xref target="BACKGROUN
		D"/>.
		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.</t>


	<ul empty="true" spacing="normal">	<t indent="3">The Router Alert Option could potentially be used with new
	<li> The function of a Router Alert Option can result in the processing	functions that have to be processed in the Control Plane. Keeping
	that this specification is proposing to eliminate, that is, to instruct	this as the single exception for processing in the Control Plane
	a router to process the packet in the control plane.	with the restrictions that follow is a reasonable compromise to
	This results in the concerns discussed in section 4.	allow future flexibility. These restrictions are compatible
	One approach would be to deprecate this, because current usage beyond	with <xref target="RFC6398" sectionFormat="of" section="5"/>.</t>
	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.</li>

	<li>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 restrictions are compatible with Section 5 of <xref target="RFC639
	8"/>.</li>
	</ul>

	<t>	<t>
	As noted in <xref target="RFC6398"/>,	As noted in <xref target="RFC6398"/>,

	"Implementations of the IP Router Alert option	"Implementations of the IP Router Alert Option
	SHOULD offer the configuration option to simply ignore the presence	<bcp14>SHOULD</bcp14> offer the configuration option to simply ignore th
	of the IP Router Alert in IPv4 and IPv6 packets."</t>	e presence
		of 'IP Router Alert' in IPv4 and IPv6 packets."</t>


	<t>A node that is configured to process a Router Alert option	<t>A node that is configured to process a Router Alert Option
	MUST protect itself from infrastructure attack	<bcp14>MUST</bcp14> protect itself from an infrastructure attack
	that could result from processing in the control plane. This might inclu	that could result from processing in the Control Plane. This might inclu
	de	de
	some combination of an access control list to only permit this from trus	some combination of an access control list to only permit access from tr
	ted nodes,	usted nodes,
	rate limiting of processing, or other methods <xref target="RFC6398"/>.< /t>	rate limiting of processing, or other methods <xref target="RFC6398"/>.< /t>


	<t>As specified in <xref target="RFC2711"/> the top two bits of Option T	<t>As specified in <xref target="RFC2711"/>, the top two bits of the Opt
	ype	ion Type
	for the Router Alert Option are always set to "00" indicating the node	for the Router Alert Option are always set to "00", indicating that the
		node
	should skip over this option as if it does not recognize the Option	should skip over this option as if it does not recognize the Option
	Type and continue processing the header.	Type and continue processing the header.
	An implementation that does recognize the Router Alert Option	An implementation that does recognize the Router Alert Option

	SHOULD verify that a Router Alert Option contains a	<bcp14>SHOULD</bcp14> verify that the Router Alert Option contains a
	protocol, as indicated by the Value field in the Router Alert Option,	protocol, as indicated by the Value field in the Router Alert Option,
	that is configured as a protocol of interest to that	that is configured as a protocol of interest to that

	router. A verified packet SHOULD be sent to the control plane for furth	router. A verified packet <bcp14>SHOULD</bcp14> be sent to the Control
	er processing	Plane for further processing
	<xref target="RFC6398"/>. Otherwise, the router implementation SHOULD f	<xref target="RFC6398"/>. Otherwise, the router implementation <bcp14>S
	orward	HOULD</bcp14> forward
	this packet subject to all normal policies and forwarding rules.	this packet subject to all normal policies and forwarding rules.
	</t>	</t>


	</section> <!-- Router Alert option -->	</section>


	<section anchor="CONFIG2" title="Configuration of Hop-by-Hop Option Processi	<section anchor="CONFIG2">
	ng">	<name>Configuration of Hop-by-Hop Options Processing</name>

	<t>A router can be configured to process a specific Option. The set	<t>A router can be configured to process a specific Option. The set

	of enabled options SHOULD be configurable by the operator of the	of enabled options <bcp14>SHOULD</bcp14> be configurable by the operator o f the
	router.</t>	router.</t>

	<t>A possible approach to implementing this is to maintain a lookup	<t>A possible approach to implementing this is to maintain a lookup

	table based on Option Type of the IPv6 options that can be	table based on an Option Type of the IPv6 options that can be
	processed at full forwarding rate. This would allow a router to	processed at the Full Forwarding Rate. This would allow a router to
	quickly determine if an option is supported and can be processed.	quickly determine if an option is supported and can be processed.
	If the option is not supported, then the router processes the	If the option is not supported, then the router processes the
	option as described in <xref target="FAST"/> of this document.</t>	option as described in <xref target="FAST"/> of this document.</t>


	<!--
	<t>A router can be configured to process a specific Option. 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 determine if an option is supported and can be
	processed. If the option is not supported, then the router processes the o
	ption as
	described in <xref target="FAST"/> of this document.</t>

	<t>The actions of the lookup table should be configurable by the operator of	<t>The actions of the lookup table should be configurable by the operator of
	the router.</t>	the router.</t>

	</section> <!-- Config options -->	</section>
	</section><!-- Options -->	</section>


	</section> <!-- HBH -->	</section>


	<section anchor="NEW" title="Defining New Hop-by-Hop Options">	<section anchor="NEW">
		<name>Defining New Hop-by-Hop Options</name>


	<t>This section updates Section 4.8 of <xref target="RFC8200"/>.</t>	<t>This section updates <xref target="RFC8200" sectionFormat="of" section="4 .8"/>.</t>


	<t>Any new IPv6 Hop-by-Hop option designed in the future should be	<t>Any future new IPv6 Hop-by-Hop options should be designed to
	designed to be processed	be processed at the Full Forwarding Rate and should have the following chara
	at full forwarding rate.	cteristics:</t>
	New Hop-by-Hop options should have the following characteristics:</t>

	<ul spacing="normal">	<ul spacing="normal">

	<li>New Hop-by-Hop options should	<li>New Hop-by-Hop options should

	be designed to ensure the router can process the options at the full	be designed to ensure the router can process the options at the Full
	forwarding rate. That is, they should be simple to process.	Forwarding Rate. That is, they should be simple to process.
	</li>	</li>


	<li>New options should be defined with the Action type (highest-order 2	<li>New Hop-by-Hop options should be defined with the Action type (highe
	bits of the Option Type) set to 00 to skip over this option and continue	st-order 2
	processing the header if a router does not recognize the option.</li>	bits of the Option Type) set to "00", which enables skipping over this o
		ption
		and continuing with the processing of the header if a router does not rec
		ognize
		the option.</li>


	<li>The size of a Hop-by-Hop option should not extend beyond what can be	<li>The size of Hop-by-Hop options should not extend beyond what can be
	expected to be executed at full forwarding rate. A larger Hop-by-Hop	expected to be executed at the Full Forwarding Rate. A larger Hop-by-Ho
	Options header can increase the likelihood that that a packet will be	p
		Options header can increase the likelihood that a packet will be
	dropped <xref target="Cus23b"/>.	dropped <xref target="Cus23b"/>.
	</li>	</li>


	<li>New Hop-by-Hop options should be designed expecting that a router	<li>New Hop-by-Hop options should be designed with the expectation that a router
	might be configured to only process a subset of Hop-by-Hop options (e.g. , the first option) in the	might be configured to only process a subset of Hop-by-Hop options (e.g. , the first option) in the
	Hop-by-Hop Options header.</li>	Hop-by-Hop Options header.</li>

	<li>The design of protocols that use new Hop-by-Hop options should consi der	<li>The design of protocols that use new Hop-by-Hop options should consi der
	that a router may drop packets containing the new Hop-by-Hop option.	that a router may drop packets containing the new Hop-by-Hop option.
	</li>	</li>
	</ul>	</ul>


	<t>Any new Hop-by-Hop option that is standardized that does not meet	<t>If a new Hop-by-Hop option does not meet
	these criteria must include in the specification	these criteria, its specification must include a detailed
	a detailed explanation why this cannot be accomplished	explanation why that is the case and show that there
	and to show that there is a reasonable expectation	is a reasonable expectation that the option can still proceed at the Full
	that the option can be proceed at full forwarding rate.	Forwarding Rate. This is consistent with [RFC6564].
	This is consistent with <xref target="RFC6564"/>.</t>	This is consistent with <xref target="RFC6564"/>.</t>

	<t>The general issue of robust operation of packets with new	<t>The general issue of robust operation of packets with new

	Hop-by-Hop options is described in <xref target="HOW"/> below.</t>	Hop-by-Hop options is described in <xref target="HOW"/>.</t>


	<section anchor="HOW" title="Example of Robust Usage">	<section anchor="HOW">
		<name>Example of Robust Usage</name>
	<t>Recent measurement	<t>Recent measurement
	surveys (e.g., <xref target="Cus23a"/>)	surveys (e.g., <xref target="Cus23a"/>)
	show that packets that include Extension Headers can cause the packets t o	show that packets that include Extension Headers can cause the packets t o
	be dropped by some	be dropped by some
	Internet paths. In a limited domain, routers can be configured or update d	Internet paths. In a limited domain, routers can be configured or update d
	to provide support for any required Hop-by-Hop options.</t>	to provide support for any required Hop-by-Hop options.</t>

	<t>The primary motivation of this document is to make it	<t>The primary motivation of this document is to make it
	more practical to use Hop-by-Hop options beyond such a limited domain, w ith the	more practical to use Hop-by-Hop options beyond such a limited domain, w ith the
	expectation that applications can improve the	expectation that applications can improve the
	quality of or add new features to their offered service when	quality of or add new features to their offered service when
	the path successfully forwards packets with the required Hop-by-Hop opti ons	the path successfully forwards packets with the required Hop-by-Hop opti ons
	and otherwise refrains from using these options.	and otherwise refrains from using these options.
	The focus is on incremental deployability.	The focus is on incremental deployability.

	A protocol feature (such as using Hop-by-Hop options) is incrementally	A protocol feature (such as using Hop-by-Hop options) is incrementally
	deployable if early adopters gain some	deployable if early adopters gain some
	benefit on the paths being used, even though other paths do not support the	benefit on the paths being used, even though other paths do not support the
	protocol feature.	protocol feature.

	A source ought to order the Hop-by-Hop options that are carried	A Source ought to order the Hop-by-Hop options that are carried
	in the Hop-by-Hop Options header in decreasing order of	in the Hop-by-Hop Options header in decreasing order of
	importance for processing by nodes on the path.	importance for processing by nodes on the path.
	</t>	</t>

	<t>Methods can be developed that do not rely upon all routers	<t>Methods can be developed that do not rely upon all routers

	to implement a specific Hop-by-Hop option (e.g., <xref target="RFC9268"/ >),	to implement a specific Hop-by-Hop option (e.g., <xref target="RFC9268"/ >)
	and that are robust when the	and that are robust when the
	current path drops packets that contain a Hop-by-Hop option (e.g.,	current path drops packets that contain a Hop-by-Hop option (e.g.,
	<xref target="RFC9098"/>).</t>	<xref target="RFC9098"/>).</t>

	<t>For example, an application can be designed to first send	<t>For example, an application can be designed to first send
	a test packet that includes the required option or combination	a test packet that includes the required option or combination

	of options, and sends other packets without including	of options and then send other packets without including
	the option. The application then does not send additional	the option. The application does not send additional
	packets that include this option (or set of options) until the	packets that include this option (or set of options) until the
	test packet(s) is acknowledged.	test packet(s) is acknowledged.
	The need for potential loss recovery when a path drops	The need for potential loss recovery when a path drops
	these test packets can be avoided by choosing packets that do not	these test packets can be avoided by choosing packets that do not
	carry application data that needs to be reliably delivered.</t>	carry application data that needs to be reliably delivered.</t>

	<t>Since the set of nodes forming a path can change with time,	<t>Since the set of nodes forming a path can change with time,

	this discovery process ought to be repeated from time-to-time.	this discovery process ought to be repeated from time to time.
	The process of sending packets both with and without a specific	The process of sending packets both with and without a specific
	header to discover whether a path can support a specific header	header to discover whether a path can support a specific header
	is sometimes called "racing". Transport protocol racing	is sometimes called "racing". Transport protocol racing
	is explained in <xref target="I-D.ietf-taps-arch"/>,	is explained in <xref target="I-D.ietf-taps-arch"/>,

	and "A/B protocol feature testing" is described in <xref target="Tram17"	and A/B protocol feature testing is described in <xref target="Tram17"/>
	/>.</t>	.</t>

	</section> <!-- HOW -->


	</section> <!-- NEW -->	</section>


	<section anchor="IANA" title="IANA Considerations">	</section>


	<t>This document requires no assignment actions by IANA.</t>	<section anchor="IANA">
		<name>IANA Considerations</name>


	<t>The document updates the processing of	<t>This document updates the processing of
	Hop-by-Hop options.	Hop-by-Hop options.

	IANA is requested to add the published RFC as an	IANA has added this document as an
	additional reference	additional reference for the "Destination Options and Hop-by-Hop Options
	for "Destination Options and Hop-by-Hop Options"	" registry
	in the Internet Protocol Version 6 (IPv6) Parameters Registry. </t>	in the "Internet Protocol Version 6 (IPv6) Parameters" registry group <x
		ref target="IANA-HBH"/>.</t>
	</section>	</section>


	<section title="Security Considerations" anchor="Security">	<section anchor="Security">
		<name>Security Considerations</name>
	<t>Security issues with including IPv6 Hop-by-Hop options are well known and	<t>Security issues caused by including IPv6 Hop-by-Hop options are well know
	have	n and have
	been documented in several places, including	been documented in several places, including
	<xref target="RFC6398"/>,	<xref target="RFC6398"/>,

	<xref target="RFC6192"/>, <xref target="RFC7045"/> and	<xref target="RFC6192"/>, <xref target="RFC7045"/>, and
	<xref target="RFC9098"/>.	<xref target="RFC9098"/>.
	The main issue, as noted in <xref target="BACKGROUND"/>, is that	The main issue, as noted in <xref target="BACKGROUND"/>, is that
	any mechanism that can be used to force packets into the	any mechanism that can be used to force packets into the

	router's control plane or slow path can be exploited as a Denial-of-Service attack on a	router's Control Plane or Slow Path can be exploited as a DoS attack on a
	router by saturating the resources needed for router management	router by saturating the resources needed for router management

	(routing protocols, network management protocols, etc.) and	(routing protocols, network management protocols, etc.), and this can
	cause the router to fail or perform sub-optimally. </t>	cause the router to fail or perform suboptimally. </t>

	<t>While Hop-by-Hop options are not required to be processed in the	<t>While Hop-by-Hop options are not required to be processed in the

	control plane, the Router Alert Option is the one exception that is designed	Control Plane, the Router Alert Option is the one exception that is designed
	to be processed in the control plane.</t>	to be processed in the Control Plane.</t>

	<t>Some IPv6 nodes implement features that access more of the protocol	<t>Some IPv6 nodes implement features that access more of the protocol
	information than a typical IPv6 router (e.g., <xref target="RFC9098"/>).	information than a typical IPv6 router (e.g., <xref target="RFC9098"/>).
	Examples are nodes that provide	Examples are nodes that provide

	Denial-of-Service mitigation, firewall/access control, traffic engineering,	DoS mitigation, firewall/access control, traffic engineering,
	or traffic normalization. These nodes	or traffic normalization. These nodes
	could be configured to drop packets when they are unable to access	could be configured to drop packets when they are unable to access
	and process all Extension Headers or are unable to locate and process	and process all Extension Headers or are unable to locate and process
	the higher-layer packet information. This document provides guidance	the higher-layer packet information. This document provides guidance
	on the requirements concerning Hop-by-Hop options.</t>	on the requirements concerning Hop-by-Hop options.</t>


	<t> Finally, the document notes that Internet protocol processing needs to b e robust to	<t> Finally, this document notes that Internet protocol processing needs to be robust for
	malformed/malicious protocol fields.	malformed/malicious protocol fields.

	For example, a packet with an	For example, a packet with an
	excessive number of options could consume significant resources;	excessive number of options could consume significant resources;

	inclusion of a large extension header could potentially cause an	inclusion of a large Extension Header could potentially cause an
	on-path router to be unable to utilise hardware optimisations	on-path router to be unable to utilize hardware optimizations
	to process later headers (e.g., to perform equal cost multipath	to process later headers (e.g., to perform equal cost multipath
	forwarding or port filtering).	forwarding or port filtering).

	This requirement is not specific to	This requirement is not specific to
	Hop-by-Hop options. It is important that implementations	Hop-by-Hop options. It is important that implementations
	fail gracefully when a malformed or malicious Hop-by-Hop option is encounter ed.</t>	fail gracefully when a malformed or malicious Hop-by-Hop option is encounter ed.</t>


	<t>This document changes the way the Hop-by-Hop Options header is processed	<t>This document changes how the Hop-by-Hop Options header is processed,
	in	which significantly reduces the attack surface. These changes include the f
	several ways that significantly reduce the attack surface. These	ollowing:
	changes include:
	</t>	</t>

	<ul spacing="normal">	<ul spacing="normal">

	<li>A router configuration needs to avoid vulnerabilities that	<li>A router configuration needs to avoid vulnerabilities that

	arise when it cannot process a Hop-by-Hop option at full	arise when it cannot process a Hop-by-Hop option at the Full
	forwarding rate and SHOULD NOT therefore be configured to	Forwarding Rate; therefore, it <bcp14>SHOULD NOT</bcp14> be configur
	process the a Hop-by-Hop option if this adversely impacts the	ed to
	aggregate forwarding rate, instead it	process the Hop-by-Hop option if it adversely impacts the
	SHOULD behave in the way specified for an unrecognized Option Type w	aggregate forwarding rate. Instead, it
	hen the	<bcp14>SHOULD</bcp14> behave in the same way specified for an unreco
	action bits were set to "00", as specified in <xref target="ONE"/>.<	gnized Option Type when the
	/li>	action bits are set to "00", as specified in <xref target="ONE"/>.</
		li>


	<li>It adds criteria for the Router Alert Option in <xref target="RTRALE	<li>This document adds criteria for the Router Alert Option (<xref targe
	RT"/>	t="RTRALERT"/>)
	to allow control over how the Router Alert Option is	to allow control over how it is
	processed and that a node configured to support these options must	processed and describes how a node configured to support these options m
	protect itself from attacks using the Router Alert Option.</li>	ust
		protect itself from attacks by using the Router Alert Option.</li>


	<li>The document sets an expectation that if a packet	<li>This document sets the expectation that if a packet
	includes a Hop-by-Hop Options header that the packet will be forwarded	includes a Hop-by-Hop Options header, the packet will be forwarded acros
	across the network path.	s the network path.
	</li>	</li>


	<li>A source MAY include, based on local configuration, a single Hop-by-	<li>A Source <bcp14>MAY</bcp14> include a single Hop-by-Hop option (base
	Hop option or may be configured to include	d on
	more Hop-by-Hop options.	local configuration) or <bcp14>MAY</bcp14> be configured to include more
	The configuration of intermediate nodes determines	Hop-by-Hop options. The configuration of intermediate nodes determines
	whether a node processes any of these options, and, if so, which and how man	whether a node processes any of these options, and if so, which ones and how
	y.</li>	many.</li>


	<li>The present document adds guidance for the design of	<li>This document adds guidance for the design of
	any future new Hop-by-Hop option that reduce their	any future new Hop-by-Hop option that reduces the
	computational requirements and encourage a	computational requirements and encourages a
	limit to their size.</li>	limit to their size.</li>

	</ul>	</ul>


	<t>The intent of this document is that these changes significantly reduce th e	<t>The intent of this document is to highlight that these changes significan tly reduce the
	security issues relating to processing the IPv6 Hop-by-Hop Options header	security issues relating to processing the IPv6 Hop-by-Hop Options header

	and to enable Hop-by-Hop options	and enable Hop-by-Hop options to be safely used in the Internet.</t>
	to be safely used in the Internet.</t>

	</section>

	<section title="Acknowledgments" anchor="Ack">

	<t>Helpful comments were received from Brian Carpenter, Ron Bonica,
	Ole Troan, Mike Heard, Tom Herbert, Cheng Li, Eric Vyncke, Greg
	Mirksy, Xiao Min, Fernando Gont, Darren Dukes, Peng Shuping, Dave
	Thaler, Ana Custura, Tim Winters, Jingrong Xie,
	Lorenzo Colitti, Toerless Eckert, Suresh Krishnan, Mikael
	Abrahamsson, Adrian Farrel, Jie Dong, Jen Linkova, Erik Kline,
	and other members of the 6MAN working group.</t>

	</section>	</section>


	<section anchor="changes" title="Change log [RFC Editor: Please remove]">

	<t>draft-ietf-6man-hbh-processing-20, 2024-June 5</t>
	<ul spacing="compact">
	<li>Changes based on John Scudder's AD review.</li>
	<li>Changes based on Deb Cooley's AD review.</li>
	<li>Changes based on Jim Guichard's AD review.</li>
	<li>Changes based on Roman Danyliw's AD review.</li>
	<li>Changes based on Jim Guichard's AD review.</li>
	<li>Editorial Changes.</li>
	</ul>

	<t>draft-ietf-6man-hbh-processing-19, 2024-June 4</t>
	<ul spacing="compact">
	<li>Changes based on Warren Kumari's AD review.</li>
	</ul>

	<t>draft-ietf-6man-hbh-processing-18, 2024-May 29:</t>
	<ul spacing="compact">
	<li>Changes based on Éric Vyncke's AD review.</li>
	<li>Changes based on Roman Danyliw's AD review.</li>
	</ul>

	<t>draft-ietf-6man-hbh-processing-17, 2024-May 16:</t>
	<ul spacing="compact">
	<li>Editorial changes and request to IANA, based on Bernie Volz's INTDIR re
	view.</li>
	</ul>

	<t>draft-ietf-6man-hbh-processing-16, 2024-April 30:</t>
	<ul spacing="compact">
	<li>Clarifications and editorial changes based on Peter Yee's SECDIR rev
	iew.</li>
	<li>Editorial changes based on Behcet Sarikaya's GENART review.</li>
	<li>Clarifications based on Brian Trammell's TSVART review.</li>
	</ul>

	<t>draft-ietf-6man-hbh-processing-15, 2024-April 13:</t>
	<ul spacing="compact">
	<li>Clarifications based on AD review by Erik Kline.</li>
	<li>Editorial Changes.</li>
	</ul>

	<t>draft-ietf-6man-hbh-processing-14, 2024-February-25:</t>
	<ul spacing="compact">
	<li>Clarifications based on comment from Jen Linkova</li>
	<li>Editorial Changes.</li>
	</ul>

	<t>draft-ietf-6man-hbh-processing-13, 2024-February-18:</t>
	<ul spacing="compact">
	<li>Correction based on comment by Jie Dong</li>
	<li>Clarifications based on comments from Tom Herbert</li>
	<li>Clarifications based on comments from Ole Troan</li>
	<li>Editorial Changes.</li>
	</ul>

	<t>draft-ietf-6man-hbh-processing-12, 2023-November-21:</t>
	<ul spacing="compact">
	<li>Clarifications and text improvements based on review by
	Fernando Gont.</li>
	<li>Editorial Changes.</li>
	</ul>

	<t>draft-ietf-6man-hbh-processing-11, 2023-November-5:</t>
	<ul spacing="compact">
	<li>Clarifications and text improvements based on review by Adrian Farr
	el.</li>
	<li>Editorial Changes.</li>
	</ul>

	<t>draft-ietf-6man-hbh-processing-10, 2023-September-26:</t>
	<ul spacing="compact">
	<li>Clarifying changes based on comments received during the
	IPv6 w.g. session at IETF117 from Lorenzo Colitti, Toerless Eckert, and
	others.</li>
	<li>Clarifying changes based on comments received after the
	first w.g. last call.</li>
	<li>Editorial Changes.</li>
	</ul>

	<t>draft-ietf-6man-hbh-processing-09, 2023-July-4:</t>
	<ul spacing="compact">
	<li>Revised text in <xref target="TERM"/> relating to fast/slow path an
	d processing</li>
	<li>Restructured <xref target="HBH"/> to separate Hop-by-Hop
	Options header and Hop-by-Hop options processing and configuration.</li>
	<li>Revised MUST/SHOULD language in <xref target="ONE"/>.</li>
	<li>Revised text to use consistant names for Hop-by-Hop Options
	header and Hop-by-Hop options.</li>
	<li>Revised <xref target="ONE"/> 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.</li>
	<li>Added to <xref target="NEW"/> that new Hop-by-Hop options
	SHOULD be designed expecting that routers may drop packets with
	the new option.</li>
	<li>Added new <xref target="HOW"/> on "Example of Robust Usage".</li>
	<li>Other editorial changes to improve readability and clarity.</li>
	</ul>

	<t>draft-ietf-6man-hbh-processing-08, 2023-April-30:</t>
	<ul spacing="compact">
	<li>Changed document that is no longer updates <xref
	target="RFC7045"/>, it now clarifies it using the language of BCP 14.
	</li>
	<li>Added additional clarification to <xref target="BACKGROUND"/>.</li>
	<li>Editorial changes</li>
	</ul>

	<t>draft-ietf-6man-hbh-processing-07, 2023-April-6:</t>
	<ul spacing="compact">
	<li>Changed text to clarify how hosts and routers process the
	Hop-by-Hop Options header based on comments at 6MAN session at IETF 116.
	</li>
	<li>Editorial changes</li>
	</ul>

	<t>draft-ietf-6man-hbh-processing-06, 2023-March-11:</t>
	<ul spacing="compact">
	<li>Added reference to RFC6564.</li>
	<li>Editorial changes</li>
	</ul>

	<t>draft-ietf-6man-hbh-processing-05, 2023-February-23:</t>
	<ul spacing="compact">
	<li>Clarified text in <xref target="NEW"/> about processing
	complexity and time to process.</li>
	<li>Added a definition to <xref target="TERM"/> for "Full
	Forwarding Rate".</li>
	<li>Added text to <xref target="FAST"/> about nodes that do not
	process the Hop-by-Hop Options header.</li>
	<li>Added text to <xref target="BACKGROUND"/> about slow path processing
	can cause packets to be deliver out of order to the destination.</li>
	<li>Editorial changes</li>
	</ul>

	<t>draft-ietf-6man-hbh-processing-04, 2022-October-21:</t>
	<ul spacing="compact">
	<li>Add a paragraph to <xref target="BACKGROUND"/> that describes the
	relationship to <xref target="RFC7045"/> "Transmission and Processing of
	IPv6
	Extension Headers".</li>
	<li>Change that this draft updates section 2.2 of <xref target="RFC7045"/>
	.
	</li>
	</ul>

	<t>draft-ietf-6man-hbh-processing-03, 2022-October-12:</t>
	<ul spacing="compact">
	<li>Changed in <xref target="FAST"/> to have router skip over options if c
	an't
	process at full forwarding rate.</li>
	<li>Added to <xref target="NEW"/> that new options should be
	defined with action type set to 00.</li>
	</ul>

	<t>draft-ietf-6man-hbh-processing-02, 2022-August-23:</t>
	<ul spacing="compact">
	<li>Several clarification and editorial changes suggested by a review
	by Peng Shuping.</li>
	<li>Editorial changes.</li>
	<li>Revised text relating to fast/slow path and processing
	rates.</li>
	<li>Revised the third paragraph in <xref target="CONFIG"/> to be clearer.<
	/li>
	<li>Revised text in Security section based on comments from Fernando Gont.
	</li>
	</ul>

	<t>draft-ietf-6man-hbh-processing-01, 2022-June-15:</t>

	<ul spacing="compact">
	<li>Fixed typo in last paragraph of <xref target="FAST"/> </li>
	<li>Revised text in <xref target="BACKGROUND"/> to reflect
	constraints on publishing RFC 8200. </li>
	<li>Changed text in <xref target="NEW"/> that new options
	SHOULD NOT (from MUST NOT) be defined that require that are not
	expected to be excepted at full forwarding rates.</li>
	<li>Added reference to RFC7872 in <xref target="BACKGROUND"/>.</li>
	<li>Added text to <xref target="INTRO"/> that the focus of this
	document is to set a minimum bound on the number of Hop-by-Hop
	options a node should process.</li>
	<li>Added text to <xref target="BACKGROUND"/> that the authors
	some Hop-by-Hop options will be supported Internet wide, and
	others only in limited domains.</li>

	<li>Editorial changes.</li>
	</ul>

	<t>draft-ietf-6man-hbh-processing-00, 2022-January-29:</t>

	<ul spacing="compact">
	<li>6MAN Working Group Draft</li>
	<li>Reworked text to talk about processing Hop-by-Hop options at full
	forwarding rates, instead of "fast path"</li>
	<li>Revised <xref target="NEW"/> "New Hop-by-Hop options" to allow variabl
	e sized Hop-by-Hop
	options, remove specific length requirements, and other clarifications.
	</li>
	<li>Editorial changes.</li>
	</ul>

	<t>draft-hinden-6man-hbh-processing-01, 2021-June-2:</t>

	<ul spacing="compact">
	<li>Expanded terminology section to include forwarding plane and
	control plane.</li>
	<li>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.</li>
	<li>Clarified that all Hop-by-Hop options (with one exception) must be
	processed on the Fast Path.</li>
	<li>Kept the Router Alert Option as the single exception for Slow
	Path processing.</li>
	<li>Rewrote and expanded section on New Hop-by-Hop options.</li>
	<li>Removed requirement for Hop-by-Hop option size and alignment.</li>
	<li>Removed sections evaluating currently defined Hop-by-Hop options.</li>
	<li>Added content to the Security Considerations section.</li>
	<li>Added people to the acknowledgements section.</li>
	<li>Numerous editorial changes</li>
	</ul>

	<t>draft-hinden-6man-hbh-processing-00, 2020-Nov-29:</t>

	<ul spacing="compact">
	<li>Initial draft.</li>
	</ul>

	</section>

	</middle>	</middle>

	<back>	<back>

		<displayreference target="I-D.ietf-v6ops-hbh" to="HBH"/>
		<displayreference target="I-D.ietf-taps-arch" to="TAPS-ARCH"/>
	<references>	<references>
	<name>Normative References</name>	<name>Normative References</name>


	<xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/refere	<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.820
	nce.RFC.8200.xml"/>	0.xml"/>
	<xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/refer	<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.211
	ence.RFC.2119.xml"/>	9.xml"/>
	<xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/refer	<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.817
	ence.RFC.8174.xml"/>	4.xml"/>


	<reference anchor="IANA-HBH"	<reference anchor="IANA-HBH"
	target="https://www.iana.org/assignments/ipv6-parameters/ipv6-parameters.	target="https://www.iana.org/assignments/ipv6-parameters/">
	xhtml#ipv6-parameters-2">
	<front>	<front>
	<title>Destination Options and Hop-by-Hop Options</title>	<title>Destination Options and Hop-by-Hop Options</title>

	<author/>	<author>
		<organization>IANA</organization>
		</author>
	<date/>	<date/>
	</front>	</front>
	</reference>	</reference>

	</references>	</references>

	<references>	<references>
	<name>Informative References</name>	<name>Informative References</name>


	<reference anchor="IANA-RA"	<reference anchor="IANA-RA"
	target="https://www.iana.org/assignments/ipv6-routeralert-values/ipv6-rou	target="https://www.iana.org/assignments/ipv6-routeralert-values/">
	teralert-values">
	<front>	<front>
	<title>IPv6 Router Alert Option Values</title>	<title>IPv6 Router Alert Option Values</title>

	<author/>	<author>
		<organization>IANA</organization>
		</author>
	<date/>	<date/>
	</front>	</front>
	</reference>	</reference>


	<xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference	<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.1883.
	.RFC.1883.xml"/>	xml"/>
	<xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference	<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.2460.
	.RFC.2460.xml"/>	xml"/>
	<xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference	<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.2711.
	.RFC.2711.xml"/>	xml"/>
	<xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference	<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.4443.
	.RFC.4443.xml"/>	xml"/>
	<xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference	<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.6398.
	.RFC.6398.xml"/>	xml"/>
	<xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference	<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.6192.
	.RFC.6192.xml"/>	xml"/>
	<xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference	<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.6564.
	.RFC.6564.xml"/>	xml"/>
	<xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference	<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.7045.
	.RFC.7045.xml"/>	xml"/>
	<xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference	<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.7872.
	.RFC.7872.xml"/>	xml"/>
	<xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference	<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8799.
	.RFC.8799.xml"/>	xml"/>
	<xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference	<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9098.
	.RFC.9098.xml"/>	xml"/>
	<xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference	<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9268.
	.RFC.9268.xml"/>	xml"/>
	<xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference	<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9288.
	.RFC.9288.xml"/>	xml"/>
	<!--
	<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml3/reference.I-D.i
	etf-6man-eh-limits.xml"/>
	<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml3/reference.I-D.
	ietf-v6ops-hbh.xml"/>
	<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml3/reference.I-D.
	ietf-taps-arch.xml"/>


	<reference anchor="Hendriks" target="http://dl.ifip.org/db/conf/tma/tma2017/t	<!-- [I-D.ietf-v6ops-hbh] IESG state: Expired as of 09/30/24-->
	ma2017_paper22.pdf">	<xi:include href="https://datatracker.ietf.org/doc/bibxml3/draft-ietf-v6ops-
		hbh.xml"/>

		<!-- [I-D.ietf-taps-arch] IESG state: RFC Ed Queue (EDIT) as of 09/30/24 (C508 d
		ocument). Missing editors. -->

		<reference anchor="I-D.ietf-taps-arch" target="https://datatracker.ietf.org/doc/
		html/draft-ietf-taps-arch-19">
		<front>
		<title>
		Architecture and Requirements for Transport Services
		</title>
		<author initials="T." surname="Pauly" fullname="Tommy Pauly" role="editor">
		<organization>Apple Inc.</organization>
		</author>
		<author initials="B." surname="Trammell" fullname="Brian Trammell" role="editor"
		>
		<organization>Google Switzerland GmbH</organization>
		</author>
		<author initials="A." surname="Brunstrom" fullname="Anna Brunstrom">
		<organization>Karlstad University</organization>
		</author>
		<author initials="G." surname="Fairhurst" fullname="Gorry Fairhurst">
		<organization>University of Aberdeen</organization>
		</author>
		<author initials="C." surname="Perkins" fullname="Colin Perkins">
		<organization>University of Glasgow</organization>
		</author>
		<date month="November" day="9" year="2023"/>
		</front>
		<seriesInfo name="Internet-Draft" value="draft-ietf-taps-arch-19"/>
		</reference>

		<reference anchor="Hendriks" target="http://dl.ifip.org/db/conf/tma/tma2017/
		tma2017_paper22.pdf">
	<front>	<front>
	<title>Threats and Surprises behind IPv6 Extension Headers</title>	<title>Threats and Surprises behind IPv6 Extension Headers</title>
	<author initials="L" surname="Hendriks" fullname="Luuk Hendriks">	<author initials="L" surname="Hendriks" fullname="Luuk Hendriks">
	<organization>University of Twente</organization>	<organization>University of Twente</organization>
	</author>	</author>
	<author initials="P" surname="Velan" fullname="Petr Velan">	<author initials="P" surname="Velan" fullname="Petr Velan">
	<organization>University of Twente</organization>	<organization>University of Twente</organization>
	</author>	</author>
	<author initials="RO" surname="Schmidt" fullname="Ricardo de O. Schmid t">	<author initials="RO" surname="Schmidt" fullname="Ricardo de O. Schmid t">
	<organization>University of Twente</organization>	<organization>University of Twente</organization>
	</author>	</author>
	<author initials="P" surname="Boer" fullname="Pieter-Tjerk de Boer">	<author initials="P" surname="Boer" fullname="Pieter-Tjerk de Boer">
	<organization>University of Twente</organization>	<organization>University of Twente</organization>
	</author>	</author>
	<author initials="A" surname="Aiko" fullname="Aiko Pras">	<author initials="A" surname="Aiko" fullname="Aiko Pras">
	<organization>University of Twente</organization>	<organization>University of Twente</organization>
	</author>	</author>
	<date month="August" year="2017" />	<date month="August" year="2017" />
	</front>	</front>

	<seriesInfo name="" value="" />	<seriesInfo name="DOI" value="10.23919/TMA.2017.8002912" />
	<refcontent></refcontent>	<refcontent>2017 Network Traffic Measurement and Analysis Conference (TM
		A)</refcontent>
	</reference>	</reference>

	<reference anchor="Tram17" target="https://irtf.org/anrw/2017/anrw17-final16. pdf">	<reference anchor="Tram17" target="https://irtf.org/anrw/2017/anrw17-final16. pdf">
	<front>	<front>

	<title>Tracking Transport-Layer Evolution with PATH Spider</title>	<title>Tracking Transport-Layer Evolution with PATHspider</title>
	<author initials="B" surname="Trammell" fullname="Brian Trammell">	<author initials="B" surname="Trammell" fullname="Brian Trammell">
	</author>	</author>

	<author initials="M" surname="Kuehlewind" fullname="Mirja Kuehlewind">	<author initials="M" surname="Kühlewind" fullname="Mirja Kühlewind">
	</author>	</author>
	<author initials="P" surname="De Vaere" fullname="Piet De Vaere">	<author initials="P" surname="De Vaere" fullname="Piet De Vaere">
	</author>	</author>

	<author initials="IR" surname="Learmonth" fullname="Iain Learmonth ">	<author initials="I" surname="Learmonth" fullname="Iain Learmonth ">
	</author>	</author>
	<author initials="G" surname="Fairhurst" fullname="Gorry Fairhurst">	<author initials="G" surname="Fairhurst" fullname="Gorry Fairhurst">
	</author>	</author>
	<date month="July" year="2017" />	<date month="July" year="2017" />
	</front>	</front>

	<seriesInfo name="ANRW" value="" />	<seriesInfo name="DOI" value="10.1145/3106328.3106336" />
	<refcontent></refcontent>	<refcontent>ANRW '17: Proceedings of the 2017 Applied Networking Researc
		h Workshop</refcontent>
	</reference>	</reference>

	<reference anchor="Cus23a" target="http://www.iepg.org/2023-03-26-ietf116/eh. pdf">	<reference anchor="Cus23a" target="http://www.iepg.org/2023-03-26-ietf116/eh. pdf">
	<front>	<front>
	<title>Internet Measurements: IPv6 Extension Header Edition</title>	<title>Internet Measurements: IPv6 Extension Header Edition</title>
	<author initials="A" surname="Custura" fullname="Ana Custura ">	<author initials="A" surname="Custura" fullname="Ana Custura ">
	</author>	</author>
	<author initials="G" surname="Fairhurst" fullname="Gorry Fairhurst">	<author initials="G" surname="Fairhurst" fullname="Gorry Fairhurst">
	</author>	</author>
	<date month="March" year="2023" />	<date month="March" year="2023" />
	</front>	</front>

	<seriesInfo name="IEPG, IETF-116" value="" />	<refcontent>IEPG Meeting: IETF 116</refcontent>
	<refcontent></refcontent>
	</reference>	</reference>

	<reference anchor="Cus23b" target="https://www.sciencedirect.com/science/artic le/pii/S0140366423003705">	<reference anchor="Cus23b" target="https://www.sciencedirect.com/science/artic le/pii/S0140366423003705">
	<front>	<front>
	<title>Is it possible to extend IPv6?</title>	<title>Is it possible to extend IPv6?</title>
	<author initials="A." surname="Custura" fullname="A. Custura"></author>	<author initials="A." surname="Custura" fullname="A. Custura"></author>
	<author initials="R." surname="Secchi" fullname="R. Secchi"></author>	<author initials="R." surname="Secchi" fullname="R. Secchi"></author>
	<author initials="E." surname="Boswell" fullname="E. Boswell"></author>	<author initials="E." surname="Boswell" fullname="E. Boswell"></author>
	<author initials="G." surname="Fairhurst" fullname="G. Fairhurst"></author>	<author initials="G." surname="Fairhurst" fullname="G. Fairhurst"></author>

	<date year="2023" month="Oct"/>	<date year="2024" month="Jan"/>
	<abstract>
	<t>The IPv6 Hop-by-Hop Options and Destination Options Extension
	Headers have historically faced challenges in deployment due to a
	lack of router support coupled with concerns around potential for
	denial-of-service attacks. However, there has been a renewed
	interest within the standards community both in simplifying their
	processing, and in using these extension headers for new
	applications. Through a wide-scale measurement campaign, we show
	that many autonomous systems in both access networks and the core
	of the Internet do permit the traversal of packets that include
	options, and that the path traversal currently depends on the type
	of network, size of the option and the transport protocol used, but
	does not usually depend on the type of included option. This is an
	encouraging result when considering the extensibility of IPv6. We
	show that packets that include an extension header can also impact
	the function of load balancing network devices, and present
	evidence of equipment mis-configuration, noting that a different
	path to the same destination can result in a different traversal
	result. Finally, we outline the current deployment challenges and
	provide recommendations for how extension headers can utilise
	options to extend IPv6.</t>
	</abstract>
	</front>	</front>

	<seriesInfo name="Computer Communications" value="X"/>	<refcontent>Computer Communications, vol. 214, pp. 90-99</refcontent>
		<seriesInfo name="DOI" value="10.1016/j.comcom.2023.10.006"/>
	</reference>	</reference>

	</references>	</references>

		<section anchor="Ack" numbered="false">
		<name>Acknowledgments</name>
		<t>Helpful comments were received from <contact fullname="Brian
		Carpenter"/>, <contact fullname="Ron Bonica"/>, <contact fullname="Ole
		Troan"/>, <contact fullname="Mike Heard"/>, <contact fullname="Tom
		Herbert"/>, <contact fullname="Cheng Li"/>, <contact fullname="Éric
		Vyncke"/>, <contact fullname="Greg Mirsky"/>, <contact fullname="Xiao
		Min"/>, <contact fullname="Fernando Gont"/>, <contact fullname="Darren
		Dukes"/>, <contact fullname="Peng Shuping"/>, <contact fullname="Dave
		Thaler"/>, <contact fullname="Ana Custura"/>, <contact fullname="Tim
		Winters"/>, <contact fullname="Jingrong Xie"/>, <contact fullname="Lorenzo
		Colitti"/>, <contact fullname="Toerless Eckert"/>, <contact
		fullname="Suresh Krishnan"/>, <contact fullname="Mikael Abrahamsson"/>,
		<contact fullname="Adrian Farrel"/>, <contact fullname="Jie Dong"/>,
		<contact fullname="Jen Linkova"/>, <contact fullname="Erik Kline"/>, and
		other members of the 6MAN Working Group.</t>


		</section>
	</back>	</back>


	</rfc>	</rfc>

End of changes. 188 change blocks.
	765 lines changed or deleted	508 lines changed or added
This html diff was produced by rfcdiff 1.48.