IPv6 Hop-by-Hop Options Processing Procedures
draft-hinden-6man-hbh-processing-00

Document Type Active Internet-Draft (individual)
Authors Bob Hinden  , Gorry Fairhurst 
Last updated 2020-12-03
Stream (None)
Intended RFC status (None)
Formats plain text html xml pdf htmlized (tools) htmlized bibtex
Stream Stream state (No stream defined)
Consensus Boilerplate Unknown
RFC Editor Note (None)
IESG IESG state I-D Exists
Telechat date
Responsible AD (None)
Send notices to (None)
Network Working Group                                          R. Hinden
Internet-Draft                                      Check Point Software
Updates: 8200 (if approved)                                 G. Fairhurst
Intended status: Standards Track                  University of Aberdeen
Expires: 6 June 2021                                     3 December 2020

             IPv6 Hop-by-Hop Options Processing Procedures
                  draft-hinden-6man-hbh-processing-00

Abstract

   This document specifies procedures for how IPv6 Hop-by-Hop options
   are processed.  It modifies the procedures specified in the IPv6
   Protocol Specification (RFC8200) to make processing in routers more
   practical with the goal of making IPv6 Hop-by-Hop options useful to
   deploy in the Internet.  When published, this document updates
   RFC8200.

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

   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 6 June 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

Hinden & Fairhurst         Expires 6 June 2021                  [Page 1]
Internet-Draft           HBH Options Processing            December 2020

   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.  Requirements Language . . . . . . . . . . . . . . . . . . . .   2
   3.  Terminology . . . . . . . . . . . . . . . . . . . . . . . . .   3
   4.  Background  . . . . . . . . . . . . . . . . . . . . . . . . .   3
   5.  Hop-by-Hop Header Processing Procedures . . . . . . . . . . .   5
     5.1.  Hop-by-Hop Options Per Packet . . . . . . . . . . . . . .   5
     5.2.  Hop-by-Hop Headers Processing . . . . . . . . . . . . . .   6
     5.3.  Configuration . . . . . . . . . . . . . . . . . . . . . .   6
   6.  Hop-by-Hop Option Header Alignment  . . . . . . . . . . . . .   7
     6.1.  Hop-by-Hop Options that Meet Alignment Requirement  . . .   7
     6.2.  Hop-by-Hop Options that Must be Deprecated or Modified  .   8
     6.3.  Destination Options and Deprecated Hop-by-Hop Options . .   8
   7.  New Hop-by-Hop Options  . . . . . . . . . . . . . . . . . . .   8
   8.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .   8
   9.  Security Considerations . . . . . . . . . . . . . . . . . . .   8
   10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . .   8
   11. Change log [RFC Editor: Please remove]  . . . . . . . . . . .   8
   12. Normative References  . . . . . . . . . . . . . . . . . . . .   9
   13. Informative References  . . . . . . . . . . . . . . . . . . .   9
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  11

1.  Introduction

   This document specifies procedures for how IPv6 Hop-by-Hop options
   are processed.  It modifies the procedures specified in the IPv6
   Protocol Specification (RFC8200) to make processing in routers more
   practical with the goal of making IPv6 Hop-by-Hop options useful to
   deploy in the Internet.

   When published this document updates [RFC8200].

   The current list of defined Hop-by-Hop options can be found at
   [IANA-HBH].

2.  Requirements Language

   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.

Hinden & Fairhurst         Expires 6 June 2021                  [Page 2]
Internet-Draft           HBH Options Processing            December 2020

3.  Terminology

   This document uses the following loosely defined terms:

   *  Fast path: Hardware or Application-Specific Integrated Circuit
      (ASIC) processing path for packets.  This is the usual processing
      path within a router for IP datagrams.  It is sometimes also
      described as the forwarding plane.

   *  Slow path: Software processing path for packets.  This is a
      special processing path for packets that require special
      processing or differ from assumptions made in fast-path
      heuristics, or for router control protocols.  It is sometimes also
      described as the control plane.

