Network Working Group                                              Z. Li
Internet-Draft                                                   S. Peng
Intended status: Standards Track                     Huawei Technologies
Expires: August 24, 2021                                       G. Mishra
                                                            Verizon Inc.
                                                       February 20, 2021


                  Hop-by-Hop Forwarding Options Header
                      draft-li-6man-hbh-fwd-hdr-01

Abstract

   RFC8200 specifies the HBH header that is assumed to be processed by
   each hop in the delivery path of the packet.  However, RFC8200 also
   expects that nodes processing the HBH header have been explicitly
   configured to do so.  Therefore, it cannot be assumed that a HBH
   header present in the packet is processed.  It all depends on the
   configuration of each node across the path.  Moreover, in most of
   networks today, the processing of the HBH header is done in the
   control plane (slow processing path) which incurs several limitations
   among which resources consumption and security risk.

   For these reasons, over time, the Hop-by-Hop Options header has been
   sparsely used without any form of large scale deployment.  Also, most
   of already defined HBH options are forwarding options which contain
   forwarding plane information that needs not to be sent to the control
   plane.

   This document proposes a new Hop-by-Hop Forwarding Options Header in
   order to carry Hop-by-Hop options that are solely intended to and
   processed by the forwarding plane.  This new HBH header is confined
   in and dedicated to the forwarding plane while the current HBH header
   can still be used for control plane options.

Requirements Language

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
   document are to be interpreted as described in RFC 2119 [RFC2119].

Status of This Memo

   This Internet-Draft is submitted in full conformance with the
   provisions of BCP 78 and BCP 79.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF).  Note that other groups may also distribute



Li, et al.               Expires August 24, 2021                [Page 1]


Internet-Draft        HBH Forwarding Options Header        February 2021


   working documents as Internet-Drafts.  The list of current Internet-
   Drafts is at https://datatracker.ietf.org/drafts/current/.

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   This Internet-Draft will expire on August 24, 2021.

Copyright Notice

   Copyright (c) 2021 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 Simplified BSD License text as described in Section 4.e of
   the Trust Legal Provisions and are provided without warranty as
   described in the Simplified BSD License.

Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   2
   2.  Problem Statement and Motivation  . . . . . . . . . . . . . .   4
     2.1.  Specifications in RFC8200 . . . . . . . . . . . . . . . .   4
     2.2.  Classification of HBH Options . . . . . . . . . . . . . .   5
     2.3.  Service Requirements  . . . . . . . . . . . . . . . . . .   6
   3.  Proposal  . . . . . . . . . . . . . . . . . . . . . . . . . .   7
     3.1.  Hop-by-Hop Forwarding Options Header  . . . . . . . . . .   7
     3.2.  The usage of the existing Hop-by-Hop Options Header . . .   8
   4.  Security Considerations . . . . . . . . . . . . . . . . . . .   8
   5.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .   8
   6.  Appendix. Existing HBH Options  . . . . . . . . . . . . . . .   8
   7.  References  . . . . . . . . . . . . . . . . . . . . . . . . .   9
     7.1.  Normative References  . . . . . . . . . . . . . . . . . .   9
     7.2.  Informative References  . . . . . . . . . . . . . . . . .   9
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  10

1.  Introduction

   As specified in [RFC8200], the Hop-by-Hop (HBH) Options header is
   used to carry optional information that will be examined and
   processed by every node along a packet's delivery path if it is



Li, et al.               Expires August 24, 2021                [Page 2]


