[Docs] [txt|pdf|xml|html] [Tracker] [Email] [Nits]



Network Working Group                                              Z. Li
Internet-Draft                                                   S. Peng
Intended status: Standards Track                                  Huawei
Expires: January 4, 2021                                    July 3, 2020


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

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
   working documents as Internet-Drafts.  The list of current Internet-
   Drafts is at https://datatracker.ietf.org/drafts/current/.



Li & Peng                Expires January 4, 2021                [Page 1]


Internet-Draft        HBH Forwarding Options Header            July 2020


   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 January 4, 2021.

Copyright Notice

   Copyright (c) 2020 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  . . . . . . . . . . . . . . . . . .   5
   3.  Proposal  . . . . . . . . . . . . . . . . . . . . . . . . . .   6
     3.1.  Hop-by-Hop Forwarding Options Header  . . . . . . . . . .   6
     3.2.  The usage of the existing Hop-by-Hop Options Header . . .   7
   4.  Security Considerations . . . . . . . . . . . . . . . . . . .   7
   5.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .   7
   6.  Appendix. Existing HBH Options  . . . . . . . . . . . . . . .   8
   7.  References  . . . . . . . . . . . . . . . . . . . . . . . . .   8
     7.1.  Normative References  . . . . . . . . . . . . . . . . . .   8
     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
   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



Li & Peng                Expires January 4, 2021                [Page 2]


Internet-Draft        HBH Forwarding Options Header            July 2020


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



Li & Peng                Expires January 4, 2021                [Page 3]


Internet-Draft        HBH Forwarding Options Header            July 2020


   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 & Peng                Expires January 4, 2021                [Page 4]


Internet-Draft        HBH Forwarding Options Header            July 2020


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.

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.



Li & Peng                Expires January 4, 2021                [Page 5]


Internet-Draft        HBH Forwarding Options Header            July 2020


   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.

   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:













Li & Peng                Expires January 4, 2021                [Page 6]


Internet-Draft        HBH Forwarding Options Header            July 2020


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

   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






Li & Peng                Expires January 4, 2021                [Page 7]


Internet-Draft        HBH Forwarding Options Header            July 2020


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:

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






Li & Peng                Expires January 4, 2021                [Page 8]


Internet-Draft        HBH Forwarding Options Header            July 2020


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

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-01 (work in progress), June
              2020.

   [I-D.ietf-6man-mtu-option]
              Hinden, R. and G. Fairhurst, "IPv6 Minimum Path MTU Hop-
              by-Hop Option", draft-ietf-6man-mtu-option-02 (work in
              progress), March 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>.





Li & Peng                Expires January 4, 2021                [Page 9]


Internet-Draft        HBH Forwarding Options Header            July 2020


   [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
   Beijing  100095
   China

   Email: lizhenbin@huawei.com


   Shuping Peng
   Huawei
   Beijing  100095
   China

   Email: pengshuping@huawei.com






















Li & Peng                Expires January 4, 2021               [Page 10]


Html markup produced by rfcmarkup 1.129d, available from https://tools.ietf.org/tools/rfcmarkup/