doc: Add RFC documents

1 files changed, 1866 insertions, 0 deletions

diff --git a/doc/rfc/rfc9288.txt b/doc/rfc/rfc9288.txt
new file mode 100644
index 0000000..abcfcf4
--- /dev/null
+++ b/doc/rfc/rfc9288.txt
@@ -0,0 +1,1866 @@
+
+
+
+
+Internet Engineering Task Force (IETF)                           F. Gont
+Request for Comments: 9288                                  SI6 Networks
+Category: Informational                                           W. Liu
+ISSN: 2070-1721                                      Huawei Technologies
+                                                             August 2022
+
+
+    Recommendations on the Filtering of IPv6 Packets Containing IPv6
+                  Extension Headers at Transit Routers
+
+Abstract
+
+   This document analyzes the security implications of IPv6 Extension
+   Headers and associated IPv6 options.  Additionally, it discusses the
+   operational and interoperability implications of discarding packets
+   based on the IPv6 Extension Headers and IPv6 options they contain.
+   Finally, it provides advice on the filtering of such IPv6 packets at
+   transit routers for traffic not directed to them, for those cases
+   where such filtering is deemed as necessary.
+
+Status of This Memo
+
+   This document is not an Internet Standards Track specification; it is
+   published for informational purposes.
+
+   This document is a product of the Internet Engineering Task Force
+   (IETF).  It represents the consensus of the IETF community.  It has
+   received public review and has been approved for publication by the
+   Internet Engineering Steering Group (IESG).  Not all documents
+   approved by the IESG are candidates for any level of Internet
+   Standard; see Section 2 of RFC 7841.
+
+   Information about the current status of this document, any errata,
+   and how to provide feedback on it may be obtained at
+   https://www.rfc-editor.org/info/rfc9288.
+
+Copyright Notice
+
+   Copyright (c) 2022 IETF Trust and the persons identified as the
+   document authors.  All rights reserved.
+
+   This document is subject to BCP 78 and the IETF Trust's Legal
+   Provisions Relating to IETF Documents
+   (https://trustee.ietf.org/license-info) in effect on the date of
+   publication of this document.  Please review these documents
+   carefully, as they describe your rights and restrictions with respect
+   to this document.  Code Components extracted from this document must
+   include Revised BSD License text as described in Section 4.e of the
+   Trust Legal Provisions and are provided without warranty as described
+   in the Revised BSD License.
+
+Table of Contents
+
+   1.  Introduction
+   2.  Terminology and Assumptions Employed in This Document
+     2.1.  Terminology
+     2.2.  Applicability Statement
+     2.3.  Router Default Behavior and Features
+   3.  IPv6 Extension Headers
+     3.1.  General Discussion
+     3.2.  General Security Implications
+     3.3.  Rationale for Our Advice on the Handling of IPv6 Packets
+           with Specific IPv6 Extension Headers
+     3.4.  Summary of Advice on the Handling of IPv6 Packets with
+           Specific IPv6 Extension Headers
+     3.5.  Advice on the Handling of IPv6 Packets with Specific IPv6
+           Extension Headers
+     3.6.  Advice on the Handling of Packets with Unknown IPv6
+           Extension Headers
+   4.  IPv6 Options
+     4.1.  General Discussion
+     4.2.  General Security Implications of IPv6 Options
+     4.3.  Summary of Advice on the Handling of IPv6 Packets with
+           Specific IPv6 Options
+     4.4.  Advice on the Handling of Packets with Specific IPv6
+           Options
+     4.5.  Advice on the Handling of Packets with Unknown IPv6 Options
+   5.  IANA Considerations
+   6.  Privacy Considerations
+   7.  Security Considerations
+   8.  References
+     8.1.  Normative References
+     8.2.  Informative References
+   Acknowledgements
+   Authors' Addresses
+
+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, as
+   an example, enforcing Access Control Lists (ACLs) or implementing
+   other functions [RFC9098].
+
+   Several studies (e.g., [Huston-2022], [JAMES], and [RFC7872]) suggest
+   that there is widespread dropping of IPv6 packets that contain IPv6
+   EHs.  In some cases, such packet drops occur at transit routers.
+   While some operators are known to intentionally drop packets that
+   contain IPv6 EHs, it is possible that some of the measured packet
+   drops are the result of inappropriate advice in this area.
+
+   This document analyzes both the general security implications of IPv6
+   EHs, as well as the security implications of specific EH and option
+   types.  It also provides advice on the filtering of IPv6 packets
+   based on the IPv6 EHs and the IPv6 options they contain.  Since
+   various protocols may use IPv6 EHs (possibly with IPv6 options),
+   discarding packets based on the IPv6 EHs or IPv6 options they contain
+   can have implications on the proper functioning of such protocols.
+   Thus, this document also attempts to discuss the operational and
+   interoperability implications of such filtering policies.
+
+   The resulting packet filtering policy typically depends on where in
+   the network such policy is enforced.  When the policy is enforced in
+   a transit network, the policy typically follows a "deny-list"
+   approach, where only packets with clear negative implications are
+   dropped.  On the other hand, when the policy is enforced closer to
+   the destination systems, the policy typically follows an "accept-
+   list" approach, where only traffic that is expected to be received is
+   allowed.  The advice in this document is aimed only at transit
+   routers that may need to enforce a filtering policy based on the IPv6
+   EHs and IPv6 options a packet may contain, following a "deny-list"
+   approach; hence, it is likely to be much more permissive than a
+   filtering policy to be employed at, for example, the edge of an
+   enterprise network.  The advice in this document is meant to improve
+   the current situation of the 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
+   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
+   and a number of IPv6 options that may be valid only when included in
+   specific EH types.
+
+   This document completes and complements the considerations for
+   protecting the control plane from packets containing IP options that
+   can be found in [RFC6192].
+
+   Section 2 specifies the terminology and conventions employed
+   throughout this document.  Section 3 discusses IPv6 EHs and provides
+   advice in the area of filtering IPv6 packets that contain such IPv6
+   EHs.  Section 4 discusses IPv6 options and provides advice in the
+   area of filtering IPv6 packets that contain such options.
+
+2.  Terminology and Assumptions Employed in This Document
+
+2.1.  Terminology
+
+   The terms "permit" (allow the traffic), "drop" (drop with no
+   notification to sender), and "reject" (drop with appropriate
+   notification to sender) are employed as defined in [RFC3871].
+   Throughout this document, we also employ the term "discard" as a
+   generic term to indicate the act of discarding a packet, irrespective
+   of whether the sender is notified of such a drop and whether the
+   specific filtering action is logged.
+
+   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
+   "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
+   "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
+
+   This document provides advice on the filtering of IPv6 packets with
+   EHs at transit routers for traffic not explicitly destined to them,
+   for cases in which such filtering is deemed as necessary.
+
+2.3.  Router Default Behavior and Features
+
+   This document assumes that nodes comply with the requirements in
+   [RFC7045].  Namely,
+
+   |  If a forwarding node discards a packet containing a standard IPv6
+   |  extension header, it MUST be the result of a configurable policy
+   |  and not just the result of a failure to recognise such a header.
+   |  This means that the discard policy for each standard type of
+   |  extension header MUST be individually configurable.  The default
+   |  configuration SHOULD allow all standard extension headers.
+
+   The advice provided in this document is only meant to guide an
+   operator in configuring forwarding devices and is not to be
+   interpreted as advice regarding default configuration settings for
+   network devices.  That is, this document provides advice with respect
+   to operational policies but does not change the implementation
+   defaults required by [RFC7045].
+
+   We recommend that configuration options be made available to govern
+   the processing of each IPv6 EH type and each IPv6 Option Type.  Such
+   configuration options should include the following possible settings:
+
+   *  Permit this IPv6 EH or IPv6 Option Type.
+
+   *  Drop packets containing this IPv6 EH or IPv6 Option Type.
+
+   *  Reject packets containing this IPv6 EH or IPv6 Option Type (where
+      the packet drop is signaled with an ICMPv6 error message).
+
+   *  Rate-limit traffic containing this IPv6 EH or IPv6 Option Type.
+
+   *  Ignore this IPv6 EH or IPv6 Option Type (as if it was not
+      present), and process the packet according the rules for the
+      remaining headers.  We note that if a packet carries forwarding
+      information (e.g., in an IPv6 Routing Header (RH)), this might be
+      an inappropriate or undesirable action.
+
+   We note that special care needs to be taken when devices log packet
+   drops/rejects.  Devices should count the number of packets dropped/
+   rejected, but the logging of drop/reject events should be limited so
+   as to not overburden device resources.
+
+   Finally, we note that when discarding packets, it is generally
+   desirable that the sender be signaled of the packet drop, since this
+   is of use for trouble-shooting purposes.  However, throughout this
+   document (when recommending that packets be discarded), we
+   generically refer to the action as "discard" without specifying
+   whether the sender is signaled of the packet drop.
+
+3.  IPv6 Extension Headers
+
+3.1.  General Discussion
+
+   IPv6 EHs [RFC8200] allow for the extension of the IPv6 protocol.
+   Since both IPv6 EHs and upper-layer protocols share the same
+   namespace ("Next Header" registry/namespace), [RFC7045] identifies
+   which of the currently assigned Internet Protocol numbers identify
+   IPv6 EHs vs. upper-layer protocols.  This document discusses the
+   filtering of packets based on the IPv6 EHs (as specified by
+   [RFC7045]) they contain.
+
+   [RFC8200] specifies that non-fragmented IPv6 datagrams and IPv6
+   First-Fragments must contain the entire IPv6 header chain [RFC7112].
+   Therefore, intermediate systems can enforce the filtering policies
+   discussed in this document or resort to simply discarding the
+   offending packets when they fail to include the entire IPv6 header
+   chain [RFC8200].
+
+   We note that in order to implement filtering rules on the fast path,
+   it may be necessary for the filtering device to limit the depth into
+   the packet that can be inspected before giving up.  In circumstances
+   where such a limitation exists, it is recommended that
+   implementations provide a configuration option that specifies whether
+   to discard packets 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
+
+   In some device architectures, IPv6 packets that contain IPv6 EHs can
+   cause the corresponding packets to be processed on the slow path and,
+   hence, may be leveraged for the purpose of Denial-of-Service (DoS)
+   attacks [RFC9098] [Cisco-EH] [FW-Benchmark].
+
+   Operators are urged to consider the IPv6 EH and IPv6 options handling
+   capabilities of their devices as they make deployment decisions in
+   the future.
+
+3.3.  Rationale for Our Advice on the Handling of IPv6 Packets with
+      Specific IPv6 Extension Headers
+
+   *  IPv6 packets with IPv6 Extension Headers (or options) that are not
+      expected to traverse transit routers should be dropped.
+
+   *  IPv6 packets with IPv6 Extension Headers (or options) that are
+      only expected to traverse transit routers when a specific
+      technology is employed should be permitted (or dropped) based on
+      the knowledge regarding the use of such technology in the transit
+      provider in question (i.e., permit the packets if the technology
+      is employed, or drop them).
+
+   *  IPv6 packets with IPv6 Extension Headers (or options) that
+      represent a concrete attack vector to network infrastructure
+      devices should be dropped.
+
+   *  IPv6 packets with any other IPv6 Extension Headers (or options)
+      should be permitted.  This is an intentional trade-off made to
+      minimize ossification.
+
+3.4.  Summary of Advice on the Handling of IPv6 Packets with Specific
+      IPv6 Extension Headers
+
+   This section summarizes the advice provided in Section 3.5, providing
+   references to the specific sections in which a detailed analysis can
+   be found.
+
+       +=====================+=========================+===========+
+       |       EH Type       |     Filtering Policy    | Reference |
+       +=====================+=========================+===========+
+       |  Hop-by-Hop Options |      Drop or Ignore     |  Section  |
+       |   Header (Proto=0)  |                         |   3.5.1   |
+       +---------------------+-------------------------+-----------+
+       |    Routing Header   |  Drop only Routing Type |  Section  |
+       |      (Proto=43)     |  0, Routing Type 1, and |   3.5.2   |
+       |                     | Routing Type 3.  Permit |           |
+       |                     |   other Routing Types   |           |
+       +---------------------+-------------------------+-----------+
+       |   Fragment Header   |          Permit         |  Section  |
+       |      (Proto=44)     |                         |   3.5.3   |
+       +---------------------+-------------------------+-----------+
+       |    Encapsulating    |          Permit         |  Section  |
+       |   Security Payload  |                         |   3.5.4   |
+       |      (Proto=50)     |                         |           |
+       +---------------------+-------------------------+-----------+
+       |    Authentication   |          Permit         |  Section  |
+       |  Header (Proto=51)  |                         |   3.5.5   |
+       +---------------------+-------------------------+-----------+
+       | Destination Options |          Permit         |  Section  |
+       |   Header(Proto=60)  |                         |   3.5.6   |
+       +---------------------+-------------------------+-----------+
+       |   Mobility Header   |          Permit         |  Section  |
+       |     (Proto=135)     |                         |   3.5.7   |
+       +---------------------+-------------------------+-----------+
+       |    Host Identity    |          Permit         |  Section  |
+       |       Protocol      |                         |   3.5.8   |
+       |     (Proto=139)     |                         |           |
+       +---------------------+-------------------------+-----------+
+       |    Shim6 Protocol   |          Permit         |  Section  |
+       |     (Proto=140)     |                         |   3.5.9   |
+       +---------------------+-------------------------+-----------+
+       |       Use for       |           Drop          |  Section  |
+       | experimentation and |                         |   3.5.10  |
+       |  testing (Proto=253 |                         |           |
+       |       and 254)      |                         |           |
+       +---------------------+-------------------------+-----------+
+
+             Table 1: Summary of Advice on the Handling of IPv6
+                Packets with Specific IPv6 Extension Headers
+
+3.5.  Advice on the Handling of IPv6 Packets with Specific IPv6
+      Extension Headers
+
+3.5.1.  IPv6 Hop-by-Hop Options (Protocol Number=0)
+
+3.5.1.1.  Uses
+
+   The Hop-by-Hop (HBH) Options header is used to carry optional
+   information that may be examined by every node along a packet's
+   delivery path.  It is expected that nodes will examine the Hop-by-Hop
+   Options header if explicitly configured to do so.
+
+      |  NOTE: A previous revision of the IPv6 core specification
+      |  [RFC2460] originally required all nodes to examine and process
+      |  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.5.1.2.  Specification
+
+   This EH is specified in [RFC8200].  As of May 2022, the following
+   options have been specified for the Hop-by-Hop Options header:
+
+   *  Type 0x00: Pad1 [RFC8200]
+
+   *  Type 0x01: PadN [RFC8200]
+
+   *  Type 0x05: Router Alert [RFC2711]
+
+   *  Type 0x07: CALIPSO [RFC5570]
+
+   *  Type 0x08: SMF_DPD [RFC6621]
+
+   *  Type 0x23: RPL Option [RFC9008]
+
+   *  Type 0x26: Quick-Start [RFC4782]
+
+   *  Type 0x4D: (Deprecated)
+
+   *  Type 0x63: RPL Option [RFC6553]
+
+   *  Type 0x6D: MPL Option [RFC7731]
+
+   *  Type 0x8A: Endpoint Identification (Deprecated) [NIMROD-EID]
+
+   *  Type 0xC2: Jumbo Payload [RFC2675]
+
+   *  Type 0xEE: IPv6 DFF Header [RFC6971]
+
+   *  Type 0x1E: RFC3692-style Experiment [RFC4727]
+
+   *  Type 0x3E: RFC3692-style Experiment [RFC4727]
+
+   *  Type 0x5E: RFC3692-style Experiment [RFC4727]
+
+   *  Type 0x7E: RFC3692-style Experiment [RFC4727]
+
+   *  Type 0x9E: RFC3692-style Experiment [RFC4727]
+
+   *  Type 0xBE: RFC3692-style Experiment [RFC4727]
+
+   *  Type 0xDE: RFC3692-style Experiment [RFC4727]
+
+   *  Type 0xFE: RFC3692-style Experiment [RFC4727]
+
+3.5.1.3.  Specific Security Implications
+
+   Legacy nodes that process this extension header might be subject to
+   DoS attacks.
+
+      |  NOTE: While [RFC8200] has removed the requirement for all nodes
+      |  to examine and process the Hop-by-Hop Options header, the
+      |  deployed base may still reflect the legacy [RFC2460] behavior
+      |  for a while; hence, the potential security problems of this EH
+      |  are still of concern.
+
+3.5.1.4.  Operational and Interoperability Impact If Blocked
+
+   Discarding packets containing a Hop-by-Hop Options header would break
+   any of the protocols that rely on it for proper functioning.  For
+   example, it would break RSVP [RFC2205] and multicast deployments and
+   would cause IPv6 jumbograms to be discarded.
+
+3.5.1.5.  Advice
+
+   Nodes implementing [RFC8200] would already ignore this extension
+   header unless explicitly required to process it.  For legacy nodes
+   [RFC2460], the recommended configuration for the processing of these
+   packets depends on the features and capabilities of the underlying
+   platform, the configuration of the platform, and also the deployment
+   environment of the platform.  On platforms that allow the forwarding
+   of packets with IPv6 HBH Options headers on the fast path, we
+   recommend that packets with IPv6 HBH Options headers be forwarded as
+   normal.  Otherwise, on platforms in which the processing of packets
+   with IPv6 HBH Options headers is carried out in the slow path and an
+   option is provided to rate-limit these packets, we recommend that
+   this option be selected.  Finally, when packets containing IPv6 HBH
+   Options headers are processed in the slow path and the underlying
+   platform does not have any mitigation options available for attacks
+   based on these packets, we recommend that such platforms discard
+   packets containing IPv6 HBH Options headers.
+
+   Finally, we note that the Routing Protocol for Low-Power and Lossy
+   Networks (RPL) routers [RFC6550] must not discard packets based on
+   the presence of an IPv6 Hop-by-Hop Options header, as this would
+   break the RPL.
+
+3.5.2.  Routing Header (Protocol Number=43)
+
+3.5.2.1.  Uses
+
+   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
+   destination.
+
+3.5.2.2.  Specification
+
+   This EH is specified in [RFC8200].  The Routing Type 0 had originally
+   been specified in [RFC2460] and was later obsoleted by [RFC5095];
+   thus, it was removed from [RFC8200].
+
+   As of May 2022, the following Routing Types have been specified:
+
+   *  Type 0: Source Route (DEPRECATED) [RFC2460] [RFC5095]
+
+   *  Type 1: Nimrod (DEPRECATED)
+
+   *  Type 2: Type 2 Routing Header [RFC6275]
+
+   *  Type 3: RPL Source Route Header [RFC6554]
+
+   *  Type 4: Segment Routing Header (SRH) [RFC8754]
+
+   *  Types 5-252: Unassigned
+
+   *  Type 253: RFC3692-style Experiment 1 [RFC4727]
+
+   *  Type 254: RFC3692-style Experiment 2 [RFC4727]
+
+   *  Type 255: Reserved
+
+3.5.2.3.  Specific Security Implications
+
+   The security implications of Routing Headers of Routing Type 0 have
+   been discussed in detail in [Biondi-2007] and [RFC5095].  Routing
+   Type 1 was never widely implemented.  The security implications of
+   Routing Headers of Routing Type 2, Routing Type 3, and Routing Type 4
+   (SRH) are discussed in [RFC6275], [RFC6554], and [RFC8754],
+   respectively.
+
+3.5.2.4.  Operational and Interoperability Impact If Blocked
+
+   Blocking packets containing Routing Headers of Routing Type 0 or
+   Routing Type 1 has no operational implications, since both have been
+   deprecated.  Blocking packets containing Routing Headers of Routing
+   Type 2 would break Mobile IPv6.  Packets containing Routing Headers
+   of Routing Type 3 may be safely blocked at RPL domain boundaries,
+   since such headers are employed within a single RPL domain.  Blocking
+   packets containing Routing Headers of Routing Type 4 (SRH) will break
+   Segment Routing (SR) deployments if the filtering policy is enforced
+   on packets being forwarded within an SR domain.
+
+3.5.2.5.  Advice
+
+   Intermediate systems should discard packets containing Routing
+   Headers of Routing Type 0, Routing Type 1, or Routing Type 3.  Other
+   Routing Types should be permitted, as required by [RFC7045].
+
+3.5.3.  Fragment Header (Protocol Number=44)
+
+3.5.3.1.  Uses
+
+   This EH provides the fragmentation and reassembly functionality for
+   IPv6.
+
+3.5.3.2.  Specification
+
+   This EH is specified in [RFC8200].
+
+3.5.3.3.  Specific Security Implications
+
+   The security implications of the Fragment Header range from DoS
+   attacks (e.g., based on flooding a target with IPv6 fragments) to
+   information leakage attacks [RFC7739].
+
+3.5.3.4.  Operational and Interoperability Impact If Blocked
+
+   Blocking packets that contain a Fragment Header will break any
+   protocol that may rely on fragmentation (e.g., the DNS [RFC1034]).
+   However, IP fragmentation is known to introduce fragility to Internet
+   communication [RFC8900].
+
+3.5.3.5.  Advice
+
+   Intermediate systems should permit packets that contain a Fragment
+   Header.
+
+3.5.4.  Encapsulating Security Payload (Protocol Number=50)
+
+3.5.4.1.  Uses
+
+   This EH is employed for the IPsec suite [RFC4303].
+
+3.5.4.2.  Specification
+
+   This EH is specified in [RFC4303].
+
+3.5.4.3.  Specific Security Implications
+
+   Besides the general implications of IPv6 EHs, this EH could be
+   employed to potentially perform a DoS attack at the destination
+   system by wasting CPU resources in validating the contents of the
+   packet.
+
+3.5.4.4.  Operational and Interoperability Impact If Blocked
+
+   Discarding packets that employ this EH would break IPsec deployments.
+
+3.5.4.5.  Advice
+
+   Intermediate systems should permit packets containing the
+   Encapsulating Security Payload EH.
+
+3.5.5.  Authentication Header (Protocol Number=51)
+
+3.5.5.1.  Uses
+
+   The Authentication Header can be employed to provide authentication
+   services in IPv4 and IPv6.
+
+3.5.5.2.  Specification
+
+   This EH is specified in [RFC4302].
+
+3.5.5.3.  Specific Security Implications
+
+   Besides the general implications of IPv6 EHs, this EH could be
+   employed to potentially perform a DoS attack at the destination
+   system by wasting CPU resources in validating the contents of the
+   packet.
+
+3.5.5.4.  Operational and Interoperability Impact If Blocked
+
+   Discarding packets that employ this EH would break IPsec deployments.
+
+3.5.5.5.  Advice
+
+   Intermediate systems should permit packets containing an
+   Authentication Header.
+
+3.5.6.  Destination Options (Protocol Number=60)
+
+3.5.6.1.  Uses
+
+   The Destination Options (DO) header is used to carry optional
+   information that needs be examined only by a packet's destination
+   node(s).
+
+3.5.6.2.  Specification
+
+   This EH is specified in [RFC8200].  As of May 2022, the following
+   options have been specified for this EH:
+
+   *  Type 0x00: Pad1 [RFC8200]
+
+   *  Type 0x01: PadN [RFC8200]
+
+   *  Type 0x04: Tunnel Encapsulation Limit [RFC2473]
+
+   *  Type 0x0F: IPv6 Performance and Diagnostic Metrics (PDM) [RFC8250]
+
+   *  Type 0x4D: (Deprecated)
+
+   *  Type 0xC9: Home Address [RFC6275]
+
+   *  Type 0x8A: Endpoint Identification (Deprecated) [NIMROD-EID]
+
+   *  Type 0x8B: ILNP Nonce [RFC6744]
+
+   *  Type 0x8C: Line-Identification Option [RFC6788]
+
+   *  Type 0x1E: RFC3692-style Experiment [RFC4727]
+
+   *  Type 0x3E: RFC3692-style Experiment [RFC4727]
+
+   *  Type 0x5E: RFC3692-style Experiment [RFC4727]
+
+   *  Type 0x7E: RFC3692-style Experiment [RFC4727]
+
+   *  Type 0x9E: RFC3692-style Experiment [RFC4727]
+
+   *  Type 0xBE: RFC3692-style Experiment [RFC4727]
+
+   *  Type 0xDE: RFC3692-style Experiment [RFC4727]
+
+   *  Type 0xFE: RFC3692-style Experiment [RFC4727]
+
+3.5.6.3.  Specific Security Implications
+
+   No security implications are known, other than the general security
+   implications of IPv6 EHs.  For a discussion of possible security
+   implications of specific options specified for the DO header, please
+   see Section 4.4.
+
+3.5.6.4.  Operational and Interoperability Impact If Blocked
+
+   Discarding packets that contain a Destination Options header would
+   break protocols that rely on this EH type for conveying information
+   (such as the Identifier-Locator Network Protocol (ILNP) [RFC6740] and
+   Mobile IPv6 [RFC6275]), as well as IPv6 tunnels that employ the
+   Tunnel Encapsulation Limit option [RFC2473].
+
+3.5.6.5.  Advice
+
+   Intermediate systems should permit packets that contain a Destination
+   Options header.
+
+3.5.7.  Mobility Header (Protocol Number=135)
+
+3.5.7.1.  Uses
+
+   The Mobility Header is an EH used by mobile nodes, correspondent
+   nodes, and home agents in all messaging related to the creation and
+   management of bindings in Mobile IPv6.
+
+3.5.7.2.  Specification
+
+   This EH is specified in [RFC6275].
+
+3.5.7.3.  Specific Security Implications
+
+   A thorough security assessment of the security implications of the
+   Mobility Header and related mechanisms can be found in Section 15 of
+   [RFC6275].
+
+3.5.7.4.  Operational and Interoperability Impact If Blocked
+
+   Discarding packets containing this EH would break Mobile IPv6.
+
+3.5.7.5.  Advice
+
+   Intermediate systems should permit packets that contain a Mobility
+   Header.
+
+3.5.8.  Host Identity Protocol (Protocol Number=139)
+
+3.5.8.1.  Uses
+
+   This EH is employed with the Host Identity Protocol (HIP), which is a
+   protocol that allows consenting hosts to securely establish and
+   maintain shared IP-layer state, allowing the separation of the
+   identifier and locator roles of IP addresses, thereby enabling
+   continuity of communications across IP address changes.
+
+3.5.8.2.  Specification
+
+   This EH is specified in [RFC7401].
+
+3.5.8.3.  Specific Security Implications
+
+   The security implications of the HIP header are discussed in detail
+   in Section 8 of [RFC7401].
+
+3.5.8.4.  Operational and Interoperability Impact If Blocked
+
+   Discarding packets that contain a HIP header would break HIP
+   deployments.
+
+3.5.8.5.  Advice
+
+   Intermediate systems should permit packets that contain a HIP header.
+
+3.5.9.  Shim6 Protocol (Protocol Number=140)
+
+3.5.9.1.  Uses
+
+   This EH is employed by the Shim6 protocol [RFC5533].
+
+3.5.9.2.  Specification
+
+   This EH is specified in [RFC5533].
+
+3.5.9.3.  Specific Security Implications
+
+   The specific security implications are discussed in detail in
+   Section 16 of [RFC5533].
+
+3.5.9.4.  Operational and Interoperability Impact If Blocked
+
+   Discarding packets that contain this EH will break Shim6.
+
+3.5.9.5.  Advice
+
+   Intermediate systems should permit packets containing this EH.
+
+3.5.10.  Use for Experimentation and Testing (Protocol Numbers=253 and
+         254)
+
+3.5.10.1.  Uses
+
+   These IPv6 EHs are employed for performing RFC3692-style experiments
+   (see [RFC3692] for details).
+
+3.5.10.2.  Specification
+
+   These EHs are specified in [RFC3692] and [RFC4727].
+
+3.5.10.3.  Specific Security Implications
+
+   The security implications of these EHs will depend on their specific
+   use.
+
+3.5.10.4.  Operational and Interoperability Impact If Blocked
+
+   For obvious reasons, discarding packets that contain these EHs limits
+   the ability to perform legitimate experiments across IPv6 routers.
+
+3.5.10.5.  Advice
+
+   Operators should determine, according to their own circumstances,
+   whether to discard packets containing these EHs.
+
+3.6.  Advice on the Handling of Packets with Unknown IPv6 Extension
+      Headers
+
+   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
+   IPv6 Extension Headers" ("unknown IPv6 EHs").
+
+3.6.1.  Uses
+
+   New IPv6 EHs may be specified as part of future extensions to the
+   IPv6 protocol.
+
+   Since IPv6 EHs and upper-layer protocols employ the same namespace,
+   it is impossible to tell whether an unknown Internet Protocol number
+   is being employed for an IPv6 EH or an upper-layer protocol.
+
+3.6.2.  Specification
+
+   The processing of unknown IPv6 EHs is specified in [RFC7045].
+
+3.6.3.  Specific Security Implications
+
+   For obvious reasons, it is impossible to determine specific security
+   implications of unknown IPv6 EHs.
+
+3.6.4.  Operational and Interoperability Impact If Blocked
+
+   As noted in [RFC7045], discarding unknown IPv6 EHs may slow down the
+   deployment of new IPv6 EHs and transport protocols.  The
+   corresponding IANA registry, which is [IANA-PROTOCOLS], should be
+   monitored such that filtering rules are updated as new IPv6 EHs are
+   standardized.
+
+   We note that since IPv6 EHs and upper-layer protocols share the same
+   numbering space, discarding unknown IPv6 EHs may result in packets
+   encapsulating unknown upper-layer protocols being discarded.
+
+3.6.5.  Advice
+
+   Operators should determine, according to their own circumstances,
+   whether to discard packets containing unknown IPv6 EHs.
+
+4.  IPv6 Options
+
+4.1.  General Discussion
+
+   The following subsections describe specific security implications of
+   different IPv6 options and provide advice regarding filtering packets
+   that contain such options.
+
+4.2.  General Security Implications of IPv6 Options
+
+   The general security implications of IPv6 options are closely related
+   to those discussed in Section 3.2 for IPv6 EHs.  Essentially, packets
+   that contain IPv6 options might need to be processed by an IPv6
+   router's general-purpose CPU and, hence, could present a Distributed
+   Denial-of-Service (DDoS) risk to that router's general-purpose CPU
+   (and thus to the router itself).  For some architectures, a possible
+   mitigation would be to rate-limit the packets that are to be
+   processed by the general-purpose CPU (see, e.g., [Cisco-EH]).
+
+4.3.  Summary of Advice on the Handling of IPv6 Packets with Specific
+      IPv6 Options
+
+   This section summarizes the advice provided in Section 4.4, and it
+   includes references to the specific sections in which a detailed
+   analysis can be found.
+
+   +===============================+======================+===========+
+   |             Option            |   Filtering Policy   | Reference |
+   +===============================+======================+===========+
+   |        Pad1 (Type=0x00)       |        Permit        |  Section  |
+   |                               |                      |   4.4.1   |
+   +-------------------------------+----------------------+-----------+
+   |        PadN (Type=0x01)       |        Permit        |  Section  |
+   |                               |                      |   4.4.2   |
+   +-------------------------------+----------------------+-----------+
+   |   Tunnel Encapsulation Limit  |        Permit        |  Section  |
+   |          (Type=0x04)          |                      |   4.4.3   |
+   +-------------------------------+----------------------+-----------+
+   |    Router Alert (Type=0x05)   |   Permit based on    |  Section  |
+   |                               | needed functionality |   4.4.4   |
+   +-------------------------------+----------------------+-----------+
+   |      CALIPSO (Type=0x07)      |   Permit based on    |  Section  |
+   |                               | needed functionality |   4.4.5   |
+   +-------------------------------+----------------------+-----------+
+   |      SMF_DPD (Type=0x08)      |   Permit based on    |  Section  |
+   |                               | needed functionality |   4.4.6   |
+   +-------------------------------+----------------------+-----------+
+   |     PDM Option (Type=0x0F)    |        Permit        |  Section  |
+   |                               |                      |   4.4.7   |
+   +-------------------------------+----------------------+-----------+
+   |     RPL Option (Type=0x23)    |        Permit        |  Section  |
+   |                               |                      |   4.4.8   |
+   +-------------------------------+----------------------+-----------+
+   |    Quick-Start (Type=0x26)    |        Permit        |  Section  |
+   |                               |                      |   4.4.9   |
+   +-------------------------------+----------------------+-----------+
+   |     Deprecated (Type=0x4D)    |         Drop         |  Section  |
+   |                               |                      |   4.4.10  |
+   +-------------------------------+----------------------+-----------+
+   |     MPL Option (Type=0x6D)    |        Permit        |  Section  |
+   |                               |                      |   4.4.12  |
+   +-------------------------------+----------------------+-----------+
+   |   Jumbo Payload (Type=0xC2)   |   Permit based on    |  Section  |
+   |                               | needed functionality |   4.4.16  |
+   +-------------------------------+----------------------+-----------+
+   |     RPL Option (Type=0x63)    |         Drop         |  Section  |
+   |                               |                      |   4.4.11  |
+   +-------------------------------+----------------------+-----------+
+   |    Endpoint Identification    |         Drop         |  Section  |
+   |          (Type=0x8A)          |                      |   4.4.13  |
+   +-------------------------------+----------------------+-----------+
+   |     ILNP Nonce (Type=0x8B)    |        Permit        |  Section  |
+   |                               |                      |   4.4.14  |
+   +-------------------------------+----------------------+-----------+
+   |   Line-Identification Option  |         Drop         |  Section  |
+   |          (Type=0x8C)          |                      |   4.4.15  |
+   +-------------------------------+----------------------+-----------+
+   |    Home Address (Type=0xC9)   |        Permit        |  Section  |
+   |                               |                      |   4.4.17  |
+   +-------------------------------+----------------------+-----------+
+   |       IP_DFF (Type=0xEE)      |   Permit based on    |  Section  |
+   |                               | needed functionality |   4.4.18  |
+   +-------------------------------+----------------------+-----------+
+   |    RFC3692-style Experiment   |   Permit based on    |  Section  |
+   |   (Types = 0x1E, 0x3E, 0x5E,  | needed functionality |   4.4.19  |
+   | 0x7E, 0x9E, 0xBE, 0xDE, 0xFE) |                      |           |
+   +-------------------------------+----------------------+-----------+
+
+     Table 2: Summary of Advice on the Handling of IPv6 Packets with
+                          Specific IPv6 Options
+
+4.4.  Advice on the Handling of Packets with Specific IPv6 Options
+
+   The following subsections contain a description of each of the IPv6
+   options that have so far been specified, a summary of the security
+   implications of each of such options, a discussion of possible
+   interoperability implications if packets containing such options are
+   discarded, and specific advice regarding whether packets containing
+   these options should be permitted.
+
+4.4.1.  Pad1 (Type=0x00)
+
+4.4.1.1.  Uses
+
+   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.
+
+4.4.1.2.  Specification
+
+   This option is specified in [RFC8200].
+
+4.4.1.3.  Specific Security Implications
+
+   None.
+
+4.4.1.4.  Operational and Interoperability Impact If Blocked
+
+   Discarding packets that contain this option would potentially break
+   any protocol that relies on IPv6 options.
+
+4.4.1.5.  Advice
+
+   Intermediate systems should not discard packets based on the presence
+   of this option.
+
+4.4.2.  PadN (Type=0x01)
+
+4.4.2.1.  Uses
+
+   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.
+
+4.4.2.2.  Specification
+
+   This option is specified in [RFC8200].
+
+4.4.2.3.  Specific Security Implications
+
+   Because of the possible size of this option, it could be leveraged as
+   a large-bandwidth covert channel.
+
+4.4.2.4.  Operational and Interoperability Impact If Blocked
+
+   Discarding packets that contain this option would potentially break
+   any protocol that relies on IPv6 options.
+
+4.4.2.5.  Advice
+
+   Intermediate systems should not discard IPv6 packets based on the
+   presence of this option.
+
+4.4.3.  Tunnel Encapsulation Limit (Type=0x04)
+
+4.4.3.1.  Uses
+
+   The Tunnel Encapsulation Limit option can be employed to specify how
+   many further levels of nesting the packet is permitted to undergo.
+
+4.4.3.2.  Specification
+
+   This option is specified in [RFC2473].
+
+4.4.3.3.  Specific Security Implications
+
+   These are discussed in [RFC2473].
+
+4.4.3.4.  Operational and Interoperability Impact If Blocked
+
+   Discarding packets based on the presence of this option could result
+   in tunnel traffic being discarded.
+
+4.4.3.5.  Advice
+
+   Intermediate systems should not discard packets based on the presence
+   of this option.
+
+4.4.4.  Router Alert (Type=0x05)
+
+4.4.4.1.  Uses
+
+   The Router Alert option [RFC2711] is employed by a number of
+   protocols, including the Resource reSerVation Protocol (RSVP)
+   [RFC2205], Multicast Listener Discovery (MLD) [RFC2710] [RFC3810],
+   Multicast Router Discovery (MRD) [RFC4286], and General Internet
+   Signaling Transport (GIST) [RFC5971].  Its usage is discussed in
+   detail in [RFC6398].
+
+4.4.4.2.  Specification
+
+   This option is specified in [RFC2711].
+
+4.4.4.3.  Specific Security Implications
+
+   Since this option causes the contents of the packet to be inspected
+   by the handling device, this option could be leveraged for performing
+   DoS attacks.  The security implications of the Router Alert option
+   are discussed in detail in [RFC6398].
+
+4.4.4.4.  Operational and Interoperability Impact If Blocked
+
+   Discarding packets that contain this option would break any protocols
+   that rely on them, such as RSVP and multicast deployments.  Please
+   see Section 4.4.4.3 for further details.
+
+4.4.4.5.  Advice
+
+   Packets containing this option should be permitted in environments
+   where support for RSVP, multicast routing, or similar protocols is
+   required.
+
+4.4.5.  CALIPSO (Type=0x07)
+
+4.4.5.1.  Uses
+
+   This option is used for encoding explicit packet Sensitivity Labels
+   on IPv6 packets.  It is intended for use only within Multi-Level
+   Secure (MLS) networking environments that are both trusted and
+   trustworthy.
+
+4.4.5.2.  Specification
+
+   This option is specified in [RFC5570].
+
+4.4.5.3.  Specific Security Implications
+
+   Presence of this option in a packet does not by itself create any
+   specific new threat.  Packets with this option ought not normally be
+   seen on the global public Internet.
+
+4.4.5.4.  Operational and Interoperability Impact If Blocked
+
+   If packets with this option are discarded or if the option is
+   stripped from the packet during transmission from source to
+   destination, then the packet itself is likely to be discarded by the
+   receiver because it is not properly labeled.  In some cases, the
+   receiver might receive the packet but associate an incorrect
+   Sensitivity Label with the received data from the packet whose Common
+   Architecture Label IPv6 Security Option (CALIPSO) was stripped by a
+   middlebox (such as a packet scrubber).  Associating an incorrect
+   Sensitivity Label can cause the received information to be handled
+   either as more sensitive than it really is ("upgrading") or as less
+   sensitive than it really is ("downgrading"), either of which is
+   problematic.  As noted in [RFC5570], IPsec [RFC4301] [RFC4302]
+   [RFC4303] can be employed to protect the CALIPSO.
+
+4.4.5.5.  Advice
+
+   Recommendations for handling the CALIPSO depend on the deployment
+   environment rather than on whether an intermediate system 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 that particular intermediate system has been
+   deployed within an 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 [RFC5570], there
+   should be a configuration option to either (a) drop packets
+   containing the CALIPSO or (b) ignore the presence of the CALIPSO 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 [RFC5570], 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 as per [RFC5570].  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 configuration option 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.4.6.  SMF_DPD (Type=0x08)
+
+4.4.6.1.  Uses
+
+   This option is employed in the (experimental) Simplified Multicast
+   Forwarding (SMF) for unique packet identification for IPv6
+   Identification-based DPD (I-DPD) and as a mechanism to guarantee non-
+   collision of hash values for different packets when Hash-based DPD
+   (H-DPD) is used.
+
+4.4.6.2.  Specification
+
+   This option is specified in [RFC6621].
+
+4.4.6.3.  Specific Security Implications
+
+   None.  The use of transient numeric identifiers is subject to the
+   security and privacy considerations discussed in [NUMERIC-IDS].
+
+4.4.6.4.  Operational and Interoperability Impact If Blocked
+
+   Dropping packets containing this option within a Mobile Ad Hoc
+   Network (MANET) domain would break SMF.  However, dropping such
+   packets at the border of such domain would have no negative impact.
+
+4.4.6.5.  Advice
+
+   Intermediate systems that are not within a MANET domain should
+   discard packets that contain this option.
+
+4.4.7.  PDM (Type=0x0F)
+
+4.4.7.1.  Uses
+
+   This option is employed to convey sequence numbers and timing
+   information in IPv6 packets as a basis for measurements.
+
+4.4.7.2.  Specification
+
+   This option is specified in [RFC8250].
+
+4.4.7.3.  Specific Security Implications
+
+   These are discussed in [RFC8250].  Additionally, since this option
+   employs transient numeric identifiers, implementations may be subject
+   to the issues discussed in [NUMERIC-IDS].
+
+4.4.7.4.  Operational and Interoperability Impact If Blocked
+
+   Dropping packets containing this option will result in negative
+   interoperability implications for traffic employing this option as a
+   basis for measurements.
+
+4.4.7.5.  Advice
+
+   Intermediate systems should not discard packets based on the presence
+   of this option.
+
+4.4.8.  RPL Option (Type=0x23)
+
+4.4.8.1.  Uses
+
+   The RPL Option provides a mechanism to include routing information in
+   each datagram that a RPL router forwards.
+
+4.4.8.2.  Specification
+
+   This option is specified in [RFC9008].
+
+4.4.8.3.  Specific Security Implications
+
+   These are discussed in [RFC9008].
+
+4.4.8.4.  Operational and Interoperability Impact If Blocked
+
+   This option can survive outside of a RPL instance.  As a result,
+   discarding packets based on the presence of this option would break
+   some use cases for RPL (see [RFC9008]).
+
+4.4.8.5.  Advice
+
+   Intermediate systems should not discard IPv6 packets based on the
+   presence of this option.
+
+4.4.9.  Quick-Start (Type=0x26)
+
+4.4.9.1.  Uses
+
+   This IP option is used in the specification of Quick-Start for TCP
+   and IP, which is an experimental mechanism that allows transport
+   protocols, in cooperation with routers, to determine an allowed
+   sending rate at the start and, at times, in the middle of a data
+   transfer (e.g., after an idle period) [RFC4782].
+
+4.4.9.2.  Specification
+
+   This option is specified in [RFC4782] on the "Experimental" track.
+
+4.4.9.3.  Specific Security Implications
+
+   Section 9.6 of [RFC4782] notes that Quick-Start is vulnerable to two
+   kinds of attacks:
+
+   *  attacks to increase the routers' processing and state load and
+
+   *  attacks with bogus Quick-Start Requests to temporarily tie up
+      available Quick-Start bandwidth, preventing routers from approving
+      Quick-Start Requests from other connections
+
+   We note that if routers in a given environment do not implement and
+   enable the Quick-Start mechanism, only the general security
+   implications of IP options (discussed in Section 4.2) would apply.
+
+4.4.9.4.  Operational and Interoperability Impact If Blocked
+
+   If packets with IPv6 Quick Start options are blocked, the host trying
+   to establish a TCP connection will fall back to not including the
+   Quick Start option -- this means that the feature will be disabled,
+   and additional delays in connection establishment will be introduced
+   (as discussed in Section 4.7.2 of [RFC4782]).  We note, however, that
+   Quick-Start has been proposed as a mechanism that could be of use in
+   controlled environments and not as a mechanism that would be intended
+   or appropriate for ubiquitous deployment in the global Internet
+   [RFC4782].
+
+4.4.9.5.  Advice
+
+   Intermediate systems should not discard IPv6 packets based on the
+   presence of this option.
+
+4.4.10.  Deprecated (Type=0x4D)
+
+4.4.10.1.  Uses
+
+   No information has been found about this option type.
+
+4.4.10.2.  Specification
+
+   No information has been found about this option type.
+
+4.4.10.3.  Specific Security Implications
+
+   No information has been found about this option type; hence, it has
+   been impossible to perform the corresponding security assessment.
+
+4.4.10.4.  Operational and Interoperability Impact If Blocked
+
+   Unknown.
+
+4.4.10.5.  Advice
+
+   Intermediate systems should discard packets that contain this option.
+
+4.4.11.  RPL Option (Type=0x63)
+
+4.4.11.1.  Uses
+
+   The RPL Option provides a mechanism to include routing information in
+   each datagram that a RPL router forwards.
+
+4.4.11.2.  Specification
+
+   This option was originally specified in [RFC6553].  It has been
+   deprecated by [RFC9008].
+
+4.4.11.3.  Specific Security Implications
+
+   These are discussed in Section 5 of [RFC6553].
+
+4.4.11.4.  Operational and Interoperability Impact If Blocked
+
+   This option is meant to be employed within a RPL instance.  As a
+   result, discarding packets based on the presence of this option
+   outside of a RPL instance will not result in interoperability
+   implications.
+
+4.4.11.5.  Advice
+
+   Intermediate systems should discard packets that contain a RPL
+   Option.
+
+4.4.12.  MPL Option (Type=0x6D)
+
+4.4.12.1.  Uses
+
+   This option is used with the Multicast Protocol for Low power and
+   Lossy Networks (MPL), which provides IPv6 multicast forwarding in
+   constrained networks.
+
+4.4.12.2.  Specification
+
+   This option is specified in [RFC7731] and is meant to be included
+   only in Hop-by-Hop Options headers.
+
+4.4.12.3.  Specific Security Implications
+
+   These are discussed in [RFC7731].
+
+4.4.12.4.  Operational and Interoperability Impact If Blocked
+
+   Dropping packets that contain an MPL Option within an MPL network
+   would break the MPL.  However, dropping such packets at the border of
+   such networks will have no negative impact.
+
+4.4.12.5.  Advice
+
+   Intermediate systems should not discard packets based on the presence
+   of this option.  However, since this option has been specified for
+   the Hop-by-Hop Options header, such systems should consider the
+   discussion in Section 3.5.1.
+
+4.4.13.  Endpoint Identification (Type=0x8A)
+
+4.4.13.1.  Uses
+
+   The Endpoint Identification option was meant to be used with the
+   Nimrod routing architecture [NIMROD-DOC] but has never seen
+   widespread deployment.
+
+4.4.13.2.  Specification
+
+   This option is specified in [NIMROD-DOC].
+
+4.4.13.3.  Specific Security Implications
+
+   Undetermined.
+
+4.4.13.4.  Operational and Interoperability Impact If Blocked
+
+   None.
+
+4.4.13.5.  Advice
+
+   Intermediate systems should discard packets that contain this option.
+
+4.4.14.  ILNP Nonce (Type=0x8B)
+
+4.4.14.1.  Uses
+
+   This option is employed by the Identifier-Locator Network Protocol
+   for IPv6 (ILNPv6) to provide protection against off-path attacks for
+   packets when ILNPv6 is in use and as a signal during initial network-
+   layer session creation that ILNPv6 is proposed for use with this
+   network-layer session, rather than classic IPv6.
+
+4.4.14.2.  Specification
+
+   This option is specified in [RFC6744].
+
+4.4.14.3.  Specific Security Implications
+
+   These are discussed in [RFC6744].
+
+4.4.14.4.  Operational and Interoperability Impact If Blocked
+
+   Discarding packets that contain this option will break ILNPv6
+   deployments.
+
+4.4.14.5.  Advice
+
+   Intermediate systems should not discard packets based on the presence
+   of this option.
+
+4.4.15.  Line-Identification Option (Type=0x8C)
+
+4.4.15.1.  Uses
+
+   This option is used by an Edge Router to identify the subscriber
+   premises in scenarios where several subscriber premises may be
+   logically connected to the same interface of an Edge Router.
+
+4.4.15.2.  Specification
+
+   This option is specified in [RFC6788].
+
+4.4.15.3.  Specific Security Implications
+
+   These are discussed in [RFC6788].
+
+4.4.15.4.  Operational and Interoperability Impact If Blocked
+
+   Since this option is meant to be used when tunneling Neighbor
+   Discovery messages in some broadband network deployment scenarios,
+   discarding packets based on the presence of this option at
+   intermediate systems will result in no interoperability implications.
+
+4.4.15.5.  Advice
+
+   Intermediate systems should discard packets that contain this option.
+
+4.4.16.  Jumbo Payload (Type=0XC2)
+
+4.4.16.1.  Uses
+
+   The Jumbo Payload option provides the means for supporting payloads
+   larger than 65535 bytes.
+
+4.4.16.2.  Specification
+
+   This option is specified in [RFC2675].
+
+4.4.16.3.  Specific Security Implications
+
+   There are no specific issues arising from this option, except for
+   improper validity checks of the option and associated packet lengths.
+
+4.4.16.4.  Operational and Interoperability Impact If Blocked
+
+   Discarding packets based on the presence of this option will cause
+   IPv6 jumbograms to be discarded.
+
+4.4.16.5.  Advice
+
+   An operator should permit this option only in specific scenarios in
+   which support for IPv6 jumbograms is required.
+
+4.4.17.  Home Address (Type=0xC9)
+
+4.4.17.1.  Uses
+
+   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.
+
+4.4.17.2.  Specification
+
+   This option is specified in [RFC6275].
+
+4.4.17.3.  Specific Security Implications
+
+   There are no (known) additional security implications, other than
+   those discussed in [RFC6275].
+
+4.4.17.4.  Operational and Interoperability Impact If Blocked
+
+   Discarding IPv6 packets based on the presence of this option will
+   break Mobile IPv6.
+
+4.4.17.5.  Advice
+
+   Intermediate systems should not discard IPv6 packets based on the
+   presence of this option.
+
+4.4.18.  IP_DFF (Type=0xEE)
+
+4.4.18.1.  Uses
+
+   This option is employed with the (experimental) Depth-First
+   Forwarding (DFF) in unreliable networks.
+
+4.4.18.2.  Specification
+
+   This option is specified in [RFC6971].
+
+4.4.18.3.  Specific Security Implications
+
+   These are specified in [RFC6971].
+
+4.4.18.4.  Operational and Interoperability Impact If Blocked
+
+   Dropping packets containing this option within a routing domain that
+   is running DFF would break DFF.  However, dropping such packets at
+   the border of such domains will have no operational or
+   interoperability implications.
+
+4.4.18.5.  Advice
+
+   Intermediate systems that do not operate within a routing domain that
+   is running DFF should discard packets containing this option.
+
+4.4.19.  RFC3692-Style Experiment (Types = 0x1E, 0x3E, 0x5E, 0x7E, 0x9E,
+         0xBE, 0xDE, 0xFE)
+
+4.4.19.1.  Uses
+
+   These options can be employed for performing RFC3692-style
+   experiments.  It is only appropriate to use these values in
+   explicitly configured experiments; they must not be shipped as
+   defaults in implementations.
+
+4.4.19.2.  Specification
+
+   These options are specified in [RFC4727] in the context of
+   RFC3692-style experiments.
+
+4.4.19.3.  Specific Security Implications
+
+   The specific security implications will depend on the specific use of
+   these options.
+
+4.4.19.4.  Operational and Interoperability Impact If Blocked
+
+   For obvious reasons, discarding packets that contain these options
+   limits the ability to perform legitimate experiments across IPv6
+   routers.
+
+4.4.19.5.  Advice
+
+   Operators should determine, according to their own circumstances,
+   whether to discard packets containing these IPv6 options.
+
+4.5.  Advice on the Handling of Packets with Unknown IPv6 Options
+
+   We refer to IPv6 options that have not been assigned an IPv6 Option
+   Type in the corresponding registry, which is [IANA-IPV6-PARAM], as
+   "unknown IPv6 options".
+
+4.5.1.  Uses
+
+   New IPv6 options may be specified as part of future protocol work.
+
+4.5.2.  Specification
+
+   The processing of unknown IPv6 options is specified in [RFC8200].
+
+4.5.3.  Specific Security Implications
+
+   For obvious reasons, it is impossible to determine specific security
+   implications of unknown IPv6 options.
+
+4.5.4.  Operational and Interoperability Impact If Blocked
+
+   Discarding unknown IPv6 options may slow down the deployment of new
+   IPv6 options.  As noted in [IPv6-OPTIONS], the corresponding IANA
+   registry, which is [IANA-IPV6-PARAM], should be monitored such that
+   IPv6 option filtering rules are updated as new IPv6 options are
+   standardized.
+
+4.5.5.  Advice
+
+   Operators should determine, according to their own circumstances,
+   whether to discard packets containing unknown IPv6 options.
+
+5.  IANA Considerations
+
+   This document has no IANA actions.
+
+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
+   contain IPv6 EHs (and possibly IPv6 options) at IPv6 transit routers.
+   It is meant to improve the current situation of widespread dropping
+   of such IPv6 packets in those cases where the drops result from
+   improper configuration defaults or inappropriate advice in this area.
+
+   As discussed in Section 3.3, one of the underlying principles for the
+   advice provided in this document is that IPv6 packets with specific
+   EHs or options that may represent an attack vector for infrastructure
+   devices should be dropped.  While this policy helps mitigate some
+   specific attack vectors, the recommendations in this document will
+   not help to mitigate vulnerabilities based on implementation errors
+   [RFC9098].
+
+   We also note that depending on the router architecture, attempts to
+   filter packets based on the presence of IPv6 EHs or options might
+   itself represent an attack vector to network infrastructure devices
+   [RFC9098].
+
+8.  References
+
+8.1.  Normative References
+
+   [RFC1034]  Mockapetris, P., "Domain names - concepts and facilities",
+              STD 13, RFC 1034, DOI 10.17487/RFC1034, November 1987,
+              <https://www.rfc-editor.org/info/rfc1034>.
+
+   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
+              Requirement Levels", BCP 14, RFC 2119,
+              DOI 10.17487/RFC2119, March 1997,
+              <https://www.rfc-editor.org/info/rfc2119>.
+
+   [RFC2205]  Braden, R., Ed., Zhang, L., Berson, S., Herzog, S., and S.
+              Jamin, "Resource ReSerVation Protocol (RSVP) -- Version 1
+              Functional Specification", RFC 2205, DOI 10.17487/RFC2205,
+              September 1997, <https://www.rfc-editor.org/info/rfc2205>.
+
+   [RFC2473]  Conta, A. and S. Deering, "Generic Packet Tunneling in
+              IPv6 Specification", RFC 2473, DOI 10.17487/RFC2473,
+              December 1998, <https://www.rfc-editor.org/info/rfc2473>.
+
+   [RFC2675]  Borman, D., Deering, S., and R. Hinden, "IPv6 Jumbograms",
+              RFC 2675, DOI 10.17487/RFC2675, August 1999,
+              <https://www.rfc-editor.org/info/rfc2675>.
+
+   [RFC2710]  Deering, S., Fenner, W., and B. Haberman, "Multicast
+              Listener Discovery (MLD) for IPv6", RFC 2710,
+              DOI 10.17487/RFC2710, October 1999,
+              <https://www.rfc-editor.org/info/rfc2710>.
+
+   [RFC2711]  Partridge, C. and A. Jackson, "IPv6 Router Alert Option",
+              RFC 2711, DOI 10.17487/RFC2711, October 1999,
+              <https://www.rfc-editor.org/info/rfc2711>.
+
+   [RFC3692]  Narten, T., "Assigning Experimental and Testing Numbers
+              Considered Useful", BCP 82, RFC 3692,
+              DOI 10.17487/RFC3692, January 2004,
+              <https://www.rfc-editor.org/info/rfc3692>.
+
+   [RFC3810]  Vida, R., Ed. and L. Costa, Ed., "Multicast Listener
+              Discovery Version 2 (MLDv2) for IPv6", RFC 3810,
+              DOI 10.17487/RFC3810, June 2004,
+              <https://www.rfc-editor.org/info/rfc3810>.
+
+   [RFC4286]  Haberman, B. and J. Martin, "Multicast Router Discovery",
+              RFC 4286, DOI 10.17487/RFC4286, December 2005,
+              <https://www.rfc-editor.org/info/rfc4286>.
+
+   [RFC4301]  Kent, S. and K. Seo, "Security Architecture for the
+              Internet Protocol", RFC 4301, DOI 10.17487/RFC4301,
+              December 2005, <https://www.rfc-editor.org/info/rfc4301>.
+
+   [RFC4302]  Kent, S., "IP Authentication Header", RFC 4302,
+              DOI 10.17487/RFC4302, December 2005,
+              <https://www.rfc-editor.org/info/rfc4302>.
+
+   [RFC4303]  Kent, S., "IP Encapsulating Security Payload (ESP)",
+              RFC 4303, DOI 10.17487/RFC4303, December 2005,
+              <https://www.rfc-editor.org/info/rfc4303>.
+
+   [RFC4727]  Fenner, B., "Experimental Values In IPv4, IPv6, ICMPv4,
+              ICMPv6, UDP, and TCP Headers", RFC 4727,
+              DOI 10.17487/RFC4727, November 2006,
+              <https://www.rfc-editor.org/info/rfc4727>.
+
+   [RFC4782]  Floyd, S., Allman, M., Jain, A., and P. Sarolahti, "Quick-
+              Start for TCP and IP", RFC 4782, DOI 10.17487/RFC4782,
+              January 2007, <https://www.rfc-editor.org/info/rfc4782>.
+
+   [RFC5095]  Abley, J., Savola, P., and G. Neville-Neil, "Deprecation
+              of Type 0 Routing Headers in IPv6", RFC 5095,
+              DOI 10.17487/RFC5095, December 2007,
+              <https://www.rfc-editor.org/info/rfc5095>.
+
+   [RFC5533]  Nordmark, E. and M. Bagnulo, "Shim6: Level 3 Multihoming
+              Shim Protocol for IPv6", RFC 5533, DOI 10.17487/RFC5533,
+              June 2009, <https://www.rfc-editor.org/info/rfc5533>.
+
+   [RFC5570]  StJohns, M., Atkinson, R., and G. Thomas, "Common
+              Architecture Label IPv6 Security Option (CALIPSO)",
+              RFC 5570, DOI 10.17487/RFC5570, July 2009,
+              <https://www.rfc-editor.org/info/rfc5570>.
+
+   [RFC5971]  Schulzrinne, H. and R. Hancock, "GIST: General Internet
+              Signalling Transport", RFC 5971, DOI 10.17487/RFC5971,
+              October 2010, <https://www.rfc-editor.org/info/rfc5971>.
+
+   [RFC6275]  Perkins, C., Ed., Johnson, D., and J. Arkko, "Mobility
+              Support in IPv6", RFC 6275, DOI 10.17487/RFC6275, July
+              2011, <https://www.rfc-editor.org/info/rfc6275>.
+
+   [RFC6398]  Le Faucheur, F., Ed., "IP Router Alert Considerations and
+              Usage", BCP 168, RFC 6398, DOI 10.17487/RFC6398, October
+              2011, <https://www.rfc-editor.org/info/rfc6398>.
+
+   [RFC6550]  Winter, T., Ed., Thubert, P., Ed., Brandt, A., Hui, J.,
+              Kelsey, R., Levis, P., Pister, K., Struik, R., Vasseur,
+              JP., and R. Alexander, "RPL: IPv6 Routing Protocol for
+              Low-Power and Lossy Networks", RFC 6550,
+              DOI 10.17487/RFC6550, March 2012,
+              <https://www.rfc-editor.org/info/rfc6550>.
+
+   [RFC6553]  Hui, J. and JP. Vasseur, "The Routing Protocol for Low-
+              Power and Lossy Networks (RPL) Option for Carrying RPL
+              Information in Data-Plane Datagrams", RFC 6553,
+              DOI 10.17487/RFC6553, March 2012,
+              <https://www.rfc-editor.org/info/rfc6553>.
+
+   [RFC6554]  Hui, J., Vasseur, JP., Culler, D., and V. Manral, "An IPv6
+              Routing Header for Source Routes with the Routing Protocol
+              for Low-Power and Lossy Networks (RPL)", RFC 6554,
+              DOI 10.17487/RFC6554, March 2012,
+              <https://www.rfc-editor.org/info/rfc6554>.
+
+   [RFC6621]  Macker, J., Ed., "Simplified Multicast Forwarding",
+              RFC 6621, DOI 10.17487/RFC6621, May 2012,
+              <https://www.rfc-editor.org/info/rfc6621>.
+
+   [RFC6740]  Atkinson, RJ. and SN. Bhatti, "Identifier-Locator Network
+              Protocol (ILNP) Architectural Description", RFC 6740,
+              DOI 10.17487/RFC6740, November 2012,
+              <https://www.rfc-editor.org/info/rfc6740>.
+
+   [RFC6744]  Atkinson, RJ. and SN. Bhatti, "IPv6 Nonce Destination
+              Option for the Identifier-Locator Network Protocol for
+              IPv6 (ILNPv6)", RFC 6744, DOI 10.17487/RFC6744, November
+              2012, <https://www.rfc-editor.org/info/rfc6744>.
+
+   [RFC6788]  Krishnan, S., Kavanagh, A., Varga, B., Ooghe, S., and E.
+              Nordmark, "The Line-Identification Option", RFC 6788,
+              DOI 10.17487/RFC6788, November 2012,
+              <https://www.rfc-editor.org/info/rfc6788>.
+
+   [RFC6971]  Herberg, U., Ed., Cardenas, A., Iwao, T., Dow, M., and S.
+              Cespedes, "Depth-First Forwarding (DFF) in Unreliable
+              Networks", RFC 6971, DOI 10.17487/RFC6971, June 2013,
+              <https://www.rfc-editor.org/info/rfc6971>.
+
+   [RFC7045]  Carpenter, B. and S. Jiang, "Transmission and Processing
+              of IPv6 Extension Headers", RFC 7045,
+              DOI 10.17487/RFC7045, December 2013,
+              <https://www.rfc-editor.org/info/rfc7045>.
+
+   [RFC7112]  Gont, F., Manral, V., and R. Bonica, "Implications of
+              Oversized IPv6 Header Chains", RFC 7112,
+              DOI 10.17487/RFC7112, January 2014,
+              <https://www.rfc-editor.org/info/rfc7112>.
+
+   [RFC7401]  Moskowitz, R., Ed., Heer, T., Jokela, P., and T.
+              Henderson, "Host Identity Protocol Version 2 (HIPv2)",
+              RFC 7401, DOI 10.17487/RFC7401, April 2015,
+              <https://www.rfc-editor.org/info/rfc7401>.
+
+   [RFC7731]  Hui, J. and R. Kelsey, "Multicast Protocol for Low-Power
+              and Lossy Networks (MPL)", RFC 7731, DOI 10.17487/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
+              (IPv6) Specification", STD 86, RFC 8200,
+              DOI 10.17487/RFC8200, July 2017,
+              <https://www.rfc-editor.org/info/rfc8200>.
+
+   [RFC8250]  Elkins, N., Hamilton, R., and M. Ackermann, "IPv6
+              Performance and Diagnostic Metrics (PDM) Destination
+              Option", RFC 8250, DOI 10.17487/RFC8250, September 2017,
+              <https://www.rfc-editor.org/info/rfc8250>.
+
+   [RFC8754]  Filsfils, C., Ed., Dukes, D., Ed., Previdi, S., Leddy, J.,
+              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>.
+
+   [RFC9008]  Robles, M.I., Richardson, M., and P. Thubert, "Using RPI
+              Option Type, Routing Header for Source Routes, and IPv6-
+              in-IPv6 Encapsulation in the RPL Data Plane", RFC 9008,
+              DOI 10.17487/RFC9008, April 2021,
+              <https://www.rfc-editor.org/info/rfc9008>.
+
+8.2.  Informative References
+
+   [Biondi-2007]
+              Biondi, P. and A. Ebalard, "IPv6 Routing Header Security",
+              CanSecWest Security Conference, April 2007,
+              <http://www.secdev.org/conf/IPv6_RH_security-csw07.pdf>.
+
+   [Cisco-EH] Cisco Systems, "IPv6 Extension Headers Review and
+              Considerations", Whitepaper, October 2006,
+              <https://www.cisco.com/en/US/technologies/tk648/tk872/
+              technologies_white_paper0900aecd8054d37d.pdf>.
+
+   [FW-Benchmark]
+              Zack, E., "Firewall Security Assessment and Benchmarking
+              IPv6 Firewall Load Tests", IPv6 Hackers Meeting #1,
+              Berlin, Germany, June 2013,
+              <https://www.ipv6hackers.org/files/meetings/ipv6-hackers-
+              1/zack-ipv6hackers1-firewall-security-assessment-and-
+              benchmarking.pdf>.
+
+   [Huston-2022]
+              Huston, G. and J. Damas, "IPv6 Fragmentation and EH
+              Behaviours", IEPG Meeting at IETF 113", March 2022,
+              <https://iepg.org/2022-03-20-ietf113/huston-v6frag.pdf>.
+
+   [IANA-IPV6-PARAM]
+              IANA, "Internet Protocol Version 6 (IPv6) Parameters",
+              <https://www.iana.org/assignments/ipv6-parameters>.
+
+   [IANA-PROTOCOLS]
+              IANA, "Protocol Numbers",
+              <https://www.iana.org/assignments/protocol-numbers>.
+
+   [IPv6-OPTIONS]
+              Gont, F., Liu, W., and R. P. Bonica, "Transmission and
+              Processing of IPv6 Options", Work in Progress, Internet-
+              Draft, draft-gont-6man-ipv6-opt-transmit-02, 21 August
+              2015, <https://datatracker.ietf.org/doc/html/draft-gont-
+              6man-ipv6-opt-transmit-02>.
+
+   [JAMES]    Iurman, J., "Just Another Measurement of Extension header
+              Survivability (JAMES)", Work in Progress, Internet-Draft,
+              draft-vyncke-v6ops-james-02, 11 July 2022,
+              <https://datatracker.ietf.org/doc/html/draft-vyncke-v6ops-
+              james-02>.
+
+   [NIMROD-DOC]
+              "Nimrod Documentation",
+              <http://ana-3.lcs.mit.edu/~jnc/nimrod>.
+
+   [NIMROD-EID]
+              Lynn, C., "Endpoint Identifier Destination Option", Work
+              in Progress, Internet-Draft, draft-ietf-nimrod-eid-00, 2
+              March 1996, <https://datatracker.ietf.org/doc/html/draft-
+              ietf-nimrod-eid-00>.
+
+   [NUMERIC-IDS]
+              Gont, F. and I. Arce, "On the Generation of Transient
+              Numeric Identifiers", Work in Progress, Internet-Draft,
+              draft-irtf-pearg-numeric-ids-generation-11, 11 July 2022,
+              <https://datatracker.ietf.org/doc/html/draft-irtf-pearg-
+              numeric-ids-generation-11>.
+
+   [RFC2460]  Deering, S. and R. Hinden, "Internet Protocol, Version 6
+              (IPv6) Specification", RFC 2460, DOI 10.17487/RFC2460,
+              December 1998, <https://www.rfc-editor.org/info/rfc2460>.
+
+   [RFC3871]  Jones, G., Ed., "Operational Security Requirements for
+              Large Internet Service Provider (ISP) IP Network
+              Infrastructure", RFC 3871, DOI 10.17487/RFC3871, September
+              2004, <https://www.rfc-editor.org/info/rfc3871>.
+
+   [RFC6192]  Dugal, D., Pignataro, C., and R. Dunn, "Protecting the
+              Router Control Plane", RFC 6192, DOI 10.17487/RFC6192,
+              March 2011, <https://www.rfc-editor.org/info/rfc6192>.
+
+   [RFC7126]  Gont, F., Atkinson, R., and C. Pignataro, "Recommendations
+              on Filtering of IPv4 Packets Containing IPv4 Options",
+              BCP 186, RFC 7126, DOI 10.17487/RFC7126, February 2014,
+              <https://www.rfc-editor.org/info/rfc7126>.
+
+   [RFC7739]  Gont, F., "Security Implications of Predictable Fragment
+              Identification Values", RFC 7739, DOI 10.17487/RFC7739,
+              February 2016, <https://www.rfc-editor.org/info/rfc7739>.
+
+   [RFC7872]  Gont, F., Linkova, J., Chown, T., and W. Liu,
+              "Observations on the Dropping of Packets with IPv6
+              Extension Headers in the Real World", RFC 7872,
+              DOI 10.17487/RFC7872, June 2016,
+              <https://www.rfc-editor.org/info/rfc7872>.
+
+   [RFC9098]  Gont, F., Hilliard, N., Doering, G., Kumari, W., Huston,
+              G., and W. Liu, "Operational Implications of IPv6 Packets
+              with Extension Headers", RFC 9098, DOI 10.17487/RFC9098,
+              September 2021, <https://www.rfc-editor.org/info/rfc9098>.
+
+Acknowledgements
+
+   The authors would like to thank Ron Bonica for his work on earlier
+   draft versions of this document.
+
+   The authors of this document would like to thank (in alphabetical
+   order) Mikael Abrahamsson, Brian Carpenter, Tim Chown, Roman Danyliw,
+   Darren Dukes, Lars Eggert, David Farmer, Mike Heard, Bob Hinden,
+   Christian Huitema, Benjamin Kaduk, Erik Kline, Murray Kucherawy, Jen
+   Linkova, Carlos Pignataro, Alvaro Retana, Maria Ines Robles,
+   Zaheduzzaman Sarker, Donald Smith, Pascal Thubert, Ole Troan, Gunter
+   Van de Velde, Éric Vyncke, and Robert Wilton for providing valuable
+   comments on earlier draft versions of this document.
+
+   This document borrows some text and analysis from [RFC7126], which is
+   authored by Fernando Gont, Randall Atkinson, and Carlos Pignataro.
+
+   The authors would like to thank Warren Kumari and Éric Vyncke for
+   their guidance during the publication process for this document.
+
+   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).
+
+Authors' Addresses
+
+   Fernando Gont
+   SI6 Networks
+   Segurola y Habana 4310 7mo piso
+   Ciudad Autonoma de Buenos Aires
+   Argentina
+   Email: fgont@si6networks.com
+   URI:   https://www.si6networks.com
+
+
+   Will (Shucheng) Liu
+   Huawei Technologies
+   Bantian, Longgang District
+   Shenzhen
+   518129
+   China
+   Email: liushucheng@huawei.com