draft-ietf-opsec-ipv6-eh-filtering-06.txt   draft-ietf-opsec-ipv6-eh-filtering-07.txt 
opsec F. Gont opsec F. Gont
Internet-Draft UTN-FRH / SI6 Networks Internet-Draft SI6 Networks
Intended status: Informational W. Liu Intended status: Informational W. Liu
Expires: January 3, 2019 Huawei Technologies Expires: July 23, 2021 Huawei Technologies
July 2, 2018 January 19, 2021
Recommendations on the Filtering of IPv6 Packets Containing IPv6 Recommendations on the Filtering of IPv6 Packets Containing IPv6
Extension Headers Extension Headers at Transit Routers
draft-ietf-opsec-ipv6-eh-filtering-06 draft-ietf-opsec-ipv6-eh-filtering-07
Abstract Abstract
It is common operator practice to mitigate security risks by This document analyzes the security implications of IPv6 Extension
enforcing appropriate packet filtering. This document analyzes both Headers and associated IPv6 options. Additionally, it discusses the
the general security implications of IPv6 Extension Headers and the operational and interoperability implications of discarding packets
specific security implications of each Extension Header and Option based on the IPv6 Extension Headers and IPv6 options they contain.
type. Additionally, it discusses the operational and Finally, it provides advice on the filtering of such IPv6 packets at
interoperability implications of discarding packets based on the IPv6 transit routers for traffic *not* directed to them, for those cases
Extension Headers and IPv6 options they contain. Finally, it where such filtering is deemed as necessary.
provides advice on the filtering of such IPv6 packets at transit
routers for traffic *not* directed to them, for those cases in which
such filtering is deemed as necessary.
Status of This Memo Status of This Memo
This Internet-Draft is submitted in full conformance with the This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/. Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on January 3, 2019. This Internet-Draft will expire on July 23, 2021.
Copyright Notice Copyright Notice
Copyright (c) 2018 IETF Trust and the persons identified as the Copyright (c) 2021 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/license-info) in effect on the date of (https://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the Simplified 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 . . . . . . 3 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
3.2. General Security Implications . . . . . . . . . . . . . . 6 3.2. General Security Implications . . . . . . . . . . . . . . 6
3.3. Summary of Advice on the Handling of IPv6 Packets with 3.3. 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 . . . . . . . . . . . . . . . . . . . . . . . . . 17
4.4. Advice on the handling of Packets with Unknown IPv6 4.4. Advice on the handling of Packets with Unknown IPv6
Options . . . . . . . . . . . . . . . . . . . . . . . . . 29 Options . . . . . . . . . . . . . . . . . . . . . . . . . 30
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 29 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 30
6. Security Considerations . . . . . . . . . . . . . . . . . . . 30 6. Privacy Considerations . . . . . . . . . . . . . . . . . . . 30
7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 30 7. Security Considerations . . . . . . . . . . . . . . . . . . . 30
8. References . . . . . . . . . . . . . . . . . . . . . . . . . 30 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 31
8.1. Normative References . . . . . . . . . . . . . . . . . . 30 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 31
8.2. Informative References . . . . . . . . . . . . . . . . . 34 9.1. Normative References . . . . . . . . . . . . . . . . . . 31
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 35 9.2. Informative References . . . . . . . . . . . . . . . . . 35
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 37
1. Introduction 1. Introduction
IPv6 Extension Headers (EHs) allow for the extension of the IPv6
protocol, and provide support for core functionality such as IPv6
fragmentation. However, common implementation limitations suggest
that EHs present a challenge for IPv6 packet routing equipment,
particularly when the IPv6 header chain needs to be processed for
e.g. enforcing ACLs or implementing other functions
[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 be 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 and the specific security implications of each EH and Option EHs, as well as the security implications of specific EH and Option
type, and provides advice on the filtering of IPv6 packets based on types. It also provides advice on the filtering of IPv6 packets
the IPv6 EHs and the IPv6 options they contain. Since various based on the IPv6 EHs and the IPv6 options they contain. Since
protocols may use IPv6 EHs (possibly with IPv6 options), discarding various protocols may use IPv6 EHs (possibly with IPv6 options),
packets based on the IPv6 EHs or IPv6 options they contain may have discarding packets based on the IPv6 EHs or IPv6 options they contain
implications on the proper functioning of such protocols. Thus, this can have implications on the proper functioning of such protocols.
document also attempts to discuss the operational and Thus, this document also attempts to discuss the operational and
interoperability implications of such filtering policies. interoperability implications of such filtering policies.
The filtering policy typically depends on where in the network such The resulting packet filtering policy typically depends on where in
policy is enforced: when the policy is enforced in a transit network, the network such policy is enforced: when the policy is enforced in a
the policy typically follows a "black-list" approach, where only transit network, the policy typically follows a "deny-list" approach,
packets with clear negative implications are dropped. On the other where only packets with clear negative implications are dropped. On
hand, when the policy is enforced closer to the destination systems, the other hand, when the policy is enforced closer to the destination
the policy typically follows a "white-list" approach, where only systems, the policy typically follows an "accept-list" approach,
traffic that is expected to be received is allowed. The advice in where only traffic that is expected to be received is allowed. The
this document is aimed only at transit routers that may need to advice in this document is aimed only at transit routers that may
enforce a filtering policy based on the EHs and IPv6 options a packet need to enforce a filtering policy based on the EHs and IPv6 options
may contain, following a "black-list" approach, and hence is likely a packet may contain, following a "deny-list" approach, and hence is
to be much more permissive that a filtering policy to be employed likely to be much more permissive that a filtering policy to be
e.g. at the edge of an enterprise network. The advice in this employed at e.g. the edge of an enterprise network. The advice in
document is meant to improve the current situation of the dropping of this document is meant to improve the current situation of the
packets with IPv6 EHs in the Internet [RFC7872]. dropping of packets with IPv6 EHs in the Internet [RFC7872] in such
cases where packets are being dropped due to inappropriate or missing
guidelines.
This document is similar in nature to [RFC7126], which addresses the This document is similar in nature to [RFC7126], which addresses the
same problem for the IPv4 case. However, in IPv6, the problem space same problem for the IPv4 case. However, in IPv6, the problem space
is compounded by the fact that IPv6 specifies a number of IPv6 EHs, is compounded by the fact that IPv6 specifies a number of IPv6 EHs,
and a number of IPv6 options which may be valid only when included in and a number of IPv6 options which may be valid only when included in
specific EH types. specific EH types.
This document completes and complements the considerations for This document completes and complements the considerations for
protecting the control plane from packets containing IP options that protecting the control plane from packets containing IP options that
can be found in [RFC6192]. can be found in [RFC6192].
Section 2 of this document specifies the terminology and conventions Section 2 of this document specifies the terminology and conventions
employed throughout this document. Section 3 of this document employed throughout this document. Section 3 of this document
discusses IPv6 EHs and provides advice in the area of filtering IPv6 discusses IPv6 EHs and provides advice in the area of filtering IPv6
packets that contain such IPv6 EHs. Section 4 of this document packets that contain such IPv6 EHs. Section 4 of this document
discusses IPv6 options and provides advice in the area of filtering discusses IPv6 options and provides advice in the area of filtering
IPv6 packets that contain such options. IPv6 packets that contain such options.
2. Terminology and Conventions Used in This Document 2. Terminology and Conventions Used in This Document
2.1. Terminology
The terms "fast path", "slow path", and associated relative terms 2.1. Terminology
("faster path" and "slower path") are loosely defined as in Section 2
of [RFC6398].
The terms "permit" (allow the traffic), "drop" (drop with no The terms "permit" (allow the traffic), "drop" (drop with no
notification to sender), and "reject" (drop with appropriate notification to sender), and "reject" (drop with appropriate
notification to sender) are employed as defined in [RFC3871]. notification to sender) are employed as defined in [RFC3871].
Throughout this document we also employ the term "discard" as a Throughout this document we also employ the term "discard" as a
generic term to indicate the act of discarding a packet, irrespective generic term to indicate the act of discarding a packet, irrespective
of whether the sender is notified of such drops, and irrespective of of whether the sender is notified of such drops, and irrespective of
whether the specific filtering action is logged. whether the specific filtering action is logged.
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
document are to be interpreted as described in [RFC2119]. "OPTIONAL" in this document are to be interpreted as described in BCP
14 [RFC2119] [RFC8174] when, and only when, they appear in all
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 such EHs at transit routers for traffic *not* explicitly destined to them,
transit routers, for those cases in which such filtering is deemed as for cases in which such filtering is deemed as necessary.
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 (from [RFC7045]), [RFC7045]. Namely,
o If a forwarding node discards a packet containing a standard IPv6 o If a forwarding node discards a packet containing a standard IPv6
EH, it MUST be the result of a configurable policy and not just EH, it MUST be the result of a configurable policy and not just
the result of a failure to recognise such a header. the result of a failure to recognise such a header.
o The discard policy for each standard type of EH MUST be o The discard policy for each standard type of EH MUST be
individually configurable. individually configurable.
o The default configuration SHOULD allow all standard IPv6 EHs. 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 may include the following possible settings: configuration options should include the following possible settings:
o Permit this IPv6 EH or IPv6 Option type o Permit this IPv6 EH or IPv6 Option type.
o Discard (and log) packets containing this IPv6 EH or option type o Discard (and log) packets containing this IPv6 EH or option type.
o Reject (and log) packets containing this IPv6 EH or option type o 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 o 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 o 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 forward the packet. We note that if a packet carries forwarding
information (e.g., in an IPv6 Routing Header) this might be an information (e.g., in an IPv6 Routing Header) this might be an
inappropriate or undesirable action. 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.
skipping to change at page 5, line 47 skipping to change at page 5, line 47
3.1. General Discussion 3.1. General Discussion
IPv6 [RFC8200] EHs allow for the extension of the IPv6 protocol. IPv6 [RFC8200] EHs allow for the extension of the IPv6 protocol.
Since both IPv6 EHs and upper-layer protocols share the same Since both IPv6 EHs and upper-layer protocols share the same
namespace ("Next Header" registry/namespace), [RFC7045] identifies namespace ("Next Header" registry/namespace), [RFC7045] identifies
which of the currently assigned Internet Protocol numbers identify which of the currently assigned Internet Protocol numbers identify
IPv6 EHs vs. upper-layer protocols. This document discusses the IPv6 EHs vs. upper-layer protocols. This document discusses the
filtering of packets based on the IPv6 EHs (as specified by filtering of packets based on the IPv6 EHs (as specified by
[RFC7045]) they contain. [RFC7045]) they contain.
NOTE: [RFC7112] specifies that non-fragmented IPv6 datagrams and NOTE: [RFC8200] specifies that non-fragmented IPv6 datagrams and
IPv6 First-Fragments MUST contain the entire IPv6 header chain IPv6 First-Fragments must contain the entire IPv6 header chain
[RFC7112]. Therefore, intermediate systems can enforce the [RFC7112]. Therefore, intermediate systems can enforce the
filtering policies discussed in this document, or resort to simply filtering policies discussed in this document, or resort to simply
discarding the offending packets when they fail to comply with the discarding the offending packets when they fail to comply with the
requirements in [RFC7112]. We note that, in order to implement requirements in [RFC8200]. We note that, in order to implement
filtering rules on the fast path, it may be necessary for the filtering rules on the fast path, it may be necessary for the
filtering device to limit the depth into the packet that can be filtering device to limit the depth into the packet that can be
inspected before giving up. In circumstances where there is such inspected before giving up. In circumstances where such a
a limitation, it is recommended that implementations discard limitation exists, it is recommended that implementations provide
packets if, when trying to determine whether to discard or permit a configuration option that specifies whether to discard packets
a packet, the aforementioned limit is encountered. if the aforementioned limit is encountered. Operators may then
determine according to their own circumstances how such packets
will be handled.
3.2. General Security Implications 3.2. General Security Implications
In some specific device architectures, IPv6 packets that contain IPv6 In some device architectures, IPv6 packets that contain IPv6 EHs can
EHs may cause the corresponding packets to be processed on the slow cause the corresponding packets to be processed on the slow path, and
path, and hence may be leveraged for the purpose of Denial of Service hence may be leveraged for the purpose of Denial of Service (DoS)
(DoS) attacks [I-D.gont-v6ops-ipv6-ehs-packet-drops] [Cisco-EH] attacks [I-D.ietf-v6ops-ipv6-ehs-packet-drops] [Cisco-EH]
[FW-Benchmark]. [FW-Benchmark].
Operators are urged to consider IPv6 EH filtering and IPv6 options Operators are urged to consider the IPv6 EH and IPv6 options handling
handling capabilities of different devices as they make deployment capabilities of their devices as they make deployment decisions in
decisions in future. 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.4.1 | | IPv6 Hop-by-Hop Options | Drop or Ignore | Section 3 |
| (Proto=0) | | | | (Proto=0) | | .4.1 |
+--------------------------+-----------------------+----------------+ +----------------------------+--------------------------+-----------+
| Routing Header for IPv6 | Drop only RTH0 and | Section 3.4.2 | | Routing Header for IPv6 | Drop only RHT0 and RHT1. | Section 3 |
| (Proto=43) | RTH1. Permit other RH | | | (Proto=43) | Permit other RH Types | .4.2 |
| | Types | | +----------------------------+--------------------------+-----------+
+--------------------------+-----------------------+----------------+ | Fragment Header for IPv6 | Permit | Section 3 |
| Fragment Header for IPv6 | Permit | Section 3.4.3 | | (Proto=44) | | .4.3 |
| (Proto=44) | | | +----------------------------+--------------------------+-----------+
+--------------------------+-----------------------+----------------+ | Encapsulating Security | Permit | Section 3 |
| Encapsulating Security | Permit | Section 3.4.4 | | Payload (Proto=50) | | .4.4 |
| Payload (Proto=50) | | | +----------------------------+--------------------------+-----------+
+--------------------------+-----------------------+----------------+ | Authentication Header | Permit | Section 3 |
| Authentication Header | Permit | Section 3.4.5 | | (Proto=51) | | .4.5 |
| (Proto=51) | | | +----------------------------+--------------------------+-----------+
+--------------------------+-----------------------+----------------+ | Destination Options for | Permit | Section 3 |
| Destination Options for | Permit | Section 3.4.6 | | IPv6 (Proto=60) | | .4.6 |
| IPv6 (Proto=60) | | | +----------------------------+--------------------------+-----------+
+--------------------------+-----------------------+----------------+ | Mobility Header | Permit | Section 3 |
| Mobility Header | Permit | Section 3.4.7 | | (Proto=135) | | .4.7 |
| (Proto=135) | | | +----------------------------+--------------------------+-----------+
+--------------------------+-----------------------+----------------+ | Host Identity Protocol | Permit | Section 3 |
| Host Identity Protocol | Permit | Section 3.4.8 | | (Proto=139) | | .4.8 |
| (Proto=139) | | | +----------------------------+--------------------------+-----------+
+--------------------------+-----------------------+----------------+ | Shim6 Protocol (Proto=140) | Permit | Section 3 |
| Shim6 Protocol | Permit | Section 3.4.9 | | | | .4.9 |
| (Proto=140) | | | +----------------------------+--------------------------+-----------+
+--------------------------+-----------------------+----------------+ | Use for experimentation | Drop | Section 3 |
| Use for experimentation | Drop | Section 3.4.10 | | and testing (Proto=253 and | | .4.10 |
| and testing (Proto=253 | | | | 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 with
Specific IPv6 Extension Headers 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: [RFC2460] required that all nodes examined and processed the NOTE: A previous revision of the IPv6 core specification, [RFC2460],
Hop-by-Hop Options header. However, even before the publication of originally required that all nodes examined and processed the Hop-by-
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] o Type 0x00: Pad1 [RFC8200]
skipping to change at page 9, line 18 skipping to change at page 9, line 14
o Type 0x9E: RFC3692-style Experiment [RFC4727] o Type 0x9E: RFC3692-style Experiment [RFC4727]
o Type 0xBE: RFC3692-style Experiment [RFC4727] o Type 0xBE: RFC3692-style Experiment [RFC4727]
o Type 0xDE: RFC3692-style Experiment [RFC4727] o Type 0xDE: RFC3692-style Experiment [RFC4727]
o Type 0xFE: RFC3692-style Experiment [RFC4727] o Type 0xFE: RFC3692-style Experiment [RFC4727]
3.4.1.3. Specific Security Implications 3.4.1.3. Specific Security Implications
Legacy nodes that may process this extencion header could be subject Legacy nodes that process this extension header might be subject to
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 traditional 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
Nodes implementing [RFC8200] would already ignore this extension Nodes implementing [RFC8200] would already ignore this extension
header unless explicitly required to process it. For legacy header unless explicitly required to process it. For legacy
([RFC2460] nodes, the recommended configuration for the processing of ([RFC2460]) nodes, the recommended configuration for the processing
these packets depends on the features and capabilities of the of these packets depends on the features and capabilities of the
underlying platform. On platforms that allow forwarding of packets underlying platform, the configuration of the platform, and also the
with HBH Options on the fast path, we recommend that packets with a deployment environment of the platform. On platforms that allow
HBH Options EH be forwarded as normal. Otherwise, on platforms in forwarding of packets with HBH Options on the fast path, we recommend
which processing of packets with a IPv6 HBH Options EH is carried out that packets with a HBH Options EH be forwarded as normal.
in the slow path, and an option is provided to rate-limit these Otherwise, on platforms in which processing of packets with a IPv6
packets, we recommend that this option be selected. Finally, when HBH Options EH is carried out in the slow path, and an option is
packets containing a HBH Options EH are processed in the slow-path, provided to rate-limit these packets, we recommend that this option
and the underlying platform does not have any mitigation options be selected. Finally, when packets containing a HBH Options EH are
available for attacks based on these packets, we recommend that such processed in the slow-path, and the underlying platform does not have
platforms discard packets containing IPv6 HBH Options EHs. any mitigation options available for attacks based on these packets,
we recommend that such platforms discard packets containing IPv6 HBH
Options EHs.
Finally, we note that, for obvious reasons, RPL (Routing Protocol for Finally, we note that, for obvious reasons, RPL (Routing Protocol for
Low-Power and Lossy Networks) [RFC6550] routers must not discard Low-Power and Lossy Networks) [RFC6550] routers must not discard
packets based on the presence of an IPv6 Hop-by-Hop Options EH. packets based on the presence of an IPv6 Hop-by-Hop Options EH.
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
skipping to change at page 10, line 30 skipping to change at page 10, line 30
specified: specified:
o Type 0: Source Route (DEPRECATED) [RFC2460] [RFC5095] o Type 0: Source Route (DEPRECATED) [RFC2460] [RFC5095]
o Type 1: Nimrod (DEPRECATED) o Type 1: Nimrod (DEPRECATED)
o Type 2: Type 2 Routing Header [RFC6275] o Type 2: Type 2 Routing Header [RFC6275]
o Type 3: RPL Source Route Header [RFC6554] o Type 3: RPL Source Route Header [RFC6554]
o Types 4-252: Unassigned o Type 4: Segment Routing Header (SRH) [RFC8754]
o Types 5-252: Unassigned
o Type 253: RFC3692-style Experiment 1 [RFC4727] o Type 253: RFC3692-style Experiment 1 [RFC4727]
o Type 254: RFC3692-style Experiment 2 [RFC4727] o Type 254: RFC3692-style Experiment 2 [RFC4727]
o Type 255: Reserved o 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]. [Biondi2007] and [RFC5095]. The security implications of RHT4 (SRH)
are discussed in [RFC8754].
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 RTH1 has no operational Blocking packets containing a RHT0 or RHT1 has no operational
implications, since both have been deprecated. However, blocking implications, since both have been deprecated. Blocking packets with
packets employing other routing header types will break the protocols a RHT4 (SRH) will break Segment Routing (SR) deployments, if the
that rely on them. 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 or
RHT1. Other routing header types should be permitted, as required by RHT1. Other routing header types should be permitted, as required by
[RFC7045]. [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
skipping to change at page 11, line 31 skipping to change at page 11, line 31
3.4.3.3. Specific Security Implications 3.4.3.3. Specific Security Implications
The security implications of the Fragment Header range from Denial of The security implications of the Fragment Header range from Denial of
Service attacks (e.g. based on flooding a target with IPv6 fragments) Service attacks (e.g. based on flooding a target with IPv6 fragments)
to information leakage attacks [RFC7739]. to information leakage attacks [RFC7739].
3.4.3.4. Operational and Interoperability Impact if Blocked 3.4.3.4. Operational and Interoperability Impact if Blocked
Blocking packets that contain a Fragment Header will break any Blocking packets that contain a Fragment Header will break any
protocol that may rely on fragmentation (e.g., the DNS [RFC1034]). protocol that may rely on fragmentation (e.g., the DNS [RFC1034]).
However, IP fragmentation is known to introduce fragility to Internet
communication [RFC8900].
3.4.3.5. Advice 3.4.3.5. Advice
Intermediate systems should permit packets that contain a Fragment Intermediate systems should permit packets that contain a Fragment
Header. Header.
3.4.4. Encapsulating Security Payload (Protocol Number=50) 3.4.4. Encapsulating Security Payload (Protocol Number=50)
3.4.4.1. Uses 3.4.4.1. Uses
skipping to change at page 16, line 21 skipping to change at page 16, line 29
The security implications of these EHs will depend on their specific The security implications of these EHs will depend on their specific
use. use.
3.4.10.4. Operational and Interoperability Impact if Blocked 3.4.10.4. Operational and Interoperability Impact if Blocked
For obvious reasons, discarding packets that contain these EHs limits For obvious reasons, discarding packets that contain these EHs limits
the ability to perform legitimate experiments across IPv6 routers. the ability to perform legitimate experiments across IPv6 routers.
3.4.10.5. Advice 3.4.10.5. Advice
Intermediate systems should discard packets containing these EHs. Operators should determine according to their own circumstances
Only in specific scenarios in which RFC3692-Style experiments are to whether to discard packets containing these EHs.
be performed should these EHs be permitted.
3.5. Advice on the Handling of Packets with Unknown IPv6 Extension 3.5. Advice on the Handling of Packets with Unknown IPv6 Extension
Headers Headers
We refer to IPv6 EHs that have not been assigned an Internet Protocol We refer to IPv6 EHs that have not been assigned an Internet Protocol
Number by IANA (and marked as such) in [IANA-PROTOCOLS] as "unknown Number by IANA (and marked as such) in [IANA-PROTOCOLS] as "unknown
IPv6 extension headers" ("unknown IPv6 EHs"). IPv6 extension headers" ("unknown IPv6 EHs").
3.5.1. Uses 3.5.1. Uses
New IPv6 EHs may be specified as part of future extensions to the New IPv6 EHs may be specified as part of future extensions to the
IPv6 protocol. IPv6 protocol.
Since IPv6 EHs and Upper-layer protocols employ the same namespace, Since IPv6 EHs and Upper-layer protocols employ the same namespace,
it is impossible to tell whether an unknown "Internet Protocol it is impossible to tell whether an unknown "Internet Protocol
Number" is being employed for an IPv6 EH or an Upper-Layer protocol. Number" is being employed for an IPv6 EH or an Upper-Layer protocol.
3.5.2. Specification 3.5.2. Specification
The processing of unknown IPv6 EHs is specified in [RFC8200] and The processing of unknown IPv6 EHs is specified in [RFC7045].
[RFC7045].
3.5.3. Specific Security Implications 3.5.3. Specific Security Implications
For obvious reasons, it is impossible to determine specific security For obvious reasons, it is impossible to determine specific security
implications of unknown IPv6 EHs. However, from security standpoint, implications of unknown IPv6 EHs.
a device should discard IPv6 extension headers for which the security
implications cannot be determined. We note that this policy is
allowed by [RFC7045].
3.5.4. Operational and Interoperability Impact if Blocked 3.5.4. Operational and Interoperability Impact if Blocked
As noted in [RFC7045], discarding unknown IPv6 EHs may slow down the As noted in [RFC7045], discarding unknown IPv6 EHs may slow down the
deployment of new IPv6 EHs and transport protocols. The deployment of new IPv6 EHs and transport protocols. The
corresponding IANA registry ([IANA-PROTOCOLS]) should be monitored corresponding IANA registry ([IANA-PROTOCOLS]) should be monitored
such that filtering rules are updated as new IPv6 EHs are such that filtering rules are updated as new IPv6 EHs are
standardized. standardized.
We note that since IPv6 EHs and upper-layer protocols share the same We note that since IPv6 EHs and upper-layer protocols share the same
numbering space, discarding unknown IPv6 EHs may result in packets numbering space, discarding unknown IPv6 EHs may result in packets
encapsulating unknown upper-layer protocols being discarded. encapsulating unknown upper-layer protocols being discarded.
3.5.5. Advice 3.5.5. Advice
Intermediate systems should discard packets containing unknown IPv6 Operators should determine according to their own circumstances
EHs. whether to discard packets containing unknown IPv6 EHs.
4. IPv6 Options 4. IPv6 Options
4.1. General Discussion 4.1. General Discussion
The following subsections describe specific security implications of The following subsections describe specific security implications of
different IPv6 options, and provide advice regarding filtering different IPv6 options, and provide advice regarding filtering
packets that contain such options. packets that contain such options.
4.2. General Security Implications of IPv6 Options 4.2. General Security Implications of IPv6 Options
skipping to change at page 18, line 23 skipping to change at page 18, line 25
This option is specified in [RFC8200]. This option is specified in [RFC8200].
4.3.1.3. Specific Security Implications 4.3.1.3. Specific Security Implications
None. None.
4.3.1.4. Operational and Interoperability Impact if Blocked 4.3.1.4. Operational and Interoperability Impact if Blocked
Discarding packets that contain this option would potentially break Discarding packets that contain this option would potentially break
any protocol that relies on IPv6 EHs. any protocol that relies on IPv6 options.
4.3.1.5. Advice 4.3.1.5. Advice
Intermediate systems should not discard packets based on the presence Intermediate systems should not discard packets based on the presence
of this option. of this option.
4.3.2. PadN (Type=0x01) 4.3.2. PadN (Type=0x01)
4.3.2.1. Uses 4.3.2.1. Uses
skipping to change at page 18, line 49 skipping to change at page 19, line 8
This option is specified in [RFC8200]. This option is specified in [RFC8200].
4.3.2.3. Specific Security Implications 4.3.2.3. Specific Security Implications
Because of the possible size of this option, it could be leveraged as Because of the possible size of this option, it could be leveraged as
a large-bandwidth covert channel. a large-bandwidth covert channel.
4.3.2.4. Operational and Interoperability Impact if Blocked 4.3.2.4. Operational and Interoperability Impact if Blocked
Discarding packets that contain this option would potentially break Discarding packets that contain this option would potentially break
any protocol that relies on IPv6 EHs. any protocol that relies on IPv6 options.
4.3.2.5. Advice 4.3.2.5. Advice
Intermediate systems should not discard IPv6 packets based on the Intermediate systems should not discard IPv6 packets based on the
presence of this option. presence of this option.
4.3.3. Jumbo Payload (Type=0XC2) 4.3.3. Jumbo Payload (Type=0XC2)
4.3.3.1. Uses 4.3.3.1. Uses
skipping to change at page 21, line 47 skipping to change at page 22, line 7
by the handling device, this option could be leveraged for performing by the handling device, this option could be leveraged for performing
DoS attacks. DoS attacks.
4.3.7.4. Operational and Interoperability Impact if Blocked 4.3.7.4. Operational and Interoperability Impact if Blocked
Discarding packets that contain this option would break RSVP and Discarding packets that contain this option would break RSVP and
multicast deployments. multicast deployments.
4.3.7.5. Advice 4.3.7.5. Advice
Intermediate systems should discard packets that contain this option. Packets containing this option should be permitted in environments
Only in specific environments where support for RSVP, multicast where support for RSVP, multicast routing, or similar protocols is
routing, or similar protocols is desired, should this option be desired.
permitted.
4.3.8. Quick-Start (Type=0x26) 4.3.8. Quick-Start (Type=0x26)
4.3.8.1. Uses 4.3.8.1. Uses
This IP Option is used in the specification of Quick-Start for TCP This IP Option is used in the specification of Quick-Start for TCP
and IP, which is an experimental mechanism that allows transport and IP, which is an experimental mechanism that allows transport
protocols, in cooperation with routers, to determine an allowed protocols, in cooperation with routers, to determine an allowed
sending rate at the start and, at times, in the middle of a data sending rate at the start and, at times, in the middle of a data
transfer (e.g., after an idle period) [RFC4782]. transfer (e.g., after an idle period) [RFC4782].
skipping to change at page 23, line 40 skipping to change at page 23, line 45
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.
4.3.9.5. Advice 4.3.9.5. Advice
Intermediate systems that do not operate in Multi-Level Secure (MLS) Recommendations for handling the CALIPSO option depend on the
networking environments should discard packets that contain this deployment environment, rather than whether an intermediate system
option. happens to be deployed as a transit device (e.g., IPv6 transit
router).
Explicit configuration is the only method via which an intermediate
system can know whether or not that particular intermediate system
has been deployed within a Multi-Level Secure (MLS) environment. In
many cases, ordinary commercial intermediate systems (e.g., IPv6
routers and firewalls) are the majority of the deployed intermediate
systems inside an MLS network environment.
For Intermediate systems that DO NOT implement RFC-5570, there should
be a configuration option to EITHER (a) drop packets containing the
CALIPSO option OR (b) to ignore the presence of the CALIPSO option
and forward the packets normally. In non-MLS environments, such
intermediate systems should have this configuration option set to (a)
above. In MLS environments, such intermediate systems should have
this option set to (b) above. The default setting for this
configuration option should be set to (a) above, because MLS
environments are much less common than non-MLS environments.
For Intermediate systems that DO implement RFC-5570, there should be
configuration options (a) and (b) from the preceding paragraph and
also a third configuration option (c) to process packets containing a
CALIPSO option as per RFC-5570. When deployed in non-MLS
environments, such intermediate systems should have this
configuration option set to (a) above. When deployed in MLS
environments, such intermediate systems should have this set to (c).
The default setting for this configuration option MAY be set to (a)
above, because MLS environments are much less common than non-MLS
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
This option is employed in the (experimental) Simplified Multicast This option is employed in the (experimental) Simplified Multicast
Forwarding (SMF) for unique packet identification for IPv6 I-DPD, and Forwarding (SMF) for unique packet identification for IPv6 I-DPD, and
as a mechanism to guarantee non-collision of hash values for as a mechanism to guarantee non-collision of hash values for
different packets when H-DPD is used. different packets when H-DPD is used.
4.3.10.2. Specification 4.3.10.2. Specification
This option is specified in [RFC6621]. This option is specified in [RFC6621].
4.3.10.3. Specific Security Implications 4.3.10.3. Specific Security Implications
None. The use of identifiers is subject to the security and privacy None. The use of transient numeric identifiers is subject to the
considerations discussed in [I-D.gont-predictable-numeric-ids]. security and privacy considerations discussed in
[I-D.irtf-pearg-numeric-ids-generation].
4.3.10.4. Operational and Interoperability Impact if Blocked 4.3.10.4. Operational and Interoperability Impact if Blocked
Dropping packets containing this option within a MANET domain would Dropping packets containing this option within a MANET domain would
break SMF. However, dropping such packets at the border of such break SMF. However, dropping such packets at the border of such
domain would have no negative impact. domain would have no negative impact.
4.3.10.5. Advice 4.3.10.5. Advice
Intermediate system should discard packets that contain this option. Intermediate systems that are not within a MANET domain should
discard packets that contain this option.
4.3.11. Home Address (Type=0xC9) 4.3.11. Home Address (Type=0xC9)
4.3.11.1. Uses 4.3.11.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.3.11.2. Specification 4.3.11.2. Specification
skipping to change at page 28, line 16 skipping to change at page 29, line 12
This option is specified in [RFC6971]. This option is specified in [RFC6971].
4.3.17.3. Specific Security Implications 4.3.17.3. Specific Security Implications
Those specified in [RFC6971]. Those specified in [RFC6971].
4.3.17.4. Operational and Interoperability Impact if Blocked 4.3.17.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, droping such packets at the is running DFF would break DFF. However, dropping such packets at
border of such domains will have no security implications. the border of such domains will have no security implications.
4.3.17.5. Advice 4.3.17.5. Advice
Intermediate systems that do not operate within a routing domain that Intermediate systems that do not operate within a routing domain that
is running DFF should discard packets containing this option. is running DFF should discard packets containing this option.
4.3.18. RFC3692-style Experiment (Types = 0x1E, 0x3E, 0x5E, 0x7E, 0x9E, 4.3.18. RFC3692-style Experiment (Types = 0x1E, 0x3E, 0x5E, 0x7E, 0x9E,
0xBE, 0xDE, 0xFE) 0xBE, 0xDE, 0xFE)
4.3.18.1. Uses 4.3.18.1. Uses
skipping to change at page 29, line 7 skipping to change at page 29, line 48
these options. these options.
4.3.18.4. Operational and Interoperability Impact if Blocked 4.3.18.4. Operational and Interoperability Impact if Blocked
For obvious reasons, discarding packets that contain these options For obvious reasons, discarding packets that contain these options
limits the ability to perform legitimate experiments across IPv6 limits the ability to perform legitimate experiments across IPv6
routers. routers.
4.3.18.5. Advice 4.3.18.5. Advice
Intermediate systems should discard packets that contain these Operators should determine according to their own circumstances
options. Only in specific environments where RFC3692-style whether to discard packets containing these IPv6 options.
experiments are meant to be performed should these options be
permitted.
4.4. Advice on the handling of Packets with Unknown IPv6 Options 4.4. Advice on the handling of Packets with Unknown IPv6 Options
We refer to IPv6 options that have not been assigned an IPv6 option We refer to IPv6 options that have not been assigned an IPv6 option
type in the corresponding registry ([IANA-IPV6-PARAM]) as "unknown type in the corresponding registry ([IANA-IPV6-PARAM]) as "unknown
IPv6 options". IPv6 options".
4.4.1. Uses 4.4.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.
skipping to change at page 29, line 41 skipping to change at page 30, line 34
4.4.4. Operational and Interoperability Impact if Blocked 4.4.4. Operational and Interoperability Impact if Blocked
Discarding unknown IPv6 options may slow down the deployment of new Discarding unknown IPv6 options may slow down the deployment of new
IPv6 options. As noted in [draft-gont-6man-ipv6-opt-transmit], the IPv6 options. As noted in [draft-gont-6man-ipv6-opt-transmit], the
corresponding IANA registry ([IANA-IPV6-PARAM] should be monitored corresponding IANA registry ([IANA-IPV6-PARAM] should be monitored
such that IPv6 option filtering rules are updated as new IPv6 options such that IPv6 option filtering rules are updated as new IPv6 options
are standardized. are standardized.
4.4.5. Advice 4.4.5. Advice
Enterprise intermediate systems that process the contents of IPv6 EHs Operators should determine according to their own circumstances
should discard packets that contain unknown options. Other whether to discard packets containing unknown IPv6 options.
intermediate systems that process the contents of IPv6 EHs should
permit packets that contain unknown options.
5. IANA Considerations 5. IANA Considerations
This document has no actions for IANA. This document has no actions for IANA.
6. Security Considerations 6. Privacy Considerations
There are no privacy considerations associated with this document.
7. Security Considerations
This document provides advice on the filtering of IPv6 packets that This document provides advice on the filtering of IPv6 packets that
contain IPv6 EHs (and possibly IPv6 options) at IPv6 transit routers. contain IPv6 EHs (and possibly IPv6 options) at IPv6 transit routers.
It is meant to improve the current situation of widespread dropping It is meant to improve the current situation of widespread dropping
of such IPv6 packets in those cases where the drops result from of such IPv6 packets in those cases where the drops result from
improper configuration defaults, or inappropriate advice in this improper configuration defaults, or inappropriate advice in this
area. area.
7. 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, Mike Heard, order) Mikael Abrahamsson, Brian Carpenter, Darren Dukes, David
Bob Hinden, Jen Linkova, Carlos Pignataro, Maria Ines Robles, Donald Farmer, Mike Heard, Bob Hinden, Christian Huitema, Jen Linkova,
Smith, Pascal Thubert, Ole Troan, Gunter Van De Velde, and Eric Carlos Pignataro, Maria Ines Robles, Donald Smith, Pascal Thubert,
Vyncke, for providing valuable comments on earlier versions of this Ole Troan, Gunter Van De Velde, and Eric Vyncke, for providing
document. 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.
Fernando Gont would like to thank Eric Vyncke for his guidance. The authors would like to thank Eric Vyncke for his guidance during
the publication process of this document.
8. References Fernando would also like to thank Brian Carpenter and Ran Atkinson
who, over the years, have answered many questions and provided
valuable comments that have benefited his protocol-related work
(including the present document).
8.1. Normative References 9. References
[draft-gont-6man-ipv6-opt-transmit] 9.1. Normative References
Gont, F., Liu, W., and R. Bonica, "Transmission and
Processing of IPv6 Options", IETF Internet Draft, work in
progress, August 2014.
[I-D.ietf-roll-useofrplinfo] [I-D.ietf-roll-useofrplinfo]
Robles, I., Richardson, M., and P. Thubert, "When to use Robles, I., Richardson, M., and P. Thubert, "Using RPI
RFC 6553, 6554 and IPv6-in-IPv6", draft-ietf-roll- Option Type, Routing Header for Source Routes and IPv6-in-
useofrplinfo-23 (work in progress), May 2018. IPv6 encapsulation in the RPL Data Plane", draft-ietf-
roll-useofrplinfo-44 (work in progress), January 2021.
[RFC1034] Mockapetris, P., "Domain names - concepts and facilities", [RFC1034] Mockapetris, P., "Domain names - concepts and facilities",
STD 13, RFC 1034, DOI 10.17487/RFC1034, November 1987, STD 13, RFC 1034, DOI 10.17487/RFC1034, November 1987,
<https://www.rfc-editor.org/info/rfc1034>. <https://www.rfc-editor.org/info/rfc1034>.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997, DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/info/rfc2119>. <https://www.rfc-editor.org/info/rfc2119>.
skipping to change at page 31, line 44 skipping to change at page 32, line 39
<https://www.rfc-editor.org/info/rfc3692>. <https://www.rfc-editor.org/info/rfc3692>.
[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>.
[RFC4304] Kent, S., "Extended Sequence Number (ESN) Addendum to
IPsec Domain of Interpretation (DOI) for Internet Security
Association and Key Management Protocol (ISAKMP)",
RFC 4304, DOI 10.17487/RFC4304, December 2005,
<https://www.rfc-editor.org/info/rfc4304>.
[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,
DOI 10.17487/RFC4727, November 2006, DOI 10.17487/RFC4727, November 2006,
<https://www.rfc-editor.org/info/rfc4727>. <https://www.rfc-editor.org/info/rfc4727>.
[RFC4782] Floyd, S., Allman, M., Jain, A., and P. Sarolahti, "Quick- [RFC4782] Floyd, S., Allman, M., Jain, A., and P. Sarolahti, "Quick-
Start for TCP and IP", RFC 4782, DOI 10.17487/RFC4782, Start for TCP and IP", RFC 4782, DOI 10.17487/RFC4782,
January 2007, <https://www.rfc-editor.org/info/rfc4782>. January 2007, <https://www.rfc-editor.org/info/rfc4782>.
[RFC5095] Abley, J., Savola, P., and G. Neville-Neil, "Deprecation [RFC5095] Abley, J., Savola, P., and G. Neville-Neil, "Deprecation
skipping to change at page 33, line 49 skipping to change at page 34, line 39
[RFC7112] Gont, F., Manral, V., and R. Bonica, "Implications of [RFC7112] Gont, F., Manral, V., and R. Bonica, "Implications of
Oversized IPv6 Header Chains", RFC 7112, Oversized IPv6 Header Chains", RFC 7112,
DOI 10.17487/RFC7112, January 2014, DOI 10.17487/RFC7112, January 2014,
<https://www.rfc-editor.org/info/rfc7112>. <https://www.rfc-editor.org/info/rfc7112>.
[RFC7731] Hui, J. and R. Kelsey, "Multicast Protocol for Low-Power [RFC7731] Hui, J. and R. Kelsey, "Multicast Protocol for Low-Power
and Lossy Networks (MPL)", RFC 7731, DOI 10.17487/RFC7731, and Lossy Networks (MPL)", RFC 7731, DOI 10.17487/RFC7731,
February 2016, <https://www.rfc-editor.org/info/rfc7731>. February 2016, <https://www.rfc-editor.org/info/rfc7731>.
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
May 2017, <https://www.rfc-editor.org/info/rfc8174>.
[RFC8200] Deering, S. and R. Hinden, "Internet Protocol, Version 6 [RFC8200] Deering, S. and R. Hinden, "Internet Protocol, Version 6
(IPv6) Specification", STD 86, RFC 8200, (IPv6) Specification", STD 86, RFC 8200,
DOI 10.17487/RFC8200, July 2017, DOI 10.17487/RFC8200, July 2017,
<https://www.rfc-editor.org/info/rfc8200>. <https://www.rfc-editor.org/info/rfc8200>.
8.2. Informative References [RFC8754] Filsfils, C., Ed., Dukes, D., Ed., Previdi, S., Leddy, J.,
Matsushima, S., and D. Voyer, "IPv6 Segment Routing Header
(SRH)", RFC 8754, DOI 10.17487/RFC8754, March 2020,
<https://www.rfc-editor.org/info/rfc8754>.
[RFC8900] Bonica, R., Baker, F., Huston, G., Hinden, R., Troan, O.,
and F. Gont, "IP Fragmentation Considered Fragile",
BCP 230, RFC 8900, DOI 10.17487/RFC8900, September 2020,
<https://www.rfc-editor.org/info/rfc8900>.
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/ <http://www.cisco.com/en/US/technologies/tk648/tk872/
technologies_white_paper0900aecd8054d37d.pdf>. technologies_white_paper0900aecd8054d37d.pdf>.
[draft-gont-6man-ipv6-opt-transmit]
Gont, F., Liu, W., and R. Bonica, "Transmission and
Processing of IPv6 Options", IETF Internet Draft, work in
progress, August 2014.
[draft-ietf-nimrod-eid] [draft-ietf-nimrod-eid]
Lynn, C., "Endpoint Identifier Destination Option", IETF Lynn, C., "Endpoint Identifier Destination Option", IETF
Internet Draft, draft-ietf-nimrod-eid-00.txt, November Internet Draft, draft-ietf-nimrod-eid-00.txt, November
1995. 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- <http://www.ipv6hackers.org/meetings/ipv6-hackers-1/zack-
ipv6hackers1-firewall-security-assessment-and- ipv6hackers1-firewall-security-assessment-and-
benchmarking.pdf>. benchmarking.pdf>.
[I-D.gont-predictable-numeric-ids]
Gont, F. and I. Arce, "Security and Privacy Implications
of Numeric Identifiers Employed in Network Protocols",
draft-gont-predictable-numeric-ids-02 (work in progress),
February 2018.
[I-D.gont-v6ops-ipv6-ehs-packet-drops]
Gont, F., Hilliard, N., Doering, G., (Will), S., and W.
Kumari, "Operational Implications of IPv6 Packets with
Extension Headers", draft-gont-v6ops-ipv6-ehs-packet-
drops-03 (work in progress), March 2016.
[I-D.ietf-6man-hbh-header-handling] [I-D.ietf-6man-hbh-header-handling]
Baker, F. and R. Bonica, "IPv6 Hop-by-Hop Options Baker, F. and R. Bonica, "IPv6 Hop-by-Hop Options
Extension Header", draft-ietf-6man-hbh-header-handling-03 Extension Header", draft-ietf-6man-hbh-header-handling-03
(work in progress), March 2016. (work in progress), March 2016.
[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-03 (work in progress), January 2021.
[I-D.irtf-pearg-numeric-ids-generation]
Gont, F. and I. Arce, "On the Generation of Transient
Numeric Identifiers", draft-irtf-pearg-numeric-ids-
generation-06 (work in progress), January 2021.
[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/ <http://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, <http://www.iana.org/assignments/protocol-numbers/
protocol-numbers.xhtml>. protocol-numbers.xhtml>.
skipping to change at page 35, line 41 skipping to change at page 37, line 8
[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>.
Authors' Addresses Authors' Addresses
Fernando Gont Fernando Gont
UTN-FRH / SI6 Networks SI6 Networks
Evaristo Carriego 2644 Segurola y Habana 4310, 7mo Piso
Haedo, Provincia de Buenos Aires 1706 Villa Devoto, Ciudad Autonoma de Buenos Aires
Argentina Argentina
Phone: +54 11 4650 8472
Email: fgont@si6networks.com Email: fgont@si6networks.com
URI: http://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. 67 change blocks. 
208 lines changed or deleted 265 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/