4.  Background

   In the first version of the IPv6 specification, Hop-by-Hop options
   were required to be processed by all nodes, routers and hosts.  This
   proved to not be practical in high speed routers due to several
   factors, including:

   *  Inability to process the hop-by-hop options at wire speed in
      hardware.

   *  Hop-by-Hop options would be sent to the "slow path".  This could
      could degrade the routers performance and it's ability to process
      important control traffic.

   *  A mechanism that forces external packets to the routers "slow
      path" could be exploited as a Denial of Service attack on the
      router.

   *  Packets could contain multiple Hop-by-Hop options making the
      previous issues worse by increasing the complexity required to
      process them.

   When the IPv6 Specification was updated and published in July 2017 as
   [RFC8200], the procedures relating to hop-by-hop options are as
   follows:

      Extension headers (except for the Hop-by-Hop Options header) are
      not processed, inserted, or deleted by any node along a packet's
      delivery path, until the packet reaches the node (or each of the
      set of nodes, in the case of multicast) identified in the
      Destination Address field of the IPv6 header.

Hinden & Fairhurst         Expires 6 June 2021                  [Page 3]
Internet-Draft           HBH Options Processing            December 2020

      The Hop-by-Hop Options header is not inserted or deleted, but may
      be examined or processed by any node along a packet's delivery
      path, until the packet reaches the node (or each of the set of
      nodes, in the case of multicast) identified in the Destination
      Address field of the IPv6 header.  The Hop-by-Hop Options header,
      when present, must immediately follow the IPv6 header.  Its
      presence is indicated by the value zero in the Next Header field
      of the IPv6 header.

      NOTE: While [RFC2460] required that all nodes must examine and
      process the Hop-by-Hop Options header, it is now 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 changes meant that an implementation complied with the IPv6
   specification even if it did not process hop-by-hop options, and that
   it was expected that routers would add configuration information to
   control which hop-by-hop options they would process.

   Unfortunately, this did not improve the processing of Hop-by-Hop
   options and they are often not possible to be deployed and used in
   the Internet.  It merely documented how they were being used in the
   Internet.

   In hindsight, hop-by-hop options were still not practical to be used
   widely in the Internet.  Many operational routers are configured to
   drop all packets containing a hop-by-hop option header.  The main
   issues remain:

   *  Routers have been configured to drop transit data packets that
      would be processed in the fast path, this includes dropping hop-
      by-hop packets that would need to be processed in the fast path.

   *  Allowing multiple hop-by-hop options in a single packet makes it
      even more expensive in router resources to process these packets
      in the fast path.  It adds complexity to the number of
      permutations that might need to be processed.

   *  Any mechanism that can be used externally to force packets into
      the router's slow path can be exploited as a denial of service
      attack on a transit router by saturating the resources need for
      router management protocols (e.g., routing protocols, network
      management protocols, etc.) that may cause the router to fail.
      This issue for the Router Alert option, which intentionally places
      packets on the slow path, is discussed in [RFC6398].  Section 3 of
      this RFC includes a good summary:

Hinden & Fairhurst         Expires 6 June 2021                  [Page 4]
Internet-Draft           HBH Options Processing            December 2020

      "In a nutshell, the IP Router Alert Option does not provide a
      convenient universal mechanism to accurately and reliably
      distinguish between IP Router Alert packets of interest and
      unwanted IP Router Alert packets.  This, in turn, creates a
      security concern when the IP Router Alert Option is used, because,
      short of appropriate router-implementation-specific mechanisms,
      the router slow path is at risk of being flooded by unwanted
      traffic."

   There has been some academic research that discussed the general
   problem with dropping packets containing IPv6 extension headers,
   including the Hop-by-Hop Options header.  For example [Hendriks]
   states that "dropping all packets with Extension Headers, is a bad
   practice", and that "The share of traffic containing more than one EH
   however, is very small.  For the design of hardware able to handle
   the dynamic nature of EHs, we therefore recommend to support at least
   one EH"

   This document defines a set of procedures for the hop-by-hop option
   header that make the processing of hop-by-hop options practical in
   modern transit routers.

5.  Hop-by-Hop Header Processing Procedures

   This section describes three sets of changes to [RFC8200].

5.1.  Hop-by-Hop Options Per Packet

   The Hop-by-Hop Option Header as defined in Section 4.3 of [RFC8200]
   is identified by a Next Header value of 0 in the IPv6 header.
   Section 4.1 requires a Hop-by-Hop Options header to appear
   immediately after the IPv6 header.  [RFC8200] also requires that a
   Hop-by-Hop Options header can only appear once in a packet.

   The Hop-by-Hop Options Header as defined in [RFC8200] can contain one
   or more Hop-by-Hop options.  This document updates [RFC8200] such
   that there MUST only be one option contained in an Hop-by-Hop Options
   header in a single packet.  The motivation for this change is to
   simplify the processing of Hop-by-Hop options in the fast path.

   Nodes creating packets with a Hop-by-Hop option headers MUST only
   include a single option in the packet.  This also requires that all
   Hop-by-Hop Options MUST be 8-octet aligned.  See Section 6 for more
   detail.

   Nodes processing a packet with a Hop-by-Hop options header MUST
   discard the packet if there is more than one Hop-by-Hop option in
   that header.

