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", . [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, . [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, . [RFC8200] Deering, S. and R. Hinden, "Internet Protocol, Version 6 (IPv6) Specification", STD 86, RFC 8200, DOI 10.17487/RFC8200, July 2017, . 13. Informative References [Hendriks] Hendriks, L., Velan, P., Schmidt, RO., Boer, P., and A. Aiko, "Threats and Surprises behind IPv6 Extension Headers", August 2017, . [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, . [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, . [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, . [RFC2473] Conta, A. and S. Deering, "Generic Packet Tunneling in IPv6 Specification", RFC 2473, DOI 10.17487/RFC2473, December 1998, . [RFC2675] Borman, D., Deering, S., and R. Hinden, "IPv6 Jumbograms", RFC 2675, DOI 10.17487/RFC2675, August 1999, . [RFC2711] Partridge, C. and A. Jackson, "IPv6 Router Alert Option", RFC 2711, DOI 10.17487/RFC2711, October 1999, . [RFC4782] Floyd, S., Allman, M., Jain, A., and P. Sarolahti, "Quick- Start for TCP and IP", RFC 4782, DOI 10.17487/RFC4782, January 2007, . [RFC5570] StJohns, M., Atkinson, R., and G. Thomas, "Common Architecture Label IPv6 Security Option (CALIPSO)", RFC 5570, DOI 10.17487/RFC5570, July 2009, . [RFC6275] Perkins, C., Ed., Johnson, D., and J. Arkko, "Mobility Support in IPv6", RFC 6275, DOI 10.17487/RFC6275, July 2011, . [RFC6398] Le Faucheur, F., Ed., "IP Router Alert Considerations and Usage", BCP 168, RFC 6398, DOI 10.17487/RFC6398, October 2011, . [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, . [RFC6621] Macker, J., Ed., "Simplified Multicast Forwarding", RFC 6621, DOI 10.17487/RFC6621, May 2012, . [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, . 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, . [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, . [RFC7731] Hui, J. and R. Kelsey, "Multicast Protocol for Low-Power and Lossy Networks (MPL)", RFC 7731, DOI 10.17487/RFC7731, February 2016, . [RFC8250] Elkins, N., Hamilton, R., and M. Ackermann, "IPv6 Performance and Diagnostic Metrics (PDM) Destination Option", RFC 8250, DOI 10.17487/RFC8250, September 2017, . 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]