Diff: rfc9288xml2.original.xml

	rfc9288xml2.original.xml	rfc9288.xml

	<?xml version="1.0" encoding="UTF-8"?>	<?xml version='1.0' encoding='utf-8'?>
	<!DOCTYPE rfc SYSTEM "rfc2629.dtd">	<rfc xmlns:xi="http://www.w3.org/2001/XInclude" version="3" category="info" cons
	<?xml-stylesheet type='text/xsl' href='rfc2629.xslt' ?>	ensus="true" docName="draft-ietf-opsec-ipv6-eh-filtering-10" indexInclude="true"
	<!-- try to enforce the ID-nits conventions and DTD validity -->	ipr="trust200902" number="9288" prepTime="2022-08-18T16:08:19" scripts="Common,
	<?rfc strict="no" ?> <!-- items used when reviewing the document -->	Latin" sortRefs="true" submissionType="IETF" symRefs="true" tocDepth="2" tocIncl
	<?rfc comments="no" ?> <!-- controls display of <cref> elements -->	ude="true" xml:lang="en">
	<?rfc inline="no" ?> <!-- when no, put comments at end in comments section,	<link href="https://datatracker.ietf.org/doc/draft-ietf-opsec-ipv6-eh-filterin
	otherwise, put inline -->	g-10" rel="prev"/>
	<?rfc editing="no" ?> <!-- when yes, insert editing marks -->	<link href="https://dx.doi.org/10.17487/rfc9288" rel="alternate"/>
		<link href="urn:issn:2070-1721" rel="alternate"/>
	<!-- create table of contents (set it options).	<front>
	Note the table of contents may be omitted	<title abbrev="Filtering of IPv6 Packets with EHs">Recommendations on the Fi
	for very short documents -->	ltering of IPv6 Packets Containing IPv6 Extension Headers at Transit Routers</ti
		tle>
	<?rfc toc="yes"?><?rfc tocompact="yes"?>	<seriesInfo name="RFC" value="9288" stream="IETF"/>
	<?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 -->

	<author fullname="Fernando Gont" initials="F." surname="Gont">	<author fullname="Fernando Gont" initials="F." surname="Gont">

		<organization abbrev="SI6 Networks" showOnFrontPage="true">SI6 Networks</o
	<organization abbrev="EdgeUno">EdgeUno</organization>	rganization>
	<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 showOnFrontPage="true">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="08" 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>

		<keyword>Denial of Service</keyword>
	<abstract>	<keyword>Distributed Denial of Service</keyword>
	<t>	<keyword>DoS</keyword>
		<keyword>DDoS</keyword>
		<keyword>ACL</keyword>
		<keyword>filtering policy</keyword>
		<abstract pn="section-abstract">
		<t indent="0" pn="section-abstract-1">
	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>
		<boilerplate>
	</front>	<section anchor="status-of-memo" numbered="false" removeInRFC="false" toc=
		"exclude" pn="section-boilerplate.1">
	<middle>	<name slugifiedName="name-status-of-this-memo">Status of This Memo</name
		>
	<section title="Introduction" anchor="intro">	<t indent="0" pn="section-boilerplate.1-1">
	<t>IPv6 Extension Headers (EHs) allow for the extension of the IPv6	This document is not an Internet Standards Track specification; it i
	protocol, and provide support for core functionality such as IPv6	s
	fragmentation. However, common implementation limitations suggest that EHs p	published for informational purposes.
	resent a challenge for IPv6 packet routing equipment, particularly when the IPv6	</t>
	header chain needs to be processed for e.g. enforcing ACLs or implementing othe	<t indent="0" pn="section-boilerplate.1-2">
	r functions <xref target="RFC9098"/>.	This document is a product of the Internet Engineering Task Force
		(IETF). It represents the consensus of the IETF community. It has
		received public review and has been approved for publication by the
		Internet Engineering Steering Group (IESG). Not all documents
		approved by the IESG are candidates for any level of Internet
		Standard; see Section 2 of RFC 7841.
		</t>
		<t indent="0" pn="section-boilerplate.1-3">
		Information about the current status of this document, any
		errata, and how to provide feedback on it may be obtained at
		<eref target="https://www.rfc-editor.org/info/rfc9288" brackets="non
		e"/>.
		</t>
		</section>
		<section anchor="copyright" numbered="false" removeInRFC="false" toc="excl
		ude" pn="section-boilerplate.2">
		<name slugifiedName="name-copyright-notice">Copyright Notice</name>
		<t indent="0" pn="section-boilerplate.2-1">
		Copyright (c) 2022 IETF Trust and the persons identified as the
		document authors. All rights reserved.
		</t>
		<t indent="0" pn="section-boilerplate.2-2">
		This document is subject to BCP 78 and the IETF Trust's Legal
		Provisions Relating to IETF Documents
		(<eref target="https://trustee.ietf.org/license-info" brackets="none
		"/>) in effect on the date of
		publication of this document. Please review these documents
		carefully, as they describe your rights and restrictions with
		respect to this document. Code Components extracted from this
		document must include Revised BSD License text as described in
		Section 4.e of the Trust Legal Provisions and are provided without
		warranty as described in the Revised BSD License.
		</t>
		</section>
		</boilerplate>
		<toc>
		<section anchor="toc" numbered="false" removeInRFC="false" toc="exclude" p
		n="section-toc.1">
		<name slugifiedName="name-table-of-contents">Table of Contents</name>
		<ul bare="true" empty="true" indent="2" spacing="compact" pn="section-to
		c.1-1">
		<li pn="section-toc.1-1.1">
		<t indent="0" keepWithNext="true" pn="section-toc.1-1.1.1"><xref der
		ivedContent="1" format="counter" sectionFormat="of" target="section-1"/>. <xref
		derivedContent="" format="title" sectionFormat="of" target="name-introduction">
		Introduction</xref></t>
		</li>
		<li pn="section-toc.1-1.2">
		<t indent="0" pn="section-toc.1-1.2.1"><xref derivedContent="2" form
		at="counter" sectionFormat="of" target="section-2"/>. <xref derivedContent="" f
		ormat="title" sectionFormat="of" target="name-terminology-and-assumptions">Termi
		nology and Assumptions Employed in This Document</xref></t>
		<ul bare="true" empty="true" indent="2" spacing="compact" pn="sectio
		n-toc.1-1.2.2">
		<li pn="section-toc.1-1.2.2.1">
		<t indent="0" keepWithNext="true" pn="section-toc.1-1.2.2.1.1"><
		xref derivedContent="2.1" format="counter" sectionFormat="of" target="section-2.
		1"/>. <xref derivedContent="" format="title" sectionFormat="of" target="name-te
		rminology">Terminology</xref></t>
		</li>
		<li pn="section-toc.1-1.2.2.2">
		<t indent="0" keepWithNext="true" pn="section-toc.1-1.2.2.2.1"><
		xref derivedContent="2.2" format="counter" sectionFormat="of" target="section-2.
		2"/>. <xref derivedContent="" format="title" sectionFormat="of" target="name-ap
		plicability-statement">Applicability Statement</xref></t>
		</li>
		<li pn="section-toc.1-1.2.2.3">
		<t indent="0" pn="section-toc.1-1.2.2.3.1"><xref derivedContent=
		"2.3" format="counter" sectionFormat="of" target="section-2.3"/>. <xref derived
		Content="" format="title" sectionFormat="of" target="name-router-default-behavio
		r-and">Router Default Behavior and Features</xref></t>
		</li>
		</ul>
		</li>
		<li pn="section-toc.1-1.3">
		<t indent="0" pn="section-toc.1-1.3.1"><xref derivedContent="3" form
		at="counter" sectionFormat="of" target="section-3"/>. <xref derivedContent="" f
		ormat="title" sectionFormat="of" target="name-ipv6-extension-headers">IPv6 Exten
		sion Headers</xref></t>
		<ul bare="true" empty="true" indent="2" spacing="compact" pn="sectio
		n-toc.1-1.3.2">
		<li pn="section-toc.1-1.3.2.1">
		<t indent="0" pn="section-toc.1-1.3.2.1.1"><xref derivedContent=
		"3.1" format="counter" sectionFormat="of" target="section-3.1"/>. <xref derived
		Content="" format="title" sectionFormat="of" target="name-general-discussion">Ge
		neral Discussion</xref></t>
		</li>
		<li pn="section-toc.1-1.3.2.2">
		<t indent="0" pn="section-toc.1-1.3.2.2.1"><xref derivedContent=
		"3.2" format="counter" sectionFormat="of" target="section-3.2"/>. <xref derived
		Content="" format="title" sectionFormat="of" target="name-general-security-impli
		catio">General Security Implications</xref></t>
		</li>
		<li pn="section-toc.1-1.3.2.3">
		<t indent="0" pn="section-toc.1-1.3.2.3.1"><xref derivedContent=
		"3.3" format="counter" sectionFormat="of" target="section-3.3"/>. <xref derived
		Content="" format="title" sectionFormat="of" target="name-rationale-for-our-advi
		ce-on">Rationale for Our Advice on the Handling of IPv6 Packets with Specific IP
		v6 Extension Headers</xref></t>
		</li>
		<li pn="section-toc.1-1.3.2.4">
		<t indent="0" pn="section-toc.1-1.3.2.4.1"><xref derivedContent=
		"3.4" format="counter" sectionFormat="of" target="section-3.4"/>. <xref derived
		Content="" format="title" sectionFormat="of" target="name-summary-of-advice-on-t
		he-ha">Summary of Advice on the Handling of IPv6 Packets with Specific IPv6 Exte
		nsion Headers</xref></t>
		</li>
		<li pn="section-toc.1-1.3.2.5">
		<t indent="0" pn="section-toc.1-1.3.2.5.1"><xref derivedContent=
		"3.5" format="counter" sectionFormat="of" target="section-3.5"/>. <xref derived
		Content="" format="title" sectionFormat="of" target="name-advice-on-the-handling
		-of-i">Advice on the Handling of IPv6 Packets with Specific IPv6 Extension Heade
		rs</xref></t>
		</li>
		<li pn="section-toc.1-1.3.2.6">
		<t indent="0" pn="section-toc.1-1.3.2.6.1"><xref derivedContent=
		"3.6" format="counter" sectionFormat="of" target="section-3.6"/>. <xref derived
		Content="" format="title" sectionFormat="of" target="name-advice-on-the-handling
		-of-p">Advice on the Handling of Packets with Unknown IPv6 Extension Headers</xr
		ef></t>
		</li>
		</ul>
		</li>
		<li pn="section-toc.1-1.4">
		<t indent="0" pn="section-toc.1-1.4.1"><xref derivedContent="4" form
		at="counter" sectionFormat="of" target="section-4"/>. <xref derivedContent="" f
		ormat="title" sectionFormat="of" target="name-ipv6-options">IPv6 Options</xref><
		/t>
		<ul bare="true" empty="true" indent="2" spacing="compact" pn="sectio
		n-toc.1-1.4.2">
		<li pn="section-toc.1-1.4.2.1">
		<t indent="0" pn="section-toc.1-1.4.2.1.1"><xref derivedContent=
		"4.1" format="counter" sectionFormat="of" target="section-4.1"/>. <xref derived
		Content="" format="title" sectionFormat="of" target="name-general-discussion-2">
		General Discussion</xref></t>
		</li>
		<li pn="section-toc.1-1.4.2.2">
		<t indent="0" pn="section-toc.1-1.4.2.2.1"><xref derivedContent=
		"4.2" format="counter" sectionFormat="of" target="section-4.2"/>. <xref derived
		Content="" format="title" sectionFormat="of" target="name-general-security-impli
		cation">General Security Implications of IPv6 Options</xref></t>
		</li>
		<li pn="section-toc.1-1.4.2.3">
		<t indent="0" pn="section-toc.1-1.4.2.3.1"><xref derivedContent=
		"4.3" format="counter" sectionFormat="of" target="section-4.3"/>. <xref derived
		Content="" format="title" sectionFormat="of" target="name-summary-of-advice-on-t
		he-hand">Summary of Advice on the Handling of IPv6 Packets with Specific IPv6 Op
		tions</xref></t>
		</li>
		<li pn="section-toc.1-1.4.2.4">
		<t indent="0" pn="section-toc.1-1.4.2.4.1"><xref derivedContent=
		"4.4" format="counter" sectionFormat="of" target="section-4.4"/>. <xref derived
		Content="" format="title" sectionFormat="of" target="name-advice-on-the-handling
		-of-pa">Advice on the Handling of Packets with Specific IPv6 Options</xref></t>
		</li>
		<li pn="section-toc.1-1.4.2.5">
		<t indent="0" pn="section-toc.1-1.4.2.5.1"><xref derivedContent=
		"4.5" format="counter" sectionFormat="of" target="section-4.5"/>. <xref derived
		Content="" format="title" sectionFormat="of" target="name-advice-on-the-handling
		-of-pac">Advice on the Handling of Packets with Unknown IPv6 Options</xref></t>
		</li>
		</ul>
		</li>
		<li pn="section-toc.1-1.5">
		<t indent="0" pn="section-toc.1-1.5.1"><xref derivedContent="5" form
		at="counter" sectionFormat="of" target="section-5"/>. <xref derivedContent="" f
		ormat="title" sectionFormat="of" target="name-iana-considerations">IANA Consider
		ations</xref></t>
		</li>
		<li pn="section-toc.1-1.6">
		<t indent="0" pn="section-toc.1-1.6.1"><xref derivedContent="6" form
		at="counter" sectionFormat="of" target="section-6"/>. <xref derivedContent="" f
		ormat="title" sectionFormat="of" target="name-privacy-considerations">Privacy Co
		nsiderations</xref></t>
		</li>
		<li pn="section-toc.1-1.7">
		<t indent="0" pn="section-toc.1-1.7.1"><xref derivedContent="7" form
		at="counter" sectionFormat="of" target="section-7"/>. <xref derivedContent="" f
		ormat="title" sectionFormat="of" target="name-security-considerations">Security
		Considerations</xref></t>
		</li>
		<li pn="section-toc.1-1.8">
		<t indent="0" pn="section-toc.1-1.8.1"><xref derivedContent="8" form
		at="counter" sectionFormat="of" target="section-8"/>. <xref derivedContent="" f
		ormat="title" sectionFormat="of" target="name-references">References</xref></t>
		<ul bare="true" empty="true" indent="2" spacing="compact" pn="sectio
		n-toc.1-1.8.2">
		<li pn="section-toc.1-1.8.2.1">
		<t indent="0" pn="section-toc.1-1.8.2.1.1"><xref derivedContent=
		"8.1" format="counter" sectionFormat="of" target="section-8.1"/>. <xref derived
		Content="" format="title" sectionFormat="of" target="name-normative-references">
		Normative References</xref></t>
		</li>
		<li pn="section-toc.1-1.8.2.2">
		<t indent="0" pn="section-toc.1-1.8.2.2.1"><xref derivedContent=
		"8.2" format="counter" sectionFormat="of" target="section-8.2"/>. <xref derived
		Content="" format="title" sectionFormat="of" target="name-informative-references
		">Informative References</xref></t>
		</li>
		</ul>
		</li>
		<li pn="section-toc.1-1.9">
		<t indent="0" pn="section-toc.1-1.9.1"><xref derivedContent="" forma
		t="none" sectionFormat="of" target="section-appendix.a"/><xref derivedContent=""
		format="title" sectionFormat="of" target="name-acknowledgements">Acknowledgemen
		ts</xref></t>
		</li>
		<li pn="section-toc.1-1.10">
		<t indent="0" pn="section-toc.1-1.10.1"><xref derivedContent="" form
		at="none" sectionFormat="of" target="section-appendix.b"/><xref derivedContent="
		" format="title" sectionFormat="of" target="name-authors-addresses">Authors' Add
		resses</xref></t>
		</li>
		</ul>
		</section>
		</toc>
		</front>
		<middle>
		<section anchor="intro" numbered="true" toc="include" removeInRFC="false" pn
		="section-1">
		<name slugifiedName="name-introduction">Introduction</name>
		<t indent="0" pn="section-1-1">IPv6 Extension Headers (EHs) allow for the
		extension of the IPv6
		protocol and provide support for core functionality, such as IPv6
		fragmentation. However, common implementation limitations suggest that EHs p
		resent a challenge for IPv6 packet routing equipment, particularly when the IPv6
		header chain needs to be processed for, as an example, enforcing Access Control
		Lists (ACLs) or implementing other functions <xref target="RFC9098" format="def
		ault" sectionFormat="of" derivedContent="RFC9098"/>.
	</t>	</t>

		<t indent="0" pn="section-1-2">Several studies (e.g., <xref target="Huston
	<t>Several studies (e.g. <xref target="Huston-2022"/>, <xref target="I-D.vyncke-	-2022" format="default" sectionFormat="of" derivedContent="Huston-2022"/>, <xref
	v6ops-james"/>, and <xref target="RFC7872"/>) suggest that there is widespread d	target="I-D.vyncke-v6ops-james" format="default" sectionFormat="of" derivedCont
	ropping of IPv6 packets that contain IPv6 Extension Headers (EHs). In some cases	ent="JAMES"/>, and <xref target="RFC7872" format="default" sectionFormat="of" de
	, such packet drops occur at transit routers. While some operators are known to	rivedContent="RFC7872"/>) suggest that there is widespread dropping of IPv6 pack
	intentionally drop packets that contain IPv6 EHs, it is possible that some of th	ets that contain IPv6 EHs. In some cases, such packet drops occur at transit rou
	e measured packet drops are the result of inappropriate advice in this area.</t>	ters. While some operators are known to intentionally drop packets that contain
		IPv6 EHs, it is possible that some of the measured packet drops are the result o
	<t>This document analyzes both the general security implications of	f inappropriate advice in this area.</t>
		<t indent="0" pn="section-1-3">This document analyzes both the general sec
		urity 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 indent="0" pn="section-1-4">The resulting packet filtering policy typic
	<t>The resulting packet filtering policy typically depends on where in the netwo	ally depends on where in the network such policy is enforced. When the policy is
	rk such policy is enforced: when the policy is enforced in a transit network, th	enforced in a transit network, the policy typically follows a "deny-list" appro
	e policy typically follows a "deny-list" approach, where only packets with clear	ach, where only packets with clear negative implications are dropped. On the oth
	negative implications are dropped. On the other hand, when the policy is enforc	er hand, when the policy is enforced closer to the destination systems, the poli
	ed closer to the destination systems, the policy typically follows an "accept-li	cy typically follows an "accept-list" approach, where only traffic that is expec
	st" approach, where only traffic that is expected to be received is allowed. The	ted to be received is allowed. The advice in this document is aimed only at tran
	advice in this document is aimed only at transit routers that may need to enfor	sit routers that may need to enforce a filtering policy based on the IPv6 EHs an
	ce a filtering policy based on the EHs and IPv6 options a packet may contain, fo	d IPv6 options a packet may contain, following a "deny-list" approach; hence, it
	llowing a "deny-list" approach, and hence is likely to be much more permissive t	is likely to be much more permissive than a filtering policy to be employed at,
	han a filtering policy to be employed at e.g. the edge of an enterprise network.	for example, the edge of an enterprise network. The advice in this document is
	The advice in this document is meant to improve the current situation of the dr	meant to improve the current situation of the dropping of packets with IPv6 EHs
	opping of packets with IPv6 EHs in the Internet <xref target="RFC7872"/> in such	in the Internet <xref target="RFC7872" format="default" sectionFormat="of" deriv
	cases where packets are being dropped due to inappropriate or missing guideline	edContent="RFC7872"/> in such cases where packets are being dropped due to inapp
	s.</t>	ropriate or missing guidelines.</t>
		<t indent="0" pn="section-1-5">This document is similar in nature to
	<t>This document is similar in nature to	<xref target="RFC7126" format="default" sectionFormat="of" derivedContent="RF
	<xref target="RFC7126"/>, which addresses the same problem for the IPv4 case.	C7126"/>, which addresses the same problem for the IPv4 case. However, in IPv6,
	However, in IPv6, the problem space is compounded by the fact that IPv6 specifi	the problem space is compounded by the fact that IPv6 specifies a number of IPv6
	es a number of IPv6 EHs, and a number of IPv6 options which may be valid only wh	EHs and a number of IPv6 options that may be valid only when included in specif
	en included in specific EH types.</t>	ic EH types.</t>
		<t indent="0" pn="section-1-6">This document completes and complements the
	<t>This document completes and complements the considerations for protecting the	considerations for protecting the control plane from packets containing IP opti
	control plane from packets containing IP options that can be found in <xref tar	ons that can be found in <xref target="RFC6192" format="default" sectionFormat="
	get="RFC6192"/>.</t>	of" derivedContent="RFC6192"/>.</t>
		<t indent="0" pn="section-1-7"><xref target="terms" format="default" secti
	<t><xref target="terms"/> specifies the terminology and conventions employed thr	onFormat="of" derivedContent="Section 2"/> specifies the terminology and convent
	oughout this document. <xref target="ipv6-extension-headers-discussion"/> discus	ions employed throughout this document. <xref target="ipv6-extension-headers-dis
	ses IPv6 EHs and provides advice in the area of filtering IPv6 packets that cont	cussion" format="default" sectionFormat="of" derivedContent="Section 3"/> discus
	ain such IPv6 EHs. <xref target="ipv6-options-discussion"/> discusses IPv6 optio	ses IPv6 EHs and provides advice in the area of filtering IPv6 packets that cont
	ns and provides advice in the area of filtering IPv6 packets that contain such o	ain such IPv6 EHs. <xref target="ipv6-options-discussion" format="default" secti
	ptions. <!-- <xref target="upper-layer"/> specifies the filtering of packets ba	onFormat="of" derivedContent="Section 4"/> discusses IPv6 options and provides a
	sed on the upper-layer protocol. Specifically, it identifies upper-layer protoco	dvice in the area of filtering IPv6 packets that contain such options.
	ls that, for different reasons, should not be present in IPv6 packets. -->	</t>
	</t>	</section>
		<section anchor="terms" numbered="true" toc="include" removeInRFC="false" pn
	<!--	="section-2">
	<t>While this document is similar in structure and nature to <xref target="RFC71	<name slugifiedName="name-terminology-and-assumptions">Terminology and Ass
	23"/>, we note that this document is aimed at firewall administrators, an hence	umptions Employed in This Document</name>
	tends to be more restrictive than what an IPv6-version of <xref target="RFC7123"	<section numbered="true" toc="include" removeInRFC="false" pn="section-2.1
	/> would be.</t>	">
		<name slugifiedName="name-terminology">Terminology</name>
	</section>	<t indent="0" pn="section-2.1-1">The terms "permit" (allow the traffic),
		"drop" (drop with no notification to sender), and "reject" (drop with appropria
	<section title="Terminology and Assumptions Employed in This Document"	te notification to sender) are employed as defined in <xref target="RFC3871" for
	anchor="terms">	mat="default" sectionFormat="of" derivedContent="RFC3871"/>. Throughout this doc
	<section title="Terminology">	ument, we also employ the term "discard" as a generic term to indicate the act o
		f discarding a packet, irrespective of whether the sender is notified of such a
	<t>The terms "permit" (allow the traffic), "drop" (drop with no notification to	drop and whether the specific filtering action is logged.
	sender), and "reject" (drop with appropriate notification to sender) are employe
	d as defined in <xref target="RFC3871"/>. Throughout this document we also emplo
	y the term "discard" as a generic term to indicate the act of discarding a packe
	t, irrespective of whether the sender is notified of such drops, and irrespectiv
	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 indent="0" pn="section-2.1-2">
	</section>	The key words "<bcp14>MUST</bcp14>", "<bcp14>MUST NOT</bcp14>", "<bcp14>REQU
		IRED</bcp14>", "<bcp14>SHALL</bcp14>", "<bcp14>SHALL NOT</bcp14>", "<bcp14>SHOUL
	<section title="Applicability Statement">	D</bcp14>", "<bcp14>SHOULD NOT</bcp14>", "<bcp14>RECOMMENDED</bcp14>", "<bcp14>N
	<t>This document provides advice on the filtering of IPv6 packets with EHs at tr	OT RECOMMENDED</bcp14>",
	ansit routers for traffic not explicitly destined to them, for cases in which su	"<bcp14>MAY</bcp14>", and "<bcp14>OPTIONAL</bcp14>" in this document are to
	ch filtering is deemed as necessary.</t>	be interpreted as
	</section>	described in BCP 14 <xref target="RFC2119" format="default" sectionFormat="o
		f" derivedContent="RFC2119"/> <xref target="RFC8174" format="default" sectionFor
	<section title="Router Default Behavior and Features">	mat="of" derivedContent="RFC8174"/>
	<t>This document assumes that nodes comply with the requirements in <xref target	when, and only when, they appear in all capitals, as shown here.
	="RFC7045"/>. Namely,	</t>
	<list style="hanging">	</section>
	<t>"If a forwarding node discards a packet containing a standard IPv6	<section numbered="true" toc="include" removeInRFC="false" pn="section-2.2
	extension header, it MUST be the result of a configurable policy and	">
		<name slugifiedName="name-applicability-statement">Applicability Stateme
		nt</name>
		<t indent="0" pn="section-2.2-1">This document provides advice on the fi
		ltering of IPv6 packets with EHs at transit routers for traffic not explicitly d
		estined to them, for cases in which such filtering is deemed as necessary.</t>
		</section>
		<section numbered="true" toc="include" removeInRFC="false" pn="section-2.3
		">
		<name slugifiedName="name-router-default-behavior-and">Router Default Be
		havior and Features</name>
		<t indent="0" pn="section-2.3-1">This document assumes that nodes comply
		with the requirements in <xref target="RFC7045" format="default" sectionFormat=
		"of" derivedContent="RFC7045"/>. Namely,
		</t>
		<blockquote pn="section-2.3-2">If a forwarding node discards a packet co
		ntaining a standard IPv6
		extension header, it <bcp14>MUST</bcp14> be the result of a configurable poli
		cy 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 indent="0" pn="section-2.3-3">


	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" sectionF
	ont-6man-ipv6-opt-transmit"/>-->. <!--We note that the advice provided in this d	ormat="of" derivedContent="RFC7045"/>.
	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 indent="0" pn="section-2.3-4">We recommend that configuration options
	<t>We note that special care needs to be taken when devices log packet drops/rej	be made available to govern the processing of each IPv6 EH type and each IPv6 O
	ects. Devices should count the number of packets dropped/rejected, but the loggi	ption Type. Such configuration options should include the following possible set
	ng of drop/reject events should be limited so as to not overburden device resour	tings:
	ces.</t>	</t>
		<ul spacing="normal" bare="false" empty="false" indent="3" pn="section-2
	<t>Finally, we note that when discarding packets, it is generally desirable that	.3-5">
	the sender be signaled of the packet drop, since this is of use for trouble-sho	<li pn="section-2.3-5.1">Permit this IPv6 EH or IPv6 Option Type.</li>
	oting purposes. However, throughout this document (when recommending that packet	<li pn="section-2.3-5.2">Drop packets containing this IPv6 EH or IPv6
	s be discarded) we generically refer to the action as "discard" without specifyi	Option Type.</li>
	ng whether the sender is signaled of the packet drop.</t>	<li pn="section-2.3-5.3">Reject packets containing this IPv6 EH or IPv
	</section>	6 Option Type (where the packet drop is signaled with an ICMPv6 error message).<
	</section>	/li>
		<li pn="section-2.3-5.4">Rate-limit traffic containing this IPv6 EH or
	<section title="IPv6 Extension Headers" anchor="ipv6-extension-headers-discussio	IPv6 Option Type.</li>
	n">	<li pn="section-2.3-5.5">Ignore this IPv6 EH or IPv6 Option Type (as i
	<section title="General Discussion">	f it was not present), and process the packet according the rules for the remain
	<t>IPv6 <xref target="RFC8200"/> EHs allow for the extension of the IPv6 protoco	ing headers. We note that if a packet carries forwarding information (e.g., in a
	l. Since both IPv6 EHs and upper-layer protocols share the same namespace ("Next	n IPv6 Routing Header (RH)), this might be an inappropriate or undesirable actio
	Header" registry/namespace), <xref target="RFC7045"/> identifies which of the c	n.</li>
	urrently assigned Internet Protocol numbers identify IPv6 EHs vs. upper-layer pr	</ul>
	otocols. This document discusses the filtering of packets based on the IPv6 EHs	<t indent="0" pn="section-2.3-6">We note that special care needs to be t
	(as specified by <xref target="RFC7045"/>) they contain. <!-- Filtering of IPv6	aken when devices log packet drops/rejects. Devices should count the number of p
	packets based on the upper-layer protocol is specified in <xref target="upper-la	ackets dropped/rejected, but the logging of drop/reject events should be limited
	yer"/>--></t>	so as to not overburden device resources.</t>
		<t indent="0" pn="section-2.3-7">Finally, we note that when discarding p
	<t>	ackets, it is generally desirable that the sender be signaled of the packet drop
	<list style="hanging">	, since this is of use for trouble-shooting purposes. However, throughout this d
	<t>	ocument (when recommending that packets be discarded), we generically refer to t
	NOTE: <xref target="RFC8200"/> specifies that non-fragmented IPv6 datagrams and	he action as "discard" without specifying whether the sender is signaled of the
	IPv6 First-Fragments must contain the entire IPv6 header chain <xref target="RFC	packet drop.</t>
	7112"/>. Therefore, intermediate systems can enforce the filtering policies disc	</section>
	ussed in this document, or resort to simply discarding the offending packets whe	</section>
	n they fail to comply with the requirements in <xref target="RFC8200"/>. We note	<section anchor="ipv6-extension-headers-discussion" numbered="true" toc="inc
	that, in order to implement filtering rules on the fast path, it may be necessa	lude" removeInRFC="false" pn="section-3">
	ry for the filtering device to limit the depth into the packet that can be inspe	<name slugifiedName="name-ipv6-extension-headers">IPv6 Extension Headers</
	cted before giving up. In circumstances where such	name>
		<section numbered="true" toc="include" removeInRFC="false" pn="section-3.1
		">
		<name slugifiedName="name-general-discussion">General Discussion</name>
		<t indent="0" pn="section-3.1-1">IPv6 EHs <xref target="RFC8200" format=
		"default" sectionFormat="of" derivedContent="RFC8200"/> allow for the extension
		of the IPv6 protocol. Since both IPv6 EHs and upper-layer protocols share the sa
		me namespace ("Next Header" registry/namespace), <xref target="RFC7045" format="
		default" sectionFormat="of" derivedContent="RFC7045"/> identifies which of the c
		urrently assigned Internet Protocol numbers identify IPv6 EHs vs. upper-layer pr
		otocols. This document discusses the filtering of packets based on the IPv6 EHs
		(as specified by <xref target="RFC7045" format="default" sectionFormat="of" deri
		vedContent="RFC7045"/>) they contain.
		</t>
		<t indent="0" pn="section-3.1-2">
		<xref target="RFC8200" format="default" sectionFormat="of" derivedContent="RFC82
		00"/> specifies that non-fragmented IPv6 datagrams and IPv6 First-Fragments must
		contain the entire IPv6 header chain <xref target="RFC7112" format="default" se
		ctionFormat="of" derivedContent="RFC7112"/>. Therefore, intermediate systems can
		enforce the filtering policies discussed in this document or resort to simply d
		iscarding the offending packets when they fail to include the entire IPv6 header
		chain <xref target="RFC8200" format="default" sectionFormat="of" derivedContent
		="RFC8200"/>. </t>
		<t indent="0" pn="section-3.1-3">
		We note that in order to implement filtering rules on the fast path, it may be n
		ecessary for the filtering device to limit the depth into the packet that can be
		inspected 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>	</section>
	</t>	<section anchor="ipv6-eh-general-implications" numbered="true" toc="includ
	<!--	e" removeInRFC="false" pn="section-3.2">
	<t>When processing a non-fragmented IPv6 datagram or an IPv6 First-Fragment, the	<name slugifiedName="name-general-security-implicatio">General Security
	packet must contain the entire IPv6 header chain <xref target="RFC7112"/>. An i	Implications</name>
	ntermediate system that processes a packet that fails to comply with this requir	<t indent="0" pn="section-3.2-1">In some device architectures, IPv6 pack
	ement should therefore drop the offending packets.	ets that contain IPv6 EHs can cause the corresponding packets to be processed on
	</t>	the slow path and, hence, may be leveraged for the purpose of Denial-of-Service
	</section>	(DoS) attacks <xref target="RFC9098" format="default" sectionFormat="of" derive
		dContent="RFC9098"/> <xref target="Cisco-EH" format="default" sectionFormat="of"
	<section title="General Security Implications" anchor="ipv6-eh-general-implicati	derivedContent="Cisco-EH"/> <xref target="FW-Benchmark" format="default" sectio
	ons">	nFormat="of" derivedContent="FW-Benchmark"/>.
	<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>

	<t>Operators are urged to consider the IPv6 EH and IPv6 options handling capabil	<t indent="0" pn="section-3.2-2">Operators are urged to consider the IPv
	ities of their devices as they make deployment decisions in the future.</t>	6 EH and IPv6 options handling capabilities of their devices as they make deploy
	</section>	ment decisions in the future.</t>
		</section>
	<section title="Rationale for Our Advice on the Handling of IPv6 Packets with Sp	<section anchor="ipv6-ehs-rationale" numbered="true" toc="include" removeI
	ecific IPv6 Extension Headers" anchor="ipv6-ehs-rationale">	nRFC="false" pn="section-3.3">
	<t>	<name slugifiedName="name-rationale-for-our-advice-on">Rationale for Our
	<list style="symbols">	Advice on the Handling of IPv6 Packets with Specific IPv6 Extension Headers</na
	<t>IPv6 Packets with IPv6 Extension Headers (or options) that are not expected t	me>
	o traverse transit routers should be dropped.</t>	<ul spacing="normal" bare="false" empty="false" indent="3" pn="section-3
		.3-1">
	<t>IPv6 Packets with IPv6 Extension Headers (or options) that are only	<li pn="section-3.3-1.1">IPv6 packets with IPv6 Extension Headers (or
		options) that are not expected to traverse transit routers should be dropped.</l
		i>
		<li pn="section-3.3-1.2">IPv6 packets with IPv6 Extension Headers (or
		options) that are only
	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 pn="section-3.3-1.3">IPv6 packets with IPv6 Extension Headers (or
	<t>IPv6 Packets with IPv6 Extension Headers (or options) that represent	options) that represent
	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 pn="section-3.3-1.4">IPv6 packets with any other IPv6 Extension He
	<t>IPv6 packets with any other IPv6 Extension headers (or options)	aders (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="include" removeInRFC="false" pn="section-3.4
	</section>	">
		<name slugifiedName="name-summary-of-advice-on-the-ha">Summary of Advice
	<section title="Summary of Advice on the Handling of IPv6 Packets with Specific	on the Handling of IPv6 Packets with Specific IPv6 Extension Headers</name>
	IPv6 Extension Headers">	<t indent="0" pn="section-3.4-1">This section summarizes the advice prov
	<t>This section summarizes the advice provided in <xref target="advice-ehs"/>, p	ided in <xref target="advice-ehs" format="default" sectionFormat="of" derivedCon
	roviding references to the specific sections in which a detailed analysis can be	tent="Section 3.5"/>, providing references to the specific sections in which a d
	found.</t>	etailed analysis can be found.</t>
		<table anchor="eh-table" align="center" pn="table-1">
	<texttable title="Summary of Advice on the Handling of IPv6 Packets with Spe	<name slugifiedName="name-summary-of-advice-on-the-han">Summary of Adv
	cific IPv6 Extension Headers" style="all" anchor="eh-table">	ice on the Handling of IPv6 Packets with Specific IPv6 Extension Headers</name>
	<ttcol align="center">EH type</ttcol>	<thead>
	<ttcol align="center">Filtering policy</ttcol>	<tr>
	<ttcol align="center">Reference</ttcol>	<th align="center" colspan="1" rowspan="1">EH Type</th>
	<c>IPv6 Hop-by-Hop Options (Proto=0)</c><c>Drop or Ignore</c><c><xref target="pr	<th align="center" colspan="1" rowspan="1">Filtering Policy</th>
	oto0"/></c>	<th align="center" colspan="1" rowspan="1">Reference</th>
	<c>Routing Header for IPv6 (Proto=43)</c><c>Drop only RHT0 and RHT1. Permit othe	</tr>
	r RH Types</c><c><xref target="proto43"/></c>	</thead>
	<c>Fragment Header for IPv6 (Proto=44)</c><c>Permit</c><c><xref target="proto44"	<tbody>
	/></c>	<tr>
	<c>Encapsulating Security Payload (Proto=50)</c><c>Permit</c><c><xref target="pr	<td align="center" colspan="1" rowspan="1">Hop-by-Hop Options Head
	oto50"/></c>	er (Proto=0)</td>
	<c>Authentication Header (Proto=51)</c><c>Permit</c><c><xref target="proto51"/><	<td align="center" colspan="1" rowspan="1">Drop or Ignore</td>
	/c>	<td align="center" colspan="1" rowspan="1">
	<c>Destination Options for IPv6 (Proto=60)</c><c>Permit</c><c><xref target="prot	<xref target="proto0" format="default" sectionFormat="of" derive
	o60"/></c>	dContent="Section 3.5.1"/></td>
	<c>Mobility Header (Proto=135)</c><c>Permit</c><c><xref target="proto135"/></c>	</tr>
	<c>Host Identity Protocol (Proto=139)</c><c>Permit</c><c><xref target="proto139"	<tr>
	/></c>	<td align="center" colspan="1" rowspan="1">Routing Header (Proto=4
	<c>Shim6 Protocol (Proto=140)</c><c>Permit</c><c><xref target="proto140"/></c>	3)</td>
	<c>Use for experimentation and testing (Proto=253 and	<td align="center" colspan="1" rowspan="1">Drop only Routing Type
	254)</c><c>Drop</c><c><xref target="proto253254"/></c>	0, Routing Type 1, and Routing Type 3. Permit other Routing Types</td>
	</texttable>	<td align="center" colspan="1" rowspan="1">
		<xref target="proto43" format="default" sectionFormat="of" deriv
	</section>	edContent="Section 3.5.2"/></td>
		</tr>
	<section title="Advice on the Handling of IPv6 Packets with Specific IPv6 Extens	<tr>
	ion Headers" anchor="advice-ehs">	<td align="center" colspan="1" rowspan="1">Fragment Header (Proto=
		44)</td>
	<section title="IPv6 Hop-by-Hop Options (Protocol Number=0)" anchor="proto0">	<td align="center" colspan="1" rowspan="1">Permit</td>
	<section title="Uses">	<td align="center" colspan="1" rowspan="1">
	<t>The Hop-by-Hop Options header is used to carry optional information that may	<xref target="proto44" format="default" sectionFormat="of" deriv
	be examined by every node along a packet's delivery path. It is expected that no	edContent="Section 3.5.3"/></td>
	des will examine the Hop-by-Hop Options header if explicitly configured to do so	</tr>
	.</t>	<tr>
		<td align="center" colspan="1" rowspan="1">Encapsulating Security
	<t>NOTE: A previous revision of the IPv6 core specification, <xref target="RFC24	Payload (Proto=50)</td>
	60"/>, originally required that all nodes examined and processed the Hop-by-Hop	<td align="center" colspan="1" rowspan="1">Permit</td>
	Options header. However, even before the publication of <xref target="RFC8200"/>	<td align="center" colspan="1" rowspan="1">
	a number of implementations already provided the option of ignoring this header	<xref target="proto50" format="default" sectionFormat="of" deriv
	unless explicitly configured to examine it.	edContent="Section 3.5.4"/></td>
	</t>	</tr>
		<tr>
	</section>	<td align="center" colspan="1" rowspan="1">Authentication Header (
		Proto=51)</td>
	<section title="Specification">	<td align="center" colspan="1" rowspan="1">Permit</td>
	<t>This EH is specified in <xref target="RFC8200"/>. As of May 2022, the followi	<td align="center" colspan="1" rowspan="1">
	ng options have been specified for the Hop-by-Hop Options EH:	<xref target="proto51" format="default" sectionFormat="of" deriv
		edContent="Section 3.5.5"/></td>
		</tr>
		<tr>
		<td align="center" colspan="1" rowspan="1">Destination Options Hea
		der(Proto=60)</td>
		<td align="center" colspan="1" rowspan="1">Permit</td>
		<td align="center" colspan="1" rowspan="1">
		<xref target="proto60" format="default" sectionFormat="of" deriv
		edContent="Section 3.5.6"/></td>
		</tr>
		<tr>
		<td align="center" colspan="1" rowspan="1">Mobility Header (Proto=
		135)</td>
		<td align="center" colspan="1" rowspan="1">Permit</td>
		<td align="center" colspan="1" rowspan="1">
		<xref target="proto135" format="default" sectionFormat="of" deri
		vedContent="Section 3.5.7"/></td>
		</tr>
		<tr>
		<td align="center" colspan="1" rowspan="1">Host Identity Protocol
		(Proto=139)</td>
		<td align="center" colspan="1" rowspan="1">Permit</td>
		<td align="center" colspan="1" rowspan="1">
		<xref target="proto139" format="default" sectionFormat="of" deri
		vedContent="Section 3.5.8"/></td>
		</tr>
		<tr>
		<td align="center" colspan="1" rowspan="1">Shim6 Protocol (Proto=1
		40)</td>
		<td align="center" colspan="1" rowspan="1">Permit</td>
		<td align="center" colspan="1" rowspan="1">
		<xref target="proto140" format="default" sectionFormat="of" deri
		vedContent="Section 3.5.9"/></td>
		</tr>
		<tr>
		<td align="center" colspan="1" rowspan="1">Use for experimentation
		and testing (Proto=253 and
		254)</td>
		<td align="center" colspan="1" rowspan="1">Drop</td>
		<td align="center" colspan="1" rowspan="1">
		<xref target="proto253254" format="default" sectionFormat="of" d
		erivedContent="Section 3.5.10"/></td>
		</tr>
		</tbody>
		</table>
		</section>
		<section anchor="advice-ehs" numbered="true" toc="include" removeInRFC="fa
		lse" pn="section-3.5">
		<name slugifiedName="name-advice-on-the-handling-of-i">Advice on the Han
		dling of IPv6 Packets with Specific IPv6 Extension Headers</name>
		<section anchor="proto0" numbered="true" toc="exclude" removeInRFC="fals
		e" pn="section-3.5.1">
		<name slugifiedName="name-ipv6-hop-by-hop-options-pro">IPv6 Hop-by-Hop
		Options (Protocol Number=0)</name>
		<section numbered="true" toc="exclude" removeInRFC="false" pn="section
		-3.5.1.1">
		<name slugifiedName="name-uses">Uses</name>
		<t indent="0" pn="section-3.5.1.1-1">The Hop-by-Hop (HBH) Options he
		ader is used to carry optional information that may be examined by every node al
		ong a packet's delivery path. It is expected that nodes will examine the Hop-by-
		Hop Options header if explicitly configured to do so.</t>
		<aside pn="section-3.5.1.1-2">
		<t indent="0" pn="section-3.5.1.1-2.1">NOTE: A previous revision o
		f the IPv6 core specification <xref target="RFC2460" format="default" sectionFor
		mat="of" derivedContent="RFC2460"/> originally required all nodes to examine and
		process the Hop-by-Hop Options header. However, even before the publication of
		<xref target="RFC8200" format="default" sectionFormat="of" derivedContent="RFC82
		00"/>, a number of implementations already provided 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="exclude" removeInRFC="false" pn="section
	<t>Type 0x01: PadN <xref target="RFC8200"/></t>	-3.5.1.2">
	<t>Type 0x05: Router Alert <xref target="RFC2711"/></t>	<name slugifiedName="name-specification">Specification</name>
	<t>Type 0x07: CALIPSO <xref target="RFC5570"/></t>	<t indent="0" pn="section-3.5.1.2-1">This EH is specified in <xref t
	<t>Type 0x08: SMF_DPD <xref target="RFC6621"/></t>	arget="RFC8200" format="default" sectionFormat="of" derivedContent="RFC8200"/>.
	<t>Type 0x23: RPL Option <xref target="RFC9008"/></t>	As of May 2022, the following options have been specified for the Hop-by-Hop Opt
	<t>Type 0x26: Quick-Start <xref target="RFC4782"/></t>	ions header:
	<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" bare="false" empty="false" indent="3" pn="secti
		on-3.5.1.2-2">
	<section title="Operational and Interoperability Impact if Blocked">	<li pn="section-3.5.1.2-2.1">Type 0x00: Pad1 <xref target="RFC8200
	<t>Discarding packets containing a Hop-by-Hop Options EH would break any of the	" format="default" sectionFormat="of" derivedContent="RFC8200"/></li>
	protocols that rely on it for proper functioning. For example, it would break RS	<li pn="section-3.5.1.2-2.2">Type 0x01: PadN <xref target="RFC8200
	VP <xref target="RFC2205"/> and multicast deployments, and would cause IPv6 jumb	" format="default" sectionFormat="of" derivedContent="RFC8200"/></li>
	ograms to be discarded.</t>	<li pn="section-3.5.1.2-2.3">Type 0x05: Router Alert <xref target=
	</section>	"RFC2711" format="default" sectionFormat="of" derivedContent="RFC2711"/></li>
		<li pn="section-3.5.1.2-2.4">Type 0x07: CALIPSO <xref target="RFC5
	<section title="Advice">	570" format="default" sectionFormat="of" derivedContent="RFC5570"/></li>
	<t>Nodes implementing <xref target="RFC8200"/> would already ignore this extensi	<li pn="section-3.5.1.2-2.5">Type 0x08: SMF_DPD <xref target="RFC6
	on header unless explicitly required to process it. For legacy (<xref target="RF	621" format="default" sectionFormat="of" derivedContent="RFC6621"/></li>
	C2460"/>) nodes, the recommended configuration for the processing of these packe	<li pn="section-3.5.1.2-2.6">Type 0x23: RPL Option <xref target="R
	ts depends on the features and capabilities of the underlying platform, the conf	FC9008" format="default" sectionFormat="of" derivedContent="RFC9008"/></li>
	iguration of the platform, and also the deployment environment of the platform.	<li pn="section-3.5.1.2-2.7">Type 0x26: Quick-Start <xref target="
	On platforms that allow forwarding of packets with HBH Options on the fast path,	RFC4782" format="default" sectionFormat="of" derivedContent="RFC4782"/></li>
	we recommend that packets with a HBH Options EH be forwarded as normal. Otherwi	<li pn="section-3.5.1.2-2.8">Type 0x4D: (Deprecated)</li>
	se, on platforms in which processing of packets with a IPv6 HBH Options EH is ca	<li pn="section-3.5.1.2-2.9">Type 0x63: RPL Option <xref target="R
	rried out in the slow path, and an option is provided to rate-limit these packet	FC6553" format="default" sectionFormat="of" derivedContent="RFC6553"/></li>
	s, we recommend that this option be selected. Finally, when packets containing a	<li pn="section-3.5.1.2-2.10">Type 0x6D: MPL Option <xref target="
	HBH Options EH are processed in the slow-path, and the underlying platform does	RFC7731" format="default" sectionFormat="of" derivedContent="RFC7731"/></li>
	not have any mitigation options available for attacks based on these packets, w	<li pn="section-3.5.1.2-2.11">Type 0x8A: Endpoint Identification (
	e recommend that such platforms discard packets containing IPv6 HBH Options EHs.	Deprecated) <xref target="NIMROD-EID" format="default" sectionFormat="of" derive
	</t>	dContent="NIMROD-EID"/></li>
		<li pn="section-3.5.1.2-2.12">Type 0xC2: Jumbo Payload <xref targe
	<t>Finally, we note that RPL (Routing Protocol for Low-Power and Lossy Networks)	t="RFC2675" format="default" sectionFormat="of" derivedContent="RFC2675"/></li>
	routers <xref target="RFC6550"/> must not discard packets based on the presenc	<li pn="section-3.5.1.2-2.13">Type 0xEE: IPv6 DFF Header <xref tar
	e of an IPv6 Hop-by-Hop Options EH, as this would break RPL.</t>	get="RFC6971" format="default" sectionFormat="of" derivedContent="RFC6971"/></li
		>
	</section>	<li pn="section-3.5.1.2-2.14">Type 0x1E: RFC3692-style Experiment
	</section>	<xref target="RFC4727" format="default" sectionFormat="of" derivedContent="RFC47
		27"/></li>
	<section title="Routing Header for IPv6 (Protocol Number=43)" anchor="proto43">	<li pn="section-3.5.1.2-2.15">Type 0x3E: RFC3692-style Experiment
	<section title="Uses">	<xref target="RFC4727" format="default" sectionFormat="of" derivedContent="RFC47
	<t>The Routing header is used by an IPv6 source to list one or more intermediate	27"/></li>
	nodes to be "visited" on the way to a packet's destination. </t>	<li pn="section-3.5.1.2-2.16">Type 0x5E: RFC3692-style Experiment
	</section>	<xref target="RFC4727" format="default" sectionFormat="of" derivedContent="RFC47
		27"/></li>
	<section title="Specification">	<li pn="section-3.5.1.2-2.17">Type 0x7E: RFC3692-style Experiment
	<t>This EH is specified in <xref target="RFC8200"/>. <xref target="RFC2460"/> ha	<xref target="RFC4727" format="default" sectionFormat="of" derivedContent="RFC47
	d originally specified the Routing Header Type 0, which was later obsoleted by <	27"/></li>
	xref target="RFC5095"/>, and thus removed from <xref target="RFC8200"/>.</t>	<li pn="section-3.5.1.2-2.18">Type 0x9E: RFC3692-style Experiment
		<xref target="RFC4727" format="default" sectionFormat="of" derivedContent="RFC47
	<t>At of May 2022, the following Routing Types have been specified:	27"/></li>
		<li pn="section-3.5.1.2-2.19">Type 0xBE: RFC3692-style Experiment
	<list style="symbols">	<xref target="RFC4727" format="default" sectionFormat="of" derivedContent="RFC47
	<t>Type 0: Source Route (DEPRECATED) <xref target="RFC2460"/> <xref target="RFC5	27"/></li>
	095"/></t>	<li pn="section-3.5.1.2-2.20">Type 0xDE: RFC3692-style Experiment
	<t>Type 1: Nimrod (DEPRECATED)</t>	<xref target="RFC4727" format="default" sectionFormat="of" derivedContent="RFC47
	<t>Type 2: Type 2 Routing Header <xref target="RFC6275"/></t>	27"/></li>
	<t>Type 3: RPL Source Route Header <xref target="RFC6554"/></t>	<li pn="section-3.5.1.2-2.21">Type 0xFE: RFC3692-style Experiment
	<t>Type 4: Segment Routing Header (SRH) <xref target="RFC8754"/></t>	<xref target="RFC4727" format="default" sectionFormat="of" derivedContent="RFC47
	<t>Types 5-252: Unassigned </t>	27"/></li>
	<t>Type 253: RFC3692-style Experiment 1 <xref target="RFC4727"/></t>	</ul>
	<t>Type 254: RFC3692-style Experiment 2 <xref target="RFC4727"/></t>	</section>
	<t>Type 255: Reserved</t>	<section numbered="true" toc="exclude" removeInRFC="false" pn="section
	</list>	-3.5.1.3">
		<name slugifiedName="name-specific-security-implicati">Specific Secu
		rity Implications</name>
		<t indent="0" pn="section-3.5.1.3-1">Legacy nodes that process this
		extension header might be subject to DoS attacks.</t>
		<aside pn="section-3.5.1.3-2">
		<t indent="0" pn="section-3.5.1.3-2.1">NOTE: While <xref target="R
		FC8200" format="default" sectionFormat="of" derivedContent="RFC8200"/> has remov
		ed the requirement for all nodes to examine and process the Hop-by-Hop Options h
		eader, the deployed base may still reflect the legacy <xref target="RFC2460" for
		mat="default" sectionFormat="of" derivedContent="RFC2460"/> behavior for a while
		; hence, the potential security problems of this EH are still of concern.
	</t>	</t>

		</aside>
	</section>	</section>
		<section numbered="true" toc="exclude" removeInRFC="false" pn="section
	<section title="Specific Security Implications">	-3.5.1.4">
	<t>The security implications of RHT0 have been discussed in detail in <xref targ	<name slugifiedName="name-operational-and-interoperab">Operational a
	et="Biondi2007"/> and <xref target="RFC5095"/>. RHT1 was never widely implemente	nd Interoperability Impact If Blocked</name>
	d. The security implications of RHT2, RHT3, and RHT4 (SRH) are discussed in <xre	<t indent="0" pn="section-3.5.1.4-1">Discarding packets containing a
	f target="RFC6275"/>, <xref target="RFC6554"/>, and <xref target="RFC8754"/>, r	Hop-by-Hop Options header would break any of the protocols that rely on it for
	espectively.</t>	proper functioning. For example, it would break RSVP <xref target="RFC2205" form
	</section>	at="default" sectionFormat="of" derivedContent="RFC2205"/> and multicast deploym
		ents and would cause IPv6 jumbograms to be discarded.</t>
	<section title="Operational and Interoperability Impact if Blocked">	</section>
	<t>Blocking packets containing a RHT0 or RHT1 has no operational implications, s	<section numbered="true" toc="exclude" removeInRFC="false" pn="section
	ince both have been deprecated. Blocking packets with a RHT2 would break Mobile	-3.5.1.5">
	IPv6. Packets with a RHT3 may be safely blocked at RPL domain boundaries, since	<name slugifiedName="name-advice">Advice</name>
	RHT3 headers are employed within a single RPL domain. Blocking packets with a RH	<t indent="0" pn="section-3.5.1.5-1">Nodes implementing <xref target
	T4 (SRH) will break Segment Routing (SR) deployments, if the filtering policy is	="RFC8200" format="default" sectionFormat="of" derivedContent="RFC8200"/> would
	enforced on packets being forwarded within an SR domain.</t>	already ignore this extension header unless explicitly required to process it. F
		or legacy nodes <xref target="RFC2460" format="default" sectionFormat="of" deriv
	<!--<t>However, blocking packets employing other routing header types will break	edContent="RFC2460"/>, the recommended configuration for the processing of these
	the protocols that rely on them.</t> -->	packets depends on the features and capabilities of the underlying platform, th
	</section>	e configuration of the platform, and also the deployment environment of the plat
		form. On platforms that allow the forwarding of packets with IPv6 HBH Options he
	<section title="Advice">	aders on the fast path, we recommend that packets with IPv6 HBH Options headers
	<t>Intermediate systems should discard packets containing a RHT0, RHT1, or RHT3.	be forwarded as normal. Otherwise, on platforms in which the processing of packe
	Other routing header types should be permitted, as required by <xref target="RF	ts with IPv6 HBH Options headers is carried out in the slow path and an option i
	C7045"/>.</t>	s provided to rate-limit these packets, we recommend that this option be selecte
	</section>	d. Finally, when packets containing IPv6 HBH Options headers are processed in th
	</section>	e slow path and the underlying platform does not have any mitigation options ava
		ilable for attacks based on these packets, we recommend that such platforms disc
	<section title="Fragment Header for IPv6 (Protocol Number=44)" anchor="proto44">	ard packets containing IPv6 HBH Options headers.</t>
	<section title="Uses">	<t indent="0" pn="section-3.5.1.5-2">Finally, we note that the Routi
	<t>This EH provides the fragmentation functionality for IPv6.</t>	ng Protocol for Low-Power and Lossy Networks (RPL) routers <xref target="RFC6550
	</section>	" format="default" sectionFormat="of" derivedContent="RFC6550"/> must not disca
		rd packets based on the presence of an IPv6 Hop-by-Hop Options header, as this w
	<section title="Specification">	ould break the RPL.</t>
	<t>This EH is specified in <xref target="RFC8200"/>.</t>	</section>
	</section>	</section>
		<section anchor="proto43" numbered="true" toc="exclude" removeInRFC="fal
	<section title="Specific Security Implications">	se" pn="section-3.5.2">
	<t>The security implications of the Fragment Header range from Denial of Service	<name slugifiedName="name-routing-header-protocol-num">Routing Header
	attacks (e.g. based on flooding a target with IPv6 fragments) to information le	(Protocol Number=43)</name>
	akage attacks <xref target="RFC7739"/>.</t>	<section numbered="true" toc="exclude" removeInRFC="false" pn="section
	</section>	-3.5.2.1">
		<name slugifiedName="name-uses-2">Uses</name>
	<section title="Operational and Interoperability Impact if Blocked">	<t indent="0" pn="section-3.5.2.1-1">The Routing Header is used by a
	<t>Blocking packets that contain a Fragment Header will break any protocol that	n IPv6 source to list one or more intermediate nodes to be "visited" on the way
	may rely on fragmentation (e.g., the DNS <xref target="RFC1034"/>). However, IP	to a packet's destination. </t>
	fragmentation is known to introduce fragility to Internet communication <xref ta	</section>
	rget="RFC8900"/>.</t>	<section numbered="true" toc="exclude" removeInRFC="false" pn="section
	</section>	-3.5.2.2">
		<name slugifiedName="name-specification-2">Specification</name>
	<section title="Advice">	<t indent="0" pn="section-3.5.2.2-1">This EH is specified in <xref t
	<t>Intermediate systems should permit packets that contain a Fragment Header.</t	arget="RFC8200" format="default" sectionFormat="of" derivedContent="RFC8200"/>.
	>	The Routing Type 0 had originally been specified in <xref target="RFC2460" forma
	</section>	t="default" sectionFormat="of" derivedContent="RFC2460"/> and was later obsolete
	</section>	d by <xref target="RFC5095" format="default" sectionFormat="of" derivedContent="
		RFC5095"/>; thus, it was removed from <xref target="RFC8200" format="default" se
	<section title="Encapsulating Security Payload (Protocol Number=50)" anchor="pro	ctionFormat="of" derivedContent="RFC8200"/>.</t>
	to50">	<t indent="0" pn="section-3.5.2.2-2">As of May 2022, the following R
	<section title="Uses">	outing Types have been specified:</t>
	<t>This EH is employed for the IPsec suite <xref target="RFC4303"/>.</t>	<ul spacing="normal" bare="false" empty="false" indent="3" pn="secti
	</section>	on-3.5.2.2-3">
		<li pn="section-3.5.2.2-3.1">Type 0: Source Route (DEPRECATED) <xr
	<section title="Specification">	ef target="RFC2460" format="default" sectionFormat="of" derivedContent="RFC2460"
	<t>This EH is specified in <xref target="RFC4303"/>.</t>	/> <xref target="RFC5095" format="default" sectionFormat="of" derivedContent="RF
	</section>	C5095"/></li>
		<li pn="section-3.5.2.2-3.2">Type 1: Nimrod (DEPRECATED)</li>
	<section title="Specific Security Implications">	<li pn="section-3.5.2.2-3.3">Type 2: Type 2 Routing Header <xref t
	<t>Besides the general implications of IPv6 EHs, this EH could be employed to po	arget="RFC6275" format="default" sectionFormat="of" derivedContent="RFC6275"/></
	tentially perform a DoS attack at the destination system by wasting CPU resource	li>
	s in validating the contents of the packet.</t>	<li pn="section-3.5.2.2-3.4">Type 3: RPL Source Route Header <xref
	</section>	target="RFC6554" format="default" sectionFormat="of" derivedContent="RFC6554"/>
		</li>
	<section title="Operational and Interoperability Impact if Blocked">	<li pn="section-3.5.2.2-3.5">Type 4: Segment Routing Header (SRH)
	<t>Discarding packets that employ this EH would break IPsec deployments.</t>	<xref target="RFC8754" format="default" sectionFormat="of" derivedContent="RFC87
	</section>	54"/></li>
		<li pn="section-3.5.2.2-3.6">Types 5-252: Unassigned</li>
	<section title="Advice">	<li pn="section-3.5.2.2-3.7">Type 253: RFC3692-style Experiment 1
	<t>Intermediate systems should permit packets containing the Encapsulating Secur	<xref target="RFC4727" format="default" sectionFormat="of" derivedContent="RFC47
	ity Payload EH.</t>	27"/></li>
	</section>	<li pn="section-3.5.2.2-3.8">Type 254: RFC3692-style Experiment 2
	</section>	<xref target="RFC4727" format="default" sectionFormat="of" derivedContent="RFC47
		27"/></li>
	<section title="Authentication Header (Protocol Number=51)" anchor="proto51">	<li pn="section-3.5.2.2-3.9">Type 255: Reserved</li>
	<section title="Uses">	</ul>
	<t>The Authentication Header can be employed for provide authentication services	</section>
	in	<section numbered="true" toc="exclude" removeInRFC="false" pn="section
		-3.5.2.3">
		<name slugifiedName="name-specific-security-implicatio">Specific Sec
		urity Implications</name>
		<t indent="0" pn="section-3.5.2.3-1">The security implications of Ro
		uting Headers of Routing Type 0 have been discussed in detail in <xref target="B
		iondi-2007" format="default" sectionFormat="of" derivedContent="Biondi-2007"/> a
		nd <xref target="RFC5095" format="default" sectionFormat="of" derivedContent="RF
		C5095"/>. Routing Type 1 was never widely implemented. 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" sectionFormat="of" deri
		vedContent="RFC6275"/>, <xref target="RFC6554" format="default" sectionFormat="
		of" derivedContent="RFC6554"/>, and <xref target="RFC8754" format="default" sect
		ionFormat="of" derivedContent="RFC8754"/>, respectively.</t>
		</section>
		<section numbered="true" toc="exclude" removeInRFC="false" pn="section
		-3.5.2.4">
		<name slugifiedName="name-operational-and-interoperabi">Operational
		and Interoperability Impact If Blocked</name>
		<t indent="0" pn="section-3.5.2.4-1">Blocking packets containing Rou
		ting Headers of Routing Type 0 or Routing Type 1 has no operational implications
		, since both have been deprecated. Blocking packets containing Routing Headers o
		f Routing Type 2 would break Mobile IPv6. Packets containing Routing Headers of
		Routing Type 3 may be safely blocked at RPL domain boundaries, since such header
		s are employed within a single RPL domain. Blocking packets containing Routing H
		eaders of Routing Type 4 (SRH) will break Segment Routing (SR) deployments if th
		e filtering policy is enforced on packets being forwarded within an SR domain.</
		t>
		</section>
		<section numbered="true" toc="exclude" removeInRFC="false" pn="section
		-3.5.2.5">
		<name slugifiedName="name-advice-2">Advice</name>
		<t indent="0" pn="section-3.5.2.5-1">Intermediate systems should dis
		card packets containing Routing Headers of Routing Type 0, Routing Type 1, or Ro
		uting Type 3. Other Routing Types should be permitted, as required by <xref targ
		et="RFC7045" format="default" sectionFormat="of" derivedContent="RFC7045"/>.</t>
		</section>
		</section>
		<section anchor="proto44" numbered="true" toc="exclude" removeInRFC="fal
		se" pn="section-3.5.3">
		<name slugifiedName="name-fragment-header-protocol-nu">Fragment Header
		(Protocol Number=44)</name>
		<section numbered="true" toc="exclude" removeInRFC="false" pn="section
		-3.5.3.1">
		<name slugifiedName="name-uses-3">Uses</name>
		<t indent="0" pn="section-3.5.3.1-1">This EH provides the fragmentat
		ion and reassembly functionality for IPv6.</t>
		</section>
		<section numbered="true" toc="exclude" removeInRFC="false" pn="section
		-3.5.3.2">
		<name slugifiedName="name-specification-3">Specification</name>
		<t indent="0" pn="section-3.5.3.2-1">This EH is specified in <xref t
		arget="RFC8200" format="default" sectionFormat="of" derivedContent="RFC8200"/>.<
		/t>
		</section>
		<section numbered="true" toc="exclude" removeInRFC="false" pn="section
		-3.5.3.3">
		<name slugifiedName="name-specific-security-implication">Specific Se
		curity Implications</name>
		<t indent="0" pn="section-3.5.3.3-1">The security implications of th
		e Fragment Header range from DoS attacks (e.g., based on flooding a target with
		IPv6 fragments) to information leakage attacks <xref target="RFC7739" format="de
		fault" sectionFormat="of" derivedContent="RFC7739"/>.</t>
		</section>
		<section numbered="true" toc="exclude" removeInRFC="false" pn="section
		-3.5.3.4">
		<name slugifiedName="name-operational-and-interoperabil">Operational
		and Interoperability Impact If Blocked</name>
		<t indent="0" pn="section-3.5.3.4-1">Blocking packets that contain a
		Fragment Header will break any protocol that may rely on fragmentation (e.g., t
		he DNS <xref target="RFC1034" format="default" sectionFormat="of" derivedContent
		="RFC1034"/>). However, IP fragmentation is known to introduce fragility to Inte
		rnet communication <xref target="RFC8900" format="default" sectionFormat="of" de
		rivedContent="RFC8900"/>.</t>
		</section>
		<section numbered="true" toc="exclude" removeInRFC="false" pn="section
		-3.5.3.5">
		<name slugifiedName="name-advice-3">Advice</name>
		<t indent="0" pn="section-3.5.3.5-1">Intermediate systems should per
		mit packets that contain a Fragment Header.</t>
		</section>
		</section>
		<section anchor="proto50" numbered="true" toc="exclude" removeInRFC="fal
		se" pn="section-3.5.4">
		<name slugifiedName="name-encapsulating-security-payl">Encapsulating S
		ecurity Payload (Protocol Number=50)</name>
		<section numbered="true" toc="exclude" removeInRFC="false" pn="section
		-3.5.4.1">
		<name slugifiedName="name-uses-4">Uses</name>
		<t indent="0" pn="section-3.5.4.1-1">This EH is employed for the IPs
		ec suite <xref target="RFC4303" format="default" sectionFormat="of" derivedConte
		nt="RFC4303"/>.</t>
		</section>
		<section numbered="true" toc="exclude" removeInRFC="false" pn="section
		-3.5.4.2">
		<name slugifiedName="name-specification-4">Specification</name>
		<t indent="0" pn="section-3.5.4.2-1">This EH is specified in <xref t
		arget="RFC4303" format="default" sectionFormat="of" derivedContent="RFC4303"/>.<
		/t>
		</section>
		<section numbered="true" toc="exclude" removeInRFC="false" pn="section
		-3.5.4.3">
		<name slugifiedName="name-specific-security-implications">Specific S
		ecurity Implications</name>
		<t indent="0" pn="section-3.5.4.3-1">Besides the general implication
		s of IPv6 EHs, this EH could be employed to potentially perform a DoS attack at
		the destination system by wasting CPU resources in validating the contents of th
		e packet.</t>
		</section>
		<section numbered="true" toc="exclude" removeInRFC="false" pn="section
		-3.5.4.4">
		<name slugifiedName="name-operational-and-interoperabili">Operationa
		l and Interoperability Impact If Blocked</name>
		<t indent="0" pn="section-3.5.4.4-1">Discarding packets that employ
		this EH would break IPsec deployments.</t>
		</section>
		<section numbered="true" toc="exclude" removeInRFC="false" pn="section
		-3.5.4.5">
		<name slugifiedName="name-advice-4">Advice</name>
		<t indent="0" pn="section-3.5.4.5-1">Intermediate systems should per
		mit packets containing the Encapsulating Security Payload EH.</t>
		</section>
		</section>
		<section anchor="proto51" numbered="true" toc="exclude" removeInRFC="fal
		se" pn="section-3.5.5">
		<name slugifiedName="name-authentication-header-proto">Authentication
		Header (Protocol Number=51)</name>
		<section numbered="true" toc="exclude" removeInRFC="false" pn="section
		-3.5.5.1">
		<name slugifiedName="name-uses-5">Uses</name>
		<t indent="0" pn="section-3.5.5.1-1">The Authentication Header can b
		e employed to provide authentication services in
	IPv4 and IPv6.</t>	IPv4 and IPv6.</t>

	</section>	</section>
		<section numbered="true" toc="exclude" removeInRFC="false" pn="section
	<section title="Specification">	-3.5.5.2">
	<t>This EH is specified in <xref target="RFC4302"/>.</t>	<name slugifiedName="name-specification-5">Specification</name>
	</section>	<t indent="0" pn="section-3.5.5.2-1">This EH is specified in <xref t
		arget="RFC4302" format="default" sectionFormat="of" derivedContent="RFC4302"/>.<
	<section title="Specific Security Implications">	/t>
	<t>Besides the general implications of IPv6 EHs, this EH could be employed to po	</section>
	tentially perform a DoS attack at the destination system by wasting CPU resource	<section numbered="true" toc="exclude" removeInRFC="false" pn="section
	s in validating the contents of the packet.</t>	-3.5.5.3">
	</section>	<name slugifiedName="name-specific-security-implications-2">Specific
		Security Implications</name>
	<section title="Operational and Interoperability Impact if Blocked">	<t indent="0" pn="section-3.5.5.3-1">Besides the general implication
	<t>Discarding packets that employ this EH would break IPsec deployments.</t>	s of IPv6 EHs, this EH could be employed to potentially perform a DoS attack at
	</section>	the destination system by wasting CPU resources in validating the contents of th
		e packet.</t>
	<section title="Advice">	</section>
	<t>Intermediate systems should permit packets containing an Authentication Heade	<section numbered="true" toc="exclude" removeInRFC="false" pn="section
	r.</t>	-3.5.5.4">
	</section>	<name slugifiedName="name-operational-and-interoperabilit">Operation
	</section>	al and Interoperability Impact If Blocked</name>
		<t indent="0" pn="section-3.5.5.4-1">Discarding packets that employ
	<section title="Destination Options for IPv6 (Protocol Number=60)" anchor="proto	this EH would break IPsec deployments.</t>
	60">	</section>
	<section title="Uses">	<section numbered="true" toc="exclude" removeInRFC="false" pn="section
	<t>The Destination Options header is used to carry optional information that nee	-3.5.5.5">
	ds be examined only by a packet's destination node(s).</t>	<name slugifiedName="name-advice-5">Advice</name>
	</section>	<t indent="0" pn="section-3.5.5.5-1">Intermediate systems should per
		mit packets containing an Authentication Header.</t>
	<section title="Specification">	</section>
	<t>This EH is specified in <xref target="RFC8200"/>. As of May 2022, the followi	</section>
	ng options have been specified for this EH:	<section anchor="proto60" numbered="true" toc="exclude" removeInRFC="fal
		se" pn="section-3.5.6">
	<list style="symbols">	<name slugifiedName="name-destination-options-protoco">Destination Opt
	<t>Type 0x00: Pad1 <xref target="RFC8200"/></t>	ions (Protocol Number=60)</name>
	<t>Type 0x01: PadN <xref target="RFC8200"/></t>	<section numbered="true" toc="exclude" removeInRFC="false" pn="section
	<t>Type 0x04: Tunnel Encapsulation Limit <xref target="RFC2473"/></t>	-3.5.6.1">
	<t>Type 0x0F: IPv6 Performance and Diagnostic Metrics (PDM) <xref target="RFC825	<name slugifiedName="name-uses-6">Uses</name>
	0"/></t>	<t indent="0" pn="section-3.5.6.1-1">The Destination Options (DO) he
	<t>Type 0x4D: (Deprecated)</t>	ader is used to carry optional information that needs be examined only by a pack
		et's destination node(s).</t>
	<t>Type 0xC9: Home Address <xref target="RFC6275"/></t>	</section>
	<t>Type 0x8A: Endpoint Identification (Deprecated) <xref target="draft-ietf-nimr	<section numbered="true" toc="exclude" removeInRFC="false" pn="section
	od-eid"/></t>	-3.5.6.2">
		<name slugifiedName="name-specification-6">Specification</name>
	<t>Type 0x8B: ILNP Nonce <xref target="RFC6744"/></t>	<t indent="0" pn="section-3.5.6.2-1">This EH is specified in <xref t
	<t>Type 0x8C: Line-Identification Option <xref target="RFC6788"/></t>	arget="RFC8200" format="default" sectionFormat="of" derivedContent="RFC8200"/>.
	<t>Type 0x1E: RFC3692-style Experiment <xref target="RFC4727"/></t>	As of May 2022, the following options have been specified for this EH:
	<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" bare="false" empty="false" indent="3" pn="secti
		on-3.5.6.2-2">
	<section title="Specific Security Implications">	<li pn="section-3.5.6.2-2.1">Type 0x00: Pad1 <xref target="RFC8200
	<t>No security implications are known, other than the general implications of IP	" format="default" sectionFormat="of" derivedContent="RFC8200"/></li>
	v6 EHs. For a discussion of possible security implications of specific options s	<li pn="section-3.5.6.2-2.2">Type 0x01: PadN <xref target="RFC8200
	pecified for the DO header, please see the <xref target="opt-filtering"/>.</t>	" format="default" sectionFormat="of" derivedContent="RFC8200"/></li>
	</section>	<li pn="section-3.5.6.2-2.3">Type 0x04: Tunnel Encapsulation Limit
		<xref target="RFC2473" format="default" sectionFormat="of" derivedContent="RFC2
	<section title="Operational and Interoperability Impact if Blocked">	473"/></li>
	<t>Discarding packets that contain a Destination Options header would break prot	<li pn="section-3.5.6.2-2.4">Type 0x0F: IPv6 Performance and Diagn
	ocols that rely on this EH type for conveying information, including protocols s	ostic Metrics (PDM) <xref target="RFC8250" format="default" sectionFormat="of" d
	uch as ILNP <xref target="RFC6740"/> and Mobile IPv6 <xref target="RFC6275"/>, a	erivedContent="RFC8250"/></li>
	nd IPv6 tunnels that employ the Tunnel Encapsulation Limit option.</t>	<li pn="section-3.5.6.2-2.5">Type 0x4D: (Deprecated)</li>
	</section>	<li pn="section-3.5.6.2-2.6">Type 0xC9: Home Address <xref target=
		"RFC6275" format="default" sectionFormat="of" derivedContent="RFC6275"/></li>
	<section title="Advice">	<li pn="section-3.5.6.2-2.7">Type 0x8A: Endpoint Identification (D
	<t>Intermediate systems should permit packets that contain a Destination Options	eprecated) <xref target="NIMROD-EID" format="default" sectionFormat="of" derived
	Header.</t>	Content="NIMROD-EID"/></li>
	</section>	<li pn="section-3.5.6.2-2.8">Type 0x8B: ILNP Nonce <xref target="R
	</section>	FC6744" format="default" sectionFormat="of" derivedContent="RFC6744"/></li>
		<li pn="section-3.5.6.2-2.9">Type 0x8C: Line-Identification Option
	<section title="Mobility Header (Protocol Number=135)" anchor="proto135">	<xref target="RFC6788" format="default" sectionFormat="of" derivedContent="RFC6
	<section title="Uses">	788"/></li>
	<t>The Mobility Header is an EH used by mobile nodes, correspondent nodes, and h	<li pn="section-3.5.6.2-2.10">Type 0x1E: RFC3692-style Experiment
	ome agents in all messaging related to the creation and management of bindings i	<xref target="RFC4727" format="default" sectionFormat="of" derivedContent="RFC47
	n Mobile IPv6.</t>	27"/></li>
	</section>	<li pn="section-3.5.6.2-2.11">Type 0x3E: RFC3692-style Experiment
		<xref target="RFC4727" format="default" sectionFormat="of" derivedContent="RFC47
	<section title="Specification">	27"/></li>
	<t>This EH is specified in <xref target="RFC6275"/>.</t>	<li pn="section-3.5.6.2-2.12">Type 0x5E: RFC3692-style Experiment
	</section>	<xref target="RFC4727" format="default" sectionFormat="of" derivedContent="RFC47
		27"/></li>
	<section title="Specific Security Implications">	<li pn="section-3.5.6.2-2.13">Type 0x7E: RFC3692-style Experiment
	<t>A thorough security assessment of the security implications of the Mobility H	<xref target="RFC4727" format="default" sectionFormat="of" derivedContent="RFC47
	eader and related mechanisms can be found in Section 15 of <xref target="RFC6275	27"/></li>
	"/>.</t>	<li pn="section-3.5.6.2-2.14">Type 0x9E: RFC3692-style Experiment
	</section>	<xref target="RFC4727" format="default" sectionFormat="of" derivedContent="RFC47
		27"/></li>
	<section title="Operational and Interoperability Impact if Blocked">	<li pn="section-3.5.6.2-2.15">Type 0xBE: RFC3692-style Experiment
	<t>Discarding packets containing this EH would break Mobile IPv6.</t>	<xref target="RFC4727" format="default" sectionFormat="of" derivedContent="RFC47
	</section>	27"/></li>
		<li pn="section-3.5.6.2-2.16">Type 0xDE: RFC3692-style Experiment
	<section title="Advice">	<xref target="RFC4727" format="default" sectionFormat="of" derivedContent="RFC47
	<t>Intermediate systems should permit packets containing this EH.</t>	27"/></li>
	</section>	<li pn="section-3.5.6.2-2.17">Type 0xFE: RFC3692-style Experiment
	</section>	<xref target="RFC4727" format="default" sectionFormat="of" derivedContent="RFC47
		27"/></li>
	<section title="Host Identity Protocol (Protocol Number=139)" anchor="proto139">	</ul>
	<section title="Uses">	</section>
	<t>This EH is employed with the Host Identity Protocol (HIP), a protocol that al	<section numbered="true" toc="exclude" removeInRFC="false" pn="section
	lows consenting hosts to securely establish and maintain shared IP-layer state,	-3.5.6.3">
	allowing separation of the identifier and locator roles of IP addresses, thereby	<name slugifiedName="name-specific-security-implications-3">Specific
	enabling continuity of communications across IP address changes.</t>	Security Implications</name>
	</section>	<t indent="0" pn="section-3.5.6.3-1">No security implications are kn
		own, other than the general security implications of IPv6 EHs. For a discussion
	<section title="Specification">	of possible security implications of specific options specified for the DO heade
	<t>This EH is specified in <xref target="RFC7401"/>.</t>	r, please see <xref target="opt-filtering" format="default" sectionFormat="of" d
	</section>	erivedContent="Section 4.4"/>.</t>
		</section>
	<section title="Specific Security Implications">	<section numbered="true" toc="exclude" removeInRFC="false" pn="section
	<t>The security implications of the HIP header are discussed in detail in Sectio	-3.5.6.4">
	n 8 of <xref target="RFC6275"/>.</t>	<name slugifiedName="name-operational-and-interoperability">Operatio
	</section>	nal and Interoperability Impact If Blocked</name>
		<t indent="0" pn="section-3.5.6.4-1">Discarding packets that contain
	<section title="Operational and Interoperability Impact if Blocked">	a Destination Options header would break protocols that rely on this EH type fo
	<t>Discarding packets that contain the Host Identity Protocol would break HIP de	r conveying information (such as the Identifier-Locator Network Protocol (ILNP)
	ployments.</t>	<xref target="RFC6740" format="default" sectionFormat="of" derivedContent="RFC67
	</section>	40"/> and Mobile IPv6 <xref target="RFC6275" format="default" sectionFormat="of"
		derivedContent="RFC6275"/>), as well as IPv6 tunnels that employ the Tunnel Enc
	<section title="Advice">	apsulation Limit option <xref target="RFC2473" format="default" sectionFormat="o
	<t>Intermediate systems should permit packets that contain a Host Identity Proto	f" derivedContent="RFC2473"/>.</t>
	col EH.</t>	</section>
	</section>	<section numbered="true" toc="exclude" removeInRFC="false" pn="section
	</section>	-3.5.6.5">
		<name slugifiedName="name-advice-6">Advice</name>
	<section title="Shim6 Protocol (Protocol Number=140)" anchor="proto140">	<t indent="0" pn="section-3.5.6.5-1">Intermediate systems should per
	<section title="Uses">	mit packets that contain a Destination Options header.</t>
	<t>This EH is employed by the Shim6 <xref target="RFC5533"/> Protocol.</t>	</section>
	</section>	</section>
		<section anchor="proto135" numbered="true" toc="exclude" removeInRFC="fa
	<section title="Specification">	lse" pn="section-3.5.7">
	<t>This EH is specified in <xref target="RFC5533"/>.</t>	<name slugifiedName="name-mobility-header-protocol-nu">Mobility Header
	</section>	(Protocol Number=135)</name>
		<section numbered="true" toc="exclude" removeInRFC="false" pn="section
	<section title="Specific Security Implications">	-3.5.7.1">
	<t>The specific security implications are discussed in detail in Section 16 of <	<name slugifiedName="name-uses-7">Uses</name>
	xref target="RFC5533"/>.</t>	<t indent="0" pn="section-3.5.7.1-1">The Mobility Header is an EH us
	</section>	ed by mobile nodes, correspondent nodes, and home agents in all messaging relate
		d to the creation and management of bindings in Mobile IPv6.</t>
	<section title="Operational and Interoperability Impact if Blocked">	</section>
	<t>Discarding packets that contain this EH will break Shim6.</t>	<section numbered="true" toc="exclude" removeInRFC="false" pn="section
	</section>	-3.5.7.2">
		<name slugifiedName="name-specification-7">Specification</name>
	<section title="Advice">	<t indent="0" pn="section-3.5.7.2-1">This EH is specified in <xref t
	<t>Intermediate systems should permit packets containing this EH.</t>	arget="RFC6275" format="default" sectionFormat="of" derivedContent="RFC6275"/>.<
	</section>	/t>
	</section>	</section>
		<section numbered="true" toc="exclude" removeInRFC="false" pn="section
	<section title="Use for experimentation and testing (Protocol Numbers=253 and 25	-3.5.7.3">
	4)" anchor="proto253254">	<name slugifiedName="name-specific-security-implications-4">Specific
	<section title="Uses">	Security Implications</name>
	<t>These IPv6 EHs are employed for performing RFC3692-Style experiments (see <xr	<t indent="0" pn="section-3.5.7.3-1">A thorough security assessment
	ef target="RFC3692"/> for details).</t>	of the security implications of the Mobility Header and related mechanisms can b
	</section>	e found in <xref target="RFC6275" sectionFormat="of" section="15" format="defaul
		t" derivedLink="https://rfc-editor.org/rfc/rfc6275#section-15" derivedContent="R
	<section title="Specification">	FC6275"/>.</t>
	<t>These EHs are specified in <xref target="RFC3692"/> and <xref target="RFC4727	</section>
	"/>.</t>	<section numbered="true" toc="exclude" removeInRFC="false" pn="section
	</section>	-3.5.7.4">
		<name slugifiedName="name-operational-and-interoperability-">Operati
	<section title="Specific Security Implications">	onal and Interoperability Impact If Blocked</name>
	<t>The security implications of these EHs will depend on their specific use.</t>	<t indent="0" pn="section-3.5.7.4-1">Discarding packets containing t
	</section>	his EH would break Mobile IPv6.</t>
		</section>
	<section title="Operational and Interoperability Impact if Blocked">	<section numbered="true" toc="exclude" removeInRFC="false" pn="section
	<t>For obvious reasons, discarding packets that contain these EHs limits the abi	-3.5.7.5">
	lity to perform legitimate experiments across IPv6 routers.	<name slugifiedName="name-advice-7">Advice</name>
		<t indent="0" pn="section-3.5.7.5-1">Intermediate systems should per
		mit packets that contain a Mobility Header.</t>
		</section>
		</section>
		<section anchor="proto139" numbered="true" toc="exclude" removeInRFC="fa
		lse" pn="section-3.5.8">
		<name slugifiedName="name-host-identity-protocol-prot">Host Identity P
		rotocol (Protocol Number=139)</name>
		<section numbered="true" toc="exclude" removeInRFC="false" pn="section
		-3.5.8.1">
		<name slugifiedName="name-uses-8">Uses</name>
		<t indent="0" pn="section-3.5.8.1-1">This EH is employed with the Ho
		st Identity Protocol (HIP), which is a protocol that allows consenting hosts to
		securely establish and maintain shared IP-layer state, allowing the separation o
		f the identifier and locator roles of IP addresses, thereby enabling continuity
		of communications across IP address changes.</t>
		</section>
		<section numbered="true" toc="exclude" removeInRFC="false" pn="section
		-3.5.8.2">
		<name slugifiedName="name-specification-8">Specification</name>
		<t indent="0" pn="section-3.5.8.2-1">This EH is specified in <xref t
		arget="RFC7401" format="default" sectionFormat="of" derivedContent="RFC7401"/>.<
		/t>
		</section>
		<section numbered="true" toc="exclude" removeInRFC="false" pn="section
		-3.5.8.3">
		<name slugifiedName="name-specific-security-implications-5">Specific
		Security Implications</name>
		<t indent="0" pn="section-3.5.8.3-1">The security implications of th
		e HIP header are discussed in detail in <xref target="RFC7401" sectionFormat="of
		" section="8" format="default" derivedLink="https://rfc-editor.org/rfc/rfc7401#s
		ection-8" derivedContent="RFC7401"/>.</t>
		</section>
		<section numbered="true" toc="exclude" removeInRFC="false" pn="section
		-3.5.8.4">
		<name slugifiedName="name-operational-and-interoperability-i">Operat
		ional and Interoperability Impact If Blocked</name>
		<t indent="0" pn="section-3.5.8.4-1">Discarding packets that contain
		a HIP header would break HIP deployments.</t>
		</section>
		<section numbered="true" toc="exclude" removeInRFC="false" pn="section
		-3.5.8.5">
		<name slugifiedName="name-advice-8">Advice</name>
		<t indent="0" pn="section-3.5.8.5-1">Intermediate systems should per
		mit packets that contain a HIP header.</t>
		</section>
		</section>
		<section anchor="proto140" numbered="true" toc="exclude" removeInRFC="fa
		lse" pn="section-3.5.9">
		<name slugifiedName="name-shim6-protocol-protocol-num">Shim6 Protocol
		(Protocol Number=140)</name>
		<section numbered="true" toc="exclude" removeInRFC="false" pn="section
		-3.5.9.1">
		<name slugifiedName="name-uses-9">Uses</name>
		<t indent="0" pn="section-3.5.9.1-1">This EH is employed by the Shim
		6 protocol <xref target="RFC5533" format="default" sectionFormat="of" derivedCon
		tent="RFC5533"/>.</t>
		</section>
		<section numbered="true" toc="exclude" removeInRFC="false" pn="section
		-3.5.9.2">
		<name slugifiedName="name-specification-9">Specification</name>
		<t indent="0" pn="section-3.5.9.2-1">This EH is specified in <xref t
		arget="RFC5533" format="default" sectionFormat="of" derivedContent="RFC5533"/>.<
		/t>
		</section>
		<section numbered="true" toc="exclude" removeInRFC="false" pn="section
		-3.5.9.3">
		<name slugifiedName="name-specific-security-implications-6">Specific
		Security Implications</name>
		<t indent="0" pn="section-3.5.9.3-1">The specific security implicati
		ons are discussed in detail in <xref target="RFC5533" sectionFormat="of" section
		="16" format="default" derivedLink="https://rfc-editor.org/rfc/rfc5533#section-1
		6" derivedContent="RFC5533"/>.</t>
		</section>
		<section numbered="true" toc="exclude" removeInRFC="false" pn="section
		-3.5.9.4">
		<name slugifiedName="name-operational-and-interoperability-im">Opera
		tional and Interoperability Impact If Blocked</name>
		<t indent="0" pn="section-3.5.9.4-1">Discarding packets that contain
		this EH will break Shim6.</t>
		</section>
		<section numbered="true" toc="exclude" removeInRFC="false" pn="section
		-3.5.9.5">
		<name slugifiedName="name-advice-9">Advice</name>
		<t indent="0" pn="section-3.5.9.5-1">Intermediate systems should per
		mit packets containing this EH.</t>
		</section>
		</section>
		<section anchor="proto253254" numbered="true" toc="exclude" removeInRFC=
		"false" pn="section-3.5.10">
		<name slugifiedName="name-use-for-experimentation-and">Use for Experim
		entation and Testing (Protocol Numbers=253 and 254)</name>
		<section numbered="true" toc="exclude" removeInRFC="false" pn="section
		-3.5.10.1">
		<name slugifiedName="name-uses-10">Uses</name>
		<t indent="0" pn="section-3.5.10.1-1">These IPv6 EHs are employed fo
		r performing RFC3692-style experiments (see <xref target="RFC3692" format="defau
		lt" sectionFormat="of" derivedContent="RFC3692"/> for details).</t>
		</section>
		<section numbered="true" toc="exclude" removeInRFC="false" pn="section
		-3.5.10.2">
		<name slugifiedName="name-specification-10">Specification</name>
		<t indent="0" pn="section-3.5.10.2-1">These EHs are specified in <xr
		ef target="RFC3692" format="default" sectionFormat="of" derivedContent="RFC3692"
		/> and <xref target="RFC4727" format="default" sectionFormat="of" derivedContent
		="RFC4727"/>.</t>
		</section>
		<section numbered="true" toc="exclude" removeInRFC="false" pn="section
		-3.5.10.3">
		<name slugifiedName="name-specific-security-implications-7">Specific
		Security Implications</name>
		<t indent="0" pn="section-3.5.10.3-1">The security implications of t
		hese EHs will depend on their specific use.</t>
		</section>
		<section numbered="true" toc="exclude" removeInRFC="false" pn="section
		-3.5.10.4">
		<name slugifiedName="name-operational-and-interoperability-im-2">Ope
		rational and Interoperability Impact If Blocked</name>
		<t indent="0" pn="section-3.5.10.4-1">For obvious reasons, discardin
		g packets that contain these EHs limits the ability to perform legitimate experi
		ments across IPv6 routers.
	</t>	</t>

	</section>	</section>
		<section numbered="true" toc="exclude" removeInRFC="false" pn="section
	<section title="Advice">	-3.5.10.5">
	<t>Operators should determine according to their own circumstances whether to di	<name slugifiedName="name-advice-10">Advice</name>
	scard packets containing these EHs.</t>	<t indent="0" pn="section-3.5.10.5-1">Operators should determine, ac
	<!--	cording to their own circumstances, whether to discard packets containing these
	<t>Intermediate systems should discard packets containing these EHs. Only in spe	EHs.</t>
	cific scenarios in which RFC3692-Style experiments are to be performed should th	</section>
	ese EHs be permitted.</t> -->	</section>
	</section>	</section>
	</section>	<section anchor="unknown-headers" numbered="true" toc="include" removeInRF
		C="false" pn="section-3.6">
	</section>	<name slugifiedName="name-advice-on-the-handling-of-p">Advice on the Han
	<section title="Advice on the Handling of Packets with Unknown IPv6 Extension He	dling of Packets with Unknown IPv6 Extension Headers</name>
	aders" anchor="unknown-headers">	<t indent="0" pn="section-3.6-1">We refer to IPv6 EHs that have not been
	<t>We refer to IPv6 EHs that have not been assigned an Internet Protocol Number	assigned an Internet Protocol number by IANA (and marked as such) in <xref targ
	by IANA (and marked as such) in <xref target="IANA-PROTOCOLS"/> as "unknown IPv6	et="IANA-PROTOCOLS" format="default" sectionFormat="of" derivedContent="IANA-PRO
	extension headers" ("unknown IPv6 EHs").	TOCOLS"/> as "unknown IPv6 Extension Headers" ("unknown IPv6 EHs").
	</t>	</t>

		<section numbered="true" toc="exclude" removeInRFC="false" pn="section-3
	<section title="Uses">	.6.1">
	<t>New IPv6 EHs may be specified as part of future extensions to the IPv6 protoc	<name slugifiedName="name-uses-11">Uses</name>
	ol.	<t indent="0" pn="section-3.6.1-1">New IPv6 EHs may be specified as pa
		rt of future extensions to the IPv6 protocol.
	</t>	</t>

		<t indent="0" pn="section-3.6.1-2">Since IPv6 EHs and upper-layer prot
	<t>Since IPv6 EHs and Upper-layer protocols employ the same namespace, it is imp	ocols employ the same namespace, it is impossible to tell whether an unknown Int
	ossible to tell whether an unknown "Internet Protocol Number" is being employed	ernet Protocol number is being employed for an IPv6 EH or an upper-layer protoco
	for an IPv6 EH or an Upper-Layer protocol.	l.
	</t>	</t>

		</section>
	</section>	<section numbered="true" toc="exclude" removeInRFC="false" pn="section-3
		.6.2">
	<section title="Specification">	<name slugifiedName="name-specification-11">Specification</name>
	<t>The processing of unknown IPv6 EHs is specified in <xref target="RFC7045"/>.<	<t indent="0" pn="section-3.6.2-1">The processing of unknown IPv6 EHs
	/t>	is specified in <xref target="RFC7045" format="default" sectionFormat="of" deriv
	</section>	edContent="RFC7045"/>.</t>
		</section>
	<section title="Specific Security Implications">	<section numbered="true" toc="exclude" removeInRFC="false" pn="section-3
	<t>For obvious reasons, it is impossible to determine specific security implicat	.6.3">
	ions of unknown IPv6 EHs.</t>	<name slugifiedName="name-specific-security-implications-8">Specific S
	</section>	ecurity Implications</name>
		<t indent="0" pn="section-3.6.3-1">For obvious reasons, it is impossib
	<section title="Operational and Interoperability Impact if Blocked">	le to determine specific security implications of unknown IPv6 EHs.</t>
	<t>As noted in <xref target="RFC7045"/>, discarding unknown IPv6 EHs may slow do	</section>
	wn the deployment of new IPv6 EHs and transport protocols. The corresponding IAN	<section numbered="true" toc="exclude" removeInRFC="false" pn="section-3
	A registry (<xref target="IANA-PROTOCOLS"/>) should be monitored such that filte	.6.4">
	ring rules are updated as new IPv6 EHs are standardized.</t>	<name slugifiedName="name-operational-and-interoperability-im-3">Opera
		tional and Interoperability Impact If Blocked</name>
	<t>We note that since IPv6 EHs and upper-layer protocols share the same numberin	<t indent="0" pn="section-3.6.4-1">As noted in <xref target="RFC7045"
	g space, discarding unknown IPv6 EHs may result in packets encapsulating unknown	format="default" sectionFormat="of" derivedContent="RFC7045"/>, discarding unkno
	upper-layer protocols being discarded.	wn IPv6 EHs may slow down the deployment of new IPv6 EHs and transport protocols
		. The corresponding IANA registry, which is <xref target="IANA-PROTOCOLS" format
		="default" sectionFormat="of" derivedContent="IANA-PROTOCOLS"/>, should be monit
		ored such that filtering rules are updated as new IPv6 EHs are standardized.</t>
		<t indent="0" pn="section-3.6.4-2">We note that since IPv6 EHs and upp
		er-layer protocols share the same numbering space, discarding unknown IPv6 EHs m
		ay result in packets encapsulating unknown upper-layer protocols being discarded
		.
	</t>	</t>

	</section>	</section>
		<section numbered="true" toc="exclude" removeInRFC="false" pn="section-3
	<section title="Advice">	.6.5">
	<t>Operators should determine according to their own circumstances whether to di	<name slugifiedName="name-advice-11">Advice</name>
	scard packets containing unknown IPv6 EHs.</t>	<t indent="0" pn="section-3.6.5-1">Operators should determine, accordi
	</section>	ng to their own circumstances, whether to discard packets containing unknown IPv
		6 EHs.</t>
	</section>	</section>
		</section>
	</section>	</section>
		<section anchor="ipv6-options-discussion" numbered="true" toc="include" remo
	<section title="IPv6 Options" anchor="ipv6-options-discussion">	veInRFC="false" pn="section-4">
	<section title="General Discussion" anchor="ipv6-options-general-discussion">	<name slugifiedName="name-ipv6-options">IPv6 Options</name>
	<t>The following subsections describe specific security implications of differen	<section anchor="ipv6-options-general-discussion" numbered="true" toc="inc
	t IPv6 options, and provide advice regarding filtering packets that contain such	lude" removeInRFC="false" pn="section-4.1">
	options.	<name slugifiedName="name-general-discussion-2">General Discussion</name
		>
		<t indent="0" pn="section-4.1-1">The following subsections describe spec
		ific security implications of different IPv6 options and provide advice regardin
		g filtering packets that contain such options.
	</t>	</t>

	</section>	</section>
		<section anchor="ipv6-options-general-implications" numbered="true" toc="i
	<section title="General Security Implications of IPv6 Options" anchor="ipv6-opti	nclude" removeInRFC="false" pn="section-4.2">
	ons-general-implications">	<name slugifiedName="name-general-security-implication">General Security
	<t>The general security implications of IPv6 options are closely related to thos	Implications of IPv6 Options</name>
	e discussed in <xref target="ipv6-eh-general-implications"/> for IPv6 EHs. Essen	<t indent="0" pn="section-4.2-1">The general security implications of IP
	tially, packets that contain IPv6 options might need to be processed by an IPv6	v6 options are closely related to those discussed in <xref target="ipv6-eh-gener
	router's general-purpose CPU,and hence could present a DDoS risk to that router'	al-implications" format="default" sectionFormat="of" derivedContent="Section 3.2
	s general-purpose CPU (and thus to the router itself). For some architectures, a	"/> for IPv6 EHs. Essentially, packets that contain IPv6 options might need to b
	possible mitigation would be to rate-limit the packets that are to be processed	e processed by an IPv6 router's general-purpose CPU and, hence, could present a
	by the general-purpose CPU (see e.g. <xref target="Cisco-EH"/>).</t>	Distributed Denial-of-Service (DDoS) risk to that router's general-purpose CPU (
	</section>	and thus to the router itself). For some architectures, a possible mitigation wo
		uld be to rate-limit the packets that are to be processed by the general-purpose
	<section title="Summary of Advice on the Handling of IPv6 Packets with Specific	CPU (see, e.g., <xref target="Cisco-EH" format="default" sectionFormat="of" der
	IPv6 Extension Headers">	ivedContent="Cisco-EH"/>).</t>
	<t>This section summarizes the advice provided in <xref target="advice-ehs"/>, p	</section>
	roviding references to the specific sections in which a detailed analysis can be	<section numbered="true" toc="include" removeInRFC="false" pn="section-4.3
	found.</t>	">
		<name slugifiedName="name-summary-of-advice-on-the-hand">Summary of Advi
	<texttable title="Summary of Advice on the Handling of IPv6 Packets with Spe	ce on the Handling of IPv6 Packets with Specific IPv6 Options</name>
	cific IPv6 options" style="all" anchor="option-table">	<t indent="0" pn="section-4.3-1">This section summarizes the advice prov
	<ttcol align="center">Option</ttcol>	ided in <xref target="opt-filtering" format="default" sectionFormat="of" derived
	<ttcol align="center">Filtering policy</ttcol>	Content="Section 4.4"/>, and it includes references to the specific sections in
	<ttcol align="center">Reference</ttcol>	which a detailed analysis can be found.</t>
	<c>Pad1 (Type=0x00)</c><c>Permit</c><c><xref target="x00"/></c>	<table anchor="option-table" align="center" pn="table-2">
	<c>PadN (Type=0x01)</c><c>Permit</c><c><xref target="x01"/></c>	<name slugifiedName="name-summary-of-advice-on-the-handl">Summary of A
	<c>Tunnel Encapsulation Limit (Type=0x04)</c><c>Permit</c><c><xref target="x04"/	dvice on the Handling of IPv6 Packets with Specific IPv6 Options</name>
	></c>	<thead>
	<c>Router Alert (Type=0x05)</c><c>Permit based on needed functionality</c><c><xr	<tr>
	ef target="x05"/></c>	<th align="center" colspan="1" rowspan="1">Option</th>
	<c>CALIPSO (Type=0x07)</c><c>Permit based on needed functionality</c><c><xref ta	<th align="center" colspan="1" rowspan="1">Filtering Policy</th>
	rget="x07"/></c>	<th align="center" colspan="1" rowspan="1">Reference</th>
	<c>SMF_DPD (Type=0x08)</c><c>Permit based on needed functionality</c><c><xref ta	</tr>
	rget="x08"/></c>	</thead>
	<c>PDM Option (Type=0x0F)</c><c>Permit</c><c><xref target="x0F"/></c>	<tbody>
	<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>	<td align="center" colspan="1" rowspan="1">Pad1 (Type=0x00)</td>
	<c>Deprecated (Type=0x4D)</c><c>Drop</c><c><xref target="x4D"/></c>	<td align="center" colspan="1" rowspan="1">Permit</td>
	<c>MPL Option (Type=0x6D)</c><c>Permit</c><c><xref target="x6D"/></c>	<td align="center" colspan="1" rowspan="1">
	<c>Jumbo Payload (Type=0C2)</c><c>Permit based on needed functionality</c><c><xr	<xref target="x00" format="default" sectionFormat="of" derivedCo
	ef target="xC2"/></c>	ntent="Section 4.4.1"/></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" colspan="1" rowspan="1">PadN (Type=0x01)</td>
	<c>ILNP Nonce (Type=0x8B)</c><c>Permit</c><c><xref target="x8B"/></c>	<td align="center" colspan="1" rowspan="1">Permit</td>
	<c>Line-Identification Option (Type=0x8C)</c><c>Drop</c><c><xref target="x8C"/><	<td align="center" colspan="1" rowspan="1">
	/c>	<xref target="x01" format="default" sectionFormat="of" derivedCo
	<c>Home Address (Type=0xC9)</c><c>Permit</c><c><xref target="xC9"/></c>	ntent="Section 4.4.2"/></td>
	<c>IP_DFF (Type=0xEE)</c><c>Permit based on needed functionality</c><c><xref tar	</tr>
	get="xEE"/></c>	<tr>
	<c>RFC3692-style Experiment (Types = 0x1E, 0x3E, 0x5E, 0x7E, 0x9E, 0xBE, 0xDE, 0	<td align="center" colspan="1" rowspan="1">Tunnel Encapsulation Li
	xFE)</c><c>Permit based on needed functionality</c><c><xref target="x1E"/></c>	mit (Type=0x04)</td>
		<td align="center" colspan="1" rowspan="1">Permit</td>
	</texttable>	<td align="center" colspan="1" rowspan="1">
		<xref target="x04" format="default" sectionFormat="of" derivedCo
	</section>	ntent="Section 4.4.3"/></td>
		</tr>
	<section title="Advice on the Handling of Packets with Specific IPv6 Options" an	<tr>
	chor="opt-filtering">	<td align="center" colspan="1" rowspan="1">Router Alert (Type=0x05
	<t>The following subsections contain a description of each of the IPv6 options t	)</td>
	hat have so far been specified, a summary of the security implications of each o	<td align="center" colspan="1" rowspan="1">Permit based on needed
	f such options, a discussion of possible	functionality</td>
		<td align="center" colspan="1" rowspan="1">
		<xref target="x05" format="default" sectionFormat="of" derivedCo
		ntent="Section 4.4.4"/></td>
		</tr>
		<tr>
		<td align="center" colspan="1" rowspan="1">CALIPSO (Type=0x07)</td
		>
		<td align="center" colspan="1" rowspan="1">Permit based on needed
		functionality</td>
		<td align="center" colspan="1" rowspan="1">
		<xref target="x07" format="default" sectionFormat="of" derivedCo
		ntent="Section 4.4.5"/></td>
		</tr>
		<tr>
		<td align="center" colspan="1" rowspan="1">SMF_DPD (Type=0x08)</td
		>
		<td align="center" colspan="1" rowspan="1">Permit based on needed
		functionality</td>
		<td align="center" colspan="1" rowspan="1">
		<xref target="x08" format="default" sectionFormat="of" derivedCo
		ntent="Section 4.4.6"/></td>
		</tr>
		<tr>
		<td align="center" colspan="1" rowspan="1">PDM Option (Type=0x0F)<
		/td>
		<td align="center" colspan="1" rowspan="1">Permit</td>
		<td align="center" colspan="1" rowspan="1">
		<xref target="x0F" format="default" sectionFormat="of" derivedCo
		ntent="Section 4.4.7"/></td>
		</tr>
		<tr>
		<td align="center" colspan="1" rowspan="1">RPL Option (Type=0x23)<
		/td>
		<td align="center" colspan="1" rowspan="1">Permit</td>
		<td align="center" colspan="1" rowspan="1">
		<xref target="x23" format="default" sectionFormat="of" derivedCo
		ntent="Section 4.4.8"/></td>
		</tr>
		<tr>
		<td align="center" colspan="1" rowspan="1">Quick-Start (Type=0x26)
		</td>
		<td align="center" colspan="1" rowspan="1">Permit</td>
		<td align="center" colspan="1" rowspan="1">
		<xref target="x26" format="default" sectionFormat="of" derivedCo
		ntent="Section 4.4.9"/></td>
		</tr>
		<tr>
		<td align="center" colspan="1" rowspan="1">Deprecated (Type=0x4D)<
		/td>
		<td align="center" colspan="1" rowspan="1">Drop</td>
		<td align="center" colspan="1" rowspan="1">
		<xref target="x4D" format="default" sectionFormat="of" derivedCo
		ntent="Section 4.4.10"/></td>
		</tr>
		<tr>
		<td align="center" colspan="1" rowspan="1">MPL Option (Type=0x6D)<
		/td>
		<td align="center" colspan="1" rowspan="1">Permit</td>
		<td align="center" colspan="1" rowspan="1">
		<xref target="x6D" format="default" sectionFormat="of" derivedCo
		ntent="Section 4.4.12"/></td>
		</tr>
		<tr>
		<td align="center" colspan="1" rowspan="1">Jumbo Payload (Type=0xC
		2)</td>
		<td align="center" colspan="1" rowspan="1">Permit based on needed
		functionality</td>
		<td align="center" colspan="1" rowspan="1">
		<xref target="xC2" format="default" sectionFormat="of" derivedCo
		ntent="Section 4.4.16"/></td>
		</tr>
		<tr>
		<td align="center" colspan="1" rowspan="1">RPL Option (Type=0x63)<
		/td>
		<td align="center" colspan="1" rowspan="1">Drop</td>
		<td align="center" colspan="1" rowspan="1">
		<xref target="x63" format="default" sectionFormat="of" derivedCo
		ntent="Section 4.4.11"/></td>
		</tr>
		<tr>
		<td align="center" colspan="1" rowspan="1">Endpoint Identification
		(Type=0x8A)</td>
		<td align="center" colspan="1" rowspan="1">Drop</td>
		<td align="center" colspan="1" rowspan="1">
		<xref target="x8A" format="default" sectionFormat="of" derivedCo
		ntent="Section 4.4.13"/></td>
		</tr>
		<tr>
		<td align="center" colspan="1" rowspan="1">ILNP Nonce (Type=0x8B)<
		/td>
		<td align="center" colspan="1" rowspan="1">Permit</td>
		<td align="center" colspan="1" rowspan="1">
		<xref target="x8B" format="default" sectionFormat="of" derivedCo
		ntent="Section 4.4.14"/></td>
		</tr>
		<tr>
		<td align="center" colspan="1" rowspan="1">Line-Identification Opt
		ion (Type=0x8C)</td>
		<td align="center" colspan="1" rowspan="1">Drop</td>
		<td align="center" colspan="1" rowspan="1">
		<xref target="x8C" format="default" sectionFormat="of" derivedCo
		ntent="Section 4.4.15"/></td>
		</tr>
		<tr>
		<td align="center" colspan="1" rowspan="1">Home Address (Type=0xC9
		)</td>
		<td align="center" colspan="1" rowspan="1">Permit</td>
		<td align="center" colspan="1" rowspan="1">
		<xref target="xC9" format="default" sectionFormat="of" derivedCo
		ntent="Section 4.4.17"/></td>
		</tr>
		<tr>
		<td align="center" colspan="1" rowspan="1">IP_DFF (Type=0xEE)</td>
		<td align="center" colspan="1" rowspan="1">Permit based on needed
		functionality</td>
		<td align="center" colspan="1" rowspan="1">
		<xref target="xEE" format="default" sectionFormat="of" derivedCo
		ntent="Section 4.4.18"/></td>
		</tr>
		<tr>
		<td align="center" colspan="1" rowspan="1">RFC3692-style Experimen
		t (Types = 0x1E, 0x3E, 0x5E, 0x7E, 0x9E, 0xBE, 0xDE, 0xFE)</td>
		<td align="center" colspan="1" rowspan="1">Permit based on needed
		functionality</td>
		<td align="center" colspan="1" rowspan="1">
		<xref target="x1E" format="default" sectionFormat="of" derivedCo
		ntent="Section 4.4.19"/></td>
		</tr>
		</tbody>
		</table>
		</section>
		<section anchor="opt-filtering" numbered="true" toc="include" removeInRFC=
		"false" pn="section-4.4">
		<name slugifiedName="name-advice-on-the-handling-of-pa">Advice on the Ha
		ndling of Packets with Specific IPv6 Options</name>
		<t indent="0" pn="section-4.4-1">The following subsections contain a des
		cription of each of the IPv6 options that have so far been specified, a summary
		of the security implications of 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="exclude" removeInRFC="false"
	<section title="Pad1 (Type=0x00)" anchor="x00">	pn="section-4.4.1">
	<section title="Uses">	<name slugifiedName="name-pad1-type0x00">Pad1 (Type=0x00)</name>
	<t>This option is used when necessary to align subsequent options and to pad out	<section numbered="true" toc="exclude" removeInRFC="false" pn="section
	the containing header to a multiple of 8 octets in length.</t>	-4.4.1.1">
	</section>	<name slugifiedName="name-uses-12">Uses</name>
		<t indent="0" pn="section-4.4.1.1-1">This option is used when necess
	<section title="Specification">	ary to align subsequent options and to pad out the containing header to a multip
	<t>This option is specified in <xref target="RFC8200"/>.</t>	le of 8 octets in length.</t>
	</section>	</section>
		<section numbered="true" toc="exclude" removeInRFC="false" pn="section
	<section title="Specific Security Implications">	-4.4.1.2">
	<t>None.</t>	<name slugifiedName="name-specification-12">Specification</name>
	</section>	<t indent="0" pn="section-4.4.1.2-1">This option is specified in <xr
		ef target="RFC8200" format="default" sectionFormat="of" derivedContent="RFC8200"
	<section title="Operational and Interoperability Impact if Blocked">	/>.</t>
	<t>Discarding packets that contain this option would potentially break any proto	</section>
	col that relies on IPv6 options.</t>	<section numbered="true" toc="exclude" removeInRFC="false" pn="section
	</section>	-4.4.1.3">
		<name slugifiedName="name-specific-security-implications-9">Specific
	<section title="Advice">	Security Implications</name>
	<t>Intermediate systems should not discard packets based on the presence of this	<t indent="0" pn="section-4.4.1.3-1">None.</t>
	option.</t>	</section>
	</section>	<section numbered="true" toc="exclude" removeInRFC="false" pn="section
	</section>	-4.4.1.4">
		<name slugifiedName="name-operational-and-interoperability-im-4">Ope
	<section title="PadN (Type=0x01)" anchor="x01">	rational and Interoperability Impact If Blocked</name>
	<section title="Uses">	<t indent="0" pn="section-4.4.1.4-1">Discarding packets that contain
	<t>This option is used when necessary to align subsequent options and to pad out	this option would potentially break any protocol that relies on IPv6 options.</
	the containing header to a multiple of 8 octets in length.</t>	t>
	</section>	</section>
		<section numbered="true" toc="exclude" removeInRFC="false" pn="section
	<section title="Specification">	-4.4.1.5">
	<t>This option is specified in <xref target="RFC8200"/>.</t>	<name slugifiedName="name-advice-12">Advice</name>
	</section>	<t indent="0" pn="section-4.4.1.5-1">Intermediate systems should not
		discard packets based on the presence of this option.</t>
	<section title="Specific Security Implications">	</section>
	<t>Because of the possible size of this option, it could be leveraged as a large	</section>
	-bandwidth covert channel.</t>	<section anchor="x01" numbered="true" toc="exclude" removeInRFC="false"
	</section>	pn="section-4.4.2">
		<name slugifiedName="name-padn-type0x01">PadN (Type=0x01)</name>
	<section title="Operational and Interoperability Impact if Blocked">	<section numbered="true" toc="exclude" removeInRFC="false" pn="section
	<t>Discarding packets that contain this option would potentially break any proto	-4.4.2.1">
	col that relies on IPv6 options.</t>	<name slugifiedName="name-uses-13">Uses</name>
	</section>	<t indent="0" pn="section-4.4.2.1-1">This option is used when necess
		ary to align subsequent options and to pad out the containing header to a multip
	<section title="Advice">	le of 8 octets in length.</t>
	<t>Intermediate systems should not discard IPv6 packets based on the presence of	</section>
	this option.</t>	<section numbered="true" toc="exclude" removeInRFC="false" pn="section
	</section>	-4.4.2.2">
	</section>	<name slugifiedName="name-specification-13">Specification</name>
		<t indent="0" pn="section-4.4.2.2-1">This option is specified in <xr
	<section title="Tunnel Encapsulation Limit (Type=0x04)" anchor="x04">	ef target="RFC8200" format="default" sectionFormat="of" derivedContent="RFC8200"
	<section title="Uses">	/>.</t>
	<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 numbered="true" toc="exclude" removeInRFC="false" pn="section
	</section>	-4.4.2.3">
		<name slugifiedName="name-specific-security-implications-10">Specifi
	<section title="Specification">	c Security Implications</name>
	<t>This option is specified in <xref target="RFC2473"/>.</t>	<t indent="0" pn="section-4.4.2.3-1">Because of the possible size of
	</section>	this option, it could be leveraged as a large-bandwidth covert channel.</t>
		</section>
	<section title="Specific Security Implications">	<section numbered="true" toc="exclude" removeInRFC="false" pn="section
	<t>Those described in <xref target="RFC2473"/>.</t>	-4.4.2.4">
	</section>	<name slugifiedName="name-operational-and-interoperability-im-5">Ope
		rational and Interoperability Impact If Blocked</name>
	<section title="Operational and Interoperability Impact if Blocked">	<t indent="0" pn="section-4.4.2.4-1">Discarding packets that contain
	<t>Discarding packets based on the presence of this option could result in tunne	this option would potentially break any protocol that relies on IPv6 options.</
	l traffic being discarded.</t>	t>
	</section>	</section>
		<section numbered="true" toc="exclude" removeInRFC="false" pn="section
	<section title="Advice">	-4.4.2.5">
	<t>Intermediate systems should not discard packets based on the presence of this	<name slugifiedName="name-advice-13">Advice</name>
	option.</t>	<t indent="0" pn="section-4.4.2.5-1">Intermediate systems should not
	</section>	discard IPv6 packets based on the presence of this option.</t>
	</section>	</section>
		</section>
	<section title="Router Alert (Type=0x05)" anchor="x05">	<section anchor="x04" numbered="true" toc="exclude" removeInRFC="false"
	<section title="Uses">	pn="section-4.4.3">
	<t>The Router Alert option <xref target="RFC2711"/> is employed by a number of p	<name slugifiedName="name-tunnel-encapsulation-limit-">Tunnel Encapsul
	rotocols, including the Resource reSerVation Protocol (RSVP) <xref target="RFC22	ation Limit (Type=0x04)</name>
	05"/>, Multicast Listener Discovery (MLD) <xref target="RFC2710"/> <xref target=	<section numbered="true" toc="exclude" removeInRFC="false" pn="section
	"RFC3810"/>, Multicast Router Discovery (MRD) <xref target="RFC4286"/>, and Gene	-4.4.3.1">
	ral Internet Signaling Transport (GIST) <xref target="RFC5971"/>. Its usage is d	<name slugifiedName="name-uses-14">Uses</name>
	iscussed in detail in <xref target="RFC6398"/>.	<t indent="0" pn="section-4.4.3.1-1">The Tunnel Encapsulation Limit
		option can be employed to specify how many further levels of nesting the packet
		is permitted to undergo.</t>
		</section>
		<section numbered="true" toc="exclude" removeInRFC="false" pn="section
		-4.4.3.2">
		<name slugifiedName="name-specification-14">Specification</name>
		<t indent="0" pn="section-4.4.3.2-1">This option is specified in <xr
		ef target="RFC2473" format="default" sectionFormat="of" derivedContent="RFC2473"
		/>.</t>
		</section>
		<section numbered="true" toc="exclude" removeInRFC="false" pn="section
		-4.4.3.3">
		<name slugifiedName="name-specific-security-implications-11">Specifi
		c Security Implications</name>
		<t indent="0" pn="section-4.4.3.3-1">These are discussed in <xref ta
		rget="RFC2473" format="default" sectionFormat="of" derivedContent="RFC2473"/>.</
		t>
		</section>
		<section numbered="true" toc="exclude" removeInRFC="false" pn="section
		-4.4.3.4">
		<name slugifiedName="name-operational-and-interoperability-im-6">Ope
		rational and Interoperability Impact If Blocked</name>
		<t indent="0" pn="section-4.4.3.4-1">Discarding packets based on the
		presence of this option could result in tunnel traffic being discarded.</t>
		</section>
		<section numbered="true" toc="exclude" removeInRFC="false" pn="section
		-4.4.3.5">
		<name slugifiedName="name-advice-14">Advice</name>
		<t indent="0" pn="section-4.4.3.5-1">Intermediate systems should not
		discard packets based on the presence of this option.</t>
		</section>
		</section>
		<section anchor="x05" numbered="true" toc="exclude" removeInRFC="false"
		pn="section-4.4.4">
		<name slugifiedName="name-router-alert-type0x05">Router Alert (Type=0x
		05)</name>
		<section numbered="true" toc="exclude" removeInRFC="false" pn="section
		-4.4.4.1">
		<name slugifiedName="name-uses-15">Uses</name>
		<t indent="0" pn="section-4.4.4.1-1">The Router Alert option <xref t
		arget="RFC2711" format="default" sectionFormat="of" derivedContent="RFC2711"/> i
		s employed by a number of protocols, including the Resource reSerVation Protocol
		(RSVP) <xref target="RFC2205" format="default" sectionFormat="of" derivedConten
		t="RFC2205"/>, Multicast Listener Discovery (MLD) <xref target="RFC2710" format=
		"default" sectionFormat="of" derivedContent="RFC2710"/> <xref target="RFC3810" f
		ormat="default" sectionFormat="of" derivedContent="RFC3810"/>, Multicast Router
		Discovery (MRD) <xref target="RFC4286" format="default" sectionFormat="of" deriv
		edContent="RFC4286"/>, and General Internet Signaling Transport (GIST) <xref tar
		get="RFC5971" format="default" sectionFormat="of" derivedContent="RFC5971"/>. It
		s usage is discussed in detail in <xref target="RFC6398" format="default" sectio
		nFormat="of" derivedContent="RFC6398"/>.
	</t>	</t>

		</section>
	</section>	<section numbered="true" toc="exclude" removeInRFC="false" pn="section
		-4.4.4.2">
	<section title="Specification">	<name slugifiedName="name-specification-15">Specification</name>
	<t>This option is specified in <xref target="RFC2711"/>.</t>	<t indent="0" pn="section-4.4.4.2-1">This option is specified in <xr
	</section>	ef target="RFC2711" format="default" sectionFormat="of" derivedContent="RFC2711"
		/>.</t>
	<section title="Specific Security Implications" anchor="ra-usage">	</section>
	<t>Since this option causes the contents of the packet to be inspected by the ha	<section anchor="ra-usage" numbered="true" toc="exclude" removeInRFC="
	ndling device, this option could be leveraged for performing DoS attacks. The se	false" pn="section-4.4.4.3">
	curity implications of the Router Alert option are discussed in detail in <xref	<name slugifiedName="name-specific-security-implications-12">Specifi
	target="RFC6398"/>.</t>	c Security Implications</name>
	</section>	<t indent="0" pn="section-4.4.4.3-1">Since this option causes the co
		ntents of the packet to be inspected by the handling device, this option could b
	<section title="Operational and Interoperability Impact if Blocked">	e leveraged for performing DoS attacks. The security implications of the Router
	<t>Discarding packets that contain this option would break any protocols that re	Alert option are discussed in detail in <xref target="RFC6398" format="default"
	ly on them, such as RSVP and multicast deployments. Please see <xref target="ra-	sectionFormat="of" derivedContent="RFC6398"/>.</t>
	usage"/> for further details.</t>	</section>
	</section>	<section numbered="true" toc="exclude" removeInRFC="false" pn="section
		-4.4.4.4">
	<section title="Advice">	<name slugifiedName="name-operational-and-interoperability-im-7">Ope
	<t>Packets containing this option should be permitted in environments where supp	rational and Interoperability Impact If Blocked</name>
	ort for RSVP, multicast routing, or similar protocols is desired.</t>	<t indent="0" pn="section-4.4.4.4-1">Discarding packets that contain
	</section>	this option would break any protocols that rely on them, such as RSVP and multi
	</section>	cast deployments. Please see <xref target="ra-usage" format="default" sectionFor
		mat="of" derivedContent="Section 4.4.4.3"/> for further details.</t>
	<section title="CALIPSO (Type=0x07)" anchor="x07">	</section>
	<section title="Uses">	<section numbered="true" toc="exclude" removeInRFC="false" pn="section
	<t>This option is used for encoding explicit packet Sensitivity Labels on IPv6 p	-4.4.4.5">
	ackets. It is intended for use only within Multi-Level Secure (MLS) networking	<name slugifiedName="name-advice-15">Advice</name>
	environments that are both trusted and trustworthy.</t>	<t indent="0" pn="section-4.4.4.5-1">Packets containing this option
	</section>	should be permitted in environments where support for RSVP, multicast routing, o
		r similar protocols is required.</t>
	<section title="Specification">	</section>
	<t>This option is specified in <xref target="RFC5570"/>.</t>	</section>
	</section>	<section anchor="x07" numbered="true" toc="exclude" removeInRFC="false"
		pn="section-4.4.5">
	<section title="Specific Security Implications">	<name slugifiedName="name-calipso-type0x07">CALIPSO (Type=0x07)</name>
	<t>Presence of this option in a packet does not by itself create any	<section numbered="true" toc="exclude" removeInRFC="false" pn="section
		-4.4.5.1">
		<name slugifiedName="name-uses-16">Uses</name>
		<t indent="0" pn="section-4.4.5.1-1">This option is used for encodin
		g explicit packet Sensitivity Labels on IPv6 packets. It is intended for use on
		ly within Multi-Level Secure (MLS) networking environments that are both trusted
		and trustworthy.</t>
		</section>
		<section numbered="true" toc="exclude" removeInRFC="false" pn="section
		-4.4.5.2">
		<name slugifiedName="name-specification-16">Specification</name>
		<t indent="0" pn="section-4.4.5.2-1">This option is specified in <xr
		ef target="RFC5570" format="default" sectionFormat="of" derivedContent="RFC5570"
		/>.</t>
		</section>
		<section numbered="true" toc="exclude" removeInRFC="false" pn="section
		-4.4.5.3">
		<name slugifiedName="name-specific-security-implications-13">Specifi
		c Security Implications</name>
		<t indent="0" pn="section-4.4.5.3-1">Presence of this option in a pa
		cket 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="exclude" removeInRFC="false" pn="section
	<section title="Operational and Interoperability Impact if Blocked">	-4.4.5.4">
	<t>If packets with this option are discarded or if the option is	<name slugifiedName="name-operational-and-interoperability-im-8">Ope
		rational and Interoperability Impact If Blocked</name>
		<t indent="0" pn="section-4.4.5.4-1">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" sectionFormat="of" derivedContent="RFC5570"/>,
	arget="RFC4303"/> can be employed to protect the CALIPSO option.</t>	IPsec <xref target="RFC4301" format="default" sectionFormat="of" derivedContent=
	</section>	"RFC4301"/> <xref target="RFC4302" format="default" sectionFormat="of" derivedCo
		ntent="RFC4302"/> <xref target="RFC4303" format="default" sectionFormat="of" der
	<section title="Advice">	ivedContent="RFC4303"/> can be employed to protect the CALIPSO.</t>
	<t>	</section>
	Recommendations for handling the CALIPSO option depend on the deployment environ	<section numbered="true" toc="exclude" removeInRFC="false" pn="section
	ment, rather than whether an intermediate system	-4.4.5.5">
		<name slugifiedName="name-advice-16">Advice</name>
		<t indent="0" pn="section-4.4.5.5-1">
		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 indent="0" pn="section-4.4.5.5-2">Explicit configuration is the o
	<t>Explicit configuration is the only method via which an intermediate system	nly method via which an intermediate 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 indent="0" pn="section-4.4.5.5-3">For intermediate systems that D
	<t>For Intermediate systems that DO NOT implement <xref target="RFC5570"/>, ther	O NOT implement <xref target="RFC5570" format="default" sectionFormat="of" deriv
	e	edContent="RFC5570"/>, there
	should be a configuration option to EITHER (a) drop packets containing	should be a configuration option to either (a) drop packets containing
	the CALIPSO option OR (b) to ignore the presence of the CALIPSO option	the CALIPSO or (b) ignore the presence of the CALIPSO
	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 indent="0" pn="section-4.4.5.5-4">For intermediate systems that D
	<t>For Intermediate systems that DO implement <xref target="RFC5570"/>, there sh	O implement <xref target="RFC5570" format="default" sectionFormat="of" derivedCo
	ould	ntent="RFC5570"/>, there should
	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" sectionFormat="of" der ivedContent="RFC5570"/>. When deployed in non-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="exclude" removeInRFC="false"
	<section title="SMF_DPD (Type=0x08)" anchor="x08">	pn="section-4.4.6">
	<section title="Uses">	<name slugifiedName="name-smf_dpd-type0x08">SMF_DPD (Type=0x08)</name>
	<t>This option is employed in the (experimental) Simplified Multicast Forwarding	<section numbered="true" toc="exclude" removeInRFC="false" pn="section
	(SMF) for unique packet identification for IPv6 I-DPD, and as a mechanism to gu	-4.4.6.1">
	arantee non-collision of hash values for different packets when H-DPD is used.</	<name slugifiedName="name-uses-17">Uses</name>
	t>	<t indent="0" pn="section-4.4.6.1-1">This option is employed in the
	</section>	(experimental) Simplified Multicast Forwarding (SMF) for unique packet identific
		ation for IPv6 Identification-based DPD (I-DPD) and as a mechanism to guarantee
	<section title="Specification">	non-collision of hash values for different packets when Hash-based DPD (H-DPD) i
	<t>This option is specified in <xref target="RFC6621"/>.</t>	s used.</t>
	</section>	</section>
		<section numbered="true" toc="exclude" removeInRFC="false" pn="section
	<section title="Specific Security Implications">	-4.4.6.2">
	<t>None. The use of transient numeric identifiers is subject to the security and	<name slugifiedName="name-specification-17">Specification</name>
	privacy considerations discussed in <xref target="I-D.irtf-pearg-numeric-ids-ge	<t indent="0" pn="section-4.4.6.2-1">This option is specified in <xr
	neration"/>.</t>	ef target="RFC6621" format="default" sectionFormat="of" derivedContent="RFC6621"
	</section>	/>.</t>
		</section>
	<section title="Operational and Interoperability Impact if Blocked">	<section numbered="true" toc="exclude" removeInRFC="false" pn="section
	<t>Dropping packets containing this option within a MANET domain would break SMF	-4.4.6.3">
	. However, dropping such packets at the border of such domain would have no nega	<name slugifiedName="name-specific-security-implications-14">Specifi
	tive impact.</t>	c Security Implications</name>
	</section>	<t indent="0" pn="section-4.4.6.3-1">None. The use of transient nume
		ric identifiers is subject to the security and privacy considerations discussed
	<section title="Advice">	in <xref target="I-D.irtf-pearg-numeric-ids-generation" format="default" section
	<t>Intermediate systems that are not within a MANET domain should discard packet	Format="of" derivedContent="NUMERIC-IDS"/>.</t>
	s that contain this option.</t>	</section>
	</section>	<section numbered="true" toc="exclude" removeInRFC="false" pn="section
	</section>	-4.4.6.4">
		<name slugifiedName="name-operational-and-interoperability-im-9">Ope
	<section title="PDM (Type=0x0F)" anchor="x0F">	rational and Interoperability Impact If Blocked</name>
	<section title="Uses">	<t indent="0" pn="section-4.4.6.4-1">Dropping packets containing thi
	<t>This option is employed to convey sequence numbers and timing information in	s option within a Mobile Ad Hoc Network (MANET) domain would break SMF. However,
	IPv6 packets as a basis for measurements.</t>	dropping such packets at the border of such domain would have no negative impac
	</section>	t.</t>
		</section>
	<section title="Specification">	<section numbered="true" toc="exclude" removeInRFC="false" pn="section
	<t>This option is specified in <xref target="RFC8250"/>.</t>	-4.4.6.5">
	</section>	<name slugifiedName="name-advice-17">Advice</name>
		<t indent="0" pn="section-4.4.6.5-1">Intermediate systems that are n
	<section title="Specific Security Implications">	ot within a MANET domain should discard packets that contain this option.</t>
	<t>Those specified in <xref target="RFC8250"/>. Additionally, since the options	</section>
	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 anchor="x0F" numbered="true" toc="exclude" removeInRFC="false"
	</section>	pn="section-4.4.7">
		<name slugifiedName="name-pdm-type0x0f">PDM (Type=0x0F)</name>
	<section title="Operational and Interoperability Impact if Blocked">	<section numbered="true" toc="exclude" removeInRFC="false" pn="section
	<t>Dropping packets containing this option will result in negative interoperaibl	-4.4.7.1">
	ity implications for traffic employing this option as a basis for measurements.<	<name slugifiedName="name-uses-18">Uses</name>
	/t>	<t indent="0" pn="section-4.4.7.1-1">This option is employed to conv
	</section>	ey sequence numbers and timing information in IPv6 packets as a basis for measur
		ements.</t>
	<section title="Advice">	</section>
	<t>Intermediate systems should not discard packets based on the presence of this	<section numbered="true" toc="exclude" removeInRFC="false" pn="section
	option.</t>	-4.4.7.2">
	</section>	<name slugifiedName="name-specification-18">Specification</name>
		<t indent="0" pn="section-4.4.7.2-1">This option is specified in <xr
	</section>	ef target="RFC8250" format="default" sectionFormat="of" derivedContent="RFC8250"
		/>.</t>
	<section title="RPL Option (Type=0x23)" anchor="x23">	</section>
	<section title="Uses">	<section numbered="true" toc="exclude" removeInRFC="false" pn="section
	<t>The RPL Option provides a mechanism to include routing information with each	-4.4.7.3">
	datagram that an RPL router forwards.</t>	<name slugifiedName="name-specific-security-implications-15">Specifi
	</section>	c Security Implications</name>
		<t indent="0" pn="section-4.4.7.3-1">These are discussed in <xref ta
	<section title="Specification">	rget="RFC8250" format="default" sectionFormat="of" derivedContent="RFC8250"/>. A
	<t>This option is specified in <xref target="RFC9008"/>.</t>	dditionally, since this option employs transient numeric identifiers, implementa
	</section>	tions may be subject to the issues discussed in <xref target="I-D.irtf-pearg-num
		eric-ids-generation" format="default" sectionFormat="of" derivedContent="NUMERIC
	<section title="Specific Security Implications">	-IDS"/>.</t>
	<t>Those described in <xref target="RFC9008"/>.</t>	</section>
	</section>	<section numbered="true" toc="exclude" removeInRFC="false" pn="section
		-4.4.7.4">
	<section title="Operational and Interoperability Impact if Blocked">	<name slugifiedName="name-operational-and-interoperability-im-10">Op
	<t>This option can survive outside of an RPL instance. As a result, discarding p	erational and Interoperability Impact If Blocked</name>
	ackets based on the presence of this option would break some use cases for RPL (	<t indent="0" pn="section-4.4.7.4-1">Dropping packets containing thi
	see <xref target="RFC9008"/>).</t>	s option will result in negative interoperability implications for traffic emplo
	</section>	ying this option as a basis for measurements.</t>
		</section>
	<section title="Advice">	<section numbered="true" toc="exclude" removeInRFC="false" pn="section
	<t>Intermediate systems should not discard IPv6 packets based on the presence of	-4.4.7.5">
	this option.</t>	<name slugifiedName="name-advice-18">Advice</name>
	</section>	<t indent="0" pn="section-4.4.7.5-1">Intermediate systems should not
	</section>	discard packets based on the presence of this option.</t>
		</section>
	<section title="Quick-Start (Type=0x26)" anchor="x26">	</section>
	<section title="Uses">	<section anchor="x23" numbered="true" toc="exclude" removeInRFC="false"
	<t>This IP Option is used in the specification of Quick-Start for	pn="section-4.4.8">
		<name slugifiedName="name-rpl-option-type0x23">RPL Option (Type=0x23)<
		/name>
		<section numbered="true" toc="exclude" removeInRFC="false" pn="section
		-4.4.8.1">
		<name slugifiedName="name-uses-19">Uses</name>
		<t indent="0" pn="section-4.4.8.1-1">The RPL Option provides a mecha
		nism to include routing information in each datagram that a RPL router forwards.
		</t>
		</section>
		<section numbered="true" toc="exclude" removeInRFC="false" pn="section
		-4.4.8.2">
		<name slugifiedName="name-specification-19">Specification</name>
		<t indent="0" pn="section-4.4.8.2-1">This option is specified in <xr
		ef target="RFC9008" format="default" sectionFormat="of" derivedContent="RFC9008"
		/>.</t>
		</section>
		<section numbered="true" toc="exclude" removeInRFC="false" pn="section
		-4.4.8.3">
		<name slugifiedName="name-specific-security-implications-16">Specifi
		c Security Implications</name>
		<t indent="0" pn="section-4.4.8.3-1">These are discussed in <xref ta
		rget="RFC9008" format="default" sectionFormat="of" derivedContent="RFC9008"/>.</
		t>
		</section>
		<section numbered="true" toc="exclude" removeInRFC="false" pn="section
		-4.4.8.4">
		<name slugifiedName="name-operational-and-interoperability-im-11">Op
		erational and Interoperability Impact If Blocked</name>
		<t indent="0" pn="section-4.4.8.4-1">This option can survive outside
		of a RPL instance. As a result, discarding packets based on the presence of thi
		s option would break some use cases for RPL (see <xref target="RFC9008" format="
		default" sectionFormat="of" derivedContent="RFC9008"/>).</t>
		</section>
		<section numbered="true" toc="exclude" removeInRFC="false" pn="section
		-4.4.8.5">
		<name slugifiedName="name-advice-19">Advice</name>
		<t indent="0" pn="section-4.4.8.5-1">Intermediate systems should not
		discard IPv6 packets based on the presence of this option.</t>
		</section>
		</section>
		<section anchor="x26" numbered="true" toc="exclude" removeInRFC="false"
		pn="section-4.4.9">
		<name slugifiedName="name-quick-start-type0x26">Quick-Start (Type=0x26
		)</name>
		<section numbered="true" toc="exclude" removeInRFC="false" pn="section
		-4.4.9.1">
		<name slugifiedName="name-uses-20">Uses</name>
		<t indent="0" pn="section-4.4.9.1-1">This IP option is used in the s
		pecification 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" sectionFormat="of" derivedContent="RFC4782"/>.</t>
		</section>
	<section title="Specification">	<section numbered="true" toc="exclude" removeInRFC="false" pn="section
	<t>This option is specified in <xref target="RFC4782"/>, on the "Experimental" t	-4.4.9.2">
	rack.</t>	<name slugifiedName="name-specification-20">Specification</name>
	</section>	<t indent="0" pn="section-4.4.9.2-1">This option is specified in <xr
		ef target="RFC4782" format="default" sectionFormat="of" derivedContent="RFC4782"
	<section title="Specific Security Implications">	/> on the "Experimental" track.</t>
	<t>Section 9.6 of <xref target="RFC4782"/> notes that Quick-Start is	</section>
	vulnerable to two kinds of attacks: <list style="symbols">	<section numbered="true" toc="exclude" removeInRFC="false" pn="section
	<t>attacks to increase the routers' processing and state load,	-4.4.9.3">
	and,</t>	<name slugifiedName="name-specific-security-implications-17">Specifi
		c Security Implications</name>
	<t>attacks with bogus Quick-Start Requests to temporarily tie up	<t indent="0" pn="section-4.4.9.3-1"><xref target="RFC4782" sectionF
		ormat="of" section="9.6" format="default" derivedLink="https://rfc-editor.org/rf
		c/rfc4782#section-9.6" derivedContent="RFC4782"/> notes that Quick-Start is
		vulnerable to two kinds of attacks: </t>
		<ul spacing="normal" bare="false" empty="false" indent="3" pn="secti
		on-4.4.9.3-2">
		<li pn="section-4.4.9.3-2.1">attacks to increase the routers' proc
		essing and state load
		and</li>
		<li pn="section-4.4.9.3-2.2">attacks with bogus Quick-Start Reques
		ts 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 indent="0" pn="section-4.4.9.3-3">We note that if routers in a gi
	<t>We note that if routers in a given environment do not implement and enable th	ven environment do not implement and enable the Quick-Start mechanism, only the
	e Quick-Start mechanism, only the general security	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"/>) would apply.</t>	ications" format="default" sectionFormat="of" derivedContent="Section 4.2"/>) wo
		uld apply.</t>
	</section>	</section>
		<section numbered="true" toc="exclude" removeInRFC="false" pn="section
	<section title="Operational and Interoperability Impact if Blocked">	-4.4.9.4">
	<t>The Quick-Start functionality would be disabled, and additional	<name slugifiedName="name-operational-and-interoperability-im-12">Op
	delays in TCP's connection establishment (for example) could be introd	erational and Interoperability Impact If Blocked</name>
	uced.	<t indent="0" pn="section-4.4.9.4-1">If packets with IPv6 Quick Star
	(Please see Section 4.7.2 of <xref target="RFC4782"/>.) We note,	t options are blocked, the host trying to establish a TCP
		connection will fall back to not including the Quick Start option --
		this means that the
		feature will be disabled, and additional delays in connection establi
		shment
		will be introduced (as discussed in <xref target="RFC4782" sectionFor
		mat="of" section="4.7.2" format="default" derivedLink="https://rfc-editor.org/rf
		c/rfc4782#section-4.7.2" derivedContent="RFC4782"/>). 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" sectionFormat=
	</section>	"of" derivedContent="RFC4782"/>.</t>
		</section>
	<section title="Advice">	<section numbered="true" toc="exclude" removeInRFC="false" pn="section
	<t>Intermediate systems should not discard IPv6 packets based on the p	-4.4.9.5">
	resence of this option.</t>	<name slugifiedName="name-advice-20">Advice</name>
		<t indent="0" pn="section-4.4.9.5-1">Intermediate systems should not
	</section>	discard IPv6 packets based on the presence of this option.</t>
	</section>	</section>
		</section>
	<section title="Deprecated (Type=0x4D)" anchor="x4D">	<section anchor="x4D" numbered="true" toc="exclude" removeInRFC="false"
	<section title="Uses">	pn="section-4.4.10">
	<t>No information has been found about this option type.</t>	<name slugifiedName="name-deprecated-type0x4d">Deprecated (Type=0x4D)<
	</section>	/name>
		<section numbered="true" toc="exclude" removeInRFC="false" pn="section
	<section title="Specification">	-4.4.10.1">
	<t>No information has been found about this option type.</t>	<name slugifiedName="name-uses-21">Uses</name>
	</section>	<t indent="0" pn="section-4.4.10.1-1">No information has been found
		about this option type.</t>
	<section title="Specific Security Implications">	</section>
	<t>No information has been found about this option type, and hence it has been i	<section numbered="true" toc="exclude" removeInRFC="false" pn="section
	mpossible to perform the corresponding security assessment.</t>	-4.4.10.2">
	</section>	<name slugifiedName="name-specification-21">Specification</name>
		<t indent="0" pn="section-4.4.10.2-1">No information has been found
	<section title="Operational and Interoperability Impact if Blocked">	about this option type.</t>
	<t>Unknown.</t>	</section>
	</section>	<section numbered="true" toc="exclude" removeInRFC="false" pn="section
		-4.4.10.3">
	<section title="Advice">	<name slugifiedName="name-specific-security-implications-18">Specifi
	<t>Intermediate systems should discard packets that contain this option.</t>	c Security Implications</name>
	</section>	<t indent="0" pn="section-4.4.10.3-1">No information has been found
	</section>	about this option type; hence, it has been impossible to perform the correspondi
		ng security assessment.</t>
	<section title="RPL Option (Type=0x63)" anchor="x63">	</section>
	<section title="Uses">	<section numbered="true" toc="exclude" removeInRFC="false" pn="section
	<t>The RPL Option provides a mechanism to include routing information with each	-4.4.10.4">
	datagram that an RPL router forwards.</t>	<name slugifiedName="name-operational-and-interoperability-im-13">Op
	</section>	erational and Interoperability Impact If Blocked</name>
		<t indent="0" pn="section-4.4.10.4-1">Unknown.</t>
	<section title="Specification">	</section>
	<t>This option was originally specified in <xref target="RFC6553"/>. It has been	<section numbered="true" toc="exclude" removeInRFC="false" pn="section
	deprecated by <xref target="RFC9008"/>.</t>	-4.4.10.5">
	</section>	<name slugifiedName="name-advice-21">Advice</name>
		<t indent="0" pn="section-4.4.10.5-1">Intermediate systems should di
	<section title="Specific Security Implications">	scard packets that contain this option.</t>
	<t>Those described in <xref target="RFC9008"/>.</t>	</section>
	</section>	</section>
		<section anchor="x63" numbered="true" toc="exclude" removeInRFC="false"
	<section title="Operational and Interoperability Impact if Blocked">	pn="section-4.4.11">
	<t>This option is meant to be employed within an RPL instance. As a result, disc	<name slugifiedName="name-rpl-option-type0x63">RPL Option (Type=0x63)<
	arding packets based on the presence of this option outside of an RPL instance w	/name>
	ill not result in interoperability implications.</t>	<section numbered="true" toc="exclude" removeInRFC="false" pn="section
	</section>	-4.4.11.1">
		<name slugifiedName="name-uses-22">Uses</name>
	<section title="Advice">	<t indent="0" pn="section-4.4.11.1-1">The RPL Option provides a mech
	<t>Non-RPL routers should discard packets that contain an RPL option.</t>	anism to include routing information in each datagram that a RPL router forwards
	</section>	.</t>
	</section>	</section>
		<section numbered="true" toc="exclude" removeInRFC="false" pn="section
	<section title="MPL Option (Type=0x6D)" anchor="x6D">	-4.4.11.2">
	<section title="Uses">	<name slugifiedName="name-specification-22">Specification</name>
	<t>This option is used with the Multicast Protocol for Low power and Lossy Netwo	<t indent="0" pn="section-4.4.11.2-1">This option was originally spe
	rks (MPL), that provides IPv6 multicast forwarding in	cified in <xref target="RFC6553" format="default" sectionFormat="of" derivedCont
		ent="RFC6553"/>. It has been deprecated by <xref target="RFC9008" format="defaul
		t" sectionFormat="of" derivedContent="RFC9008"/>.</t>
		</section>
		<section numbered="true" toc="exclude" removeInRFC="false" pn="section
		-4.4.11.3">
		<name slugifiedName="name-specific-security-implications-19">Specifi
		c Security Implications</name>
		<t indent="0" pn="section-4.4.11.3-1">These are discussed in <xref t
		arget="RFC6553" sectionFormat="of" section="5" format="default" derivedLink="htt
		ps://rfc-editor.org/rfc/rfc6553#section-5" derivedContent="RFC6553"/>.</t>
		</section>
		<section numbered="true" toc="exclude" removeInRFC="false" pn="section
		-4.4.11.4">
		<name slugifiedName="name-operational-and-interoperability-im-14">Op
		erational and Interoperability Impact If Blocked</name>
		<t indent="0" pn="section-4.4.11.4-1">This option is meant to be emp
		loyed within a RPL instance. As a result, discarding packets based on the presen
		ce of this option outside of a RPL instance will not result in interoperability
		implications.</t>
		</section>
		<section numbered="true" toc="exclude" removeInRFC="false" pn="section
		-4.4.11.5">
		<name slugifiedName="name-advice-22">Advice</name>
		<t indent="0" pn="section-4.4.11.5-1">Intermediate systems should di
		scard packets that contain a RPL Option.</t>
		</section>
		</section>
		<section anchor="x6D" numbered="true" toc="exclude" removeInRFC="false"
		pn="section-4.4.12">
		<name slugifiedName="name-mpl-option-type0x6d">MPL Option (Type=0x6D)<
		/name>
		<section numbered="true" toc="exclude" removeInRFC="false" pn="section
		-4.4.12.1">
		<name slugifiedName="name-uses-23">Uses</name>
		<t indent="0" pn="section-4.4.12.1-1">This option is used with the M
		ulticast Protocol for Low power and Lossy Networks (MPL), which provides IPv6 mu
		lticast forwarding in
	constrained networks.</t>	constrained networks.</t>

	</section>	</section>
		<section numbered="true" toc="exclude" removeInRFC="false" pn="section
	<section title="Specification">	-4.4.12.2">
	<t>This option is specified in <xref target="RFC7731"/>, and is meant to be incl	<name slugifiedName="name-specification-23">Specification</name>
	uded only in Hop-by-Hop Option headers.</t>	<t indent="0" pn="section-4.4.12.2-1">This option is specified in <x
	</section>	ref target="RFC7731" format="default" sectionFormat="of" derivedContent="RFC7731
		"/> and is meant to be included only in Hop-by-Hop Options headers.</t>
	<section title="Specific Security Implications">	</section>
	<t>Those described in <xref target="RFC7731"/>.</t>	<section numbered="true" toc="exclude" removeInRFC="false" pn="section
	</section>	-4.4.12.3">
		<name slugifiedName="name-specific-security-implications-20">Specifi
	<section title="Operational and Interoperability Impact if Blocked">	c Security Implications</name>
	<t>Dropping packets that contain an MPL option within an MPL network would break	<t indent="0" pn="section-4.4.12.3-1">These are discussed in <xref t
	the Multicast Protocol for Low power and Lossy Networks (MPL). However, droppin	arget="RFC7731" format="default" sectionFormat="of" derivedContent="RFC7731"/>.<
	g such packets at the border of such networks will have no negative impact.</t>	/t>
	</section>	</section>
		<section numbered="true" toc="exclude" removeInRFC="false" pn="section
	<section title="Advice">	-4.4.12.4">
	<t>Intermediate systems should not discard packets based on the presence of this	<name slugifiedName="name-operational-and-interoperability-im-15">Op
	option. However, since this option has been specified for the Hop-by-Hop Option	erational and Interoperability Impact If Blocked</name>
	s, such systems should consider the discussion in <xref target="proto0"/>.</t>	<t indent="0" pn="section-4.4.12.4-1">Dropping packets that contain
	</section>	an MPL Option within an MPL network would break the MPL. However, dropping such
	</section>	packets at the border of such networks will have no negative impact.</t>
		</section>
	<section title="Endpoint Identification (Type=0x8A)" anchor="x8A">	<section numbered="true" toc="exclude" removeInRFC="false" pn="section
	<section title="Uses">	-4.4.12.5">
	<t>The Endpoint Identification option was meant to be used with the Nimrod routi	<name slugifiedName="name-advice-23">Advice</name>
	ng architecture <xref target="NIMROD-DOC"/>, but has never seen widespread deplo	<t indent="0" pn="section-4.4.12.5-1">Intermediate systems should no
	yment.</t>	t discard packets based on the presence of this option. However, since this opti
	</section>	on has been specified for the Hop-by-Hop Options header, such systems should con
		sider the discussion in <xref target="proto0" format="default" sectionFormat="of
	<section title="Specification">	" derivedContent="Section 3.5.1"/>.</t>
	<t>This option is specified in <xref target="NIMROD-DOC"/>.</t>	</section>
	</section>	</section>
		<section anchor="x8A" numbered="true" toc="exclude" removeInRFC="false"
	<section title="Specific Security Implications">	pn="section-4.4.13">
	<t>Undetermined.</t>	<name slugifiedName="name-endpoint-identification-typ">Endpoint Identi
	</section>	fication (Type=0x8A)</name>
		<section numbered="true" toc="exclude" removeInRFC="false" pn="section
	<section title="Operational and Interoperability Impact if Blocked">	-4.4.13.1">
	<t>None.</t>	<name slugifiedName="name-uses-24">Uses</name>
	</section>	<t indent="0" pn="section-4.4.13.1-1">The Endpoint Identification op
		tion was meant to be used with the Nimrod routing architecture <xref target="NIM
	<section title="Advice">	ROD-DOC" format="default" sectionFormat="of" derivedContent="NIMROD-DOC"/> but h
	<t>Intermediate systems should discard packets that contain this option.</t>	as never seen widespread deployment.</t>
	</section>	</section>
	</section>	<section numbered="true" toc="exclude" removeInRFC="false" pn="section
		-4.4.13.2">
	<section title="ILNP Nonce (Type=0x8B)" anchor="x8B">	<name slugifiedName="name-specification-24">Specification</name>
	<section title="Uses">	<t indent="0" pn="section-4.4.13.2-1">This option is specified in <x
	<t>This option is employed by Identifier-Locator Network Protocol for IPv6 (ILNP	ref target="NIMROD-DOC" format="default" sectionFormat="of" derivedContent="NIMR
	v6) for providing protection against off-path attacks for packets when ILNPv6 is	OD-DOC"/>.</t>
	in use, and as a signal during initial network-layer session creation that ILNP	</section>
	v6 is proposed for use with this network-layer session, rather than classic IPv6	<section numbered="true" toc="exclude" removeInRFC="false" pn="section
	.</t>	-4.4.13.3">
	</section>	<name slugifiedName="name-specific-security-implications-21">Specifi
		c Security Implications</name>
	<section title="Specification">	<t indent="0" pn="section-4.4.13.3-1">Undetermined.</t>
	<t>This option is specified in <xref target="RFC6744"/>.</t>	</section>
	</section>	<section numbered="true" toc="exclude" removeInRFC="false" pn="section
		-4.4.13.4">
	<section title="Specific Security Implications">	<name slugifiedName="name-operational-and-interoperability-im-16">Op
	<t>Those described in <xref target="RFC6744"/>.</t>	erational and Interoperability Impact If Blocked</name>
	</section>	<t indent="0" pn="section-4.4.13.4-1">None.</t>
		</section>
	<section title="Operational and Interoperability Impact if Blocked">	<section numbered="true" toc="exclude" removeInRFC="false" pn="section
	<t>Discarding packets that contain this option will break INLPv6 deployments.</t	-4.4.13.5">
	>	<name slugifiedName="name-advice-24">Advice</name>
	</section>	<t indent="0" pn="section-4.4.13.5-1">Intermediate systems should di
		scard packets that contain this option.</t>
	<section title="Advice">	</section>
	<t>Intermediate systems should not discard packets based on the presence of this	</section>
	option.</t>	<section anchor="x8B" numbered="true" toc="exclude" removeInRFC="false"
	</section>	pn="section-4.4.14">
	</section>	<name slugifiedName="name-ilnp-nonce-type0x8b">ILNP Nonce (Type=0x8B)<
		/name>
	<section title="Line-Identification Option (Type=0x8C)" anchor="x8C">	<section numbered="true" toc="exclude" removeInRFC="false" pn="section
	<section title="Uses">	-4.4.14.1">
	<t>This option is used by an Edge Router to identify the subscriber premises in	<name slugifiedName="name-uses-25">Uses</name>
	scenarios where several subscriber premises may be logically connected to the sa	<t indent="0" pn="section-4.4.14.1-1">This option is employed by the
	me interface of an Edge Router.</t>	Identifier-Locator Network Protocol for IPv6 (ILNPv6) to provide protection aga
		inst off-path attacks for packets when ILNPv6 is in use and as a signal during i
	<!--	nitial network-layer session creation that ILNPv6 is proposed for use with this
	The Line-Identification Option (LIO) is a destination option that can	network-layer session, rather than classic IPv6.</t>
	be included in IPv6 datagrams that tunnel Router Solicitation and	</section>
	Router Advertisement messages. The use of the Line-ID option in any	<section numbered="true" toc="exclude" removeInRFC="false" pn="section
	other IPv6 datagrams is not defined by this document. Multiple Line-	-4.4.14.2">
	ID destination options MUST NOT be present in the same IPv6 datagram.	<name slugifiedName="name-specification-25">Specification</name>
	The LIO has no alignment requirement.	<t indent="0" pn="section-4.4.14.2-1">This option is specified in <x
	</section>	ref target="RFC6744" format="default" sectionFormat="of" derivedContent="RFC6744
		"/>.</t>
	<section title="Specification">	</section>
	<t>This option is specified in <xref target="RFC6788"/>.</t>	<section numbered="true" toc="exclude" removeInRFC="false" pn="section
	</section>	-4.4.14.3">
		<name slugifiedName="name-specific-security-implications-22">Specifi
	<section title="Specific Security Implications">	c Security Implications</name>
	<t>Those described in <xref target="RFC6788"/>.</t>	<t indent="0" pn="section-4.4.14.3-1">These are discussed in <xref t
	</section>	arget="RFC6744" format="default" sectionFormat="of" derivedContent="RFC6744"/>.<
		/t>
	<section title="Operational and Interoperability Impact if Blocked">	</section>
	<t>Since this option is meant to be employed in Router Solicitation messages, di	<section numbered="true" toc="exclude" removeInRFC="false" pn="section
	scarding packets based on the presence of this option at intermediate systems wi	-4.4.14.4">
	ll result in no interoperability implications.</t>	<name slugifiedName="name-operational-and-interoperability-im-17">Op
	</section>	erational and Interoperability Impact If Blocked</name>
		<t indent="0" pn="section-4.4.14.4-1">Discarding packets that contai
	<section title="Advice">	n this option will break ILNPv6 deployments.</t>
	<t>Intermediate devices should discard packets that contain this option.</t>	</section>
	</section>	<section numbered="true" toc="exclude" removeInRFC="false" pn="section
	</section>	-4.4.14.5">
		<name slugifiedName="name-advice-25">Advice</name>
	<section title="Jumbo Payload (Type=0XC2)" anchor="xC2">	<t indent="0" pn="section-4.4.14.5-1">Intermediate systems should no
	<section title="Uses">	t discard packets based on the presence of this option.</t>
	<t>The Jumbo payload option provides the means of specifying payloads larger tha	</section>
	n 65535 bytes.</t>	</section>
	</section>	<section anchor="x8C" numbered="true" toc="exclude" removeInRFC="false"
		pn="section-4.4.15">
	<section title="Specification">	<name slugifiedName="name-line-identification-option-">Line-Identifica
	<t>This option is specified in <xref target="RFC2675"/>.</t>	tion Option (Type=0x8C)</name>
	</section>	<section numbered="true" toc="exclude" removeInRFC="false" pn="section
		-4.4.15.1">
	<section title="Specific Security Implications">	<name slugifiedName="name-uses-26">Uses</name>
	<t>There are no specific issues arising from this option, except for improper va	<t indent="0" pn="section-4.4.15.1-1">This option is used by an Edge
	lidity checks of the option and associated packet lengths.</t>	Router to identify the subscriber premises in scenarios where several subscribe
	</section>	r premises may be logically connected to the same interface of an Edge Router.</
		t>
	<section title="Operational and Interoperability Impact if Blocked">	</section>
	<t>Discarding packets based on the presence of this option will cause IPv6 jumbo	<section numbered="true" toc="exclude" removeInRFC="false" pn="section
	grams to be discarded.</t>	-4.4.15.2">
	</section>	<name slugifiedName="name-specification-26">Specification</name>
		<t indent="0" pn="section-4.4.15.2-1">This option is specified in <x
	<section title="Advice">	ref target="RFC6788" format="default" sectionFormat="of" derivedContent="RFC6788
	<t>An operator should permit this option only in specific scenarios in which sup	"/>.</t>
	port for IPv6 jumbograms is desired.	</section>
		<section numbered="true" toc="exclude" removeInRFC="false" pn="section
		-4.4.15.3">
		<name slugifiedName="name-specific-security-implications-23">Specifi
		c Security Implications</name>
		<t indent="0" pn="section-4.4.15.3-1">These are discussed in <xref t
		arget="RFC6788" format="default" sectionFormat="of" derivedContent="RFC6788"/>.<
		/t>
		</section>
		<section numbered="true" toc="exclude" removeInRFC="false" pn="section
		-4.4.15.4">
		<name slugifiedName="name-operational-and-interoperability-im-18">Op
		erational and Interoperability Impact If Blocked</name>
		<t indent="0" pn="section-4.4.15.4-1">Since this option is meant to
		be used when tunneling Neighbor Discovery messages in some broadband network dep
		loyment scenarios, discarding packets based on the presence of this option at in
		termediate systems will result in no interoperability implications.</t>
		</section>
		<section numbered="true" toc="exclude" removeInRFC="false" pn="section
		-4.4.15.5">
		<name slugifiedName="name-advice-26">Advice</name>
		<t indent="0" pn="section-4.4.15.5-1">Intermediate systems should di
		scard packets that contain this option.</t>
		</section>
		</section>
		<section anchor="xC2" numbered="true" toc="exclude" removeInRFC="false"
		pn="section-4.4.16">
		<name slugifiedName="name-jumbo-payload-type0xc2">Jumbo Payload (Type=
		0XC2)</name>
		<section numbered="true" toc="exclude" removeInRFC="false" pn="section
		-4.4.16.1">
		<name slugifiedName="name-uses-27">Uses</name>
		<t indent="0" pn="section-4.4.16.1-1">The Jumbo Payload option provi
		des the means for supporting payloads larger than 65535 bytes.</t>
		</section>
		<section numbered="true" toc="exclude" removeInRFC="false" pn="section
		-4.4.16.2">
		<name slugifiedName="name-specification-27">Specification</name>
		<t indent="0" pn="section-4.4.16.2-1">This option is specified in <x
		ref target="RFC2675" format="default" sectionFormat="of" derivedContent="RFC2675
		"/>.</t>
		</section>
		<section numbered="true" toc="exclude" removeInRFC="false" pn="section
		-4.4.16.3">
		<name slugifiedName="name-specific-security-implications-24">Specifi
		c Security Implications</name>
		<t indent="0" pn="section-4.4.16.3-1">There are no specific issues a
		rising from this option, except for improper validity checks of the option and a
		ssociated packet lengths.</t>
		</section>
		<section numbered="true" toc="exclude" removeInRFC="false" pn="section
		-4.4.16.4">
		<name slugifiedName="name-operational-and-interoperability-im-19">Op
		erational and Interoperability Impact If Blocked</name>
		<t indent="0" pn="section-4.4.16.4-1">Discarding packets based on th
		e presence of this option will cause IPv6 jumbograms to be discarded.</t>
		</section>
		<section numbered="true" toc="exclude" removeInRFC="false" pn="section
		-4.4.16.5">
		<name slugifiedName="name-advice-27">Advice</name>
		<t indent="0" pn="section-4.4.16.5-1">An operator should permit this
		option only in specific scenarios in which support for IPv6 jumbograms is requi
		red.
	</t>	</t>

	</section>	</section>
	</section>	</section>
		<section anchor="xC9" numbered="true" toc="exclude" removeInRFC="false"
	<section title="Home Address (Type=0xC9)" anchor="xC9">	pn="section-4.4.17">
	<section title="Uses">	<name slugifiedName="name-home-address-type0xc9">Home Address (Type=0x
	<t>The Home Address option is used by a Mobile IPv6 node while away from home, t	C9)</name>
	o inform the recipient of the mobile node's home address.</t>	<section numbered="true" toc="exclude" removeInRFC="false" pn="section
	</section>	-4.4.17.1">
		<name slugifiedName="name-uses-28">Uses</name>
	<section title="Specification">	<t indent="0" pn="section-4.4.17.1-1">The Home Address option is use
	<t>This option is specified in <xref target="RFC6275"/>.</t>	d by a Mobile IPv6 node while away from home to inform the recipient of the mobi
	</section>	le node's home address.</t>
		</section>
	<section title="Specific Security Implications">	<section numbered="true" toc="exclude" removeInRFC="false" pn="section
	<t>No (known) additional security implications than those described in <xref tar	-4.4.17.2">
	get="RFC6275"/>.</t>	<name slugifiedName="name-specification-28">Specification</name>
	</section>	<t indent="0" pn="section-4.4.17.2-1">This option is specified in <x
		ref target="RFC6275" format="default" sectionFormat="of" derivedContent="RFC6275
	<section title="Operational and Interoperability Impact if Blocked">	"/>.</t>
	<t>Discarding IPv6 packets based on the presence of this option will break Mobil	</section>
	e IPv6.</t>	<section numbered="true" toc="exclude" removeInRFC="false" pn="section
	</section>	-4.4.17.3">
		<name slugifiedName="name-specific-security-implications-25">Specifi
	<section title="Advice">	c Security Implications</name>
	<t>Intermediate systems should not discard IPv6 packets based on the presence of	<t indent="0" pn="section-4.4.17.3-1">There are no (known) additiona
	this option.</t>	l security implications, other than those discussed in <xref target="RFC6275" fo
	</section>	rmat="default" sectionFormat="of" derivedContent="RFC6275"/>.</t>
	</section>	</section>
		<section numbered="true" toc="exclude" removeInRFC="false" pn="section
	<section title="IP_DFF (Type=0xEE)" anchor="xEE">	-4.4.17.4">
	<section title="Uses">	<name slugifiedName="name-operational-and-interoperability-im-20">Op
	<t>This option is employed with the (Experimental) Depth-First Forwarding (DFF)	erational and Interoperability Impact If Blocked</name>
	in Unreliable Networks.</t>	<t indent="0" pn="section-4.4.17.4-1">Discarding IPv6 packets based
	</section>	on the presence of this option will break Mobile IPv6.</t>
		</section>
	<section title="Specification">	<section numbered="true" toc="exclude" removeInRFC="false" pn="section
	<t>This option is specified in <xref target="RFC6971"/>.</t>	-4.4.17.5">
	</section>	<name slugifiedName="name-advice-28">Advice</name>
		<t indent="0" pn="section-4.4.17.5-1">Intermediate systems should no
	<section title="Specific Security Implications">	t discard IPv6 packets based on the presence of this option.</t>
	<t>Those specified in <xref target="RFC6971"/>.</t>	</section>
	</section>	</section>
		<section anchor="xEE" numbered="true" toc="exclude" removeInRFC="false"
	<section title="Operational and Interoperability Impact if Blocked">	pn="section-4.4.18">
	<t>Dropping packets containing this option within a routing domain that is runni	<name slugifiedName="name-ip_dff-type0xee">IP_DFF (Type=0xEE)</name>
	ng DFF would break DFF. However, dropping such packets at the border of such dom	<section numbered="true" toc="exclude" removeInRFC="false" pn="section
	ains will have no security implications.</t>	-4.4.18.1">
	</section>	<name slugifiedName="name-uses-29">Uses</name>
		<t indent="0" pn="section-4.4.18.1-1">This option is employed with t
	<section title="Advice">	he (experimental) Depth-First Forwarding (DFF) in unreliable networks.</t>
	<t>Intermediate systems that do not operate within a routing domain that is runn	</section>
	ing DFF should discard packets containing this option.</t>	<section numbered="true" toc="exclude" removeInRFC="false" pn="section
	</section>	-4.4.18.2">
	</section>	<name slugifiedName="name-specification-29">Specification</name>
		<t indent="0" pn="section-4.4.18.2-1">This option is specified in <x
	<section title="RFC3692-style Experiment (Types = 0x1E, 0x3E, 0x5E, 0x7E, 0x9E,	ref target="RFC6971" format="default" sectionFormat="of" derivedContent="RFC6971
	0xBE, 0xDE, 0xFE)" anchor="x1E">	"/>.</t>
	<section title="Uses">	</section>
	<t>These options can be employed for performing RFC3692-style experime	<section numbered="true" toc="exclude" removeInRFC="false" pn="section
	nts. It is only appropriate to use these values in	-4.4.18.3">
		<name slugifiedName="name-specific-security-implications-26">Specifi
		c Security Implications</name>
		<t indent="0" pn="section-4.4.18.3-1">These are specified in <xref t
		arget="RFC6971" format="default" sectionFormat="of" derivedContent="RFC6971"/>.<
		/t>
		</section>
		<section numbered="true" toc="exclude" removeInRFC="false" pn="section
		-4.4.18.4">
		<name slugifiedName="name-operational-and-interoperability-im-21">Op
		erational and Interoperability Impact If Blocked</name>
		<t indent="0" pn="section-4.4.18.4-1">Dropping packets containing th
		is option within a routing domain that is running DFF would break DFF. However,
		dropping such packets at the border of such domains will have no operational or
		interoperability implications.</t>
		</section>
		<section numbered="true" toc="exclude" removeInRFC="false" pn="section
		-4.4.18.5">
		<name slugifiedName="name-advice-29">Advice</name>
		<t indent="0" pn="section-4.4.18.5-1">Intermediate systems that do n
		ot operate within a routing domain that is running DFF should discard packets co
		ntaining this option.</t>
		</section>
		</section>
		<section anchor="x1E" numbered="true" toc="exclude" removeInRFC="false"
		pn="section-4.4.19">
		<name slugifiedName="name-rfc3692-style-experiment-ty">RFC3692-Style E
		xperiment (Types = 0x1E, 0x3E, 0x5E, 0x7E, 0x9E, 0xBE, 0xDE, 0xFE)</name>
		<section numbered="true" toc="exclude" removeInRFC="false" pn="section
		-4.4.19.1">
		<name slugifiedName="name-uses-30">Uses</name>
		<t indent="0" pn="section-4.4.19.1-1">These options can be employed
		for performing RFC3692-style experiments. It is only appropriate to use these va
		lues 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="exclude" removeInRFC="false" pn="section
	<section title="Specification">	-4.4.19.2">
	<t>Specified in RFC 4727 <xref target="RFC4727"/> in the context of	<name slugifiedName="name-specification-30">Specification</name>
		<t indent="0" pn="section-4.4.19.2-1">These options are specified in
		<xref target="RFC4727" format="default" sectionFormat="of" derivedContent="RFC4
		727"/> in the context of
	RFC3692-style experiments.</t>	RFC3692-style experiments.</t>

	</section>	</section>
		<section numbered="true" toc="exclude" removeInRFC="false" pn="section
	<section title="Specific Security Implications">	-4.4.19.3">
	<t>The specific security implications will depend on the specific use of these	<name slugifiedName="name-specific-security-implications-27">Specifi
	options.</t>	c Security Implications</name>
	</section>	<t indent="0" pn="section-4.4.19.3-1">The specific security implicat
		ions will depend on the specific use of these options.</t>
	<section title="Operational and Interoperability Impact if Blocked">	</section>
	<t>For obvious reasons, discarding packets that contain these options limits the	<section numbered="true" toc="exclude" removeInRFC="false" pn="section
	ability to perform legitimate experiments across IPv6 routers.</t>	-4.4.19.4">
	</section>	<name slugifiedName="name-operational-and-interoperability-im-22">Op
		erational and Interoperability Impact If Blocked</name>
	<section title="Advice">	<t indent="0" pn="section-4.4.19.4-1">For obvious reasons, discardin
	<t>Operators should determine according to their own circumstances whether to di	g packets that contain these options limits the ability to perform legitimate ex
	scard packets containing these IPv6 options.</t>	periments across IPv6 routers.</t>
	<!--	</section>
	<t>Intermediate systems should discard packets that contain these options. Only	<section numbered="true" toc="exclude" removeInRFC="false" pn="section
	in specific environments where RFC3692-style experiments are meant to be perform	-4.4.19.5">
	ed should these options be permitted.</t> -->	<name slugifiedName="name-advice-30">Advice</name>
	</section>	<t indent="0" pn="section-4.4.19.5-1">Operators should determine, ac
	</section>	cording to their own circumstances, whether to discard packets containing these
		IPv6 options.</t>
	</section>	</section>
		</section>
	<section title="Advice on the handling of Packets with Unknown IPv6 Options">	</section>
		<section numbered="true" toc="include" removeInRFC="false" pn="section-4.5
	<t>We refer to IPv6 options that have not been assigned an IPv6 option type in t	">
	he corresponding registry (<xref target="IANA-IPV6-PARAM"/>) as "unknown IPv6 op	<name slugifiedName="name-advice-on-the-handling-of-pac">Advice on the H
	tions".</t>	andling of Packets with Unknown IPv6 Options</name>
		<t indent="0" pn="section-4.5-1">We refer to IPv6 options that have not
	<section title="Uses">	been assigned an IPv6 Option Type in the corresponding registry, which is <xref
	<t>New IPv6 options may be specified as part of future protocol work.<	target="IANA-IPV6-PARAM" format="default" sectionFormat="of" derivedContent="IAN
	/t>	A-IPV6-PARAM"/>, as "unknown IPv6 options".</t>
	</section>	<section numbered="true" toc="exclude" removeInRFC="false" pn="section-4
		.5.1">
	<section title="Specification">	<name slugifiedName="name-uses-31">Uses</name>
	<t>The processing of unknown IPv6 options is specified in <xref target="RFC8200"	<t indent="0" pn="section-4.5.1-1">New IPv6 options may be specified a
	/>.</t>	s part of future protocol work.</t>
	</section>	</section>
		<section numbered="true" toc="exclude" removeInRFC="false" pn="section-4
	<section title="Specific Security Implications">	.5.2">
	<t>For obvious reasons, it is impossible to determine specific security implica	<name slugifiedName="name-specification-31">Specification</name>
	tions of unknown IPv6 options.</t>	<t indent="0" pn="section-4.5.2-1">The processing of unknown IPv6 opti
	</section>	ons is specified in <xref target="RFC8200" format="default" sectionFormat="of" d
		erivedContent="RFC8200"/>.</t>
	<section title="Operational and Interoperability Impact if Blocked">	</section>
	<t>Discarding unknown IPv6 options may slow down the deployment of new IPv6 opti	<section numbered="true" toc="exclude" removeInRFC="false" pn="section-4
	ons. As noted in <xref target="draft-gont-6man-ipv6-opt-transmit"/>, the corresp	.5.3">
	onding IANA registry (<xref target="IANA-IPV6-PARAM"/> should be monitored such	<name slugifiedName="name-specific-security-implications-28">Specific
	that IPv6 option filtering rules are updated as new IPv6 options are standardize	Security Implications</name>
	d.</t>	<t indent="0" pn="section-4.5.3-1">For obvious reasons, it is impossib
	</section>	le to determine specific security implications of unknown IPv6 options.</t>
		</section>
	<section title="Advice">	<section numbered="true" toc="exclude" removeInRFC="false" pn="section-4
		.5.4">
	<t>Operators should determine according to their own circumstances whether to di	<name slugifiedName="name-operational-and-interoperability-im-23">Oper
	scard packets containing unknown IPv6 options.</t>	ational and Interoperability Impact If Blocked</name>
		<t indent="0" pn="section-4.5.4-1">Discarding unknown IPv6 options may
	</section>	slow down the deployment of new IPv6 options. As noted in <xref target="I-D.gon
	</section>	t-6man-ipv6-opt-transmit" format="default" sectionFormat="of" derivedContent="IP
		v6-OPTIONS"/>, the corresponding IANA registry, which is <xref target="IANA-IPV6
	</section>	-PARAM" format="default" sectionFormat="of" derivedContent="IANA-IPV6-PARAM"/>,
		should be monitored such that IPv6 option filtering rules are updated as new IPv
	<section anchor="IANA" title="IANA Considerations">	6 options are standardized.</t>
	<t>This document has no actions for IANA.</t>	</section>
	</section>	<section numbered="true" toc="exclude" removeInRFC="false" pn="section-4
		.5.5">
	<section title="Privacy Considerations" anchor="Privacy" >	<name slugifiedName="name-advice-31">Advice</name>
	<t>	<t indent="0" pn="section-4.5.5-1">Operators should determine, accordi
		ng to their own circumstances, whether to discard packets containing unknown IPv
		6 options.</t>
		</section>
		</section>
		</section>
		<section anchor="IANA" numbered="true" toc="include" removeInRFC="false" pn=
		"section-5">
		<name slugifiedName="name-iana-considerations">IANA Considerations</name>
		<t indent="0" pn="section-5-1">This document has no IANA actions.</t>
		</section>
		<section anchor="Privacy" numbered="true" toc="include" removeInRFC="false"
		pn="section-6">
		<name slugifiedName="name-privacy-considerations">Privacy Considerations</
		name>
		<t indent="0" pn="section-6-1">
	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="include" removeInRFC="false"
	<section title="Security Considerations" anchor="Security" >	pn="section-7">
	<t>	<name slugifiedName="name-security-considerations">Security Considerations
	This document provides advice on the filtering of IPv6 packets that contain IPv6	</name>
	EHs (and possibly IPv6 options) at IPv6 transit routers. It is meant to improve	<t indent="0" pn="section-7-1">
	the current situation of widespread dropping of such IPv6 packets in those case	This document provides advice on the filtering of IPv6 packets that contain IPv6
	s where the drops result from improper configuration defaults, or inappropriate	EHs (and possibly IPv6 options) at IPv6 transit routers. It is meant to improve
	advice in this area.	the current situation of widespread dropping of such IPv6 packets in those case
		s where the drops result from improper configuration defaults or inappropriate a
		dvice in this area.
	</t>	</t>

	<t>	<t indent="0" pn="section-7-2">
	As discussed in Section <xref target="ipv6-ehs-rationale"/> of this document,	As discussed in <xref target="ipv6-ehs-rationale" format="default" sectionFor
	one of the	mat="of" derivedContent="Section 3.3"/>, one of 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" sectionFormat="of" derivedContent="RFC9098"/>.
	</t>	</t>

		<t indent="0" pn="section-7-3">We also note that depending on the router a
	<t>We also note that depending on the router architecture, attempts to filter pa	rchitecture, attempts to filter packets based on the presence of IPv6 EHs or opt
	ckets ased on the presence of IPv6 EHs or options might itself represent an atta	ions might itself represent an attack vector to network infrastructure devices <
	ck vector to network infrastructure devices <xref target="RFC9098"/>.</t>	xref target="RFC9098" format="default" sectionFormat="of" derivedContent="RFC909
	</section>	8"/>.</t>
		</section>
	<section title="Acknowledgements">	</middle>
	<t>The authors would like to thank Ron Bonica for his work on earlier versions o	<back>
	f this document.</t>	<displayreference target="I-D.irtf-pearg-numeric-ids-generation" to="NUMERIC
	<t>The authors of this document would like to thank (in alphabetical order) Mika	-IDS"/>
	el Abrahamsson, Brian Carpenter, Tim Chown, Roman Danyliw, Darren Dukes, Lars Eg	<displayreference target="I-D.vyncke-v6ops-james" to="JAMES"/>
	gert, David Farmer, Mike Heard, Bob Hinden, Christian Huitema, Benjamin Kaduk, E	<displayreference target="I-D.gont-6man-ipv6-opt-transmit" to="IPv6-OPTIONS"
	rik Kline, Murray Kucherawy, Jen Linkova, Carlos Pignataro, Alvaro Retana, Maria	/>
	Ines Robles, Zaheduzzaman Sarker, Donald Smith, Pascal Thubert, Ole Troan, Gunt	<references pn="section-8">
	er Van De Velde, Eric Vyncke, and Robert Wilton, for providing valuable comments	<name slugifiedName="name-references">References</name>
	on earlier versions of this document.</t>	<references pn="section-8.1">
	<t>This document borrows some text and analysis from <xref target="RFC7126"/>, a	<name slugifiedName="name-normative-references">Normative References</na
	uthored by Fernando Gont, Randall Atkinson, and Carlos Pignataro.</t>	me>
		<reference anchor="RFC1034" target="https://www.rfc-editor.org/info/rfc1
	<t>The authors would like to thank Warren Kumari and Eric Vyncke for their guida	034" quoteTitle="true" derivedAnchor="RFC1034">
	nce during the publication process of this document.</t>	<front>
		<title>Domain names - concepts and facilities</title>
	<t>Fernando would also like to thank Brian Carpenter and Ran Atkinson who, over	<author initials="P." surname="Mockapetris" fullname="P. Mockapetris
	the years, have answered many questions and provided valuable comments that have	">
	benefited his protocol-related work (including the present document).</t>	<organization showOnFrontPage="true"/>
	</section>	</author>
		<date year="1987" month="November"/>
	</middle>	<abstract>
		<t indent="0">This RFC is the revised basic definition of The Doma
	<back>	in Name System. It obsoletes RFC-882. This memo describes the domain style nam
	<references title="Normative References">	es and their used for host address look up and electronic mail forwarding. It d
	<?rfc include="reference.RFC.1034" ?>	iscusses the clients and servers in the domain name system and the protocol used
	<?rfc include="reference.RFC.5570" ?>	between them.</t>
	<?rfc include="reference.RFC.2119" ?>	</abstract>
	<?rfc include="reference.RFC.8174" ?>	</front>
		<seriesInfo name="STD" value="13"/>
	<?rfc include="reference.RFC.2205" ?>	<seriesInfo name="RFC" value="1034"/>
		<seriesInfo name="DOI" value="10.17487/RFC1034"/>
	<?rfc include="reference.RFC.2675" ?>	</reference>
	<?rfc include="reference.RFC.4301" ?>	<reference anchor="RFC2119" target="https://www.rfc-editor.org/info/rfc2
	<?rfc include="reference.RFC.4302" ?>	119" quoteTitle="true" derivedAnchor="RFC2119">
	<?rfc include="reference.RFC.4303" ?>	<front>
		<title>Key words for use in RFCs to Indicate Requirement Levels</tit
	<?rfc include="reference.RFC.6275" ?>	le>
	<?rfc include="reference.RFC.7401" ?>	<author fullname="S. Bradner" initials="S" surname="Bradner"/>
	<?rfc include="reference.RFC.5533" ?>	<date month="March" year="1997"/>
	<?rfc include="reference.RFC.3692" ?>	<abstract>
	<?rfc include="reference.RFC.4727" ?>	<t indent="0">In many standards track documents several words are
	<?rfc include="reference.RFC.2710" ?>	used to signify the requirements in the specification. These words are often ca
	<?rfc include="reference.RFC.3810" ?>	pitalized. This document defines these words as they should be interpreted in I
	<?rfc include="reference.RFC.4286" ?>	ETF documents. This document specifies an Internet Best Current Practices for t
	<?rfc include="reference.RFC.5971" ?>	he Internet Community, and requests discussion and suggestions for improvements.
	<?rfc include="reference.RFC.2711" ?>	</t>
	<?rfc include="reference.RFC.5095" ?>	</abstract>
	<?rfc include="reference.RFC.6550" ?>	</front>
	<?rfc include="reference.RFC.6621" ?>	<seriesInfo name="BCP" value="14"/>
	<?rfc include="reference.RFC.6971" ?>	<seriesInfo name="RFC" value="2119"/>
	<?rfc include="reference.RFC.7045" ?>	<seriesInfo name="DOI" value="10.17487/RFC2119"/>
	<?rfc include="reference.RFC.7112" ?>	</reference>
	<?rfc include="reference.RFC.4782" ?>	<reference anchor="RFC2205" target="https://www.rfc-editor.org/info/rfc2
	<?rfc include="reference.RFC.6788" ?>	205" quoteTitle="true" derivedAnchor="RFC2205">
	<?rfc include="reference.RFC.6740" ?>	<front>
	<?rfc include="reference.RFC.6744" ?>	<title>Resource ReSerVation Protocol (RSVP) -- Version 1 Functional
	<?rfc include="reference.RFC.2473" ?>	Specification</title>
	<?rfc include="reference.RFC.6553" ?>	<author fullname="R. Braden" initials="R" role="editor" surname="Bra
	<?rfc include="reference.RFC.6554" ?>	den"/>
	<?rfc include="reference.RFC.6398" ?>	<author fullname="L. Zhang" initials="L" surname="Zhang"/>
	<?rfc include="reference.RFC.8754" ?>	<author fullname="S. Berson" initials="S" surname="Berson"/>
		<author fullname="S. Herzog" initials="S" surname="Herzog"/>
	<?rfc include="reference.RFC.9008" ?>	<author fullname="S. Jamin" initials="S" surname="Jamin"/>
		<date month="September" year="1997"/>
	<?rfc include="reference.RFC.7731" ?>	<abstract>
	<?rfc include="reference.RFC.8200" ?>	<t indent="0">This memo describes version 1 of RSVP, a resource re
	<?rfc include="reference.RFC.8250" ?>	servation setup protocol designed for an integrated services Internet. RSVP pro
	<?rfc include="reference.RFC.8900" ?>	vides receiver-initiated setup of resource reservations for multicast or unicast
	</references>	data flows, with good scaling and robustness properties. [STANDARDS-TRACK]</t>
		</abstract>
	<references title="Informative References">	</front>
	<?rfc include="reference.RFC.2460" ?>	<seriesInfo name="RFC" value="2205"/>
	<?rfc include="reference.RFC.3871" ?>	<seriesInfo name="DOI" value="10.17487/RFC2205"/>
	<?rfc include="reference.RFC.6192" ?>	</reference>
	<?rfc include="reference.RFC.7126" ?>	<reference anchor="RFC2473" target="https://www.rfc-editor.org/info/rfc2
	<?rfc include="reference.RFC.7739" ?>	473" quoteTitle="true" derivedAnchor="RFC2473">
		<front>
	<?rfc include="reference.I-D.irtf-pearg-numeric-ids-generation" ?>	<title>Generic Packet Tunneling in IPv6 Specification</title>
		<author fullname="A. Conta" initials="A" surname="Conta"/>
	<?rfc include="reference.RFC.9098" ?>	<author fullname="S. Deering" initials="S" surname="Deering"/>
		<date month="December" year="1998"/>
	<?rfc include="reference.RFC.7872" ?>	<abstract>
		<t indent="0">This document defines the model and generic mechanis
	<?rfc include="reference.I-D.vyncke-v6ops-james" ?>	ms for IPv6 encapsulation of Internet packets, such as IPv6 and IPv4. [STANDARDS
		-TRACK]</t>
	<reference anchor="Huston-2022" target="https://iepg.org/2022-03-20-ietf11	</abstract>
	3/huston-v6frag.pdf">	</front>
	<front>	<seriesInfo name="RFC" value="2473"/>
	<title>IPv6 Fragmentation and EH Behaviours</title>	<seriesInfo name="DOI" value="10.17487/RFC2473"/>
		</reference>
	<author fullname="Geoff Huston" initials="G." surname="Huston">	<reference anchor="RFC2675" target="https://www.rfc-editor.org/info/rfc2
	<organization abbrev="APNIC"/>	675" quoteTitle="true" derivedAnchor="RFC2675">
	<address>	<front>
	<email>gih@apnic.net</email>	<title>IPv6 Jumbograms</title>
	<uri>https://www.apnic.net</uri>	<author fullname="D. Borman" initials="D" surname="Borman"/>
	</address>	<author fullname="S. Deering" initials="S" surname="Deering"/>
	</author>	<author fullname="R. Hinden" initials="R" surname="Hinden"/>
		<date month="August" year="1999"/>
	<author fullname="Joao Damas" initials="J." surname="Damas">	<abstract>
	<organization abbrev="APNIC"/>	<t indent="0">This document describes the IPv6 Jumbo Payload optio
	</author>	n, which provides the means of specifying such large payload lengths. It also d
		escribes the changes needed to TCP and UDP to make use of jumbograms. [STANDARDS
	<date month="March" year="2022"/>	-TRACK]</t>
	</front>	</abstract>
		</front>
	<seriesInfo name=""	<seriesInfo name="RFC" value="2675"/>
	value="IEPG Meeting - March 2022 @ IETF 113"/>	<seriesInfo name="DOI" value="10.17487/RFC2675"/>
	</reference>	</reference>
		<reference anchor="RFC2710" target="https://www.rfc-editor.org/info/rfc2
	<!--	710" quoteTitle="true" derivedAnchor="RFC2710">
	<reference anchor="Vyncke-2022" target="https://iepg.org/2022-03-20-ietf11	<front>
	3/james-IEPG.pdf">	<title>Multicast Listener Discovery (MLD) for IPv6</title>
	<front>	<author fullname="S. Deering" initials="S" surname="Deering"/>
	<title>Just Another Measurement of Extension Header Survivability (JAM	<author fullname="W. Fenner" initials="W" surname="Fenner"/>
	ES)</title>	<author fullname="B. Haberman" initials="B" surname="Haberman"/>
		<date month="October" year="1999"/>
	<author fullname="Eric Vyncke" initials="E." surname="Vyncke">	<abstract>
		<t indent="0">This document specifies the protocol used by an IPv6
	</author>	router to discover the presence of multicast listeners (that is, nodes wishing
		to receive multicast packets) on its directly attached links, and to discover sp
	<author fullname="Raphael Leas" initials="R." surname="Leas">	ecifically which multicast addresses are of interest to those neighboring nodes.
	<organization/>	[STANDARDS-TRACK]</t>
	</author>	</abstract>
		</front>
	<author fullname="Justin Iurman" initials="J." surname="Iurman">	<seriesInfo name="RFC" value="2710"/>
	<organization/>	<seriesInfo name="DOI" value="10.17487/RFC2710"/>
	</author>	</reference>
		<reference anchor="RFC2711" target="https://www.rfc-editor.org/info/rfc2
	<date month="March" year="2022"/>	711" quoteTitle="true" derivedAnchor="RFC2711">
	</front>	<front>
		<title>IPv6 Router Alert Option</title>
	<seriesInfo name=""	<author fullname="C. Partridge" initials="C" surname="Partridge"/>
	value="IEPG Meeting - March 2022 @ IETF 113"/>	<author fullname="A. Jackson" initials="A" surname="Jackson"/>
	</reference>	<date month="October" year="1999"/>
		<abstract>
	<reference anchor="draft-ietf-nimrod-eid">	<t indent="0">This memo describes a new IPv6 Hop-by-Hop Option typ
	<front>	e that alerts transit routers to more closely examine the contents of an IP data
	<title>Endpoint Identifier Destination Option</title>	gram. [STANDARDS-TRACK]</t>
		</abstract>
	<author fullname="Charles Lynn" initials="C.L." surname="Lynn">	</front>
	<organization>BBN Systems and Technologies</organization>	<seriesInfo name="RFC" value="2711"/>
	</author>	<seriesInfo name="DOI" value="10.17487/RFC2711"/>
		</reference>
	<date month="November" year="1995"/>	<reference anchor="RFC3692" target="https://www.rfc-editor.org/info/rfc3
	</front>	692" quoteTitle="true" derivedAnchor="RFC3692">
		<front>
	<seriesInfo name=""	<title>Assigning Experimental and Testing Numbers Considered Useful<
	value="IETF Internet Draft, draft-ietf-nimrod-eid-00.txt"/>	/title>
	</reference>	<author fullname="T. Narten" initials="T" surname="Narten"/>
	<reference anchor="NIMROD-DOC">	<date month="January" year="2004"/>
	<front>	<abstract>
	<title>http://ana-3.lcs.mit.edu/~jnc/nimrod/</title>	<t indent="0">When experimenting with or extending protocols, it i
	<author initials="" surname="Nimrod Documentation Page" f	s often necessary to use some sort of protocol number or constant in order to ac
	ullname="Nimrod Documentation Page">	tually test or experiment with the new function, even when testing in a closed e
	<organization></organization>	nvironment. For example, to test a new DHCP option, one needs an option number
	</author>	to identify the new function. This document recommends that when writing IANA C
	<date year=""/>	onsiderations sections, authors should consider assigning a small range of numbe
	</front>	rs for experimentation purposes that implementers can use when testing protocol
	</reference>	extensions or other new features. This document reserves some ranges of numbers
		for experimentation purposes in specific protocols where the need to support ex
	<reference anchor="Biondi2007" target="http://www.secdev.org/conf/IPv6_RH_	perimentation has been identified.</t>
	security-csw07.pdf">	</abstract>
	<front>	</front>
	<title>IPv6 Routing Header Security</title>	<seriesInfo name="BCP" value="82"/>
		<seriesInfo name="RFC" value="3692"/>
	<author fullname="P. Biondi" initials="P." surname="Biondi">	<seriesInfo name="DOI" value="10.17487/RFC3692"/>
	<organization/>	</reference>
	</author>	<reference anchor="RFC3810" target="https://www.rfc-editor.org/info/rfc3
		810" quoteTitle="true" derivedAnchor="RFC3810">
	<author fullname="A. Ebalard" initials="A." surname="Ebalard">	<front>
	<organization/>	<title>Multicast Listener Discovery Version 2 (MLDv2) for IPv6</titl
	</author>	e>
		<author fullname="R. Vida" initials="R" role="editor" surname="Vida"
	<date year="2007"/>	/>
	</front>	<author fullname="L. Costa" initials="L" role="editor" surname="Cost
		a"/>
	<seriesInfo name="CanSecWest 2007"	<date month="June" year="2004"/>
	value="Security Conference"/>	<abstract>
	</reference>	<t indent="0">This document updates RFC 2710, and it specifies Ver
		sion 2 of the ulticast Listener Discovery Protocol (MLDv2). MLD is used by an I
	<reference anchor="IANA-PROTOCOLS"	Pv6 router to discover the presence of multicast listeners on directly attached
	target="https://www.iana.org/assignments/protocol-numbers/proto	links, and to discover which multicast addresses are of interest to those neighb
	col-numbers.xhtml">	oring nodes. MLDv2 is designed to be interoperable with MLDv1. MLDv2 adds the
	<front>	ability for a node to report interest in listening to packets with a particular
	<title>Protocol Numbers</title>	multicast address only from specific source addresses or from all sources except
		for specific source addresses. [STANDARDS-TRACK]</t>
	<author fullname="">	</abstract>
	<organization>Internet Assigned Numbers Authority</organization>	</front>
	</author>	<seriesInfo name="RFC" value="3810"/>
		<seriesInfo name="DOI" value="10.17487/RFC3810"/>
	<date year="2014"/>	</reference>
	</front>	<reference anchor="RFC4286" target="https://www.rfc-editor.org/info/rfc4
		286" quoteTitle="true" derivedAnchor="RFC4286">
	<format target="https://www.iana.org/assignments/protocol-numbers/protoc	<front>
	ol-numbers.txt"	<title>Multicast Router Discovery</title>
	type="TXT"/>	<author fullname="B. Haberman" initials="B" surname="Haberman"/>
	</reference>	<author fullname="J. Martin" initials="J" surname="Martin"/>
		<date month="December" year="2005"/>
	<reference anchor="IANA-IPV6-PARAM"	<abstract>
	target="https://www.iana.org/assignments/ipv6-parameters/ipv6-p	<t indent="0">The concept of Internet Group Management Protocol (I
	arameters.xhtml">	GMP) and Multicast Listener Discovery (MLD) snooping requires the ability to ide
	<front>	ntify the location of multicast routers. Since snooping is not standardized, the
	<title>Internet Protocol Version 6 (IPv6) Parameters</title>	re are many mechanisms in use to identify the multicast routers. However, this c
		an lead to interoperability issues between multicast routers and snooping switch
	<author fullname="">	es from different vendors.</t>
	<organization>Internet Assigned Numbers Authority</organization>	<t indent="0">This document introduces a general mechanism that al
	</author>	lows for the discovery of multicast routers. This new mechanism, Multicast Route
		r Discovery (MRD), introduces a standardized means of identifying multicast rout
	<date month="December" year="2013"/>	ers without a dependency on particular multicast routing protocols. [STANDARDS-T
	</front>	RACK]</t>
	</reference>	</abstract>
		</front>
	<reference anchor="FW-Benchmark" target="https://www.ipv6hackers.org/files/m	<seriesInfo name="RFC" value="4286"/>
	eetings/ipv6-hackers-1/zack-ipv6hackers1-firewall-security-assessment-and-benchm	<seriesInfo name="DOI" value="10.17487/RFC4286"/>
	arking.pdf">	</reference>
	<front>	<reference anchor="RFC4301" target="https://www.rfc-editor.org/info/rfc4
	<title abbrev="Firewall Benchmarking">Firewall Security Assessment and Benchma	301" quoteTitle="true" derivedAnchor="RFC4301">
	rking IPv6 Firewall Load Tests</title>	<front>
	<author initials="E." surname="Zack" fullname="Eldad Zack">	<title>Security Architecture for the Internet Protocol</title>
	</author>	<author fullname="S. Kent" initials="S" surname="Kent"/>
	<date year=""/>	<author fullname="K. Seo" initials="K" surname="Seo"/>
	</front>	<date month="December" year="2005"/>
	<seriesInfo name="" value="IPv6 Hackers Meeting #1, Berlin, Germa	<abstract>
	ny. June 30, 2013"/>	<t indent="0">This document describes an updated version of the "S
	<!-- July 27 - August 1 -->	ecurity Architecture for IP", which is designed to provide security services for
	</reference>	traffic at the IP layer. This document obsoletes RFC 2401 (November 1998). [ST
		ANDARDS-TRACK]</t>
	<reference anchor="Cisco-EH" target="https://www.cisco.com/en/US/technologie	</abstract>
	s/tk648/tk872/technologies_white_paper0900aecd8054d37d.pdf">	</front>
	<front>	<seriesInfo name="RFC" value="4301"/>
	<title abbrev="Cisco IPv6 EH">IPv6 Extension Headers Review and Considerations	<seriesInfo name="DOI" value="10.17487/RFC4301"/>
	</title>	</reference>
	<author initials="" surname="Cisco Systems" fullname="Cisco Systems">	<reference anchor="RFC4302" target="https://www.rfc-editor.org/info/rfc4
		302" quoteTitle="true" derivedAnchor="RFC4302">
		<front>
		<title>IP Authentication Header</title>
		<author fullname="S. Kent" initials="S" surname="Kent"/>
		<date month="December" year="2005"/>
		<abstract>
		<t indent="0">This document describes an updated version of the IP
		Authentication Header (AH), which is designed to provide authentication service
		s in IPv4 and IPv6. This document obsoletes RFC 2402 (November 1998). [STANDARD
		S-TRACK]</t>
		</abstract>
		</front>
		<seriesInfo name="RFC" value="4302"/>
		<seriesInfo name="DOI" value="10.17487/RFC4302"/>
		</reference>
		<reference anchor="RFC4303" target="https://www.rfc-editor.org/info/rfc4
		303" quoteTitle="true" derivedAnchor="RFC4303">
		<front>
		<title>IP Encapsulating Security Payload (ESP)</title>
		<author fullname="S. Kent" initials="S" surname="Kent"/>
		<date month="December" year="2005"/>
		<abstract>
		<t indent="0">This document describes an updated version of the En
		capsulating Security Payload (ESP) protocol, which is designed to provide a mix
		of security services in IPv4 and IPv6. ESP is used to provide confidentiality,
		data origin authentication, connectionless integrity, an anti-replay service (a
		form of partial sequence integrity), and limited traffic flow confidentiality.
		This document obsoletes RFC 2406 (November 1998). [STANDARDS-TRACK]</t>
		</abstract>
		</front>
		<seriesInfo name="RFC" value="4303"/>
		<seriesInfo name="DOI" value="10.17487/RFC4303"/>
		</reference>
		<reference anchor="RFC4727" target="https://www.rfc-editor.org/info/rfc4
		727" quoteTitle="true" derivedAnchor="RFC4727">
		<front>
		<title>Experimental Values In IPv4, IPv6, ICMPv4, ICMPv6, UDP, and T
		CP Headers</title>
		<author fullname="B. Fenner" initials="B" surname="Fenner"/>
		<date month="November" year="2006"/>
		<abstract>
		<t indent="0">When experimenting with or extending protocols, it i
		s often necessary to use some sort of protocol number or constant in order to ac
		tually test or experiment with the new function, even when testing in a closed e
		nvironment. This document reserves some ranges of numbers for experimentation p
		urposes in specific protocols where the need to support experimentation has been
		identified, and it describes the numbers that have already been reserved by oth
		er documents. [STANDARDS-TRACK]</t>
		</abstract>
		</front>
		<seriesInfo name="RFC" value="4727"/>
		<seriesInfo name="DOI" value="10.17487/RFC4727"/>
		</reference>
		<reference anchor="RFC4782" target="https://www.rfc-editor.org/info/rfc4
		782" quoteTitle="true" derivedAnchor="RFC4782">
		<front>
		<title>Quick-Start for TCP and IP</title>
		<author fullname="S. Floyd" initials="S" surname="Floyd"/>
		<author fullname="M. Allman" initials="M" surname="Allman"/>
		<author fullname="A. Jain" initials="A" surname="Jain"/>
		<author fullname="P. Sarolahti" initials="P" surname="Sarolahti"/>
		<date month="January" year="2007"/>
		<abstract>
		<t indent="0">This document specifies an optional Quick-Start mech
		anism for transport protocols, in cooperation with routers, to determine an allo
		wed sending rate at the start and, at times, in the middle of a data transfer (e
		.g., after an idle period). While Quick-Start is designed to be used by a range
		of transport protocols, in this document we only specify its use with TCP. Quick
		-Start is designed to allow connections to use higher sending rates when there i
		s significant unused bandwidth along the path, and the sender and all of the rou
		ters along the path approve the Quick-Start Request.</t>
		<t indent="0">This document describes many paths where Quick-Start
		Requests would not be approved. These paths include all paths containing router
		s, IP tunnels, MPLS paths, and the like that do not support Quick- Start. These
		paths also include paths with routers or middleboxes that drop packets containin
		g IP options. Quick-Start Requests could be difficult to approve over paths that
		include multi-access layer- two networks. This document also describes environm
		ents where the Quick-Start process could fail with false positives, with the sen
		der incorrectly assuming that the Quick-Start Request had been approved by all o
		f the routers along the path. As a result of these concerns, and as a result of
		the difficulties and seeming absence of motivation for routers, such as core rou
		ters to deploy Quick-Start, Quick-Start is being proposed as a mechanism that co
		uld be of use in controlled environments, and not as a mechanism that would be i
		ntended or appropriate for ubiquitous deployment in the global Internet. This me
		mo defines an Experimental Protocol for the Internet community.</t>
		</abstract>
		</front>
		<seriesInfo name="RFC" value="4782"/>
		<seriesInfo name="DOI" value="10.17487/RFC4782"/>
		</reference>
		<reference anchor="RFC5095" target="https://www.rfc-editor.org/info/rfc5
		095" quoteTitle="true" derivedAnchor="RFC5095">
		<front>
		<title>Deprecation of Type 0 Routing Headers in IPv6</title>
		<author fullname="J. Abley" initials="J" surname="Abley"/>
		<author fullname="P. Savola" initials="P" surname="Savola"/>
		<author fullname="G. Neville-Neil" initials="G" surname="Neville-Nei
		l"/>
		<date month="December" year="2007"/>
		<abstract>
		<t indent="0">The functionality provided by IPv6's Type 0 Routing
		Header can be exploited in order to achieve traffic amplification over a remote
		path for the purposes of generating denial-of-service traffic. This document up
		dates the IPv6 specification to deprecate the use of IPv6 Type 0 Routing Headers
		, in light of this security concern. [STANDARDS-TRACK]</t>
		</abstract>
		</front>
		<seriesInfo name="RFC" value="5095"/>
		<seriesInfo name="DOI" value="10.17487/RFC5095"/>
		</reference>
		<reference anchor="RFC5533" target="https://www.rfc-editor.org/info/rfc5
		533" quoteTitle="true" derivedAnchor="RFC5533">
		<front>
		<title>Shim6: Level 3 Multihoming Shim Protocol for IPv6</title>
		<author fullname="E. Nordmark" initials="E" surname="Nordmark"/>
		<author fullname="M. Bagnulo" initials="M" surname="Bagnulo"/>
		<date month="June" year="2009"/>
		<abstract>
		<t indent="0">This document defines the Shim6 protocol, a layer 3
		shim for providing locator agility below the transport protocols, so that multih
		oming can be provided for IPv6 with failover and load-sharing properties, withou
		t assuming that a multihomed site will have a provider-independent IPv6 address
		prefix announced in the global IPv6 routing table. The hosts in a site that has
		multiple provider- allocated IPv6 address prefixes will use the Shim6 protocol
		specified in this document to set up state with peer hosts so that the state can
		later be used to failover to a different locator pair, should the original one
		stop working. [STANDARDS-TRACK]</t>
		</abstract>
		</front>
		<seriesInfo name="RFC" value="5533"/>
		<seriesInfo name="DOI" value="10.17487/RFC5533"/>
		</reference>
		<reference anchor="RFC5570" target="https://www.rfc-editor.org/info/rfc5
		570" quoteTitle="true" derivedAnchor="RFC5570">
		<front>
		<title>Common Architecture Label IPv6 Security Option (CALIPSO)</tit
		le>
		<author fullname="M. StJohns" initials="M" surname="StJohns"/>
		<author fullname="R. Atkinson" initials="R" surname="Atkinson"/>
		<author fullname="G. Thomas" initials="G" surname="Thomas"/>
		<date month="July" year="2009"/>
		<abstract>
		<t indent="0">This document describes an optional method for encod
		ing explicit packet Sensitivity Labels on IPv6 packets. It is intended for use
		only within Multi-Level Secure (MLS) networking environments that are both trust
		ed and trustworthy. This memo provides information for the Internet community.<
		/t>
		</abstract>
		</front>
		<seriesInfo name="RFC" value="5570"/>
		<seriesInfo name="DOI" value="10.17487/RFC5570"/>
		</reference>
		<reference anchor="RFC5971" target="https://www.rfc-editor.org/info/rfc5
		971" quoteTitle="true" derivedAnchor="RFC5971">
		<front>
		<title>GIST: General Internet Signalling Transport</title>
		<author fullname="H. Schulzrinne" initials="H" surname="Schulzrinne"
		/>
		<author fullname="R. Hancock" initials="R" surname="Hancock"/>
		<date month="October" year="2010"/>
		<abstract>
		<t indent="0">This document specifies protocol stacks for the rout
		ing and transport of per-flow signalling messages along the path taken by that f
		low through the network. The design uses existing transport and security protoc
		ols under a common messaging layer, the General Internet Signalling Transport (G
		IST), which provides a common service for diverse signalling applications. GIST
		does not handle signalling application state itself, but manages its own intern
		al state and the configuration of the underlying transport and security protocol
		s to enable the transfer of messages in both directions along the flow path. Th
		e combination of GIST and the lower layer transport and security protocols provi
		des a solution for the base protocol component of the "Next Steps in Signalling"
		(NSIS) framework. This document defines an Experimental Protocol for the Inter
		net community.</t>
		</abstract>
		</front>
		<seriesInfo name="RFC" value="5971"/>
		<seriesInfo name="DOI" value="10.17487/RFC5971"/>
		</reference>
		<reference anchor="RFC6275" target="https://www.rfc-editor.org/info/rfc6
		275" quoteTitle="true" derivedAnchor="RFC6275">
		<front>
		<title>Mobility Support in IPv6</title>
		<author fullname="C. Perkins" initials="C" role="editor" surname="Pe
		rkins"/>
		<author fullname="D. Johnson" initials="D" surname="Johnson"/>
		<author fullname="J. Arkko" initials="J" surname="Arkko"/>
		<date month="July" year="2011"/>
		<abstract>
		<t indent="0">This document specifies Mobile IPv6, a protocol that
		allows nodes to remain reachable while moving around in the IPv6 Internet. Eac
		h mobile node is always identified by its home address, regardless of its curren
		t point of attachment to the Internet. While situated away from its home, a mob
		ile node is also associated with a care-of address, which provides information a
		bout the mobile node's current location. IPv6 packets addressed to a mobile nod
		e's home address are transparently routed to its care-of address. The protocol
		enables IPv6 nodes to cache the binding of a mobile node's home address with its
		care-of address, and to then send any packets destined for the mobile node dire
		ctly to it at this care-of address. To support this operation, Mobile IPv6 defi
		nes a new IPv6 protocol and a new destination option. All IPv6 nodes, whether m
		obile or stationary, can communicate with mobile nodes. This document obsoletes
		RFC 3775. [STANDARDS-TRACK]</t>
		</abstract>
		</front>
		<seriesInfo name="RFC" value="6275"/>
		<seriesInfo name="DOI" value="10.17487/RFC6275"/>
		</reference>
		<reference anchor="RFC6398" target="https://www.rfc-editor.org/info/rfc6
		398" quoteTitle="true" derivedAnchor="RFC6398">
		<front>
		<title>IP Router Alert Considerations and Usage</title>
		<author fullname="F. Le Faucheur" initials="F" role="editor" surname
		="Le Faucheur"/>
		<date month="October" year="2011"/>
		<abstract>
		<t indent="0">The IP Router Alert Option is an IP option that aler
		ts transit routers to more closely examine the contents of an IP packet. The Re
		source reSerVation Protocol (RSVP), Pragmatic General Multicast (PGM), the Inter
		net Group Management Protocol (IGMP), Multicast Listener Discovery (MLD), Multic
		ast Router Discovery (MRD), and General Internet Signaling Transport (GIST) are
		some of the protocols that make use of the IP Router Alert Option. This documen
		t discusses security aspects and usage guidelines around the use of the current
		IP Router Alert Option, thereby updating RFC 2113 and RFC 2711. Specifically, i
		t provides recommendations against using the Router Alert in the end-to-end open
		Internet and identifies controlled environments where protocols depending on Ro
		uter Alert can be used safely. It also provides recommendations about protectio
		n approaches for service providers. Finally, it provides brief guidelines for R
		outer Alert implementation on routers. This memo documents an Internet Best Cur
		rent Practice.</t>
		</abstract>
		</front>
		<seriesInfo name="BCP" value="168"/>
		<seriesInfo name="RFC" value="6398"/>
		<seriesInfo name="DOI" value="10.17487/RFC6398"/>
		</reference>
		<reference anchor="RFC6550" target="https://www.rfc-editor.org/info/rfc6
		550" quoteTitle="true" derivedAnchor="RFC6550">
		<front>
		<title>RPL: IPv6 Routing Protocol for Low-Power and Lossy Networks</
		title>
		<author fullname="T. Winter" initials="T" role="editor" surname="Win
		ter"/>
		<author fullname="P. Thubert" initials="P" role="editor" surname="Th
		ubert"/>
		<author fullname="A. Brandt" initials="A" surname="Brandt"/>
		<author fullname="J. Hui" initials="J" surname="Hui"/>
		<author fullname="R. Kelsey" initials="R" surname="Kelsey"/>
		<author fullname="P. Levis" initials="P" surname="Levis"/>
		<author fullname="K. Pister" initials="K" surname="Pister"/>
		<author fullname="R. Struik" initials="R" surname="Struik"/>
		<author fullname="JP. Vasseur" initials="JP" surname="Vasseur"/>
		<author fullname="R. Alexander" initials="R" surname="Alexander"/>
		<date month="March" year="2012"/>
		<abstract>
		<t indent="0">Low-Power and Lossy Networks (LLNs) are a class of n
		etwork in which both the routers and their interconnect are constrained. LLN ro
		uters typically operate with constraints on processing power, memory, and energy
		(battery power). Their interconnects are characterized by high loss rates, low
		data rates, and instability. LLNs are comprised of anything from a few dozen t
		o thousands of routers. Supported traffic flows include point-to-point (between
		devices inside the LLN), point-to-multipoint (from a central control point to a
		subset of devices inside the LLN), and multipoint-to-point (from devices inside
		the LLN towards a central control point). This document specifies the IPv6 Rou
		ting Protocol for Low-Power and Lossy Networks (RPL), which provides a mechanism
		whereby multipoint-to-point traffic from devices inside the LLN towards a centr
		al control point as well as point-to-multipoint traffic from the central control
		point to the devices inside the LLN are supported. Support for point-to-point
		traffic is also available. [STANDARDS-TRACK]</t>
		</abstract>
		</front>
		<seriesInfo name="RFC" value="6550"/>
		<seriesInfo name="DOI" value="10.17487/RFC6550"/>
		</reference>
		<reference anchor="RFC6553" target="https://www.rfc-editor.org/info/rfc6
		553" quoteTitle="true" derivedAnchor="RFC6553">
		<front>
		<title>The Routing Protocol for Low-Power and Lossy Networks (RPL) O
		ption for Carrying RPL Information in Data-Plane Datagrams</title>
		<author fullname="J. Hui" initials="J" surname="Hui"/>
		<author fullname="JP. Vasseur" initials="JP" surname="Vasseur"/>
		<date month="March" year="2012"/>
		<abstract>
		<t indent="0">The Routing Protocol for Low-Power and Lossy Network
		s (RPL) includes routing information in data-plane datagrams to quickly identify
		inconsistencies in the routing topology. This document describes the RPL Optio
		n for use among RPL routers to include such routing information. [STANDARDS-TRAC
		K]</t>
		</abstract>
		</front>
		<seriesInfo name="RFC" value="6553"/>
		<seriesInfo name="DOI" value="10.17487/RFC6553"/>
		</reference>
		<reference anchor="RFC6554" target="https://www.rfc-editor.org/info/rfc6
		554" quoteTitle="true" derivedAnchor="RFC6554">
		<front>
		<title>An IPv6 Routing Header for Source Routes with the Routing Pro
		tocol for Low-Power and Lossy Networks (RPL)</title>
		<author fullname="J. Hui" initials="J" surname="Hui"/>
		<author fullname="JP. Vasseur" initials="JP" surname="Vasseur"/>
		<author fullname="D. Culler" initials="D" surname="Culler"/>
		<author fullname="V. Manral" initials="V" surname="Manral"/>
		<date month="March" year="2012"/>
		<abstract>
		<t indent="0">In Low-Power and Lossy Networks (LLNs), memory const
		raints on routers may limit them to maintaining, at most, a few routes. In some
		configurations, it is necessary to use these memory-constrained routers to deli
		ver datagrams to nodes within the LLN. The Routing Protocol for Low-Power and L
		ossy Networks (RPL) can be used in some deployments to store most, if not all, r
		outes on one (e.g., the Directed Acyclic Graph (DAG) root) or a few routers and
		forward the IPv6 datagram using a source routing technique to avoid large routin
		g tables on memory-constrained routers. This document specifies a new IPv6 Rout
		ing header type for delivering datagrams within a RPL routing domain. [STANDARDS
		-TRACK]</t>
		</abstract>
		</front>
		<seriesInfo name="RFC" value="6554"/>
		<seriesInfo name="DOI" value="10.17487/RFC6554"/>
		</reference>
		<reference anchor="RFC6621" target="https://www.rfc-editor.org/info/rfc6
		621" quoteTitle="true" derivedAnchor="RFC6621">
		<front>
		<title>Simplified Multicast Forwarding</title>
		<author fullname="J. Macker" initials="J" role="editor" surname="Mac
		ker"/>
		<date month="May" year="2012"/>
		<abstract>
		<t indent="0">This document describes a Simplified Multicast Forwa
		rding (SMF) mechanism that provides basic Internet Protocol (IP) multicast forwa
		rding suitable for limited wireless mesh and mobile ad hoc network (MANET) use.
		It is mainly applicable in situations where efficient flooding represents an ac
		ceptable engineering design trade-off. It defines techniques for multicast dupl
		icate packet detection (DPD), to be applied in the forwarding process, for both
		IPv4 and IPv6 protocol use. This document also specifies optional mechanisms fo
		r using reduced relay sets to achieve more efficient multicast data distribution
		within a mesh topology as compared to Classic Flooding. Interactions with othe
		r protocols, such as use of information provided by concurrently running unicast
		routing protocols or interaction with other multicast protocols, as well as mul
		tiple deployment approaches are also described. Distributed algorithms for sele
		cting reduced relay sets and related discussion are provided in the appendices.
		Basic issues relating to the operation of multicast MANET border routers are di
		scussed, but ongoing work remains in this area and is beyond the scope of this d
		ocument. This document defines an Experimental Protocol for the Internet commun
		ity.</t>
		</abstract>
		</front>
		<seriesInfo name="RFC" value="6621"/>
		<seriesInfo name="DOI" value="10.17487/RFC6621"/>
		</reference>
		<reference anchor="RFC6740" target="https://www.rfc-editor.org/info/rfc6
		740" quoteTitle="true" derivedAnchor="RFC6740">
		<front>
		<title>Identifier-Locator Network Protocol (ILNP) Architectural Desc
		ription</title>
		<author fullname="RJ Atkinson" initials="RJ" surname="Atkinson"/>
		<author fullname="SN Bhatti" initials="SN" surname="Bhatti"/>
		<date month="November" year="2012"/>
		<abstract>
		<t indent="0">This document provides an architectural description
		and the concept of operations for the Identifier-Locator Network Protocol (ILNP)
		, which is an experimental, evolutionary enhancement to IP. This is a product o
		f the IRTF Routing Research Group. This document defines an Experimental Protoc
		ol for the Internet community.</t>
		</abstract>
		</front>
		<seriesInfo name="RFC" value="6740"/>
		<seriesInfo name="DOI" value="10.17487/RFC6740"/>
		</reference>
		<reference anchor="RFC6744" target="https://www.rfc-editor.org/info/rfc6
		744" quoteTitle="true" derivedAnchor="RFC6744">
		<front>
		<title>IPv6 Nonce Destination Option for the Identifier-Locator Netw
		ork Protocol for IPv6 (ILNPv6)</title>
		<author fullname="RJ Atkinson" initials="RJ" surname="Atkinson"/>
		<author fullname="SN Bhatti" initials="SN" surname="Bhatti"/>
		<date month="November" year="2012"/>
		<abstract>
		<t indent="0">The Identifier-Locator Network Protocol (ILNP) is an
		experimental, evolutionary enhancement to IP. ILNP has multiple instantiations
		. This document describes an experimental Nonce Destination Option used only wi
		th ILNP for IPv6 (ILNPv6). This document is a product of the IRTF Routing Resea
		rch Group. This document defines an Experimental Protocol for the Internet comm
		unity.</t>
		</abstract>
		</front>
		<seriesInfo name="RFC" value="6744"/>
		<seriesInfo name="DOI" value="10.17487/RFC6744"/>
		</reference>
		<reference anchor="RFC6788" target="https://www.rfc-editor.org/info/rfc6
		788" quoteTitle="true" derivedAnchor="RFC6788">
		<front>
		<title>The Line-Identification Option</title>
		<author fullname="S. Krishnan" initials="S" surname="Krishnan"/>
		<author fullname="A. Kavanagh" initials="A" surname="Kavanagh"/>
		<author fullname="B. Varga" initials="B" surname="Varga"/>
		<author fullname="S. Ooghe" initials="S" surname="Ooghe"/>
		<author fullname="E. Nordmark" initials="E" surname="Nordmark"/>
		<date month="November" year="2012"/>
		<abstract>
		<t indent="0">In Ethernet-based aggregation networks, several subs
		criber premises may be logically connected to the same interface of an Edge Rout
		er. This document proposes a method for the Edge Router to identify the subscri
		ber premises using the contents of the received Router Solicitation messages. T
		he applicability is limited to broadband network deployment scenarios in which m
		ultiple user ports are mapped to the same virtual interface on the Edge Router.
		[STANDARDS-TRACK]</t>
		</abstract>
		</front>
		<seriesInfo name="RFC" value="6788"/>
		<seriesInfo name="DOI" value="10.17487/RFC6788"/>
		</reference>
		<reference anchor="RFC6971" target="https://www.rfc-editor.org/info/rfc6
		971" quoteTitle="true" derivedAnchor="RFC6971">
		<front>
		<title>Depth-First Forwarding (DFF) in Unreliable Networks</title>
		<author fullname="U. Herberg" initials="U" role="editor" surname="He
		rberg"/>
		<author fullname="A. Cardenas" initials="A" surname="Cardenas"/>
		<author fullname="T. Iwao" initials="T" surname="Iwao"/>
		<author fullname="M. Dow" initials="M" surname="Dow"/>
		<author fullname="S. Cespedes" initials="S" surname="Cespedes"/>
		<date month="June" year="2013"/>
		<abstract>
		<t indent="0">This document specifies the Depth-First Forwarding (
		DFF) protocol for IPv6 networks, a data-forwarding mechanism that can increase r
		eliability of data delivery in networks with dynamic topology and/or lossy links
		. The protocol operates entirely on the forwarding plane but may interact with
		the routing plane. DFF forwards data packets using a mechanism similar to a "de
		pth-first search" for the destination of a packet. The routing plane may be inf
		ormed of failures to deliver a packet or loops. This document specifies the DFF
		mechanism both for IPv6 networks (as specified in RFC 2460) and for "mesh-under
		" Low-Power Wireless Personal Area Networks (LoWPANs), as specified in RFC 4944.
		The design of DFF assumes that the underlying link layer provides means to det
		ect if a packet has been successfully delivered to the Next Hop or not. It is a
		pplicable for networks with little traffic and is used for unicast transmissions
		only.</t>
		</abstract>
		</front>
		<seriesInfo name="RFC" value="6971"/>
		<seriesInfo name="DOI" value="10.17487/RFC6971"/>
		</reference>
		<reference anchor="RFC7045" target="https://www.rfc-editor.org/info/rfc7
		045" quoteTitle="true" derivedAnchor="RFC7045">
		<front>
		<title>Transmission and Processing of IPv6 Extension Headers</title>
		<author fullname="B. Carpenter" initials="B" surname="Carpenter"/>
		<author fullname="S. Jiang" initials="S" surname="Jiang"/>
		<date month="December" year="2013"/>
		<abstract>
		<t indent="0">Various IPv6 extension headers have been standardise
		d since the IPv6 standard was first published. This document updates RFC 2460 t
		o clarify how intermediate nodes should deal with such extension headers and wit
		h any that are defined in the future. It also specifies how extension headers s
		hould be registered by IANA, with a corresponding minor update to RFC 2780.</t>
		</abstract>
		</front>
		<seriesInfo name="RFC" value="7045"/>
		<seriesInfo name="DOI" value="10.17487/RFC7045"/>
		</reference>
		<reference anchor="RFC7112" target="https://www.rfc-editor.org/info/rfc7
		112" quoteTitle="true" derivedAnchor="RFC7112">
		<front>
		<title>Implications of Oversized IPv6 Header Chains</title>
		<author fullname="F. Gont" initials="F" surname="Gont"/>
		<author fullname="V. Manral" initials="V" surname="Manral"/>
		<author fullname="R. Bonica" initials="R" surname="Bonica"/>
		<date month="January" year="2014"/>
		<abstract>
		<t indent="0">The IPv6 specification allows IPv6 Header Chains of
		an arbitrary size. The specification also allows options that can, in turn, ext
		end each of the headers. In those scenarios in which the IPv6 Header Chain or o
		ptions are unusually long and packets are fragmented, or scenarios in which the
		fragment size is very small, the First Fragment of a packet may fail to include
		the entire IPv6 Header Chain. This document discusses the interoperability and
		security problems of such traffic, and updates RFC 2460 such that the First Frag
		ment of a packet is required to contain the entire IPv6 Header Chain.</t>
		</abstract>
		</front>
		<seriesInfo name="RFC" value="7112"/>
		<seriesInfo name="DOI" value="10.17487/RFC7112"/>
		</reference>
		<reference anchor="RFC7401" target="https://www.rfc-editor.org/info/rfc7
		401" quoteTitle="true" derivedAnchor="RFC7401">
		<front>
		<title>Host Identity Protocol Version 2 (HIPv2)</title>
		<author fullname="R. Moskowitz" initials="R" role="editor" surname="
		Moskowitz"/>
		<author fullname="T. Heer" initials="T" surname="Heer"/>
		<author fullname="P. Jokela" initials="P" surname="Jokela"/>
		<author fullname="T. Henderson" initials="T" surname="Henderson"/>
		<date month="April" year="2015"/>
		<abstract>
		<t indent="0">This document specifies the details of the Host Iden
		tity Protocol (HIP). HIP allows consenting hosts to securely establish and maint
		ain shared IP-layer state, allowing separation of the identifier and locator rol
		es of IP addresses, thereby enabling continuity of communications across IP addr
		ess changes. HIP is based on a Diffie-Hellman key exchange, using public key ide
		ntifiers from a new Host Identity namespace for mutual peer authentication. The
		protocol is designed to be resistant to denial-of-service (DoS) and man-in-the-m
		iddle (MitM) attacks. When used together with another suitable security protocol
		, such as the Encapsulating Security Payload (ESP), it provides integrity protec
		tion and optional encryption for upper-layer protocols, such as TCP and UDP.</t>
		<t indent="0">This document obsoletes RFC 5201 and addresses the c
		oncerns raised by the IESG, particularly that of crypto agility. It also incorpo
		rates lessons learned from the implementations of RFC 5201.</t>
		</abstract>
		</front>
		<seriesInfo name="RFC" value="7401"/>
		<seriesInfo name="DOI" value="10.17487/RFC7401"/>
		</reference>
		<reference anchor="RFC7731" target="https://www.rfc-editor.org/info/rfc7
		731" quoteTitle="true" derivedAnchor="RFC7731">
		<front>
		<title>Multicast Protocol for Low-Power and Lossy Networks (MPL)</ti
		tle>
		<author fullname="J. Hui" initials="J" surname="Hui"/>
		<author fullname="R. Kelsey" initials="R" surname="Kelsey"/>
		<date month="February" year="2016"/>
		<abstract>
		<t indent="0">This document specifies the Multicast Protocol for L
		ow-Power and Lossy Networks (MPL), which provides IPv6 multicast forwarding in c
		onstrained networks. MPL avoids the need to construct or maintain any multicast
		forwarding topology, disseminating messages to all MPL Forwarders in an MPL Doma
		in.</t>
		<t indent="0">MPL has two modes of operation. One mode uses the Tr
		ickle algorithm to manage control-plane and data-plane message transmissions and
		is applicable for deployments with few multicast sources. The other mode uses c
		lassic flooding. By providing both modes and parameterization of the Trickle alg
		orithm, an MPL implementation can be used in a variety of multicast deployments
		and can trade between dissemination latency and transmission efficiency.</t>
		</abstract>
		</front>
		<seriesInfo name="RFC" value="7731"/>
		<seriesInfo name="DOI" value="10.17487/RFC7731"/>
		</reference>
		<reference anchor="RFC8174" target="https://www.rfc-editor.org/info/rfc8
		174" quoteTitle="true" derivedAnchor="RFC8174">
		<front>
		<title>Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words</ti
		tle>
		<author fullname="B. Leiba" initials="B" surname="Leiba"/>
		<date month="May" year="2017"/>
		<abstract>
		<t indent="0">RFC 2119 specifies common key words that may be used
		in protocol specifications. This document aims to reduce the ambiguity by clar
		ifying that only UPPERCASE usage of the key words have the defined special meani
		ngs.</t>
		</abstract>
		</front>
		<seriesInfo name="BCP" value="14"/>
		<seriesInfo name="RFC" value="8174"/>
		<seriesInfo name="DOI" value="10.17487/RFC8174"/>
		</reference>
		<reference anchor="RFC8200" target="https://www.rfc-editor.org/info/rfc8
		200" quoteTitle="true" derivedAnchor="RFC8200">
		<front>
		<title>Internet Protocol, Version 6 (IPv6) Specification</title>
		<author fullname="S. Deering" initials="S" surname="Deering"/>
		<author fullname="R. Hinden" initials="R" surname="Hinden"/>
		<date month="July" year="2017"/>
		<abstract>
		<t indent="0">This document specifies version 6 of the Internet Pr
		otocol (IPv6). It obsoletes RFC 2460.</t>
		</abstract>
		</front>
		<seriesInfo name="STD" value="86"/>
		<seriesInfo name="RFC" value="8200"/>
		<seriesInfo name="DOI" value="10.17487/RFC8200"/>
		</reference>
		<reference anchor="RFC8250" target="https://www.rfc-editor.org/info/rfc8
		250" quoteTitle="true" derivedAnchor="RFC8250">
		<front>
		<title>IPv6 Performance and Diagnostic Metrics (PDM) Destination Opt
		ion</title>
		<author fullname="N. Elkins" initials="N" surname="Elkins"/>
		<author fullname="R. Hamilton" initials="R" surname="Hamilton"/>
		<author fullname="M. Ackermann" initials="M" surname="Ackermann"/>
		<date month="September" year="2017"/>
		<abstract>
		<t indent="0">To assess performance problems, this document descri
		bes optional headers embedded in each packet that provide sequence numbers and t
		iming information as a basis for measurements. Such measurements may be interpr
		eted in real time or after the fact. This document specifies the Performance an
		d Diagnostic Metrics (PDM) Destination Options header. The field limits, calcul
		ations, and usage in measurement of PDM are included in this document.</t>
		</abstract>
		</front>
		<seriesInfo name="RFC" value="8250"/>
		<seriesInfo name="DOI" value="10.17487/RFC8250"/>
		</reference>
		<reference anchor="RFC8754" target="https://www.rfc-editor.org/info/rfc8
		754" quoteTitle="true" derivedAnchor="RFC8754">
		<front>
		<title>IPv6 Segment Routing Header (SRH)</title>
		<author fullname="C. Filsfils" initials="C" role="editor" surname="F
		ilsfils"/>
		<author fullname="D. Dukes" initials="D" role="editor" surname="Duke
		s"/>
		<author fullname="S. Previdi" initials="S" surname="Previdi"/>
		<author fullname="J. Leddy" initials="J" surname="Leddy"/>
		<author fullname="S. Matsushima" initials="S" surname="Matsushima"/>
		<author fullname="D. Voyer" initials="D" surname="Voyer"/>
		<date month="March" year="2020"/>
		<abstract>
		<t indent="0">Segment Routing can be applied to the IPv6 data plan
		e using a new type of Routing Extension Header called the Segment Routing Header
		(SRH). This document describes the SRH and how it is used by nodes that are Se
		gment Routing (SR) capable.</t>
		</abstract>
		</front>
		<seriesInfo name="RFC" value="8754"/>
		<seriesInfo name="DOI" value="10.17487/RFC8754"/>
		</reference>
		<reference anchor="RFC8900" target="https://www.rfc-editor.org/info/rfc8
		900" quoteTitle="true" derivedAnchor="RFC8900">
		<front>
		<title>IP Fragmentation Considered Fragile</title>
		<author fullname="R. Bonica" initials="R" surname="Bonica"/>
		<author fullname="F. Baker" initials="F" surname="Baker"/>
		<author fullname="G. Huston" initials="G" surname="Huston"/>
		<author fullname="R. Hinden" initials="R" surname="Hinden"/>
		<author fullname="O. Troan" initials="O" surname="Troan"/>
		<author fullname="F. Gont" initials="F" surname="Gont"/>
		<date month="September" year="2020"/>
		<abstract>
		<t indent="0">This document describes IP fragmentation and explain
		s how it introduces fragility to Internet communication.</t>
		<t indent="0">This document also proposes alternatives to IP fragm
		entation and provides recommendations for developers and network operators.</t>
		</abstract>
		</front>
		<seriesInfo name="BCP" value="230"/>
		<seriesInfo name="RFC" value="8900"/>
		<seriesInfo name="DOI" value="10.17487/RFC8900"/>
		</reference>
		<reference anchor="RFC9008" target="https://www.rfc-editor.org/info/rfc9
		008" quoteTitle="true" derivedAnchor="RFC9008">
		<front>
		<title>Using RPI Option Type, Routing Header for Source Routes, and
		IPv6-in-IPv6 Encapsulation in the RPL Data Plane</title>
		<author initials="M.I." surname="Robles" fullname="M.I. Robles">
		<organization showOnFrontPage="true"/>
		</author>
		<author initials="M." surname="Richardson" fullname="M. Richardson">
		<organization showOnFrontPage="true"/>
		</author>
		<author initials="P." surname="Thubert" fullname="P. Thubert">
		<organization showOnFrontPage="true"/>
		</author>
		<date year="2021" month="April"/>
		<abstract>
		<t indent="0">This document looks at different data flows through
		Low-Power and Lossy Networks (LLN) where RPL (IPv6 Routing Protocol for Low-Powe
		r and Lossy Networks) is used to establish routing. The document enumerates the
		cases where RPL Packet Information (RPI) Option Type (RFC 6553), RPL Source Rout
		e Header (RFC 6554), and IPv6-in-IPv6 encapsulation are required in the data pla
		ne. This analysis provides the basis upon which to design efficient compression
		of these headers. This document updates RFC 6553 by adding a change to the RPI O
		ption Type. Additionally, this document updates RFC 6550 by defining a flag in t
		he DODAG Information Object (DIO) Configuration option to indicate this change a
		nd updates RFC 8138 as well to consider the new Option Type when the RPL Option
		is decompressed.</t>
		</abstract>
		</front>
		<seriesInfo name="RFC" value="9008"/>
		<seriesInfo name="DOI" value="10.17487/RFC9008"/>
		</reference>
		</references>
		<references pn="section-8.2">
		<name slugifiedName="name-informative-references">Informative References
		</name>
		<reference anchor="Biondi-2007" target="http://www.secdev.org/conf/IPv6_
		RH_security-csw07.pdf" quoteTitle="true" derivedAnchor="Biondi-2007">
		<front>
		<title>IPv6 Routing Header Security</title>
		<author fullname="P. Biondi" initials="P." surname="Biondi">
		<organization showOnFrontPage="true"/>
		</author>
		<author fullname="A. Ebalard" initials="A." surname="Ebalard">
		<organization showOnFrontPage="true"/>
		</author>
		<date month="April" year="2007"/>
		</front>
		<refcontent>CanSecWest Security Conference</refcontent>
		</reference>
		<reference anchor="Cisco-EH" target="https://www.cisco.com/en/US/technol
		ogies/tk648/tk872/technologies_white_paper0900aecd8054d37d.pdf" quoteTitle="true
		" derivedAnchor="Cisco-EH">
		<front>
		<title abbrev="Cisco IPv6 EH">IPv6 Extension Headers Review and Cons
		iderations</title>
		<author initials="" surname="" fullname="">
		<organization showOnFrontPage="true">Cisco Systems</organization>
		</author>
		<date month="October" year="2006"/>
		</front>
		<refcontent>Whitepaper</refcontent>
		</reference>
		<reference anchor="FW-Benchmark" target="https://www.ipv6hackers.org/fil
		es/meetings/ipv6-hackers-1/zack-ipv6hackers1-firewall-security-assessment-and-be
		nchmarking.pdf" quoteTitle="true" derivedAnchor="FW-Benchmark">
		<front>
		<title abbrev="Firewall Benchmarking">Firewall Security Assessment a
		nd Benchmarking IPv6 Firewall Load Tests</title>
		<author initials="E." surname="Zack" fullname="Eldad Zack">
	</author>	</author>

	<date year=""/>	<date month="June" year="2013"/>
	</front>	</front>
	<seriesInfo name="" value="Whitepaper. October 2006"/>	<refcontent>IPv6 Hackers Meeting #1, Berlin, Germany</refcontent>
	<!-- July 27 - August 1 -->	</reference>
	</reference>	<reference anchor="Huston-2022" target="https://iepg.org/2022-03-20-ietf
		113/huston-v6frag.pdf" quoteTitle="true" derivedAnchor="Huston-2022">
	<reference anchor="draft-gont-6man-ipv6-opt-transmit">	<front>
	<front>	<title>IPv6 Fragmentation and EH Behaviours</title>
	<title>Transmission and Processing of IPv6 Options</title>	<author fullname="Geoff Huston" initials="G." surname="Huston">
		<organization abbrev="APNIC" showOnFrontPage="true"/>
	<author fullname="Fernando Gont" initials="F." surname="Gont">	<address>
	<organization>SI6 Networks / UTN-FRH</organization>	<email>gih@apnic.net</email>
	</author>	<uri>https://www.apnic.net</uri>
	<author fullname="Will Liu" initials="W." surname="Liu">	</address>
	<organization></organization>	</author>
	</author>	<author fullname="Joao Damas" initials="J." surname="Damas">
	<author fullname="Ron Bonica" initials="R." surname="Bonica">	<organization abbrev="APNIC" showOnFrontPage="true"/>
	<organization></organization>	</author>
	</author>	<date month="March" year="2022"/>
	<date month="August" year="2014"/>	</front>
	</front>	<refcontent>IEPG Meeting at IETF 113"</refcontent>
		</reference>
		<reference anchor="IANA-IPV6-PARAM" target="https://www.iana.org/assignm
		ents/ipv6-parameters" quoteTitle="true" derivedAnchor="IANA-IPV6-PARAM">
		<front>
		<title>Internet Protocol Version 6 (IPv6) Parameters</title>
		<author>
		<organization showOnFrontPage="true">IANA</organization>
		</author>
		</front>
		</reference>
		<reference anchor="IANA-PROTOCOLS" target="https://www.iana.org/assignme
		nts/protocol-numbers" quoteTitle="true" derivedAnchor="IANA-PROTOCOLS">
		<front>
		<title>Protocol Numbers</title>
		<author>
		<organization showOnFrontPage="true">IANA</organization>
		</author>
		</front>
		</reference>
		<reference anchor="I-D.gont-6man-ipv6-opt-transmit" quoteTitle="true" ta
		rget="https://datatracker.ietf.org/doc/html/draft-gont-6man-ipv6-opt-transmit-02
		" derivedAnchor="IPv6-OPTIONS">
		<front>
		<title>Transmission and Processing of IPv6 Options</title>
		<author fullname="Fernando Gont">
		</author>
		<author fullname="Will(Shucheng) Liu">
		</author>
		<author fullname="Ronald P. Bonica">
		</author>
		<date month="August" day="21" year="2015"/>
		<abstract>
		<t indent="0"> Various IPv6 options have been standardized since
		the core IPv6
		standard was first published. This document updates RFC 2460 to
		clarify how nodes should deal with such IPv6 options and with any
		options that are defined in the future. It complements [RFC7045],
		which offers a similar clarification regarding IPv6 Extension
		Headers.


	<seriesInfo name=""	</t>
	value="IETF Internet Draft, work in progress"/>	</abstract>
	</reference>	</front>
		<seriesInfo name="Internet-Draft" value="draft-gont-6man-ipv6-opt-tran
		smit-02"/>
		<format type="TXT" target="https://www.ietf.org/archive/id/draft-gont-
		6man-ipv6-opt-transmit-02.txt"/>
		<refcontent>Work in Progress</refcontent>
		</reference>
		<reference anchor="I-D.vyncke-v6ops-james" quoteTitle="true" target="htt
		ps://datatracker.ietf.org/doc/html/draft-vyncke-v6ops-james-02" derivedAnchor="J
		AMES">
		<front>
		<title>Just Another Measurement of Extension header Survivability (J
		AMES)</title>
		<author fullname="Justin Iurman">
		</author>
		<date month="July" day="11" year="2022"/>
		<abstract>
		<t indent="0"> In 2016, RFC7872 has measured the drop of packets
		with IPv6 extension
		headers. This document presents a slightly different methodology
		with more recent results. It is still work in progress.


	</references>	</t>
		</abstract>
		</front>
		<seriesInfo name="Internet-Draft" value="draft-vyncke-v6ops-james-02"/
		>
		<format type="TXT" target="https://www.ietf.org/archive/id/draft-vynck
		e-v6ops-james-02.txt"/>
		<refcontent>Work in Progress</refcontent>
		</reference>
		<reference anchor="NIMROD-DOC" target="http://ana-3.lcs.mit.edu/~jnc/nim
		rod" quoteTitle="true" derivedAnchor="NIMROD-DOC">
		<front>
		<title>Nimrod Documentation</title>
		<author/>
		</front>
		</reference>
		<reference anchor="NIMROD-EID" quoteTitle="true" target="https://datatra
		cker.ietf.org/doc/html/draft-ietf-nimrod-eid-00" derivedAnchor="NIMROD-EID">
		<front>
		<title>Endpoint Identifier Destination Option</title>
		<author initials="C." surname="Lynn" fullname="Dr. Charles W. Lynn J
		r.">
		</author>
		<date month="March" day="2" year="1996"/>
		</front>
		<seriesInfo name="Internet-Draft" value="draft-ietf-nimrod-eid-00"/>
		<refcontent>Work in Progress</refcontent>
		</reference>
		<reference anchor="I-D.irtf-pearg-numeric-ids-generation" quoteTitle="tr
		ue" target="https://datatracker.ietf.org/doc/html/draft-irtf-pearg-numeric-ids-g
		eneration-11" derivedAnchor="NUMERIC-IDS">
		<front>
		<title>On the Generation of Transient Numeric Identifiers</title>
		<author fullname="Fernando Gont">
		<organization showOnFrontPage="true">SI6 Networks</organization>
		</author>
		<author fullname="Ivan Arce">
		<organization showOnFrontPage="true">Quarkslab</organization>
		</author>
		<date month="July" day="11" year="2022"/>
		<abstract>
		<t indent="0"> This document performs an analysis of the securit
		y and privacy
		implications of different types of "transient numeric identifiers"
		used in IETF protocols, and tries to categorize them based on their
		interoperability requirements and their associated failure severity
		when such requirements are not met. Subsequently, it provides advice
		on possible algorithms that could be employed to satisfy the
		interoperability requirements of each identifier category, while
		minimizing the negative security and privacy implications, thus
		providing guidance to protocol designers and protocol implementers.
		Finally, it describes a number of algorithms that have been employed
		in real implementations to generate transient numeric identifiers,
		and analyzes their security and privacy properties. This document is
		a product of the Privacy Enhancement and Assessment Research Group
		(PEARG) in the IRTF.


	</back>	</t>
		</abstract>
		</front>
		<seriesInfo name="Internet-Draft" value="draft-irtf-pearg-numeric-ids-
		generation-11"/>
		<format type="TXT" target="https://www.ietf.org/archive/id/draft-irtf-
		pearg-numeric-ids-generation-11.txt"/>
		<refcontent>Work in Progress</refcontent>
		</reference>
		<reference anchor="RFC2460" target="https://www.rfc-editor.org/info/rfc2
		460" quoteTitle="true" derivedAnchor="RFC2460">
		<front>
		<title>Internet Protocol, Version 6 (IPv6) Specification</title>
		<author fullname="S. Deering" initials="S" surname="Deering"/>
		<author fullname="R. Hinden" initials="R" surname="Hinden"/>
		<date month="December" year="1998"/>
		<abstract>
		<t indent="0">This document specifies version 6 of the Internet Pr
		otocol (IPv6), also sometimes referred to as IP Next Generation or IPng. [STANDA
		RDS-TRACK]</t>
		</abstract>
		</front>
		<seriesInfo name="RFC" value="2460"/>
		<seriesInfo name="DOI" value="10.17487/RFC2460"/>
		</reference>
		<reference anchor="RFC3871" target="https://www.rfc-editor.org/info/rfc3
		871" quoteTitle="true" derivedAnchor="RFC3871">
		<front>
		<title>Operational Security Requirements for Large Internet Service
		Provider (ISP) IP Network Infrastructure</title>
		<author fullname="G. Jones" initials="G" role="editor" surname="Jone
		s"/>
		<date month="September" year="2004"/>
		<abstract>
		<t indent="0">This document defines a list of operational security
		requirements for the infrastructure of large Internet Service Provider (ISP) IP
		networks (routers and switches). A framework is defined for specifying "profil
		es", which are collections of requirements applicable to certain network topolog
		y contexts (all, core-only, edge-only...). The goal is to provide network opera
		tors a clear, concise way of communicating their security requirements to vendor
		s. This memo provides information for the Internet community.</t>
		</abstract>
		</front>
		<seriesInfo name="RFC" value="3871"/>
		<seriesInfo name="DOI" value="10.17487/RFC3871"/>
		</reference>
		<reference anchor="RFC6192" target="https://www.rfc-editor.org/info/rfc6
		192" quoteTitle="true" derivedAnchor="RFC6192">
		<front>
		<title>Protecting the Router Control Plane</title>
		<author fullname="D. Dugal" initials="D" surname="Dugal"/>
		<author fullname="C. Pignataro" initials="C" surname="Pignataro"/>
		<author fullname="R. Dunn" initials="R" surname="Dunn"/>
		<date month="March" year="2011"/>
		<abstract>
		<t indent="0">This memo provides a method for protecting a router'
		s control plane from undesired or malicious traffic. In this approach, all legit
		imate router control plane traffic is identified. Once legitimate traffic has be
		en identified, a filter is deployed in the router's forwarding plane. That filte
		r prevents traffic not specifically identified as legitimate from reaching the r
		outer's control plane, or rate-limits such traffic to an acceptable level.</t>
		<t indent="0">Note that the filters described in this memo are app
		lied only to traffic that is destined for the router, and not to all traffic tha
		t is passing through the router. This document is not an Internet Standards Trac
		k specification; it is published for informational purposes.</t>
		</abstract>
		</front>
		<seriesInfo name="RFC" value="6192"/>
		<seriesInfo name="DOI" value="10.17487/RFC6192"/>
		</reference>
		<reference anchor="RFC7126" target="https://www.rfc-editor.org/info/rfc7
		126" quoteTitle="true" derivedAnchor="RFC7126">
		<front>
		<title>Recommendations on Filtering of IPv4 Packets Containing IPv4
		Options</title>
		<author fullname="F. Gont" initials="F" surname="Gont"/>
		<author fullname="R. Atkinson" initials="R" surname="Atkinson"/>
		<author fullname="C. Pignataro" initials="C" surname="Pignataro"/>
		<date month="February" year="2014"/>
		<abstract>
		<t indent="0">This document provides advice on the filtering of IP
		v4 packets based on the IPv4 options they contain. Additionally, it discusses t
		he operational and interoperability implications of dropping packets based on th
		e IP options they contain.</t>
		</abstract>
		</front>
		<seriesInfo name="BCP" value="186"/>
		<seriesInfo name="RFC" value="7126"/>
		<seriesInfo name="DOI" value="10.17487/RFC7126"/>
		</reference>
		<reference anchor="RFC7739" target="https://www.rfc-editor.org/info/rfc7
		739" quoteTitle="true" derivedAnchor="RFC7739">
		<front>
		<title>Security Implications of Predictable Fragment Identification
		Values</title>
		<author fullname="F. Gont" initials="F" surname="Gont"/>
		<date month="February" year="2016"/>
		<abstract>
		<t indent="0">IPv6 specifies the Fragment Header, which is employe
		d for the fragmentation and reassembly mechanisms. The Fragment Header contains
		an "Identification" field that, together with the IPv6 Source Address and the I
		Pv6 Destination Address of a packet, identifies fragments that correspond to the
		same original datagram, such that they can be reassembled together by the recei
		ving host. The only requirement for setting the Identification field is that th
		e corresponding value must be different than that employed for any other fragmen
		ted datagram sent recently with the same Source Address and Destination Address.
		Some implementations use a simple global counter for setting the Identificatio
		n field, thus leading to predictable Identification values. This document analy
		zes the security implications of predictable Identification values, and provides
		implementation guidance for setting the Identification field of the Fragment He
		ader, such that the aforementioned security implications are mitigated.</t>
		</abstract>
		</front>
		<seriesInfo name="RFC" value="7739"/>
		<seriesInfo name="DOI" value="10.17487/RFC7739"/>
		</reference>
		<reference anchor="RFC7872" target="https://www.rfc-editor.org/info/rfc7
		872" quoteTitle="true" derivedAnchor="RFC7872">
		<front>
		<title>Observations on the Dropping of Packets with IPv6 Extension H
		eaders in the Real World</title>
		<author fullname="F. Gont" initials="F" surname="Gont"/>
		<author fullname="J. Linkova" initials="J" surname="Linkova"/>
		<author fullname="T. Chown" initials="T" surname="Chown"/>
		<author fullname="W. Liu" initials="W" surname="Liu"/>
		<date month="June" year="2016"/>
		<abstract>
		<t indent="0">This document presents real-world data regarding the
		extent to which packets with IPv6 Extension Headers (EHs) are dropped in the In
		ternet (as originally measured in August 2014 and later in June 2015, with simil
		ar results) and where in the network such dropping occurs. The aforementioned r
		esults serve as a problem statement that is expected to trigger operational advi
		ce on the filtering of IPv6 packets carrying IPv6 EHs so that the situation impr
		oves over time. This document also explains how the results were obtained, such
		that the corresponding measurements can be reproduced by other members of the c
		ommunity and repeated over time to observe changes in the handling of packets wi
		th IPv6 EHs.</t>
		</abstract>
		</front>
		<seriesInfo name="RFC" value="7872"/>
		<seriesInfo name="DOI" value="10.17487/RFC7872"/>
		</reference>
		<reference anchor="RFC9098" target="https://www.rfc-editor.org/info/rfc9
		098" quoteTitle="true" derivedAnchor="RFC9098">
		<front>
		<title>Operational Implications of IPv6 Packets with Extension Heade
		rs</title>
		<author fullname="F. Gont" initials="F" surname="Gont"/>
		<author fullname="N. Hilliard" initials="N" surname="Hilliard"/>
		<author fullname="G. Doering" initials="G" surname="Doering"/>
		<author fullname="W. Kumari" initials="W" surname="Kumari"/>
		<author fullname="G. Huston" initials="G" surname="Huston"/>
		<author fullname="W. Liu" initials="W" surname="Liu"/>
		<date month="September" year="2021"/>
		<abstract>
		<t indent="0">This document summarizes the operational implication
		s of IPv6 extension headers specified in the IPv6 protocol specification (RFC 82
		00) and attempts to analyze reasons why packets with IPv6 extension headers are
		often dropped in the public Internet.</t>
		</abstract>
		</front>
		<seriesInfo name="RFC" value="9098"/>
		<seriesInfo name="DOI" value="10.17487/RFC9098"/>
		</reference>
		</references>
		</references>
		<section numbered="false" toc="include" removeInRFC="false" pn="section-appe
		ndix.a">
		<name slugifiedName="name-acknowledgements">Acknowledgements</name>
		<t indent="0" pn="section-appendix.a-1">The authors would like to thank <c
		ontact fullname="Ron Bonica"/> for his work on earlier draft versions of this do
		cument.</t>
		<t indent="0" pn="section-appendix.a-2">The authors of this document would
		like to thank (in alphabetical order) <contact fullname="Mikael Abrahamsson"/>,
		<contact fullname="Brian Carpenter"/>, <contact fullname="Tim Chown"/>, <contac
		t fullname="Roman Danyliw"/>, <contact fullname="Darren Dukes"/>, <contact fulln
		ame="Lars Eggert"/>, <contact fullname="David Farmer"/>, <contact fullname="Mike
		Heard"/>, <contact fullname="Bob Hinden"/>, <contact fullname="Christian Huitem
		a"/>, <contact fullname="Benjamin Kaduk"/>, <contact fullname="Erik Kline"/>, <c
		ontact fullname="Murray Kucherawy"/>, <contact fullname="Jen Linkova"/>, <contac
		t fullname="Carlos Pignataro"/>, <contact fullname="Alvaro Retana"/>, <contact f
		ullname="Maria Ines Robles"/>, <contact fullname="Zaheduzzaman Sarker"/>, <conta
		ct fullname="Donald Smith"/>, <contact fullname="Pascal Thubert"/>, <contact ful
		lname="Ole Troan"/>, <contact fullname="Gunter Van de Velde"/>, <contact fullnam
		e="Éric Vyncke"/>, and <contact fullname="Robert Wilton"/> for providing valuabl
		e comments on earlier draft versions of this document.</t>
		<t indent="0" pn="section-appendix.a-3">This document borrows some text an
		d analysis from <xref target="RFC7126" format="default" sectionFormat="of" deriv
		edContent="RFC7126"/>, which is authored by <contact fullname="Fernando Gont"/>,
		<contact fullname="Randall Atkinson"/>, and <contact fullname="Carlos Pignataro
		"/>.</t>
		<t indent="0" pn="section-appendix.a-4">The authors would like to thank <c
		ontact fullname="Warren Kumari"/> and <contact fullname="Éric Vyncke"/> for thei
		r guidance during the publication process for this document.</t>
		<t indent="0" pn="section-appendix.a-5">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 th
		at have benefited his protocol-related work (including the present document).</t
		>
		</section>
		<section anchor="authors-addresses" numbered="false" removeInRFC="false" toc
		="include" pn="section-appendix.b">
		<name slugifiedName="name-authors-addresses">Authors' Addresses</name>
		<author fullname="Fernando Gont" initials="F." surname="Gont">
		<organization abbrev="SI6 Networks" showOnFrontPage="true">SI6 Networks<
		/organization>
		<address>
		<postal>
		<street>Segurola y Habana 4310 7mo piso</street>
		<city>Ciudad Autonoma de Buenos Aires</city>
		<country>Argentina</country>
		</postal>
		<email>fgont@si6networks.com</email>
		<uri>https://www.si6networks.com</uri>
		</address>
		</author>
		<author fullname="Will (Shucheng) Liu" initials="W." surname="Liu">
		<organization showOnFrontPage="true">Huawei Technologies</organization>
		<address>
		<postal>
		<street>Bantian, Longgang District</street>
		<city>Shenzhen</city>
		<code>518129</code>
		<country>China</country>
		</postal>
		<email>liushucheng@huawei.com</email>
		</address>
		</author>
		</section>
		</back>
	</rfc>	</rfc>

End of changes. 63 change blocks.
	1725 lines changed or deleted	3703 lines changed or added
This html diff was produced by rfcdiff 1.48.