draft-ietf-opsec-ipv6-eh-filtering-08.txt   draft-ietf-opsec-ipv6-eh-filtering-09.txt 
opsec F. Gont opsec F. Gont
Internet-Draft SI6 Networks Internet-Draft SI6 Networks
Intended status: Informational W. Liu Intended status: Informational W. Liu
Expires: December 5, 2021 Huawei Technologies Expires: 3 November 2022 Huawei Technologies
June 3, 2021 2 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-08 draft-ietf-opsec-ipv6-eh-filtering-09
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.
skipping to change at page 1, line 38 skipping to change at page 1, line 38
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 December 5, 2021. This Internet-Draft will expire on 3 November 2022.
Copyright Notice Copyright Notice
Copyright (c) 2021 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 Provisions Relating to IETF Documents (https://trustee.ietf.org/
(https://trustee.ietf.org/license-info) in effect on the date of license-info) in effect on the date of publication of this document.
publication of this document. Please review these documents Please review these documents carefully, as they describe your rights
carefully, as they describe your rights and restrictions with respect and restrictions with respect to this document. Code Components
to this document. Code Components extracted from this document must extracted from this document must include Revised BSD License text as
include Simplified BSD License text as described in Section 4.e of described in Section 4.e of the Trust Legal Provisions and are
the Trust Legal Provisions and are provided without warranty as provided without warranty as described in the Revised BSD License.
described in the Simplified 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 Conventions Used 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. Conventions . . . . . . . . . . . . . . . . . . . . . . . 4
3. IPv6 Extension Headers . . . . . . . . . . . . . . . . . . . 5 3. IPv6 Extension Headers . . . . . . . . . . . . . . . . . . . 5
3.1. General Discussion . . . . . . . . . . . . . . . . . . . 5 3.1. General Discussion . . . . . . . . . . . . . . . . . . . 5
skipping to change at page 2, line 29 skipping to change at page 2, line 28
3.3. Summary of Advice on the Handling of IPv6 Packets with 3.3. 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.4. 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.5. 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. Advice on the Handling of Packets with Specific IPv6
Options . . . . . . . . . . . . . . . . . . . . . . . . . 17 Options . . . . . . . . . . . . . . . . . . . . . . . . . 18
4.4. Advice on the handling of Packets with Unknown IPv6 4.4. Advice on the handling of Packets with Unknown IPv6
Options . . . . . . . . . . . . . . . . . . . . . . . . . 30 Options . . . . . . . . . . . . . . . . . . . . . . . . . 30
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 30 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 30
6. Privacy Considerations . . . . . . . . . . . . . . . . . . . 30 6. Privacy Considerations . . . . . . . . . . . . . . . . . . . 30
7. Security Considerations . . . . . . . . . . . . . . . . . . . 30 7. Security Considerations . . . . . . . . . . . . . . . . . . . 31
8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 31 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 31
9. References . . . . . . . . . . . . . . . . . . . . . . . . . 31 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 31
9.1. Normative References . . . . . . . . . . . . . . . . . . 31 9.1. Normative References . . . . . . . . . . . . . . . . . . 31
9.2. Informative References . . . . . . . . . . . . . . . . . 35 9.2. Informative References . . . . . . . . . . . . . . . . . 35
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 37 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 37
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 e.g. enforcing ACLs or implementing other functions [RFC9098].
[I-D.ietf-v6ops-ipv6-ehs-packet-drops].
Recent studies (see e.g. [RFC7872]) suggest that there is widespread Recent studies (see e.g. [RFC7872]) suggest that there is widespread
dropping of IPv6 packets that contain IPv6 Extension Headers (EHs). dropping of IPv6 packets that contain IPv6 Extension Headers (EHs).
In some cases, such packet drops occur at transit routers. While In some cases, such packet drops occur at transit routers. While
some operators "officially" drop packets that contain IPv6 EHs, it is some operators "officially" drop packets that contain IPv6 EHs, it is
possible that some of the measured packet drops be the result of possible that some of the measured packet drops are the result of
improper configuration defaults, or inappropriate advice in this improper configuration defaults, or 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.
skipping to change at page 4, line 37 skipping to change at page 4, line 34
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. Conventions
This document assumes that nodes comply with the requirements in This document assumes that nodes comply with the requirements in
[RFC7045]. Namely, [RFC7045]. Namely,
o If a forwarding node discards a packet containing a standard IPv6 "If a forwarding node discards a packet containing a standard IPv6
EH, it MUST be the result of a configurable policy and not just extension header, it MUST be the result of a configurable policy
the result of a failure to recognize 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
o The discard policy for each standard type of EH MUST be extension header MUST be individually configurable. The default
individually configurable. configuration SHOULD allow all standard extension headers."
o The default configuration should allow all standard IPv6 EHs.
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 configurations, 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:
o Permit this IPv6 EH or IPv6 Option type. * Permit this IPv6 EH or IPv6 Option type.
o Discard (and log) packets containing this IPv6 EH or option type. * Drop (and log) packets containing this IPv6 EH or option type.
o Reject (and log) packets containing this IPv6 EH or option type * Reject (and log) packets containing this IPv6 EH or option type
(where the packet drop is signaled with an ICMPv6 error message). (where the packet drop is signaled with an ICMPv6 error message).
o Rate-limit traffic containing this IPv6 EH or option type. * Rate-limit traffic containing this IPv6 EH or option type.
o 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
forward the packet. We note that if a packet carries forwarding process the packet according the rules for the remaining headers.
information (e.g., in an IPv6 Routing Header) this might be an We note that if a packet carries forwarding information (e.g., in
inappropriate or undesirable action. an IPv6 Routing Header) this might be an inappropriate or
undesirable action.
We note that special care needs to be taken when devices log packet We note that special care needs to be taken when devices log packet
drops/rejects. Devices should count the number of packets dropped/ drops/rejects. Devices should count the number of packets dropped/
rejected, but the logging of drop/reject events should be limited so rejected, but the logging of drop/reject events should be limited so
as to not overburden device resources. as to not overburden device resources.
Finally, we note that when discarding packets, it is generally Finally, we note that when discarding packets, it is generally
desirable that the sender be signaled of the packet drop, since this desirable that the sender be signaled of the packet drop, since this
is of use for trouble-shooting purposes. However, throughout this is of use for trouble-shooting purposes. However, throughout this
document (when recommending that packets be discarded) we generically document (when recommending that packets be discarded) we generically
skipping to change at page 6, line 18 skipping to change at page 6, line 13
a configuration option that specifies whether to discard packets a configuration option that specifies whether to discard packets
if the aforementioned limit is encountered. Operators may then if the aforementioned limit is encountered. Operators may then
determine according to their own circumstances how such packets determine according to their own circumstances how such packets
will be handled. will be handled.
3.2. General Security Implications 3.2. General Security Implications
In some device architectures, IPv6 packets that contain IPv6 EHs can In some device architectures, IPv6 packets that contain IPv6 EHs can
cause the corresponding packets to be processed on the slow path, and cause the corresponding packets to be processed on the slow path, and
hence may be leveraged for the purpose of Denial of Service (DoS) hence may be leveraged for the purpose of Denial of Service (DoS)
attacks [I-D.ietf-v6ops-ipv6-ehs-packet-drops] [Cisco-EH] attacks [RFC9098] [Cisco-EH] [FW-Benchmark].
[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
future. the future.
3.3. Summary of Advice on the Handling of IPv6 Packets with Specific 3.3. 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.4, 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 3 | | IPv6 Hop-by-Hop Options | Drop or Ignore | Section |
| (Proto=0) | | .4.1 | | (Proto=0) | | 3.4.1 |
+----------------------------+--------------------------+-----------+ +-------------------------+--------------------------+-----------+
| Routing Header for IPv6 | Drop only RHT0 and RHT1. | Section 3 | | Routing Header for IPv6 | Drop only RHT0 and RHT1. | Section |
| (Proto=43) | Permit other RH Types | .4.2 | | (Proto=43) | Permit other RH Types | 3.4.2 |
+----------------------------+--------------------------+-----------+ +-------------------------+--------------------------+-----------+
| Fragment Header for IPv6 | Permit | Section 3 | | Fragment Header for | Permit | Section |
| (Proto=44) | | .4.3 | | IPv6 (Proto=44) | | 3.4.3 |
+----------------------------+--------------------------+-----------+ +-------------------------+--------------------------+-----------+
| Encapsulating Security | Permit | Section 3 | | Encapsulating Security | Permit | Section |
| Payload (Proto=50) | | .4.4 | | Payload (Proto=50) | | 3.4.4 |
+----------------------------+--------------------------+-----------+ +-------------------------+--------------------------+-----------+
| Authentication Header | Permit | Section 3 | | Authentication Header | Permit | Section |
| (Proto=51) | | .4.5 | | (Proto=51) | | 3.4.5 |
+----------------------------+--------------------------+-----------+ +-------------------------+--------------------------+-----------+
| Destination Options for | Permit | Section 3 | | Destination Options for | Permit | Section |
| IPv6 (Proto=60) | | .4.6 | | IPv6 (Proto=60) | | 3.4.6 |
+----------------------------+--------------------------+-----------+ +-------------------------+--------------------------+-----------+
| Mobility Header | Permit | Section 3 | | Mobility Header | Permit | Section |
| (Proto=135) | | .4.7 | | (Proto=135) | | 3.4.7 |
+----------------------------+--------------------------+-----------+ +-------------------------+--------------------------+-----------+
| Host Identity Protocol | Permit | Section 3 | | Host Identity Protocol | Permit | Section |
| (Proto=139) | | .4.8 | | (Proto=139) | | 3.4.8 |
+----------------------------+--------------------------+-----------+ +-------------------------+--------------------------+-----------+
| Shim6 Protocol (Proto=140) | Permit | Section 3 | | Shim6 Protocol | Permit | Section |
| | | .4.9 | | (Proto=140) | | 3.4.9 |
+----------------------------+--------------------------+-----------+ +-------------------------+--------------------------+-----------+
| Use for experimentation | Drop | Section 3 | | Use for experimentation | Drop | Section |
| and testing (Proto=253 and | | .4.10 | | and testing (Proto=253 | | 3.4.10 |
| 254) | | | | and 254) | | |
+----------------------------+--------------------------+-----------+ +-------------------------+--------------------------+-----------+
Table 1: Summary of Advice on the Handling of IPv6 Packets with Table 1: Summary of Advice on the Handling of IPv6 Packets
Specific IPv6 Extension Headers with Specific IPv6 Extension Headers
3.4. Advice on the Handling of IPv6 Packets with Specific IPv6 3.4. 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.4.1. IPv6 Hop-by-Hop Options (Protocol Number=0)
3.4.1.1. Uses 3.4.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.4.1.2. Specification
skipping to change at page 8, line 19 skipping to change at page 8, line 22
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.4.1.2. Specification
This EH is specified in [RFC8200]. At the time of this writing, the This EH is specified in [RFC8200]. At the time of this writing, the
following options have been specified for the Hop-by-Hop Options EH: following options have been specified for the Hop-by-Hop Options EH:
o Type 0x00: Pad1 [RFC8200] * Type 0x00: Pad1 [RFC8200]
o Type 0x01: PadN [RFC8200] * Type 0x01: PadN [RFC8200]
o Type 0x05: Router Alert [RFC2711] * Type 0x05: Router Alert [RFC2711]
o Type 0x07: CALIPSO [RFC5570] * Type 0x07: CALIPSO [RFC5570]
o Type 0x08: SMF_DPD [RFC6621] * Type 0x08: SMF_DPD [RFC6621]
o Type 0x23: RPL Option [RFC9008] * Type 0x23: RPL Option [RFC9008]
o Type 0x26: Quick-Start [RFC4782] * Type 0x26: Quick-Start [RFC4782]
o Type 0x4D: (Deprecated) * Type 0x4D: (Deprecated)
o Type 0x63: RPL Option [RFC6553] * Type 0x63: RPL Option [RFC6553]
o Type 0x6D: MPL Option [RFC7731] * Type 0x6D: MPL Option [RFC7731]
o Type 0x8A: Endpoint Identification (Deprecated) * Type 0x8A: Endpoint Identification (Deprecated)
[draft-ietf-nimrod-eid] [draft-ietf-nimrod-eid]
o Type 0xC2: Jumbo Payload [RFC2675] * Type 0xC2: Jumbo Payload [RFC2675]
o Type 0xEE: IPv6 DFF Header [RFC6971] * Type 0xEE: IPv6 DFF Header [RFC6971]
o Type 0x1E: RFC3692-style Experiment [RFC4727] * Type 0x1E: RFC3692-style Experiment [RFC4727]
o Type 0x3E: RFC3692-style Experiment [RFC4727] * Type 0x3E: RFC3692-style Experiment [RFC4727]
* Type 0x5E: RFC3692-style Experiment [RFC4727]
o Type 0x5E: RFC3692-style Experiment [RFC4727] * Type 0x7E: RFC3692-style Experiment [RFC4727]
o Type 0x7E: RFC3692-style Experiment [RFC4727] * Type 0x9E: RFC3692-style Experiment [RFC4727]
o Type 0x9E: RFC3692-style Experiment [RFC4727]
o Type 0xBE: RFC3692-style Experiment [RFC4727] * Type 0xBE: RFC3692-style Experiment [RFC4727]
o Type 0xDE: RFC3692-style Experiment [RFC4727] * Type 0xDE: RFC3692-style Experiment [RFC4727]
o Type 0xFE: RFC3692-style Experiment [RFC4727] * Type 0xFE: RFC3692-style Experiment [RFC4727]
3.4.1.3. Specific Security Implications 3.4.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 traditional 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.4.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.4.1.5. Advice
skipping to change at page 9, line 47 skipping to change at page 10, line 5
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
HBH Options EH is carried out in the slow path, and an option is HBH Options EH is carried out in the slow path, and an option is
provided to rate-limit these packets, we recommend that this option provided to rate-limit these packets, we recommend that this option
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, for obvious reasons, RPL (Routing Protocol for Finally, we note that RPL (Routing Protocol for Low-Power and Lossy
Low-Power and Lossy Networks) [RFC6550] routers must not discard Networks) routers [RFC6550] must not discard packets based on the
packets based on the presence of an IPv6 Hop-by-Hop Options EH. 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.4.2. Routing Header for IPv6 (Protocol Number=43)
3.4.2.1. Uses 3.4.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.4.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 the time of this writing, the following Routing Types have been
specified: specified:
o Type 0: Source Route (DEPRECATED) [RFC2460] [RFC5095] * Type 0: Source Route (DEPRECATED) [RFC2460] [RFC5095]
o Type 1: Nimrod (DEPRECATED) * Type 1: Nimrod (DEPRECATED)
o Type 2: Type 2 Routing Header [RFC6275] * Type 2: Type 2 Routing Header [RFC6275]
o Type 3: RPL Source Route Header [RFC6554] * Type 3: RPL Source Route Header [RFC6554]
o Type 4: Segment Routing Header (SRH) [RFC8754] * Type 4: Segment Routing Header (SRH) [RFC8754]
o Types 5-252: Unassigned * Types 5-252: Unassigned
o Type 253: RFC3692-style Experiment 1 [RFC4727] * Type 253: RFC3692-style Experiment 1 [RFC4727]
o Type 254: RFC3692-style Experiment 2 [RFC4727] * Type 254: RFC3692-style Experiment 2 [RFC4727]
o Type 255: Reserved * Type 255: Reserved
3.4.2.3. Specific Security Implications 3.4.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]. The security implications of RHT4 (SRH) [Biondi2007] and [RFC5095]. RHT1 was never widely implemented. The
are discussed in [RFC8754]. security implications of RHT2, RHT3, and RHT4 (SRH) are discussed in
[RFC6275], [RFC6554], and [RFC8754], respectively.
3.4.2.4. Operational and Interoperability Impact if Blocked 3.4.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 RHT4 (SRH) will break Segment Routing (SR) deployments, if the a RHT2 would break Mobile IPv6. Packets with a RHT3 may be safely
filtering policy is enforced on packets being forwarded within an SR blocked at RPL domain boundaries, since RHT3 headers are employed
domain. within a single RPL domain. Blocking packets with a RHT4 (SRH) will
break Segment Routing (SR) deployments, if the filtering policy is
enforced on packets being forwarded within an SR domain.
3.4.2.5. Advice 3.4.2.5. Advice
Intermediate systems should discard packets containing a RHT0 or Intermediate systems should discard packets containing a RHT0, RHT1,
RHT1. Other routing header types should be permitted, as required by or RHT3. Other routing header types should be permitted, as required
[RFC7045]. by [RFC7045].
3.4.3. Fragment Header for IPv6 (Protocol Number=44) 3.4.3. Fragment Header for IPv6 (Protocol Number=44)
3.4.3.1. Uses 3.4.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.4.3.2. Specification
This EH is specified in [RFC8200]. This EH is specified in [RFC8200].
skipping to change at page 13, line 14 skipping to change at page 13, line 22
3.4.6.1. Uses 3.4.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.4.6.2. Specification
This EH is specified in [RFC8200]. At the time of this writing, the This EH is specified in [RFC8200]. At the time of this writing, the
following options have been specified for this EH: following options have been specified for this EH:
o Type 0x00: Pad1 [RFC8200] * Type 0x00: Pad1 [RFC8200]
o Type 0x01: PadN [RFC8200] * Type 0x01: PadN [RFC8200]
o Type 0x04: Tunnel Encapsulation Limit [RFC2473] * Type 0x04: Tunnel Encapsulation Limit [RFC2473]
o Type 0x4D: (Deprecated) * Type 0x4D: (Deprecated)
o Type 0xC9: Home Address [RFC6275] * Type 0xC9: Home Address [RFC6275]
o Type 0x8A: Endpoint Identification (Deprecated) * Type 0x8A: Endpoint Identification (Deprecated)
[draft-ietf-nimrod-eid] [draft-ietf-nimrod-eid]
o Type 0x8B: ILNP Nonce [RFC6744] * Type 0x8B: ILNP Nonce [RFC6744]
o Type 0x8C: Line-Identification Option [RFC6788]
o Type 0x1E: RFC3692-style Experiment [RFC4727] * Type 0x8C: Line-Identification Option [RFC6788]
o Type 0x3E: RFC3692-style Experiment [RFC4727] * Type 0x1E: RFC3692-style Experiment [RFC4727]
o Type 0x5E: RFC3692-style Experiment [RFC4727] * Type 0x3E: RFC3692-style Experiment [RFC4727]
o Type 0x7E: RFC3692-style Experiment [RFC4727] * Type 0x5E: RFC3692-style Experiment [RFC4727]
o Type 0x9E: RFC3692-style Experiment [RFC4727] * Type 0x7E: RFC3692-style Experiment [RFC4727]
o Type 0xBE: RFC3692-style Experiment [RFC4727] * Type 0x9E: RFC3692-style Experiment [RFC4727]
o Type 0xDE: RFC3692-style Experiment [RFC4727] * Type 0xBE: RFC3692-style Experiment [RFC4727]
o Type 0xFE: RFC3692-style Experiment [RFC4727] * Type 0xDE: RFC3692-style Experiment [RFC4727]
* Type 0xFE: RFC3692-style Experiment [RFC4727]
3.4.6.3. Specific Security Implications 3.4.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.3.
3.4.6.4. Operational and Interoperability Impact if Blocked 3.4.6.4. Operational and Interoperability Impact if Blocked
skipping to change at page 19, line 38 skipping to change at page 19, line 43
There are no specific issues arising from this option, except for There are no specific issues arising from this option, except for
improper validity checks of the option and associated packet lengths. improper validity checks of the option and associated packet lengths.
4.3.3.4. Operational and Interoperability Impact if Blocked 4.3.3.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.3.3.5. Advice 4.3.3.5. Advice
Intermediate systems should discard packets that contain this option.
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 desired.
4.3.4. RPL Option (Type=0x63) 4.3.4. RPL Option (Type=0x63)
4.3.4.1. Uses 4.3.4.1. Uses
The RPL Option provides a mechanism to include routing information The RPL Option provides a mechanism to include routing information
with each datagram that an RPL router forwards. with each datagram that an RPL router forwards.
4.3.4.2. Specification 4.3.4.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.3.4.3. Specific Security Implications 4.3.4.3. Specific Security Implications
Those described in [RFC6553]. Those described in [RFC9008].
4.3.4.4. Operational and Interoperability Impact if Blocked 4.3.4.4. Operational and Interoperability Impact if Blocked
This option is meant to be employed within an RPL instance. As a This option is meant to be employed within an RPL instance. As a
result, discarding packets based on the presence of this option (e.g. result, discarding packets based on the presence of this option
at an ISP) will not result in interoperability implications. outside of an RPL instance will not result in interoperability
implications.
4.3.4.5. Advice 4.3.4.5. Advice
Non-RPL routers should discard packets that contain an RPL option. Non-RPL routers should discard packets that contain an RPL option.
4.3.5. RPL Option (Type=0x23) 4.3.5. RPL Option (Type=0x23)
4.3.5.1. Uses 4.3.5.1. Uses
The RPL Option provides a mechanism to include routing information The RPL Option provides a mechanism to include routing information
skipping to change at page 20, line 41 skipping to change at page 20, line 42
4.3.5.2. Specification 4.3.5.2. Specification
This option is specified in [RFC9008]. This option is specified in [RFC9008].
4.3.5.3. Specific Security Implications 4.3.5.3. Specific Security Implications
Those described in [RFC9008]. Those described in [RFC9008].
4.3.5.4. Operational and Interoperability Impact if Blocked 4.3.5.4. Operational and Interoperability Impact if Blocked
This option is meant to survive outside of an RPL instance. As a This option can survive outside of an RPL instance. As a result,
result, discarding packets based on the presence of this option would discarding packets based on the presence of this option would break
break some use cases for RPL (see [RFC9008]). some use cases for RPL (see [RFC9008]).
4.3.5.5. Advice 4.3.5.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.6. Tunnel Encapsulation Limit (Type=0x04) 4.3.6. Tunnel Encapsulation Limit (Type=0x04)
4.3.6.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.3.6.2. Specification
This option is specified in [RFC2473]. This option is specified in [RFC2473].
4.3.6.3. Specific Security Implications 4.3.6.3. Specific Security Implications
skipping to change at page 22, line 36 skipping to change at page 22, line 36
4.3.8.2. Specification 4.3.8.2. Specification
This option is specified in [RFC4782], on the "Experimental" track. This option is specified in [RFC4782], on the "Experimental" track.
4.3.8.3. Specific Security Implications 4.3.8.3. Specific Security Implications
Section 9.6 of [RFC4782] notes that Quick-Start is vulnerable to two Section 9.6 of [RFC4782] notes that Quick-Start is vulnerable to two
kinds of attacks: kinds of attacks:
o attacks to increase the routers' processing and state load, and, * attacks to increase the routers' processing and state load, and,
o 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.3.8.4. Operational and Interoperability Impact if Blocked 4.3.8.4. Operational and Interoperability Impact if Blocked
The Quick-Start functionality would be disabled, and additional The Quick-Start functionality would be disabled, and additional
skipping to change at page 23, line 43 skipping to change at page 23, line 51
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 an intermediate router or firewall.
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. either of which is problematic. As noted in [RFC5570], IPsec
[RFC4301] [RFC4302] [RFC4303] can be employed to protect the CALIPSO
option.
4.3.9.5. Advice 4.3.9.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 or not that particular intermediate system system can know whether that particular intermediate system has been
has been deployed within a Multi-Level Secure (MLS) environment. In deployed within a Multi-Level Secure (MLS) environment. In many
many cases, ordinary commercial intermediate systems (e.g., IPv6 cases, ordinary commercial intermediate systems (e.g., IPv6 routers
routers and firewalls) are the majority of the deployed intermediate and firewalls) are the majority of the deployed intermediate systems
systems inside an MLS network environment. inside an MLS network environment.
For Intermediate systems that DO NOT implement RFC-5570, there should For Intermediate systems that DO NOT implement [RFC5570], there
be a configuration option to EITHER (a) drop packets containing the should be a configuration option to EITHER (a) drop packets
CALIPSO option OR (b) to ignore the presence of the CALIPSO option containing the CALIPSO option OR (b) to ignore the presence of the
and forward the packets normally. In non-MLS environments, such CALIPSO option and forward the packets normally. In non-MLS
intermediate systems should have this configuration option set to (a) environments, such intermediate systems should have this
above. In MLS environments, such intermediate systems should have configuration option set to (a) above. In MLS environments, such
this option set to (b) above. The default setting for this intermediate systems should have this option set to (b) above. The
configuration option should be set to (a) above, because MLS default setting for this configuration option should 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.
For Intermediate systems that DO implement RFC-5570, there should be For Intermediate systems that DO implement [RFC5570], there should be
configuration options (a) and (b) from the preceding paragraph and configuration options (a) and (b) from the preceding paragraph and
also a third configuration option (c) to process packets containing a also a third configuration option (c) to process packets containing a
CALIPSO option as per RFC-5570. 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.3.10. SMF_DPD (Type=0x08)
4.3.10.1. Uses 4.3.10.1. Uses
skipping to change at page 31, line 11 skipping to change at page 31, line 20
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.
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, David order) Mikael Abrahamsson, Brian Carpenter, Darren Dukes, Lars
Farmer, Mike Heard, Bob Hinden, Christian Huitema, Jen Linkova, Eggert, David Farmer, Mike Heard, Bob Hinden, Christian Huitema,
Carlos Pignataro, Maria Ines Robles, Donald Smith, Pascal Thubert, Benjamin Kaduk, Erik Kline, Jen Linkova, Carlos Pignataro, Alvaro
Ole Troan, Gunter Van De Velde, and Eric Vyncke, for providing Retana, Maria Ines Robles, Donald Smith, Pascal Thubert, Ole Troan,
valuable comments on earlier versions of this document. Gunter Van De Velde, and Eric Vyncke, 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 Eric Vyncke for his guidance during
the publication process of this document. 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
skipping to change at page 32, line 28 skipping to change at page 32, line 41
[RFC3810] Vida, R., Ed. and L. Costa, Ed., "Multicast Listener [RFC3810] Vida, R., Ed. and L. Costa, Ed., "Multicast Listener
Discovery Version 2 (MLDv2) for IPv6", RFC 3810, Discovery Version 2 (MLDv2) for IPv6", RFC 3810,
DOI 10.17487/RFC3810, June 2004, DOI 10.17487/RFC3810, June 2004,
<https://www.rfc-editor.org/info/rfc3810>. <https://www.rfc-editor.org/info/rfc3810>.
[RFC4286] Haberman, B. and J. Martin, "Multicast Router Discovery", [RFC4286] Haberman, B. and J. Martin, "Multicast Router Discovery",
RFC 4286, DOI 10.17487/RFC4286, December 2005, RFC 4286, DOI 10.17487/RFC4286, December 2005,
<https://www.rfc-editor.org/info/rfc4286>. <https://www.rfc-editor.org/info/rfc4286>.
[RFC4301] Kent, S. and K. Seo, "Security Architecture for the
Internet Protocol", RFC 4301, DOI 10.17487/RFC4301,
December 2005, <https://www.rfc-editor.org/info/rfc4301>.
[RFC4302] Kent, S., "IP Authentication Header", RFC 4302, [RFC4302] Kent, S., "IP Authentication Header", RFC 4302,
DOI 10.17487/RFC4302, December 2005, DOI 10.17487/RFC4302, December 2005,
<https://www.rfc-editor.org/info/rfc4302>. <https://www.rfc-editor.org/info/rfc4302>.
[RFC4303] Kent, S., "IP Encapsulating Security Payload (ESP)", [RFC4303] Kent, S., "IP Encapsulating Security Payload (ESP)",
RFC 4303, DOI 10.17487/RFC4303, December 2005, RFC 4303, DOI 10.17487/RFC4303, December 2005,
<https://www.rfc-editor.org/info/rfc4303>. <https://www.rfc-editor.org/info/rfc4303>.
[RFC4727] Fenner, B., "Experimental Values In IPv4, IPv6, ICMPv4, [RFC4727] Fenner, B., "Experimental Values In IPv4, IPv6, ICMPv4,
ICMPv6, UDP, and TCP Headers", RFC 4727, ICMPv6, UDP, and TCP Headers", RFC 4727,
skipping to change at page 35, line 10 skipping to change at page 35, line 24
[RFC8754] Filsfils, C., Ed., Dukes, D., Ed., Previdi, S., Leddy, J., [RFC8754] Filsfils, C., Ed., Dukes, D., Ed., Previdi, S., Leddy, J.,
Matsushima, S., and D. Voyer, "IPv6 Segment Routing Header Matsushima, S., and D. Voyer, "IPv6 Segment Routing Header
(SRH)", RFC 8754, DOI 10.17487/RFC8754, March 2020, (SRH)", RFC 8754, DOI 10.17487/RFC8754, March 2020,
<https://www.rfc-editor.org/info/rfc8754>. <https://www.rfc-editor.org/info/rfc8754>.
[RFC8900] Bonica, R., Baker, F., Huston, G., Hinden, R., Troan, O., [RFC8900] Bonica, R., Baker, F., Huston, G., Hinden, R., Troan, O.,
and F. Gont, "IP Fragmentation Considered Fragile", and F. Gont, "IP Fragmentation Considered Fragile",
BCP 230, RFC 8900, DOI 10.17487/RFC8900, September 2020, BCP 230, RFC 8900, DOI 10.17487/RFC8900, September 2020,
<https://www.rfc-editor.org/info/rfc8900>. <https://www.rfc-editor.org/info/rfc8900>.
[RFC9008] Robles, M., Richardson, M., and P. Thubert, "Using RPI [RFC9008] Robles, M.I., Richardson, M., and P. Thubert, "Using RPI
Option Type, Routing Header for Source Routes, and IPv6- Option Type, Routing Header for Source Routes, and IPv6-
in-IPv6 Encapsulation in the RPL Data Plane", RFC 9008, in-IPv6 Encapsulation in the RPL Data Plane", RFC 9008,
DOI 10.17487/RFC9008, April 2021, DOI 10.17487/RFC9008, April 2021,
<https://www.rfc-editor.org/info/rfc9008>. <https://www.rfc-editor.org/info/rfc9008>.
9.2. Informative References 9.2. Informative References
[Biondi2007] [Biondi2007]
Biondi, P. and A. Ebalard, "IPv6 Routing Header Security", Biondi, P. and A. Ebalard, "IPv6 Routing Header Security",
CanSecWest 2007 Security Conference, 2007, CanSecWest 2007 Security Conference, 2007,
<http://www.secdev.org/conf/IPv6_RH_security-csw07.pdf>. <http://www.secdev.org/conf/IPv6_RH_security-csw07.pdf>.
[Cisco-EH] [Cisco-EH] Cisco Systems, "IPv6 Extension Headers Review and
Cisco Systems, "IPv6 Extension Headers Review and
Considerations", Whitepaper. October 2006, Considerations", Whitepaper. October 2006,
<http://www.cisco.com/en/US/technologies/tk648/tk872/ <https://www.cisco.com/en/US/technologies/tk648/tk872/
technologies_white_paper0900aecd8054d37d.pdf>. technologies_white_paper0900aecd8054d37d.pdf>.
[draft-gont-6man-ipv6-opt-transmit] [draft-gont-6man-ipv6-opt-transmit]
Gont, F., Liu, W., and R. Bonica, "Transmission and Gont, F., Liu, W., and R. Bonica, "Transmission and
Processing of IPv6 Options", IETF Internet Draft, work in Processing of IPv6 Options", IETF Internet Draft, work in
progress, August 2014. progress, August 2014.
[draft-ietf-nimrod-eid] [draft-ietf-nimrod-eid]
Lynn, C., "Endpoint Identifier Destination Option", IETF Lynn, C.L., "Endpoint Identifier Destination
Internet Draft, draft-ietf-nimrod-eid-00.txt, November Option", IETF Internet Draft, draft-ietf-nimrod-eid-
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,
<http://www.ipv6hackers.org/meetings/ipv6-hackers-1/zack- <https://www.ipv6hackers.org/files/meetings/ipv6-hackers-
ipv6hackers1-firewall-security-assessment-and- 1/zack-ipv6hackers1-firewall-security-assessment-and-
benchmarking.pdf>. benchmarking.pdf>.
[I-D.ietf-v6ops-ipv6-ehs-packet-drops]
Gont, F., Hilliard, N., Doering, G., Kumari, W., Huston,
G., and W. (. Liu, "Operational Implications of IPv6
Packets with Extension Headers", draft-ietf-v6ops-ipv6-
ehs-packet-drops-06 (work in progress), April 2021.
[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", draft-irtf-pearg-numeric-ids- Numeric Identifiers", Work in Progress, Internet-Draft,
generation-07 (work in progress), February 2021. draft-irtf-pearg-numeric-ids-generation-08, 31 January
2022, <https://www.ietf.org/archive/id/draft-irtf-pearg-
numeric-ids-generation-08.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,
<http://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, <http://www.iana.org/assignments/protocol-numbers/ 2014, <https://www.iana.org/assignments/protocol-numbers/
protocol-numbers.xhtml>. protocol-numbers.xhtml>.
[NIMROD-DOC] [NIMROD-DOC]
Nimrod Documentation Page, Nimrod Documentation Page,
"http://ana-3.lcs.mit.edu/~jnc/nimrod/". "http://ana-3.lcs.mit.edu/~jnc/nimrod/".
[RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6 [RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6
(IPv6) Specification", RFC 2460, DOI 10.17487/RFC2460, (IPv6) Specification", RFC 2460, DOI 10.17487/RFC2460,
December 1998, <https://www.rfc-editor.org/info/rfc2460>. December 1998, <https://www.rfc-editor.org/info/rfc2460>.
skipping to change at page 37, line 5 skipping to change at page 37, line 15
[RFC7739] Gont, F., "Security Implications of Predictable Fragment [RFC7739] Gont, F., "Security Implications of Predictable Fragment
Identification Values", RFC 7739, DOI 10.17487/RFC7739, Identification Values", RFC 7739, DOI 10.17487/RFC7739,
February 2016, <https://www.rfc-editor.org/info/rfc7739>. February 2016, <https://www.rfc-editor.org/info/rfc7739>.
[RFC7872] Gont, F., Linkova, J., Chown, T., and W. Liu, [RFC7872] Gont, F., Linkova, J., Chown, T., and W. Liu,
"Observations on the Dropping of Packets with IPv6 "Observations on the Dropping of Packets with IPv6
Extension Headers in the Real World", RFC 7872, Extension Headers in the Real World", RFC 7872,
DOI 10.17487/RFC7872, June 2016, DOI 10.17487/RFC7872, June 2016,
<https://www.rfc-editor.org/info/rfc7872>. <https://www.rfc-editor.org/info/rfc7872>.
[RFC9098] Gont, F., Hilliard, N., Doering, G., Kumari, W., Huston,
G., and W. Liu, "Operational Implications of IPv6 Packets
with Extension Headers", RFC 9098, DOI 10.17487/RFC9098,
September 2021, <https://www.rfc-editor.org/info/rfc9098>.
Authors' Addresses Authors' Addresses
Fernando Gont Fernando Gont
SI6 Networks SI6 Networks
Segurola y Habana 4310, 7mo Piso Segurola y Habana 4310, 7mo Piso
Villa Devoto, Ciudad Autonoma de Buenos Aires Villa Devoto
Ciudad Autonoma de Buenos Aires
Argentina Argentina
Email: fgont@si6networks.com Email: fgont@si6networks.com
URI: https://www.si6networks.com URI: https://www.si6networks.com
Will (Shucheng) Liu Will (Shucheng) Liu
Huawei Technologies Huawei Technologies
Bantian, Longgang District Bantian, Longgang District
Shenzhen 518129 Shenzhen
518129
P.R. China P.R. China
Email: liushucheng@huawei.com Email: liushucheng@huawei.com
 End of changes. 98 change blocks. 
189 lines changed or deleted 192 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/