rfc9288v2.txt   rfc9288.txt 
skipping to change at line 18 skipping to change at line 18
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
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, i.e., for those transit routers for traffic not directed to them, for those cases
cases where such filtering is deemed as necessary. where such filtering is deemed as necessary.
Status of This Memo Status of This Memo
This document is not an Internet Standards Track specification; it is This document is not an Internet Standards Track specification; it is
published for informational purposes. published for informational purposes.
This document is a product of the Internet Engineering Task Force This document is a product of the Internet Engineering Task Force
(IETF). It represents the consensus of the IETF community. It has (IETF). It represents the consensus of the IETF community. It has
received public review and has been approved for publication by the received public review and has been approved for publication by the
Internet Engineering Steering Group (IESG). Not all documents Internet Engineering Steering Group (IESG). Not all documents
skipping to change at line 74 skipping to change at line 74
3.4. Summary of Advice on the Handling of IPv6 Packets with 3.4. Summary of Advice on the Handling of IPv6 Packets with
Specific IPv6 Extension Headers Specific IPv6 Extension Headers
3.5. Advice on the Handling of IPv6 Packets with Specific IPv6 3.5. Advice on the Handling of IPv6 Packets with Specific IPv6
Extension Headers Extension Headers
3.6. Advice on the Handling of Packets with Unknown IPv6 3.6. Advice on the Handling of Packets with Unknown IPv6
Extension Headers Extension Headers
4. IPv6 Options 4. IPv6 Options
4.1. General Discussion 4.1. General Discussion
4.2. General Security Implications of IPv6 Options 4.2. General Security Implications of IPv6 Options
4.3. Summary of Advice on the Handling of IPv6 Packets with 4.3. Summary of Advice on the Handling of IPv6 Packets with
Specific IPv6 Extension Headers Specific IPv6 Options
4.4. Advice on the Handling of Packets with Specific IPv6 4.4. Advice on the Handling of Packets with Specific IPv6
Options Options
4.5. Advice on the Handling of Packets with Unknown IPv6 Options 4.5. Advice on the Handling of Packets with Unknown IPv6 Options
5. IANA Considerations 5. IANA Considerations
6. Privacy Considerations 6. Privacy Considerations
7. Security Considerations 7. Security Considerations
8. References 8. References
8.1. Normative References 8.1. Normative References
8.2. Informative References 8.2. Informative References
Acknowledgements Acknowledgements
skipping to change at line 122 skipping to change at line 122
interoperability implications of such filtering policies. interoperability implications of such filtering policies.
The resulting packet filtering policy typically depends on where in The resulting packet filtering policy typically depends on where in
the network such policy is enforced. When the policy is enforced in the network such policy is enforced. When the policy is enforced in
a transit network, the policy typically follows a "deny-list" a transit network, the policy typically follows a "deny-list"
approach, where only packets with clear negative implications are approach, where only packets with clear negative implications are
dropped. On the other hand, when the policy is enforced closer to dropped. On the other hand, when the policy is enforced closer to
the destination systems, the policy typically follows an "accept- the destination systems, the policy typically follows an "accept-
list" approach, where only traffic that is expected to be received is list" approach, where only traffic that is expected to be received is
allowed. The advice in this document is aimed only at transit allowed. The advice in this document is aimed only at transit
routers that may need to enforce a filtering policy based on the EHs routers that may need to enforce a filtering policy based on the IPv6
and IPv6 options a packet may contain, following a "deny-list" EHs and IPv6 options a packet may contain, following a "deny-list"
approach; hence, it is likely to be much more permissive than a approach; hence, it is likely to be much more permissive than a
filtering policy to be employed at, for example, the edge of an filtering policy to be employed at, for example, the edge of an
enterprise network. The advice in this document is meant to improve enterprise network. The advice in this document is meant to improve
the current situation of the dropping of packets with IPv6 EHs in the the current situation of the dropping of packets with IPv6 EHs in the
Internet [RFC7872] in such cases where packets are being dropped due Internet [RFC7872] in such cases where packets are being dropped due
to inappropriate or missing guidelines. to inappropriate or missing guidelines.
This document is similar in nature to [RFC7126], which addresses the This document is similar in nature to [RFC7126], which addresses the
same problem for the IPv4 case. However, in IPv6, the problem space same problem for the IPv4 case. However, in IPv6, the problem space
is compounded by the fact that IPv6 specifies a number of IPv6 EHs is compounded by the fact that IPv6 specifies a number of IPv6 EHs
and a number of IPv6 options, which may be valid only when included and a number of IPv6 options that may be valid only when included in
in specific EH types. specific EH types.
This document completes and complements the considerations for This document completes and complements the considerations for
protecting the control plane from packets containing IP options that protecting the control plane from packets containing IP options that
can be found in [RFC6192]. can be found in [RFC6192].
Section 2 specifies the terminology and conventions employed Section 2 specifies the terminology and conventions employed
throughout this document. Section 3 discusses IPv6 EHs and provides throughout this document. Section 3 discusses IPv6 EHs and provides
advice in the area of filtering IPv6 packets that contain such IPv6 advice in the area of filtering IPv6 packets that contain such IPv6
EHs. Section 4 discusses IPv6 options and provides advice in the EHs. Section 4 discusses IPv6 options and provides advice in the
area of filtering IPv6 packets that contain such options. area of filtering IPv6 packets that contain such options.
2. Terminology and Assumptions Employed in This Document 2. Terminology and Assumptions Employed in This Document
2.1. Terminology 2.1. Terminology
The terms "permit" (allow the traffic), "drop" (drop with no The terms "permit" (allow the traffic), "drop" (drop with no
notification to sender), and "reject" (drop with appropriate notification to sender), and "reject" (drop with appropriate
notification to sender) are employed as defined in [RFC3871]. notification to sender) are employed as defined in [RFC3871].
Throughout this document, we also employ the term "discard" as a Throughout this document, we also employ the term "discard" as a
generic term to indicate the act of discarding a packet, irrespective generic term to indicate the act of discarding a packet, irrespective
of whether the sender is notified of such drops and whether the of whether the sender is notified of such a drop and whether the
specific filtering action is logged. specific filtering action is logged.
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described in "OPTIONAL" in this document are to be interpreted as described in
BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all
capitals, as shown here. capitals, as shown here.
2.2. Applicability Statement 2.2. Applicability Statement
This document provides advice on the filtering of IPv6 packets with This document provides advice on the filtering of IPv6 packets with
EHs at transit routers for traffic not explicitly destined to them, EHs at transit routers for traffic not explicitly destined to them,
i.e., for cases in which such filtering is deemed as necessary. for cases in which such filtering is deemed as necessary.
2.3. Router Default Behavior and Features 2.3. Router Default Behavior and Features
This document assumes that nodes comply with the requirements in This document assumes that nodes comply with the requirements in
[RFC7045]. Namely, [RFC7045]. Namely,
| If a forwarding node discards a packet containing a standard IPv6 | If a forwarding node discards a packet containing a standard IPv6
| extension header, it MUST be the result of a configurable policy | extension header, it MUST be the result of a configurable policy
| and not just the result of a failure to recognise such a header. | and not just the result of a failure to recognise such a header.
| This means that the discard policy for each standard type of | This means that the discard policy for each standard type of
skipping to change at line 191 skipping to change at line 191
| configuration SHOULD allow all standard extension headers. | configuration SHOULD allow all standard extension headers.
The advice provided in this document is only meant to guide an The advice provided in this document is only meant to guide an
operator in configuring forwarding devices and is not to be operator in configuring forwarding devices and is not to be
interpreted as advice regarding default configuration settings for interpreted as advice regarding default configuration settings for
network devices. That is, this document provides advice with respect network devices. That is, this document provides advice with respect
to operational policies but does not change the implementation to operational policies but does not change the implementation
defaults required by [RFC7045]. defaults required by [RFC7045].
We recommend that configuration options be made available to govern We recommend that configuration options be made available to govern
the processing of each IPv6 EH type and each IPv6 option type. Such the processing of each IPv6 EH type and each IPv6 Option Type. Such
configuration options should include the following possible settings: configuration options should include the following possible settings:
* Permit this IPv6 EH or IPv6 Option Type. * Permit this IPv6 EH or IPv6 Option Type.
* Drop packets containing this IPv6 EH or IPv6 Option Type. * Drop packets containing this IPv6 EH or IPv6 Option Type.
* Reject packets containing this IPv6 EH or IPv6 Option Type (where * Reject packets containing this IPv6 EH or IPv6 Option Type (where
the packet drop is signaled with an ICMPv6 error message). the packet drop is signaled with an ICMPv6 error message).
* Rate-limit traffic containing this IPv6 EH or IPv6 Option Type. * Rate-limit traffic containing this IPv6 EH or IPv6 Option Type.
skipping to change at line 237 skipping to change at line 237
namespace ("Next Header" registry/namespace), [RFC7045] identifies namespace ("Next Header" registry/namespace), [RFC7045] identifies
which of the currently assigned Internet Protocol numbers identify which of the currently assigned Internet Protocol numbers identify
IPv6 EHs vs. upper-layer protocols. This document discusses the IPv6 EHs vs. upper-layer protocols. This document discusses the
filtering of packets based on the IPv6 EHs (as specified by filtering of packets based on the IPv6 EHs (as specified by
[RFC7045]) they contain. [RFC7045]) they contain.
[RFC8200] specifies that non-fragmented IPv6 datagrams and IPv6 [RFC8200] specifies that non-fragmented IPv6 datagrams and IPv6
First-Fragments must contain the entire IPv6 header chain [RFC7112]. First-Fragments must contain the entire IPv6 header chain [RFC7112].
Therefore, intermediate systems can enforce the filtering policies Therefore, intermediate systems can enforce the filtering policies
discussed in this document or resort to simply discarding the discussed in this document or resort to simply discarding the
offending packets when they fail include the entire IPv6 header chain offending packets when they fail to include the entire IPv6 header
[RFC8200]. chain [RFC8200].
We note that in order to implement filtering rules on the fast path, We note that in order to implement filtering rules on the fast path,
it may be necessary for the filtering device to limit the depth into it may be necessary for the filtering device to limit the depth into
the packet that can be inspected before giving up. In circumstances the packet that can be inspected before giving up. In circumstances
where such a limitation exists, it is recommended that where such a limitation exists, it is recommended that
implementations provide a configuration option that specifies whether implementations provide a configuration option that specifies whether
to discard packets if the aforementioned limit is encountered. to discard packets if the aforementioned limit is encountered.
Operators may then determine, according to their own circumstances, Operators may then determine, according to their own circumstances,
how such packets will be handled. how such packets will be handled.
skipping to change at line 288 skipping to change at line 288
should be permitted. This is an intentional trade-off made to should be permitted. This is an intentional trade-off made to
minimize ossification. minimize ossification.
3.4. Summary of Advice on the Handling of IPv6 Packets with Specific 3.4. Summary of Advice on the Handling of IPv6 Packets with Specific
IPv6 Extension Headers IPv6 Extension Headers
This section summarizes the advice provided in Section 3.5, providing This section summarizes the advice provided in Section 3.5, providing
references to the specific sections in which a detailed analysis can references to the specific sections in which a detailed analysis can
be found. be found.
+=========================+============================+===========+ +=====================+=========================+===========+
| EH Type | Filtering Policy | Reference | | EH Type | Filtering Policy | Reference |
+=========================+============================+===========+ +=====================+=========================+===========+
| IPv6 Hop-by-Hop Options | Drop or Ignore | Section | | Hop-by-Hop Options | Drop or Ignore | Section |
| (Proto=0) | | 3.5.1 | | Header (Proto=0) | | 3.5.1 |
+-------------------------+----------------------------+-----------+ +---------------------+-------------------------+-----------+
| Routing Header for IPv6 | Drop only Routing Type 0 | Section | | Routing Header | Drop only Routing Type | Section |
| (Proto=43) | and Routing Type 1. | 3.5.2 | | (Proto=43) | 0, Routing Type 1, and | 3.5.2 |
| | Permit other Routing Types | | | | Routing Type 3. Permit | |
+-------------------------+----------------------------+-----------+ | | other Routing Types | |
| Fragment Header for | Permit | Section | +---------------------+-------------------------+-----------+
| IPv6 (Proto=44) | | 3.5.3 | | Fragment Header | Permit | Section |
+-------------------------+----------------------------+-----------+ | (Proto=44) | | 3.5.3 |
| Encapsulating Security | Permit | Section | +---------------------+-------------------------+-----------+
| Payload (Proto=50) | | 3.5.4 | | Encapsulating | Permit | Section |
+-------------------------+----------------------------+-----------+ | Security Payload | | 3.5.4 |
| Authentication Header | Permit | Section | | (Proto=50) | | |
| (Proto=51) | | 3.5.5 | +---------------------+-------------------------+-----------+
+-------------------------+----------------------------+-----------+ | Authentication | Permit | Section |
| Destination Options for | Permit | Section | | Header (Proto=51) | | 3.5.5 |
| IPv6 (Proto=60) | | 3.5.6 | +---------------------+-------------------------+-----------+
+-------------------------+----------------------------+-----------+ | Destination Options | Permit | Section |
| Mobility Header | Permit | Section | | Header(Proto=60) | | 3.5.6 |
| (Proto=135) | | 3.5.7 | +---------------------+-------------------------+-----------+
+-------------------------+----------------------------+-----------+ | Mobility Header | Permit | Section |
| Host Identity Protocol | Permit | Section | | (Proto=135) | | 3.5.7 |
| (Proto=139) | | 3.5.8 | +---------------------+-------------------------+-----------+
+-------------------------+----------------------------+-----------+ | Host Identity | Permit | Section |
| Shim6 Protocol | Permit | Section | | Protocol | | 3.5.8 |
| (Proto=140) | | 3.5.9 | | (Proto=139) | | |
+-------------------------+----------------------------+-----------+ +---------------------+-------------------------+-----------+
| Use for experimentation | Drop | Section | | Shim6 Protocol | Permit | Section |
| and testing (Proto=253 | | 3.5.10 | | (Proto=140) | | 3.5.9 |
| and 254) | | | +---------------------+-------------------------+-----------+
+-------------------------+----------------------------+-----------+ | Use for | Drop | Section |
| experimentation and | | 3.5.10 |
| testing (Proto=253 | | |
| and 254) | | |
+---------------------+-------------------------+-----------+
Table 1: Summary of Advice on the Handling of IPv6 Packets with Table 1: Summary of Advice on the Handling of IPv6
Specific IPv6 Extension Headers Packets with Specific IPv6 Extension Headers
3.5. Advice on the Handling of IPv6 Packets with Specific IPv6 3.5. Advice on the Handling of IPv6 Packets with Specific IPv6
Extension Headers Extension Headers
3.5.1. IPv6 Hop-by-Hop Options (Protocol Number=0) 3.5.1. IPv6 Hop-by-Hop Options (Protocol Number=0)
3.5.1.1. Uses 3.5.1.1. Uses
The Hop-by-Hop (HBH) Options header is used to carry optional The Hop-by-Hop (HBH) Options header is used to carry optional
information that may be examined by every node along a packet's information that may be examined by every node along a packet's
delivery path. It is expected that nodes will examine the Hop-by-Hop delivery path. It is expected that nodes will examine the Hop-by-Hop
Options header if explicitly configured to do so. Options header if explicitly configured to do so.
| NOTE: A previous revision of the IPv6 core specification | NOTE: A previous revision of the IPv6 core specification
| [RFC2460] originally required that all nodes be examined and | [RFC2460] originally required all nodes to examine and process
| processed the Hop-by-Hop Options header. However, even before | the Hop-by-Hop Options header. However, even before the
| the publication of [RFC8200], a number of implementations | publication of [RFC8200], a number of implementations already
| already provided the option of ignoring this header unless | provided the option of ignoring this header unless explicitly
| explicitly configured to examine it. | configured to examine it.
3.5.1.2. Specification 3.5.1.2. Specification
This EH is specified in [RFC8200]. As of May 2022, the following This EH is specified in [RFC8200]. As of May 2022, the following
options have been specified for the Hop-by-Hop Options header: options have been specified for the Hop-by-Hop Options header:
* Type 0x00: Pad1 [RFC8200] * Type 0x00: Pad1 [RFC8200]
* Type 0x01: PadN [RFC8200] * Type 0x01: PadN [RFC8200]
skipping to change at line 398 skipping to change at line 402
* Type 0xDE: RFC3692-style Experiment [RFC4727] * Type 0xDE: RFC3692-style Experiment [RFC4727]
* Type 0xFE: RFC3692-style Experiment [RFC4727] * Type 0xFE: RFC3692-style Experiment [RFC4727]
3.5.1.3. Specific Security Implications 3.5.1.3. Specific Security Implications
Legacy nodes that process this extension header might be subject to Legacy nodes that process this extension header might be subject to
DoS attacks. DoS attacks.
| NOTE: While [RFC8200] has removed this requirement, the | NOTE: While [RFC8200] has removed the requirement for all nodes
| deployed base may still reflect the classical behavior for a | to examine and process the Hop-by-Hop Options header, the
| while; hence, the potential security problems of this EH are | deployed base may still reflect the legacy [RFC2460] behavior
| still of concern. | for a while; hence, the potential security problems of this EH
| are still of concern.
3.5.1.4. Operational and Interoperability Impact If Blocked 3.5.1.4. Operational and Interoperability Impact If Blocked
Discarding packets containing a Hop-by-Hop Options header would break Discarding packets containing a Hop-by-Hop Options header would break
any of the protocols that rely on it for proper functioning. For any of the protocols that rely on it for proper functioning. For
example, it would break RSVP [RFC2205] and multicast deployments and example, it would break RSVP [RFC2205] and multicast deployments and
would cause IPv6 jumbograms to be discarded. would cause IPv6 jumbograms to be discarded.
3.5.1.5. Advice 3.5.1.5. Advice
Nodes implementing [RFC8200] would already ignore this extension Nodes implementing [RFC8200] would already ignore this extension
header unless explicitly required to process it. For legacy nodes header unless explicitly required to process it. For legacy nodes
[RFC2460], the recommended configuration for the processing of these [RFC2460], the recommended configuration for the processing of these
packets depends on the features and capabilities of the underlying packets depends on the features and capabilities of the underlying
platform, the configuration of the platform, and also the deployment platform, the configuration of the platform, and also the deployment
environment of the platform. On platforms that allow the forwarding environment of the platform. On platforms that allow the forwarding
of packets with HBH Options on the fast path, we recommend that of packets with IPv6 HBH Options headers on the fast path, we
packets with a HBH Options EH be forwarded as normal. Otherwise, on recommend that packets with IPv6 HBH Options headers be forwarded as
platforms in which the processing of packets with an IPv6 HBH Options normal. Otherwise, on platforms in which the processing of packets
EH is carried out in the slow path and an option is provided to rate- with IPv6 HBH Options headers is carried out in the slow path and an
limit these packets, we recommend that this option be selected. option is provided to rate-limit these packets, we recommend that
Finally, when packets containing a HBH Options EH are processed in this option be selected. Finally, when packets containing IPv6 HBH
the slow path and the underlying platform does not have any Options headers are processed in the slow path and the underlying
mitigation options available for attacks based on these packets, we platform does not have any mitigation options available for attacks
recommend that such platforms discard packets containing IPv6 HBH based on these packets, we recommend that such platforms discard
Options EHs. packets containing IPv6 HBH Options headers.
Finally, we note that the Routing Protocol for Low-Power and Lossy Finally, we note that the Routing Protocol for Low-Power and Lossy
Networks (RPL) routers [RFC6550] must not discard packets based on Networks (RPL) routers [RFC6550] must not discard packets based on
the presence of an IPv6 Hop-by-Hop Options header, as this would the presence of an IPv6 Hop-by-Hop Options header, as this would
break the RPL. break the RPL.
3.5.2. Routing Header for IPv6 (Protocol Number=43) 3.5.2. Routing Header (Protocol Number=43)
3.5.2.1. Uses 3.5.2.1. Uses
The Routing Header is used by an IPv6 source to list one or more The Routing Header is used by an IPv6 source to list one or more
intermediate nodes to be "visited" on the way to a packet's intermediate nodes to be "visited" on the way to a packet's
destination. destination.
3.5.2.2. Specification 3.5.2.2. Specification
This EH is specified in [RFC8200]. The Routing Type 0 had originally This EH is specified in [RFC8200]. The Routing Type 0 had originally
skipping to change at line 495 skipping to change at line 500
packets containing Routing Headers of Routing Type 4 (SRH) will break packets containing Routing Headers of Routing Type 4 (SRH) will break
Segment Routing (SR) deployments if the filtering policy is enforced Segment Routing (SR) deployments if the filtering policy is enforced
on packets being forwarded within an SR domain. on packets being forwarded within an SR domain.
3.5.2.5. Advice 3.5.2.5. Advice
Intermediate systems should discard packets containing Routing Intermediate systems should discard packets containing Routing
Headers of Routing Type 0, Routing Type 1, or Routing Type 3. Other Headers of Routing Type 0, Routing Type 1, or Routing Type 3. Other
Routing Types should be permitted, as required by [RFC7045]. Routing Types should be permitted, as required by [RFC7045].
3.5.3. Fragment Header for IPv6 (Protocol Number=44) 3.5.3. Fragment Header (Protocol Number=44)
3.5.3.1. Uses 3.5.3.1. Uses
This EH provides the fragmentation functionality for IPv6. This EH provides the fragmentation and reassembly functionality for
IPv6.
3.5.3.2. Specification 3.5.3.2. Specification
This EH is specified in [RFC8200]. This EH is specified in [RFC8200].
3.5.3.3. Specific Security Implications 3.5.3.3. Specific Security Implications
The security implications of the Fragment Header range from DoS The security implications of the Fragment Header range from DoS
attacks (e.g., based on flooding a target with IPv6 fragments) to attacks (e.g., based on flooding a target with IPv6 fragments) to
information leakage attacks [RFC7739]. information leakage attacks [RFC7739].
skipping to change at line 576 skipping to change at line 582
3.5.5.4. Operational and Interoperability Impact If Blocked 3.5.5.4. Operational and Interoperability Impact If Blocked
Discarding packets that employ this EH would break IPsec deployments. Discarding packets that employ this EH would break IPsec deployments.
3.5.5.5. Advice 3.5.5.5. Advice
Intermediate systems should permit packets containing an Intermediate systems should permit packets containing an
Authentication Header. Authentication Header.
3.5.6. Destination Options for IPv6 (Protocol Number=60) 3.5.6. Destination Options (Protocol Number=60)
3.5.6.1. Uses 3.5.6.1. Uses
The Destination Options (DO) header is used to carry optional The Destination Options (DO) header is used to carry optional
information that needs be examined only by a packet's destination information that needs be examined only by a packet's destination
node(s). node(s).
3.5.6.2. Specification 3.5.6.2. Specification
This EH is specified in [RFC8200]. As of May 2022, the following This EH is specified in [RFC8200]. As of May 2022, the following
skipping to change at line 625 skipping to change at line 631
* Type 0x9E: RFC3692-style Experiment [RFC4727] * Type 0x9E: RFC3692-style Experiment [RFC4727]
* Type 0xBE: RFC3692-style Experiment [RFC4727] * Type 0xBE: RFC3692-style Experiment [RFC4727]
* Type 0xDE: RFC3692-style Experiment [RFC4727] * Type 0xDE: RFC3692-style Experiment [RFC4727]
* Type 0xFE: RFC3692-style Experiment [RFC4727] * Type 0xFE: RFC3692-style Experiment [RFC4727]
3.5.6.3. Specific Security Implications 3.5.6.3. Specific Security Implications
No security implications are known, other than the general No security implications are known, other than the general security
implications of IPv6 EHs. For a discussion of possible security implications of IPv6 EHs. For a discussion of possible security
implications of specific options specified for the DO header, please implications of specific options specified for the DO header, please
see the Section 4.4. see Section 4.4.
3.5.6.4. Operational and Interoperability Impact If Blocked 3.5.6.4. Operational and Interoperability Impact If Blocked
Discarding packets that contain a Destination Options header would Discarding packets that contain a Destination Options header would
break protocols that rely on this EH type for conveying information break protocols that rely on this EH type for conveying information
(such as the Identifier-Locator Network Protocol (ILNP) [RFC6740] and (such as the Identifier-Locator Network Protocol (ILNP) [RFC6740] and
Mobile IPv6 [RFC6275]), as well as IPv6 tunnels that employ the Mobile IPv6 [RFC6275]), as well as IPv6 tunnels that employ the
Tunnel Encapsulation Limit option. Tunnel Encapsulation Limit option [RFC2473].
3.5.6.5. Advice 3.5.6.5. Advice
Intermediate systems should permit packets that contain a Destination Intermediate systems should permit packets that contain a Destination
Options header. Options header.
3.5.7. Mobility Header (Protocol Number=135) 3.5.7. Mobility Header (Protocol Number=135)
3.5.7.1. Uses 3.5.7.1. Uses
skipping to change at line 667 skipping to change at line 673
A thorough security assessment of the security implications of the A thorough security assessment of the security implications of the
Mobility Header and related mechanisms can be found in Section 15 of Mobility Header and related mechanisms can be found in Section 15 of
[RFC6275]. [RFC6275].
3.5.7.4. Operational and Interoperability Impact If Blocked 3.5.7.4. Operational and Interoperability Impact If Blocked
Discarding packets containing this EH would break Mobile IPv6. Discarding packets containing this EH would break Mobile IPv6.
3.5.7.5. Advice 3.5.7.5. Advice
Intermediate systems should permit packets containing this EH. Intermediate systems should permit packets that contain a Mobility
Header.
3.5.8. Host Identity Protocol (Protocol Number=139) 3.5.8. Host Identity Protocol (Protocol Number=139)
3.5.8.1. Uses 3.5.8.1. Uses
This EH is employed with the Host Identity Protocol (HIP), which is a This EH is employed with the Host Identity Protocol (HIP), which is a
protocol that allows consenting hosts to securely establish and protocol that allows consenting hosts to securely establish and
maintain shared IP-layer state, allowing the separation of the maintain shared IP-layer state, allowing the separation of the
identifier and locator roles of IP addresses, thereby enabling identifier and locator roles of IP addresses, thereby enabling
continuity of communications across IP address changes. continuity of communications across IP address changes.
3.5.8.2. Specification 3.5.8.2. Specification
This EH is specified in [RFC7401]. This EH is specified in [RFC7401].
3.5.8.3. Specific Security Implications 3.5.8.3. Specific Security Implications
The security implications of the HIP header are discussed in detail The security implications of the HIP header are discussed in detail
in Section 8 of [RFC6275]. in Section 8 of [RFC7401].
3.5.8.4. Operational and Interoperability Impact If Blocked 3.5.8.4. Operational and Interoperability Impact If Blocked
Discarding packets that contain the Host Identity Protocol would Discarding packets that contain a HIP header would break HIP
break HIP deployments. deployments.
3.5.8.5. Advice 3.5.8.5. Advice
Intermediate systems should permit packets that contain a Host Intermediate systems should permit packets that contain a HIP header.
Identity Protocol EH.
3.5.9. Shim6 Protocol (Protocol Number=140) 3.5.9. Shim6 Protocol (Protocol Number=140)
3.5.9.1. Uses 3.5.9.1. Uses
This EH is employed by the Shim6 protocol [RFC5533]. This EH is employed by the Shim6 protocol [RFC5533].
3.5.9.2. Specification 3.5.9.2. Specification
This EH is specified in [RFC5533]. This EH is specified in [RFC5533].
skipping to change at line 810 skipping to change at line 816
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 Distributed router's general-purpose CPU and, hence, could present a Distributed
Denial-of-Service (DDoS) risk to that router's general-purpose CPU Denial-of-Service (DDoS) risk to that router's general-purpose CPU
(and thus to the router itself). For some architectures, a possible (and thus to the router itself). For some architectures, a possible
mitigation would be to rate-limit the packets that are to be mitigation would be to rate-limit the packets that are to be
processed by the general-purpose CPU (see, e.g., [Cisco-EH]). processed by the general-purpose CPU (see, e.g., [Cisco-EH]).
4.3. Summary of Advice on the Handling of IPv6 Packets with Specific 4.3. Summary of Advice on the Handling of IPv6 Packets with Specific
IPv6 Extension Headers IPv6 Options
This section summarizes the advice provided in Section 3.5, and it This section summarizes the advice provided in Section 4.4, and it
includes references to the specific sections in which a detailed includes references to the specific sections in which a detailed
analysis can be found. analysis can be found.
+===============================+======================+===========+ +===============================+======================+===========+
| Option | Filtering Policy | Reference | | Option | Filtering Policy | Reference |
+===============================+======================+===========+ +===============================+======================+===========+
| Pad1 (Type=0x00) | Permit | Section | | Pad1 (Type=0x00) | Permit | Section |
| | | 4.4.1 | | | | 4.4.1 |
+-------------------------------+----------------------+-----------+ +-------------------------------+----------------------+-----------+
| PadN (Type=0x01) | Permit | Section | | PadN (Type=0x01) | Permit | Section |
skipping to change at line 855 skipping to change at line 861
+-------------------------------+----------------------+-----------+ +-------------------------------+----------------------+-----------+
| Deprecated (Type=0x4D) | Drop | Section | | Deprecated (Type=0x4D) | Drop | Section |
| | | 4.4.10 | | | | 4.4.10 |
+-------------------------------+----------------------+-----------+ +-------------------------------+----------------------+-----------+
| MPL Option (Type=0x6D) | Permit | Section | | MPL Option (Type=0x6D) | Permit | Section |
| | | 4.4.12 | | | | 4.4.12 |
+-------------------------------+----------------------+-----------+ +-------------------------------+----------------------+-----------+
| Jumbo Payload (Type=0xC2) | Permit based on | Section | | Jumbo Payload (Type=0xC2) | Permit based on | Section |
| | needed functionality | 4.4.16 | | | needed functionality | 4.4.16 |
+-------------------------------+----------------------+-----------+ +-------------------------------+----------------------+-----------+
| RPL Option (Type=0x63) | Drop in non-RPL | Section | | RPL Option (Type=0x63) | Drop | Section |
| | routers | 4.4.11 | | | | 4.4.11 |
+-------------------------------+----------------------+-----------+ +-------------------------------+----------------------+-----------+
| Endpoint Identification | Drop | Section | | Endpoint Identification | Drop | Section |
| (Type=0x8A) | | 4.4.13 | | (Type=0x8A) | | 4.4.13 |
+-------------------------------+----------------------+-----------+ +-------------------------------+----------------------+-----------+
| ILNP Nonce (Type=0x8B) | Permit | Section | | ILNP Nonce (Type=0x8B) | Permit | Section |
| | | 4.4.14 | | | | 4.4.14 |
+-------------------------------+----------------------+-----------+ +-------------------------------+----------------------+-----------+
| Line-Identification Option | Drop | Section | | Line-Identification Option | Drop | Section |
| (Type=0x8C) | | 4.4.15 | | (Type=0x8C) | | 4.4.15 |
+-------------------------------+----------------------+-----------+ +-------------------------------+----------------------+-----------+
skipping to change at line 998 skipping to change at line 1004
4.4.4.4. Operational and Interoperability Impact If Blocked 4.4.4.4. Operational and Interoperability Impact If Blocked
Discarding packets that contain this option would break any protocols Discarding packets that contain this option would break any protocols
that rely on them, such as RSVP and multicast deployments. Please that rely on them, such as RSVP and multicast deployments. Please
see Section 4.4.4.3 for further details. see Section 4.4.4.3 for further details.
4.4.4.5. Advice 4.4.4.5. Advice
Packets containing this option should be permitted in environments Packets containing this option should be permitted in environments
where support for RSVP, multicast routing, or similar protocols is where support for RSVP, multicast routing, or similar protocols is
desired. required.
4.4.5. CALIPSO (Type=0x07) 4.4.5. CALIPSO (Type=0x07)
4.4.5.1. Uses 4.4.5.1. Uses
This option is used for encoding explicit packet Sensitivity Labels This option is used for encoding explicit packet Sensitivity Labels
on IPv6 packets. It is intended for use only within Multi-Level on IPv6 packets. It is intended for use only within Multi-Level
Secure (MLS) networking environments that are both trusted and Secure (MLS) networking environments that are both trusted and
trustworthy. trustworthy.
skipping to change at line 1064 skipping to change at line 1070
this option set to (b) above. The default setting for this this option set to (b) above. The default setting for this
configuration option should be set to (a) above, because MLS configuration option should be set to (a) above, because MLS
environments are much less common than non-MLS environments. environments are much less common than non-MLS environments.
For intermediate systems that DO implement [RFC5570], there should be For intermediate systems that DO implement [RFC5570], there should be
configuration options (a) and (b) from the preceding paragraph and configuration options (a) and (b) from the preceding paragraph and
also a third configuration option (c) to process packets containing a also a third configuration option (c) to process packets containing a
CALIPSO as per [RFC5570]. When deployed in non-MLS environments, CALIPSO as per [RFC5570]. When deployed in non-MLS environments,
such intermediate systems should have this configuration option set such intermediate systems should have this configuration option set
to (a) above. When deployed in MLS environments, such intermediate to (a) above. When deployed in MLS environments, such intermediate
systems should have this set to (c). The default setting for this systems should have this configuration option set to (c). The
configuration option MAY be set to (a) above, because MLS default setting for this configuration option MAY be set to (a)
environments are much less common than non-MLS environments. above, because MLS environments are much less common than non-MLS
environments.
4.4.6. SMF_DPD (Type=0x08) 4.4.6. SMF_DPD (Type=0x08)
4.4.6.1. Uses 4.4.6.1. Uses
This option is employed in the (experimental) Simplified Multicast This option is employed in the (experimental) Simplified Multicast
Forwarding (SMF) for unique packet identification for IPv6 Forwarding (SMF) for unique packet identification for IPv6
Identification-based DPD (I-DPD) and as a mechanism to guarantee non- Identification-based DPD (I-DPD) and as a mechanism to guarantee non-
collision of hash values for different packets when Hash-based DPD collision of hash values for different packets when Hash-based DPD
(H-DPD) is used. (H-DPD) is used.
skipping to change at line 1130 skipping to change at line 1137
4.4.7.5. Advice 4.4.7.5. Advice
Intermediate systems should not discard packets based on the presence Intermediate systems should not discard packets based on the presence
of this option. of this option.
4.4.8. RPL Option (Type=0x23) 4.4.8. RPL Option (Type=0x23)
4.4.8.1. Uses 4.4.8.1. Uses
The RPL Option provides a mechanism to include routing information The RPL Option provides a mechanism to include routing information in
with each datagram that a RPL router forwards. each datagram that a RPL router forwards.
4.4.8.2. Specification 4.4.8.2. Specification
This option is specified in [RFC9008]. This option is specified in [RFC9008].
4.4.8.3. Specific Security Implications 4.4.8.3. Specific Security Implications
These are discussed in [RFC9008]. These are discussed in [RFC9008].
4.4.8.4. Operational and Interoperability Impact If Blocked 4.4.8.4. Operational and Interoperability Impact If Blocked
skipping to change at line 1183 skipping to change at line 1190
* attacks with bogus Quick-Start Requests to temporarily tie up * attacks with bogus Quick-Start Requests to temporarily tie up
available Quick-Start bandwidth, preventing routers from approving available Quick-Start bandwidth, preventing routers from approving
Quick-Start Requests from other connections Quick-Start Requests from other connections
We note that if routers in a given environment do not implement and We note that if routers in a given environment do not implement and
enable the Quick-Start mechanism, only the general security enable the Quick-Start mechanism, only the general security
implications of IP options (discussed in Section 4.2) would apply. implications of IP options (discussed in Section 4.2) would apply.
4.4.9.4. Operational and Interoperability Impact If Blocked 4.4.9.4. Operational and Interoperability Impact If Blocked
If packets with IPv6 options are blocked, the host trying to If packets with IPv6 Quick Start options are blocked, the host trying
establish a TCP connection will fall back to not including options -- to establish a TCP connection will fall back to not including the
this means that the feature will be disabled, and additional delays Quick Start option -- this means that the feature will be disabled,
in connection establishment will be introduced (as discussed in and additional delays in connection establishment will be introduced
Section 4.7.2 of [RFC4782]. We note, however, that Quick-Start has (as discussed in Section 4.7.2 of [RFC4782]). We note, however, that
been proposed as a mechanism that could be of use in controlled Quick-Start has been proposed as a mechanism that could be of use in
environments and not as a mechanism that would be intended or controlled environments and not as a mechanism that would be intended
appropriate for ubiquitous deployment in the global Internet or appropriate for ubiquitous deployment in the global Internet
[RFC4782]. [RFC4782].
4.4.9.5. Advice 4.4.9.5. Advice
Intermediate systems should not discard IPv6 packets based on the Intermediate systems should not discard IPv6 packets based on the
presence of this option. presence of this option.
4.4.10. Deprecated (Type=0x4D) 4.4.10. Deprecated (Type=0x4D)
4.4.10.1. Uses 4.4.10.1. Uses
skipping to change at line 1225 skipping to change at line 1232
Unknown. Unknown.
4.4.10.5. Advice 4.4.10.5. Advice
Intermediate systems should discard packets that contain this option. Intermediate systems should discard packets that contain this option.
4.4.11. RPL Option (Type=0x63) 4.4.11. RPL Option (Type=0x63)
4.4.11.1. Uses 4.4.11.1. Uses
The RPL Option provides a mechanism to include routing information The RPL Option provides a mechanism to include routing information in
with each datagram that a RPL router forwards. each datagram that a RPL router forwards.
4.4.11.2. Specification 4.4.11.2. Specification
This option was originally specified in [RFC6553]. It has been This option was originally specified in [RFC6553]. It has been
deprecated by [RFC9008]. deprecated by [RFC9008].
4.4.11.3. Specific Security Implications 4.4.11.3. Specific Security Implications
These are discussed in [RFC9008]. These are discussed in Section 5 of [RFC6553].
4.4.11.4. Operational and Interoperability Impact If Blocked 4.4.11.4. Operational and Interoperability Impact If Blocked
This option is meant to be employed within a RPL instance. As a This option is meant to be employed within a RPL instance. As a
result, discarding packets based on the presence of this option result, discarding packets based on the presence of this option
outside of a RPL instance will not result in interoperability outside of a RPL instance will not result in interoperability
implications. implications.
4.4.11.5. Advice 4.4.11.5. Advice
Non-RPL routers should discard packets that contain a RPL Option. Intermediate systems should discard packets that contain a RPL
Option.
4.4.12. MPL Option (Type=0x6D) 4.4.12. MPL Option (Type=0x6D)
4.4.12.1. Uses 4.4.12.1. Uses
This option is used with the Multicast Protocol for Low power and This option is used with the Multicast Protocol for Low power and
Lossy Networks (MPL), which provides IPv6 multicast forwarding in Lossy Networks (MPL), which provides IPv6 multicast forwarding in
constrained networks. constrained networks.
4.4.12.2. Specification 4.4.12.2. Specification
skipping to change at line 1355 skipping to change at line 1363
4.4.15.4. Operational and Interoperability Impact If Blocked 4.4.15.4. Operational and Interoperability Impact If Blocked
Since this option is meant to be used when tunneling Neighbor Since this option is meant to be used when tunneling Neighbor
Discovery messages in some broadband network deployment scenarios, Discovery messages in some broadband network deployment scenarios,
discarding packets based on the presence of this option at discarding packets based on the presence of this option at
intermediate systems will result in no interoperability implications. intermediate systems will result in no interoperability implications.
4.4.15.5. Advice 4.4.15.5. Advice
Intermediate devices should discard packets that contain this option. Intermediate systems should discard packets that contain this option.
4.4.16. Jumbo Payload (Type=0XC2) 4.4.16. Jumbo Payload (Type=0XC2)
4.4.16.1. Uses 4.4.16.1. Uses
The Jumbo Payload option provides the means for supporting payloads The Jumbo Payload option provides the means for supporting payloads
larger than 65535 bytes. larger than 65535 bytes.
4.4.16.2. Specification 4.4.16.2. Specification
skipping to change at line 1381 skipping to change at line 1389
improper validity checks of the option and associated packet lengths. improper validity checks of the option and associated packet lengths.
4.4.16.4. Operational and Interoperability Impact If Blocked 4.4.16.4. Operational and Interoperability Impact If Blocked
Discarding packets based on the presence of this option will cause Discarding packets based on the presence of this option will cause
IPv6 jumbograms to be discarded. IPv6 jumbograms to be discarded.
4.4.16.5. Advice 4.4.16.5. Advice
An operator should permit this option only in specific scenarios in An operator should permit this option only in specific scenarios in
which support for IPv6 jumbograms is desired. which support for IPv6 jumbograms is required.
4.4.17. Home Address (Type=0xC9) 4.4.17. Home Address (Type=0xC9)
4.4.17.1. Uses 4.4.17.1. Uses
The Home Address option is used by a Mobile IPv6 node while away from The Home Address option is used by a Mobile IPv6 node while away from
home to inform the recipient of the mobile node's home address. home to inform the recipient of the mobile node's home address.
4.4.17.2. Specification 4.4.17.2. Specification
skipping to change at line 1428 skipping to change at line 1436
This option is specified in [RFC6971]. This option is specified in [RFC6971].
4.4.18.3. Specific Security Implications 4.4.18.3. Specific Security Implications
These are specified in [RFC6971]. These are specified in [RFC6971].
4.4.18.4. Operational and Interoperability Impact If Blocked 4.4.18.4. Operational and Interoperability Impact If Blocked
Dropping packets containing this option within a routing domain that Dropping packets containing this option within a routing domain that
is running DFF would break DFF. However, dropping such packets at is running DFF would break DFF. However, dropping such packets at
the border of such domains will have no security implications. the border of such domains will have no operational or
interoperability implications.
4.4.18.5. Advice 4.4.18.5. Advice
Intermediate systems that do not operate within a routing domain that Intermediate systems that do not operate within a routing domain that
is running DFF should discard packets containing this option. is running DFF should discard packets containing this option.
4.4.19. RFC3692-Style Experiment (Types = 0x1E, 0x3E, 0x5E, 0x7E, 0x9E, 4.4.19. RFC3692-Style Experiment (Types = 0x1E, 0x3E, 0x5E, 0x7E, 0x9E,
0xBE, 0xDE, 0xFE) 0xBE, 0xDE, 0xFE)
4.4.19.1. Uses 4.4.19.1. Uses
skipping to change at line 1468 skipping to change at line 1477
limits the ability to perform legitimate experiments across IPv6 limits the ability to perform legitimate experiments across IPv6
routers. routers.
4.4.19.5. Advice 4.4.19.5. Advice
Operators should determine, according to their own circumstances, Operators should determine, according to their own circumstances,
whether to discard packets containing these IPv6 options. whether to discard packets containing these IPv6 options.
4.5. Advice on the Handling of Packets with Unknown IPv6 Options 4.5. Advice on the Handling of Packets with Unknown IPv6 Options
We refer to IPv6 options that have not been assigned an IPv6 option We refer to IPv6 options that have not been assigned an IPv6 Option
type in the corresponding registry, which is [IANA-IPV6-PARAM], as Type in the corresponding registry, which is [IANA-IPV6-PARAM], as
"unknown IPv6 options". "unknown IPv6 options".
4.5.1. Uses 4.5.1. Uses
New IPv6 options may be specified as part of future protocol work. New IPv6 options may be specified as part of future protocol work.
4.5.2. Specification 4.5.2. Specification
The processing of unknown IPv6 options is specified in [RFC8200]. The processing of unknown IPv6 options is specified in [RFC8200].
 End of changes. 38 change blocks. 
108 lines changed or deleted 117 lines changed or added

This html diff was produced by rfcdiff 1.48.