draft-ietf-opsec-ipv6-eh-filtering-03.txt   draft-ietf-opsec-ipv6-eh-filtering-04.txt 
opsec F. Gont opsec F. Gont
Internet-Draft UTN-FRH / SI6 Networks Internet-Draft UTN-FRH / SI6 Networks
Intended status: Informational W. Liu Intended status: Informational W. Liu
Expires: January 4, 2018 Huawei Technologies Expires: May 3, 2018 Huawei Technologies
R. Bonica R. Bonica
Juniper Networks Juniper Networks
July 3, 2017 October 30, 2017
Recommendations on the Filtering of IPv6 Packets Containing IPv6 Recommendations on the Filtering of IPv6 Packets Containing IPv6
Extension Headers Extension Headers
draft-ietf-opsec-ipv6-eh-filtering-03 draft-ietf-opsec-ipv6-eh-filtering-04
Abstract Abstract
It is common operator practice to mitigate security risks by It is common operator practice to mitigate security risks by
enforcing appropriate packet filtering. This document analyzes both enforcing appropriate packet filtering. This document analyzes both
the general security implications of IPv6 Extension Headers and the the general security implications of IPv6 Extension Headers and the
specific security implications of each Extension Header and Option specific security implications of each Extension Header and Option
type. Additionally, it discusses the operational and type. Additionally, it discusses the operational and
interoperability implications of discarding packets based on the IPv6 interoperability implications of discarding packets based on the IPv6
Extension Headers and IPv6 options they contain. Finally, it Extension Headers and IPv6 options they contain. Finally, it
provides advice on the filtering of such IPv6 packets at transit provides advice on the filtering of such IPv6 packets at transit
routers, for those cases in which such filtering is deemed as routers for traffic *not* directed to them, for those cases in which
necessary. 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 http://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 4, 2018. This Internet-Draft will expire on May 3, 2018.
Copyright Notice Copyright Notice
Copyright (c) 2017 IETF Trust and the persons identified as the Copyright (c) 2017 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
(http://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 . . . . . . 4 2. Terminology and Conventions Used in This Document . . . . . . 4
2.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 4 2.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 4
2.2. Conventions . . . . . . . . . . . . . . . . . . . . . . . 4 2.2. Applicability Statement . . . . . . . . . . . . . . . . . 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
skipping to change at page 4, line 25 skipping to change at page 4, line 25
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", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [RFC2119]. document are to be interpreted as described in [RFC2119].
2.2. Conventions 2.2. Applicability Statement
This document provides advice on the filtering of IPv6 packets with
EHs at transit routers for traffic *not* explicitly destined to such
transit routers, for those cases in which such filtering is deemed as
necessary.
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 (from [RFC7045]),
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.
skipping to change at page 5, line 30 skipping to change at page 5, line 39
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
refer to the action as "discard" without specifying whether the refer to the action as "discard" without specifying whether the
sender is signaled of the packet drop. sender is signaled of the packet drop.
3. IPv6 Extension Headers 3. IPv6 Extension Headers
3.1. General Discussion 3.1. General Discussion
IPv6 [RFC2460] 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: [RFC7112] 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
skipping to change at page 7, line 51 skipping to change at page 7, line 51
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 should 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
if explicitly configured to do so.
NOTE: [RFC2460] 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
ignoring this header unless explicitly configured to examine it.
3.4.1.2. Specification 3.4.1.2. Specification
This EH is specified in [RFC2460], and its processing rules have been This EH is specified in [RFC8200]. At the time of this writing, the
updated by [RFC7045]. At the time of this writing, the following following options have been specified for the Hop-by-Hop Options EH:
options have been specified for the Hop-by-Hop Options EH:
o Type 0x00: Pad1 [RFC2460] o Type 0x00: Pad1 [RFC8200]
o Type 0x01: PadN [RFC2460] o Type 0x01: PadN [RFC8200]
o Type 0x05: Router Alert [RFC2711] o Type 0x05: Router Alert [RFC2711]
o Type 0x07: CALIPSO [RFC5570] o Type 0x07: CALIPSO [RFC5570]
o Type 0x08: SMF_DPD [RFC6621] o Type 0x08: SMF_DPD [RFC6621]
o Type 0x26: Quick-Start [RFC4782] o Type 0x26: Quick-Start [RFC4782]
o Type 0x4D: (Deprecated) o Type 0x4D: (Deprecated)
skipping to change at page 8, line 45 skipping to change at page 9, line 4
o Type 0x1E: RFC3692-style Experiment [RFC4727] o Type 0x1E: RFC3692-style Experiment [RFC4727]
o Type 0x3E: RFC3692-style Experiment [RFC4727] o Type 0x3E: RFC3692-style Experiment [RFC4727]
o Type 0x5E: RFC3692-style Experiment [RFC4727] o Type 0x5E: RFC3692-style Experiment [RFC4727]
o Type 0x7E: RFC3692-style Experiment [RFC4727] o Type 0x7E: RFC3692-style Experiment [RFC4727]
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
Since this EH is required to be processed by all intermediate-systems Legacy nodes that may process this extencion header could be subject
en route, it can be leveraged to perform Denial of Service attacks to Denial of Service attacks.
against the network infrastructure.
NOTE: Ongoing work essentially aims at requiring the Hop-by-Hop NOTE: While [RFC8200] has removed this requirement, the deployed base
Option EH to be processed only in cases where the intermediate node may still reflect the traditional behavior for a while, and hence the
is making use of any functionality provided by such header (see
[I-D.ietf-6man-hbh-header-handling]). However, the deployed base is
likely to 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
The recommended configuration for the processing of these packets Nodes implementing [RFC8200] would already ignore this extension
depends on the features and capabilities of the underlying platform. header unless explicitly required to process it. For legacy
On platforms that allow forwarding of packets with HBH Options on the ([RFC2460] nodes, the recommended configuration for the processing of
fast path, we recommend that packets with a HBH Options EH be these packets depends on the features and capabilities of the
forwarded as normal (for instance, [RFC7045] allows for underlying platform. On platforms that allow forwarding of packets
implementations to ignore the HBH Options EH when forwarding with HBH Options on the fast path, we recommend that packets with a
packets). Otherwise, on platforms in which processing of packets HBH Options EH be forwarded as normal. Otherwise, on platforms in
with a IPv6 HBH Options EH is carried out in the slow path, and an which processing of packets with a IPv6 HBH Options EH is carried out
option is provided to rate-limit these packets, we recommend that in the slow path, and an option is provided to rate-limit these
this option be selected. Finally, when packets containing a HBH packets, we recommend that this option be selected. Finally, when
Options EH are processed in the slow-path, and the underlying packets containing a HBH Options EH are processed in the slow-path,
platform does not have any mitigation options available for attacks and the underlying platform does not have any mitigation options
based on these packets, we recommend that such platforms discard available for attacks based on these packets, we recommend that such
packets containing IPv6 HBH Options EHs. 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
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 [RFC2460]. [RFC2460] originally specified This EH is specified in [RFC8200]. [RFC2460] had originally
the Routing Header Type 0, which has been later obsoleted by specified the Routing Header Type 0, which was later obsoleted by
[RFC5095]. [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] 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]
skipping to change at page 11, line 4 skipping to change at page 11, line 6
implications. However, blocking packets employing other routing implications. However, blocking packets employing other routing
header types will break the protocols that rely on them. header types will break the protocols that rely on them.
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. RHT2 and RHT3 should be permitted, as required by [RFC7045]. RHT1. RHT2 and RHT3 should be permitted, as required by [RFC7045].
Other routing header types should be discarded. Other routing header types should be discarded.
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 [RFC2460]. This EH is specified in [RFC8200].
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
skipping to change at page 12, line 46 skipping to change at page 12, line 46
3.4.6. Destination Options for IPv6 (Protocol Number=60) 3.4.6. Destination Options for IPv6 (Protocol Number=60)
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 [RFC2460]. 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 [RFC2460] o Type 0x00: Pad1 [RFC8200]
o Type 0x01: PadN [RFC2460] o Type 0x01: PadN [RFC8200]
o Type 0x04: Tunnel Encapsulation Limit [RFC2473] o Type 0x04: Tunnel Encapsulation Limit [RFC2473]
o Type 0x4D: (Deprecated) o Type 0x4D: (Deprecated)
o Type 0xC9: Home Address [RFC6275] o Type 0xC9: Home Address [RFC6275]
o Type 0x8A: Endpoint Identification (Deprecated) o Type 0x8A: Endpoint Identification (Deprecated)
[draft-ietf-nimrod-eid] [draft-ietf-nimrod-eid]
o Type 0x8B: ILNP Nonce [RFC6744] o Type 0x8B: ILNP Nonce [RFC6744]
skipping to change at page 16, line 39 skipping to change at page 16, line 39
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 [RFC2460] and The processing of unknown IPv6 EHs is specified in [RFC8200] and
[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. However, from security standpoint,
a device should discard IPv6 extension headers for which the security a device should discard IPv6 extension headers for which the security
implications cannot be determined. We note that this policy is implications cannot be determined. We note that this policy is
allowed by [RFC7045]. allowed by [RFC7045].
skipping to change at page 18, line 14 skipping to change at page 18, line 14
4.3.1. Pad1 (Type=0x00) 4.3.1. Pad1 (Type=0x00)
4.3.1.1. Uses 4.3.1.1. Uses
This option is used when necessary to align subsequent options and to This option is used when necessary to align subsequent options and to
pad out the containing header to a multiple of 8 octets in length. pad out the containing header to a multiple of 8 octets in length.
4.3.1.2. Specification 4.3.1.2. Specification
This option is specified in [RFC2460]. 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 EHs.
skipping to change at page 18, line 39 skipping to change at page 18, line 39
4.3.2. PadN (Type=0x01) 4.3.2. PadN (Type=0x01)
4.3.2.1. Uses 4.3.2.1. Uses
This option is used when necessary to align subsequent options and to This option is used when necessary to align subsequent options and to
pad out the containing header to a multiple of 8 octets in length. pad out the containing header to a multiple of 8 octets in length.
4.3.2.2. Specification 4.3.2.2. Specification
This option is specified in [RFC2460]. 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 EHs.
skipping to change at page 28, line 35 skipping to change at page 28, line 35
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.
4.4.2. Specification 4.4.2. Specification
The processing of unknown IPv6 options is specified in [RFC2460]. The processing of unknown IPv6 options is specified in [RFC8200].
4.4.3. Specific Security Implications 4.4.3. Specific Security Implications
For obvious reasons, it is impossible to determine specific security For obvious reasons, it is impossible to determine specific security
implications of unknown IPv6 options. implications of unknown IPv6 options.
4.4.4. Operational and Interoperability Impact if Blocked 4.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
skipping to change at page 29, line 28 skipping to change at page 29, line 28
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 7. Acknowledgements
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, Mike Heard, Jen Linkova, order) Mikael Abrahamsson, Brian Carpenter, Mike Heard, Bob Hinden,
Carlos Pignataro, Donald Smith, Gunter Van De Velde, and Erick Jen Linkova, Carlos Pignataro, Donald Smith, Ole Troan, Gunter Van De
Vyncke, for providing valuable comments on earlier versions of this Velde, and Eric Vyncke, for providing valuable comments on earlier
document. versions of this document.
This document borrows some text an analysis from [RFC7126], authored This document borrows some text an analysis from [RFC7126], authored
by Fernando Gont, Randall Atkinson, and Carlos Pignataro. by Fernando Gont, Randall Atkinson, and Carlos Pignataro.
8. References 8. References
8.1. Normative References 8.1. Normative References
[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.
[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,
<http://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,
<http://www.rfc-editor.org/info/rfc2119>. <https://www.rfc-editor.org/info/rfc2119>.
[RFC2205] Braden, R., Ed., Zhang, L., Berson, S., Herzog, S., and S. [RFC2205] Braden, R., Ed., Zhang, L., Berson, S., Herzog, S., and S.
Jamin, "Resource ReSerVation Protocol (RSVP) -- Version 1 Jamin, "Resource ReSerVation Protocol (RSVP) -- Version 1
Functional Specification", RFC 2205, DOI 10.17487/RFC2205, Functional Specification", RFC 2205, DOI 10.17487/RFC2205,
September 1997, <http://www.rfc-editor.org/info/rfc2205>. September 1997, <https://www.rfc-editor.org/info/rfc2205>.
[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, <http://www.rfc-editor.org/info/rfc2460>. December 1998, <https://www.rfc-editor.org/info/rfc2460>.
[RFC2473] Conta, A. and S. Deering, "Generic Packet Tunneling in [RFC2473] Conta, A. and S. Deering, "Generic Packet Tunneling in
IPv6 Specification", RFC 2473, DOI 10.17487/RFC2473, IPv6 Specification", RFC 2473, DOI 10.17487/RFC2473,
December 1998, <http://www.rfc-editor.org/info/rfc2473>. December 1998, <https://www.rfc-editor.org/info/rfc2473>.
[RFC2675] Borman, D., Deering, S., and R. Hinden, "IPv6 Jumbograms", [RFC2675] Borman, D., Deering, S., and R. Hinden, "IPv6 Jumbograms",
RFC 2675, DOI 10.17487/RFC2675, August 1999, RFC 2675, DOI 10.17487/RFC2675, August 1999,
<http://www.rfc-editor.org/info/rfc2675>. <https://www.rfc-editor.org/info/rfc2675>.
[RFC2710] Deering, S., Fenner, W., and B. Haberman, "Multicast [RFC2710] Deering, S., Fenner, W., and B. Haberman, "Multicast
Listener Discovery (MLD) for IPv6", RFC 2710, Listener Discovery (MLD) for IPv6", RFC 2710,
DOI 10.17487/RFC2710, October 1999, DOI 10.17487/RFC2710, October 1999,
<http://www.rfc-editor.org/info/rfc2710>. <https://www.rfc-editor.org/info/rfc2710>.
[RFC2711] Partridge, C. and A. Jackson, "IPv6 Router Alert Option", [RFC2711] Partridge, C. and A. Jackson, "IPv6 Router Alert Option",
RFC 2711, DOI 10.17487/RFC2711, October 1999, RFC 2711, DOI 10.17487/RFC2711, October 1999,
<http://www.rfc-editor.org/info/rfc2711>. <https://www.rfc-editor.org/info/rfc2711>.
[RFC3692] Narten, T., "Assigning Experimental and Testing Numbers [RFC3692] Narten, T., "Assigning Experimental and Testing Numbers
Considered Useful", BCP 82, RFC 3692, Considered Useful", BCP 82, RFC 3692,
DOI 10.17487/RFC3692, January 2004, DOI 10.17487/RFC3692, January 2004,
<http://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,
<http://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,
<http://www.rfc-editor.org/info/rfc4303>. <https://www.rfc-editor.org/info/rfc4303>.
[RFC4304] Kent, S., "Extended Sequence Number (ESN) Addendum to [RFC4304] Kent, S., "Extended Sequence Number (ESN) Addendum to
IPsec Domain of Interpretation (DOI) for Internet Security IPsec Domain of Interpretation (DOI) for Internet Security
Association and Key Management Protocol (ISAKMP)", Association and Key Management Protocol (ISAKMP)",
RFC 4304, DOI 10.17487/RFC4304, December 2005, RFC 4304, DOI 10.17487/RFC4304, December 2005,
<http://www.rfc-editor.org/info/rfc4304>. <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,
<http://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, <http://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
of Type 0 Routing Headers in IPv6", RFC 5095, of Type 0 Routing Headers in IPv6", RFC 5095,
DOI 10.17487/RFC5095, December 2007, DOI 10.17487/RFC5095, December 2007,
<http://www.rfc-editor.org/info/rfc5095>. <https://www.rfc-editor.org/info/rfc5095>.
[RFC5201] Moskowitz, R., Nikander, P., Jokela, P., Ed., and T. [RFC5201] Moskowitz, R., Nikander, P., Jokela, P., Ed., and T.
Henderson, "Host Identity Protocol", RFC 5201, Henderson, "Host Identity Protocol", RFC 5201,
DOI 10.17487/RFC5201, April 2008, DOI 10.17487/RFC5201, April 2008,
<http://www.rfc-editor.org/info/rfc5201>. <https://www.rfc-editor.org/info/rfc5201>.
[RFC5533] Nordmark, E. and M. Bagnulo, "Shim6: Level 3 Multihoming [RFC5533] Nordmark, E. and M. Bagnulo, "Shim6: Level 3 Multihoming
Shim Protocol for IPv6", RFC 5533, DOI 10.17487/RFC5533, Shim Protocol for IPv6", RFC 5533, DOI 10.17487/RFC5533,
June 2009, <http://www.rfc-editor.org/info/rfc5533>. June 2009, <https://www.rfc-editor.org/info/rfc5533>.
[RFC5570] StJohns, M., Atkinson, R., and G. Thomas, "Common [RFC5570] StJohns, M., Atkinson, R., and G. Thomas, "Common
Architecture Label IPv6 Security Option (CALIPSO)", Architecture Label IPv6 Security Option (CALIPSO)",
RFC 5570, DOI 10.17487/RFC5570, July 2009, RFC 5570, DOI 10.17487/RFC5570, July 2009,
<http://www.rfc-editor.org/info/rfc5570>. <https://www.rfc-editor.org/info/rfc5570>.
[RFC6275] Perkins, C., Ed., Johnson, D., and J. Arkko, "Mobility [RFC6275] Perkins, C., Ed., Johnson, D., and J. Arkko, "Mobility
Support in IPv6", RFC 6275, DOI 10.17487/RFC6275, July Support in IPv6", RFC 6275, DOI 10.17487/RFC6275, July
2011, <http://www.rfc-editor.org/info/rfc6275>. 2011, <https://www.rfc-editor.org/info/rfc6275>.
[RFC6398] Le Faucheur, F., Ed., "IP Router Alert Considerations and [RFC6398] Le Faucheur, F., Ed., "IP Router Alert Considerations and
Usage", BCP 168, RFC 6398, DOI 10.17487/RFC6398, October Usage", BCP 168, RFC 6398, DOI 10.17487/RFC6398, October
2011, <http://www.rfc-editor.org/info/rfc6398>. 2011, <https://www.rfc-editor.org/info/rfc6398>.
[RFC6550] Winter, T., Ed., Thubert, P., Ed., Brandt, A., Hui, J., [RFC6550] Winter, T., Ed., Thubert, P., Ed., Brandt, A., Hui, J.,
Kelsey, R., Levis, P., Pister, K., Struik, R., Vasseur, Kelsey, R., Levis, P., Pister, K., Struik, R., Vasseur,
JP., and R. Alexander, "RPL: IPv6 Routing Protocol for JP., and R. Alexander, "RPL: IPv6 Routing Protocol for
Low-Power and Lossy Networks", RFC 6550, Low-Power and Lossy Networks", RFC 6550,
DOI 10.17487/RFC6550, March 2012, DOI 10.17487/RFC6550, March 2012,
<http://www.rfc-editor.org/info/rfc6550>. <https://www.rfc-editor.org/info/rfc6550>.
[RFC6553] Hui, J. and JP. Vasseur, "The Routing Protocol for Low- [RFC6553] Hui, J. and JP. Vasseur, "The Routing Protocol for Low-
Power and Lossy Networks (RPL) Option for Carrying RPL Power and Lossy Networks (RPL) Option for Carrying RPL
Information in Data-Plane Datagrams", RFC 6553, Information in Data-Plane Datagrams", RFC 6553,
DOI 10.17487/RFC6553, March 2012, DOI 10.17487/RFC6553, March 2012,
<http://www.rfc-editor.org/info/rfc6553>. <https://www.rfc-editor.org/info/rfc6553>.
[RFC6554] Hui, J., Vasseur, JP., Culler, D., and V. Manral, "An IPv6 [RFC6554] Hui, J., Vasseur, JP., Culler, D., and V. Manral, "An IPv6
Routing Header for Source Routes with the Routing Protocol Routing Header for Source Routes with the Routing Protocol
for Low-Power and Lossy Networks (RPL)", RFC 6554, for Low-Power and Lossy Networks (RPL)", RFC 6554,
DOI 10.17487/RFC6554, March 2012, DOI 10.17487/RFC6554, March 2012,
<http://www.rfc-editor.org/info/rfc6554>. <https://www.rfc-editor.org/info/rfc6554>.
[RFC6621] Macker, J., Ed., "Simplified Multicast Forwarding", [RFC6621] Macker, J., Ed., "Simplified Multicast Forwarding",
RFC 6621, DOI 10.17487/RFC6621, May 2012, RFC 6621, DOI 10.17487/RFC6621, May 2012,
<http://www.rfc-editor.org/info/rfc6621>. <https://www.rfc-editor.org/info/rfc6621>.
[RFC6740] Atkinson, RJ. and SN. Bhatti, "Identifier-Locator Network [RFC6740] Atkinson, RJ. and SN. Bhatti, "Identifier-Locator Network
Protocol (ILNP) Architectural Description", RFC 6740, Protocol (ILNP) Architectural Description", RFC 6740,
DOI 10.17487/RFC6740, November 2012, DOI 10.17487/RFC6740, November 2012,
<http://www.rfc-editor.org/info/rfc6740>. <https://www.rfc-editor.org/info/rfc6740>.
[RFC6744] Atkinson, RJ. and SN. Bhatti, "IPv6 Nonce Destination [RFC6744] Atkinson, RJ. and SN. Bhatti, "IPv6 Nonce Destination
Option for the Identifier-Locator Network Protocol for Option for the Identifier-Locator Network Protocol for
IPv6 (ILNPv6)", RFC 6744, DOI 10.17487/RFC6744, November IPv6 (ILNPv6)", RFC 6744, DOI 10.17487/RFC6744, November
2012, <http://www.rfc-editor.org/info/rfc6744>. 2012, <https://www.rfc-editor.org/info/rfc6744>.
[RFC6788] Krishnan, S., Kavanagh, A., Varga, B., Ooghe, S., and E. [RFC6788] Krishnan, S., Kavanagh, A., Varga, B., Ooghe, S., and E.
Nordmark, "The Line-Identification Option", RFC 6788, Nordmark, "The Line-Identification Option", RFC 6788,
DOI 10.17487/RFC6788, November 2012, DOI 10.17487/RFC6788, November 2012,
<http://www.rfc-editor.org/info/rfc6788>. <https://www.rfc-editor.org/info/rfc6788>.
[RFC6971] Herberg, U., Ed., Cardenas, A., Iwao, T., Dow, M., and S. [RFC6971] Herberg, U., Ed., Cardenas, A., Iwao, T., Dow, M., and S.
Cespedes, "Depth-First Forwarding (DFF) in Unreliable Cespedes, "Depth-First Forwarding (DFF) in Unreliable
Networks", RFC 6971, DOI 10.17487/RFC6971, June 2013, Networks", RFC 6971, DOI 10.17487/RFC6971, June 2013,
<http://www.rfc-editor.org/info/rfc6971>. <https://www.rfc-editor.org/info/rfc6971>.
[RFC7045] Carpenter, B. and S. Jiang, "Transmission and Processing [RFC7045] Carpenter, B. and S. Jiang, "Transmission and Processing
of IPv6 Extension Headers", RFC 7045, of IPv6 Extension Headers", RFC 7045,
DOI 10.17487/RFC7045, December 2013, DOI 10.17487/RFC7045, December 2013,
<http://www.rfc-editor.org/info/rfc7045>. <https://www.rfc-editor.org/info/rfc7045>.
[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,
<http://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, <http://www.rfc-editor.org/info/rfc7731>. February 2016, <https://www.rfc-editor.org/info/rfc7731>.
[RFC8200] Deering, S. and R. Hinden, "Internet Protocol, Version 6
(IPv6) Specification", STD 86, RFC 8200,
DOI 10.17487/RFC8200, July 2017,
<https://www.rfc-editor.org/info/rfc8200>.
8.2. Informative References 8.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
skipping to change at page 34, line 17 skipping to change at page 34, line 17
2014, <http://www.iana.org/assignments/protocol-numbers/ 2014, <http://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/".
[RFC3871] Jones, G., Ed., "Operational Security Requirements for [RFC3871] Jones, G., Ed., "Operational Security Requirements for
Large Internet Service Provider (ISP) IP Network Large Internet Service Provider (ISP) IP Network
Infrastructure", RFC 3871, DOI 10.17487/RFC3871, September Infrastructure", RFC 3871, DOI 10.17487/RFC3871, September
2004, <http://www.rfc-editor.org/info/rfc3871>. 2004, <https://www.rfc-editor.org/info/rfc3871>.
[RFC6192] Dugal, D., Pignataro, C., and R. Dunn, "Protecting the [RFC6192] Dugal, D., Pignataro, C., and R. Dunn, "Protecting the
Router Control Plane", RFC 6192, DOI 10.17487/RFC6192, Router Control Plane", RFC 6192, DOI 10.17487/RFC6192,
March 2011, <http://www.rfc-editor.org/info/rfc6192>. March 2011, <https://www.rfc-editor.org/info/rfc6192>.
[RFC7126] Gont, F., Atkinson, R., and C. Pignataro, "Recommendations [RFC7126] Gont, F., Atkinson, R., and C. Pignataro, "Recommendations
on Filtering of IPv4 Packets Containing IPv4 Options", on Filtering of IPv4 Packets Containing IPv4 Options",
BCP 186, RFC 7126, DOI 10.17487/RFC7126, February 2014, BCP 186, RFC 7126, DOI 10.17487/RFC7126, February 2014,
<http://www.rfc-editor.org/info/rfc7126>. <https://www.rfc-editor.org/info/rfc7126>.
[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, <http://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,
<http://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 UTN-FRH / SI6 Networks
Evaristo Carriego 2644 Evaristo Carriego 2644
Haedo, Provincia de Buenos Aires 1706 Haedo, Provincia de Buenos Aires 1706
Argentina Argentina
Phone: +54 11 4650 8472 Phone: +54 11 4650 8472
 End of changes. 66 change blocks. 
92 lines changed or deleted 107 lines changed or added

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