rfc9288xml2.original.xml		rfc9288.xml
	<?xml version="1.0" encoding="UTF-8"?>		<?xml version='1.0' encoding='utf-8'?>
	<!DOCTYPE rfc SYSTEM "rfc2629.dtd">
	<?xml-stylesheet type='text/xsl' href='rfc2629.xslt' ?>
	<!-- try to enforce the ID-nits conventions and DTD validity -->
	<?rfc strict="no" ?> <!-- items used when reviewing the document -->
	<?rfc comments="no" ?> <!-- controls display of <cref> elements -->
	<?rfc inline="no" ?> <!-- when no, put comments at end in comments section,
	otherwise, put inline -->
	<?rfc editing="no" ?> <!-- when yes, insert editing marks -->
	<!-- create table of contents (set it options).
	Note the table of contents may be omitted
	for very short documents -->
	<?rfc toc="yes"?><?rfc tocompact="yes"?>
	<?rfc tocdepth="2"?>
	<!-- choose the options for the references. Some like
	symbolic tags in the references (and citations)
	and others prefer numbers. -->
	<?rfc symrefs="yes"?><?rfc sortrefs="yes" ?>
	<!-- these two save paper: start new paragraphs from the same page etc. -->
	<?rfc compact="yes" ?><?rfc subcompact="no" ?>
	<!-- end of list of processing instructions -->
	<!-- Information about the document.
	categories values: std, bcp, info, exp, and historic
	For Internet-Drafts, specify attribute "ipr".
	(ipr values are: full3667, noModification3667, noDerivatives3667),
	Also for Internet-Drafts, can specify values for
	attributes "iprExtract", and "docName". Note
	that the value for iprExtract is the anchor attribute
	value of a section that can be extracted, and is only
	useful when the value of "ipr" is not "full3667". -->
	<!-- TODO: verify which attributes are specified only
	by the RFC editor. It appears that attributes
	"number", "obsoletes", "updates", and "seriesNo"
	are specified by the RFC editor (and not by
	the document author). -->
	<rfc
	category="info"
	ipr="trust200902"
	docName="draft-ietf-opsec-ipv6-eh-filtering-10" >
	<front>
	<title abbrev="Filtering of IPv6 packets with EHs">Recommendations on the Fi
	ltering of IPv6 Packets Containing IPv6 Extension Headers at Transit Routers</ti
	tle>
	<!-- add 'role="editor"' below for the editors if appropriate -->		<!DOCTYPE rfc [
			<!ENTITY nbsp "&#160;">
			<!ENTITY zwsp "&#8203;">
			<!ENTITY nbhy "&#8209;">
			<!ENTITY wj "&#8288;">
			]>
			<rfc xmlns:xi="http://www.w3.org/2001/XInclude" number="9288" category="info" ip
			r="trust200902" docName="draft-ietf-opsec-ipv6-eh-filtering-10" obsoletes="" upd
			ates="" submissionType="IETF" xml:lang="en" consensus="true" tocInclude="true" t
			ocDepth="2" symRefs="true" sortRefs="true" version="3">
			<!-- xml2rfc v2v3 conversion 3.12.10 -->
			<front>
			<title abbrev="Filtering of IPv6 Packets with EHs">Recommendations on the Fi
			ltering of IPv6 Packets Containing IPv6 Extension Headers at Transit Routers</ti
			tle>
			<seriesInfo name="RFC" value="9288"/>
	<author fullname="Fernando Gont" initials="F." surname="Gont">		<author fullname="Fernando Gont" initials="F." surname="Gont">
			<organization abbrev="SI6 Networks">SI6 Networks</organization>
	<organization abbrev="EdgeUno">EdgeUno</organization>
	<address>		<address>
	<postal>		<postal>
	<street>Segurola y Habana 4310, 7mo Piso</street>		<street>Segurola y Habana 4310 7mo piso</street>
	<city>Villa Devoto</city>		<city>Ciudad Autonoma de Buenos Aires</city>
	<region>Ciudad Autonoma de Buenos Aires</region>
	<country>Argentina</country>		<country>Argentina</country>
	</postal>		</postal>
	<email>fernando.gont@edgeuno.com</email>		<email>fgont@si6networks.com</email>
	<uri>https://www.edgeuno.com</uri>		<uri>https://www.si6networks.com</uri>
	</address>		</address>
	</author>		</author>
			<author fullname="Will (Shucheng) Liu" initials="W." surname="Liu">
	<author fullname="Will (Shucheng) Liu" initials="W." surname="Liu">
	<organization>Huawei Technologies</organization>		<organization>Huawei Technologies</organization>
	<address>		<address>
	<postal>		<postal>
	<street>Bantian, Longgang District</street>		<street>Bantian, Longgang District</street>
	<city>Shenzhen</city>		<city>Shenzhen</city>
	<code>518129</code>		<code>518129</code>
	<country>P.R. China</country>		<country>China</country>
	</postal>		</postal>
	<email>liushucheng@huawei.com</email>		<email>liushucheng@huawei.com</email>
	</address>		</address>
	</author>
	<!--
	<author fullname="Ronald P. Bonica" initials="R." surname="Bonica">
	<organization>Juniper Networks</organization>
	<address>
	<postal>
	<street>2251 Corporate Park Drive</street>
	<city>Herndon</city>
	<region>VA</region>
	<code>20171</code>
	<country>US</country>
	</postal>
	<phone>571 250 5819</phone>
	<email>rbonica@juniper.net</email>
	</address>
	</author>		</author>
			<date month="August" year="2022" />
	<date />		<area>Operations and Management (ops)</area>
	<!-- month="May" is no longer necessary note also, day="30" is optional -->
	<area>Operations and Management (ops)</area> <!-- WG name at the upperlef
	t corner of the doc,
	IETF fine for individual submissions -->
	<workgroup>opsec</workgroup>		<workgroup>opsec</workgroup>
	<abstract>		<keyword>Denial of Service</keyword>
	<t>		<keyword>Distributed Denial of Service</keyword>
			<keyword>DoS</keyword>
			<keyword>DDoS</keyword>
			<keyword>ACL</keyword>
			<keyword>filtering policy</keyword>
			<abstract>
			<t>
	This document analyzes the security implications of IPv6 Extension Headers an d associated IPv6 options. Additionally, it discusses the operational and		This document analyzes the security implications of IPv6 Extension Headers an d associated IPv6 options. Additionally, it discusses the operational and
	interoperability implications of discarding packets based on the		interoperability implications of discarding packets based on the
	IPv6 Extension Headers and IPv6 options they contain. Finally, it provides ad vice on the filtering of such IPv6		IPv6 Extension Headers and IPv6 options they contain. Finally, it provides ad vice on the filtering of such IPv6
	packets at transit routers for traffic not directed to them, for those cases where such filtering is deemed as necessary.		packets at transit routers for traffic not directed to them, for those cases where such filtering is deemed as necessary.
	</t>		</t>
	</abstract>		</abstract>
			</front>
	</front>		<middle>
			<section anchor="intro" numbered="true" toc="default">
	<middle>		<name>Introduction</name>
			<t>IPv6 Extension Headers (EHs) allow for the extension of the IPv6
	<section title="Introduction" anchor="intro">		protocol and provide support for core functionality, such as IPv6
	<t>IPv6 Extension Headers (EHs) allow for the extension of the IPv6		fragmentation. However, common implementation limitations suggest that EHs p
	protocol, and provide support for core functionality such as IPv6		resent a challenge for IPv6 packet routing equipment, particularly when the IPv6
	fragmentation. However, common implementation limitations suggest that EHs p		header chain needs to be processed for, as an example, enforcing Access Control
	resent a challenge for IPv6 packet routing equipment, particularly when the IPv6		Lists (ACLs) or implementing other functions <xref target="RFC9098" format="def
	header chain needs to be processed for e.g. enforcing ACLs or implementing othe		ault"/>.
	r functions <xref target="RFC9098"/>.
	</t>		</t>
			<t>Several studies (e.g., <xref target="Huston-2022" format="default"/>, <
	<t>Several studies (e.g. <xref target="Huston-2022"/>, <xref target="I-D.vyncke-		xref target="I-D.vyncke-v6ops-james" format="default"/>, and <xref target="RFC78
	v6ops-james"/>, and <xref target="RFC7872"/>) suggest that there is widespread d		72" format="default"/>) suggest that there is widespread dropping of IPv6 packet
	ropping of IPv6 packets that contain IPv6 Extension Headers (EHs). In some cases		s that contain IPv6 EHs. In some cases, such packet drops occur at transit route
	, such packet drops occur at transit routers. While some operators are known to		rs. While some operators are known to intentionally drop packets that contain IP
	intentionally drop packets that contain IPv6 EHs, it is possible that some of th		v6 EHs, it is possible that some of the measured packet drops are the result of
	e measured packet drops are the result of inappropriate advice in this area.</t>		inappropriate advice in this area.</t>
			<t>This document analyzes both the general security implications of
	<t>This document analyzes both the general security implications of
	IPv6 EHs, as well as the security implications of		IPv6 EHs, as well as the security implications of
	specific EH and Option types. It also provides advice on the		specific EH and option types. It also provides advice on the
	filtering of IPv6 packets based on the IPv6 EHs and		filtering of IPv6 packets based on the IPv6 EHs and
	the IPv6 options they contain. Since		the IPv6 options they contain. Since
	various protocols may use IPv6 EHs (possibly with IPv6		various protocols may use IPv6 EHs (possibly with IPv6
	options), discarding packets based on the IPv6 EHs or		options), discarding packets based on the IPv6 EHs or
	IPv6 options they contain can have implications on the proper		IPv6 options they contain can have implications on the proper
	functioning of such protocols. Thus, this document also attempts to		functioning of such protocols. Thus, this document also attempts to
	discuss the operational and interoperability implications of such		discuss the operational and interoperability implications of such
	filtering policies.</t>		filtering policies.</t>
			<t>The resulting packet filtering policy typically depends on where in the
	<t>The resulting packet filtering policy typically depends on where in the netwo		network such policy is enforced. When the policy is enforced in a transit netwo
	rk such policy is enforced: when the policy is enforced in a transit network, th		rk, the policy typically follows a "deny-list" approach, where only packets with
	e policy typically follows a "deny-list" approach, where only packets with clear		clear negative implications are dropped. On the other hand, when the policy is
	negative implications are dropped. On the other hand, when the policy is enforc		enforced closer to the destination systems, the policy typically follows an "acc
	ed closer to the destination systems, the policy typically follows an "accept-li		ept-list" approach, where only traffic that is expected to be received is allowe
	st" approach, where only traffic that is expected to be received is allowed. The		d. The advice in this document is aimed only at transit routers that may need to
	advice in this document is aimed only at transit routers that may need to enfor		enforce a filtering policy based on the IPv6 EHs and IPv6 options a packet may
	ce a filtering policy based on the EHs and IPv6 options a packet may contain, fo		contain, following a "deny-list" approach; hence, it is likely to be much more p
	llowing a "deny-list" approach, and hence is likely to be much more permissive t		ermissive than a filtering policy to be employed at, for example, the edge of an
	han a filtering policy to be employed at e.g. the edge of an enterprise network.		enterprise network. The advice in this document is meant to improve the current
	The advice in this document is meant to improve the current situation of the dr		situation of the dropping of packets with IPv6 EHs in the Internet <xref target
	opping of packets with IPv6 EHs in the Internet <xref target="RFC7872"/> in such		="RFC7872" format="default"/> in such cases where packets are being dropped due
	cases where packets are being dropped due to inappropriate or missing guideline		to inappropriate or missing guidelines.</t>
	s.</t>		<t>This document is similar in nature to
			<xref target="RFC7126" format="default"/>, which addresses the same problem f
	<t>This document is similar in nature to		or the IPv4 case. However, in IPv6, the problem space is compounded by the fact
	<xref target="RFC7126"/>, which addresses the same problem for the IPv4 case.		that IPv6 specifies a number of IPv6 EHs and a number of IPv6 options that may b
	However, in IPv6, the problem space is compounded by the fact that IPv6 specifi		e valid only when included in specific EH types.</t>
	es a number of IPv6 EHs, and a number of IPv6 options which may be valid only wh		<t>This document completes and complements the considerations for protecti
	en included in specific EH types.</t>		ng the control plane from packets containing IP options that can be found in <xr
			ef target="RFC6192" format="default"/>.</t>
	<t>This document completes and complements the considerations for protecting the		<t><xref target="terms" format="default"/> specifies the terminology and c
	control plane from packets containing IP options that can be found in <xref tar		onventions employed throughout this document. <xref target="ipv6-extension-heade
	get="RFC6192"/>.</t>		rs-discussion" format="default"/> discusses IPv6 EHs and provides advice in the
			area of filtering IPv6 packets that contain such IPv6 EHs. <xref target="ipv6-op
	<t><xref target="terms"/> specifies the terminology and conventions employed thr		tions-discussion" format="default"/> discusses IPv6 options and provides advice
	oughout this document. <xref target="ipv6-extension-headers-discussion"/> discus		in the area of filtering IPv6 packets that contain such options.
	ses IPv6 EHs and provides advice in the area of filtering IPv6 packets that cont		</t>
	ain such IPv6 EHs. <xref target="ipv6-options-discussion"/> discusses IPv6 optio
	ns and provides advice in the area of filtering IPv6 packets that contain such o
	ptions. <!-- <xref target="upper-layer"/> specifies the filtering of packets ba
	sed on the upper-layer protocol. Specifically, it identifies upper-layer protoco
	ls that, for different reasons, should not be present in IPv6 packets. -->
	</t>
	<!--
	<t>While this document is similar in structure and nature to <xref target="RFC71
	23"/>, we note that this document is aimed at firewall administrators, an hence
	tends to be more restrictive than what an IPv6-version of <xref target="RFC7123"
	/> would be.</t>
	</section>		</section>
			<section anchor="terms" numbered="true" toc="default">
	<section title="Terminology and Assumptions Employed in This Document"		<name>Terminology and Assumptions Employed in This Document</name>
	anchor="terms">		<section numbered="true" toc="default">
	<section title="Terminology">		<name>Terminology</name>
			<t>The terms "permit" (allow the traffic), "drop" (drop with no notifica
	<t>The terms "permit" (allow the traffic), "drop" (drop with no notification to		tion to sender), and "reject" (drop with appropriate notification to sender) are
	sender), and "reject" (drop with appropriate notification to sender) are employe		employed as defined in <xref target="RFC3871" format="default"/>. Throughout th
	d as defined in <xref target="RFC3871"/>. Throughout this document we also emplo		is document, we also employ the term "discard" as a generic term to indicate the
	y the term "discard" as a generic term to indicate the act of discarding a packe		act of discarding a packet, irrespective of whether the sender is notified of s
	t, irrespective of whether the sender is notified of such drops, and irrespectiv		uch a drop and whether the specific filtering action is logged.
	e of whether the specific filtering action is logged.
	</t>
	<t>The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD",
	"SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED",
	"MAY", and "OPTIONAL" in this document are to be interpreted as
	described in BCP 14 <xref target='RFC2119' /> <xref target='RFC8174' /> wh
	en, and only when, they
	appear in all capitals, as shown here.
	</t>		</t>
			<t>
			The key words "<bcp14>MUST</bcp14>", "<bcp14>MUST NOT</bcp14>", "<bcp14>REQU
			IRED</bcp14>", "<bcp14>SHALL</bcp14>", "<bcp14>SHALL
			NOT</bcp14>", "<bcp14>SHOULD</bcp14>", "<bcp14>SHOULD NOT</bcp14>", "<bcp14>
			RECOMMENDED</bcp14>", "<bcp14>NOT RECOMMENDED</bcp14>",
			"<bcp14>MAY</bcp14>", and "<bcp14>OPTIONAL</bcp14>" in this document are to
			be interpreted as
			described in BCP&nbsp;14 <xref target="RFC2119"/> <xref target="RFC8174"/>
			when, and only when, they appear in all capitals, as shown here.
			</t>
			</section>
			<section numbered="true" toc="default">
			<name>Applicability Statement</name>
			<t>This document provides advice on the filtering of IPv6 packets with E
			Hs at transit routers for traffic not explicitly destined to them, for cases in
			which such filtering is deemed as necessary.</t>
			</section>
			<section numbered="true" toc="default">
			<name>Router Default Behavior and Features</name>
			<t>This document assumes that nodes comply with the requirements in <xre
			f target="RFC7045" format="default"/>. Namely,
			</t>
	</section>		<blockquote>If a forwarding node discards a packet containing a standard IPv6
			extension header, it <bcp14>MUST</bcp14> be the result of a configurable poli
	<section title="Applicability Statement">		cy and
	<t>This document provides advice on the filtering of IPv6 packets with EHs at tr
	ansit routers for traffic not explicitly destined to them, for cases in which su
	ch filtering is deemed as necessary.</t>
	</section>
	<section title="Router Default Behavior and Features">
	<t>This document assumes that nodes comply with the requirements in <xref target
	="RFC7045"/>. Namely,
	<list style="hanging">
	<t>"If a forwarding node discards a packet containing a standard IPv6
	extension header, it MUST be the result of a configurable policy and
	not just the result of a failure to recognise such a header. This		not just the result of a failure to recognise such a header. This
	means that the discard policy for each standard type of extension		means that the discard policy for each standard type of extension
	header MUST be individually configurable. The default configuration		header <bcp14>MUST</bcp14> be individually configurable. The default configu
	SHOULD allow all standard extension headers."</t>		ration
	</list>		<bcp14>SHOULD</bcp14> allow all standard extension headers.</blockquote>
			<t>
	The advice provided in this document is only meant to guide an operator in confi		The advice provided in this document is only meant to guide an operator
	guring forwarding devices, and is not to be interpreted as advice regarding defa		in configuring forwarding devices and is not to be interpreted as advice regard
	ult configuration settings for network devices. That is, this document provides		ing default configuration settings for network devices. That is, this document p
	advice with respect to operational policies, but does not change the implementat		rovides advice with respect to operational policies but does not change the impl
	ion defaults required by <xref target="RFC7045"/><!-- and <xref target="draft-g		ementation defaults required by <xref target="RFC7045" format="default"/>.
	ont-6man-ipv6-opt-transmit"/>-->. <!--We note that the advice provided in this d
	ocument is *not* meant to be employed by transit routers for transit traffic, si
	nce such devices should not enforce this type of filtering policy on traffic not
	directed to them. -->
	</t>
	<t>We recommend that configuration options are made available to govern the proc
	essing of each IPv6 EH type and each IPv6 option type. Such configuration option
	s should include the following possible settings:
	<list style="symbols">
	<t>Permit this IPv6 EH or IPv6 Option type.</t>
	<t>Drop packets containing this IPv6 EH or option type.</t>
	<t>Reject packets containing this IPv6 EH or option type (where the packet drop
	is signaled with an ICMPv6 error message).</t>
	<t>Rate-limit traffic containing this IPv6 EH or option type.</t>
	<t>Ignore this IPv6 EH or option type (as if it was not present) and process the
	packet according the rules for the remaining headers. We note that if a packet
	carries forwarding information (e.g., in an IPv6 Routing Header) this might be a
	n inappropriate or undesirable action.</t>
	</list>
	</t>		</t>
			<t>We recommend that configuration options be made available to govern t
	<t>We note that special care needs to be taken when devices log packet drops/rej		he processing of each IPv6 EH type and each IPv6 Option Type. Such configuration
	ects. Devices should count the number of packets dropped/rejected, but the loggi		options should include the following possible settings:
	ng of drop/reject events should be limited so as to not overburden device resour		</t>
	ces.</t>		<ul spacing="normal">
			<li>Permit this IPv6 EH or IPv6 Option Type.</li>
	<t>Finally, we note that when discarding packets, it is generally desirable that		<li>Drop packets containing this IPv6 EH or IPv6 Option Type.</li>
	the sender be signaled of the packet drop, since this is of use for trouble-sho		<li>Reject packets containing this IPv6 EH or IPv6 Option Type (where
	oting purposes. However, throughout this document (when recommending that packet		the packet drop is signaled with an ICMPv6 error message).</li>
	s be discarded) we generically refer to the action as "discard" without specifyi		<li>Rate-limit traffic containing this IPv6 EH or IPv6 Option Type.</l
	ng whether the sender is signaled of the packet drop.</t>		i>
	</section>		<li>Ignore this IPv6 EH or IPv6 Option Type (as if it was not present)
	</section>		, and process the packet according the rules for the remaining headers. We note
			that if a packet carries forwarding information (e.g., in an IPv6 Routing Header
	<section title="IPv6 Extension Headers" anchor="ipv6-extension-headers-discussio		(RH)), this might be an inappropriate or undesirable action.</li>
	n">		</ul>
	<section title="General Discussion">		<t>We note that special care needs to be taken when devices log packet d
	<t>IPv6 <xref target="RFC8200"/> EHs allow for the extension of the IPv6 protoco		rops/rejects. Devices should count the number of packets dropped/rejected, but t
	l. Since both IPv6 EHs and upper-layer protocols share the same namespace ("Next		he logging of drop/reject events should be limited so as to not overburden devic
	Header" registry/namespace), <xref target="RFC7045"/> identifies which of the c		e resources.</t>
	urrently assigned Internet Protocol numbers identify IPv6 EHs vs. upper-layer pr		<t>Finally, we note that when discarding packets, it is generally desira
	otocols. This document discusses the filtering of packets based on the IPv6 EHs		ble that the sender be signaled of the packet drop, since this is of use for tro
	(as specified by <xref target="RFC7045"/>) they contain. <!-- Filtering of IPv6		uble-shooting purposes. However, throughout this document (when recommending tha
	packets based on the upper-layer protocol is specified in <xref target="upper-la		t packets be discarded), we generically refer to the action as "discard" without
	yer"/>--></t>		specifying whether the sender is signaled of the packet drop.</t>
			</section>
			</section>
			<section anchor="ipv6-extension-headers-discussion" numbered="true" toc="def
			ault">
			<name>IPv6 Extension Headers</name>
			<section numbered="true" toc="default">
			<name>General Discussion</name>
			<t>IPv6 EHs <xref target="RFC8200" format="default"/> allow for the exte
			nsion of the IPv6 protocol. Since both IPv6 EHs and upper-layer protocols share
			the same namespace ("Next Header" registry/namespace), <xref target="RFC7045" fo
			rmat="default"/> identifies which of the currently assigned Internet Protocol nu
			mbers identify IPv6 EHs vs. upper-layer protocols. This document discusses the f
			iltering of packets based on the IPv6 EHs (as specified by <xref target="RFC7045
			" format="default"/>) they contain.
			</t>
			<t>
			<xref target="RFC8200" format="default"/> specifies that non-fragmented IPv6 dat
			agrams and IPv6 First-Fragments must contain the entire IPv6 header chain <xref
			target="RFC7112" format="default"/>. Therefore, intermediate systems can enforce
			the filtering policies discussed in this document or resort to simply discardin
			g the offending packets when they fail to include the entire IPv6 header chain <
			xref target="RFC8200" format="default"/>. </t>
	<t>		<t>
	<list style="hanging">		We note that in order to implement filtering rules on the fast path, it may be n
	<t>		ecessary for the filtering device to limit the depth into the packet that can be
	NOTE: <xref target="RFC8200"/> specifies that non-fragmented IPv6 datagrams and		inspected before giving up. In circumstances where such
	IPv6 First-Fragments must contain the entire IPv6 header chain <xref target="RFC
	7112"/>. Therefore, intermediate systems can enforce the filtering policies disc
	ussed in this document, or resort to simply discarding the offending packets whe
	n they fail to comply with the requirements in <xref target="RFC8200"/>. We note
	that, in order to implement filtering rules on the fast path, it may be necessa
	ry for the filtering device to limit the depth into the packet that can be inspe
	cted before giving up. In circumstances where such
	a limitation exists, it is recommended that implementations provide a		a limitation exists, it is recommended that implementations provide a
	configuration option that specifies whether to discard packets if		configuration option that specifies whether to discard packets if
	the aforementioned limit is encountered. Operators may then		the aforementioned limit is encountered. Operators may then
	determine according to their own circumstances how such packets		determine, according to their own circumstances, how such packets
	will be handled.		will be handled.
	</t>		</t>
	</list>
	</t>
	<!--
	<t>When processing a non-fragmented IPv6 datagram or an IPv6 First-Fragment, the
	packet must contain the entire IPv6 header chain <xref target="RFC7112"/>. An i
	ntermediate system that processes a packet that fails to comply with this requir
	ement should therefore drop the offending packets.
	</t>
	</section>
	<section title="General Security Implications" anchor="ipv6-eh-general-implicati
	ons">
	<t>In some device architectures, IPv6 packets that contain IPv6 EHs can cause th
	e corresponding packets to be processed on the slow path, and hence may be lever
	aged for the purpose of Denial of Service (DoS) attacks <xref target="RFC9098"/>
	<xref target="Cisco-EH"/> <xref target="FW-Benchmark"/>.
	</t>
	<t>Operators are urged to consider the IPv6 EH and IPv6 options handling capabil
	ities of their devices as they make deployment decisions in the future.</t>
	</section>		</section>
			<section anchor="ipv6-eh-general-implications" numbered="true" toc="defaul
	<section title="Rationale for Our Advice on the Handling of IPv6 Packets with Sp		t">
	ecific IPv6 Extension Headers" anchor="ipv6-ehs-rationale">		<name>General Security Implications</name>
	<t>		<t>In some device architectures, IPv6 packets that contain IPv6 EHs can
	<list style="symbols">		cause the corresponding packets to be processed on the slow path and, hence, may
	<t>IPv6 Packets with IPv6 Extension Headers (or options) that are not expected t		be leveraged for the purpose of Denial-of-Service (DoS) attacks <xref target="R
	o traverse transit routers should be dropped.</t>		FC9098" format="default"/> <xref target="Cisco-EH" format="default"/> <xref targ
			et="FW-Benchmark" format="default"/>.
	<t>IPv6 Packets with IPv6 Extension Headers (or options) that are only		</t>
			<t>Operators are urged to consider the IPv6 EH and IPv6 options handling
			capabilities of their devices as they make deployment decisions in the future.<
			/t>
			</section>
			<section anchor="ipv6-ehs-rationale" numbered="true" toc="default">
			<name>Rationale for Our Advice on the Handling of IPv6 Packets with Spec
			ific IPv6 Extension Headers</name>
			<ul spacing="normal">
			<li>IPv6 packets with IPv6 Extension Headers (or options) that are not
			expected to traverse transit routers should be dropped.</li>
			<li>IPv6 packets with IPv6 Extension Headers (or options) that are onl
			y
	expected to traverse transit routers when a specific technology is		expected to traverse transit routers when a specific technology is
	employed, should be permitted (or dropped) based on the knowledge		employed should be permitted (or dropped) based on the knowledge
	regarding the use of such technology in transit provider in question		regarding the use of such technology in the transit provider in question
	(i.e. permit the packets if the technology is employed, or drop them)		(i.e., permit the packets if the technology is employed, or drop them).
	</t>		</li>
			<li>IPv6 packets with IPv6 Extension Headers (or options) that represe
	<t>IPv6 Packets with IPv6 Extension Headers (or options) that represent		nt
	a concrete attack vector to network infrastructure devices should be dropped		a concrete attack vector to network infrastructure devices should be dropped
	.</t>		.</li>
			<li>IPv6 packets with any other IPv6 Extension Headers (or options)
	<t>IPv6 packets with any other IPv6 Extension headers (or options)
	should be permitted. This is an intentional trade-off made to		should be permitted. This is an intentional trade-off made to
	minimize ossification.</t>		minimize ossification.</li>
	</list>		</ul>
			</section>
	</t>		<section numbered="true" toc="default">
	</section>		<name>Summary of Advice on the Handling of IPv6 Packets with Specific IP
			v6 Extension Headers</name>
	<section title="Summary of Advice on the Handling of IPv6 Packets with Specific		<t>This section summarizes the advice provided in <xref target="advice-e
	IPv6 Extension Headers">		hs" format="default"/>, providing references to the specific sections in which a
	<t>This section summarizes the advice provided in <xref target="advice-ehs"/>, p		detailed analysis can be found.</t>
	roviding references to the specific sections in which a detailed analysis can be		<table anchor="eh-table" align="center">
	found.</t>		<name>Summary of Advice on the Handling of IPv6 Packets with Specific
			IPv6 Extension Headers</name>
	<texttable title="Summary of Advice on the Handling of IPv6 Packets with Spe		<thead>
	cific IPv6 Extension Headers" style="all" anchor="eh-table">		<tr>
	<ttcol align="center">EH type</ttcol>		<th align="center">EH Type</th>
	<ttcol align="center">Filtering policy</ttcol>		<th align="center">Filtering Policy</th>
	<ttcol align="center">Reference</ttcol>		<th align="center">Reference</th>
	<c>IPv6 Hop-by-Hop Options (Proto=0)</c><c>Drop or Ignore</c><c><xref target="pr		</tr>
	oto0"/></c>		</thead>
	<c>Routing Header for IPv6 (Proto=43)</c><c>Drop only RHT0 and RHT1. Permit othe		<tbody>
	r RH Types</c><c><xref target="proto43"/></c>		<tr>
	<c>Fragment Header for IPv6 (Proto=44)</c><c>Permit</c><c><xref target="proto44"		<td align="center">Hop-by-Hop Options Header (Proto=0)</td>
	/></c>		<td align="center">Drop or Ignore</td>
	<c>Encapsulating Security Payload (Proto=50)</c><c>Permit</c><c><xref target="pr		<td align="center">
	oto50"/></c>		<xref target="proto0" format="default"/></td>
	<c>Authentication Header (Proto=51)</c><c>Permit</c><c><xref target="proto51"/><		</tr>
	/c>		<tr>
	<c>Destination Options for IPv6 (Proto=60)</c><c>Permit</c><c><xref target="prot		<td align="center">Routing Header (Proto=43)</td>
	o60"/></c>		<td align="center">Drop only Routing Type 0, Routing Type 1, and R
	<c>Mobility Header (Proto=135)</c><c>Permit</c><c><xref target="proto135"/></c>		outing Type 3. Permit other Routing Types</td>
	<c>Host Identity Protocol (Proto=139)</c><c>Permit</c><c><xref target="proto139"		<td align="center">
	/></c>		<xref target="proto43" format="default"/></td>
	<c>Shim6 Protocol (Proto=140)</c><c>Permit</c><c><xref target="proto140"/></c>		</tr>
	<c>Use for experimentation and testing (Proto=253 and		<tr>
	254)</c><c>Drop</c><c><xref target="proto253254"/></c>		<td align="center">Fragment Header (Proto=44)</td>
	</texttable>		<td align="center">Permit</td>
			<td align="center">
	</section>		<xref target="proto44" format="default"/></td>
			</tr>
	<section title="Advice on the Handling of IPv6 Packets with Specific IPv6 Extens		<tr>
	ion Headers" anchor="advice-ehs">		<td align="center">Encapsulating Security Payload (Proto=50)</td>
			<td align="center">Permit</td>
	<section title="IPv6 Hop-by-Hop Options (Protocol Number=0)" anchor="proto0">		<td align="center">
	<section title="Uses">		<xref target="proto50" format="default"/></td>
	<t>The Hop-by-Hop Options header is used to carry optional information that may		</tr>
	be examined by every node along a packet's delivery path. It is expected that no		<tr>
	des will examine the Hop-by-Hop Options header if explicitly configured to do so		<td align="center">Authentication Header (Proto=51)</td>
	.</t>		<td align="center">Permit</td>
			<td align="center">
	<t>NOTE: A previous revision of the IPv6 core specification, <xref target="RFC24		<xref target="proto51" format="default"/></td>
	60"/>, originally required that all nodes examined and processed the Hop-by-Hop		</tr>
	Options header. However, even before the publication of <xref target="RFC8200"/>		<tr>
	a number of implementations already provided the option of ignoring this header		<td align="center">Destination Options Header(Proto=60)</td>
	unless explicitly configured to examine it.		<td align="center">Permit</td>
	</t>		<td align="center">
			<xref target="proto60" format="default"/></td>
	</section>		</tr>
			<tr>
	<section title="Specification">		<td align="center">Mobility Header (Proto=135)</td>
	<t>This EH is specified in <xref target="RFC8200"/>. As of May 2022, the followi		<td align="center">Permit</td>
	ng options have been specified for the Hop-by-Hop Options EH:		<td align="center">
			<xref target="proto135" format="default"/></td>
			</tr>
			<tr>
			<td align="center">Host Identity Protocol (Proto=139)</td>
			<td align="center">Permit</td>
			<td align="center">
			<xref target="proto139" format="default"/></td>
			</tr>
			<tr>
			<td align="center">Shim6 Protocol (Proto=140)</td>
			<td align="center">Permit</td>
			<td align="center">
			<xref target="proto140" format="default"/></td>
			</tr>
			<tr>
			<td align="center">Use for experimentation and testing (Proto=253
			and
			254)</td>
			<td align="center">Drop</td>
			<td align="center">
			<xref target="proto253254" format="default"/></td>
			</tr>
			</tbody>
			</table>
			</section>
			<section anchor="advice-ehs" numbered="true" toc="default">
			<name>Advice on the Handling of IPv6 Packets with Specific IPv6 Extensio
			n Headers</name>
			<section anchor="proto0" numbered="true" toc="default">
			<name>IPv6 Hop-by-Hop Options (Protocol Number=0)</name>
			<section numbered="true" toc="default">
			<name>Uses</name>
			<t>The Hop-by-Hop (HBH) Options header is used to carry optional inf
			ormation that may be examined by every node along a packet's delivery path. It i
			s expected that nodes will examine the Hop-by-Hop Options header if explicitly c
			onfigured to do so.</t>
			<aside>
			<t>NOTE: A previous revision of the IPv6 core specification <xref ta
			rget="RFC2460" format="default"/> originally required all nodes to examine and p
			rocess the Hop-by-Hop Options header. However, even before the publication of <x
			ref target="RFC8200" format="default"/>, a number of implementations already pro
			vided the option of ignoring this header unless explicitly configured to examine
			it.
	</t>		</t>
	<t>		</aside>
	<list style="symbols">		</section>
	<t>Type 0x00: Pad1 <xref target="RFC8200"/></t>		<section numbered="true" toc="default">
	<t>Type 0x01: PadN <xref target="RFC8200"/></t>		<name>Specification</name>
	<t>Type 0x05: Router Alert <xref target="RFC2711"/></t>		<t>This EH is specified in <xref target="RFC8200" format="default"/>
	<t>Type 0x07: CALIPSO <xref target="RFC5570"/></t>		. As of May 2022, the following options have been specified for the Hop-by-Hop O
	<t>Type 0x08: SMF_DPD <xref target="RFC6621"/></t>		ptions header:
	<t>Type 0x23: RPL Option <xref target="RFC9008"/></t>
	<t>Type 0x26: Quick-Start <xref target="RFC4782"/></t>
	<t>Type 0x4D: (Deprecated)</t>
	<t>Type 0x63: RPL Option <xref target="RFC6553"/></t>
	<t>Type 0x6D: MPL Option <xref target="RFC7731"/></t>
	<!-- [fgont] THis one is deprecated... I guess no need to mention it, right? -->
	<t>Type 0x8A: Endpoint Identification (Deprecated) <xref target="draft-ietf-nimr
	od-eid"/></t>
	<t>Type 0xC2: Jumbo Payload <xref target="RFC2675"/></t>
	<t>Type 0xEE: IPv6 DFF Header <xref target="RFC6971"/></t>
	<t>Type 0x1E: RFC3692-style Experiment <xref target="RFC4727"/></t>
	<t>Type 0x3E: RFC3692-style Experiment <xref target="RFC4727"/></t>
	<t>Type 0x5E: RFC3692-style Experiment <xref target="RFC4727"/></t>
	<t>Type 0x7E: RFC3692-style Experiment <xref target="RFC4727"/></t>
	<t>Type 0x9E: RFC3692-style Experiment <xref target="RFC4727"/></t>
	<t>Type 0xBE: RFC3692-style Experiment <xref target="RFC4727"/></t>
	<t>Type 0xDE: RFC3692-style Experiment <xref target="RFC4727"/></t>
	<t>Type 0xFE: RFC3692-style Experiment <xref target="RFC4727"/></t>
	</list></t>
	</section>
	<section title="Specific Security Implications">
	<t>Legacy nodes that process this extension header might be subject to Denial of
	Service attacks.</t>
	<t>NOTE: While <xref target="RFC8200"/> has removed this requirement, the deploy
	ed base may still reflect the classical behavior for a while, and hence the pote
	ntial security problems of this EH are still of concern.
	</t>		</t>
	</section>		<ul spacing="normal">
			<li>Type 0x00: Pad1 <xref target="RFC8200" format="default"/></li>
	<section title="Operational and Interoperability Impact if Blocked">		<li>Type 0x01: PadN <xref target="RFC8200" format="default"/></li>
	<t>Discarding packets containing a Hop-by-Hop Options EH would break any of the		<li>Type 0x05: Router Alert <xref target="RFC2711" format="default
	protocols that rely on it for proper functioning. For example, it would break RS		"/></li>
	VP <xref target="RFC2205"/> and multicast deployments, and would cause IPv6 jumb		<li>Type 0x07: CALIPSO <xref target="RFC5570" format="default"/></
	ograms to be discarded.</t>		li>
	</section>		<li>Type 0x08: SMF_DPD <xref target="RFC6621" format="default"/></
			li>
	<section title="Advice">		<li>Type 0x23: RPL Option <xref target="RFC9008" format="default"/
	<t>Nodes implementing <xref target="RFC8200"/> would already ignore this extensi		></li>
	on header unless explicitly required to process it. For legacy (<xref target="RF		<li>Type 0x26: Quick-Start <xref target="RFC4782" format="default"
	C2460"/>) nodes, the recommended configuration for the processing of these packe		/></li>
	ts depends on the features and capabilities of the underlying platform, the conf		<li>Type 0x4D: (Deprecated)</li>
	iguration of the platform, and also the deployment environment of the platform.		<li>Type 0x63: RPL Option <xref target="RFC6553" format="default"/
	On platforms that allow forwarding of packets with HBH Options on the fast path,		></li>
	we recommend that packets with a HBH Options EH be forwarded as normal. Otherwi		<li>Type 0x6D: MPL Option <xref target="RFC7731" format="default"/
	se, on platforms in which processing of packets with a IPv6 HBH Options EH is ca		></li>
	rried out in the slow path, and an option is provided to rate-limit these packet		<li>Type 0x8A: Endpoint Identification (Deprecated) <xref target="N
	s, we recommend that this option be selected. Finally, when packets containing a		IMROD-EID" format="default"/></li>
	HBH Options EH are processed in the slow-path, and the underlying platform does		<li>Type 0xC2: Jumbo Payload <xref target="RFC2675" format="defaul
	not have any mitigation options available for attacks based on these packets, w		t"/></li>
	e recommend that such platforms discard packets containing IPv6 HBH Options EHs.		<li>Type 0xEE: IPv6 DFF Header <xref target="RFC6971" format="defa
	</t>		ult"/></li>
			<li>Type 0x1E: RFC3692-style Experiment <xref target="RFC4727" for
	<t>Finally, we note that RPL (Routing Protocol for Low-Power and Lossy Networks)		mat="default"/></li>
	routers <xref target="RFC6550"/> must not discard packets based on the presenc		<li>Type 0x3E: RFC3692-style Experiment <xref target="RFC4727" for
	e of an IPv6 Hop-by-Hop Options EH, as this would break RPL.</t>		mat="default"/></li>
			<li>Type 0x5E: RFC3692-style Experiment <xref target="RFC4727" for
	</section>		mat="default"/></li>
	</section>		<li>Type 0x7E: RFC3692-style Experiment <xref target="RFC4727" for
			mat="default"/></li>
	<section title="Routing Header for IPv6 (Protocol Number=43)" anchor="proto43">		<li>Type 0x9E: RFC3692-style Experiment <xref target="RFC4727" for
	<section title="Uses">		mat="default"/></li>
	<t>The Routing header is used by an IPv6 source to list one or more intermediate		<li>Type 0xBE: RFC3692-style Experiment <xref target="RFC4727" for
	nodes to be "visited" on the way to a packet's destination. </t>		mat="default"/></li>
	</section>		<li>Type 0xDE: RFC3692-style Experiment <xref target="RFC4727" for
			mat="default"/></li>
	<section title="Specification">		<li>Type 0xFE: RFC3692-style Experiment <xref target="RFC4727" for
	<t>This EH is specified in <xref target="RFC8200"/>. <xref target="RFC2460"/> ha		mat="default"/></li>
	d originally specified the Routing Header Type 0, which was later obsoleted by <		</ul>
	xref target="RFC5095"/>, and thus removed from <xref target="RFC8200"/>.</t>		</section>
			<section numbered="true" toc="default">
	<t>At of May 2022, the following Routing Types have been specified:		<name>Specific Security Implications</name>
			<t>Legacy nodes that process this extension header might be subject
	<list style="symbols">		to DoS attacks.</t>
	<t>Type 0: Source Route (DEPRECATED) <xref target="RFC2460"/> <xref target="RFC5		<aside>
	095"/></t>		<t>NOTE: While <xref target="RFC8200" format="default"/> has removed
	<t>Type 1: Nimrod (DEPRECATED)</t>		the requirement for all nodes to examine and process the Hop-by-Hop Options hea
	<t>Type 2: Type 2 Routing Header <xref target="RFC6275"/></t>		der, the deployed base may still reflect the legacy <xref target="RFC2460"/> beh
	<t>Type 3: RPL Source Route Header <xref target="RFC6554"/></t>		avior for a while; hence, the potential security problems of this EH are still o
	<t>Type 4: Segment Routing Header (SRH) <xref target="RFC8754"/></t>		f concern.
	<t>Types 5-252: Unassigned </t>
	<t>Type 253: RFC3692-style Experiment 1 <xref target="RFC4727"/></t>
	<t>Type 254: RFC3692-style Experiment 2 <xref target="RFC4727"/></t>
	<t>Type 255: Reserved</t>
	</list>
	</t>		</t>
			</aside>
			</section>
			<section numbered="true" toc="default">
			<name>Operational and Interoperability Impact If Blocked</name>
			<t>Discarding packets containing a Hop-by-Hop Options header would b
			reak any of the protocols that rely on it for proper functioning. For example, i
			t would break RSVP <xref target="RFC2205" format="default"/> and multicast deplo
			yments and would cause IPv6 jumbograms to be discarded.</t>
			</section>
			<section numbered="true" toc="default">
			<name>Advice</name>
			<t>Nodes implementing <xref target="RFC8200" format="default"/> woul
			d already ignore this extension header unless explicitly required to process it.
			For legacy nodes <xref target="RFC2460" format="default"/>, the recommended con
			figuration for the processing of these packets depends on the features and capab
			ilities of the underlying platform, the configuration of the platform, and also
			the deployment environment of the platform. On platforms that allow the forwardi
			ng of packets with IPv6 HBH Options headers on the fast path, we recommend that
			packets with IPv6 HBH Options headers be forwarded as normal. Otherwise, on plat
			forms in which the processing of packets with IPv6 HBH Options headers is carrie
			d out in the slow path and an option is provided to rate-limit these packets, we
			recommend that this option be selected. Finally, when packets containing IPv6 H
			BH Options headers are processed in the slow path and the underlying platform do
			es not have any mitigation options available for attacks based on these packets,
			we recommend that such platforms discard packets containing IPv6 HBH Options he
			aders.</t>
			<t>Finally, we note that the Routing Protocol for Low-Power and Loss
			y Networks (RPL) routers <xref target="RFC6550" format="default"/> must not dis
			card packets based on the presence of an IPv6 Hop-by-Hop Options header, as this
			would break the RPL.</t>
			</section>
			</section>
			<section anchor="proto43" numbered="true" toc="default">
			<name>Routing Header (Protocol Number=43)</name>
			<section numbered="true" toc="default">
			<name>Uses</name>
			<t>The Routing Header is used by an IPv6 source to list one or more
			intermediate nodes to be "visited" on the way to a packet's destination. </t>
			</section>
			<section numbered="true" toc="default">
			<name>Specification</name>
			<t>This EH is specified in <xref target="RFC8200" format="default"/>
			. The Routing Type 0 had originally been specified in <xref target="RFC2460" for
			mat="default"/> and was later obsoleted by <xref target="RFC5095" format="defaul
			t"/>; thus, it was removed from <xref target="RFC8200" format="default"/>.</t>
			<t>As of May 2022, the following Routing Types have been specified:<
			/t>
			<ul spacing="normal">
			<li>Type 0: Source Route (DEPRECATED) <xref target="RFC2460" forma
			t="default"/> <xref target="RFC5095" format="default"/></li>
			<li>Type 1: Nimrod (DEPRECATED)</li>
			<li>Type 2: Type 2 Routing Header <xref target="RFC6275" format="d
			efault"/></li>
			<li>Type 3: RPL Source Route Header <xref target="RFC6554" format=
			"default"/></li>
			<li>Type 4: Segment Routing Header (SRH) <xref target="RFC8754" fo
			rmat="default"/></li>
			<li>Types 5-252: Unassigned</li>
			<li>Type 253: RFC3692-style Experiment 1 <xref target="RFC4727" fo
			rmat="default"/></li>
			<li>Type 254: RFC3692-style Experiment 2 <xref target="RFC4727" fo
			rmat="default"/></li>
			<li>Type 255: Reserved</li>
			</ul>
			</section>
			<section numbered="true" toc="default">
			<name>Specific Security Implications</name>
			<t>The security implications of Routing Headers of Routing Type 0 ha
			ve been discussed in detail in <xref target="Biondi-2007" format="default"/> and
			<xref target="RFC5095" format="default"/>. Routing Type 1 was never widely impl
			emented. The security implications of Routing Headers of Routing Type 2, Routing
			Type 3, and Routing Type 4 (SRH) are discussed in <xref target="RFC6275" format
			="default"/>, <xref target="RFC6554" format="default"/>, and <xref target="RFC8
			754" format="default"/>, respectively.</t>
			</section>
			<section numbered="true" toc="default">
			<name>Operational and Interoperability Impact If Blocked</name>
	</section>		<t>Blocking packets containing Routing Headers of Routing Type 0 or
			Routing Type 1 has no operational implications, since both have been deprecated.
	<section title="Specific Security Implications">		Blocking packets containing Routing Headers of Routing Type 2 would break Mobil
	<t>The security implications of RHT0 have been discussed in detail in <xref targ		e IPv6. Packets containing Routing Headers of Routing Type 3 may be safely block
	et="Biondi2007"/> and <xref target="RFC5095"/>. RHT1 was never widely implemente		ed at RPL domain boundaries, since such headers are employed within a single RPL
	d. The security implications of RHT2, RHT3, and RHT4 (SRH) are discussed in <xre		domain. Blocking packets containing Routing Headers of Routing Type 4 (SRH) wil
	f target="RFC6275"/>, <xref target="RFC6554"/>, and <xref target="RFC8754"/>, r		l break Segment Routing (SR) deployments if the filtering policy is enforced on
	espectively.</t>		packets being forwarded within an SR domain.</t>
	</section>		</section>
			<section numbered="true" toc="default">
	<section title="Operational and Interoperability Impact if Blocked">		<name>Advice</name>
	<t>Blocking packets containing a RHT0 or RHT1 has no operational implications, s
	ince both have been deprecated. Blocking packets with a RHT2 would break Mobile
	IPv6. Packets with a RHT3 may be safely blocked at RPL domain boundaries, since
	RHT3 headers are employed within a single RPL domain. Blocking packets with a RH
	T4 (SRH) will break Segment Routing (SR) deployments, if the filtering policy is
	enforced on packets being forwarded within an SR domain.</t>
	<!--<t>However, blocking packets employing other routing header types will break
	the protocols that rely on them.</t> -->
	</section>
	<section title="Advice">
	<t>Intermediate systems should discard packets containing a RHT0, RHT1, or RHT3.
	Other routing header types should be permitted, as required by <xref target="RF
	C7045"/>.</t>
	</section>
	</section>
	<section title="Fragment Header for IPv6 (Protocol Number=44)" anchor="proto44">
	<section title="Uses">
	<t>This EH provides the fragmentation functionality for IPv6.</t>
	</section>
	<section title="Specification">
	<t>This EH is specified in <xref target="RFC8200"/>.</t>
	</section>
	<section title="Specific Security Implications">
	<t>The security implications of the Fragment Header range from Denial of Service
	attacks (e.g. based on flooding a target with IPv6 fragments) to information le
	akage attacks <xref target="RFC7739"/>.</t>
	</section>
	<section title="Operational and Interoperability Impact if Blocked">
	<t>Blocking packets that contain a Fragment Header will break any protocol that
	may rely on fragmentation (e.g., the DNS <xref target="RFC1034"/>). However, IP
	fragmentation is known to introduce fragility to Internet communication <xref ta
	rget="RFC8900"/>.</t>
	</section>
	<section title="Advice">
	<t>Intermediate systems should permit packets that contain a Fragment Header.</t
	>
	</section>
	</section>
	<section title="Encapsulating Security Payload (Protocol Number=50)" anchor="pro
	to50">
	<section title="Uses">
	<t>This EH is employed for the IPsec suite <xref target="RFC4303"/>.</t>
	</section>
	<section title="Specification">
	<t>This EH is specified in <xref target="RFC4303"/>.</t>
	</section>
	<section title="Specific Security Implications">
	<t>Besides the general implications of IPv6 EHs, this EH could be employed to po
	tentially perform a DoS attack at the destination system by wasting CPU resource
	s in validating the contents of the packet.</t>
	</section>
	<section title="Operational and Interoperability Impact if Blocked">
	<t>Discarding packets that employ this EH would break IPsec deployments.</t>
	</section>
	<section title="Advice">
	<t>Intermediate systems should permit packets containing the Encapsulating Secur
	ity Payload EH.</t>
	</section>
	</section>
	<section title="Authentication Header (Protocol Number=51)" anchor="proto51">		<t>Intermediate systems should discard packets containing Routing He
	<section title="Uses">		aders of Routing Type 0, Routing Type 1, or Routing Type 3. Other Routing Types
	<t>The Authentication Header can be employed for provide authentication services		should be permitted, as required by <xref target="RFC7045" format="default"/>.</
	in		t>
			</section>
			</section>
			<section anchor="proto44" numbered="true" toc="default">
			<name>Fragment Header (Protocol Number=44)</name>
			<section numbered="true" toc="default">
			<name>Uses</name>
			<t>This EH provides the fragmentation and reassembly functionality f
			or IPv6.</t>
			</section>
			<section numbered="true" toc="default">
			<name>Specification</name>
			<t>This EH is specified in <xref target="RFC8200" format="default"/>
			.</t>
			</section>
			<section numbered="true" toc="default">
			<name>Specific Security Implications</name>
			<t>The security implications of the Fragment Header range from DoS a
			ttacks (e.g., based on flooding a target with IPv6 fragments) to information lea
			kage attacks <xref target="RFC7739" format="default"/>.</t>
			</section>
			<section numbered="true" toc="default">
			<name>Operational and Interoperability Impact If Blocked</name>
			<t>Blocking packets that contain a Fragment Header will break any pr
			otocol that may rely on fragmentation (e.g., the DNS <xref target="RFC1034" form
			at="default"/>). However, IP fragmentation is known to introduce fragility to In
			ternet communication <xref target="RFC8900" format="default"/>.</t>
			</section>
			<section numbered="true" toc="default">
			<name>Advice</name>
			<t>Intermediate systems should permit packets that contain a Fragmen
			t Header.</t>
			</section>
			</section>
			<section anchor="proto50" numbered="true" toc="default">
			<name>Encapsulating Security Payload (Protocol Number=50)</name>
			<section numbered="true" toc="default">
			<name>Uses</name>
			<t>This EH is employed for the IPsec suite <xref target="RFC4303" fo
			rmat="default"/>.</t>
			</section>
			<section numbered="true" toc="default">
			<name>Specification</name>
			<t>This EH is specified in <xref target="RFC4303" format="default"/>
			.</t>
			</section>
			<section numbered="true" toc="default">
			<name>Specific Security Implications</name>
			<t>Besides the general implications of IPv6 EHs, this EH could be em
			ployed to potentially perform a DoS attack at the destination system by wasting
			CPU resources in validating the contents of the packet.</t>
			</section>
			<section numbered="true" toc="default">
			<name>Operational and Interoperability Impact If Blocked</name>
			<t>Discarding packets that employ this EH would break IPsec deployme
			nts.</t>
			</section>
			<section numbered="true" toc="default">
			<name>Advice</name>
			<t>Intermediate systems should permit packets containing the Encapsu
			lating Security Payload EH.</t>
			</section>
			</section>
			<section anchor="proto51" numbered="true" toc="default">
			<name>Authentication Header (Protocol Number=51)</name>
			<section numbered="true" toc="default">
			<name>Uses</name>
			<t>The Authentication Header can be employed to provide authenticati
			on services in
	IPv4 and IPv6.</t>		IPv4 and IPv6.</t>
	</section>		</section>
			<section numbered="true" toc="default">
	<section title="Specification">		<name>Specification</name>
	<t>This EH is specified in <xref target="RFC4302"/>.</t>		<t>This EH is specified in <xref target="RFC4302" format="default"/>
	</section>		.</t>
			</section>
	<section title="Specific Security Implications">		<section numbered="true" toc="default">
	<t>Besides the general implications of IPv6 EHs, this EH could be employed to po		<name>Specific Security Implications</name>
	tentially perform a DoS attack at the destination system by wasting CPU resource		<t>Besides the general implications of IPv6 EHs, this EH could be em
	s in validating the contents of the packet.</t>		ployed to potentially perform a DoS attack at the destination system by wasting
	</section>		CPU resources in validating the contents of the packet.</t>
			</section>
	<section title="Operational and Interoperability Impact if Blocked">		<section numbered="true" toc="default">
	<t>Discarding packets that employ this EH would break IPsec deployments.</t>		<name>Operational and Interoperability Impact If Blocked</name>
	</section>		<t>Discarding packets that employ this EH would break IPsec deployme
			nts.</t>
	<section title="Advice">		</section>
	<t>Intermediate systems should permit packets containing an Authentication Heade		<section numbered="true" toc="default">
	r.</t>		<name>Advice</name>
	</section>		<t>Intermediate systems should permit packets containing an Authenti
	</section>		cation Header.</t>
			</section>
	<section title="Destination Options for IPv6 (Protocol Number=60)" anchor="proto		</section>
	60">		<section anchor="proto60" numbered="true" toc="default">
	<section title="Uses">		<name>Destination Options (Protocol Number=60)</name>
	<t>The Destination Options header is used to carry optional information that nee		<section numbered="true" toc="default">
	ds be examined only by a packet's destination node(s).</t>		<name>Uses</name>
	</section>		<t>The Destination Options (DO) header is used to carry optional inf
			ormation that needs be examined only by a packet's destination node(s).</t>
	<section title="Specification">		</section>
	<t>This EH is specified in <xref target="RFC8200"/>. As of May 2022, the followi		<section numbered="true" toc="default">
	ng options have been specified for this EH:		<name>Specification</name>
			<t>This EH is specified in <xref target="RFC8200" format="default"/>
	<list style="symbols">		. As of May 2022, the following options have been specified for this EH:
	<t>Type 0x00: Pad1 <xref target="RFC8200"/></t>
	<t>Type 0x01: PadN <xref target="RFC8200"/></t>
	<t>Type 0x04: Tunnel Encapsulation Limit <xref target="RFC2473"/></t>
	<t>Type 0x0F: IPv6 Performance and Diagnostic Metrics (PDM) <xref target="RFC825
	0"/></t>
	<t>Type 0x4D: (Deprecated)</t>
	<t>Type 0xC9: Home Address <xref target="RFC6275"/></t>
	<t>Type 0x8A: Endpoint Identification (Deprecated) <xref target="draft-ietf-nimr
	od-eid"/></t>
	<t>Type 0x8B: ILNP Nonce <xref target="RFC6744"/></t>
	<t>Type 0x8C: Line-Identification Option <xref target="RFC6788"/></t>
	<t>Type 0x1E: RFC3692-style Experiment <xref target="RFC4727"/></t>
	<t>Type 0x3E: RFC3692-style Experiment <xref target="RFC4727"/></t>
	<t>Type 0x5E: RFC3692-style Experiment <xref target="RFC4727"/></t>
	<t>Type 0x7E: RFC3692-style Experiment <xref target="RFC4727"/></t>
	<t>Type 0x9E: RFC3692-style Experiment <xref target="RFC4727"/></t>
	<t>Type 0xBE: RFC3692-style Experiment <xref target="RFC4727"/></t>
	<t>Type 0xDE: RFC3692-style Experiment <xref target="RFC4727"/></t>
	<t>Type 0xFE: RFC3692-style Experiment <xref target="RFC4727"/></t>
	</list>
	</t>		</t>
	</section>		<ul spacing="normal">
			<li>Type 0x00: Pad1 <xref target="RFC8200" format="default"/></li>
	<section title="Specific Security Implications">		<li>Type 0x01: PadN <xref target="RFC8200" format="default"/></li>
	<t>No security implications are known, other than the general implications of IP		<li>Type 0x04: Tunnel Encapsulation Limit <xref target="RFC2473" f
	v6 EHs. For a discussion of possible security implications of specific options s		ormat="default"/></li>
	pecified for the DO header, please see the <xref target="opt-filtering"/>.</t>		<li>Type 0x0F: IPv6 Performance and Diagnostic Metrics (PDM) <xref
	</section>		target="RFC8250" format="default"/></li>
			<li>Type 0x4D: (Deprecated)</li>
	<section title="Operational and Interoperability Impact if Blocked">		<li>Type 0xC9: Home Address <xref target="RFC6275" format="default
	<t>Discarding packets that contain a Destination Options header would break prot		"/></li>
	ocols that rely on this EH type for conveying information, including protocols s		<li>Type 0x8A: Endpoint Identification (Deprecated) <xref target="
	uch as ILNP <xref target="RFC6740"/> and Mobile IPv6 <xref target="RFC6275"/>, a		NIMROD-EID" format="default"/></li>
	nd IPv6 tunnels that employ the Tunnel Encapsulation Limit option.</t>		<li>Type 0x8B: ILNP Nonce <xref target="RFC6744" format="default"/
	</section>		></li>
			<li>Type 0x8C: Line-Identification Option <xref target="RFC6788" f
	<section title="Advice">		ormat="default"/></li>
	<t>Intermediate systems should permit packets that contain a Destination Options		<li>Type 0x1E: RFC3692-style Experiment <xref target="RFC4727" for
	Header.</t>		mat="default"/></li>
	</section>		<li>Type 0x3E: RFC3692-style Experiment <xref target="RFC4727" for
	</section>		mat="default"/></li>
			<li>Type 0x5E: RFC3692-style Experiment <xref target="RFC4727" for
	<section title="Mobility Header (Protocol Number=135)" anchor="proto135">		mat="default"/></li>
	<section title="Uses">		<li>Type 0x7E: RFC3692-style Experiment <xref target="RFC4727" for
	<t>The Mobility Header is an EH used by mobile nodes, correspondent nodes, and h		mat="default"/></li>
	ome agents in all messaging related to the creation and management of bindings i		<li>Type 0x9E: RFC3692-style Experiment <xref target="RFC4727" for
	n Mobile IPv6.</t>		mat="default"/></li>
	</section>		<li>Type 0xBE: RFC3692-style Experiment <xref target="RFC4727" for
			mat="default"/></li>
	<section title="Specification">		<li>Type 0xDE: RFC3692-style Experiment <xref target="RFC4727" for
	<t>This EH is specified in <xref target="RFC6275"/>.</t>		mat="default"/></li>
	</section>		<li>Type 0xFE: RFC3692-style Experiment <xref target="RFC4727" for
			mat="default"/></li>
	<section title="Specific Security Implications">		</ul>
	<t>A thorough security assessment of the security implications of the Mobility H		</section>
	eader and related mechanisms can be found in Section 15 of <xref target="RFC6275		<section numbered="true" toc="default">
	"/>.</t>		<name>Specific Security Implications</name>
	</section>		<t>No security implications are known, other than the general securi
			ty implications of IPv6 EHs. For a discussion of possible security implications
	<section title="Operational and Interoperability Impact if Blocked">		of specific options specified for the DO header, please see <xref target="opt-fi
	<t>Discarding packets containing this EH would break Mobile IPv6.</t>		ltering" format="default"/>.</t>
	</section>		</section>
			<section numbered="true" toc="default">
	<section title="Advice">		<name>Operational and Interoperability Impact If Blocked</name>
	<t>Intermediate systems should permit packets containing this EH.</t>		<t>Discarding packets that contain a Destination Options header woul
	</section>		d break protocols that rely on this EH type for conveying information (such as t
	</section>		he Identifier-Locator Network Protocol (ILNP) <xref target="RFC6740" format="def
			ault"/> and Mobile IPv6 <xref target="RFC6275" format="default"/>), as well as I
	<section title="Host Identity Protocol (Protocol Number=139)" anchor="proto139">		Pv6 tunnels that employ the Tunnel Encapsulation Limit option <xref target="RFC2
	<section title="Uses">		473"/>.</t>
	<t>This EH is employed with the Host Identity Protocol (HIP), a protocol that al		</section>
	lows consenting hosts to securely establish and maintain shared IP-layer state,		<section numbered="true" toc="default">
	allowing separation of the identifier and locator roles of IP addresses, thereby		<name>Advice</name>
	enabling continuity of communications across IP address changes.</t>		<t>Intermediate systems should permit packets that contain a Destina
	</section>		tion Options header.</t>
			</section>
	<section title="Specification">		</section>
	<t>This EH is specified in <xref target="RFC7401"/>.</t>		<section anchor="proto135" numbered="true" toc="default">
	</section>		<name>Mobility Header (Protocol Number=135)</name>
			<section numbered="true" toc="default">
	<section title="Specific Security Implications">		<name>Uses</name>
	<t>The security implications of the HIP header are discussed in detail in Sectio		<t>The Mobility Header is an EH used by mobile nodes, correspondent
	n 8 of <xref target="RFC6275"/>.</t>		nodes, and home agents in all messaging related to the creation and management o
	</section>		f bindings in Mobile IPv6.</t>
			</section>
	<section title="Operational and Interoperability Impact if Blocked">		<section numbered="true" toc="default">
	<t>Discarding packets that contain the Host Identity Protocol would break HIP de		<name>Specification</name>
	ployments.</t>		<t>This EH is specified in <xref target="RFC6275" format="default"/>
	</section>		.</t>
			</section>
	<section title="Advice">		<section numbered="true" toc="default">
	<t>Intermediate systems should permit packets that contain a Host Identity Proto		<name>Specific Security Implications</name>
	col EH.</t>		<t>A thorough security assessment of the security implications of th
	</section>		e Mobility Header and related mechanisms can be found in <xref target="RFC6275"
	</section>		sectionFormat="of" section="15"/>.</t>
			</section>
	<section title="Shim6 Protocol (Protocol Number=140)" anchor="proto140">		<section numbered="true" toc="default">
	<section title="Uses">		<name>Operational and Interoperability Impact If Blocked</name>
	<t>This EH is employed by the Shim6 <xref target="RFC5533"/> Protocol.</t>		<t>Discarding packets containing this EH would break Mobile IPv6.</t
	</section>		>
			</section>
	<section title="Specification">		<section numbered="true" toc="default">
	<t>This EH is specified in <xref target="RFC5533"/>.</t>		<name>Advice</name>
	</section>		<t>Intermediate systems should permit packets that contain a Mobilit
			y Header.</t>
	<section title="Specific Security Implications">		</section>
	<t>The specific security implications are discussed in detail in Section 16 of <		</section>
	xref target="RFC5533"/>.</t>		<section anchor="proto139" numbered="true" toc="default">
	</section>		<name>Host Identity Protocol (Protocol Number=139)</name>
			<section numbered="true" toc="default">
	<section title="Operational and Interoperability Impact if Blocked">		<name>Uses</name>
	<t>Discarding packets that contain this EH will break Shim6.</t>		<t>This EH is employed with the Host Identity Protocol (HIP), which
	</section>		is a protocol that allows consenting hosts to securely establish and maintain sh
			ared IP-layer state, allowing the separation of the identifier and locator roles
	<section title="Advice">		of IP addresses, thereby enabling continuity of communications across IP addres
	<t>Intermediate systems should permit packets containing this EH.</t>		s changes.</t>
	</section>		</section>
	</section>		<section numbered="true" toc="default">
			<name>Specification</name>
	<section title="Use for experimentation and testing (Protocol Numbers=253 and 25		<t>This EH is specified in <xref target="RFC7401" format="default"/>
	4)" anchor="proto253254">		.</t>
	<section title="Uses">		</section>
	<t>These IPv6 EHs are employed for performing RFC3692-Style experiments (see <xr		<section numbered="true" toc="default">
	ef target="RFC3692"/> for details).</t>		<name>Specific Security Implications</name>
	</section>		<t>The security implications of the HIP header are discussed in deta
			il in <xref target="RFC7401" sectionFormat="of" section="8"/>.</t>
	<section title="Specification">		</section>
	<t>These EHs are specified in <xref target="RFC3692"/> and <xref target="RFC4727		<section numbered="true" toc="default">
	"/>.</t>		<name>Operational and Interoperability Impact If Blocked</name>
	</section>		<t>Discarding packets that contain a HIP header would break HIP depl
			oyments.</t>
	<section title="Specific Security Implications">		</section>
	<t>The security implications of these EHs will depend on their specific use.</t>		<section numbered="true" toc="default">
	</section>		<name>Advice</name>
			<t>Intermediate systems should permit packets that contain a HIP hea
	<section title="Operational and Interoperability Impact if Blocked">		der.</t>
	<t>For obvious reasons, discarding packets that contain these EHs limits the abi		</section>
	lity to perform legitimate experiments across IPv6 routers.		</section>
			<section anchor="proto140" numbered="true" toc="default">
			<name>Shim6 Protocol (Protocol Number=140)</name>
			<section numbered="true" toc="default">
			<name>Uses</name>
			<t>This EH is employed by the Shim6 protocol <xref target="RFC5533"
			format="default"/>.</t>
			</section>
			<section numbered="true" toc="default">
			<name>Specification</name>
			<t>This EH is specified in <xref target="RFC5533" format="default"/>
			.</t>
			</section>
			<section numbered="true" toc="default">
			<name>Specific Security Implications</name>
			<t>The specific security implications are discussed in detail in <xr
			ef target="RFC5533" sectionFormat="of" section="16"/>.</t>
			</section>
			<section numbered="true" toc="default">
			<name>Operational and Interoperability Impact If Blocked</name>
			<t>Discarding packets that contain this EH will break Shim6.</t>
			</section>
			<section numbered="true" toc="default">
			<name>Advice</name>
			<t>Intermediate systems should permit packets containing this EH.</t
			>
			</section>
			</section>
			<section anchor="proto253254" numbered="true" toc="default">
			<name>Use for Experimentation and Testing (Protocol Numbers=253 and 25
			4)</name>
			<section numbered="true" toc="default">
			<name>Uses</name>
			<t>These IPv6 EHs are employed for performing RFC3692-style experime
			nts (see <xref target="RFC3692" format="default"/> for details).</t>
			</section>
			<section numbered="true" toc="default">
			<name>Specification</name>
			<t>These EHs are specified in <xref target="RFC3692" format="default
			"/> and <xref target="RFC4727" format="default"/>.</t>
			</section>
			<section numbered="true" toc="default">
			<name>Specific Security Implications</name>
			<t>The security implications of these EHs will depend on their speci
			fic use.</t>
			</section>
			<section numbered="true" toc="default">
			<name>Operational and Interoperability Impact If Blocked</name>
			<t>For obvious reasons, discarding packets that contain these EHs li
			mits the ability to perform legitimate experiments across IPv6 routers.
	</t>		</t>
	</section>		</section>
			<section numbered="true" toc="default">
	<section title="Advice">		<name>Advice</name>
	<t>Operators should determine according to their own circumstances whether to di		<t>Operators should determine, according to their own circumstances,
	scard packets containing these EHs.</t>		whether to discard packets containing these EHs.</t>
	<!--
	<t>Intermediate systems should discard packets containing these EHs. Only in spe
	cific scenarios in which RFC3692-Style experiments are to be performed should th
	ese EHs be permitted.</t> -->
	</section>
	</section>
	</section>		</section>
	<section title="Advice on the Handling of Packets with Unknown IPv6 Extension He		</section>
	aders" anchor="unknown-headers">		</section>
	<t>We refer to IPv6 EHs that have not been assigned an Internet Protocol Number		<section anchor="unknown-headers" numbered="true" toc="default">
	by IANA (and marked as such) in <xref target="IANA-PROTOCOLS"/> as "unknown IPv6		<name>Advice on the Handling of Packets with Unknown IPv6 Extension Head
	extension headers" ("unknown IPv6 EHs").		ers</name>
			<t>We refer to IPv6 EHs that have not been assigned an Internet Protocol
			number by IANA (and marked as such) in <xref target="IANA-PROTOCOLS" format="de
			fault"/> as "unknown IPv6 Extension Headers" ("unknown IPv6 EHs").
	</t>		</t>
			<section numbered="true" toc="default">
	<section title="Uses">		<name>Uses</name>
	<t>New IPv6 EHs may be specified as part of future extensions to the IPv6 protoc		<t>New IPv6 EHs may be specified as part of future extensions to the I
	ol.		Pv6 protocol.
	</t>		</t>
			<t>Since IPv6 EHs and upper-layer protocols employ the same namespace,
	<t>Since IPv6 EHs and Upper-layer protocols employ the same namespace, it is imp		it is impossible to tell whether an unknown Internet Protocol number is being e
	ossible to tell whether an unknown "Internet Protocol Number" is being employed		mployed for an IPv6 EH or an upper-layer protocol.
	for an IPv6 EH or an Upper-Layer protocol.
	</t>		</t>
			</section>
	</section>		<section numbered="true" toc="default">
			<name>Specification</name>
	<section title="Specification">		<t>The processing of unknown IPv6 EHs is specified in <xref target="RF
	<t>The processing of unknown IPv6 EHs is specified in <xref target="RFC7045"/>.<		C7045" format="default"/>.</t>
	/t>		</section>
	</section>		<section numbered="true" toc="default">
			<name>Specific Security Implications</name>
	<section title="Specific Security Implications">		<t>For obvious reasons, it is impossible to determine specific securit
	<t>For obvious reasons, it is impossible to determine specific security implicat		y implications of unknown IPv6 EHs.</t>
	ions of unknown IPv6 EHs.</t>		</section>
	</section>		<section numbered="true" toc="default">
			<name>Operational and Interoperability Impact If Blocked</name>
	<section title="Operational and Interoperability Impact if Blocked">		<t>As noted in <xref target="RFC7045" format="default"/>, discarding u
	<t>As noted in <xref target="RFC7045"/>, discarding unknown IPv6 EHs may slow do		nknown IPv6 EHs may slow down the deployment of new IPv6 EHs and transport proto
	wn the deployment of new IPv6 EHs and transport protocols. The corresponding IAN		cols. The corresponding IANA registry, which is <xref target="IANA-PROTOCOLS" fo
	A registry (<xref target="IANA-PROTOCOLS"/>) should be monitored such that filte		rmat="default"/>, should be monitored such that filtering rules are updated as n
	ring rules are updated as new IPv6 EHs are standardized.</t>		ew IPv6 EHs are standardized.</t>
			<t>We note that since IPv6 EHs and upper-layer protocols share the sam
	<t>We note that since IPv6 EHs and upper-layer protocols share the same numberin		e numbering space, discarding unknown IPv6 EHs may result in packets encapsulati
	g space, discarding unknown IPv6 EHs may result in packets encapsulating unknown		ng unknown upper-layer protocols being discarded.
	upper-layer protocols being discarded.
	</t>		</t>
	</section>		</section>
			<section numbered="true" toc="default">
	<section title="Advice">		<name>Advice</name>
	<t>Operators should determine according to their own circumstances whether to di		<t>Operators should determine, according to their own circumstances, w
	scard packets containing unknown IPv6 EHs.</t>		hether to discard packets containing unknown IPv6 EHs.</t>
	</section>		</section>
			</section>
	</section>		</section>
			<section anchor="ipv6-options-discussion" numbered="true" toc="default">
	</section>		<name>IPv6 Options</name>
			<section anchor="ipv6-options-general-discussion" numbered="true" toc="def
	<section title="IPv6 Options" anchor="ipv6-options-discussion">		ault">
	<section title="General Discussion" anchor="ipv6-options-general-discussion">		<name>General Discussion</name>
	<t>The following subsections describe specific security implications of differen		<t>The following subsections describe specific security implications of
	t IPv6 options, and provide advice regarding filtering packets that contain such		different IPv6 options and provide advice regarding filtering packets that conta
	options.		in such options.
	</t>		</t>
	</section>		</section>
			<section anchor="ipv6-options-general-implications" numbered="true" toc="d
	<section title="General Security Implications of IPv6 Options" anchor="ipv6-opti		efault">
	ons-general-implications">		<name>General Security Implications of IPv6 Options</name>
	<t>The general security implications of IPv6 options are closely related to thos		<t>The general security implications of IPv6 options are closely related
	e discussed in <xref target="ipv6-eh-general-implications"/> for IPv6 EHs. Essen		to those discussed in <xref target="ipv6-eh-general-implications" format="defau
	tially, packets that contain IPv6 options might need to be processed by an IPv6		lt"/> for IPv6 EHs. Essentially, packets that contain IPv6 options might need to
	router's general-purpose CPU,and hence could present a DDoS risk to that router'		be processed by an IPv6 router's general-purpose CPU and, hence, could present
	s general-purpose CPU (and thus to the router itself). For some architectures, a		a Distributed Denial-of-Service (DDoS) risk to that router's general-purpose CPU
	possible mitigation would be to rate-limit the packets that are to be processed		(and thus to the router itself). For some architectures, a possible mitigation
	by the general-purpose CPU (see e.g. <xref target="Cisco-EH"/>).</t>		would be to rate-limit the packets that are to be processed by the general-purpo
	</section>		se CPU (see, e.g., <xref target="Cisco-EH" format="default"/>).</t>
			</section>
	<section title="Summary of Advice on the Handling of IPv6 Packets with Specific		<section numbered="true" toc="default">
	IPv6 Extension Headers">		<name>Summary of Advice on the Handling of IPv6 Packets with Specific IP
	<t>This section summarizes the advice provided in <xref target="advice-ehs"/>, p		v6 Options</name>
	roviding references to the specific sections in which a detailed analysis can be		<t>This section summarizes the advice provided in <xref target="opt-filt
	found.</t>		ering" format="default"/>, and it includes references to the specific sections i
			n which a detailed analysis can be found.</t>
	<texttable title="Summary of Advice on the Handling of IPv6 Packets with Spe		<table anchor="option-table" align="center">
	cific IPv6 options" style="all" anchor="option-table">		<name>Summary of Advice on the Handling of IPv6 Packets with Specific
	<ttcol align="center">Option</ttcol>		IPv6 Options</name>
	<ttcol align="center">Filtering policy</ttcol>		<thead>
	<ttcol align="center">Reference</ttcol>		<tr>
	<c>Pad1 (Type=0x00)</c><c>Permit</c><c><xref target="x00"/></c>		<th align="center">Option</th>
	<c>PadN (Type=0x01)</c><c>Permit</c><c><xref target="x01"/></c>		<th align="center">Filtering Policy</th>
	<c>Tunnel Encapsulation Limit (Type=0x04)</c><c>Permit</c><c><xref target="x04"/		<th align="center">Reference</th>
	></c>		</tr>
	<c>Router Alert (Type=0x05)</c><c>Permit based on needed functionality</c><c><xr		</thead>
	ef target="x05"/></c>		<tbody>
	<c>CALIPSO (Type=0x07)</c><c>Permit based on needed functionality</c><c><xref ta		<tr>
	rget="x07"/></c>		<td align="center">Pad1 (Type=0x00)</td>
	<c>SMF_DPD (Type=0x08)</c><c>Permit based on needed functionality</c><c><xref ta		<td align="center">Permit</td>
	rget="x08"/></c>		<td align="center">
	<c>PDM Option (Type=0x0F)</c><c>Permit</c><c><xref target="x0F"/></c>		<xref target="x00" format="default"/></td>
	<c>RPL Option (Type=0x23)</c><c>Permit</c><c><xref target="x23"/></c>		</tr>
	<c>Quick-Start (Type=0x26)</c><c>Permit</c><c><xref target="x26"/></c>		<tr>
	<c>Deprecated (Type=0x4D)</c><c>Drop</c><c><xref target="x4D"/></c>		<td align="center">PadN (Type=0x01)</td>
	<c>MPL Option (Type=0x6D)</c><c>Permit</c><c><xref target="x6D"/></c>		<td align="center">Permit</td>
	<c>Jumbo Payload (Type=0C2)</c><c>Permit based on needed functionality</c><c><xr		<td align="center">
	ef target="xC2"/></c>		<xref target="x01" format="default"/></td>
	<c>RPL Option (Type=0x63)</c><c>Drop in non-RPL routers</c><c><xref target="x63"		</tr>
	/></c>		<tr>
	<c>Endpoint Identification (Type=0x8A)</c><c>Drop</c><c><xref target="x8A"/></c>		<td align="center">Tunnel Encapsulation Limit (Type=0x04)</td>
	<c>ILNP Nonce (Type=0x8B)</c><c>Permit</c><c><xref target="x8B"/></c>		<td align="center">Permit</td>
	<c>Line-Identification Option (Type=0x8C)</c><c>Drop</c><c><xref target="x8C"/><		<td align="center">
	/c>		<xref target="x04" format="default"/></td>
	<c>Home Address (Type=0xC9)</c><c>Permit</c><c><xref target="xC9"/></c>		</tr>
	<c>IP_DFF (Type=0xEE)</c><c>Permit based on needed functionality</c><c><xref tar		<tr>
	get="xEE"/></c>		<td align="center">Router Alert (Type=0x05)</td>
	<c>RFC3692-style Experiment (Types = 0x1E, 0x3E, 0x5E, 0x7E, 0x9E, 0xBE, 0xDE, 0		<td align="center">Permit based on needed functionality</td>
	xFE)</c><c>Permit based on needed functionality</c><c><xref target="x1E"/></c>		<td align="center">
			<xref target="x05" format="default"/></td>
	</texttable>		</tr>
			<tr>
	</section>		<td align="center">CALIPSO (Type=0x07)</td>
			<td align="center">Permit based on needed functionality</td>
	<section title="Advice on the Handling of Packets with Specific IPv6 Options" an		<td align="center">
	chor="opt-filtering">		<xref target="x07" format="default"/></td>
	<t>The following subsections contain a description of each of the IPv6 options t		</tr>
	hat have so far been specified, a summary of the security implications of each o		<tr>
	f such options, a discussion of possible		<td align="center">SMF_DPD (Type=0x08)</td>
			<td align="center">Permit based on needed functionality</td>
			<td align="center">
			<xref target="x08" format="default"/></td>
			</tr>
			<tr>
			<td align="center">PDM Option (Type=0x0F)</td>
			<td align="center">Permit</td>
			<td align="center">
			<xref target="x0F" format="default"/></td>
			</tr>
			<tr>
			<td align="center">RPL Option (Type=0x23)</td>
			<td align="center">Permit</td>
			<td align="center">
			<xref target="x23" format="default"/></td>
			</tr>
			<tr>
			<td align="center">Quick-Start (Type=0x26)</td>
			<td align="center">Permit</td>
			<td align="center">
			<xref target="x26" format="default"/></td>
			</tr>
			<tr>
			<td align="center">Deprecated (Type=0x4D)</td>
			<td align="center">Drop</td>
			<td align="center">
			<xref target="x4D" format="default"/></td>
			</tr>
			<tr>
			<td align="center">MPL Option (Type=0x6D)</td>
			<td align="center">Permit</td>
			<td align="center">
			<xref target="x6D" format="default"/></td>
			</tr>
			<tr>
			<td align="center">Jumbo Payload (Type=0xC2)</td>
			<td align="center">Permit based on needed functionality</td>
			<td align="center">
			<xref target="xC2" format="default"/></td>
			</tr>
			<tr>
			<td align="center">RPL Option (Type=0x63)</td>
			<td align="center">Drop</td>
			<td align="center">
			<xref target="x63" format="default"/></td>
			</tr>
			<tr>
			<td align="center">Endpoint Identification (Type=0x8A)</td>
			<td align="center">Drop</td>
			<td align="center">
			<xref target="x8A" format="default"/></td>
			</tr>
			<tr>
			<td align="center">ILNP Nonce (Type=0x8B)</td>
			<td align="center">Permit</td>
			<td align="center">
			<xref target="x8B" format="default"/></td>
			</tr>
			<tr>
			<td align="center">Line-Identification Option (Type=0x8C)</td>
			<td align="center">Drop</td>
			<td align="center">
			<xref target="x8C" format="default"/></td>
			</tr>
			<tr>
			<td align="center">Home Address (Type=0xC9)</td>
			<td align="center">Permit</td>
			<td align="center">
			<xref target="xC9" format="default"/></td>
			</tr>
			<tr>
			<td align="center">IP_DFF (Type=0xEE)</td>
			<td align="center">Permit based on needed functionality</td>
			<td align="center">
			<xref target="xEE" format="default"/></td>
			</tr>
			<tr>
			<td align="center">RFC3692-style Experiment (Types = 0x1E, 0x3E, 0
			x5E, 0x7E, 0x9E, 0xBE, 0xDE, 0xFE)</td>
			<td align="center">Permit based on needed functionality</td>
			<td align="center">
			<xref target="x1E" format="default"/></td>
			</tr>
			</tbody>
			</table>
			</section>
			<section anchor="opt-filtering" numbered="true" toc="default">
			<name>Advice on the Handling of Packets with Specific IPv6 Options</name
			>
			<t>The following subsections contain a description of each of the IPv6 o
			ptions that have so far been specified, a summary of the security implications o
			f each of such options, a discussion of possible
	interoperability implications if packets containing such options are		interoperability implications if packets containing such options are
	discarded, and specific advice regarding whether packets containing these op tions should be permitted.</t>		discarded, and specific advice regarding whether packets containing these op tions should be permitted.</t>
			<section anchor="x00" numbered="true" toc="default">
	<section title="Pad1 (Type=0x00)" anchor="x00">		<name>Pad1 (Type=0x00)</name>
	<section title="Uses">		<section numbered="true" toc="default">
	<t>This option is used when necessary to align subsequent options and to pad out		<name>Uses</name>
	the containing header to a multiple of 8 octets in length.</t>		<t>This option is used when necessary to align subsequent options an
	</section>		d to pad out the containing header to a multiple of 8 octets in length.</t>
			</section>
	<section title="Specification">		<section numbered="true" toc="default">
	<t>This option is specified in <xref target="RFC8200"/>.</t>		<name>Specification</name>
	</section>		<t>This option is specified in <xref target="RFC8200" format="defaul
			t"/>.</t>
	<section title="Specific Security Implications">		</section>
	<t>None.</t>		<section numbered="true" toc="default">
	</section>		<name>Specific Security Implications</name>
			<t>None.</t>
	<section title="Operational and Interoperability Impact if Blocked">		</section>
	<t>Discarding packets that contain this option would potentially break any proto		<section numbered="true" toc="default">
	col that relies on IPv6 options.</t>		<name>Operational and Interoperability Impact If Blocked</name>
	</section>		<t>Discarding packets that contain this option would potentially bre
			ak any protocol that relies on IPv6 options.</t>
	<section title="Advice">		</section>
	<t>Intermediate systems should not discard packets based on the presence of this		<section numbered="true" toc="default">
	option.</t>		<name>Advice</name>
	</section>		<t>Intermediate systems should not discard packets based on the pres
	</section>		ence of this option.</t>
			</section>
	<section title="PadN (Type=0x01)" anchor="x01">		</section>
	<section title="Uses">		<section anchor="x01" numbered="true" toc="default">
	<t>This option is used when necessary to align subsequent options and to pad out		<name>PadN (Type=0x01)</name>
	the containing header to a multiple of 8 octets in length.</t>		<section numbered="true" toc="default">
	</section>		<name>Uses</name>
			<t>This option is used when necessary to align subsequent options an
	<section title="Specification">		d to pad out the containing header to a multiple of 8 octets in length.</t>
	<t>This option is specified in <xref target="RFC8200"/>.</t>		</section>
	</section>		<section numbered="true" toc="default">
			<name>Specification</name>
	<section title="Specific Security Implications">		<t>This option is specified in <xref target="RFC8200" format="defaul
	<t>Because of the possible size of this option, it could be leveraged as a large		t"/>.</t>
	-bandwidth covert channel.</t>		</section>
	</section>		<section numbered="true" toc="default">
			<name>Specific Security Implications</name>
	<section title="Operational and Interoperability Impact if Blocked">		<t>Because of the possible size of this option, it could be leverage
	<t>Discarding packets that contain this option would potentially break any proto		d as a large-bandwidth covert channel.</t>
	col that relies on IPv6 options.</t>		</section>
	</section>		<section numbered="true" toc="default">
			<name>Operational and Interoperability Impact If Blocked</name>
	<section title="Advice">		<t>Discarding packets that contain this option would potentially bre
	<t>Intermediate systems should not discard IPv6 packets based on the presence of		ak any protocol that relies on IPv6 options.</t>
	this option.</t>		</section>
	</section>		<section numbered="true" toc="default">
	</section>		<name>Advice</name>
			<t>Intermediate systems should not discard IPv6 packets based on the
	<section title="Tunnel Encapsulation Limit (Type=0x04)" anchor="x04">		presence of this option.</t>
	<section title="Uses">		</section>
	<t>The Tunnel Encapsulation Limit option can be employed to specify how many fur		</section>
	ther levels of nesting the packet is permitted to undergo.</t>		<section anchor="x04" numbered="true" toc="default">
	</section>		<name>Tunnel Encapsulation Limit (Type=0x04)</name>
			<section numbered="true" toc="default">
	<section title="Specification">		<name>Uses</name>
	<t>This option is specified in <xref target="RFC2473"/>.</t>		<t>The Tunnel Encapsulation Limit option can be employed to specify
	</section>		how many further levels of nesting the packet is permitted to undergo.</t>
			</section>
	<section title="Specific Security Implications">		<section numbered="true" toc="default">
	<t>Those described in <xref target="RFC2473"/>.</t>		<name>Specification</name>
	</section>		<t>This option is specified in <xref target="RFC2473" format="defaul
			t"/>.</t>
	<section title="Operational and Interoperability Impact if Blocked">		</section>
	<t>Discarding packets based on the presence of this option could result in tunne		<section numbered="true" toc="default">
	l traffic being discarded.</t>		<name>Specific Security Implications</name>
	</section>		<t>These are discussed in <xref target="RFC2473" format="default"/>.
			</t>
	<section title="Advice">		</section>
	<t>Intermediate systems should not discard packets based on the presence of this		<section numbered="true" toc="default">
	option.</t>		<name>Operational and Interoperability Impact If Blocked</name>
	</section>		<t>Discarding packets based on the presence of this option could res
	</section>		ult in tunnel traffic being discarded.</t>
			</section>
	<section title="Router Alert (Type=0x05)" anchor="x05">		<section numbered="true" toc="default">
	<section title="Uses">		<name>Advice</name>
	<t>The Router Alert option <xref target="RFC2711"/> is employed by a number of p		<t>Intermediate systems should not discard packets based on the pres
	rotocols, including the Resource reSerVation Protocol (RSVP) <xref target="RFC22		ence of this option.</t>
	05"/>, Multicast Listener Discovery (MLD) <xref target="RFC2710"/> <xref target=		</section>
	"RFC3810"/>, Multicast Router Discovery (MRD) <xref target="RFC4286"/>, and Gene		</section>
	ral Internet Signaling Transport (GIST) <xref target="RFC5971"/>. Its usage is d		<section anchor="x05" numbered="true" toc="default">
	iscussed in detail in <xref target="RFC6398"/>.		<name>Router Alert (Type=0x05)</name>
			<section numbered="true" toc="default">
			<name>Uses</name>
			<t>The Router Alert option <xref target="RFC2711" format="default"/>
			is employed by a number of protocols, including the Resource reSerVation Protoc
			ol (RSVP) <xref target="RFC2205" format="default"/>, Multicast Listener Discover
			y (MLD) <xref target="RFC2710" format="default"/> <xref target="RFC3810" format=
			"default"/>, Multicast Router Discovery (MRD) <xref target="RFC4286" format="def
			ault"/>, and General Internet Signaling Transport (GIST) <xref target="RFC5971"
			format="default"/>. Its usage is discussed in detail in <xref target="RFC6398" f
			ormat="default"/>.
	</t>		</t>
			</section>
	</section>		<section numbered="true" toc="default">
			<name>Specification</name>
	<section title="Specification">		<t>This option is specified in <xref target="RFC2711" format="defaul
	<t>This option is specified in <xref target="RFC2711"/>.</t>		t"/>.</t>
	</section>		</section>
			<section anchor="ra-usage" numbered="true" toc="default">
	<section title="Specific Security Implications" anchor="ra-usage">		<name>Specific Security Implications</name>
	<t>Since this option causes the contents of the packet to be inspected by the ha		<t>Since this option causes the contents of the packet to be inspect
	ndling device, this option could be leveraged for performing DoS attacks. The se		ed by the handling device, this option could be leveraged for performing DoS att
	curity implications of the Router Alert option are discussed in detail in <xref		acks. The security implications of the Router Alert option are discussed in deta
	target="RFC6398"/>.</t>		il in <xref target="RFC6398" format="default"/>.</t>
	</section>		</section>
			<section numbered="true" toc="default">
	<section title="Operational and Interoperability Impact if Blocked">		<name>Operational and Interoperability Impact If Blocked</name>
	<t>Discarding packets that contain this option would break any protocols that re		<t>Discarding packets that contain this option would break any proto
	ly on them, such as RSVP and multicast deployments. Please see <xref target="ra-		cols that rely on them, such as RSVP and multicast deployments. Please see <xref
	usage"/> for further details.</t>		target="ra-usage" format="default"/> for further details.</t>
	</section>		</section>
			<section numbered="true" toc="default">
	<section title="Advice">		<name>Advice</name>
	<t>Packets containing this option should be permitted in environments where supp		<t>Packets containing this option should be permitted in environment
	ort for RSVP, multicast routing, or similar protocols is desired.</t>		s where support for RSVP, multicast routing, or similar protocols is required.</
	</section>		t>
	</section>		</section>
			</section>
	<section title="CALIPSO (Type=0x07)" anchor="x07">		<section anchor="x07" numbered="true" toc="default">
	<section title="Uses">		<name>CALIPSO (Type=0x07)</name>
	<t>This option is used for encoding explicit packet Sensitivity Labels on IPv6 p		<section numbered="true" toc="default">
	ackets. It is intended for use only within Multi-Level Secure (MLS) networking		<name>Uses</name>
	environments that are both trusted and trustworthy.</t>		<t>This option is used for encoding explicit packet Sensitivity Labe
	</section>		ls on IPv6 packets. It is intended for use only within Multi-Level Secure (MLS)
			networking environments that are both trusted and trustworthy.</t>
	<section title="Specification">		</section>
	<t>This option is specified in <xref target="RFC5570"/>.</t>		<section numbered="true" toc="default">
	</section>		<name>Specification</name>
			<t>This option is specified in <xref target="RFC5570" format="defaul
	<section title="Specific Security Implications">		t"/>.</t>
	<t>Presence of this option in a packet does not by itself create any		</section>
			<section numbered="true" toc="default">
			<name>Specific Security Implications</name>
			<t>Presence of this option in a packet does not by itself create any
	specific new threat. Packets with this option ought not normally be		specific new threat. Packets with this option ought not normally be
	seen on the global public Internet.</t>		seen on the global public Internet.</t>
	</section>		</section>
			<section numbered="true" toc="default">
	<section title="Operational and Interoperability Impact if Blocked">		<name>Operational and Interoperability Impact If Blocked</name>
	<t>If packets with this option are discarded or if the option is		<t>If packets with this option are discarded or if the option is
	stripped from the packet during transmission from source to		stripped from the packet during transmission from source to
	destination, then the packet itself is likely to be discarded by the		destination, then the packet itself is likely to be discarded by the
	receiver because it is not properly labeled. In some cases, the		receiver because it is not properly labeled. In some cases, the
	receiver might receive the packet but associate an incorrect		receiver might receive the packet but associate an incorrect
	sensitivity label with the received data from the packet whose CALIPSO		Sensitivity Label with the received data from the packet whose Common
	was stripped by a middle-box (such as a packet-scrubber). Associating		Architecture Label
	an		IPv6 Security Option (CALIPSO)
	incorrect sensitivity label can cause the received information		was stripped by a middlebox (such as a packet scrubber). Associating a
	either to be handled as more sensitive than it really is		n
			incorrect Sensitivity Label can cause the received information
			to be handled either as more sensitive than it really is
	("upgrading") or as less sensitive than it really is		("upgrading") or as less sensitive than it really is
	("downgrading"), either of which is problematic. As noted in <xref tar		("downgrading"), either of which is problematic. As noted in <xref t
	get="RFC5570"/>, IPsec <xref target="RFC4301"/> <xref target="RFC4302"/> <xref t		arget="RFC5570" format="default"/>, IPsec <xref target="RFC4301" format="default
	arget="RFC4303"/> can be employed to protect the CALIPSO option.</t>		"/> <xref target="RFC4302" format="default"/> <xref target="RFC4303" format="def
	</section>		ault"/> can be employed to protect the CALIPSO.</t>
			</section>
	<section title="Advice">		<section numbered="true" toc="default">
	<t>		<name>Advice</name>
	Recommendations for handling the CALIPSO option depend on the deployment environ		<t>
	ment, rather than whether an intermediate system		Recommendations for handling the CALIPSO depend on the deployment environment ra
			ther than on whether an intermediate system
	happens to be deployed as a transit device (e.g., IPv6 transit router).</t>		happens to be deployed as a transit device (e.g., IPv6 transit router).</t>
			<t>Explicit configuration is the only method via which an intermedia
	<t>Explicit configuration is the only method via which an intermediate system		te system
	can know whether that particular intermediate system has been		can know whether that particular intermediate system has been
	deployed within a Multi-Level Secure (MLS) environment. In many cases,		deployed within an MLS environment. In many cases,
	ordinary commercial intermediate systems (e.g., IPv6 routers and firewalls)		ordinary commercial intermediate systems (e.g., IPv6 routers and firewalls)
	are the majority of the deployed intermediate systems inside an MLS		are the majority of the deployed intermediate systems inside an MLS
	network environment. </t>		network environment. </t>
			<t>For intermediate systems that DO NOT implement <xref target="RFC5
	<t>For Intermediate systems that DO NOT implement <xref target="RFC5570"/>, ther		570" format="default"/>, there
	e		should be a configuration option to either (a) drop packets containing
	should be a configuration option to EITHER (a) drop packets containing		the CALIPSO or (b) ignore the presence of the CALIPSO
	the CALIPSO option OR (b) to ignore the presence of the CALIPSO option
	and forward the packets normally. In non-MLS environments, such		and forward the packets normally. In non-MLS environments, such
	intermediate systems should have this configuration option set to (a)		intermediate systems should have this configuration option set to (a)
	above. In MLS environments, such intermediate systems should		above. In MLS environments, such intermediate systems should
	have this option set to (b) above. The default setting for this configuration		have this option set to (b) above. The default setting for this configuration
	option should be set to (a) above, because MLS environments are much		option should be set to (a) above, because MLS environments are much
	less common than non-MLS environments.		less common than non-MLS environments.
	</t>		</t>
			<t>For intermediate systems that DO implement <xref target="RFC5570"
	<t>For Intermediate systems that DO implement <xref target="RFC5570"/>, there sh		format="default"/>, there should
	ould
	be configuration options (a) and (b) from the preceding paragraph and		be configuration options (a) and (b) from the preceding paragraph and
	also a third configuration option (c) to process packets containing		also a third configuration option (c) to process packets containing
	a CALIPSO option as per <xref target="RFC5570"/>. When deployed in non-MLS		a CALIPSO as per <xref target="RFC5570" format="default"/>. When deployed in n on-MLS
	environments, such intermediate systems should have this configuration		environments, such intermediate systems should have this configuration
	option set to (a) above. When deployed in MLS environments, such		option set to (a) above. When deployed in MLS environments, such
	intermediate systems should have this set to (c). The default setting		intermediate systems should have this configuration option set to (c). The def
	for this configuration option MAY be set to (a) above, because MLS		ault setting
			for this configuration option <bcp14>MAY</bcp14> be set to (a) above, because M
			LS
	environments are much less common than non-MLS environments.		environments are much less common than non-MLS environments.
	</t>		</t>
	</section>		</section>
	</section>		</section>
			<section anchor="x08" numbered="true" toc="default">
	<section title="SMF_DPD (Type=0x08)" anchor="x08">		<name>SMF_DPD (Type=0x08)</name>
	<section title="Uses">		<section numbered="true" toc="default">
	<t>This option is employed in the (experimental) Simplified Multicast Forwarding		<name>Uses</name>
	(SMF) for unique packet identification for IPv6 I-DPD, and as a mechanism to gu		<t>This option is employed in the (experimental) Simplified Multicas
	arantee non-collision of hash values for different packets when H-DPD is used.</		t Forwarding (SMF) for unique packet identification for IPv6 Identification-base
	t>		d DPD (I-DPD) and as a mechanism to guarantee non-collision of hash values for d
	</section>		ifferent packets when Hash-based DPD (H-DPD) is used.</t>
			</section>
	<section title="Specification">		<section numbered="true" toc="default">
	<t>This option is specified in <xref target="RFC6621"/>.</t>		<name>Specification</name>
	</section>		<t>This option is specified in <xref target="RFC6621" format="defaul
			t"/>.</t>
	<section title="Specific Security Implications">		</section>
	<t>None. The use of transient numeric identifiers is subject to the security and		<section numbered="true" toc="default">
	privacy considerations discussed in <xref target="I-D.irtf-pearg-numeric-ids-ge		<name>Specific Security Implications</name>
	neration"/>.</t>		<t>None. The use of transient numeric identifiers is subject to the
	</section>		security and privacy considerations discussed in <xref target="I-D.irtf-pearg-nu
			meric-ids-generation" format="default"/>.</t>
	<section title="Operational and Interoperability Impact if Blocked">		</section>
	<t>Dropping packets containing this option within a MANET domain would break SMF		<section numbered="true" toc="default">
	. However, dropping such packets at the border of such domain would have no nega		<name>Operational and Interoperability Impact If Blocked</name>
	tive impact.</t>		<t>Dropping packets containing this option within a Mobile Ad Hoc Ne
	</section>		twork (MANET) domain would break SMF. However, dropping such packets at the bord
			er of such domain would have no negative impact.</t>
	<section title="Advice">		</section>
	<t>Intermediate systems that are not within a MANET domain should discard packet		<section numbered="true" toc="default">
	s that contain this option.</t>		<name>Advice</name>
	</section>		<t>Intermediate systems that are not within a MANET domain should di
	</section>		scard packets that contain this option.</t>
			</section>
	<section title="PDM (Type=0x0F)" anchor="x0F">		</section>
	<section title="Uses">		<section anchor="x0F" numbered="true" toc="default">
	<t>This option is employed to convey sequence numbers and timing information in		<name>PDM (Type=0x0F)</name>
	IPv6 packets as a basis for measurements.</t>		<section numbered="true" toc="default">
	</section>		<name>Uses</name>
			<t>This option is employed to convey sequence numbers and timing inf
	<section title="Specification">		ormation in IPv6 packets as a basis for measurements.</t>
	<t>This option is specified in <xref target="RFC8250"/>.</t>		</section>
	</section>		<section numbered="true" toc="default">
			<name>Specification</name>
	<section title="Specific Security Implications">		<t>This option is specified in <xref target="RFC8250" format="defaul
	<t>Those specified in <xref target="RFC8250"/>. Additionally, since the options		t"/>.</t>
	employs transient numeric identifiers, implementations may be subject to the iss		</section>
	ues discussed in <xref target="I-D.irtf-pearg-numeric-ids-generation"/>.</t>		<section numbered="true" toc="default">
	</section>		<name>Specific Security Implications</name>
			<t>These are discussed in <xref target="RFC8250" format="default"/>.
	<section title="Operational and Interoperability Impact if Blocked">		Additionally, since this option employs transient numeric identifiers, implemen
	<t>Dropping packets containing this option will result in negative interoperaibl		tations may be subject to the issues discussed in <xref target="I-D.irtf-pearg-n
	ity implications for traffic employing this option as a basis for measurements.<		umeric-ids-generation" format="default"/>.</t>
	/t>		</section>
	</section>		<section numbered="true" toc="default">
			<name>Operational and Interoperability Impact If Blocked</name>
	<section title="Advice">		<t>Dropping packets containing this option will result in negative i
	<t>Intermediate systems should not discard packets based on the presence of this		nteroperability implications for traffic employing this option as a basis for me
	option.</t>		asurements.</t>
	</section>		</section>
			<section numbered="true" toc="default">
	</section>		<name>Advice</name>
			<t>Intermediate systems should not discard packets based on the pres
	<section title="RPL Option (Type=0x23)" anchor="x23">		ence of this option.</t>
	<section title="Uses">		</section>
	<t>The RPL Option provides a mechanism to include routing information with each		</section>
	datagram that an RPL router forwards.</t>		<section anchor="x23" numbered="true" toc="default">
	</section>		<name>RPL Option (Type=0x23)</name>
			<section numbered="true" toc="default">
	<section title="Specification">		<name>Uses</name>
	<t>This option is specified in <xref target="RFC9008"/>.</t>		<t>The RPL Option provides a mechanism to include routing informatio
	</section>		n in each datagram that a RPL router forwards.</t>
			</section>
	<section title="Specific Security Implications">		<section numbered="true" toc="default">
	<t>Those described in <xref target="RFC9008"/>.</t>		<name>Specification</name>
	</section>		<t>This option is specified in <xref target="RFC9008" format="defaul
			t"/>.</t>
	<section title="Operational and Interoperability Impact if Blocked">		</section>
	<t>This option can survive outside of an RPL instance. As a result, discarding p		<section numbered="true" toc="default">
	ackets based on the presence of this option would break some use cases for RPL (		<name>Specific Security Implications</name>
	see <xref target="RFC9008"/>).</t>		<t>These are discussed in <xref target="RFC9008" format="default"/>.
	</section>		</t>
			</section>
	<section title="Advice">		<section numbered="true" toc="default">
	<t>Intermediate systems should not discard IPv6 packets based on the presence of		<name>Operational and Interoperability Impact If Blocked</name>
	this option.</t>		<t>This option can survive outside of a RPL instance. As a result, d
	</section>		iscarding packets based on the presence of this option would break some use case
	</section>		s for RPL (see <xref target="RFC9008" format="default"/>).</t>
			</section>
	<section title="Quick-Start (Type=0x26)" anchor="x26">		<section numbered="true" toc="default">
	<section title="Uses">		<name>Advice</name>
	<t>This IP Option is used in the specification of Quick-Start for		<t>Intermediate systems should not discard IPv6 packets based on the
			presence of this option.</t>
			</section>
			</section>
			<section anchor="x26" numbered="true" toc="default">
			<name>Quick-Start (Type=0x26)</name>
			<section numbered="true" toc="default">
			<name>Uses</name>
			<t>This IP option is used in the specification of Quick-Start for
	TCP and IP, which is an experimental mechanism that allows transport		TCP and IP, which is an experimental mechanism that allows transport
	protocols, in cooperation with routers, to determine an allowed		protocols, in cooperation with routers, to determine an allowed
	sending rate at the start and, at times, in the middle of a data		sending rate at the start and, at times, in the middle of a data
	transfer (e.g., after an idle period) <xref target="RFC4782"/>.</t>		transfer (e.g., after an idle period) <xref target="RFC4782" format="d
	</section>		efault"/>.</t>
			</section>
	<section title="Specification">		<section numbered="true" toc="default">
	<t>This option is specified in <xref target="RFC4782"/>, on the "Experimental" t		<name>Specification</name>
	rack.</t>		<t>This option is specified in <xref target="RFC4782" format="defaul
	</section>		t"/> on the "Experimental" track.</t>
			</section>
	<section title="Specific Security Implications">		<section numbered="true" toc="default">
	<t>Section 9.6 of <xref target="RFC4782"/> notes that Quick-Start is		<name>Specific Security Implications</name>
	vulnerable to two kinds of attacks: <list style="symbols">		<t><xref target="RFC4782" sectionFormat="of" section="9.6"/> notes t
	<t>attacks to increase the routers' processing and state load,		hat Quick-Start is
	and,</t>		vulnerable to two kinds of attacks: </t>
			<ul spacing="normal">
	<t>attacks with bogus Quick-Start Requests to temporarily tie up		<li>attacks to increase the routers' processing and state load
			and</li>
			<li>attacks with bogus Quick-Start Requests to temporarily tie up
	available Quick-Start bandwidth, preventing routers from		available Quick-Start bandwidth, preventing routers from
	approving Quick-Start Requests from other connections.</t>		approving Quick-Start Requests from other connections</li>
	</list></t>		</ul>
			<t>We note that if routers in a given environment do not implement a
	<t>We note that if routers in a given environment do not implement and enable th		nd enable the Quick-Start mechanism, only the general security
	e Quick-Start mechanism, only the general security		implications of IP options (discussed in <xref target="ipv6-options-general-impl
	implications of IP options (discussed in <xref target="ipv6-options-general-impl		ications" format="default"/>) would apply.</t>
	ications"/>) would apply.</t>		</section>
			<section numbered="true" toc="default">
	</section>		<name>Operational and Interoperability Impact If Blocked</name>
			<t>If packets with IPv6 Quick Start options are blocked, the host tr
	<section title="Operational and Interoperability Impact if Blocked">		ying to establish a TCP
	<t>The Quick-Start functionality would be disabled, and additional		connection will fall back to not including the Quick Start option --
	delays in TCP's connection establishment (for example) could be introd		this means that the
	uced.		feature will be disabled, and additional delays in connection establi
	(Please see Section 4.7.2 of <xref target="RFC4782"/>.) We note,		shment
			will be introduced (as discussed in <xref target="RFC4782" sectionFor
			mat="of"
			section="4.7.2"/>). We note,
	however, that Quick-Start has been proposed as a mechanism that could		however, that Quick-Start has been proposed as a mechanism that could
	be of use in controlled environments, and not as a mechanism that		be of use in controlled environments and not as a mechanism that
	would be intended or appropriate for ubiquitous deployment in the		would be intended or appropriate for ubiquitous deployment in the
	global Internet <xref target="RFC4782"/>.</t>		global Internet <xref target="RFC4782" format="default"/>.</t>
	</section>		</section>
			<section numbered="true" toc="default">
	<section title="Advice">		<name>Advice</name>
	<t>Intermediate systems should not discard IPv6 packets based on the p		<t>Intermediate systems should not discard IPv6 packets based on the
	resence of this option.</t>		presence of this option.</t>
			</section>
	</section>		</section>
	</section>		<section anchor="x4D" numbered="true" toc="default">
			<name>Deprecated (Type=0x4D)</name>
	<section title="Deprecated (Type=0x4D)" anchor="x4D">		<section numbered="true" toc="default">
	<section title="Uses">		<name>Uses</name>
	<t>No information has been found about this option type.</t>		<t>No information has been found about this option type.</t>
	</section>		</section>
			<section numbered="true" toc="default">
	<section title="Specification">		<name>Specification</name>
	<t>No information has been found about this option type.</t>		<t>No information has been found about this option type.</t>
	</section>		</section>
			<section numbered="true" toc="default">
	<section title="Specific Security Implications">		<name>Specific Security Implications</name>
	<t>No information has been found about this option type, and hence it has been i		<t>No information has been found about this option type; hence, it h
	mpossible to perform the corresponding security assessment.</t>		as been impossible to perform the corresponding security assessment.</t>
	</section>		</section>
			<section numbered="true" toc="default">
	<section title="Operational and Interoperability Impact if Blocked">		<name>Operational and Interoperability Impact If Blocked</name>
	<t>Unknown.</t>		<t>Unknown.</t>
	</section>		</section>
			<section numbered="true" toc="default">
	<section title="Advice">		<name>Advice</name>
	<t>Intermediate systems should discard packets that contain this option.</t>		<t>Intermediate systems should discard packets that contain this opt
	</section>		ion.</t>
	</section>		</section>
			</section>
	<section title="RPL Option (Type=0x63)" anchor="x63">		<section anchor="x63" numbered="true" toc="default">
	<section title="Uses">		<name>RPL Option (Type=0x63)</name>
	<t>The RPL Option provides a mechanism to include routing information with each		<section numbered="true" toc="default">
	datagram that an RPL router forwards.</t>		<name>Uses</name>
	</section>		<t>The RPL Option provides a mechanism to include routing informatio
			n in each datagram that a RPL router forwards.</t>
	<section title="Specification">		</section>
	<t>This option was originally specified in <xref target="RFC6553"/>. It has been		<section numbered="true" toc="default">
	deprecated by <xref target="RFC9008"/>.</t>		<name>Specification</name>
	</section>		<t>This option was originally specified in <xref target="RFC6553" fo
			rmat="default"/>. It has been deprecated by <xref target="RFC9008" format="defau
	<section title="Specific Security Implications">		lt"/>.</t>
	<t>Those described in <xref target="RFC9008"/>.</t>		</section>
	</section>		<section numbered="true" toc="default">
			<name>Specific Security Implications</name>
	<section title="Operational and Interoperability Impact if Blocked">		<t>These are discussed in <xref target="RFC6553" sectionFormat="of"
	<t>This option is meant to be employed within an RPL instance. As a result, disc		section="5"/>.</t>
	arding packets based on the presence of this option outside of an RPL instance w		</section>
	ill not result in interoperability implications.</t>		<section numbered="true" toc="default">
	</section>		<name>Operational and Interoperability Impact If Blocked</name>
			<t>This option is meant to be employed within a RPL instance. As a r
	<section title="Advice">		esult, discarding packets based on the presence of this option outside of a RPL
	<t>Non-RPL routers should discard packets that contain an RPL option.</t>		instance will not result in interoperability implications.</t>
	</section>		</section>
	</section>		<section numbered="true" toc="default">
			<name>Advice</name>
	<section title="MPL Option (Type=0x6D)" anchor="x6D">		<t>Intermediate systems should discard packets that contain a RPL Op
	<section title="Uses">		tion.</t>
	<t>This option is used with the Multicast Protocol for Low power and Lossy Netwo		</section>
	rks (MPL), that provides IPv6 multicast forwarding in		</section>
			<section anchor="x6D" numbered="true" toc="default">
			<name>MPL Option (Type=0x6D)</name>
			<section numbered="true" toc="default">
			<name>Uses</name>
			<t>This option is used with the Multicast Protocol for Low power and
			Lossy Networks (MPL), which provides IPv6 multicast forwarding in
	constrained networks.</t>		constrained networks.</t>
	</section>		</section>
			<section numbered="true" toc="default">
	<section title="Specification">		<name>Specification</name>
	<t>This option is specified in <xref target="RFC7731"/>, and is meant to be incl		<t>This option is specified in <xref target="RFC7731" format="defaul
	uded only in Hop-by-Hop Option headers.</t>		t"/> and is meant to be included only in Hop-by-Hop Options headers.</t>
	</section>		</section>
			<section numbered="true" toc="default">
	<section title="Specific Security Implications">		<name>Specific Security Implications</name>
	<t>Those described in <xref target="RFC7731"/>.</t>		<t>These are discussed in <xref target="RFC7731" format="default"/>.
	</section>		</t>
			</section>
	<section title="Operational and Interoperability Impact if Blocked">		<section numbered="true" toc="default">
	<t>Dropping packets that contain an MPL option within an MPL network would break		<name>Operational and Interoperability Impact If Blocked</name>
	the Multicast Protocol for Low power and Lossy Networks (MPL). However, droppin		<t>Dropping packets that contain an MPL Option within an MPL network
	g such packets at the border of such networks will have no negative impact.</t>		would break the MPL. However, dropping such packets at the border of such netwo
	</section>		rks will have no negative impact.</t>
			</section>
	<section title="Advice">		<section numbered="true" toc="default">
	<t>Intermediate systems should not discard packets based on the presence of this		<name>Advice</name>
	option. However, since this option has been specified for the Hop-by-Hop Option		<t>Intermediate systems should not discard packets based on the pres
	s, such systems should consider the discussion in <xref target="proto0"/>.</t>		ence of this option. However, since this option has been specified for the Hop-b
	</section>		y-Hop Options header, such systems should consider the discussion in <xref targe
	</section>		t="proto0" format="default"/>.</t>
			</section>
	<section title="Endpoint Identification (Type=0x8A)" anchor="x8A">		</section>
	<section title="Uses">		<section anchor="x8A" numbered="true" toc="default">
	<t>The Endpoint Identification option was meant to be used with the Nimrod routi		<name>Endpoint Identification (Type=0x8A)</name>
	ng architecture <xref target="NIMROD-DOC"/>, but has never seen widespread deplo		<section numbered="true" toc="default">
	yment.</t>		<name>Uses</name>
	</section>		<t>The Endpoint Identification option was meant to be used with the
			Nimrod routing architecture <xref target="NIMROD-DOC" format="default"/> but has
	<section title="Specification">		never seen widespread deployment.</t>
	<t>This option is specified in <xref target="NIMROD-DOC"/>.</t>		</section>
	</section>		<section numbered="true" toc="default">
			<name>Specification</name>
	<section title="Specific Security Implications">		<t>This option is specified in <xref target="NIMROD-DOC" format="def
	<t>Undetermined.</t>		ault"/>.</t>
	</section>		</section>
			<section numbered="true" toc="default">
	<section title="Operational and Interoperability Impact if Blocked">		<name>Specific Security Implications</name>
	<t>None.</t>		<t>Undetermined.</t>
	</section>		</section>
			<section numbered="true" toc="default">
	<section title="Advice">		<name>Operational and Interoperability Impact If Blocked</name>
	<t>Intermediate systems should discard packets that contain this option.</t>		<t>None.</t>
	</section>		</section>
	</section>		<section numbered="true" toc="default">
			<name>Advice</name>
	<section title="ILNP Nonce (Type=0x8B)" anchor="x8B">		<t>Intermediate systems should discard packets that contain this opt
	<section title="Uses">		ion.</t>
	<t>This option is employed by Identifier-Locator Network Protocol for IPv6 (ILNP		</section>
	v6) for providing protection against off-path attacks for packets when ILNPv6 is		</section>
	in use, and as a signal during initial network-layer session creation that ILNP		<section anchor="x8B" numbered="true" toc="default">
	v6 is proposed for use with this network-layer session, rather than classic IPv6		<name>ILNP Nonce (Type=0x8B)</name>
	.</t>		<section numbered="true" toc="default">
	</section>		<name>Uses</name>
			<t>This option is employed by the Identifier-Locator Network Protoco
	<section title="Specification">		l for IPv6 (ILNPv6) to provide protection against off-path attacks for packets w
	<t>This option is specified in <xref target="RFC6744"/>.</t>		hen ILNPv6 is in use and as a signal during initial network-layer session creati
	</section>		on that ILNPv6 is proposed for use with this network-layer session, rather than
			classic IPv6.</t>
	<section title="Specific Security Implications">		</section>
	<t>Those described in <xref target="RFC6744"/>.</t>		<section numbered="true" toc="default">
	</section>		<name>Specification</name>
			<t>This option is specified in <xref target="RFC6744" format="defaul
	<section title="Operational and Interoperability Impact if Blocked">		t"/>.</t>
	<t>Discarding packets that contain this option will break INLPv6 deployments.</t		</section>
	>		<section numbered="true" toc="default">
	</section>		<name>Specific Security Implications</name>
			<t>These are discussed in <xref target="RFC6744" format="default"/>.
	<section title="Advice">		</t>
	<t>Intermediate systems should not discard packets based on the presence of this		</section>
	option.</t>		<section numbered="true" toc="default">
	</section>		<name>Operational and Interoperability Impact If Blocked</name>
	</section>		<t>Discarding packets that contain this option will break ILNPv6 dep
			loyments.</t>
	<section title="Line-Identification Option (Type=0x8C)" anchor="x8C">		</section>
	<section title="Uses">		<section numbered="true" toc="default">
	<t>This option is used by an Edge Router to identify the subscriber premises in		<name>Advice</name>
	scenarios where several subscriber premises may be logically connected to the sa		<t>Intermediate systems should not discard packets based on the pres
	me interface of an Edge Router.</t>		ence of this option.</t>
			</section>
	<!--		</section>
	The Line-Identification Option (LIO) is a destination option that can		<section anchor="x8C" numbered="true" toc="default">
	be included in IPv6 datagrams that tunnel Router Solicitation and		<name>Line-Identification Option (Type=0x8C)</name>
	Router Advertisement messages. The use of the Line-ID option in any		<section numbered="true" toc="default">
	other IPv6 datagrams is not defined by this document. Multiple Line-		<name>Uses</name>
	ID destination options MUST NOT be present in the same IPv6 datagram.		<t>This option is used by an Edge Router to identify the subscriber
	The LIO has no alignment requirement.		premises in scenarios where several subscriber premises may be logically connect
	</section>		ed to the same interface of an Edge Router.</t>
	<section title="Specification">
	<t>This option is specified in <xref target="RFC6788"/>.</t>
	</section>
	<section title="Specific Security Implications">
	<t>Those described in <xref target="RFC6788"/>.</t>
	</section>
	<section title="Operational and Interoperability Impact if Blocked">
	<t>Since this option is meant to be employed in Router Solicitation messages, di
	scarding packets based on the presence of this option at intermediate systems wi
	ll result in no interoperability implications.</t>
	</section>
	<section title="Advice">
	<t>Intermediate devices should discard packets that contain this option.</t>
	</section>
	</section>
	<section title="Jumbo Payload (Type=0XC2)" anchor="xC2">
	<section title="Uses">
	<t>The Jumbo payload option provides the means of specifying payloads larger tha
	n 65535 bytes.</t>
	</section>
	<section title="Specification">
	<t>This option is specified in <xref target="RFC2675"/>.</t>
	</section>
	<section title="Specific Security Implications">
	<t>There are no specific issues arising from this option, except for improper va
	lidity checks of the option and associated packet lengths.</t>
	</section>
	<section title="Operational and Interoperability Impact if Blocked">
	<t>Discarding packets based on the presence of this option will cause IPv6 jumbo
	grams to be discarded.</t>
	</section>		</section>
			<section numbered="true" toc="default">
	<section title="Advice">		<name>Specification</name>
	<t>An operator should permit this option only in specific scenarios in which sup		<t>This option is specified in <xref target="RFC6788" format="defaul
	port for IPv6 jumbograms is desired.		t"/>.</t>
			</section>
			<section numbered="true" toc="default">
			<name>Specific Security Implications</name>
			<t>These are discussed in <xref target="RFC6788" format="default"/>.
			</t>
			</section>
			<section numbered="true" toc="default">
			<name>Operational and Interoperability Impact If Blocked</name>
			<t>Since this option is meant to be used when tunneling Neighbor Dis
			covery messages in some broadband network deployment scenarios, discarding packe
			ts based on the presence of this option at intermediate systems will result in n
			o interoperability implications.</t>
			</section>
			<section numbered="true" toc="default">
			<name>Advice</name>
			<t>Intermediate systems should discard packets that contain this opt
			ion.</t>
			</section>
			</section>
			<section anchor="xC2" numbered="true" toc="default">
			<name>Jumbo Payload (Type=0XC2)</name>
			<section numbered="true" toc="default">
			<name>Uses</name>
			<t>The Jumbo Payload option provides the means for supporting payloa
			ds larger than 65535 bytes.</t>
			</section>
			<section numbered="true" toc="default">
			<name>Specification</name>
			<t>This option is specified in <xref target="RFC2675" format="defaul
			t"/>.</t>
			</section>
			<section numbered="true" toc="default">
			<name>Specific Security Implications</name>
			<t>There are no specific issues arising from this option, except for
			improper validity checks of the option and associated packet lengths.</t>
			</section>
			<section numbered="true" toc="default">
			<name>Operational and Interoperability Impact If Blocked</name>
			<t>Discarding packets based on the presence of this option will caus
			e IPv6 jumbograms to be discarded.</t>
			</section>
			<section numbered="true" toc="default">
			<name>Advice</name>
			<t>An operator should permit this option only in specific scenarios
			in which support for IPv6 jumbograms is required.
	</t>		</t>
	</section>		</section>
	</section>		</section>
			<section anchor="xC9" numbered="true" toc="default">
	<section title="Home Address (Type=0xC9)" anchor="xC9">		<name>Home Address (Type=0xC9)</name>
	<section title="Uses">		<section numbered="true" toc="default">
	<t>The Home Address option is used by a Mobile IPv6 node while away from home, t		<name>Uses</name>
	o inform the recipient of the mobile node's home address.</t>		<t>The Home Address option is used by a Mobile IPv6 node while away
	</section>		from home to inform the recipient of the mobile node's home address.</t>
			</section>
	<section title="Specification">		<section numbered="true" toc="default">
	<t>This option is specified in <xref target="RFC6275"/>.</t>		<name>Specification</name>
	</section>		<t>This option is specified in <xref target="RFC6275" format="defaul
			t"/>.</t>
	<section title="Specific Security Implications">		</section>
	<t>No (known) additional security implications than those described in <xref tar		<section numbered="true" toc="default">
	get="RFC6275"/>.</t>		<name>Specific Security Implications</name>
	</section>		<t>There are no (known) additional security implications, other than
			those discussed in <xref target="RFC6275" format="default"/>.</t>
	<section title="Operational and Interoperability Impact if Blocked">		</section>
	<t>Discarding IPv6 packets based on the presence of this option will break Mobil		<section numbered="true" toc="default">
	e IPv6.</t>		<name>Operational and Interoperability Impact If Blocked</name>
	</section>		<t>Discarding IPv6 packets based on the presence of this option will
			break Mobile IPv6.</t>
	<section title="Advice">		</section>
	<t>Intermediate systems should not discard IPv6 packets based on the presence of		<section numbered="true" toc="default">
	this option.</t>		<name>Advice</name>
	</section>		<t>Intermediate systems should not discard IPv6 packets based on the
	</section>		presence of this option.</t>
			</section>
	<section title="IP_DFF (Type=0xEE)" anchor="xEE">		</section>
	<section title="Uses">		<section anchor="xEE" numbered="true" toc="default">
	<t>This option is employed with the (Experimental) Depth-First Forwarding (DFF)		<name>IP_DFF (Type=0xEE)</name>
	in Unreliable Networks.</t>		<section numbered="true" toc="default">
	</section>		<name>Uses</name>
			<t>This option is employed with the (experimental) Depth-First Forwa
	<section title="Specification">		rding (DFF) in unreliable networks.</t>
	<t>This option is specified in <xref target="RFC6971"/>.</t>		</section>
	</section>		<section numbered="true" toc="default">
			<name>Specification</name>
	<section title="Specific Security Implications">		<t>This option is specified in <xref target="RFC6971" format="defaul
	<t>Those specified in <xref target="RFC6971"/>.</t>		t"/>.</t>
	</section>		</section>
			<section numbered="true" toc="default">
	<section title="Operational and Interoperability Impact if Blocked">		<name>Specific Security Implications</name>
	<t>Dropping packets containing this option within a routing domain that is runni		<t>These are specified in <xref target="RFC6971" format="default"/>.
	ng DFF would break DFF. However, dropping such packets at the border of such dom		</t>
	ains will have no security implications.</t>		</section>
	</section>		<section numbered="true" toc="default">
			<name>Operational and Interoperability Impact If Blocked</name>
	<section title="Advice">		<t>Dropping packets containing this option within a routing domain t
	<t>Intermediate systems that do not operate within a routing domain that is runn		hat is running DFF would break DFF. However, dropping such packets at the border
	ing DFF should discard packets containing this option.</t>		of such domains will have no operational or interoperability implications.</t>
	</section>		</section>
	</section>		<section numbered="true" toc="default">
			<name>Advice</name>
	<section title="RFC3692-style Experiment (Types = 0x1E, 0x3E, 0x5E, 0x7E, 0x9E,		<t>Intermediate systems that do not operate within a routing domain
	0xBE, 0xDE, 0xFE)" anchor="x1E">		that is running DFF should discard packets containing this option.</t>
	<section title="Uses">		</section>
	<t>These options can be employed for performing RFC3692-style experime		</section>
	nts. It is only appropriate to use these values in		<section anchor="x1E" numbered="true" toc="default">
			<name>RFC3692-Style Experiment (Types = 0x1E, 0x3E, 0x5E, 0x7E, 0x9E,
			0xBE, 0xDE, 0xFE)</name>
			<section numbered="true" toc="default">
			<name>Uses</name>
			<t>These options can be employed for performing RFC3692-style experi
			ments. It is only appropriate to use these values in
	explicitly configured experiments; they must not be shipped as default s in implementations.</t>		explicitly configured experiments; they must not be shipped as default s in implementations.</t>
	</section>		</section>
			<section numbered="true" toc="default">
	<section title="Specification">		<name>Specification</name>
	<t>Specified in RFC 4727 <xref target="RFC4727"/> in the context of		<t>These options are specified in <xref target="RFC4727" format="def
			ault"/> in the context of
	RFC3692-style experiments.</t>		RFC3692-style experiments.</t>
	</section>		</section>
			<section numbered="true" toc="default">
	<section title="Specific Security Implications">		<name>Specific Security Implications</name>
	<t>The specific security implications will depend on the specific use of these		<t>The specific security implications will depend on the specific us
	options.</t>		e of these options.</t>
	</section>		</section>
			<section numbered="true" toc="default">
	<section title="Operational and Interoperability Impact if Blocked">		<name>Operational and Interoperability Impact If Blocked</name>
	<t>For obvious reasons, discarding packets that contain these options limits the		<t>For obvious reasons, discarding packets that contain these option
	ability to perform legitimate experiments across IPv6 routers.</t>		s limits the ability to perform legitimate experiments across IPv6 routers.</t>
	</section>		</section>
			<section numbered="true" toc="default">
	<section title="Advice">		<name>Advice</name>
	<t>Operators should determine according to their own circumstances whether to di		<t>Operators should determine, according to their own circumstances,
	scard packets containing these IPv6 options.</t>		whether to discard packets containing these IPv6 options.</t>
	<!--
	<t>Intermediate systems should discard packets that contain these options. Only
	in specific environments where RFC3692-style experiments are meant to be perform
	ed should these options be permitted.</t> -->
	</section>
	</section>
	</section>		</section>
			</section>
	<section title="Advice on the handling of Packets with Unknown IPv6 Options">		</section>
			<section numbered="true" toc="default">
	<t>We refer to IPv6 options that have not been assigned an IPv6 option type in t		<name>Advice on the Handling of Packets with Unknown IPv6 Options</name>
	he corresponding registry (<xref target="IANA-IPV6-PARAM"/>) as "unknown IPv6 op		<t>We refer to IPv6 options that have not been assigned an IPv6 Option T
	tions".</t>		ype in the corresponding registry, which is <xref target="IANA-IPV6-PARAM" forma
			t="default"/>, as "unknown IPv6 options".</t>
	<section title="Uses">		<section numbered="true" toc="default">
			<name>Uses</name>
	<t>New IPv6 options may be specified as part of future protocol work.< /t>		<t>New IPv6 options may be specified as part of future protocol work.< /t>
	</section>		</section>
			<section numbered="true" toc="default">
	<section title="Specification">		<name>Specification</name>
	<t>The processing of unknown IPv6 options is specified in <xref target="RFC8200"		<t>The processing of unknown IPv6 options is specified in <xref target
	/>.</t>		="RFC8200" format="default"/>.</t>
	</section>		</section>
			<section numbered="true" toc="default">
	<section title="Specific Security Implications">		<name>Specific Security Implications</name>
	<t>For obvious reasons, it is impossible to determine specific security implica		<t>For obvious reasons, it is impossible to determine specific securit
	tions of unknown IPv6 options.</t>		y implications of unknown IPv6 options.</t>
	</section>		</section>
			<section numbered="true" toc="default">
	<section title="Operational and Interoperability Impact if Blocked">		<name>Operational and Interoperability Impact If Blocked</name>
	<t>Discarding unknown IPv6 options may slow down the deployment of new IPv6 opti		<t>Discarding unknown IPv6 options may slow down the deployment of new
	ons. As noted in <xref target="draft-gont-6man-ipv6-opt-transmit"/>, the corresp		IPv6 options. As noted in <xref target="I-D.gont-6man-ipv6-opt-transmit" format
	onding IANA registry (<xref target="IANA-IPV6-PARAM"/> should be monitored such		="default"/>, the corresponding IANA registry, which is <xref target="IANA-IPV6-
	that IPv6 option filtering rules are updated as new IPv6 options are standardize		PARAM" format="default"/>, should be monitored such that IPv6 option filtering r
	d.</t>		ules are updated as new IPv6 options are standardized.</t>
	</section>		</section>
			<section numbered="true" toc="default">
	<section title="Advice">		<name>Advice</name>
			<t>Operators should determine, according to their own circumstances, w
	<t>Operators should determine according to their own circumstances whether to di		hether to discard packets containing unknown IPv6 options.</t>
	scard packets containing unknown IPv6 options.</t>		</section>
			</section>
	</section>		</section>
	</section>		<section anchor="IANA" numbered="true" toc="default">
			<name>IANA Considerations</name>
	</section>		<t>This document has no IANA actions.</t>
			</section>
	<section anchor="IANA" title="IANA Considerations">		<section anchor="Privacy" numbered="true" toc="default">
	<t>This document has no actions for IANA.</t>		<name>Privacy Considerations</name>
	</section>		<t>
	<section title="Privacy Considerations" anchor="Privacy" >
	<t>
	There are no privacy considerations associated with this document.		There are no privacy considerations associated with this document.
	</t>		</t>
	</section>		</section>
			<section anchor="Security" numbered="true" toc="default">
	<section title="Security Considerations" anchor="Security" >		<name>Security Considerations</name>
	<t>		<t>
	This document provides advice on the filtering of IPv6 packets that contain IPv6		This document provides advice on the filtering of IPv6 packets that contain IPv6
	EHs (and possibly IPv6 options) at IPv6 transit routers. It is meant to improve		EHs (and possibly IPv6 options) at IPv6 transit routers. It is meant to improve
	the current situation of widespread dropping of such IPv6 packets in those case		the current situation of widespread dropping of such IPv6 packets in those case
	s where the drops result from improper configuration defaults, or inappropriate		s where the drops result from improper configuration defaults or inappropriate a
	advice in this area.		dvice in this area.
	</t>		</t>
	<t>		<t>
	As discussed in Section <xref target="ipv6-ehs-rationale"/> of this document,		As discussed in <xref target="ipv6-ehs-rationale" format="default"/>, one of
	one of the		the
	underlying principles for the advice provided in this document is		underlying principles for the advice provided in this document is
	that IPv6 packets with specific EHs or options which may represent an		that IPv6 packets with specific EHs or options that may represent an
	attack vector for infrastructure devices should be dropped. While		attack vector for infrastructure devices should be dropped. While
	this policy helps mitigate some specific attack vectors, the		this policy helps mitigate some specific attack vectors, the
	recommendations in this document will not help to mitigate		recommendations in this document will not help to mitigate
	vulnerabilities based on implementation errors <xref target="RFC9098"/>.		vulnerabilities based on implementation errors <xref target="RFC9098" format= "default"/>.
	</t>		</t>
			<t>We also note that depending on the router architecture, attempts to fil
			ter packets based on the presence of IPv6 EHs or options might itself represent
			an attack vector to network infrastructure devices <xref target="RFC9098" format
			="default"/>.</t>
			</section>
	<t>We also note that depending on the router architecture, attempts to filter pa		</middle>
	ckets ased on the presence of IPv6 EHs or options might itself represent an atta		<back>
	ck vector to network infrastructure devices <xref target="RFC9098"/>.</t>		<displayreference target="I-D.irtf-pearg-numeric-ids-generation" to="NUMERIC-IDS
	</section>		"/>
			<displayreference target="I-D.vyncke-v6ops-james" to="JAMES"/>
	<section title="Acknowledgements">		<displayreference target="I-D.gont-6man-ipv6-opt-transmit" to="IPv6-OPTIONS"/>
	<t>The authors would like to thank Ron Bonica for his work on earlier versions o		<references>
	f this document.</t>		<name>References</name>
	<t>The authors of this document would like to thank (in alphabetical order) Mika		<references>
	el Abrahamsson, Brian Carpenter, Tim Chown, Roman Danyliw, Darren Dukes, Lars Eg		<name>Normative References</name>
	gert, David Farmer, Mike Heard, Bob Hinden, Christian Huitema, Benjamin Kaduk, E		<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
	rik Kline, Murray Kucherawy, Jen Linkova, Carlos Pignataro, Alvaro Retana, Maria		FC.1034.xml"/>
	Ines Robles, Zaheduzzaman Sarker, Donald Smith, Pascal Thubert, Ole Troan, Gunt		<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
	er Van De Velde, Eric Vyncke, and Robert Wilton, for providing valuable comments		FC.5570.xml"/>
	on earlier versions of this document.</t>		<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
	<t>This document borrows some text and analysis from <xref target="RFC7126"/>, a		FC.2119.xml"/>
	uthored by Fernando Gont, Randall Atkinson, and Carlos Pignataro.</t>		<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
			FC.8174.xml"/>
	<t>The authors would like to thank Warren Kumari and Eric Vyncke for their guida		<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
	nce during the publication process of this document.</t>		FC.2205.xml"/>
			<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
	<t>Fernando would also like to thank Brian Carpenter and Ran Atkinson who, over		FC.2675.xml"/>
	the years, have answered many questions and provided valuable comments that have		<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
	benefited his protocol-related work (including the present document).</t>		FC.4301.xml"/>
	</section>		<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
			FC.4302.xml"/>
	</middle>		<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
			FC.4303.xml"/>
	<back>		<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
	<references title="Normative References">		FC.6275.xml"/>
	<?rfc include="reference.RFC.1034" ?>		<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
	<?rfc include="reference.RFC.5570" ?>		FC.7401.xml"/>
	<?rfc include="reference.RFC.2119" ?>		<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
	<?rfc include="reference.RFC.8174" ?>		FC.5533.xml"/>
			<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
	<?rfc include="reference.RFC.2205" ?>		FC.3692.xml"/>
			<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
	<?rfc include="reference.RFC.2675" ?>		FC.4727.xml"/>
	<?rfc include="reference.RFC.4301" ?>		<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
	<?rfc include="reference.RFC.4302" ?>		FC.2710.xml"/>
	<?rfc include="reference.RFC.4303" ?>		<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
			FC.3810.xml"/>
	<?rfc include="reference.RFC.6275" ?>		<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
	<?rfc include="reference.RFC.7401" ?>		FC.4286.xml"/>
	<?rfc include="reference.RFC.5533" ?>		<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
	<?rfc include="reference.RFC.3692" ?>		FC.5971.xml"/>
	<?rfc include="reference.RFC.4727" ?>		<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
	<?rfc include="reference.RFC.2710" ?>		FC.2711.xml"/>
	<?rfc include="reference.RFC.3810" ?>		<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
	<?rfc include="reference.RFC.4286" ?>		FC.5095.xml"/>
	<?rfc include="reference.RFC.5971" ?>		<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
	<?rfc include="reference.RFC.2711" ?>		FC.6550.xml"/>
	<?rfc include="reference.RFC.5095" ?>		<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
	<?rfc include="reference.RFC.6550" ?>		FC.6621.xml"/>
	<?rfc include="reference.RFC.6621" ?>		<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
	<?rfc include="reference.RFC.6971" ?>		FC.6971.xml"/>
	<?rfc include="reference.RFC.7045" ?>		<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
	<?rfc include="reference.RFC.7112" ?>		FC.7045.xml"/>
	<?rfc include="reference.RFC.4782" ?>		<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
	<?rfc include="reference.RFC.6788" ?>		FC.7112.xml"/>
	<?rfc include="reference.RFC.6740" ?>		<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
	<?rfc include="reference.RFC.6744" ?>		FC.4782.xml"/>
	<?rfc include="reference.RFC.2473" ?>		<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
	<?rfc include="reference.RFC.6553" ?>		FC.6788.xml"/>
	<?rfc include="reference.RFC.6554" ?>		<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
	<?rfc include="reference.RFC.6398" ?>		FC.6740.xml"/>
	<?rfc include="reference.RFC.8754" ?>		<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
			FC.6744.xml"/>
	<?rfc include="reference.RFC.9008" ?>		<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
			FC.2473.xml"/>
	<?rfc include="reference.RFC.7731" ?>		<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
	<?rfc include="reference.RFC.8200" ?>		FC.6553.xml"/>
	<?rfc include="reference.RFC.8250" ?>		<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
	<?rfc include="reference.RFC.8900" ?>		FC.6554.xml"/>
	</references>		<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
			FC.6398.xml"/>
	<references title="Informative References">		<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
	<?rfc include="reference.RFC.2460" ?>		FC.8754.xml"/>
	<?rfc include="reference.RFC.3871" ?>		<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
	<?rfc include="reference.RFC.6192" ?>		FC.9008.xml"/>
	<?rfc include="reference.RFC.7126" ?>		<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
	<?rfc include="reference.RFC.7739" ?>		FC.7731.xml"/>
			<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
	<?rfc include="reference.I-D.irtf-pearg-numeric-ids-generation" ?>		FC.8200.xml"/>
			<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
	<?rfc include="reference.RFC.9098" ?>		FC.8250.xml"/>
			<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
	<?rfc include="reference.RFC.7872" ?>		FC.8900.xml"/>
			</references>
	<?rfc include="reference.I-D.vyncke-v6ops-james" ?>		<references>
			<name>Informative References</name>
	<reference anchor="Huston-2022" target="https://iepg.org/2022-03-20-ietf11		<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
	3/huston-v6frag.pdf">		FC.2460.xml"/>
	<front>		<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
	<title>IPv6 Fragmentation and EH Behaviours</title>		FC.3871.xml"/>
			<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
	<author fullname="Geoff Huston" initials="G." surname="Huston">		FC.6192.xml"/>
	<organization abbrev="APNIC"/>		<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
	<address>		FC.7126.xml"/>
	<email>gih@apnic.net</email>		<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
	<uri>https://www.apnic.net</uri>		FC.7739.xml"/>
	</address>		<xi:include href="https://datatracker.ietf.org/doc/bibxml3/reference.I-D
	</author>		.irtf-pearg-numeric-ids-generation.xml"/>
			<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
	<author fullname="Joao Damas" initials="J." surname="Damas">		FC.9098.xml"/>
	<organization abbrev="APNIC"/>		<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
	</author>		FC.7872.xml"/>
			<xi:include href="https://datatracker.ietf.org/doc/bibxml3/reference.I-D.vyncke
	<date month="March" year="2022"/>		-v6ops-james.xml"/>
	</front>
	<seriesInfo name=""
	value="IEPG Meeting - March 2022 @ IETF 113"/>
	</reference>
	<!--
	<reference anchor="Vyncke-2022" target="https://iepg.org/2022-03-20-ietf11
	3/james-IEPG.pdf">
	<front>
	<title>Just Another Measurement of Extension Header Survivability (JAM
	ES)</title>
	<author fullname="Eric Vyncke" initials="E." surname="Vyncke">
	</author>
	<author fullname="Raphael Leas" initials="R." surname="Leas">
	<organization/>
	</author>
	<author fullname="Justin Iurman" initials="J." surname="Iurman">
	<organization/>
	</author>
	<date month="March" year="2022"/>
	</front>
	<seriesInfo name=""
	value="IEPG Meeting - March 2022 @ IETF 113"/>
	</reference>
	<reference anchor="draft-ietf-nimrod-eid">
	<front>
	<title>Endpoint Identifier Destination Option</title>
	<author fullname="Charles Lynn" initials="C.L." surname="Lynn">
	<organization>BBN Systems and Technologies</organization>
	</author>
	<date month="November" year="1995"/>
	</front>
	<seriesInfo name=""
	value="IETF Internet Draft, draft-ietf-nimrod-eid-00.txt"/>
	</reference>
	<reference anchor="NIMROD-DOC">
	<front>
	<title>http://ana-3.lcs.mit.edu/~jnc/nimrod/</title>
	<author initials="" surname="Nimrod Documentation Page" f
	ullname="Nimrod Documentation Page">
	<organization></organization>
	</author>
	<date year=""/>
	</front>
	</reference>
	<reference anchor="Biondi2007" target="http://www.secdev.org/conf/IPv6_RH_
	security-csw07.pdf">
	<front>
	<title>IPv6 Routing Header Security</title>
	<author fullname="P. Biondi" initials="P." surname="Biondi">
	<organization/>
	</author>
	<author fullname="A. Ebalard" initials="A." surname="Ebalard">
	<organization/>
	</author>
	<date year="2007"/>
	</front>
	<seriesInfo name="CanSecWest 2007"
	value="Security Conference"/>
	</reference>
	<reference anchor="IANA-PROTOCOLS"
	target="https://www.iana.org/assignments/protocol-numbers/proto
	col-numbers.xhtml">
	<front>
	<title>Protocol Numbers</title>
	<author fullname="">		<reference anchor="Huston-2022" target="https://iepg.org/2022-03-20-ietf
	<organization>Internet Assigned Numbers Authority</organization>		113/huston-v6frag.pdf">
	</author>		<front>
			<title>IPv6 Fragmentation and EH Behaviours</title>
			<author fullname="Geoff Huston" initials="G." surname="Huston">
			<organization abbrev="APNIC"/>
			<address>
			<email>gih@apnic.net</email>
			<uri>https://www.apnic.net</uri>
			</address>
			</author>
			<author fullname="Joao Damas" initials="J." surname="Damas">
			<organization abbrev="APNIC"/>
			</author>
			<date month="March" year="2022"/>
			</front>
			<refcontent>IEPG Meeting at IETF 113"</refcontent>
			</reference>
	<date year="2014"/>		<reference anchor="NIMROD-EID">
	</front>		<front>
			<title>Endpoint Identifier Destination Option</title>
			<author initials="C." surname="Lynn" fullname="Dr. Charles W. Lynn Jr.">
			</author>
			<date month="March" day="2" year="1996" />
			</front>
			<seriesInfo name="Internet-Draft" value="draft-ietf-nimrod-eid-00" />
			</reference>
	<format target="https://www.iana.org/assignments/protocol-numbers/protoc		<reference anchor="NIMROD-DOC" target="http://ana-3.lcs.mit.edu/~jnc/nim
	ol-numbers.txt"		rod">
	type="TXT"/>		<front>
	</reference>		<title>Nimrod Documentation</title>
			<author/>
			</front>
			</reference>
	<reference anchor="IANA-IPV6-PARAM"		<reference anchor="Biondi-2007" target="http://www.secdev.org/conf/IPv6_
	target="https://www.iana.org/assignments/ipv6-parameters/ipv6-p		RH_security-csw07.pdf">
	arameters.xhtml">		<front>
	<front>		<title>IPv6 Routing Header Security</title>
	<title>Internet Protocol Version 6 (IPv6) Parameters</title>		<author fullname="P. Biondi" initials="P." surname="Biondi">
			<organization/>
			</author>
			<author fullname="A. Ebalard" initials="A." surname="Ebalard">
			<organization/>
			</author>
			<date month="April" year="2007"/>
			</front>
			<refcontent>CanSecWest Security Conference</refcontent>
			</reference>
	<author fullname="">		<reference anchor="IANA-PROTOCOLS" target="https://www.iana.org/assignme
	<organization>Internet Assigned Numbers Authority</organization>		nts/protocol-numbers">
	</author>		<front>
			<title>Protocol Numbers</title>
			<author>
			<organization>IANA</organization>
			</author>
			</front>
			</reference>
	<date month="December" year="2013"/>		<reference anchor="IANA-IPV6-PARAM" target="https://www.iana.org/assignm
	</front>		ents/ipv6-parameters">
	</reference>		<front>
			<title>Internet Protocol Version 6 (IPv6) Parameters</title>
			<author>
			<organization>IANA</organization>
			</author>
			</front>
			</reference>
	<reference anchor="FW-Benchmark" target="https://www.ipv6hackers.org/files/m		<reference anchor="FW-Benchmark" target="https://www.ipv6hackers.org/fil
	eetings/ipv6-hackers-1/zack-ipv6hackers1-firewall-security-assessment-and-benchm		es/meetings/ipv6-hackers-1/zack-ipv6hackers1-firewall-security-assessment-and-be
	arking.pdf">		nchmarking.pdf">
	<front>		<front>
	<title abbrev="Firewall Benchmarking">Firewall Security Assessment and Benchma		<title abbrev="Firewall Benchmarking">Firewall Security Assessment a
	rking IPv6 Firewall Load Tests</title>		nd Benchmarking IPv6 Firewall Load Tests</title>
	<author initials="E." surname="Zack" fullname="Eldad Zack">		<author initials="E." surname="Zack" fullname="Eldad Zack">
	</author>		</author>
	<date year=""/>		<date month="June" year="2013"/>
	</front>		</front>
	<seriesInfo name="" value="IPv6 Hackers Meeting #1, Berlin, Germa		<refcontent>IPv6 Hackers Meeting #1, Berlin, Germany</refcontent>
	ny. June 30, 2013"/>
	<!-- July 27 - August 1 -->
	</reference>		</reference>
	<reference anchor="Cisco-EH" target="https://www.cisco.com/en/US/technologie		<reference anchor="Cisco-EH" target="https://www.cisco.com/en/US/technol
	s/tk648/tk872/technologies_white_paper0900aecd8054d37d.pdf">		ogies/tk648/tk872/technologies_white_paper0900aecd8054d37d.pdf">
	<front>		<front>
	<title abbrev="Cisco IPv6 EH">IPv6 Extension Headers Review and Considerations		<title abbrev="Cisco IPv6 EH">IPv6 Extension Headers Review and Cons
	</title>		iderations</title>
	<author initials="" surname="Cisco Systems" fullname="Cisco Systems">		<author initials="" surname="" fullname="">
			<organization>Cisco Systems</organization>
	</author>		</author>
	<date year=""/>		<date month="October" year="2006"/>
	</front>		</front>
	<seriesInfo name="" value="Whitepaper. October 2006"/>		<refcontent>Whitepaper</refcontent>
	<!-- July 27 - August 1 -->		</reference>
	</reference>		<xi:include href="https://datatracker.ietf.org/doc/bibxml3/reference.I-D.gont-6m
			an-ipv6-opt-transmit.xml"/>
	<reference anchor="draft-gont-6man-ipv6-opt-transmit">		</references>
	<front>
	<title>Transmission and Processing of IPv6 Options</title>
	<author fullname="Fernando Gont" initials="F." surname="Gont">
	<organization>SI6 Networks / UTN-FRH</organization>
	</author>
	<author fullname="Will Liu" initials="W." surname="Liu">
	<organization></organization>
	</author>
	<author fullname="Ron Bonica" initials="R." surname="Bonica">
	<organization></organization>
	</author>
	<date month="August" year="2014"/>
	</front>
	<seriesInfo name=""
	value="IETF Internet Draft, work in progress"/>
	</reference>
	</references>		</references>
			<section numbered="false" toc="default">
			<name>Acknowledgements</name>
	</back>		<t>The authors would like to thank <contact fullname="Ron Bonica"/> for hi
			s work on earlier draft versions of this document.</t>
			<t>The authors of this document would like to thank (in alphabetical order
			) <contact fullname="Mikael Abrahamsson"/>, <contact fullname="Brian Carpenter"/
			>, <contact fullname="Tim Chown"/>, <contact fullname="Roman Danyliw"/>, <contac
			t fullname="Darren Dukes"/>, <contact fullname="Lars Eggert"/>, <contact fullnam
			e="David Farmer"/>, <contact fullname="Mike Heard"/>, <contact fullname="Bob Hin
			den"/>, <contact fullname="Christian Huitema"/>, <contact fullname="Benjamin Kad
			uk"/>, <contact fullname="Erik Kline"/>, <contact fullname="Murray Kucherawy"/>,
			<contact fullname="Jen Linkova"/>, <contact fullname="Carlos Pignataro"/>, <con
			tact fullname="Alvaro Retana"/>, <contact fullname="Maria Ines Robles"/>, <conta
			ct fullname="Zaheduzzaman Sarker"/>, <contact fullname="Donald Smith"/>, <contac
			t fullname="Pascal Thubert"/>, <contact fullname="Ole Troan"/>, <contact fullnam
			e="Gunter Van de Velde"/>, <contact fullname="Éric Vyncke"/>, and <contact fulln
			ame="Robert Wilton"/> for providing valuable comments on earlier draft versions
			of this document.</t>
			<t>This document borrows some text and analysis from <xref target="RFC7126
			" format="default"/>, which is authored by <contact fullname="Fernando Gont"/>,
			<contact fullname="Randall Atkinson"/>, and <contact fullname="Carlos Pignataro"
			/>.</t>
			<t>The authors would like to thank <contact fullname="Warren Kumari"/> and
			<contact fullname="Éric Vyncke"/> for their guidance during the publication pro
			cess for this document.</t>
			<t>Fernando would also like to thank <contact fullname="Brian Carpenter"/>
			and <contact fullname="Ran Atkinson"/> who, over the years, have answered many
			questions and provided valuable comments that have benefited his protocol-relate
			d work (including the present document).</t>
			</section>
			</back>
	</rfc>		</rfc>
End of changes. 85 change blocks.
	1695 lines changed or deleted		1836 lines changed or added
This html diff was produced by rfcdiff 1.48.