Internet-Draft        HBH Forwarding Options Header        February 2021


   explicitly configured to do so.  Since there is no specification on
   the possible configuration, nodes may be configured to ignore the
   Hop-by-Hop Options header, drop packets containing a Hop-by-Hop
   Options header, or assign packets containing a Hop-by-Hop Options
   header to a slow processing path.  [RFC6564] shows the Reports from
   the field indicating that some IP routers deployed within the global
   Internet are configured either to ignore or to drop packets having a
   hop-by-hop header.  As stated in [RFC7872], many network operators
   perceive HBH Options to be a breach of the separation between the
   forwarding and control planes.  Therefore, several network operators
   configured their nodes so to discard all packets containing the HBH
   Options Extension Header, while others configured nodes to forward
   the packet but to ignore the HBH Options.  [RFC7045] also states that
   hop-by-hop options are not handled by many high-speed routers or are
   processed only on a slow path.

   Generally, modern routers maintain the separation between forwarding
   plane and control plane with plentiful forwarding plane resource but
   constrained control plane resource.  In order to protect the control
   plane, policies are enforced in order to restrict access from the
   forwarding plane to the control plane.  Some operators severely rate-
   limit packets containing the HBH Options Extension Header when they
   are being sent to the control plane which will cause packet drops.

   The Hop-by-Hop Options can be categorized into Hop-by-Hop Forwarding
   Options and Hop-by-Hop Control Options, which contains information
   for the forwarding plane and the control plane of the nodes,
   respectively.  It is necessary and required to separate the two types
   of Hop-by-Hop options since they require different process
   procedures.  The packets carrying the Hop-by-Hop Forwarding Options
   are supposed to be maintained in the forwarding plane while the
   packets carrying the Hop-by-Hop Control Options are supposed to be
   sent to the control plane.  The current Hop-by-Hop Options header
   specified in [RFC8200] is used to carry both types of Hop-by-Hop
   options, and there is no way or indicator to separate the processing
   of the two kinds of Hop-by-Hop options using the current
   specifications in [RFC8200].

   In the current networks, the common implementation is to send all
   packets containing a HBH header to the control plane even if they
   contain only pad options (a forwarding option specified in
   [RFC8200]), resulting in various possible effects such as a risk of a
   DoS attack on the router, inconsistent drops among those packets due
   to rate limiting, or other effects.  This will impact the normal end-
   to-end IP forwarding of the network services.

   Therefore, due to these limitations, the HBH header has seen limited
   use and deployments, and protocol designers are recommended to avoid



Li, et al.               Expires August 24, 2021                [Page 3]


Internet-Draft        HBH Forwarding Options Header        February 2021


   using hop-by-hop options in any new protocols.  However, there have
   been over ten HBH options already specified in RFCs as listed in
   Appendix and the specified Forwarding Options are in the majority.
   Moreover, as IPv6 is being rapidly and widely deployed worldwide,
   more and more new services that requires hop-by-hop forwarding
   process behavior are emerging such as IOAM with IPv6 encapsulation
   [draft-ietf-ippm-ioam-ipv6-options].  Therefore, these requirements
   should be addressed urgently and properly by the use of an efficient
   HBH header when processed in the forwarding plane by transit nodes.

   This document proposes a Hop-by-Hop Forwarding Options header to
   carry the Hop-by-Hop forwarding options while the existing Hop-by-Hop
   Options header is used to carry the Hop-by-Hop control options only.

2.  Problem Statement and Motivation

   This section describes the problem statement and motivation for
   defining a new Hop-by-Hop Forwarding Options header.

2.1.  Specifications in RFC8200

   While [RFC2460] required that all nodes must examine and process the
   Hop-by-Hop Options header, with [RFC8200] it is expected that nodes
   along a packet's delivery path only examine and process the Hop-by-
   Hop Options header if explicitly configured to do so.  The
   configuration of the node determines the HBH processing behavior in
   the node which implies that each node may have a different behavior
   than the others.  As specified in [RFC8200], nodes may be configured
   to ignore the Hop-by-Hop Options header or drop packets containing a
   Hop-by-Hop Options header or assign packets containing a Hop-by-Hop
   Options header to a slow processing path.  These various behaviors
   are observed and described in specifications such as [RFC7045] and
   [RFC7872].  Due to such behaviors, new hop-by-hop options are not
   recommended in [RFC8200] hence the usability of HBH options is
   severely limited.

   The Hop-by-Hop Options header is identified by a Next Header value of
   zero in the IPv6 header.  Currently, the behaviors performed by the
   nodes on the packets containing a Hop-by-Hop Options header is only
   based on the value of this Next Header in the IPv6 header, that is,
   the value of the Next Header is the only trigger for the behaviors to
   be performed.

   In current networks, usually, nodes are configured in order to assign
   packets containing a Hop-by-Hop Options header (indicated by the Next
   Header = 0) to a slow processing path, i.e. to the control plane of
   the nodes.  Very often, such configuration is embedded in the
   implementation of the node and cannot be changed or reconfigured.



Li, et al.               Expires August 24, 2021                [Page 4]


Internet-Draft        HBH Forwarding Options Header        February 2021


