draft-ietf-opsec-ipv6-eh-filtering-09.txt   draft-ietf-opsec-ipv6-eh-filtering-10.txt 
opsec F. Gont opsec F. Gont
Internet-Draft SI6 Networks Internet-Draft EdgeUno
Intended status: Informational W. Liu Intended status: Informational W. Liu
Expires: 3 November 2022 Huawei Technologies Expires: 4 November 2022 Huawei Technologies
2 May 2022 3 May 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-09 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 Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/. Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on 3 November 2022. This Internet-Draft will expire on 4 November 2022.
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 (https://trustee.ietf.org/
license-info) in effect on the date of publication of this document. license-info) in effect on the date of publication of this document.
Please review these documents carefully, as they describe your rights Please review these documents carefully, as they describe your rights
and restrictions with respect to this document. Code Components and restrictions with respect to this document. Code Components
extracted from this document must include Revised BSD License text as extracted from this document must include Revised BSD License text as
described in Section 4.e of the Trust Legal Provisions and are described in Section 4.e of the Trust Legal Provisions and are
provided without warranty as described in the Revised BSD License. provided without warranty as described in the Revised BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Terminology and Conventions Used in This Document . . . . . . 4 2. Terminology and Assumptions Employed in This Document . . . . 4
2.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 4 2.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 4
2.2. Applicability Statement . . . . . . . . . . . . . . . . . 4 2.2. Applicability Statement . . . . . . . . . . . . . . . . . 4
2.3. Conventions . . . . . . . . . . . . . . . . . . . . . . . 4 2.3. Router Default Behavior and Features . . . . . . . . . . 4
3. IPv6 Extension Headers . . . . . . . . . . . . . . . . . . . 5 3. IPv6 Extension Headers . . . . . . . . . . . . . . . . . . . 5
3.1. General Discussion . . . . . . . . . . . . . . . . . . . 5 3.1. General Discussion . . . . . . . . . . . . . . . . . . . 5
3.2. General Security Implications . . . . . . . . . . . . . . 6 3.2. General Security Implications . . . . . . . . . . . . . . 6
3.3. Summary of 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 . . . . . . . . . . 6
3.4. Summary of Advice on the Handling of IPv6 Packets with
Specific IPv6 Extension Headers . . . . . . . . . . . . . 6 Specific IPv6 Extension Headers . . . . . . . . . . . . . 6
3.4. 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 . . . . . . . . . . . . . . . . . . . . 7
3.5. 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 . . . . . . . . . . . . . . . . . . . . 16
4. IPv6 Options . . . . . . . . . . . . . . . . . . . . . . . . 17 4. IPv6 Options . . . . . . . . . . . . . . . . . . . . . . . . 17
4.1. General Discussion . . . . . . . . . . . . . . . . . . . 17 4.1. General Discussion . . . . . . . . . . . . . . . . . . . 17
4.2. General Security Implications of IPv6 Options . . . . . . 17 4.2. General Security Implications of IPv6 Options . . . . . . 17
4.3. Advice on the Handling of Packets with Specific IPv6 4.3. Summary of Advice on the Handling of IPv6 Packets with
Options . . . . . . . . . . . . . . . . . . . . . . . . . 18 Specific IPv6 Extension Headers . . . . . . . . . . . . . 18
4.4. Advice on the handling of Packets with Unknown IPv6 4.4. Advice on the Handling of Packets with Specific IPv6
Options . . . . . . . . . . . . . . . . . . . . . . . . . 30 Options . . . . . . . . . . . . . . . . . . . . . . . . . 19
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 30 4.5. Advice on the handling of Packets with Unknown IPv6
6. Privacy Considerations . . . . . . . . . . . . . . . . . . . 30 Options . . . . . . . . . . . . . . . . . . . . . . . . . 32
7. Security Considerations . . . . . . . . . . . . . . . . . . . 31 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 32
8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 31 6. Privacy Considerations . . . . . . . . . . . . . . . . . . . 32
9. References . . . . . . . . . . . . . . . . . . . . . . . . . 31 7. Security Considerations . . . . . . . . . . . . . . . . . . . 32
9.1. Normative References . . . . . . . . . . . . . . . . . . 31 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 33
9.2. Informative References . . . . . . . . . . . . . . . . . 35 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 33
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 37 9.1. Normative References . . . . . . . . . . . . . . . . . . 33
9.2. Informative References . . . . . . . . . . . . . . . . . 37
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
e.g. enforcing ACLs or implementing other functions [RFC9098]. e.g. enforcing ACLs or implementing other functions [RFC9098].
Recent studies (see e.g. [RFC7872]) suggest that there is widespread Several studies (e.g. [Huston-2022], [I-D.vyncke-v6ops-james], and
dropping of IPv6 packets that contain IPv6 Extension Headers (EHs). [RFC7872]) suggest that there is widespread dropping of IPv6 packets
In some cases, such packet drops occur at transit routers. While that contain IPv6 Extension Headers (EHs). In some cases, such
some operators "officially" drop packets that contain IPv6 EHs, it is packet drops occur at transit routers. While some operators are
known to intentionally drop packets that contain IPv6 EHs, it is
possible that some of the measured packet drops are the result of possible that some of the measured packet drops are the result of
improper configuration defaults, or inappropriate advice in this inappropriate advice in this area.
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.
skipping to change at page 3, line 29 skipping to change at page 3, line 33
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 a
transit network, the policy typically follows a "deny-list" approach, transit network, the policy typically follows a "deny-list" approach,
where only packets with clear negative implications are dropped. On where only packets with clear negative implications are dropped. On
the other hand, when the policy is enforced closer to the destination the other hand, when the policy is enforced closer to the destination
systems, the policy typically follows an "accept-list" approach, systems, the policy typically follows an "accept-list" approach,
where only traffic that is expected to be received is allowed. The where only traffic that is expected to be received is allowed. The
advice in this document is aimed only at transit routers that may advice in this document is aimed only at transit routers that may
need to enforce a filtering policy based on the EHs and IPv6 options need to enforce a filtering policy based on the EHs and IPv6 options
a packet may contain, following a "deny-list" approach, and hence is a packet may contain, following a "deny-list" approach, and hence is
likely to be much more permissive that a filtering policy to be likely to be much more permissive than a filtering policy to be
employed at e.g. the edge of an enterprise network. The advice in employed at e.g. the edge of an enterprise network. The advice in
this document is meant to improve the current situation of the this document is meant to improve the current situation of the
dropping of packets with IPv6 EHs in the Internet [RFC7872] in such dropping of packets with IPv6 EHs in the Internet [RFC7872] in such
cases where packets are being dropped due to inappropriate or missing cases where packets are being dropped due to inappropriate or missing
guidelines. 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 which 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 of this document specifies the terminology and conventions Section 2 specifies the terminology and conventions employed
employed throughout this document. Section 3 of this document throughout this document. Section 3 discusses IPv6 EHs and provides
discusses IPv6 EHs and provides advice in the area of filtering IPv6 advice in the area of filtering IPv6 packets that contain such IPv6
packets that contain such IPv6 EHs. Section 4 of this document EHs. Section 4 discusses IPv6 options and provides advice in the
discusses IPv6 options and provides advice in the area of filtering area of filtering IPv6 packets that contain such options.
IPv6 packets that contain such options.
2. Terminology and Conventions Used 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 drops, and irrespective of
whether the specific filtering action is logged. whether the 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 BCP
14 [RFC2119] [RFC8174] when, and only when, they appear in all 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. Conventions 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 configurations, 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 are 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 (and log) packets containing this IPv6 EH or option type. * Drop packets containing this IPv6 EH or option type.
* Reject (and log) packets containing this IPv6 EH or option type * Reject packets containing this IPv6 EH or option type (where the
(where the packet drop is signaled with an ICMPv6 error message). 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 option type.
* Ignore this IPv6 EH or option type (as if it was not present) and * Ignore this IPv6 EH or option type (as if it was not present) and
process the packet according the rules for the remaining headers. process the packet according the rules for the remaining headers.
We note that if a packet carries forwarding information (e.g., in We note that if a packet carries forwarding information (e.g., in
an IPv6 Routing Header) this might be an inappropriate or an IPv6 Routing Header) this might be an inappropriate or
undesirable action. 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
skipping to change at page 6, line 19 skipping to change at page 6, line 25
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. Summary of Advice on the Handling of IPv6 Packets with Specific 3.3. Rationale for Our Advice on the Handling of IPv6 Packets with
Specific IPv6 Extension Headers
* IPv6 Packets with IPv6 Extension Headers (or options) that are not
expected to traverse transit routers should be dropped.
* IPv6 Packets with IPv6 Extension Headers (or options) that are
only expected to traverse transit routers when a specific
technology is employed, should be permitted (or dropped) based on
the knowledge regarding the use of such technology in transit
provider in question (i.e. permit the packets if the technology is
employed, or drop them)
* IPv6 Packets with IPv6 Extension Headers (or options) that
represent a concrete attack vector to network infrastructure
devices should be dropped.
* IPv6 packets with any other IPv6 Extension headers (or options)
should be permitted. This is an intentional trade-off made to
minimize ossification.
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.4, 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 | | IPv6 Hop-by-Hop Options | Drop or Ignore | Section |
| (Proto=0) | | 3.4.1 | | (Proto=0) | | 3.5.1 |
+-------------------------+--------------------------+-----------+ +-------------------------+--------------------------+-----------+
| Routing Header for IPv6 | Drop only RHT0 and RHT1. | Section | | Routing Header for IPv6 | Drop only RHT0 and RHT1. | Section |
| (Proto=43) | Permit other RH Types | 3.4.2 | | (Proto=43) | Permit other RH Types | 3.5.2 |
+-------------------------+--------------------------+-----------+ +-------------------------+--------------------------+-----------+
| Fragment Header for | Permit | Section | | Fragment Header for | Permit | Section |
| IPv6 (Proto=44) | | 3.4.3 | | IPv6 (Proto=44) | | 3.5.3 |
+-------------------------+--------------------------+-----------+ +-------------------------+--------------------------+-----------+
| Encapsulating Security | Permit | Section | | Encapsulating Security | Permit | Section |
| Payload (Proto=50) | | 3.4.4 | | Payload (Proto=50) | | 3.5.4 |
+-------------------------+--------------------------+-----------+ +-------------------------+--------------------------+-----------+
| Authentication Header | Permit | Section | | Authentication Header | Permit | Section |
| (Proto=51) | | 3.4.5 | | (Proto=51) | | 3.5.5 |
+-------------------------+--------------------------+-----------+ +-------------------------+--------------------------+-----------+
| Destination Options for | Permit | Section | | Destination Options for | Permit | Section |
| IPv6 (Proto=60) | | 3.4.6 | | IPv6 (Proto=60) | | 3.5.6 |
+-------------------------+--------------------------+-----------+ +-------------------------+--------------------------+-----------+
| Mobility Header | Permit | Section | | Mobility Header | Permit | Section |
| (Proto=135) | | 3.4.7 | | (Proto=135) | | 3.5.7 |
+-------------------------+--------------------------+-----------+ +-------------------------+--------------------------+-----------+
| Host Identity Protocol | Permit | Section | | Host Identity Protocol | Permit | Section |
| (Proto=139) | | 3.4.8 | | (Proto=139) | | 3.5.8 |
+-------------------------+--------------------------+-----------+ +-------------------------+--------------------------+-----------+
| Shim6 Protocol | Permit | Section | | Shim6 Protocol | Permit | Section |
| (Proto=140) | | 3.4.9 | | (Proto=140) | | 3.5.9 |
+-------------------------+--------------------------+-----------+ +-------------------------+--------------------------+-----------+
| Use for experimentation | Drop | Section | | Use for experimentation | Drop | Section |
| and testing (Proto=253 | | 3.4.10 | | and testing (Proto=253 | | 3.5.10 |
| and 254) | | | | and 254) | | |
+-------------------------+--------------------------+-----------+ +-------------------------+--------------------------+-----------+
Table 1: Summary of Advice on the Handling of IPv6 Packets Table 1: Summary of Advice on the Handling of IPv6 Packets
with Specific IPv6 Extension Headers with Specific IPv6 Extension Headers
3.4. 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.4.1. IPv6 Hop-by-Hop Options (Protocol Number=0) 3.5.1. IPv6 Hop-by-Hop Options (Protocol Number=0)
3.4.1.1. Uses 3.5.1.1. Uses
The Hop-by-Hop Options header is used to carry optional information The Hop-by-Hop Options header is used to carry optional information
that may be examined by every node along a packet's delivery path. that may be examined by every node along a packet's delivery path.
It is expected that nodes will examine the Hop-by-Hop Options header It is expected that nodes will examine the Hop-by-Hop Options header
if explicitly configured to do so. 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, [RFC2460],
originally required that all nodes examined and processed the Hop-by- originally required that all nodes examined and processed the Hop-by-
Hop Options header. However, even before the publication of Hop Options header. However, even before the publication of
[RFC8200] a number of implementations already provided the option of [RFC8200] a number of implementations already provided the option of
ignoring this header unless explicitly configured to examine it. ignoring this header unless explicitly configured to examine it.
3.4.1.2. Specification 3.5.1.2. Specification
This EH is specified in [RFC8200]. At the time of this writing, the This EH is specified in [RFC8200]. As of May 2022, the following
following options have been specified for the Hop-by-Hop Options EH: options have been specified for the Hop-by-Hop Options EH:
* 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 9, line 16 skipping to change at page 9, line 16
* 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.4.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. Denial of Service attacks.
NOTE: While [RFC8200] has removed this requirement, the deployed base NOTE: While [RFC8200] has removed this requirement, the deployed base
may still reflect the classical behavior for a while, and hence the may still reflect the classical behavior for a while, and hence the
potential security problems of this EH are still of concern. potential security problems of this EH are still of concern.
3.4.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 EH would break any
of the protocols that rely on it for proper functioning. For 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.4.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
([RFC2460]) nodes, the recommended configuration for the processing ([RFC2460]) nodes, the recommended configuration for the processing
of these packets depends on the features and capabilities of the of these packets depends on the features and capabilities of the
underlying platform, the configuration of the platform, and also the underlying platform, the configuration of the platform, and also the
deployment environment of the platform. On platforms that allow deployment environment of the platform. On platforms that allow
forwarding of packets with HBH Options on the fast path, we recommend forwarding of packets with HBH Options on the fast path, we recommend
that packets with a HBH Options EH be forwarded as normal. that packets with a HBH Options EH be forwarded as normal.
Otherwise, on platforms in which processing of packets with a IPv6 Otherwise, on platforms in which processing of packets with a IPv6
skipping to change at page 10, line 9 skipping to change at page 10, line 9
be selected. Finally, when packets containing a HBH Options EH are be selected. Finally, when packets containing a HBH Options EH are
processed in the slow-path, and the underlying platform does not have processed in the slow-path, and the underlying platform does not have
any mitigation options available for attacks based on these packets, any mitigation options available for attacks based on these packets,
we recommend that such platforms discard packets containing IPv6 HBH we recommend that such platforms discard packets containing IPv6 HBH
Options EHs. Options EHs.
Finally, we note that RPL (Routing Protocol for Low-Power and Lossy Finally, we note that RPL (Routing Protocol for Low-Power and Lossy
Networks) routers [RFC6550] must not discard packets based on the Networks) routers [RFC6550] must not discard packets based on the
presence of an IPv6 Hop-by-Hop Options EH, as this would break RPL. presence of an IPv6 Hop-by-Hop Options EH, as this would break RPL.
3.4.2. Routing Header for IPv6 (Protocol Number=43) 3.5.2. Routing Header for IPv6 (Protocol Number=43)
3.4.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.4.2.2. Specification 3.5.2.2. Specification
This EH is specified in [RFC8200]. [RFC2460] had originally This EH is specified in [RFC8200]. [RFC2460] had originally
specified the Routing Header Type 0, which was later obsoleted by specified the Routing Header Type 0, which was later obsoleted by
[RFC5095], and thus removed from [RFC8200]. [RFC5095], and thus removed from [RFC8200].
At the time of this writing, the following Routing Types have been At of May 2022, the following Routing Types have been specified:
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]
* 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.4.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 RHT0 have been discussed in detail in
[Biondi2007] and [RFC5095]. RHT1 was never widely implemented. The [Biondi2007] and [RFC5095]. RHT1 was never widely implemented. The
security implications of RHT2, RHT3, and RHT4 (SRH) are discussed in security implications of RHT2, RHT3, and RHT4 (SRH) are discussed in
[RFC6275], [RFC6554], and [RFC8754], respectively. [RFC6275], [RFC6554], and [RFC8754], respectively.
3.4.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 a RHT0 or RHT1 has no operational
implications, since both have been deprecated. Blocking packets with implications, since both have been deprecated. Blocking packets with
a RHT2 would break Mobile IPv6. Packets with a RHT3 may be safely a RHT2 would break Mobile IPv6. Packets with a RHT3 may be safely
blocked at RPL domain boundaries, since RHT3 headers are employed blocked at RPL domain boundaries, since RHT3 headers are employed
within a single RPL domain. Blocking packets with a RHT4 (SRH) will within a single RPL domain. Blocking packets with a RHT4 (SRH) will
break Segment Routing (SR) deployments, if the filtering policy is break Segment Routing (SR) deployments, if the filtering policy is
enforced on packets being forwarded within an SR domain. enforced on packets being forwarded within an SR domain.
3.4.2.5. Advice 3.5.2.5. Advice
Intermediate systems should discard packets containing a RHT0, RHT1, Intermediate systems should discard packets containing a RHT0, RHT1,
or RHT3. Other routing header types should be permitted, as required or RHT3. Other routing header types should be permitted, as required
by [RFC7045]. by [RFC7045].
3.4.3. Fragment Header for IPv6 (Protocol Number=44) 3.5.3. Fragment Header for IPv6 (Protocol Number=44)
3.4.3.1. Uses 3.5.3.1. Uses
This EH provides the fragmentation functionality for IPv6. This EH provides the fragmentation functionality for IPv6.
3.4.3.2. Specification 3.5.3.2. Specification
This EH is specified in [RFC8200]. This EH is specified in [RFC8200].
3.4.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 Denial of
Service attacks (e.g. based on flooding a target with IPv6 fragments) Service attacks (e.g. based on flooding a target with IPv6 fragments)
to information leakage attacks [RFC7739]. to information leakage attacks [RFC7739].
3.4.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.4.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.4.4. Encapsulating Security Payload (Protocol Number=50) 3.5.4. Encapsulating Security Payload (Protocol Number=50)
3.4.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.4.4.2. Specification 3.5.4.2. Specification
This EH is specified in [RFC4303]. This EH is specified in [RFC4303].
3.4.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.4.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.4.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.4.5. Authentication Header (Protocol Number=51) 3.5.5. Authentication Header (Protocol Number=51)
3.4.5.1. Uses 3.5.5.1. Uses
The Authentication Header can be employed for provide authentication The Authentication Header can be employed for provide authentication
services in IPv4 and IPv6. services in IPv4 and IPv6.
3.4.5.2. Specification 3.5.5.2. Specification
This EH is specified in [RFC4302]. This EH is specified in [RFC4302].
3.4.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.4.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.4.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.4.6. Destination Options for IPv6 (Protocol Number=60) 3.5.6. Destination Options for IPv6 (Protocol Number=60)
3.4.6.1. Uses 3.5.6.1. Uses
The Destination Options header is used to carry optional information The Destination Options header is used to carry optional information
that needs be examined only by a packet's destination node(s). that needs be examined only by a packet's destination node(s).
3.4.6.2. Specification 3.5.6.2. Specification
This EH is specified in [RFC8200]. At the time of this writing, the This EH is specified in [RFC8200]. As of May 2022, the following
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 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)
[draft-ietf-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]
skipping to change at page 13, line 50 skipping to change at page 14, line 4
* 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.4.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
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.3. see the Section 4.4.
3.4.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], including protocols such as ILNP [RFC6740] and Mobile IPv6 [RFC6275],
and IPv6 tunnels that employ the Tunnel Encapsulation Limit option. and IPv6 tunnels that employ the Tunnel Encapsulation Limit option.
3.4.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.4.7. Mobility Header (Protocol Number=135) 3.5.7. Mobility Header (Protocol Number=135)
3.4.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.4.7.2. Specification 3.5.7.2. Specification
This EH is specified in [RFC6275]. This EH is specified in [RFC6275].
3.4.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.4.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.4.7.5. Advice 3.5.7.5. Advice
Intermediate systems should permit packets containing this EH. Intermediate systems should permit packets containing this EH.
3.4.8. Host Identity Protocol (Protocol Number=139) 3.5.8. Host Identity Protocol (Protocol Number=139)
3.4.8.1. Uses 3.5.8.1. Uses
This EH is employed with the Host Identity Protocol (HIP), an This EH is employed with the Host Identity Protocol (HIP), a protocol
experimental protocol that allows consenting hosts to securely that allows consenting hosts to securely establish and maintain
establish and maintain shared IP-layer state, allowing separation of shared IP-layer state, allowing separation of the identifier and
the identifier and locator roles of IP addresses, thereby enabling locator roles of IP addresses, thereby enabling continuity of
continuity of communications across IP address changes. communications across IP address changes.
3.4.8.2. Specification 3.5.8.2. Specification
This EH is specified in [RFC7401]. This EH is specified in [RFC7401].
3.4.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 [RFC6275].
3.4.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 the Host Identity Protocol would
break HIP deployments. break HIP deployments.
3.4.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 Host
Identity Protocol EH. Identity Protocol EH.
3.4.9. Shim6 Protocol (Protocol Number=140) 3.5.9. Shim6 Protocol (Protocol Number=140)
3.4.9.1. Uses 3.5.9.1. Uses
This EH is employed by the Shim6 [RFC5533] Protocol. This EH is employed by the Shim6 [RFC5533] Protocol.
3.4.9.2. Specification 3.5.9.2. Specification
This EH is specified in [RFC5533]. This EH is specified in [RFC5533].
3.4.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.4.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.4.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.4.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.4.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.4.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.4.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.4.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.4.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.5. 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.5.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" is being employed for an IPv6 EH or an Upper-Layer protocol. Number" is being employed for an IPv6 EH or an Upper-Layer protocol.
3.5.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.5.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.5.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 ([IANA-PROTOCOLS]) should be monitored
such that filtering rules are updated as new IPv6 EHs are 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.5.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
skipping to change at page 18, line 5 skipping to change at page 18, line 5
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 DDoS risk to
that router's general-purpose CPU (and thus to the router itself). that router's general-purpose CPU (and thus to the router itself).
For some architectures, a possible mitigation would be to rate-limit For some architectures, a possible mitigation would be to rate-limit
the packets that are to be processed by the general-purpose CPU (see the packets that are to be processed by the general-purpose CPU (see
e.g. [Cisco-EH]). e.g. [Cisco-EH]).
4.3. Advice on the Handling of Packets with Specific IPv6 Options 4.3. Summary of Advice on the Handling of IPv6 Packets with Specific
IPv6 Extension Headers
This section summarizes the advice provided in Section 3.5, providing
references to the specific sections in which a detailed analysis can
be found.
+===============================+======================+===========+
| Option | Filtering policy | Reference |
+===============================+======================+===========+
| Pad1 (Type=0x00) | Permit | Section |
| | | 4.4.1 |
+-------------------------------+----------------------+-----------+
| PadN (Type=0x01) | Permit | Section |
| | | 4.4.2 |
+-------------------------------+----------------------+-----------+
| Tunnel Encapsulation Limit | Permit | Section |
| (Type=0x04) | | 4.4.3 |
+-------------------------------+----------------------+-----------+
| Router Alert (Type=0x05) | Permit based on | Section |
| | needed functionality | 4.4.4 |
+-------------------------------+----------------------+-----------+
| CALIPSO (Type=0x07) | Permit based on | Section |
| | needed functionality | 4.4.5 |
+-------------------------------+----------------------+-----------+
| SMF_DPD (Type=0x08) | Permit based on | Section |
| | needed functionality | 4.4.6 |
+-------------------------------+----------------------+-----------+
| PDM Option (Type=0x0F) | Permit | Section |
| | | 4.4.7 |
+-------------------------------+----------------------+-----------+
| RPL Option (Type=0x23) | Permit | Section |
| | | 4.4.8 |
+-------------------------------+----------------------+-----------+
| Quick-Start (Type=0x26) | Permit | Section |
| | | 4.4.9 |
+-------------------------------+----------------------+-----------+
| Deprecated (Type=0x4D) | Drop | Section |
| | | 4.4.10 |
+-------------------------------+----------------------+-----------+
| MPL Option (Type=0x6D) | Permit | Section |
| | | 4.4.12 |
+-------------------------------+----------------------+-----------+
| Jumbo Payload (Type=0C2) | Permit based on | Section |
| | needed functionality | 4.4.16 |
+-------------------------------+----------------------+-----------+
| RPL Option (Type=0x63) | Drop in non-RPL | Section |
| | routers | 4.4.11 |
+-------------------------------+----------------------+-----------+
| Endpoint Identification | Drop | Section |
| (Type=0x8A) | | 4.4.13 |
+-------------------------------+----------------------+-----------+
| ILNP Nonce (Type=0x8B) | Permit | Section |
| | | 4.4.14 |
+-------------------------------+----------------------+-----------+
| Line-Identification Option | Drop | Section |
| (Type=0x8C) | | 4.4.15 |
+-------------------------------+----------------------+-----------+
| Home Address (Type=0xC9) | Permit | Section |
| | | 4.4.17 |
+-------------------------------+----------------------+-----------+
| IP_DFF (Type=0xEE) | Permit based on | Section |
| | needed functionality | 4.4.18 |
+-------------------------------+----------------------+-----------+
| RFC3692-style Experiment | Permit based on | Section |
| (Types = 0x1E, 0x3E, 0x5E, | needed functionality | 4.4.19 |
| 0x7E, 0x9E, 0xBE, 0xDE, 0xFE) | | |
+-------------------------------+----------------------+-----------+
Table 2: Summary of Advice on the Handling of IPv6 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.
4.3.1. Pad1 (Type=0x00) 4.4.1. Pad1 (Type=0x00)
4.3.1.1. Uses 4.4.1.1. Uses
This option is used when necessary to align subsequent options and to This option is used when necessary to align subsequent options and to
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.3.1.2. Specification 4.4.1.2. Specification
This option is specified in [RFC8200]. This option is specified in [RFC8200].
4.3.1.3. Specific Security Implications 4.4.1.3. Specific Security Implications
None. None.
4.3.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.3.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.3.2. PadN (Type=0x01) 4.4.2. PadN (Type=0x01)
4.3.2.1. Uses 4.4.2.1. Uses
This option is used when necessary to align subsequent options and to This option is used when necessary to align subsequent options and to
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.3.2.2. Specification 4.4.2.2. Specification
This option is specified in [RFC8200]. This option is specified in [RFC8200].
4.3.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.3.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.3.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.3.3. Jumbo Payload (Type=0XC2) 4.4.3. Tunnel Encapsulation Limit (Type=0x04)
4.3.3.1. Uses
The Jumbo payload option provides the means of specifying payloads
larger than 65535 bytes.
4.3.3.2. Specification
This option is specified in [RFC2675].
4.3.3.3. Specific Security Implications
There are no specific issues arising from this option, except for
improper validity checks of the option and associated packet lengths.
4.3.3.4. Operational and Interoperability Impact if Blocked
Discarding packets based on the presence of this option will cause
IPv6 jumbograms to be discarded.
4.3.3.5. Advice
An operator should permit this option only in specific scenarios in
which support for IPv6 jumbograms is desired.
4.3.4. RPL Option (Type=0x63)
4.3.4.1. Uses
The RPL Option provides a mechanism to include routing information
with each datagram that an RPL router forwards.
4.3.4.2. Specification
This option was originally specified in [RFC6553]. It has been
deprecated by [RFC9008].
4.3.4.3. Specific Security Implications
Those described in [RFC9008].
4.3.4.4. Operational and Interoperability Impact if Blocked
This option is meant to be employed within an RPL instance. As a
result, discarding packets based on the presence of this option
outside of an RPL instance will not result in interoperability
implications.
4.3.4.5. Advice
Non-RPL routers should discard packets that contain an RPL option.
4.3.5. RPL Option (Type=0x23)
4.3.5.1. Uses
The RPL Option provides a mechanism to include routing information
with each datagram that an RPL router forwards.
4.3.5.2. Specification
This option is specified in [RFC9008].
4.3.5.3. Specific Security Implications
Those described in [RFC9008].
4.3.5.4. Operational and Interoperability Impact if Blocked
This option can survive outside of an RPL instance. As a result,
discarding packets based on the presence of this option would break
some use cases for RPL (see [RFC9008]).
4.3.5.5. Advice
Intermediate systems should not discard IPv6 packets based on the
presence of this option.
4.3.6. Tunnel Encapsulation Limit (Type=0x04) 4.4.3.1. Uses
4.3.6.1. Uses
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.3.6.2. Specification 4.4.3.2. Specification
This option is specified in [RFC2473]. This option is specified in [RFC2473].
4.3.6.3. Specific Security Implications 4.4.3.3. Specific Security Implications
Those described in [RFC2473]. Those described in [RFC2473].
4.3.6.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.3.6.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.3.7. Router Alert (Type=0x05) 4.4.4. Router Alert (Type=0x05)
4.3.7.1. Uses 4.4.4.1. Uses
The Router Alert option [RFC2711] is employed by a number of The Router Alert option [RFC2711] is employed by a number of
protocols, including the Resource reSerVation Protocol (RSVP) protocols, including the Resource reSerVation Protocol (RSVP)
[RFC2205], Multicast Listener Discovery (MLD) [RFC2710] [RFC3810], [RFC2205], Multicast Listener Discovery (MLD) [RFC2710] [RFC3810],
Multicast Router Discovery (MRD) [RFC4286], and General Internet Multicast Router Discovery (MRD) [RFC4286], and General Internet
Signaling Transport (GIST) [RFC5971]. Its usage is discussed in Signaling Transport (GIST) [RFC5971]. Its usage is discussed in
detail in [RFC6398]. detail in [RFC6398].
4.3.7.2. Specification 4.4.4.2. Specification
This option is specified in [RFC2711]. This option is specified in [RFC2711].
4.3.7.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.3.7.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.3.7.3 for further details. see Section 4.4.4.3 for further details.
4.3.7.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. desired.
4.3.8. Quick-Start (Type=0x26) 4.4.5. CALIPSO (Type=0x07)
4.3.8.1. Uses
This IP Option is used in the specification of Quick-Start for TCP
and IP, which is an experimental mechanism that allows transport
protocols, in cooperation with routers, to determine an allowed
sending rate at the start and, at times, in the middle of a data
transfer (e.g., after an idle period) [RFC4782].
4.3.8.2. Specification
This option is specified in [RFC4782], on the "Experimental" track.
4.3.8.3. Specific Security Implications
Section 9.6 of [RFC4782] notes that Quick-Start is vulnerable to two
kinds of attacks:
* attacks to increase the routers' processing and state load, and,
* attacks with bogus Quick-Start Requests to temporarily tie up
available Quick-Start bandwidth, preventing routers from approving
Quick-Start Requests from other connections.
We note that if routers in a given environment do not implement and
enable the Quick-Start mechanism, only the general security
implications of IP options (discussed in Section 4.2) would apply.
4.3.8.4. Operational and Interoperability Impact if Blocked
The Quick-Start functionality would be disabled, and additional
delays in TCP's connection establishment (for example) could be
introduced. (Please see Section 4.7.2 of [RFC4782].) We note,
however, that Quick-Start has been proposed as a mechanism that could
be of use in controlled environments, and not as a mechanism that
would be intended or appropriate for ubiquitous deployment in the
global Internet [RFC4782].
4.3.8.5. Advice
Intermediate systems should not discard IPv6 packets based on the
presence of this option.
4.3.9. CALIPSO (Type=0x07)
4.3.9.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.3.9.2. Specification 4.4.5.2. Specification
This option is specified in [RFC5570]. This option is specified in [RFC5570].
4.3.9.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.3.9.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
CALIPSO was stripped by an intermediate router or firewall. CALIPSO was stripped by a middle-box (such as a packet-scrubber).
Associating an incorrect sensitivity label can cause the received Associating an incorrect sensitivity label can cause the received
information either to be handled as more sensitive than it really is information either to be handled as more sensitive than it really is
("upgrading") or as less sensitive than it really is ("downgrading"), ("upgrading") or as less sensitive than it really is ("downgrading"),
either of which is problematic. As noted in [RFC5570], IPsec either of which is problematic. As noted in [RFC5570], IPsec
[RFC4301] [RFC4302] [RFC4303] can be employed to protect the CALIPSO [RFC4301] [RFC4302] [RFC4303] can be employed to protect the CALIPSO
option. option.
4.3.9.5. Advice 4.4.5.5. Advice
Recommendations for handling the CALIPSO option depend on the Recommendations for handling the CALIPSO option depend on the
deployment environment, rather than whether an intermediate system deployment environment, rather than whether an intermediate system
happens to be deployed as a transit device (e.g., IPv6 transit happens to 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 a Multi-Level Secure (MLS) environment. In many
cases, ordinary commercial intermediate systems (e.g., IPv6 routers cases, ordinary commercial intermediate systems (e.g., IPv6 routers
skipping to change at page 24, line 42 skipping to change at page 23, line 27
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 option as per [RFC5570]. When deployed in non-MLS
environments, such intermediate systems should have this environments, such intermediate systems should have this
configuration option set to (a) above. When deployed in MLS configuration option set to (a) above. When deployed in MLS
environments, such intermediate systems should have this set to (c). environments, such intermediate systems should have this set to (c).
The default setting for this configuration option MAY be set to (a) The 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.3.10. SMF_DPD (Type=0x08) 4.4.6. SMF_DPD (Type=0x08)
4.3.10.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 I-DPD, and
as a mechanism to guarantee non-collision of hash values for as a mechanism to guarantee non-collision of hash values for
different packets when H-DPD is used. different packets when H-DPD is used.
4.3.10.2. Specification 4.4.6.2. Specification
This option is specified in [RFC6621]. This option is specified in [RFC6621].
4.3.10.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
[I-D.irtf-pearg-numeric-ids-generation]. [I-D.irtf-pearg-numeric-ids-generation].
4.3.10.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 MANET domain would
break SMF. However, dropping such packets at the border of such break SMF. However, dropping such packets at the border of such
domain would have no negative impact. domain would have no negative impact.
4.3.10.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.3.11. Home Address (Type=0xC9) 4.4.7. PDM (Type=0x0F)
4.3.11.1. Uses 4.4.7.1. Uses
The Home Address option is used by a Mobile IPv6 node while away from This option is employed to convey sequence numbers and timing
home, to inform the recipient of the mobile node's home address. information in IPv6 packets as a basis for measurements.
4.3.11.2. Specification 4.4.7.2. Specification
This option is specified in [RFC6275]. This option is specified in [RFC8250].
4.3.11.3. Specific Security Implications 4.4.7.3. Specific Security Implications
No (known) additional security implications than those described in Those specified in [RFC8250]. Additionally, since the options
[RFC6275]. employs transient numeric identifiers, implementations may be subject
to the issues discussed in [I-D.irtf-pearg-numeric-ids-generation].
4.3.11.4. Operational and Interoperability Impact if Blocked 4.4.7.4. Operational and Interoperability Impact if Blocked
Discarding IPv6 packets based on the presence of this option will Dropping packets containing this option will result in negative
break Mobile IPv6. interoperaiblity implications for traffic employing this option as a
basis for measurements.
4.3.11.5. Advice 4.4.7.5. Advice
Intermediate systems should not discard packets based on the presence
of this option.
4.4.8. RPL Option (Type=0x23)
4.4.8.1. Uses
The RPL Option provides a mechanism to include routing information
with each datagram that an RPL router forwards.
4.4.8.2. Specification
This option is specified in [RFC9008].
4.4.8.3. Specific Security Implications
Those described in [RFC9008].
4.4.8.4. Operational and Interoperability Impact if Blocked
This option can survive outside of an RPL instance. As a result,
discarding packets based on the presence of this option would break
some use cases for RPL (see [RFC9008]).
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.3.12. Endpoint Identification (Type=0x8A) 4.4.9. Quick-Start (Type=0x26)
4.3.12.1. Uses 4.4.9.1. Uses
This IP Option is used in the specification of Quick-Start for TCP
and IP, which is an experimental mechanism that allows transport
protocols, in cooperation with routers, to determine an allowed
sending rate at the start and, at times, in the middle of a data
transfer (e.g., after an idle period) [RFC4782].
4.4.9.2. Specification
This option is specified in [RFC4782], on the "Experimental" track.
4.4.9.3. Specific Security Implications
Section 9.6 of [RFC4782] notes that Quick-Start is vulnerable to two
kinds of attacks:
* attacks to increase the routers' processing and state load, and,
* attacks with bogus Quick-Start Requests to temporarily tie up
available Quick-Start bandwidth, preventing routers from approving
Quick-Start Requests from other connections.
We note that if routers in a given environment do not implement and
enable the Quick-Start mechanism, only the general security
implications of IP options (discussed in Section 4.2) would apply.
4.4.9.4. Operational and Interoperability Impact if Blocked
The Quick-Start functionality would be disabled, and additional
delays in TCP's connection establishment (for example) could be
introduced. (Please see Section 4.7.2 of [RFC4782].) We note,
however, that Quick-Start has been proposed as a mechanism that could
be of use in 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
Intermediate systems should not discard IPv6 packets based on the
presence of this option.
4.4.10. Deprecated (Type=0x4D)
4.4.10.1. Uses
No information has been found about this option type.
4.4.10.2. Specification
No information has been found about this option type.
4.4.10.3. Specific Security Implications
No information has been found about this option type, and hence it
has been impossible to perform the corresponding security assessment.
4.4.10.4. Operational and Interoperability Impact if Blocked
Unknown.
4.4.10.5. Advice
Intermediate systems should discard packets that contain this option.
4.4.11. RPL Option (Type=0x63)
4.4.11.1. Uses
The RPL Option provides a mechanism to include routing information
with each datagram that an RPL router forwards.
4.4.11.2. Specification
This option was originally specified in [RFC6553]. It has been
deprecated by [RFC9008].
4.4.11.3. Specific Security Implications
Those described in [RFC9008].
4.4.11.4. Operational and Interoperability Impact if Blocked
This option is meant to be employed within an RPL instance. As a
result, discarding packets based on the presence of this option
outside of an RPL instance will not result in interoperability
implications.
4.4.11.5. Advice
Non-RPL routers should discard packets that contain an RPL option.
4.4.12. MPL Option (Type=0x6D)
4.4.12.1. Uses
This option is used with the Multicast Protocol for Low power and
Lossy Networks (MPL), that provides IPv6 multicast forwarding in
constrained networks.
4.4.12.2. Specification
This option is specified in [RFC7731], and is meant to be included
only in Hop-by-Hop Option headers.
4.4.12.3. Specific Security Implications
Those described in [RFC7731].
4.4.12.4. Operational and Interoperability Impact if Blocked
Dropping packets that contain an MPL option within an MPL network
would break the Multicast Protocol for Low power and Lossy Networks
(MPL). However, dropping such packets at the border of such networks
will have no negative impact.
4.4.12.5. Advice
Intermediate systems should not discard packets based on the presence
of this option. However, since this option has been specified for
the Hop-by-Hop Options, such systems should consider the discussion
in Section 3.5.1.
4.4.13. Endpoint Identification (Type=0x8A)
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.3.12.2. Specification 4.4.13.2. Specification
This option is specified in [NIMROD-DOC]. This option is specified in [NIMROD-DOC].
4.3.12.3. Specific Security Implications 4.4.13.3. Specific Security Implications
Undetermined. Undetermined.
4.3.12.4. Operational and Interoperability Impact if Blocked 4.4.13.4. Operational and Interoperability Impact if Blocked
None. None.
4.3.12.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.3.13. ILNP Nonce (Type=0x8B) 4.4.14. ILNP Nonce (Type=0x8B)
4.3.13.1. Uses 4.4.14.1. Uses
This option is employed by Identifier-Locator Network Protocol for This option is employed by Identifier-Locator Network Protocol for
IPv6 (ILNPv6) for providing protection against off-path attacks for IPv6 (ILNPv6) for providing 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-layer session creation that ILNPv6 is proposed for use with network-layer session creation that ILNPv6 is proposed for use with
this network-layer session, rather than classic IPv6. this network-layer session, rather than classic IPv6.
4.3.13.2. Specification 4.4.14.2. Specification
This option is specified in [RFC6744]. This option is specified in [RFC6744].
4.3.13.3. Specific Security Implications 4.4.14.3. Specific Security Implications
Those described in [RFC6744]. Those described in [RFC6744].
4.3.13.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 INLPv6
deployments. deployments.
4.3.13.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.3.14. Line-Identification Option (Type=0x8C) 4.4.15. Line-Identification Option (Type=0x8C)
4.3.14.1. Uses 4.4.15.1. Uses
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.3.14.2. Specification 4.4.15.2. Specification
This option is specified in [RFC6788]. This option is specified in [RFC6788].
4.3.14.3. Specific Security Implications 4.4.15.3. Specific Security Implications
Those described in [RFC6788]. Those described in [RFC6788].
4.3.14.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 employed in Router Solicitation
messages, discarding packets based on the presence of this option at messages, 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.3.14.5. Advice 4.4.15.5. Advice
Intermediate devices should discard packets that contain this option. Intermediate devices should discard packets that contain this option.
4.3.15. Deprecated (Type=0x4D) 4.4.16. Jumbo Payload (Type=0XC2)
4.3.15.1. Uses 4.4.16.1. Uses
No information has been found about this option type. The Jumbo payload option provides the means of specifying payloads
larger than 65535 bytes.
4.3.15.2. Specification 4.4.16.2. Specification
No information has been found about this option type. This option is specified in [RFC2675].
4.3.15.3. Specific Security Implications 4.4.16.3. Specific Security Implications
No information has been found about this option type, and hence it There are no specific issues arising from this option, except for
has been impossible to perform the corresponding security assessment. improper validity checks of the option and associated packet lengths.
4.3.15.4. Operational and Interoperability Impact if Blocked 4.4.16.4. Operational and Interoperability Impact if Blocked
Unknown. Discarding packets based on the presence of this option will cause
IPv6 jumbograms to be discarded.
4.3.15.5. Advice 4.4.16.5. Advice
Intermediate systems should discard packets that contain this option. An operator should permit this option only in specific scenarios in
which support for IPv6 jumbograms is desired.
4.3.16. MPL Option (Type=0x6D) 4.4.17. Home Address (Type=0xC9)
4.3.16.1. Uses 4.4.17.1. Uses
This option is used with the Multicast Protocol for Low power and The Home Address option is used by a Mobile IPv6 node while away from
Lossy Networks (MPL), that provides IPv6 multicast forwarding in home, to inform the recipient of the mobile node's home address.
constrained networks.
4.3.16.2. Specification 4.4.17.2. Specification
This option is specified in [RFC7731], and is meant to be included This option is specified in [RFC6275].
only in Hop-by-Hop Option headers.
4.3.16.3. Specific Security Implications 4.4.17.3. Specific Security Implications
Those described in [RFC7731]. No (known) additional security implications than those described in
[RFC6275].
4.3.16.4. Operational and Interoperability Impact if Blocked 4.4.17.4. Operational and Interoperability Impact if Blocked
Dropping packets that contain an MPL option within an MPL network Discarding IPv6 packets based on the presence of this option will
would break the Multicast Protocol for Low power and Lossy Networks break Mobile IPv6.
(MPL). However, dropping such packets at the border of such networks
will have no negative impact.
4.3.16.5. Advice 4.4.17.5. Advice
Intermediate systems should not discard packets based on the presence Intermediate systems should not discard IPv6 packets based on the
of this option. However, since this option has been specified for presence of this option.
the Hop-by-Hop Options, such systems should consider the discussion
in Section 3.4.1.
4.3.17. IP_DFF (Type=0xEE) 4.4.18. IP_DFF (Type=0xEE)
4.3.17.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.3.17.2. Specification 4.4.18.2. Specification
This option is specified in [RFC6971]. This option is specified in [RFC6971].
4.3.17.3. Specific Security Implications 4.4.18.3. Specific Security Implications
Those specified in [RFC6971]. Those specified in [RFC6971].
4.3.17.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 security implications.
4.3.17.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.3.18. 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.3.18.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.3.18.2. Specification 4.4.19.2. Specification
Specified in RFC 4727 [RFC4727] in the context of RFC3692-style Specified in RFC 4727 [RFC4727] in the context of RFC3692-style
experiments. experiments.
4.3.18.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.3.18.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.3.18.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.4. 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 ([IANA-IPV6-PARAM]) as "unknown
IPv6 options". IPv6 options".
4.4.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.4.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.4.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.4.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 [draft-gont-6man-ipv6-opt-transmit], the
corresponding IANA registry ([IANA-IPV6-PARAM] should be monitored corresponding IANA registry ([IANA-IPV6-PARAM] should be monitored
such that IPv6 option filtering rules are updated as new IPv6 options such that IPv6 option filtering rules are updated as new IPv6 options
are standardized. are standardized.
4.4.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 actions for IANA.
6. Privacy Considerations 6. Privacy Considerations
skipping to change at page 31, line 14 skipping to change at page 33, line 5
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
underlying principles for the advice provided in this document is
that IPv6 packets with specific EHs or options which may represent an
attack vector for infrastructure devices should be dropped. While
this policy helps mitigate some specific attack vectors, the
recommendations in this document will not help to mitigate
vulnerabilities based on implementation errors [RFC9098].
We also note that depending on the router architecture, attempts to
filter packets ased on the presence of IPv6 EHs or options might
itself represent an attack vector to network infrastructure devices
[RFC9098].
8. Acknowledgements 8. Acknowledgements
The authors would like to thank Ron Bonica for his work on earlier The authors would like to thank Ron Bonica for his work on earlier
versions of this document. versions of this document.
The authors of this document would like to thank (in alphabetical The authors of this document would like to thank (in alphabetical
order) Mikael Abrahamsson, Brian Carpenter, Darren Dukes, Lars order) Mikael Abrahamsson, Brian Carpenter, Tim Chown, Roman Danyliw,
Eggert, David Farmer, Mike Heard, Bob Hinden, Christian Huitema, Darren Dukes, Lars Eggert, David Farmer, Mike Heard, Bob Hinden,
Benjamin Kaduk, Erik Kline, Jen Linkova, Carlos Pignataro, Alvaro Christian Huitema, Benjamin Kaduk, Erik Kline, Murray Kucherawy, Jen
Retana, Maria Ines Robles, Donald Smith, Pascal Thubert, Ole Troan, Linkova, Carlos Pignataro, Alvaro Retana, Maria Ines Robles,
Gunter Van De Velde, and Eric Vyncke, for providing valuable comments Zaheduzzaman Sarker, Donald Smith, Pascal Thubert, Ole Troan, Gunter
on earlier versions of this document. 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 This document borrows some text and analysis from [RFC7126], authored
by Fernando Gont, Randall Atkinson, and Carlos Pignataro. by Fernando Gont, Randall Atkinson, and Carlos Pignataro.
The authors would like to thank Eric Vyncke for his guidance during The authors would like to thank Warren Kumari and Eric Vyncke for
the publication process of this document. their guidance during the publication process of this document.
Fernando would also like to thank Brian Carpenter and Ran Atkinson Fernando would also like to thank Brian Carpenter and Ran Atkinson
who, over the years, have answered many questions and provided who, over the years, have answered many questions and provided
valuable comments that have benefited his protocol-related work valuable comments that have benefited his protocol-related work
(including the present document). (including the present document).
9. References 9. References
9.1. Normative References 9.1. Normative References
skipping to change at page 35, line 14 skipping to change at page 37, line 23
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
May 2017, <https://www.rfc-editor.org/info/rfc8174>. May 2017, <https://www.rfc-editor.org/info/rfc8174>.
[RFC8200] Deering, S. and R. Hinden, "Internet Protocol, Version 6 [RFC8200] Deering, S. and R. Hinden, "Internet Protocol, Version 6
(IPv6) Specification", STD 86, RFC 8200, (IPv6) Specification", STD 86, RFC 8200,
DOI 10.17487/RFC8200, July 2017, DOI 10.17487/RFC8200, July 2017,
<https://www.rfc-editor.org/info/rfc8200>. <https://www.rfc-editor.org/info/rfc8200>.
[RFC8250] Elkins, N., Hamilton, R., and M. Ackermann, "IPv6
Performance and Diagnostic Metrics (PDM) Destination
Option", RFC 8250, DOI 10.17487/RFC8250, September 2017,
<https://www.rfc-editor.org/info/rfc8250>.
[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>.
skipping to change at page 36, line 13 skipping to change at page 38, line 28
00.txt, November 1995. 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 30, 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, G. and J. Damas, "IPv6 Fragmentation and EH
Behaviours", IEPG Meeting - March 2022 @ IETF 113, March
2022,
<https://iepg.org/2022-03-20-ietf113/huston-v6frag.pdf>.
[I-D.irtf-pearg-numeric-ids-generation] [I-D.irtf-pearg-numeric-ids-generation]
Gont, F. and I. Arce, "On the Generation of Transient Gont, F. and I. Arce, "On the Generation of Transient
Numeric Identifiers", Work in Progress, Internet-Draft, Numeric Identifiers", Work in Progress, Internet-Draft,
draft-irtf-pearg-numeric-ids-generation-08, 31 January draft-irtf-pearg-numeric-ids-generation-08, 31 January
2022, <https://www.ietf.org/archive/id/draft-irtf-pearg- 2022, <https://www.ietf.org/archive/id/draft-irtf-pearg-
numeric-ids-generation-08.txt>. 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 Internet Assigned Numbers Authority, "Internet Protocol
Version 6 (IPv6) Parameters", December 2013, Version 6 (IPv6) Parameters", December 2013,
<https://www.iana.org/assignments/ipv6-parameters/ <https://www.iana.org/assignments/ipv6-parameters/
ipv6-parameters.xhtml>. ipv6-parameters.xhtml>.
[IANA-PROTOCOLS] [IANA-PROTOCOLS]
Internet Assigned Numbers Authority, "Protocol Numbers", Internet Assigned Numbers Authority, "Protocol Numbers",
2014, <https://www.iana.org/assignments/protocol-numbers/ 2014, <https://www.iana.org/assignments/protocol-numbers/
protocol-numbers.xhtml>. protocol-numbers.xhtml>.
skipping to change at page 37, line 21 skipping to change at page 40, line 4
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>.
Authors' Addresses Authors' Addresses
Fernando Gont Fernando Gont
SI6 Networks EdgeUno
Segurola y Habana 4310, 7mo Piso Segurola y Habana 4310, 7mo Piso
Villa Devoto Villa Devoto
Ciudad Autonoma de Buenos Aires Ciudad Autonoma de Buenos Aires
Argentina Argentina
Email: fgont@si6networks.com Email: fernando.gont@edgeuno.com
URI: https://www.si6networks.com URI: https://www.edgeuno.com
Will (Shucheng) Liu Will (Shucheng) Liu
Huawei Technologies Huawei Technologies
Bantian, Longgang District Bantian, Longgang District
Shenzhen Shenzhen
518129 518129
P.R. China P.R. China
Email: liushucheng@huawei.com Email: liushucheng@huawei.com
 End of changes. 223 change blocks. 
390 lines changed or deleted 546 lines changed or added

This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/