Hinden & Fairhurst         Expires 6 June 2021                  [Page 5]
Internet-Draft           HBH Options Processing            December 2020

5.2.  Hop-by-Hop Headers Processing

   Section 4.2 of [RFC8200] defines an Option Type field in options that
   controls how the option is processed if the IPv6 node processing the
   option header does not recognize the Option Type.  This document
   modifies that behavior for options carried in an Hop-by-Hop Option
   header in two ways.

   IPv6 nodes MUST only process an Hop-by-Hop Options header if it can
   be done in the fast path of the router.  If the IPv6 node can not
   process the Hop-by-Hop Option header in the fast path is MUST skip
   over this option and continue processing the header normally.

   Section 4.2 of [RFC8200] defines the Option Type identifiers as
   internally encoded such that their highest-order 2 bits specify the
   action that must be taken if the processing IPv6 node does not
   recognize the Option Type.  This document modifies this behaviour for
   Hop-by-Hop options as follows:

       00 - skip over this option and continue processing the header.

       01 - discard the packet.

       10 - discard the packet.

       11 - discard the packet.

   The motivation for this change is to simplify what the router needs
   to do in the fast path when it can not recognize the Option Type.  It
   is no longer required to send ICMP Parameter Problem messages.

5.3.  Configuration

   Section 4 of [RFC8200] allows for a router to control it's processing
   of IPv6 Hop-by-Hop options by local configuration.  The text is:

      NOTE: While [RFC2460] required that all nodes must examine and
      process the Hop-by-Hop Options header, it is now 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.

   A possible approach to implementing this is to maintain a lookup
   table based on Option Type of the IPv6 options that are supported in
   the fast path.  This would allow for a node to quickly determine if
   an option is supported and can be processed.  If the option is not
   supported, then the node processes it as described in Section 5.2 of
   this document.

Hinden & Fairhurst         Expires 6 June 2021                  [Page 6]
Internet-Draft           HBH Options Processing            December 2020

   The actions of the lookup table SHOULD be configurable by the
   operator of the router.

6.  Hop-by-Hop Option Header Alignment

   [RFC8200] requires all extension headers to be 8-octet aligned.  The
   text from Section 4 is:

      Each extension header is an integer multiple of 8 octets long, in
      order to retain 8-octet alignment for subsequent headers.

   Two types of Pad options are defined to keep this alignment, that is
   Pad1 and PadN, if the options in an Destination Option Header or Hop-
   by-Hop Option Header do not result in 8-octet alignment.

   This document requires all Hop-by-Hop Options to be 8-octet aligned
   (see Section 5.1).  This eliminates the need for Pad options to be
   used in the Hop-by-Hop Option header to make them 8-octet aligned.

   The current list of defined Destination and Hop-by-Hop options can be
   found at [IANA-HBH].

   The following sections list current Hop-by-Hop Options that meet the
   alignment requirement defined here (Section 6.1) or if they need to
   be be deprecated or modified (Section 6.2).  Hop-by-Hop Options that
   have been deprecated, and Destination Options are listed separately
   in Section 6.3.  Pad Options (Pad1 and PadN), and RFC3692-style
   Experiment options are not listed.

6.1.  Hop-by-Hop Options that Meet Alignment Requirement

   The following Hop-by-Hop Options meet the alignment requirements
   defined in this section:

   *  Jumbo Payload [RFC2675]
   *  Path MTU Record Option [I-D.ietf-6man-mtu-option]
   *  RPL Option [I-D.ietf-roll-useofrplinfo] ***
   *  Quick-Start [RFC4782]
   *  CALIPSO [RFC5570] ***
   *  SMF_DPD [RFC6621] ***
   *  ILNP Nonce [RFC6744] ***
   *  MPL Option [RFC7731]

   *** Note: Need to verify that these options are 8-octet aligned.

Hinden & Fairhurst         Expires 6 June 2021                  [Page 7]
Internet-Draft           HBH Options Processing            December 2020