2.2.  Classification of HBH Options

   The Hop-by-Hop Options header contains one or more Hop-by-Hop
   Options.  Each HBH Option contains a type identifier, i.e. Option
   Type.  The Hop-by-Hop Options can be categorized into two types: HBH
   Forwarding Options and HBH Control Options.  The HBH forward options
   contain information that is useful to a router's forwarding plane,
   e.g. the Jumbo Payload Option [RFC2675].  While the HBH Control
   Options contain information that is useful to a router's control
   plane, e.g. the Router Alert Option [RFC2711].  Currently, both HBH
   forwarding and control options are carried in the same HBH Options
   header.  There is no specification defining rules for differentiating
   the process of the two kinds of options.

   According to the common configuration in the current networks, i.e.
   to assign packets containing a Hop-by-Hop Options header (indicated
   by the Next Header = 0) to a slow processing path, all the HBH
   Options will be sent to the control plane of the nodes.  It impacts
   the normal IP forwarding procedure of the packets containing the HBH
   forwarding options which should be processed in the forwarding plane.
   As stated above, it also introduces a severe risk of DoS attacks
   using HBH headers.

   If all the HBH Options are forced to be processed first in the
   forwarding plane and then classified according to the HBH Option
   Type, it requires the consumption of the forwarding plane resources
   to make such processing selection, which will impact the forwarding
   efficiency.  Moreover, there are some existing nodes that are
   configured to assign the packets containing a Hop-by-Hop Options
   header to the control plane of the nodes cannot be reconfigured.

   Appendix of this document provides the classification of the
   currently defined HBH options into HBH forwarding options and HBH
   control options, and the HBH forwarding options are in the majority.

   IPv6 Extended Header limitations that need to be addressed to make
   HBH processing more efficient and viable in the fast path:

   [RFC8504] defines the IPv6 node requirements and how to protect a
   node from excessive header chain and excessive header options with
   various limitations that can be defined on a node.  [RFC8883] defines
   ICMPv6 Errors for discarding packets due to processing limits.  Per
   [RFC8200] HBH options must be processed serially.  However, an
   implementation of options processing can be made to be done with more
   parallelism in serial processing grouping of similar options to be
   processed in parallel.





Li, et al.               Expires August 24, 2021                [Page 5]


Internet-Draft        HBH Forwarding Options Header        February 2021


   The IPv6 standard does not currently limit the header chain length or
   number of options that can be encoded.

   Each Option is encoded in a TLV and so processing of a long list of
   TLVs is expensive.  Zero data length encoded options TLVs are a valid
   option.  A DOS vector could be easily generated by encoding 1000 HBH
   options (Zero data length) in a standard 1500 MTU packet.  So now
   Imagine if you have a Christmas tree long header chain to parse each
   with many options.

   Limit length of the header chain.

   Reduce the length of the HBH which is currently 2,048 bytes.

   Limit the maximum number of HBH.

   Limit the maximum number of options in an HBH.

2.3.  Service Requirements

   As listed in the Appendix, there have been over ten HBH options
   already specified in RFCs and the specified forwarding options are in
   the majority.  As IPv6 is being rapidly and widely deployed
   worldwide, more and more applications and network services are
   migrating to or adopting IPv6.  More and more new services that
   requires hop-by-hop forwarding process behavior are emerging and the
   HBH Options header is going to be utilized by new services in various
   use scenarios.

   As more services start utilizing the HBH Options header, more packets
   containing HBH Options are going to be injected into the networks.
   According to the current common configuration in most network
   deployments, all the packets of the new services are going to be sent
   to the control plane of the nodes, with the possible consequence of
   causing a DoS effect on the control plane.  The packets will be
   dropped and the normal IP forwarding may be severely impacted.  The
   deployment of new network services involving multi-vendor
   interoperability will become impossible.

   In-situ OAM with IPv6 encapsulation [draft-ietf-ippm-ioam-
   ipv6-options] is one of the examples.  IOAM in IPv6 is used to
   enhance diagnostics of IPv6 networks and complements other
   mechanisms, such as the IPv6 Performance and Diagnostic Metrics
   Destination Option described in [RFC8250].  The IOAM data fields are
   encapsulated in "option data" fields of the Hop-by-Hop Options header
   if Pre-allocated Tracing Option, Incremental Tracing Option, or Proof
   of Transit Option are carried [I-D.ietf-ippm-ioam-data], that is, the
   IOAM performs per hop.



Li, et al.               Expires August 24, 2021                [Page 6]


Internet-Draft        HBH Forwarding Options Header        February 2021


   As above mentioned, according to the current common configuration,
   all the packets employing IOAM are going to be sent to the control
   plane of every node along the path, it will cause a severe effect DoS
   on the control plane.  The packets will be inconsistently dropped and
   the normal IP forwarding will be severely impacted.  The end-to-end
   deployment of IOAM in a network involving nodes from multiple vendors
   is impossible.

3.  Proposal

