rfc9288.original		rfc9288.txt
	opsec F. Gont		Internet Engineering Task Force (IETF) F. Gont
	Internet-Draft EdgeUno		Request for Comments: 9288 SI6 Networks
	Intended status: Informational W. Liu		Category: Informational W. Liu
	Expires: 4 November 2022 Huawei Technologies		ISSN: 2070-1721 Huawei Technologies
	3 May 2022		August 2022
	Recommendations on the Filtering of IPv6 Packets Containing IPv6		Recommendations on the Filtering of IPv6 Packets Containing IPv6
	Extension Headers at Transit Routers		Extension Headers at Transit Routers
	draft-ietf-opsec-ipv6-eh-filtering-10
	Abstract		Abstract
	This document analyzes the security implications of IPv6 Extension		This document analyzes the security implications of IPv6 Extension
	Headers and associated IPv6 options. Additionally, it discusses the		Headers and associated IPv6 options. Additionally, it discusses the
	operational and interoperability implications of discarding packets		operational and interoperability implications of discarding packets
	based on the IPv6 Extension Headers and IPv6 options they contain.		based on the IPv6 Extension Headers and IPv6 options they contain.
	Finally, it provides advice on the filtering of such IPv6 packets at		Finally, it provides advice on the filtering of such IPv6 packets at
	transit routers for traffic not directed to them, for those cases		transit routers for traffic not directed to them, for those cases
	where such filtering is deemed as necessary.		where such filtering is deemed as necessary.
	Status of This Memo		Status of This Memo
	This Internet-Draft is submitted in full conformance with the		This document is not an Internet Standards Track specification; it is
	provisions of BCP 78 and BCP 79.		published for informational purposes.
	Internet-Drafts are working documents of the Internet Engineering
	Task Force (IETF). Note that other groups may also distribute
	working documents as Internet-Drafts. The list of current Internet-
	Drafts is at https://datatracker.ietf.org/drafts/current/.
	Internet-Drafts are draft documents valid for a maximum of six months		This document is a product of the Internet Engineering Task Force
	and may be updated, replaced, or obsoleted by other documents at any		(IETF). It represents the consensus of the IETF community. It has
	time. It is inappropriate to use Internet-Drafts as reference		received public review and has been approved for publication by the
	material or to cite them other than as "work in progress."		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.
	This Internet-Draft will expire on 4 November 2022.		Information about the current status of this document, any errata,
			and how to provide feedback on it may be obtained at
			https://www.rfc-editor.org/info/rfc9288.
	Copyright Notice		Copyright Notice
	Copyright (c) 2022 IETF Trust and the persons identified as the		Copyright (c) 2022 IETF Trust and the persons identified as the
	document authors. All rights reserved.		document authors. All rights reserved.
	This document is subject to BCP 78 and the IETF Trust's Legal		This document is subject to BCP 78 and the IETF Trust's Legal
	Provisions Relating to IETF Documents (https://trustee.ietf.org/		Provisions Relating to IETF Documents
	license-info) in effect on the date of publication of this document.		(https://trustee.ietf.org/license-info) in effect on the date of
	Please review these documents carefully, as they describe your rights		publication of this document. Please review these documents
	and restrictions with respect to this document. Code Components		carefully, as they describe your rights and restrictions with respect
	extracted from this document must include Revised BSD License text as		to this document. Code Components extracted from this document must
	described in Section 4.e of the Trust Legal Provisions and are		include Revised BSD License text as described in Section 4.e of the
	provided without warranty as described in the Revised BSD License.		Trust Legal Provisions and are provided without warranty as described
			in the Revised BSD License.
	Table of Contents		Table of Contents
	1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2		1. Introduction
	2. Terminology and Assumptions Employed in This Document . . . . 4		2. Terminology and Assumptions Employed in This Document
	2.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 4		2.1. Terminology
	2.2. Applicability Statement . . . . . . . . . . . . . . . . . 4		2.2. Applicability Statement
	2.3. Router Default Behavior and Features . . . . . . . . . . 4		2.3. Router Default Behavior and Features
	3. IPv6 Extension Headers . . . . . . . . . . . . . . . . . . . 5		3. IPv6 Extension Headers
	3.1. General Discussion . . . . . . . . . . . . . . . . . . . 5		3.1. General Discussion
	3.2. General Security Implications . . . . . . . . . . . . . . 6		3.2. General Security Implications
	3.3. Rationale for Our Advice on the Handling of IPv6 Packets		3.3. Rationale for Our Advice on the Handling of IPv6 Packets
	with Specific IPv6 Extension Headers . . . . . . . . . . 6		with Specific IPv6 Extension Headers
	3.4. Summary of Advice on the Handling of IPv6 Packets with		3.4. Summary of Advice on the Handling of IPv6 Packets with
	Specific IPv6 Extension Headers . . . . . . . . . . . . . 6		Specific IPv6 Extension Headers
	3.5. Advice on the Handling of IPv6 Packets with Specific IPv6		3.5. Advice on the Handling of IPv6 Packets with Specific IPv6
	Extension Headers . . . . . . . . . . . . . . . . . . . . 7		Extension Headers
	3.6. Advice on the Handling of Packets with Unknown IPv6		3.6. Advice on the Handling of Packets with Unknown IPv6
	Extension Headers . . . . . . . . . . . . . . . . . . . . 16		Extension Headers
	4. IPv6 Options . . . . . . . . . . . . . . . . . . . . . . . . 17		4. IPv6 Options
	4.1. General Discussion . . . . . . . . . . . . . . . . . . . 17		4.1. General Discussion
	4.2. General Security Implications of IPv6 Options . . . . . . 17		4.2. General Security Implications of IPv6 Options
	4.3. Summary of Advice on the Handling of IPv6 Packets with		4.3. Summary of Advice on the Handling of IPv6 Packets with
	Specific IPv6 Extension Headers . . . . . . . . . . . . . 18		Specific IPv6 Options
	4.4. Advice on the Handling of Packets with Specific IPv6		4.4. Advice on the Handling of Packets with Specific IPv6
	Options . . . . . . . . . . . . . . . . . . . . . . . . . 19		Options
	4.5. Advice on the handling of Packets with Unknown IPv6		4.5. Advice on the Handling of Packets with Unknown IPv6 Options
	Options . . . . . . . . . . . . . . . . . . . . . . . . . 32		5. IANA Considerations
	5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 32		6. Privacy Considerations
	6. Privacy Considerations . . . . . . . . . . . . . . . . . . . 32		7. Security Considerations
	7. Security Considerations . . . . . . . . . . . . . . . . . . . 32		8. References
	8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 33		8.1. Normative References
	9. References . . . . . . . . . . . . . . . . . . . . . . . . . 33		8.2. Informative References
	9.1. Normative References . . . . . . . . . . . . . . . . . . 33		Acknowledgements
	9.2. Informative References . . . . . . . . . . . . . . . . . 37		Authors' Addresses
	Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 39
	1. Introduction		1. Introduction
	IPv6 Extension Headers (EHs) allow for the extension of the IPv6		IPv6 Extension Headers (EHs) allow for the extension of the IPv6
	protocol, and provide support for core functionality such as IPv6		protocol and provide support for core functionality, such as IPv6
	fragmentation. However, common implementation limitations suggest		fragmentation. However, common implementation limitations suggest
	that EHs present a challenge for IPv6 packet routing equipment,		that EHs present a challenge for IPv6 packet routing equipment,
	particularly when the IPv6 header chain needs to be processed for		particularly when the IPv6 header chain needs to be processed for, as
	e.g. enforcing ACLs or implementing other functions [RFC9098].		an example, enforcing Access Control Lists (ACLs) or implementing
			other functions [RFC9098].
	Several studies (e.g. [Huston-2022], [I-D.vyncke-v6ops-james], and		Several studies (e.g., [Huston-2022], [JAMES], and [RFC7872]) suggest
	[RFC7872]) suggest that there is widespread dropping of IPv6 packets		that there is widespread dropping of IPv6 packets that contain IPv6
	that contain IPv6 Extension Headers (EHs). In some cases, such		EHs. In some cases, such packet drops occur at transit routers.
	packet drops occur at transit routers. While some operators are		While some operators are known to intentionally drop packets that
	known to intentionally drop packets that contain IPv6 EHs, it is		contain IPv6 EHs, it is possible that some of the measured packet
	possible that some of the measured packet drops are the result of		drops are the result of inappropriate advice in this area.
	inappropriate advice in this area.
	This document analyzes both the general security implications of IPv6		This document analyzes both the general security implications of IPv6
	EHs, as well as the security implications of specific EH and Option		EHs, as well as the security implications of specific EH and option
	types. It also provides advice on the filtering of IPv6 packets		types. It also provides advice on the filtering of IPv6 packets
	based on the IPv6 EHs and the IPv6 options they contain. Since		based on the IPv6 EHs and the IPv6 options they contain. Since
	various protocols may use IPv6 EHs (possibly with IPv6 options),		various protocols may use IPv6 EHs (possibly with IPv6 options),
	discarding packets based on the IPv6 EHs or IPv6 options they contain		discarding packets based on the IPv6 EHs or IPv6 options they contain
	can have implications on the proper functioning of such protocols.		can have implications on the proper functioning of such protocols.
	Thus, this document also attempts to discuss the operational and		Thus, this document also attempts to discuss the operational and
	interoperability implications of such filtering policies.		interoperability implications of such filtering policies.
	The resulting packet filtering policy typically depends on where in		The resulting packet filtering policy typically depends on where in
	the network such policy is enforced: when the policy is enforced in a		the network such policy is enforced. When the policy is enforced in
	transit network, the policy typically follows a "deny-list" approach,		a transit network, the policy typically follows a "deny-list"
	where only packets with clear negative implications are dropped. On		approach, where only packets with clear negative implications are
	the other hand, when the policy is enforced closer to the destination		dropped. On the other hand, when the policy is enforced closer to
	systems, the policy typically follows an "accept-list" approach,		the destination systems, the policy typically follows an "accept-
	where only traffic that is expected to be received is allowed. The		list" approach, where only traffic that is expected to be received is
	advice in this document is aimed only at transit routers that may		allowed. The advice in this document is aimed only at transit
	need to enforce a filtering policy based on the EHs and IPv6 options		routers that may need to enforce a filtering policy based on the IPv6
	a packet may contain, following a "deny-list" approach, and hence is		EHs and IPv6 options a packet may contain, following a "deny-list"
	likely to be much more permissive than a filtering policy to be		approach; hence, it is likely to be much more permissive than a
	employed at e.g. the edge of an enterprise network. The advice in		filtering policy to be employed at, for example, the edge of an
	this document is meant to improve the current situation of the		enterprise network. The advice in this document is meant to improve
	dropping of packets with IPv6 EHs in the Internet [RFC7872] in such		the current situation of the dropping of packets with IPv6 EHs in the
	cases where packets are being dropped due to inappropriate or missing		Internet [RFC7872] in such cases where packets are being dropped due
	guidelines.		to inappropriate or missing guidelines.
	This document is similar in nature to [RFC7126], which addresses the		This document is similar in nature to [RFC7126], which addresses the
	same problem for the IPv4 case. However, in IPv6, the problem space		same problem for the IPv4 case. However, in IPv6, the problem space
	is compounded by the fact that IPv6 specifies a number of IPv6 EHs,		is compounded by the fact that IPv6 specifies a number of IPv6 EHs
	and a number of IPv6 options which may be valid only when included in		and a number of IPv6 options that may be valid only when included in
	specific EH types.		specific EH types.
	This document completes and complements the considerations for		This document completes and complements the considerations for
	protecting the control plane from packets containing IP options that		protecting the control plane from packets containing IP options that
	can be found in [RFC6192].		can be found in [RFC6192].
	Section 2 specifies the terminology and conventions employed		Section 2 specifies the terminology and conventions employed
	throughout this document. Section 3 discusses IPv6 EHs and provides		throughout this document. Section 3 discusses IPv6 EHs and provides
	advice in the area of filtering IPv6 packets that contain such IPv6		advice in the area of filtering IPv6 packets that contain such IPv6
	EHs. Section 4 discusses IPv6 options and provides advice in the		EHs. Section 4 discusses IPv6 options and provides advice in the
	area of filtering IPv6 packets that contain such options.		area of filtering IPv6 packets that contain such options.
	2. Terminology and Assumptions Employed in This Document		2. Terminology and Assumptions Employed in This Document
	2.1. Terminology		2.1. Terminology
	The terms "permit" (allow the traffic), "drop" (drop with no		The terms "permit" (allow the traffic), "drop" (drop with no
	notification to sender), and "reject" (drop with appropriate		notification to sender), and "reject" (drop with appropriate
	notification to sender) are employed as defined in [RFC3871].		notification to sender) are employed as defined in [RFC3871].
	Throughout this document we also employ the term "discard" as a		Throughout this document, we also employ the term "discard" as a
	generic term to indicate the act of discarding a packet, irrespective		generic term to indicate the act of discarding a packet, irrespective
	of whether the sender is notified of such drops, and irrespective of		of whether the sender is notified of such a drop and whether the
	whether the specific filtering action is logged.		specific filtering action is logged.
	The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",		The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
	"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and		"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
	"OPTIONAL" in this document are to be interpreted as described in BCP		"OPTIONAL" in this document are to be interpreted as described in
	14 [RFC2119] [RFC8174] when, and only when, they appear in all		BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all
	capitals, as shown here.		capitals, as shown here.
	2.2. Applicability Statement		2.2. Applicability Statement
	This document provides advice on the filtering of IPv6 packets with		This document provides advice on the filtering of IPv6 packets with
	EHs at transit routers for traffic not explicitly destined to them,		EHs at transit routers for traffic not explicitly destined to them,
	for cases in which such filtering is deemed as necessary.		for cases in which such filtering is deemed as necessary.
	2.3. Router Default Behavior and Features		2.3. Router Default Behavior and Features
	This document assumes that nodes comply with the requirements in		This document assumes that nodes comply with the requirements in
	[RFC7045]. Namely,		[RFC7045]. Namely,
	"If a forwarding node discards a packet containing a standard IPv6		| If a forwarding node discards a packet containing a standard IPv6
	extension header, it MUST be the result of a configurable policy		| extension header, it MUST be the result of a configurable policy
	and not just the result of a failure to recognise such a header.		| and not just the result of a failure to recognise such a header.
	This means that the discard policy for each standard type of		| This means that the discard policy for each standard type of
	extension header MUST be individually configurable. The default		| extension header MUST be individually configurable. The default
	configuration SHOULD allow all standard extension headers."		| configuration SHOULD allow all standard extension headers.
	The advice provided in this document is only meant to guide an		The advice provided in this document is only meant to guide an
	operator in configuring forwarding devices, and is not to be		operator in configuring forwarding devices and is not to be
	interpreted as advice regarding default configuration settings for		interpreted as advice regarding default configuration settings for
	network devices. That is, this document provides advice with respect		network devices. That is, this document provides advice with respect
	to operational policies, but does not change the implementation		to operational policies but does not change the implementation
	defaults required by [RFC7045].		defaults required by [RFC7045].
	We recommend that configuration options are made available to govern		We recommend that configuration options be made available to govern
	the processing of each IPv6 EH type and each IPv6 option type. Such		the processing of each IPv6 EH type and each IPv6 Option Type. Such
	configuration options should include the following possible settings:		configuration options should include the following possible settings:
	* Permit this IPv6 EH or IPv6 Option type.		* Permit this IPv6 EH or IPv6 Option Type.
	* Drop packets containing this IPv6 EH or option type.		* Drop packets containing this IPv6 EH or IPv6 Option Type.
	* Reject packets containing this IPv6 EH or option type (where the		* Reject packets containing this IPv6 EH or IPv6 Option Type (where
	packet drop is signaled with an ICMPv6 error message).		the packet drop is signaled with an ICMPv6 error message).
	* Rate-limit traffic containing this IPv6 EH or option type.		* Rate-limit traffic containing this IPv6 EH or IPv6 Option Type.
	* Ignore this IPv6 EH or option type (as if it was not present) and		* Ignore this IPv6 EH or IPv6 Option Type (as if it was not
	process the packet according the rules for the remaining headers.		present), and process the packet according the rules for the
	We note that if a packet carries forwarding information (e.g., in		remaining headers. We note that if a packet carries forwarding
	an IPv6 Routing Header) this might be an inappropriate or		information (e.g., in an IPv6 Routing Header (RH)), this might be
	undesirable action.		an inappropriate or undesirable action.
	We note that special care needs to be taken when devices log packet		We note that special care needs to be taken when devices log packet
	drops/rejects. Devices should count the number of packets dropped/		drops/rejects. Devices should count the number of packets dropped/
	rejected, but the logging of drop/reject events should be limited so		rejected, but the logging of drop/reject events should be limited so
	as to not overburden device resources.		as to not overburden device resources.
	Finally, we note that when discarding packets, it is generally		Finally, we note that when discarding packets, it is generally
	desirable that the sender be signaled of the packet drop, since this		desirable that the sender be signaled of the packet drop, since this
	is of use for trouble-shooting purposes. However, throughout this		is of use for trouble-shooting purposes. However, throughout this
	document (when recommending that packets be discarded) we generically		document (when recommending that packets be discarded), we
	refer to the action as "discard" without specifying whether the		generically refer to the action as "discard" without specifying
	sender is signaled of the packet drop.		whether the sender is signaled of the packet drop.
	3. IPv6 Extension Headers		3. IPv6 Extension Headers
	3.1. General Discussion		3.1. General Discussion
	IPv6 [RFC8200] EHs allow for the extension of the IPv6 protocol.		IPv6 EHs [RFC8200] allow for the extension of the IPv6 protocol.
	Since both IPv6 EHs and upper-layer protocols share the same		Since both IPv6 EHs and upper-layer protocols share the same
	namespace ("Next Header" registry/namespace), [RFC7045] identifies		namespace ("Next Header" registry/namespace), [RFC7045] identifies
	which of the currently assigned Internet Protocol numbers identify		which of the currently assigned Internet Protocol numbers identify
	IPv6 EHs vs. upper-layer protocols. This document discusses the		IPv6 EHs vs. upper-layer protocols. This document discusses the
	filtering of packets based on the IPv6 EHs (as specified by		filtering of packets based on the IPv6 EHs (as specified by
	[RFC7045]) they contain.		[RFC7045]) they contain.
	NOTE: [RFC8200] specifies that non-fragmented IPv6 datagrams and		[RFC8200] specifies that non-fragmented IPv6 datagrams and IPv6
	IPv6 First-Fragments must contain the entire IPv6 header chain		First-Fragments must contain the entire IPv6 header chain [RFC7112].
	[RFC7112]. Therefore, intermediate systems can enforce the		Therefore, intermediate systems can enforce the filtering policies
	filtering policies discussed in this document, or resort to simply		discussed in this document or resort to simply discarding the
	discarding the offending packets when they fail to comply with the		offending packets when they fail to include the entire IPv6 header
	requirements in [RFC8200]. We note that, in order to implement		chain [RFC8200].
	filtering rules on the fast path, it may be necessary for the
	filtering device to limit the depth into the packet that can be		We note that in order to implement filtering rules on the fast path,
	inspected before giving up. In circumstances where such a		it may be necessary for the filtering device to limit the depth into
	limitation exists, it is recommended that implementations provide		the packet that can be inspected before giving up. In circumstances
	a configuration option that specifies whether to discard packets		where such a limitation exists, it is recommended that
	if the aforementioned limit is encountered. Operators may then		implementations provide a configuration option that specifies whether
	determine according to their own circumstances how such packets		to discard packets if the aforementioned limit is encountered.
	will be handled.		Operators may then determine, according to their own circumstances,
			how such packets will be handled.
	3.2. General Security Implications		3.2. General Security Implications
	In some device architectures, IPv6 packets that contain IPv6 EHs can		In some device architectures, IPv6 packets that contain IPv6 EHs can
	cause the corresponding packets to be processed on the slow path, and		cause the corresponding packets to be processed on the slow path and,
	hence may be leveraged for the purpose of Denial of Service (DoS)		hence, may be leveraged for the purpose of Denial-of-Service (DoS)
	attacks [RFC9098] [Cisco-EH] [FW-Benchmark].		attacks [RFC9098] [Cisco-EH] [FW-Benchmark].
	Operators are urged to consider the IPv6 EH and IPv6 options handling		Operators are urged to consider the IPv6 EH and IPv6 options handling
	capabilities of their devices as they make deployment decisions in		capabilities of their devices as they make deployment decisions in
	the future.		the future.
	3.3. Rationale for Our Advice on the Handling of IPv6 Packets with		3.3. Rationale for Our Advice on the Handling of IPv6 Packets with
	Specific IPv6 Extension Headers		Specific IPv6 Extension Headers
	* IPv6 Packets with IPv6 Extension Headers (or options) that are not		* IPv6 packets with IPv6 Extension Headers (or options) that are not
	expected to traverse transit routers should be dropped.		expected to traverse transit routers should be dropped.
	* IPv6 Packets with IPv6 Extension Headers (or options) that are		* IPv6 packets with IPv6 Extension Headers (or options) that are
	only expected to traverse transit routers when a specific		only expected to traverse transit routers when a specific
	technology is employed, should be permitted (or dropped) based on		technology is employed should be permitted (or dropped) based on
	the knowledge regarding the use of such technology in transit		the knowledge regarding the use of such technology in the transit
	provider in question (i.e. permit the packets if the technology is		provider in question (i.e., permit the packets if the technology
	employed, or drop them)		is employed, or drop them).
	* IPv6 Packets with IPv6 Extension Headers (or options) that		* IPv6 packets with IPv6 Extension Headers (or options) that
	represent a concrete attack vector to network infrastructure		represent a concrete attack vector to network infrastructure
	devices should be dropped.		devices should be dropped.
	* IPv6 packets with any other IPv6 Extension headers (or options)		* IPv6 packets with any other IPv6 Extension Headers (or options)
	should be permitted. This is an intentional trade-off made to		should be permitted. This is an intentional trade-off made to
	minimize ossification.		minimize ossification.
	3.4. Summary of Advice on the Handling of IPv6 Packets with Specific		3.4. Summary of Advice on the Handling of IPv6 Packets with Specific
	IPv6 Extension Headers		IPv6 Extension Headers
	This section summarizes the advice provided in Section 3.5, providing		This section summarizes the advice provided in Section 3.5, providing
	references to the specific sections in which a detailed analysis can		references to the specific sections in which a detailed analysis can
	be found.		be found.
	+=========================+==========================+===========+		+=====================+=========================+===========+
	| EH type | Filtering policy | Reference |		| EH Type | Filtering Policy | Reference |
	+=========================+==========================+===========+		+=====================+=========================+===========+
	| IPv6 Hop-by-Hop Options | Drop or Ignore | Section |		| Hop-by-Hop Options | Drop or Ignore | Section |
	| (Proto=0) | | 3.5.1 |		| Header (Proto=0) | | 3.5.1 |
	+-------------------------+--------------------------+-----------+		+---------------------+-------------------------+-----------+
	| Routing Header for IPv6 | Drop only RHT0 and RHT1. | Section |		| Routing Header | Drop only Routing Type | Section |
	| (Proto=43) | Permit other RH Types | 3.5.2 |		| (Proto=43) | 0, Routing Type 1, and | 3.5.2 |
	+-------------------------+--------------------------+-----------+		| | Routing Type 3. Permit | |
	| Fragment Header for | Permit | Section |		| | other Routing Types | |
	| IPv6 (Proto=44) | | 3.5.3 |		+---------------------+-------------------------+-----------+
	+-------------------------+--------------------------+-----------+		| Fragment Header | Permit | Section |
	| Encapsulating Security | Permit | Section |		| (Proto=44) | | 3.5.3 |
	| Payload (Proto=50) | | 3.5.4 |		+---------------------+-------------------------+-----------+
	+-------------------------+--------------------------+-----------+		| Encapsulating | Permit | Section |
	| Authentication Header | Permit | Section |		| Security Payload | | 3.5.4 |
	| (Proto=51) | | 3.5.5 |		| (Proto=50) | | |
	+-------------------------+--------------------------+-----------+		+---------------------+-------------------------+-----------+
	| Destination Options for | Permit | Section |		| Authentication | Permit | Section |
	| IPv6 (Proto=60) | | 3.5.6 |		| Header (Proto=51) | | 3.5.5 |
	+-------------------------+--------------------------+-----------+		+---------------------+-------------------------+-----------+
	| Mobility Header | Permit | Section |		| Destination Options | Permit | Section |
	| (Proto=135) | | 3.5.7 |		| Header(Proto=60) | | 3.5.6 |
	+-------------------------+--------------------------+-----------+		+---------------------+-------------------------+-----------+
	| Host Identity Protocol | Permit | Section |		| Mobility Header | Permit | Section |
	| (Proto=139) | | 3.5.8 |		| (Proto=135) | | 3.5.7 |
	+-------------------------+--------------------------+-----------+		+---------------------+-------------------------+-----------+
	| Shim6 Protocol | Permit | Section |		| Host Identity | Permit | Section |
	| (Proto=140) | | 3.5.9 |		| Protocol | | 3.5.8 |
	+-------------------------+--------------------------+-----------+		| (Proto=139) | | |
	| Use for experimentation | Drop | Section |		+---------------------+-------------------------+-----------+
	| and testing (Proto=253 | | 3.5.10 |		| Shim6 Protocol | Permit | Section |
	| and 254) | | |		| (Proto=140) | | 3.5.9 |
	+-------------------------+--------------------------+-----------+		+---------------------+-------------------------+-----------+
			| Use for | Drop | Section |
			| experimentation and | | 3.5.10 |
			| testing (Proto=253 | | |
			| and 254) | | |
			+---------------------+-------------------------+-----------+
	Table 1: Summary of Advice on the Handling of IPv6 Packets		Table 1: Summary of Advice on the Handling of IPv6
	with Specific IPv6 Extension Headers		Packets with Specific IPv6 Extension Headers
	3.5. Advice on the Handling of IPv6 Packets with Specific IPv6		3.5. Advice on the Handling of IPv6 Packets with Specific IPv6
	Extension Headers		Extension Headers
	3.5.1. IPv6 Hop-by-Hop Options (Protocol Number=0)		3.5.1. IPv6 Hop-by-Hop Options (Protocol Number=0)
	3.5.1.1. Uses		3.5.1.1. Uses
	The Hop-by-Hop Options header is used to carry optional information		The Hop-by-Hop (HBH) Options header is used to carry optional
	that may be examined by every node along a packet's delivery path.		information that may be examined by every node along a packet's
	It is expected that nodes will examine the Hop-by-Hop Options header		delivery path. It is expected that nodes will examine the Hop-by-Hop
	if explicitly configured to do so.		Options header if explicitly configured to do so.
	NOTE: A previous revision of the IPv6 core specification, [RFC2460],		| NOTE: A previous revision of the IPv6 core specification
	originally required that all nodes examined and processed the Hop-by-		| [RFC2460] originally required all nodes to examine and process
	Hop Options header. However, even before the publication of		| the Hop-by-Hop Options header. However, even before the
	[RFC8200] a number of implementations already provided the option of		| publication of [RFC8200], a number of implementations already
	ignoring this header unless explicitly configured to examine it.		| provided the option of ignoring this header unless explicitly
			| configured to examine it.
	3.5.1.2. Specification		3.5.1.2. Specification
	This EH is specified in [RFC8200]. As of May 2022, the following		This EH is specified in [RFC8200]. As of May 2022, the following
	options have been specified for the Hop-by-Hop Options EH:		options have been specified for the Hop-by-Hop Options header:
	* Type 0x00: Pad1 [RFC8200]		* Type 0x00: Pad1 [RFC8200]
	* Type 0x01: PadN [RFC8200]		* Type 0x01: PadN [RFC8200]
	* Type 0x05: Router Alert [RFC2711]		* Type 0x05: Router Alert [RFC2711]
	* Type 0x07: CALIPSO [RFC5570]		* Type 0x07: CALIPSO [RFC5570]
	* Type 0x08: SMF_DPD [RFC6621]		* Type 0x08: SMF_DPD [RFC6621]
	skipping to change at page 8, line 42 ¶		skipping to change at line 375 ¶
	* Type 0x23: RPL Option [RFC9008]		* Type 0x23: RPL Option [RFC9008]
	* Type 0x26: Quick-Start [RFC4782]		* Type 0x26: Quick-Start [RFC4782]
	* Type 0x4D: (Deprecated)		* Type 0x4D: (Deprecated)
	* Type 0x63: RPL Option [RFC6553]		* Type 0x63: RPL Option [RFC6553]
	* Type 0x6D: MPL Option [RFC7731]		* Type 0x6D: MPL Option [RFC7731]
	* Type 0x8A: Endpoint Identification (Deprecated)		* Type 0x8A: Endpoint Identification (Deprecated) [NIMROD-EID]
	[draft-ietf-nimrod-eid]
	* Type 0xC2: Jumbo Payload [RFC2675]		* Type 0xC2: Jumbo Payload [RFC2675]
	* Type 0xEE: IPv6 DFF Header [RFC6971]		* Type 0xEE: IPv6 DFF Header [RFC6971]
	* Type 0x1E: RFC3692-style Experiment [RFC4727]		* Type 0x1E: RFC3692-style Experiment [RFC4727]
	* Type 0x3E: RFC3692-style Experiment [RFC4727]		* Type 0x3E: RFC3692-style Experiment [RFC4727]
	* Type 0x5E: RFC3692-style Experiment [RFC4727]		* Type 0x5E: RFC3692-style Experiment [RFC4727]
	* Type 0x7E: RFC3692-style Experiment [RFC4727]		* Type 0x7E: RFC3692-style Experiment [RFC4727]
	* Type 0x9E: RFC3692-style Experiment [RFC4727]		* Type 0x9E: RFC3692-style Experiment [RFC4727]
	* Type 0xBE: RFC3692-style Experiment [RFC4727]		* Type 0xBE: RFC3692-style Experiment [RFC4727]
	* Type 0xDE: RFC3692-style Experiment [RFC4727]		* Type 0xDE: RFC3692-style Experiment [RFC4727]
	* Type 0xFE: RFC3692-style Experiment [RFC4727]		* Type 0xFE: RFC3692-style Experiment [RFC4727]
	3.5.1.3. Specific Security Implications		3.5.1.3. Specific Security Implications
	Legacy nodes that process this extension header might be subject to		Legacy nodes that process this extension header might be subject to
	Denial of Service attacks.		DoS attacks.
	NOTE: While [RFC8200] has removed this requirement, the deployed base		| NOTE: While [RFC8200] has removed the requirement for all nodes
	may still reflect the classical behavior for a while, and hence the		| to examine and process the Hop-by-Hop Options header, the
	potential security problems of this EH are still of concern.		| deployed base may still reflect the legacy [RFC2460] behavior
			| for a while; hence, the potential security problems of this EH
			| are still of concern.
	3.5.1.4. Operational and Interoperability Impact if Blocked		3.5.1.4. Operational and Interoperability Impact If Blocked
	Discarding packets containing a Hop-by-Hop Options EH would break any		Discarding packets containing a Hop-by-Hop Options header would break
	of the protocols that rely on it for proper functioning. For		any of the protocols that rely on it for proper functioning. For
	example, it would break RSVP [RFC2205] and multicast deployments, and		example, it would break RSVP [RFC2205] and multicast deployments and
	would cause IPv6 jumbograms to be discarded.		would cause IPv6 jumbograms to be discarded.
	3.5.1.5. Advice		3.5.1.5. Advice
	Nodes implementing [RFC8200] would already ignore this extension		Nodes implementing [RFC8200] would already ignore this extension
	header unless explicitly required to process it. For legacy		header unless explicitly required to process it. For legacy nodes
	([RFC2460]) nodes, the recommended configuration for the processing		[RFC2460], the recommended configuration for the processing of these
	of these packets depends on the features and capabilities of the		packets depends on the features and capabilities of the underlying
	underlying platform, the configuration of the platform, and also the		platform, the configuration of the platform, and also the deployment
	deployment environment of the platform. On platforms that allow		environment of the platform. On platforms that allow the forwarding
	forwarding of packets with HBH Options on the fast path, we recommend		of packets with IPv6 HBH Options headers on the fast path, we
	that packets with a HBH Options EH be forwarded as normal.		recommend that packets with IPv6 HBH Options headers be forwarded as
	Otherwise, on platforms in which processing of packets with a IPv6		normal. Otherwise, on platforms in which the processing of packets
	HBH Options EH is carried out in the slow path, and an option is		with IPv6 HBH Options headers is carried out in the slow path and an
	provided to rate-limit these packets, we recommend that this option		option is provided to rate-limit these packets, we recommend that
	be selected. Finally, when packets containing a HBH Options EH are		this option be selected. Finally, when packets containing IPv6 HBH
	processed in the slow-path, and the underlying platform does not have		Options headers are processed in the slow path and the underlying
	any mitigation options available for attacks based on these packets,		platform does not have any mitigation options available for attacks
	we recommend that such platforms discard packets containing IPv6 HBH		based on these packets, we recommend that such platforms discard
	Options EHs.		packets containing IPv6 HBH Options headers.
	Finally, we note that RPL (Routing Protocol for Low-Power and Lossy		Finally, we note that the Routing Protocol for Low-Power and Lossy
	Networks) routers [RFC6550] must not discard packets based on the		Networks (RPL) routers [RFC6550] must not discard packets based on
	presence of an IPv6 Hop-by-Hop Options EH, as this would break RPL.		the presence of an IPv6 Hop-by-Hop Options header, as this would
			break the RPL.
	3.5.2. Routing Header for IPv6 (Protocol Number=43)		3.5.2. Routing Header (Protocol Number=43)
	3.5.2.1. Uses		3.5.2.1. Uses
	The Routing header is used by an IPv6 source to list one or more		The Routing Header is used by an IPv6 source to list one or more
	intermediate nodes to be "visited" on the way to a packet's		intermediate nodes to be "visited" on the way to a packet's
	destination.		destination.
	3.5.2.2. Specification		3.5.2.2. Specification
	This EH is specified in [RFC8200]. [RFC2460] had originally		This EH is specified in [RFC8200]. The Routing Type 0 had originally
	specified the Routing Header Type 0, which was later obsoleted by		been specified in [RFC2460] and was later obsoleted by [RFC5095];
	[RFC5095], and thus removed from [RFC8200].		thus, it was removed from [RFC8200].
	At of May 2022, the following Routing Types have been specified:		As of May 2022, the following Routing Types have been specified:
	* Type 0: Source Route (DEPRECATED) [RFC2460] [RFC5095]		* Type 0: Source Route (DEPRECATED) [RFC2460] [RFC5095]
	* Type 1: Nimrod (DEPRECATED)		* Type 1: Nimrod (DEPRECATED)
	* Type 2: Type 2 Routing Header [RFC6275]		* Type 2: Type 2 Routing Header [RFC6275]
	* Type 3: RPL Source Route Header [RFC6554]		* Type 3: RPL Source Route Header [RFC6554]
	* Type 4: Segment Routing Header (SRH) [RFC8754]		* Type 4: Segment Routing Header (SRH) [RFC8754]
	skipping to change at page 10, line 45 ¶		skipping to change at line 475 ¶
	* Types 5-252: Unassigned		* Types 5-252: Unassigned
	* Type 253: RFC3692-style Experiment 1 [RFC4727]		* Type 253: RFC3692-style Experiment 1 [RFC4727]
	* Type 254: RFC3692-style Experiment 2 [RFC4727]		* Type 254: RFC3692-style Experiment 2 [RFC4727]
	* Type 255: Reserved		* Type 255: Reserved
	3.5.2.3. Specific Security Implications		3.5.2.3. Specific Security Implications
	The security implications of RHT0 have been discussed in detail in		The security implications of Routing Headers of Routing Type 0 have
	[Biondi2007] and [RFC5095]. RHT1 was never widely implemented. The		been discussed in detail in [Biondi-2007] and [RFC5095]. Routing
	security implications of RHT2, RHT3, and RHT4 (SRH) are discussed in		Type 1 was never widely implemented. The security implications of
	[RFC6275], [RFC6554], and [RFC8754], respectively.		Routing Headers of Routing Type 2, Routing Type 3, and Routing Type 4
			(SRH) are discussed in [RFC6275], [RFC6554], and [RFC8754],
			respectively.
	3.5.2.4. Operational and Interoperability Impact if Blocked		3.5.2.4. Operational and Interoperability Impact If Blocked
	Blocking packets containing a RHT0 or RHT1 has no operational		Blocking packets containing Routing Headers of Routing Type 0 or
	implications, since both have been deprecated. Blocking packets with		Routing Type 1 has no operational implications, since both have been
	a RHT2 would break Mobile IPv6. Packets with a RHT3 may be safely		deprecated. Blocking packets containing Routing Headers of Routing
	blocked at RPL domain boundaries, since RHT3 headers are employed		Type 2 would break Mobile IPv6. Packets containing Routing Headers
	within a single RPL domain. Blocking packets with a RHT4 (SRH) will		of Routing Type 3 may be safely blocked at RPL domain boundaries,
	break Segment Routing (SR) deployments, if the filtering policy is		since such headers are employed within a single RPL domain. Blocking
	enforced on packets being forwarded within an SR domain.		packets containing Routing Headers of Routing Type 4 (SRH) will break
			Segment Routing (SR) deployments if the filtering policy is enforced
			on packets being forwarded within an SR domain.
	3.5.2.5. Advice		3.5.2.5. Advice
	Intermediate systems should discard packets containing a RHT0, RHT1,		Intermediate systems should discard packets containing Routing
	or RHT3. Other routing header types should be permitted, as required		Headers of Routing Type 0, Routing Type 1, or Routing Type 3. Other
	by [RFC7045].		Routing Types should be permitted, as required by [RFC7045].
	3.5.3. Fragment Header for IPv6 (Protocol Number=44)		3.5.3. Fragment Header (Protocol Number=44)
	3.5.3.1. Uses		3.5.3.1. Uses
	This EH provides the fragmentation functionality for IPv6.		This EH provides the fragmentation and reassembly functionality for
			IPv6.
	3.5.3.2. Specification		3.5.3.2. Specification
	This EH is specified in [RFC8200].		This EH is specified in [RFC8200].
	3.5.3.3. Specific Security Implications		3.5.3.3. Specific Security Implications
	The security implications of the Fragment Header range from Denial of		The security implications of the Fragment Header range from DoS
	Service attacks (e.g. based on flooding a target with IPv6 fragments)		attacks (e.g., based on flooding a target with IPv6 fragments) to
	to information leakage attacks [RFC7739].		information leakage attacks [RFC7739].
	3.5.3.4. Operational and Interoperability Impact if Blocked		3.5.3.4. Operational and Interoperability Impact If Blocked
	Blocking packets that contain a Fragment Header will break any		Blocking packets that contain a Fragment Header will break any
	protocol that may rely on fragmentation (e.g., the DNS [RFC1034]).		protocol that may rely on fragmentation (e.g., the DNS [RFC1034]).
	However, IP fragmentation is known to introduce fragility to Internet		However, IP fragmentation is known to introduce fragility to Internet
	communication [RFC8900].		communication [RFC8900].
	3.5.3.5. Advice		3.5.3.5. Advice
	Intermediate systems should permit packets that contain a Fragment		Intermediate systems should permit packets that contain a Fragment
	Header.		Header.
	skipping to change at page 12, line 4 ¶		skipping to change at line 530 ¶
	protocol that may rely on fragmentation (e.g., the DNS [RFC1034]).		protocol that may rely on fragmentation (e.g., the DNS [RFC1034]).
	However, IP fragmentation is known to introduce fragility to Internet		However, IP fragmentation is known to introduce fragility to Internet
	communication [RFC8900].		communication [RFC8900].
	3.5.3.5. Advice		3.5.3.5. Advice
	Intermediate systems should permit packets that contain a Fragment		Intermediate systems should permit packets that contain a Fragment
	Header.		Header.
	3.5.4. Encapsulating Security Payload (Protocol Number=50)		3.5.4. Encapsulating Security Payload (Protocol Number=50)
	3.5.4.1. Uses		3.5.4.1. Uses
	This EH is employed for the IPsec suite [RFC4303].		This EH is employed for the IPsec suite [RFC4303].
	3.5.4.2. Specification		3.5.4.2. Specification
	This EH is specified in [RFC4303].		This EH is specified in [RFC4303].
	3.5.4.3. Specific Security Implications		3.5.4.3. Specific Security Implications
	Besides the general implications of IPv6 EHs, this EH could be		Besides the general implications of IPv6 EHs, this EH could be
	employed to potentially perform a DoS attack at the destination		employed to potentially perform a DoS attack at the destination
	system by wasting CPU resources in validating the contents of the		system by wasting CPU resources in validating the contents of the
	packet.		packet.
	3.5.4.4. Operational and Interoperability Impact if Blocked		3.5.4.4. Operational and Interoperability Impact If Blocked
	Discarding packets that employ this EH would break IPsec deployments.		Discarding packets that employ this EH would break IPsec deployments.
	3.5.4.5. Advice		3.5.4.5. Advice
	Intermediate systems should permit packets containing the		Intermediate systems should permit packets containing the
	Encapsulating Security Payload EH.		Encapsulating Security Payload EH.
	3.5.5. Authentication Header (Protocol Number=51)		3.5.5. Authentication Header (Protocol Number=51)
	3.5.5.1. Uses		3.5.5.1. Uses
	The Authentication Header can be employed for provide authentication		The Authentication Header can be employed to provide authentication
	services in IPv4 and IPv6.		services in IPv4 and IPv6.
	3.5.5.2. Specification		3.5.5.2. Specification
	This EH is specified in [RFC4302].		This EH is specified in [RFC4302].
	3.5.5.3. Specific Security Implications		3.5.5.3. Specific Security Implications
	Besides the general implications of IPv6 EHs, this EH could be		Besides the general implications of IPv6 EHs, this EH could be
	employed to potentially perform a DoS attack at the destination		employed to potentially perform a DoS attack at the destination
	system by wasting CPU resources in validating the contents of the		system by wasting CPU resources in validating the contents of the
	packet.		packet.
	3.5.5.4. Operational and Interoperability Impact if Blocked		3.5.5.4. Operational and Interoperability Impact If Blocked
	Discarding packets that employ this EH would break IPsec deployments.		Discarding packets that employ this EH would break IPsec deployments.
	3.5.5.5. Advice		3.5.5.5. Advice
	Intermediate systems should permit packets containing an		Intermediate systems should permit packets containing an
	Authentication Header.		Authentication Header.
	3.5.6. Destination Options for IPv6 (Protocol Number=60)		3.5.6. Destination Options (Protocol Number=60)
	3.5.6.1. Uses		3.5.6.1. Uses
	The Destination Options header is used to carry optional information		The Destination Options (DO) header is used to carry optional
	that needs be examined only by a packet's destination node(s).		information that needs be examined only by a packet's destination
			node(s).
	3.5.6.2. Specification		3.5.6.2. Specification
	This EH is specified in [RFC8200]. As of May 2022, the following		This EH is specified in [RFC8200]. As of May 2022, the following
	options have been specified for this EH:		options have been specified for this EH:
	* Type 0x00: Pad1 [RFC8200]		* Type 0x00: Pad1 [RFC8200]
	* Type 0x01: PadN [RFC8200]		* Type 0x01: PadN [RFC8200]
	* Type 0x04: Tunnel Encapsulation Limit [RFC2473]		* Type 0x04: Tunnel Encapsulation Limit [RFC2473]
	* Type 0x0F: IPv6 Performance and Diagnostic Metrics (PDM) [RFC8250]		* Type 0x0F: IPv6 Performance and Diagnostic Metrics (PDM) [RFC8250]
	* Type 0x4D: (Deprecated)		* Type 0x4D: (Deprecated)
	* Type 0xC9: Home Address [RFC6275]		* Type 0xC9: Home Address [RFC6275]
	* Type 0x8A: Endpoint Identification (Deprecated)		* Type 0x8A: Endpoint Identification (Deprecated) [NIMROD-EID]
	[draft-ietf-nimrod-eid]
	* Type 0x8B: ILNP Nonce [RFC6744]		* Type 0x8B: ILNP Nonce [RFC6744]
	* Type 0x8C: Line-Identification Option [RFC6788]		* Type 0x8C: Line-Identification Option [RFC6788]
	* Type 0x1E: RFC3692-style Experiment [RFC4727]		* Type 0x1E: RFC3692-style Experiment [RFC4727]
	* Type 0x3E: RFC3692-style Experiment [RFC4727]		* Type 0x3E: RFC3692-style Experiment [RFC4727]
	* Type 0x5E: RFC3692-style Experiment [RFC4727]		* Type 0x5E: RFC3692-style Experiment [RFC4727]
	skipping to change at page 14, line 4 ¶		skipping to change at line 624 ¶
	* Type 0x3E: RFC3692-style Experiment [RFC4727]		* Type 0x3E: RFC3692-style Experiment [RFC4727]
	* Type 0x5E: RFC3692-style Experiment [RFC4727]		* Type 0x5E: RFC3692-style Experiment [RFC4727]
	* Type 0x7E: RFC3692-style Experiment [RFC4727]		* Type 0x7E: RFC3692-style Experiment [RFC4727]
	* Type 0x9E: RFC3692-style Experiment [RFC4727]		* Type 0x9E: RFC3692-style Experiment [RFC4727]
	* Type 0xBE: RFC3692-style Experiment [RFC4727]		* Type 0xBE: RFC3692-style Experiment [RFC4727]
	* Type 0xDE: RFC3692-style Experiment [RFC4727]		* Type 0xDE: RFC3692-style Experiment [RFC4727]
	* Type 0xFE: RFC3692-style Experiment [RFC4727]		* Type 0xFE: RFC3692-style Experiment [RFC4727]
	3.5.6.3. Specific Security Implications		3.5.6.3. Specific Security Implications
	No security implications are known, other than the general		No security implications are known, other than the general security
	implications of IPv6 EHs. For a discussion of possible security		implications of IPv6 EHs. For a discussion of possible security
	implications of specific options specified for the DO header, please		implications of specific options specified for the DO header, please
	see the Section 4.4.		see Section 4.4.
	3.5.6.4. Operational and Interoperability Impact if Blocked		3.5.6.4. Operational and Interoperability Impact If Blocked
	Discarding packets that contain a Destination Options header would		Discarding packets that contain a Destination Options header would
	break protocols that rely on this EH type for conveying information,		break protocols that rely on this EH type for conveying information
	including protocols such as ILNP [RFC6740] and Mobile IPv6 [RFC6275],		(such as the Identifier-Locator Network Protocol (ILNP) [RFC6740] and
	and IPv6 tunnels that employ the Tunnel Encapsulation Limit option.		Mobile IPv6 [RFC6275]), as well as IPv6 tunnels that employ the
			Tunnel Encapsulation Limit option [RFC2473].
	3.5.6.5. Advice		3.5.6.5. Advice
	Intermediate systems should permit packets that contain a Destination		Intermediate systems should permit packets that contain a Destination
	Options Header.		Options header.
	3.5.7. Mobility Header (Protocol Number=135)		3.5.7. Mobility Header (Protocol Number=135)
	3.5.7.1. Uses		3.5.7.1. Uses
	The Mobility Header is an EH used by mobile nodes, correspondent		The Mobility Header is an EH used by mobile nodes, correspondent
	nodes, and home agents in all messaging related to the creation and		nodes, and home agents in all messaging related to the creation and
	management of bindings in Mobile IPv6.		management of bindings in Mobile IPv6.
	3.5.7.2. Specification		3.5.7.2. Specification
	This EH is specified in [RFC6275].		This EH is specified in [RFC6275].
	3.5.7.3. Specific Security Implications		3.5.7.3. Specific Security Implications
	A thorough security assessment of the security implications of the		A thorough security assessment of the security implications of the
	Mobility Header and related mechanisms can be found in Section 15 of		Mobility Header and related mechanisms can be found in Section 15 of
	[RFC6275].		[RFC6275].
	3.5.7.4. Operational and Interoperability Impact if Blocked		3.5.7.4. Operational and Interoperability Impact If Blocked
	Discarding packets containing this EH would break Mobile IPv6.		Discarding packets containing this EH would break Mobile IPv6.
	3.5.7.5. Advice		3.5.7.5. Advice
	Intermediate systems should permit packets containing this EH.		Intermediate systems should permit packets that contain a Mobility
			Header.
	3.5.8. Host Identity Protocol (Protocol Number=139)		3.5.8. Host Identity Protocol (Protocol Number=139)
	3.5.8.1. Uses		3.5.8.1. Uses
	This EH is employed with the Host Identity Protocol (HIP), a protocol		This EH is employed with the Host Identity Protocol (HIP), which is a
	that allows consenting hosts to securely establish and maintain		protocol that allows consenting hosts to securely establish and
	shared IP-layer state, allowing separation of the identifier and		maintain shared IP-layer state, allowing the separation of the
	locator roles of IP addresses, thereby enabling continuity of		identifier and locator roles of IP addresses, thereby enabling
	communications across IP address changes.		continuity of communications across IP address changes.
	3.5.8.2. Specification		3.5.8.2. Specification
	This EH is specified in [RFC7401].		This EH is specified in [RFC7401].
	3.5.8.3. Specific Security Implications		3.5.8.3. Specific Security Implications
	The security implications of the HIP header are discussed in detail		The security implications of the HIP header are discussed in detail
	in Section 8 of [RFC6275].		in Section 8 of [RFC7401].
	3.5.8.4. Operational and Interoperability Impact if Blocked		3.5.8.4. Operational and Interoperability Impact If Blocked
	Discarding packets that contain the Host Identity Protocol would		Discarding packets that contain a HIP header would break HIP
	break HIP deployments.		deployments.
	3.5.8.5. Advice		3.5.8.5. Advice
	Intermediate systems should permit packets that contain a Host		Intermediate systems should permit packets that contain a HIP header.
	Identity Protocol EH.
	3.5.9. Shim6 Protocol (Protocol Number=140)		3.5.9. Shim6 Protocol (Protocol Number=140)
	3.5.9.1. Uses		3.5.9.1. Uses
	This EH is employed by the Shim6 [RFC5533] Protocol.		This EH is employed by the Shim6 protocol [RFC5533].
	3.5.9.2. Specification		3.5.9.2. Specification
	This EH is specified in [RFC5533].		This EH is specified in [RFC5533].
	3.5.9.3. Specific Security Implications		3.5.9.3. Specific Security Implications
	The specific security implications are discussed in detail in		The specific security implications are discussed in detail in
	Section 16 of [RFC5533].		Section 16 of [RFC5533].
	3.5.9.4. Operational and Interoperability Impact if Blocked		3.5.9.4. Operational and Interoperability Impact If Blocked
	Discarding packets that contain this EH will break Shim6.		Discarding packets that contain this EH will break Shim6.
	3.5.9.5. Advice		3.5.9.5. Advice
	Intermediate systems should permit packets containing this EH.		Intermediate systems should permit packets containing this EH.
	3.5.10. Use for experimentation and testing (Protocol Numbers=253 and		3.5.10. Use for Experimentation and Testing (Protocol Numbers=253 and
	254)		254)
	3.5.10.1. Uses		3.5.10.1. Uses
	These IPv6 EHs are employed for performing RFC3692-Style experiments		These IPv6 EHs are employed for performing RFC3692-style experiments
	(see [RFC3692] for details).		(see [RFC3692] for details).
	3.5.10.2. Specification		3.5.10.2. Specification
	These EHs are specified in [RFC3692] and [RFC4727].		These EHs are specified in [RFC3692] and [RFC4727].
	3.5.10.3. Specific Security Implications		3.5.10.3. Specific Security Implications
	The security implications of these EHs will depend on their specific		The security implications of these EHs will depend on their specific
	use.		use.
	3.5.10.4. Operational and Interoperability Impact if Blocked		3.5.10.4. Operational and Interoperability Impact If Blocked
	For obvious reasons, discarding packets that contain these EHs limits		For obvious reasons, discarding packets that contain these EHs limits
	the ability to perform legitimate experiments across IPv6 routers.		the ability to perform legitimate experiments across IPv6 routers.
	3.5.10.5. Advice		3.5.10.5. Advice
	Operators should determine according to their own circumstances		Operators should determine, according to their own circumstances,
	whether to discard packets containing these EHs.		whether to discard packets containing these EHs.
	3.6. Advice on the Handling of Packets with Unknown IPv6 Extension		3.6. Advice on the Handling of Packets with Unknown IPv6 Extension
	Headers		Headers
	We refer to IPv6 EHs that have not been assigned an Internet Protocol		We refer to IPv6 EHs that have not been assigned an Internet Protocol
	Number by IANA (and marked as such) in [IANA-PROTOCOLS] as "unknown		number by IANA (and marked as such) in [IANA-PROTOCOLS] as "unknown
	IPv6 extension headers" ("unknown IPv6 EHs").		IPv6 Extension Headers" ("unknown IPv6 EHs").
	3.6.1. Uses		3.6.1. Uses
	New IPv6 EHs may be specified as part of future extensions to the		New IPv6 EHs may be specified as part of future extensions to the
	IPv6 protocol.		IPv6 protocol.
	Since IPv6 EHs and Upper-layer protocols employ the same namespace,		Since IPv6 EHs and upper-layer protocols employ the same namespace,
	it is impossible to tell whether an unknown "Internet Protocol		it is impossible to tell whether an unknown Internet Protocol number
	Number" is being employed for an IPv6 EH or an Upper-Layer protocol.		is being employed for an IPv6 EH or an upper-layer protocol.
	3.6.2. Specification		3.6.2. Specification
	The processing of unknown IPv6 EHs is specified in [RFC7045].		The processing of unknown IPv6 EHs is specified in [RFC7045].
	3.6.3. Specific Security Implications		3.6.3. Specific Security Implications
	For obvious reasons, it is impossible to determine specific security		For obvious reasons, it is impossible to determine specific security
	implications of unknown IPv6 EHs.		implications of unknown IPv6 EHs.
	3.6.4. Operational and Interoperability Impact if Blocked		3.6.4. Operational and Interoperability Impact If Blocked
	As noted in [RFC7045], discarding unknown IPv6 EHs may slow down the		As noted in [RFC7045], discarding unknown IPv6 EHs may slow down the
	deployment of new IPv6 EHs and transport protocols. The		deployment of new IPv6 EHs and transport protocols. The
	corresponding IANA registry ([IANA-PROTOCOLS]) should be monitored		corresponding IANA registry, which is [IANA-PROTOCOLS], should be
	such that filtering rules are updated as new IPv6 EHs are		monitored such that filtering rules are updated as new IPv6 EHs are
	standardized.		standardized.
	We note that since IPv6 EHs and upper-layer protocols share the same		We note that since IPv6 EHs and upper-layer protocols share the same
	numbering space, discarding unknown IPv6 EHs may result in packets		numbering space, discarding unknown IPv6 EHs may result in packets
	encapsulating unknown upper-layer protocols being discarded.		encapsulating unknown upper-layer protocols being discarded.
	3.6.5. Advice		3.6.5. Advice
	Operators should determine according to their own circumstances		Operators should determine, according to their own circumstances,
	whether to discard packets containing unknown IPv6 EHs.		whether to discard packets containing unknown IPv6 EHs.
	4. IPv6 Options		4. IPv6 Options
	4.1. General Discussion		4.1. General Discussion
	The following subsections describe specific security implications of		The following subsections describe specific security implications of
	different IPv6 options, and provide advice regarding filtering		different IPv6 options and provide advice regarding filtering packets
	packets that contain such options.		that contain such options.
	4.2. General Security Implications of IPv6 Options		4.2. General Security Implications of IPv6 Options
	The general security implications of IPv6 options are closely related		The general security implications of IPv6 options are closely related
	to those discussed in Section 3.2 for IPv6 EHs. Essentially, packets		to those discussed in Section 3.2 for IPv6 EHs. Essentially, packets
	that contain IPv6 options might need to be processed by an IPv6		that contain IPv6 options might need to be processed by an IPv6
	router's general-purpose CPU,and hence could present a DDoS risk to		router's general-purpose CPU and, hence, could present a Distributed
	that router's general-purpose CPU (and thus to the router itself).		Denial-of-Service (DDoS) risk to that router's general-purpose CPU
	For some architectures, a possible mitigation would be to rate-limit		(and thus to the router itself). For some architectures, a possible
	the packets that are to be processed by the general-purpose CPU (see		mitigation would be to rate-limit the packets that are to be
	e.g. [Cisco-EH]).		processed by the general-purpose CPU (see, e.g., [Cisco-EH]).
	4.3. Summary of Advice on the Handling of IPv6 Packets with Specific		4.3. Summary of Advice on the Handling of IPv6 Packets with Specific
	IPv6 Extension Headers		IPv6 Options
	This section summarizes the advice provided in Section 3.5, providing		This section summarizes the advice provided in Section 4.4, and it
	references to the specific sections in which a detailed analysis can		includes references to the specific sections in which a detailed
	be found.		analysis can be found.
	+===============================+======================+===========+		+===============================+======================+===========+
	| Option | Filtering policy | Reference |		| Option | Filtering Policy | Reference |
	+===============================+======================+===========+		+===============================+======================+===========+
	| Pad1 (Type=0x00) | Permit | Section |		| Pad1 (Type=0x00) | Permit | Section |
	| | | 4.4.1 |		| | | 4.4.1 |
	+-------------------------------+----------------------+-----------+		+-------------------------------+----------------------+-----------+
	| PadN (Type=0x01) | Permit | Section |		| PadN (Type=0x01) | Permit | Section |
	| | | 4.4.2 |		| | | 4.4.2 |
	+-------------------------------+----------------------+-----------+		+-------------------------------+----------------------+-----------+
	| Tunnel Encapsulation Limit | Permit | Section |		| Tunnel Encapsulation Limit | Permit | Section |
	| (Type=0x04) | | 4.4.3 |		| (Type=0x04) | | 4.4.3 |
	+-------------------------------+----------------------+-----------+		+-------------------------------+----------------------+-----------+
	skipping to change at page 18, line 48 ¶		skipping to change at line 858 ¶
	+-------------------------------+----------------------+-----------+		+-------------------------------+----------------------+-----------+
	| Quick-Start (Type=0x26) | Permit | Section |		| Quick-Start (Type=0x26) | Permit | Section |
	| | | 4.4.9 |		| | | 4.4.9 |
	+-------------------------------+----------------------+-----------+		+-------------------------------+----------------------+-----------+
	| Deprecated (Type=0x4D) | Drop | Section |		| Deprecated (Type=0x4D) | Drop | Section |
	| | | 4.4.10 |		| | | 4.4.10 |
	+-------------------------------+----------------------+-----------+		+-------------------------------+----------------------+-----------+
	| MPL Option (Type=0x6D) | Permit | Section |		| MPL Option (Type=0x6D) | Permit | Section |
	| | | 4.4.12 |		| | | 4.4.12 |
	+-------------------------------+----------------------+-----------+		+-------------------------------+----------------------+-----------+
	| Jumbo Payload (Type=0C2) | Permit based on | Section |		| Jumbo Payload (Type=0xC2) | Permit based on | Section |
	| | needed functionality | 4.4.16 |		| | needed functionality | 4.4.16 |
	+-------------------------------+----------------------+-----------+		+-------------------------------+----------------------+-----------+
	| RPL Option (Type=0x63) | Drop in non-RPL | Section |		| RPL Option (Type=0x63) | Drop | Section |
	| | routers | 4.4.11 |		| | | 4.4.11 |
	+-------------------------------+----------------------+-----------+		+-------------------------------+----------------------+-----------+
	| Endpoint Identification | Drop | Section |		| Endpoint Identification | Drop | Section |
	| (Type=0x8A) | | 4.4.13 |		| (Type=0x8A) | | 4.4.13 |
	+-------------------------------+----------------------+-----------+		+-------------------------------+----------------------+-----------+
	| ILNP Nonce (Type=0x8B) | Permit | Section |		| ILNP Nonce (Type=0x8B) | Permit | Section |
	| | | 4.4.14 |		| | | 4.4.14 |
	+-------------------------------+----------------------+-----------+		+-------------------------------+----------------------+-----------+
	| Line-Identification Option | Drop | Section |		| Line-Identification Option | Drop | Section |
	| (Type=0x8C) | | 4.4.15 |		| (Type=0x8C) | | 4.4.15 |
	+-------------------------------+----------------------+-----------+		+-------------------------------+----------------------+-----------+
	skipping to change at page 19, line 26 ¶		skipping to change at line 885 ¶
	+-------------------------------+----------------------+-----------+		+-------------------------------+----------------------+-----------+
	| IP_DFF (Type=0xEE) | Permit based on | Section |		| IP_DFF (Type=0xEE) | Permit based on | Section |
	| | needed functionality | 4.4.18 |		| | needed functionality | 4.4.18 |
	+-------------------------------+----------------------+-----------+		+-------------------------------+----------------------+-----------+
	| RFC3692-style Experiment | Permit based on | Section |		| RFC3692-style Experiment | Permit based on | Section |
	| (Types = 0x1E, 0x3E, 0x5E, | needed functionality | 4.4.19 |		| (Types = 0x1E, 0x3E, 0x5E, | needed functionality | 4.4.19 |
	| 0x7E, 0x9E, 0xBE, 0xDE, 0xFE) | | |		| 0x7E, 0x9E, 0xBE, 0xDE, 0xFE) | | |
	+-------------------------------+----------------------+-----------+		+-------------------------------+----------------------+-----------+
	Table 2: Summary of Advice on the Handling of IPv6 Packets with		Table 2: Summary of Advice on the Handling of IPv6 Packets with
	Specific IPv6 options		Specific IPv6 Options
	4.4. Advice on the Handling of Packets with Specific IPv6 Options		4.4. Advice on the Handling of Packets with Specific IPv6 Options
	The following subsections contain a description of each of the IPv6		The following subsections contain a description of each of the IPv6
	options that have so far been specified, a summary of the security		options that have so far been specified, a summary of the security
	implications of each of such options, a discussion of possible		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		discarded, and specific advice regarding whether packets containing
	these options should be permitted.		these options should be permitted.
	skipping to change at page 20, line 5 ¶		skipping to change at line 911 ¶
	pad out the containing header to a multiple of 8 octets in length.		pad out the containing header to a multiple of 8 octets in length.
	4.4.1.2. Specification		4.4.1.2. Specification
	This option is specified in [RFC8200].		This option is specified in [RFC8200].
	4.4.1.3. Specific Security Implications		4.4.1.3. Specific Security Implications
	None.		None.
	4.4.1.4. Operational and Interoperability Impact if Blocked		4.4.1.4. Operational and Interoperability Impact If Blocked
	Discarding packets that contain this option would potentially break		Discarding packets that contain this option would potentially break
	any protocol that relies on IPv6 options.		any protocol that relies on IPv6 options.
	4.4.1.5. Advice		4.4.1.5. Advice
	Intermediate systems should not discard packets based on the presence		Intermediate systems should not discard packets based on the presence
	of this option.		of this option.
	4.4.2. PadN (Type=0x01)		4.4.2. PadN (Type=0x01)
	skipping to change at page 20, line 31 ¶		skipping to change at line 937 ¶
	4.4.2.2. Specification		4.4.2.2. Specification
	This option is specified in [RFC8200].		This option is specified in [RFC8200].
	4.4.2.3. Specific Security Implications		4.4.2.3. Specific Security Implications
	Because of the possible size of this option, it could be leveraged as		Because of the possible size of this option, it could be leveraged as
	a large-bandwidth covert channel.		a large-bandwidth covert channel.
	4.4.2.4. Operational and Interoperability Impact if Blocked		4.4.2.4. Operational and Interoperability Impact If Blocked
	Discarding packets that contain this option would potentially break		Discarding packets that contain this option would potentially break
	any protocol that relies on IPv6 options.		any protocol that relies on IPv6 options.
	4.4.2.5. Advice		4.4.2.5. Advice
	Intermediate systems should not discard IPv6 packets based on the		Intermediate systems should not discard IPv6 packets based on the
	presence of this option.		presence of this option.
	4.4.3. Tunnel Encapsulation Limit (Type=0x04)		4.4.3. Tunnel Encapsulation Limit (Type=0x04)
	skipping to change at page 21, line 7 ¶		skipping to change at line 960 ¶
	The Tunnel Encapsulation Limit option can be employed to specify how		The Tunnel Encapsulation Limit option can be employed to specify how
	many further levels of nesting the packet is permitted to undergo.		many further levels of nesting the packet is permitted to undergo.
	4.4.3.2. Specification		4.4.3.2. Specification
	This option is specified in [RFC2473].		This option is specified in [RFC2473].
	4.4.3.3. Specific Security Implications		4.4.3.3. Specific Security Implications
	Those described in [RFC2473].		These are discussed in [RFC2473].
	4.4.3.4. Operational and Interoperability Impact if Blocked		4.4.3.4. Operational and Interoperability Impact If Blocked
	Discarding packets based on the presence of this option could result		Discarding packets based on the presence of this option could result
	in tunnel traffic being discarded.		in tunnel traffic being discarded.
	4.4.3.5. Advice		4.4.3.5. Advice
	Intermediate systems should not discard packets based on the presence		Intermediate systems should not discard packets based on the presence
	of this option.		of this option.
	4.4.4. Router Alert (Type=0x05)		4.4.4. Router Alert (Type=0x05)
	skipping to change at page 21, line 41 ¶		skipping to change at line 994 ¶
	This option is specified in [RFC2711].		This option is specified in [RFC2711].
	4.4.4.3. Specific Security Implications		4.4.4.3. Specific Security Implications
	Since this option causes the contents of the packet to be inspected		Since this option causes the contents of the packet to be inspected
	by the handling device, this option could be leveraged for performing		by the handling device, this option could be leveraged for performing
	DoS attacks. The security implications of the Router Alert option		DoS attacks. The security implications of the Router Alert option
	are discussed in detail in [RFC6398].		are discussed in detail in [RFC6398].
	4.4.4.4. Operational and Interoperability Impact if Blocked		4.4.4.4. Operational and Interoperability Impact If Blocked
	Discarding packets that contain this option would break any protocols		Discarding packets that contain this option would break any protocols
	that rely on them, such as RSVP and multicast deployments. Please		that rely on them, such as RSVP and multicast deployments. Please
	see Section 4.4.4.3 for further details.		see Section 4.4.4.3 for further details.
	4.4.4.5. Advice		4.4.4.5. Advice
	Packets containing this option should be permitted in environments		Packets containing this option should be permitted in environments
	where support for RSVP, multicast routing, or similar protocols is		where support for RSVP, multicast routing, or similar protocols is
	desired.		required.
	4.4.5. CALIPSO (Type=0x07)		4.4.5. CALIPSO (Type=0x07)
	4.4.5.1. Uses		4.4.5.1. Uses
	This option is used for encoding explicit packet Sensitivity Labels		This option is used for encoding explicit packet Sensitivity Labels
	on IPv6 packets. It is intended for use only within Multi-Level		on IPv6 packets. It is intended for use only within Multi-Level
	Secure (MLS) networking environments that are both trusted and		Secure (MLS) networking environments that are both trusted and
	trustworthy.		trustworthy.
	4.4.5.2. Specification		4.4.5.2. Specification
	This option is specified in [RFC5570].		This option is specified in [RFC5570].
	4.4.5.3. Specific Security Implications		4.4.5.3. Specific Security Implications
	Presence of this option in a packet does not by itself create any		Presence of this option in a packet does not by itself create any
	specific new threat. Packets with this option ought not normally be		specific new threat. Packets with this option ought not normally be
	seen on the global public Internet.		seen on the global public Internet.
	4.4.5.4. Operational and Interoperability Impact if Blocked		4.4.5.4. Operational and Interoperability Impact If Blocked
	If packets with this option are discarded or if the option is		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		Sensitivity Label with the received data from the packet whose Common
	CALIPSO was stripped by a middle-box (such as a packet-scrubber).		Architecture Label IPv6 Security Option (CALIPSO) was stripped by a
	Associating an incorrect sensitivity label can cause the received		middlebox (such as a packet scrubber). Associating an incorrect
	information either to be handled as more sensitive than it really is		Sensitivity Label can cause the received information to be handled
	("upgrading") or as less sensitive than it really is ("downgrading"),		either as more sensitive than it really is ("upgrading") or as less
	either of which is problematic. As noted in [RFC5570], IPsec		sensitive than it really is ("downgrading"), either of which is
	[RFC4301] [RFC4302] [RFC4303] can be employed to protect the CALIPSO		problematic. As noted in [RFC5570], IPsec [RFC4301] [RFC4302]
	option.		[RFC4303] can be employed to protect the CALIPSO.
	4.4.5.5. Advice		4.4.5.5. Advice
	Recommendations for handling the CALIPSO option depend on the		Recommendations for handling the CALIPSO depend on the deployment
	deployment environment, rather than whether an intermediate system		environment rather than on whether an intermediate system happens to
	happens to be deployed as a transit device (e.g., IPv6 transit		be deployed as a transit device (e.g., IPv6 transit router).
	router).
	Explicit configuration is the only method via which an intermediate		Explicit configuration is the only method via which an intermediate
	system can know whether that particular intermediate system has been		system can know whether that particular intermediate system has been
	deployed within a Multi-Level Secure (MLS) environment. In many		deployed within an MLS environment. In many cases, ordinary
	cases, ordinary commercial intermediate systems (e.g., IPv6 routers		commercial intermediate systems (e.g., IPv6 routers and firewalls)
	and firewalls) are the majority of the deployed intermediate systems		are the majority of the deployed intermediate systems inside an MLS
	inside an MLS network environment.		network environment.
	For Intermediate systems that DO NOT implement [RFC5570], there		For intermediate systems that DO NOT implement [RFC5570], there
	should be a configuration option to EITHER (a) drop packets		should be a configuration option to either (a) drop packets
	containing the CALIPSO option OR (b) to ignore the presence of the		containing the CALIPSO or (b) ignore the presence of the CALIPSO and
	CALIPSO option and forward the packets normally. In non-MLS		forward the packets normally. In non-MLS environments, such
	environments, such intermediate systems should have this		intermediate systems should have this configuration option set to (a)
	configuration option set to (a) above. In MLS environments, such		above. In MLS environments, such intermediate systems should have
	intermediate systems should have this option set to (b) above. The		this option set to (b) above. The default setting for this
	default setting for this configuration option should be set to (a)		configuration option should be set to (a) above, because MLS
	above, because MLS environments are much less common than non-MLS		environments are much less common than non-MLS environments.
	environments.
	For Intermediate systems that DO implement [RFC5570], there should be		For intermediate systems that DO implement [RFC5570], there should be
	configuration options (a) and (b) from the preceding paragraph and		configuration options (a) and (b) from the preceding paragraph and
	also a third configuration option (c) to process packets containing a		also a third configuration option (c) to process packets containing a
	CALIPSO option as per [RFC5570]. When deployed in non-MLS		CALIPSO as per [RFC5570]. When deployed in non-MLS environments,
	environments, such intermediate systems should have this		such intermediate systems should have this configuration option set
	configuration option set to (a) above. When deployed in MLS		to (a) above. When deployed in MLS environments, such intermediate
	environments, such intermediate systems should have this set to (c).		systems should have this configuration option set to (c). The
	The default setting for this configuration option MAY be set to (a)		default setting for this configuration option MAY be set to (a)
	above, because MLS environments are much less common than non-MLS		above, because MLS environments are much less common than non-MLS
	environments.		environments.
	4.4.6. SMF_DPD (Type=0x08)		4.4.6. SMF_DPD (Type=0x08)
	4.4.6.1. Uses		4.4.6.1. Uses
	This option is employed in the (experimental) Simplified Multicast		This option is employed in the (experimental) Simplified Multicast
	Forwarding (SMF) for unique packet identification for IPv6 I-DPD, and		Forwarding (SMF) for unique packet identification for IPv6
	as a mechanism to guarantee non-collision of hash values for		Identification-based DPD (I-DPD) and as a mechanism to guarantee non-
	different packets when H-DPD is used.		collision of hash values for different packets when Hash-based DPD
			(H-DPD) is used.
	4.4.6.2. Specification		4.4.6.2. Specification
	This option is specified in [RFC6621].		This option is specified in [RFC6621].
	4.4.6.3. Specific Security Implications		4.4.6.3. Specific Security Implications
	None. The use of transient numeric identifiers is subject to the		None. The use of transient numeric identifiers is subject to the
	security and privacy considerations discussed in		security and privacy considerations discussed in [NUMERIC-IDS].
	[I-D.irtf-pearg-numeric-ids-generation].
	4.4.6.4. Operational and Interoperability Impact if Blocked		4.4.6.4. Operational and Interoperability Impact If Blocked
	Dropping packets containing this option within a MANET domain would		Dropping packets containing this option within a Mobile Ad Hoc
	break SMF. However, dropping such packets at the border of such		Network (MANET) domain would break SMF. However, dropping such
	domain would have no negative impact.		packets at the border of such domain would have no negative impact.
	4.4.6.5. Advice		4.4.6.5. Advice
	Intermediate systems that are not within a MANET domain should		Intermediate systems that are not within a MANET domain should
	discard packets that contain this option.		discard packets that contain this option.
	4.4.7. PDM (Type=0x0F)		4.4.7. PDM (Type=0x0F)
	4.4.7.1. Uses		4.4.7.1. Uses
	This option is employed to convey sequence numbers and timing		This option is employed to convey sequence numbers and timing
	information in IPv6 packets as a basis for measurements.		information in IPv6 packets as a basis for measurements.
	4.4.7.2. Specification		4.4.7.2. Specification
	This option is specified in [RFC8250].		This option is specified in [RFC8250].
	4.4.7.3. Specific Security Implications		4.4.7.3. Specific Security Implications
	Those specified in [RFC8250]. Additionally, since the options		These are discussed in [RFC8250]. Additionally, since this option
	employs transient numeric identifiers, implementations may be subject		employs transient numeric identifiers, implementations may be subject
	to the issues discussed in [I-D.irtf-pearg-numeric-ids-generation].		to the issues discussed in [NUMERIC-IDS].
	4.4.7.4. Operational and Interoperability Impact if Blocked		4.4.7.4. Operational and Interoperability Impact If Blocked
	Dropping packets containing this option will result in negative		Dropping packets containing this option will result in negative
	interoperaiblity implications for traffic employing this option as a		interoperability implications for traffic employing this option as a
	basis for measurements.		basis for measurements.
	4.4.7.5. Advice		4.4.7.5. Advice
	Intermediate systems should not discard packets based on the presence		Intermediate systems should not discard packets based on the presence
	of this option.		of this option.
	4.4.8. RPL Option (Type=0x23)		4.4.8. RPL Option (Type=0x23)
	4.4.8.1. Uses		4.4.8.1. Uses
	The RPL Option provides a mechanism to include routing information		The RPL Option provides a mechanism to include routing information in
	with each datagram that an RPL router forwards.		each datagram that a RPL router forwards.
	4.4.8.2. Specification		4.4.8.2. Specification
	This option is specified in [RFC9008].		This option is specified in [RFC9008].
	4.4.8.3. Specific Security Implications		4.4.8.3. Specific Security Implications
	Those described in [RFC9008].		These are discussed in [RFC9008].
	4.4.8.4. Operational and Interoperability Impact if Blocked		4.4.8.4. Operational and Interoperability Impact If Blocked
	This option can survive outside of an RPL instance. As a result,		This option can survive outside of a RPL instance. As a result,
	discarding packets based on the presence of this option would break		discarding packets based on the presence of this option would break
	some use cases for RPL (see [RFC9008]).		some use cases for RPL (see [RFC9008]).
	4.4.8.5. Advice		4.4.8.5. Advice
	Intermediate systems should not discard IPv6 packets based on the		Intermediate systems should not discard IPv6 packets based on the
	presence of this option.		presence of this option.
	4.4.9. Quick-Start (Type=0x26)		4.4.9. Quick-Start (Type=0x26)
	4.4.9.1. Uses		4.4.9.1. Uses
	This IP Option is used in the specification of Quick-Start for TCP		This IP option is used in the specification of Quick-Start for TCP
	and IP, which is an experimental mechanism that allows transport		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) [RFC4782].		transfer (e.g., after an idle period) [RFC4782].
	4.4.9.2. Specification		4.4.9.2. Specification
	This option is specified in [RFC4782], on the "Experimental" track.		This option is specified in [RFC4782] on the "Experimental" track.
	4.4.9.3. Specific Security Implications		4.4.9.3. Specific Security Implications
	Section 9.6 of [RFC4782] notes that Quick-Start is vulnerable to two		Section 9.6 of [RFC4782] notes that Quick-Start is vulnerable to two
	kinds of attacks:		kinds of attacks:
	* attacks to increase the routers' processing and state load, and,		* attacks to increase the routers' processing and state load and
	* attacks with bogus Quick-Start Requests to temporarily tie up		* attacks with bogus Quick-Start Requests to temporarily tie up
	available Quick-Start bandwidth, preventing routers from approving		available Quick-Start bandwidth, preventing routers from approving
	Quick-Start Requests from other connections.		Quick-Start Requests from other connections
	We note that if routers in a given environment do not implement and		We note that if routers in a given environment do not implement and
	enable the Quick-Start mechanism, only the general security		enable the Quick-Start mechanism, only the general security
	implications of IP options (discussed in Section 4.2) would apply.		implications of IP options (discussed in Section 4.2) would apply.
	4.4.9.4. Operational and Interoperability Impact if Blocked		4.4.9.4. Operational and Interoperability Impact If Blocked
	The Quick-Start functionality would be disabled, and additional		If packets with IPv6 Quick Start options are blocked, the host trying
	delays in TCP's connection establishment (for example) could be		to establish a TCP connection will fall back to not including the
	introduced. (Please see Section 4.7.2 of [RFC4782].) We note,		Quick Start option -- this means that the feature will be disabled,
	however, that Quick-Start has been proposed as a mechanism that could		and additional delays in connection establishment will be introduced
	be of use in controlled environments, and not as a mechanism that		(as discussed in Section 4.7.2 of [RFC4782]). We note, however, that
	would be intended or appropriate for ubiquitous deployment in the		Quick-Start has been proposed as a mechanism that could be of use in
	global Internet [RFC4782].		controlled environments and not as a mechanism that would be intended
			or appropriate for ubiquitous deployment in the global Internet
			[RFC4782].
	4.4.9.5. Advice		4.4.9.5. Advice
	Intermediate systems should not discard IPv6 packets based on the		Intermediate systems should not discard IPv6 packets based on the
	presence of this option.		presence of this option.
	4.4.10. Deprecated (Type=0x4D)		4.4.10. Deprecated (Type=0x4D)
	4.4.10.1. Uses		4.4.10.1. Uses
	No information has been found about this option type.		No information has been found about this option type.
	4.4.10.2. Specification		4.4.10.2. Specification
	No information has been found about this option type.		No information has been found about this option type.
	4.4.10.3. Specific Security Implications		4.4.10.3. Specific Security Implications
	No information has been found about this option type, and hence it		No information has been found about this option type; hence, it has
	has been impossible to perform the corresponding security assessment.		been impossible to perform the corresponding security assessment.
	4.4.10.4. Operational and Interoperability Impact if Blocked		4.4.10.4. Operational and Interoperability Impact If Blocked
	Unknown.		Unknown.
	4.4.10.5. Advice		4.4.10.5. Advice
	Intermediate systems should discard packets that contain this option.		Intermediate systems should discard packets that contain this option.
	4.4.11. RPL Option (Type=0x63)		4.4.11. RPL Option (Type=0x63)
	4.4.11.1. Uses		4.4.11.1. Uses
	The RPL Option provides a mechanism to include routing information		The RPL Option provides a mechanism to include routing information in
	with each datagram that an RPL router forwards.		each datagram that a RPL router forwards.
	4.4.11.2. Specification		4.4.11.2. Specification
	This option was originally specified in [RFC6553]. It has been		This option was originally specified in [RFC6553]. It has been
	deprecated by [RFC9008].		deprecated by [RFC9008].
	4.4.11.3. Specific Security Implications		4.4.11.3. Specific Security Implications
	Those described in [RFC9008].		These are discussed in Section 5 of [RFC6553].
	4.4.11.4. Operational and Interoperability Impact if Blocked		4.4.11.4. Operational and Interoperability Impact If Blocked
	This option is meant to be employed within an RPL instance. As a		This option is meant to be employed within a RPL instance. As a
	result, discarding packets based on the presence of this option		result, discarding packets based on the presence of this option
	outside of an RPL instance will not result in interoperability		outside of a RPL instance will not result in interoperability
	implications.		implications.
	4.4.11.5. Advice		4.4.11.5. Advice
	Non-RPL routers should discard packets that contain an RPL option.		Intermediate systems should discard packets that contain a RPL
			Option.
	4.4.12. MPL Option (Type=0x6D)		4.4.12. MPL Option (Type=0x6D)
	4.4.12.1. Uses		4.4.12.1. Uses
	This option is used with the Multicast Protocol for Low power and		This option is used with the Multicast Protocol for Low power and
	Lossy Networks (MPL), that provides IPv6 multicast forwarding in		Lossy Networks (MPL), which provides IPv6 multicast forwarding in
	constrained networks.		constrained networks.
	4.4.12.2. Specification		4.4.12.2. Specification
	This option is specified in [RFC7731], and is meant to be included		This option is specified in [RFC7731] and is meant to be included
	only in Hop-by-Hop Option headers.		only in Hop-by-Hop Options headers.
	4.4.12.3. Specific Security Implications		4.4.12.3. Specific Security Implications
	Those described in [RFC7731].		These are discussed in [RFC7731].
	4.4.12.4. Operational and Interoperability Impact if Blocked		4.4.12.4. Operational and Interoperability Impact If Blocked
	Dropping packets that contain an MPL option within an MPL network		Dropping packets that contain an MPL Option within an MPL network
	would break the Multicast Protocol for Low power and Lossy Networks		would break the MPL. However, dropping such packets at the border of
	(MPL). However, dropping such packets at the border of such networks		such networks will have no negative impact.
	will have no negative impact.
	4.4.12.5. Advice		4.4.12.5. Advice
	Intermediate systems should not discard packets based on the presence		Intermediate systems should not discard packets based on the presence
	of this option. However, since this option has been specified for		of this option. However, since this option has been specified for
	the Hop-by-Hop Options, such systems should consider the discussion		the Hop-by-Hop Options header, such systems should consider the
	in Section 3.5.1.		discussion in Section 3.5.1.
	4.4.13. Endpoint Identification (Type=0x8A)		4.4.13. Endpoint Identification (Type=0x8A)
	4.4.13.1. Uses		4.4.13.1. Uses
	The Endpoint Identification option was meant to be used with the		The Endpoint Identification option was meant to be used with the
	Nimrod routing architecture [NIMROD-DOC], but has never seen		Nimrod routing architecture [NIMROD-DOC] but has never seen
	widespread deployment.		widespread deployment.
	4.4.13.2. Specification		4.4.13.2. Specification
	This option is specified in [NIMROD-DOC].		This option is specified in [NIMROD-DOC].
	4.4.13.3. Specific Security Implications		4.4.13.3. Specific Security Implications
	Undetermined.		Undetermined.
	4.4.13.4. Operational and Interoperability Impact if Blocked		4.4.13.4. Operational and Interoperability Impact If Blocked
	None.		None.
	4.4.13.5. Advice		4.4.13.5. Advice
	Intermediate systems should discard packets that contain this option.		Intermediate systems should discard packets that contain this option.
	4.4.14. ILNP Nonce (Type=0x8B)		4.4.14. ILNP Nonce (Type=0x8B)
	4.4.14.1. Uses		4.4.14.1. Uses
	This option is employed by Identifier-Locator Network Protocol for		This option is employed by the Identifier-Locator Network Protocol
	IPv6 (ILNPv6) for providing protection against off-path attacks for		for IPv6 (ILNPv6) to provide protection against off-path attacks for
	packets when ILNPv6 is in use, and as a signal during initial		packets when ILNPv6 is in use and as a signal during initial network-
	network-layer session creation that ILNPv6 is proposed for use with		layer session creation that ILNPv6 is proposed for use with this
	this network-layer session, rather than classic IPv6.		network-layer session, rather than classic IPv6.
	4.4.14.2. Specification		4.4.14.2. Specification
	This option is specified in [RFC6744].		This option is specified in [RFC6744].
	4.4.14.3. Specific Security Implications		4.4.14.3. Specific Security Implications
	Those described in [RFC6744].		These are discussed in [RFC6744].
	4.4.14.4. Operational and Interoperability Impact if Blocked		4.4.14.4. Operational and Interoperability Impact If Blocked
	Discarding packets that contain this option will break INLPv6		Discarding packets that contain this option will break ILNPv6
	deployments.		deployments.
	4.4.14.5. Advice		4.4.14.5. Advice
	Intermediate systems should not discard packets based on the presence		Intermediate systems should not discard packets based on the presence
	of this option.		of this option.
	4.4.15. Line-Identification Option (Type=0x8C)		4.4.15. Line-Identification Option (Type=0x8C)
	4.4.15.1. Uses		4.4.15.1. Uses
	skipping to change at page 29, line 24 ¶		skipping to change at line 1352 ¶
	This option is used by an Edge Router to identify the subscriber		This option is used by an Edge Router to identify the subscriber
	premises in scenarios where several subscriber premises may be		premises in scenarios where several subscriber premises may be
	logically connected to the same interface of an Edge Router.		logically connected to the same interface of an Edge Router.
	4.4.15.2. Specification		4.4.15.2. Specification
	This option is specified in [RFC6788].		This option is specified in [RFC6788].
	4.4.15.3. Specific Security Implications		4.4.15.3. Specific Security Implications
	Those described in [RFC6788].		These are discussed in [RFC6788].
	4.4.15.4. Operational and Interoperability Impact if Blocked		4.4.15.4. Operational and Interoperability Impact If Blocked
	Since this option is meant to be employed in Router Solicitation		Since this option is meant to be used when tunneling Neighbor
	messages, discarding packets based on the presence of this option at		Discovery messages in some broadband network deployment scenarios,
			discarding packets based on the presence of this option at
	intermediate systems will result in no interoperability implications.		intermediate systems will result in no interoperability implications.
	4.4.15.5. Advice		4.4.15.5. Advice
	Intermediate devices should discard packets that contain this option.		Intermediate systems should discard packets that contain this option.
	4.4.16. Jumbo Payload (Type=0XC2)		4.4.16. Jumbo Payload (Type=0XC2)
	4.4.16.1. Uses		4.4.16.1. Uses
	The Jumbo payload option provides the means of specifying payloads		The Jumbo Payload option provides the means for supporting payloads
	larger than 65535 bytes.		larger than 65535 bytes.
	4.4.16.2. Specification		4.4.16.2. Specification
	This option is specified in [RFC2675].		This option is specified in [RFC2675].
	4.4.16.3. Specific Security Implications		4.4.16.3. Specific Security Implications
	There are no specific issues arising from this option, except for		There are no specific issues arising from this option, except for
	improper validity checks of the option and associated packet lengths.		improper validity checks of the option and associated packet lengths.
	4.4.16.4. Operational and Interoperability Impact if Blocked		4.4.16.4. Operational and Interoperability Impact If Blocked
	Discarding packets based on the presence of this option will cause		Discarding packets based on the presence of this option will cause
	IPv6 jumbograms to be discarded.		IPv6 jumbograms to be discarded.
	4.4.16.5. Advice		4.4.16.5. Advice
	An operator should permit this option only in specific scenarios in		An operator should permit this option only in specific scenarios in
	which support for IPv6 jumbograms is desired.		which support for IPv6 jumbograms is required.
	4.4.17. Home Address (Type=0xC9)		4.4.17. Home Address (Type=0xC9)
	4.4.17.1. Uses		4.4.17.1. Uses
	The Home Address option is used by a Mobile IPv6 node while away from		The Home Address option is used by a Mobile IPv6 node while away from
	home, to inform the recipient of the mobile node's home address.		home to inform the recipient of the mobile node's home address.
	4.4.17.2. Specification		4.4.17.2. Specification
	This option is specified in [RFC6275].		This option is specified in [RFC6275].
	4.4.17.3. Specific Security Implications		4.4.17.3. Specific Security Implications
	No (known) additional security implications than those described in		There are no (known) additional security implications, other than
	[RFC6275].		those discussed in [RFC6275].
	4.4.17.4. Operational and Interoperability Impact if Blocked		4.4.17.4. Operational and Interoperability Impact If Blocked
	Discarding IPv6 packets based on the presence of this option will		Discarding IPv6 packets based on the presence of this option will
	break Mobile IPv6.		break Mobile IPv6.
	4.4.17.5. Advice		4.4.17.5. Advice
	Intermediate systems should not discard IPv6 packets based on the		Intermediate systems should not discard IPv6 packets based on the
	presence of this option.		presence of this option.
	4.4.18. IP_DFF (Type=0xEE)		4.4.18. IP_DFF (Type=0xEE)
	4.4.18.1. Uses		4.4.18.1. Uses
	This option is employed with the (Experimental) Depth-First		This option is employed with the (experimental) Depth-First
	Forwarding (DFF) in Unreliable Networks.		Forwarding (DFF) in unreliable networks.
	4.4.18.2. Specification		4.4.18.2. Specification
	This option is specified in [RFC6971].		This option is specified in [RFC6971].
	4.4.18.3. Specific Security Implications		4.4.18.3. Specific Security Implications
	Those specified in [RFC6971].		These are specified in [RFC6971].
	4.4.18.4. Operational and Interoperability Impact if Blocked		4.4.18.4. Operational and Interoperability Impact If Blocked
	Dropping packets containing this option within a routing domain that		Dropping packets containing this option within a routing domain that
	is running DFF would break DFF. However, dropping such packets at		is running DFF would break DFF. However, dropping such packets at
	the border of such domains will have no security implications.		the border of such domains will have no operational or
			interoperability implications.
	4.4.18.5. Advice		4.4.18.5. Advice
	Intermediate systems that do not operate within a routing domain that		Intermediate systems that do not operate within a routing domain that
	is running DFF should discard packets containing this option.		is running DFF should discard packets containing this option.
	4.4.19. RFC3692-style Experiment (Types = 0x1E, 0x3E, 0x5E, 0x7E, 0x9E,		4.4.19. RFC3692-Style Experiment (Types = 0x1E, 0x3E, 0x5E, 0x7E, 0x9E,
	0xBE, 0xDE, 0xFE)		0xBE, 0xDE, 0xFE)
	4.4.19.1. Uses		4.4.19.1. Uses
	These options can be employed for performing RFC3692-style		These options can be employed for performing RFC3692-style
	experiments. It is only appropriate to use these values in		experiments. It is only appropriate to use these values in
	explicitly configured experiments; they must not be shipped as		explicitly configured experiments; they must not be shipped as
	defaults in implementations.		defaults in implementations.
	4.4.19.2. Specification		4.4.19.2. Specification
	Specified in RFC 4727 [RFC4727] in the context of RFC3692-style		These options are specified in [RFC4727] in the context of
	experiments.		RFC3692-style experiments.
	4.4.19.3. Specific Security Implications		4.4.19.3. Specific Security Implications
	The specific security implications will depend on the specific use of		The specific security implications will depend on the specific use of
	these options.		these options.
	4.4.19.4. Operational and Interoperability Impact if Blocked		4.4.19.4. Operational and Interoperability Impact If Blocked
	For obvious reasons, discarding packets that contain these options		For obvious reasons, discarding packets that contain these options
	limits the ability to perform legitimate experiments across IPv6		limits the ability to perform legitimate experiments across IPv6
	routers.		routers.
	4.4.19.5. Advice		4.4.19.5. Advice
	Operators should determine according to their own circumstances		Operators should determine, according to their own circumstances,
	whether to discard packets containing these IPv6 options.		whether to discard packets containing these IPv6 options.
	4.5. Advice on the handling of Packets with Unknown IPv6 Options		4.5. Advice on the Handling of Packets with Unknown IPv6 Options
	We refer to IPv6 options that have not been assigned an IPv6 option		We refer to IPv6 options that have not been assigned an IPv6 Option
	type in the corresponding registry ([IANA-IPV6-PARAM]) as "unknown		Type in the corresponding registry, which is [IANA-IPV6-PARAM], as
	IPv6 options".		"unknown IPv6 options".
	4.5.1. Uses		4.5.1. Uses
	New IPv6 options may be specified as part of future protocol work.		New IPv6 options may be specified as part of future protocol work.
	4.5.2. Specification		4.5.2. Specification
	The processing of unknown IPv6 options is specified in [RFC8200].		The processing of unknown IPv6 options is specified in [RFC8200].
	4.5.3. Specific Security Implications		4.5.3. Specific Security Implications
	For obvious reasons, it is impossible to determine specific security		For obvious reasons, it is impossible to determine specific security
	implications of unknown IPv6 options.		implications of unknown IPv6 options.
	4.5.4. Operational and Interoperability Impact if Blocked		4.5.4. Operational and Interoperability Impact If Blocked
	Discarding unknown IPv6 options may slow down the deployment of new		Discarding unknown IPv6 options may slow down the deployment of new
	IPv6 options. As noted in [draft-gont-6man-ipv6-opt-transmit], the		IPv6 options. As noted in [IPv6-OPTIONS], the corresponding IANA
	corresponding IANA registry ([IANA-IPV6-PARAM] should be monitored		registry, which is [IANA-IPV6-PARAM], should be monitored such that
	such that IPv6 option filtering rules are updated as new IPv6 options		IPv6 option filtering rules are updated as new IPv6 options are
	are standardized.		standardized.
	4.5.5. Advice		4.5.5. Advice
	Operators should determine according to their own circumstances		Operators should determine, according to their own circumstances,
	whether to discard packets containing unknown IPv6 options.		whether to discard packets containing unknown IPv6 options.
	5. IANA Considerations		5. IANA Considerations
	This document has no actions for IANA.		This document has no IANA actions.
	6. Privacy Considerations		6. Privacy Considerations
	There are no privacy considerations associated with this document.		There are no privacy considerations associated with this document.
	7. Security Considerations		7. Security Considerations
	This document provides advice on the filtering of IPv6 packets that		This document provides advice on the filtering of IPv6 packets that
	contain IPv6 EHs (and possibly IPv6 options) at IPv6 transit routers.		contain IPv6 EHs (and possibly IPv6 options) at IPv6 transit routers.
	It is meant to improve the current situation of widespread dropping		It is meant to improve the current situation of widespread dropping
	of such IPv6 packets in those cases where the drops result from		of such IPv6 packets in those cases where the drops result from
	improper configuration defaults, or inappropriate advice in this		improper configuration defaults or inappropriate advice in this area.
	area.
	As discussed in Section Section 3.3 of this document, one of the		As discussed in Section 3.3, one of the underlying principles for the
	underlying principles for the advice provided in this document is		advice provided in this document is that IPv6 packets with specific
	that IPv6 packets with specific EHs or options which may represent an		EHs or options that may represent an attack vector for infrastructure
	attack vector for infrastructure devices should be dropped. While		devices should be dropped. While this policy helps mitigate some
	this policy helps mitigate some specific attack vectors, the		specific attack vectors, the recommendations in this document will
	recommendations in this document will not help to mitigate		not help to mitigate vulnerabilities based on implementation errors
	vulnerabilities based on implementation errors [RFC9098].		[RFC9098].
	We also note that depending on the router architecture, attempts to		We also note that depending on the router architecture, attempts to
	filter packets ased on the presence of IPv6 EHs or options might		filter packets based on the presence of IPv6 EHs or options might
	itself represent an attack vector to network infrastructure devices		itself represent an attack vector to network infrastructure devices
	[RFC9098].		[RFC9098].
	8. Acknowledgements		8. References
	The authors would like to thank Ron Bonica for his work on earlier
	versions of this document.
	The authors of this document would like to thank (in alphabetical
	order) Mikael Abrahamsson, Brian Carpenter, Tim Chown, Roman Danyliw,
	Darren Dukes, Lars Eggert, David Farmer, Mike Heard, Bob Hinden,
	Christian Huitema, Benjamin Kaduk, Erik Kline, Murray Kucherawy, Jen
	Linkova, Carlos Pignataro, Alvaro Retana, Maria Ines Robles,
	Zaheduzzaman Sarker, Donald Smith, Pascal Thubert, Ole Troan, Gunter
	Van De Velde, Eric Vyncke, and Robert Wilton, for providing valuable
	comments on earlier versions of this document.
	This document borrows some text and analysis from [RFC7126], authored
	by Fernando Gont, Randall Atkinson, and Carlos Pignataro.
	The authors would like to thank Warren Kumari and Eric Vyncke for
	their guidance during the publication process of this document.
	Fernando would also like to thank Brian Carpenter and Ran Atkinson
	who, over the years, have answered many questions and provided
	valuable comments that have benefited his protocol-related work
	(including the present document).
	9. References
	9.1. Normative References		8.1. Normative References
	[RFC1034] Mockapetris, P., "Domain names - concepts and facilities",		[RFC1034] Mockapetris, P V., "Domain names - concepts and
	STD 13, RFC 1034, DOI 10.17487/RFC1034, November 1987,		facilities", STD 13, RFC 1034, DOI 10.17487/RFC1034,
	<https://www.rfc-editor.org/info/rfc1034>.		November 1987, <https://www.rfc-editor.org/info/rfc1034>.
	[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate		[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
	Requirement Levels", BCP 14, RFC 2119,		Requirement Levels", BCP 14, RFC 2119,
	DOI 10.17487/RFC2119, March 1997,		DOI 10.17487/RFC2119, March 1997,
	<https://www.rfc-editor.org/info/rfc2119>.		<https://www.rfc-editor.org/info/rfc2119>.
	[RFC2205] Braden, R., Ed., Zhang, L., Berson, S., Herzog, S., and S.		[RFC2205] Braden, R., Ed., Zhang, L., Berson, S., Herzog, S., and S.
	Jamin, "Resource ReSerVation Protocol (RSVP) -- Version 1		Jamin, "Resource ReSerVation Protocol (RSVP) -- Version 1
	Functional Specification", RFC 2205, DOI 10.17487/RFC2205,		Functional Specification", RFC 2205, DOI 10.17487/RFC2205,
	September 1997, <https://www.rfc-editor.org/info/rfc2205>.		September 1997, <https://www.rfc-editor.org/info/rfc2205>.
	skipping to change at page 37, line 38 ¶		skipping to change at line 1718 ¶
	[RFC8754] Filsfils, C., Ed., Dukes, D., Ed., Previdi, S., Leddy, J.,		[RFC8754] Filsfils, C., Ed., Dukes, D., Ed., Previdi, S., Leddy, J.,
	Matsushima, S., and D. Voyer, "IPv6 Segment Routing Header		Matsushima, S., and D. Voyer, "IPv6 Segment Routing Header
	(SRH)", RFC 8754, DOI 10.17487/RFC8754, March 2020,		(SRH)", RFC 8754, DOI 10.17487/RFC8754, March 2020,
	<https://www.rfc-editor.org/info/rfc8754>.		<https://www.rfc-editor.org/info/rfc8754>.
	[RFC8900] Bonica, R., Baker, F., Huston, G., Hinden, R., Troan, O.,		[RFC8900] Bonica, R., Baker, F., Huston, G., Hinden, R., Troan, O.,
	and F. Gont, "IP Fragmentation Considered Fragile",		and F. Gont, "IP Fragmentation Considered Fragile",
	BCP 230, RFC 8900, DOI 10.17487/RFC8900, September 2020,		BCP 230, RFC 8900, DOI 10.17487/RFC8900, September 2020,
	<https://www.rfc-editor.org/info/rfc8900>.		<https://www.rfc-editor.org/info/rfc8900>.
	[RFC9008] Robles, M.I., Richardson, M., and P. Thubert, "Using RPI		[RFC9008] Robles, M I., Richardson, M., and P. Thubert, "Using RPI
	Option Type, Routing Header for Source Routes, and IPv6-		Option Type, Routing Header for Source Routes, and IPv6-
	in-IPv6 Encapsulation in the RPL Data Plane", RFC 9008,		in-IPv6 Encapsulation in the RPL Data Plane", RFC 9008,
	DOI 10.17487/RFC9008, April 2021,		DOI 10.17487/RFC9008, April 2021,
	<https://www.rfc-editor.org/info/rfc9008>.		<https://www.rfc-editor.org/info/rfc9008>.
	9.2. Informative References		8.2. Informative References
	[Biondi2007]		[Biondi-2007]
	Biondi, P. and A. Ebalard, "IPv6 Routing Header Security",		Biondi, P. and A. Ebalard, "IPv6 Routing Header Security",
	CanSecWest 2007 Security Conference, 2007,		CanSecWest Security Conference, April 2007,
	<http://www.secdev.org/conf/IPv6_RH_security-csw07.pdf>.		<http://www.secdev.org/conf/IPv6_RH_security-csw07.pdf>.
	[Cisco-EH] Cisco Systems, "IPv6 Extension Headers Review and		[Cisco-EH] Cisco Systems, "IPv6 Extension Headers Review and
	Considerations", Whitepaper. October 2006,		Considerations", Whitepaper, October 2006,
	<https://www.cisco.com/en/US/technologies/tk648/tk872/		<https://www.cisco.com/en/US/technologies/tk648/tk872/
	technologies_white_paper0900aecd8054d37d.pdf>.		technologies_white_paper0900aecd8054d37d.pdf>.
	[draft-gont-6man-ipv6-opt-transmit]
	Gont, F., Liu, W., and R. Bonica, "Transmission and
	Processing of IPv6 Options", IETF Internet Draft, work in
	progress, August 2014.
	[draft-ietf-nimrod-eid]
	Lynn, C.L., "Endpoint Identifier Destination
	Option", IETF Internet Draft, draft-ietf-nimrod-eid-
	00.txt, November 1995.
	[FW-Benchmark]		[FW-Benchmark]
	Zack, E., "Firewall Security Assessment and Benchmarking		Zack, E., "Firewall Security Assessment and Benchmarking
	IPv6 Firewall Load Tests", IPv6 Hackers Meeting #1,		IPv6 Firewall Load Tests", IPv6 Hackers Meeting #1,
	Berlin, Germany. June 30, 2013,		Berlin, Germany, June 2013,
	<https://www.ipv6hackers.org/files/meetings/ipv6-hackers-		<https://www.ipv6hackers.org/files/meetings/ipv6-hackers-
	1/zack-ipv6hackers1-firewall-security-assessment-and-		1/zack-ipv6hackers1-firewall-security-assessment-and-
	benchmarking.pdf>.		benchmarking.pdf>.
	[Huston-2022]		[Huston-2022]
	Huston, G. and J. Damas, "IPv6 Fragmentation and EH		Huston, G. and J. Damas, "IPv6 Fragmentation and EH
	Behaviours", IEPG Meeting - March 2022 @ IETF 113, March		Behaviours", IEPG Meeting at IETF 113", March 2022,
	2022,
	<https://iepg.org/2022-03-20-ietf113/huston-v6frag.pdf>.		<https://iepg.org/2022-03-20-ietf113/huston-v6frag.pdf>.
	[I-D.irtf-pearg-numeric-ids-generation]
	Gont, F. and I. Arce, "On the Generation of Transient
	Numeric Identifiers", Work in Progress, Internet-Draft,
	draft-irtf-pearg-numeric-ids-generation-08, 31 January
	2022, <https://www.ietf.org/archive/id/draft-irtf-pearg-
	numeric-ids-generation-08.txt>.
	[I-D.vyncke-v6ops-james]
	Vyncke, É., Léas, R., and J. Iurman, "Just Another
	Measurement of Extension header Survivability (JAMES)",
	Work in Progress, Internet-Draft, draft-vyncke-v6ops-
	james-01, 19 March 2022, <https://www.ietf.org/archive/id/
	draft-vyncke-v6ops-james-01.txt>.
	[IANA-IPV6-PARAM]		[IANA-IPV6-PARAM]
	Internet Assigned Numbers Authority, "Internet Protocol		IANA, "Internet Protocol Version 6 (IPv6) Parameters",
	Version 6 (IPv6) Parameters", December 2013,		<https://www.iana.org/assignments/ipv6-parameters>.
	<https://www.iana.org/assignments/ipv6-parameters/
	ipv6-parameters.xhtml>.
	[IANA-PROTOCOLS]		[IANA-PROTOCOLS]
	Internet Assigned Numbers Authority, "Protocol Numbers",		IANA, "Protocol Numbers",
	2014, <https://www.iana.org/assignments/protocol-numbers/		<https://www.iana.org/assignments/protocol-numbers>.
	protocol-numbers.xhtml>.
			[IPv6-OPTIONS]
			Gont, F., Liu, W., and R. P. Bonica, "Transmission and
			Processing of IPv6 Options", Work in Progress, Internet-
			Draft, draft-gont-6man-ipv6-opt-transmit-02, 21 August
			2015, <https://datatracker.ietf.org/doc/html/draft-gont-
			6man-ipv6-opt-transmit-02>.
			[JAMES] Iurman, J., "Just Another Measurement of Extension header
			Survivability (JAMES)", Work in Progress, Internet-Draft,
			draft-vyncke-v6ops-james-02, 11 July 2022,
			<https://datatracker.ietf.org/doc/html/draft-vyncke-v6ops-
			james-02>.
	[NIMROD-DOC]		[NIMROD-DOC]
	Nimrod Documentation Page,		"Nimrod Documentation",
	"http://ana-3.lcs.mit.edu/~jnc/nimrod/".		<http://ana-3.lcs.mit.edu/~jnc/nimrod>.
			[NIMROD-EID]
			Lynn, C., "Endpoint Identifier Destination Option", Work
			in Progress, Internet-Draft, draft-ietf-nimrod-eid-00, 2
			March 1996, <https://datatracker.ietf.org/doc/html/draft-
			ietf-nimrod-eid-00>.
			[NUMERIC-IDS]
			Gont, F. and I. Arce, "On the Generation of Transient
			Numeric Identifiers", Work in Progress, Internet-Draft,
			draft-irtf-pearg-numeric-ids-generation-11, 11 July 2022,
			<https://datatracker.ietf.org/doc/html/draft-irtf-pearg-
			numeric-ids-generation-11>.
	[RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6		[RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6
	(IPv6) Specification", RFC 2460, DOI 10.17487/RFC2460,		(IPv6) Specification", RFC 2460, DOI 10.17487/RFC2460,
	December 1998, <https://www.rfc-editor.org/info/rfc2460>.		December 1998, <https://www.rfc-editor.org/info/rfc2460>.
	[RFC3871] Jones, G., Ed., "Operational Security Requirements for		[RFC3871] Jones, G., Ed., "Operational Security Requirements for
	Large Internet Service Provider (ISP) IP Network		Large Internet Service Provider (ISP) IP Network
	Infrastructure", RFC 3871, DOI 10.17487/RFC3871, September		Infrastructure", RFC 3871, DOI 10.17487/RFC3871, September
	2004, <https://www.rfc-editor.org/info/rfc3871>.		2004, <https://www.rfc-editor.org/info/rfc3871>.
	skipping to change at page 39, line 47 ¶		skipping to change at line 1820 ¶
	"Observations on the Dropping of Packets with IPv6		"Observations on the Dropping of Packets with IPv6
	Extension Headers in the Real World", RFC 7872,		Extension Headers in the Real World", RFC 7872,
	DOI 10.17487/RFC7872, June 2016,		DOI 10.17487/RFC7872, June 2016,
	<https://www.rfc-editor.org/info/rfc7872>.		<https://www.rfc-editor.org/info/rfc7872>.
	[RFC9098] Gont, F., Hilliard, N., Doering, G., Kumari, W., Huston,		[RFC9098] Gont, F., Hilliard, N., Doering, G., Kumari, W., Huston,
	G., and W. Liu, "Operational Implications of IPv6 Packets		G., and W. Liu, "Operational Implications of IPv6 Packets
	with Extension Headers", RFC 9098, DOI 10.17487/RFC9098,		with Extension Headers", RFC 9098, DOI 10.17487/RFC9098,
	September 2021, <https://www.rfc-editor.org/info/rfc9098>.		September 2021, <https://www.rfc-editor.org/info/rfc9098>.
			Acknowledgements
			The authors would like to thank Ron Bonica for his work on earlier
			draft versions of this document.
			The authors of this document would like to thank (in alphabetical
			order) Mikael Abrahamsson, Brian Carpenter, Tim Chown, Roman Danyliw,
			Darren Dukes, Lars Eggert, David Farmer, Mike Heard, Bob Hinden,
			Christian Huitema, Benjamin Kaduk, Erik Kline, Murray Kucherawy, Jen
			Linkova, Carlos Pignataro, Alvaro Retana, Maria Ines Robles,
			Zaheduzzaman Sarker, Donald Smith, Pascal Thubert, Ole Troan, Gunter
			Van de Velde, Éric Vyncke, and Robert Wilton for providing valuable
			comments on earlier draft versions of this document.
			This document borrows some text and analysis from [RFC7126], which is
			authored by Fernando Gont, Randall Atkinson, and Carlos Pignataro.
			The authors would like to thank Warren Kumari and Éric Vyncke for
			their guidance during the publication process for this document.
			Fernando would also like to thank Brian Carpenter and Ran Atkinson
			who, over the years, have answered many questions and provided
			valuable comments that have benefited his protocol-related work
			(including the present document).
	Authors' Addresses		Authors' Addresses
	Fernando Gont		Fernando Gont
	EdgeUno		SI6 Networks
	Segurola y Habana 4310, 7mo Piso		Segurola y Habana 4310 7mo piso
	Villa Devoto
	Ciudad Autonoma de Buenos Aires		Ciudad Autonoma de Buenos Aires
	Argentina		Argentina
	Email: fernando.gont@edgeuno.com		Email: fgont@si6networks.com
	URI: https://www.edgeuno.com		URI: https://www.si6networks.com
	Will (Shucheng) Liu		Will (Shucheng) Liu
	Huawei Technologies		Huawei Technologies
	Bantian, Longgang District		Bantian, Longgang District
	Shenzhen		Shenzhen
	518129		518129
	P.R. China		China
	Email: liushucheng@huawei.com		Email: liushucheng@huawei.com
End of changes. 204 change blocks.
	514 lines changed or deleted		531 lines changed or added
This html diff was produced by rfcdiff 1.48.