6.2.  Hop-by-Hop Options that Must be Deprecated or Modified

   The Hop-by-Hop Options listed in this section do not meet the
   alignment requirements defined in this section.  They either need to
   be deprecated or modified to support 8-octet alignment without the
   use of Pad options.  If there is interest in modifying them, it
   should be straightforward to make them have 8-octet alignment.

   *  Router Alert [RFC2711]
   *  IP_DFF [RFC6971]
   *  IOAM [I-D.ietf-ippm-ioam-ipv6-options]

6.3.  Destination Options and Deprecated Hop-by-Hop Options

   The options listed in this section are either Destination Options or
   Deprecated Hop-by-Hop Options.  8-octet alignment is not an issue.

   *  Tunnel Encapsulation Limit [RFC2473]
   *  RPL Option (DEPRECATED) [RFC6553]
   *  Endpoint Identification (DEPRECATED) [CHARLES LYNN]
   *  MPL Option (DEPRECATED) [RFC7731]
   *  Home Address [RFC6275]
   *  Line-Identification Option [RFC6788]
   *  Performance and Diagnostic Metrics (PDM) [RFC8250]

7.  New Hop-by-Hop Options

   Any new IPv6 Hop-by-Hop option defined in the future should have
   8-octet alignment without the use of any Pad options.  This
   requirement modifies Section 4.8 of [RFC8200].

8.  IANA Considerations

   This draft has no actions for the IANA.

9.  Security Considerations

   TBD

10.  Acknowledgments

   Helpful comments were received from Brian Carpenter, Ron Bonica, Ole
   Troan, [your name here], and other members of the 6MAN working group.

11.  Change log [RFC Editor: Please remove]

   draft-hinden-6man-hbh-processing-00, 2020-Nov-29: Initial draft.

Hinden & Fairhurst         Expires 6 June 2021                  [Page 8]
Internet-Draft           HBH Options Processing            December 2020

12.  Normative References

   [IANA-HBH] "Destination Options and Hop-by-Hop Options",
              <https://www.iana.org/assignments/ipv6-parameters/
              ipv6-parameters.xhtml#ipv6-parameters-2>.

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

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

13.  Informative References

   [Hendriks] Hendriks, L., Velan, P., Schmidt, RO., Boer, P., and A.
              Aiko, "Threats and Surprises behind IPv6 Extension
              Headers", August 2017,
              <http://dl.ifip.org/db/conf/tma/tma2017/
              tma2017_paper22.pdf>.

   [I-D.ietf-6man-mtu-option]
              Hinden, R. and G. Fairhurst, "IPv6 Minimum Path MTU Hop-
              by-Hop Option", Work in Progress, Internet-Draft, draft-
              ietf-6man-mtu-option-04, 23 October 2020,
              <https://tools.ietf.org/html/draft-ietf-6man-mtu-option-
              04>.

   [I-D.ietf-ippm-ioam-ipv6-options]
              Bhandari, S., Brockners, F., Pignataro, C., Gredler, H.,
              Leddy, J., Youell, S., Mizrahi, T., Kfir, A., Gafni, B.,
              Lapukhov, P., Spiegel, M., Krishnan, S., Asati, R., and M.
              Smith, "In-situ OAM IPv6 Options", Work in Progress,
              Internet-Draft, draft-ietf-ippm-ioam-ipv6-options-04, 1
              November 2020, <https://tools.ietf.org/html/draft-ietf-
              ippm-ioam-ipv6-options-04>.

   [I-D.ietf-roll-useofrplinfo]
              Robles, 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", Work in

Hinden & Fairhurst         Expires 6 June 2021                  [Page 9]
Internet-Draft           HBH Options Processing            December 2020

              Progress, Internet-Draft, draft-ietf-roll-useofrplinfo-42,
              12 November 2020, <https://tools.ietf.org/html/draft-ietf-
              roll-useofrplinfo-42>.

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

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

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

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

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

Hinden & Fairhurst         Expires 6 June 2021                 [Page 10]
Internet-Draft           HBH Options Processing            December 2020

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

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

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

Authors' Addresses

   Robert M. Hinden
   Check Point Software
   959 Skyway Road
   San Carlos, CA 94070
   United States of America

   Email: bob.hinden@gmail.com

   Godred Fairhurst
   University of Aberdeen
   School of Engineering, Fraser Noble Building
   Aberdeen
   AB24 3UE
   United Kingdom

   Email: gorry@erg.abdn.ac.uk

Hinden & Fairhurst         Expires 6 June 2021                 [Page 11]