3.1.  Hop-by-Hop Forwarding Options Header

   We propose to define a new HBH Forwarding Options header dedicated to
   carry the HBH Forwarding Options.  The IPv6 packets containing this
   Hop-by-Hop Forwarding Options header will be only processed in the
   forwarding plane and MUST NOT be sent to the control plane of the
   network nodes.

   The Hop-by-Hop Forwarding Options header is identified by a Next
   Header value of TBD in the IPv6 header and has the following format:


    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |  Next Header  |  Hdr Ext Len  |                               |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+                               +
    |                                                               |
    .                                                               .
    .                     HBH Forwarding Options                    .
    .                                                               .
    |                                                               |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

      Next Header         8-bit selector.  Identifies the type of header
                          immediately following the Hop-by-Hop
                          Forwarding Options header.

      Hdr Ext Len         8-bit unsigned integer.  Length of the
                          Hop-by-Hop Forwarding Options header in 8-octet
                          units, not including the first 8 octets.

      Options             Variable-length field, of length such that the
                          complete Hop-by-Hop Options header is an
                          integer multiple of 8 octets long.  Contains
                          one or more TLV-encoded HBH forwarding options.

   The Hop-by-Hop Forwarding Options header is recommended to be placed
   immediately after the IPv6 header.




Li, et al.               Expires August 24, 2021                [Page 7]


Internet-Draft        HBH Forwarding Options Header        February 2021


   The Hop-by-Hop Forwarding Options follows the formatting guidelines
   specified in the Appendix A. of [RFC8200].

3.2.  The usage of the existing Hop-by-Hop Options Header

   The existing Hop-by-Hop Options Header, identified by a Next Header
   value of zero in the IPv6 header, can still be used for carrying the
   HBH control options.  The IPv6 packets carrying such HBH control
   options will be sent to the control plane anyway, so it follows the
   exact current processing procedures.

4.  Security Considerations

   It is the same as the Security Considerations in [RFC8200] for the
   part related with the HBH Options header.

5.  IANA Considerations

   TBD: Next Header for Hop-by-Hop Forwarding Options Header

6.  Appendix.  Existing HBH Options

   We further classify the HBH Options into HBH Forwarding and HBH
   Control Options.  We can see that among all the defined HBH Options
   the HBH Forwarding Options are in the majority.

   HBH Forwarding Options:

   o  PAD Options: PAD1 and PADn [RFC8200]

   o  Jumbo Payload [RFC2675]

   o  RPL Option [RFC6553]

   o  Common Architecture Label 1Pv6 Security Option [RFC5570]

   o  SMF Option [RFC6621]

   o  MPL Option [RFC7731]

   o  DFF Option [RFC6971]

   o  MTU Option [I-D.ietf-6man-mtu-option]

   o  AltMark Option [I-D.ietf-6man-ipv6-alt-mark]

   HBH Control Options:




Li, et al.               Expires August 24, 2021                [Page 8]


Internet-Draft        HBH Forwarding Options Header        February 2021


   o  Router Alert Option [RFC2711]

   o  Quickstart Option [RFC4782]

7.  References

7.1.  Normative References

   [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>.

   [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>.

   [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>.

   [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>.

   [RFC8504]  Chown, T., Loughney, J., and T. Winters, "IPv6 Node
              Requirements", BCP 220, RFC 8504, DOI 10.17487/RFC8504,
              January 2019, <https://www.rfc-editor.org/info/rfc8504>.

   [RFC8883]  Herbert, T., "ICMPv6 Errors for Discarding Packets Due to
              Processing Limits", RFC 8883, DOI 10.17487/RFC8883,
              September 2020, <https://www.rfc-editor.org/info/rfc8883>.

7.2.  Informative References

   [I-D.ietf-6man-ipv6-alt-mark]
              Fioccola, G., Zhou, T., Cociglio, M., Qin, F., and R.
              Pang, "IPv6 Application of the Alternate Marking Method",
              draft-ietf-6man-ipv6-alt-mark-02 (work in progress),
              October 2020.







Li, et al.               Expires August 24, 2021                [Page 9]


Internet-Draft        HBH Forwarding Options Header        February 2021


   [I-D.ietf-6man-mtu-option]
              Hinden, R. and G. Fairhurst, "IPv6 Minimum Path MTU Hop-
              by-Hop Option", draft-ietf-6man-mtu-option-04 (work in
              progress), October 2020.

   [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>.

   [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>.

   [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>.

   [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>.

   [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>.

   [RFC6621]  Macker, J., Ed., "Simplified Multicast Forwarding",
              RFC 6621, DOI 10.17487/RFC6621, May 2012,
              <https://www.rfc-editor.org/info/rfc6621>.

   [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>.

   [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>.

Authors' Addresses

   Zhenbin Li
   Huawei Technologies

   Email: lizhenbin@huawei.com




Li, et al.               Expires August 24, 2021               [Page 10]


Internet-Draft        HBH Forwarding Options Header        February 2021


   Shuping Peng
   Huawei Technologies

   Email: pengshuping@huawei.com


   Gyan Mishra
   Verizon Inc.

   Email: gyan.s.mishra@verizon.com









































Li, et al.               Expires August 24, 2021               [Page 11]