Network Working Group S. Peng Internet-Draft Z. Li Intended status: Informational Huawei Technologies Expires: June 4, 2021 C. Xie China Telecom Z. Qin China Unicom G. Mishra Verizon Inc. December 1, 2020 Processing of the Hop-by-Hop Options Header draft-peng-v6ops-hbh-02 Abstract This document describes the processing of the Hop-by-Hop Options Header in today's routers in the aspects of standards specification, common implementations, and default operations. This document outlines the reasons why the Hop-by-Hop Options Header is rarely utilized in current networks. In addition, this document describes how the HBH could be used as a powerful mechanism allowing deployment and operations of new services requiring a more optimized way to leverage network resources of an infrastructure. The Hop-by-Hop Options Header is taken into consideration by several network operators, as a valuable container for carrying the information facilitating the introduction of new services. The desired, and proposed, processing behavior of the HBH and the migration strategies towards it are also suggested. 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/. Peng, et al. Expires June 4, 2021 [Page 1] Internet-Draft Processing HBH Opt Hdr December 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 June 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. Modern Router Architecture . . . . . . . . . . . . . . . . . 3 3. Specification of RFC8200 . . . . . . . . . . . . . . . . . . 4 4. Common Implementations . . . . . . . . . . . . . . . . . . . 5 4.1. Historical Reasons . . . . . . . . . . . . . . . . . . . 6 4.2. Consequences . . . . . . . . . . . . . . . . . . . . . . 6 5. Operators' typical processing . . . . . . . . . . . . . . . . 6 6. New Services . . . . . . . . . . . . . . . . . . . . . . . . 7 7. The desired processing behavior . . . . . . . . . . . . . . . 7 8. Migration strategies . . . . . . . . . . . . . . . . . . . . 8 9. Security Considerations . . . . . . . . . . . . . . . . . . . 9 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 9 12. References . . . . . . . . . . . . . . . . . . . . . . . . . 9 12.1. Normative References . . . . . . . . . . . . . . . . . . 9 12.2. Informative References . . . . . . . . . . . . . . . . . 10 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 11 1. Introduction Due to the historical reasons, such as incapable ASICs, limited IPv6 deployments and few service requirements, the most common implementation on the processing of the Hop-by-Hop Options header (HBH) is that the node will directly send the IPv6 packets with the Peng, et al. Expires June 4, 2021 [Page 2] Internet-Draft Processing HBH Opt Hdr December 2020 Hop-by-Hop Options header to the slow path (i.e. the control plane) of the node. The option type of each option carried within the Hop- by-Hop Options header will not even be examined before the packet is sent to the slow path. Very often, such processing behavior is the default configuration or, even worse, is the only behavior of the ipv6 implementation of the node. Such default processing behavior of the Hop-by-Hop Options header could result in various unpleasant effects such as a risk of DoS attack on the router control plane and inconsistent packet drops due to rate limiting on the interface between the router control plane and forwarding plane, which will impact the normal end-to-end IP forwarding of the network services. This actually introduced a circular problem: -> An implementation problem caused HBH to become a DoS vector. -> Because HBH is a DoS vector, network operators deployed ACLs that discard packets containing HBH. -> Because network operators deployed ACLs that discard packets containing HBH, network designers stopped defining new HBH Options. -> Because network designers stopped defining new HBH Options, the community was not motivated to fix the implementation problem that cause HBH to become a DoS vector. The purpose of this draft is to break the cycle described above, fixing the problem that caused HBH not actually being utilized in operators' networks so to allow a better leverage of the HBH capability. Driven by the wide deployments of IPv6 and ever-emerging new services, the Hop-by-Hop Options Header is taken as a valuable container for carrying the information to facilitate these new services. This document suggests the desired processing behavior and the migration strategies towards it. 2. Modern Router Architecture Modern router architecture design maintains a strict separation of the router control plane and its forwarding plane [RFC6192], as shown in Figure 1. Either the control plane or the forwarding plane is composed of both software and hardware, but each plane is responsible for different functionalities. Peng, et al. Expires June 4, 2021 [Page 3] Internet-Draft Processing HBH Opt Hdr December 2020 +----------------+ | Router Control | | Plane | +------+-+-------+ | | Interface Z | | +------+-+-------+ | Forwarding | Interface X ==[ Plane ]== Interface Y +----------------+ Figure 1. Modern Router Architecture The router control plane supports routing and management functions, handling packets destined to the device as well as building and sending packets originated locally on the device, and also drives the programming of the forwarding plane. The router control plane is generally realized in software on general-purpose processors, and its hardware is usually not optimized for high-speed packet handling. Because of the wide range of functionality, it is more susceptible to security vulnerabilities and a more likely a target for a DoS attack. The forwarding plane is typically responsible for receiving a packet on an incoming interface, performing a lookup to identify the packet's next hop and determine the outgoing interface towards the destination, and forwarding the packet out through the appropriate outgoing interface. Typically, forwarding plane functionality is realized in high-performance Application Specific Integrated Circuits (ASICs) or Network Processors (NPs) that are capable of handling very high packet rates. The router control plane interfaces with its forwarding plane through the Interface Z, as shown in the Figure 1, and the forwarding plane connects to other network devices via Interfaces such as X and Y. Since the router control plane is vulnerable to the DoS attack, usually a traffic filtering mechanism is implemented on Interface Z in order to block unwanted traffic. In order to protect the router control plane, a rate-limit mechanism is always implemented on the same interface. However, such rate limiting mechanism will always cause inconsistent packet drops, which will impact the normal IP forwarding. 3. Specification of RFC8200 [RFC8200] defines several IPv6 extension header types, including the Hop-by-Hop (HBH) Options header. As specified in [RFC8200], the Hop- by-Hop (HBH) Options header is used to carry optional information Peng, et al. Expires June 4, 2021 [Page 4] Internet-Draft Processing HBH Opt Hdr December 2020 that will be examined and processed by every node along a packet's delivery path, and it is identified by a Next Header value of zero in the IPv6 header. The Hop-by-Hop (HBH) Options header contains the following fields: -- Next Header: 8-bit selector, identifies the type of header immediately following the Hop-by-Hop Options header. -- Hdr Ext Len: 8-bit unsigned integer, the length of the Hop-by-Hop 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. The Hop-by-Hop (HBH) Options header carries a variable number of "options" that are encoded in the format of type-length-value (TLV). The highest-order two bits (i.e., the ACT bits) of the Option Type specify the action that must be taken if the processing IPv6 node does not recognize the Option Type. The third-highest-order bit (i.e., the CHG bit) of the Option Type specifies whether or not the Option Data of that option can change en route to the packet's final destination. 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. It means that the HBH processing behavior in a node depends on the configuration on it. However, in the current [RFC8200], there is no explicit specification on the possible configurations. Therefore, the 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 [RFC8200]. Because of these likely uncertain processing behaviors, new hop-by- hop options are not recommended. 4. Common Implementations In the current common implementations, once an IPv6 packet, with its Next Header field set to 0, arrives at a node, it will be directly sent to the slow path (i.e. the control plane) of the node. With such implementation, the value of the Next Header field in the IPv6 header is the only trigger for the default processing behavior. The option type of each option carried within the Hop-by-Hop Options Peng, et al. Expires June 4, 2021 [Page 5] Internet-Draft Processing HBH Opt Hdr December 2020 header will not even be examined before the packet is sent to the slow path. Very often, such processing behavior is the default configuration on the node, which is embedded in the implementation and cannot be changed or reconfigured. 4.1. Historical Reasons When IPv6 was first implemented on high-speed routers, HBH options were not yet well-understood and ASICs were not so capable as they are today. So, early IPv6 implementations dispatched all packets that contain HBH options to their slow path. 4.2. Consequences Such implementation introduces a risk of a DoS attack on the control plane of the node, and a large flow of IPv6 packets could congest the slow path, causing other critical functions (incl. routing and network management) that are executed on the control plane to fail. Rate limiting mechanisms will cause inconsistent packet drops and impact the normal end-to-end IP forwarding of the network services. 5. Operators' typical processing To mitigate this DoS vulnerability, many operators deployed Access Control Lists (ACLs) that discard all packets containing HBH Options. [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. Due to such behaviors observed and described in these specifications, new hop-by-hop options are not recommended in [RFC8200] hence the usability of HBH options is severely limited. Peng, et al. Expires June 4, 2021 [Page 6] Internet-Draft Processing HBH Opt Hdr December 2020 6. New Services As IPv6 is being rapidly and widely deployed worldwide, more and more applications and network services are migrating to or directly adopting IPv6. More and more new services that require HBH are emerging and the HBH Options header is going to be utilized by the new services in various scenarios. In-situ OAM with IPv6 encapsulation [I-D.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. Alternate Marking Method can be used as the passive performance measurement tool in an IPv6 domain. The AltMark Option is defined as a new IPv6 extension header option to encode alternate marking technique and Hop-by-Hop Options Header is considered [I-D.ietf-6man-ipv6-alt-mark]. The Minimum Path MTU Hop-by-Hop Option is defined in [I-D.ietf-6man-mtu-option] to record the minimum Path MTU along the forward path between a source host to a destination host. This Hop- by-Hop option is intended to be used in environments like Data Centers and on paths between Data Centers as well as other environments including the general Internet. It provides a useful tool for allowing to better take advantage of paths able to support a large Path MTU. 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. 7. The desired processing behavior The following requirements should be met: o The control plane SHOULD be protected from undesired traffic. Peng, et al. Expires June 4, 2021 [Page 7] Internet-Draft Processing HBH Opt Hdr December 2020 -* The HBH options header should not be directly sent to the control plane once the packets are received since these options may not aim for the control plane. -* The HBH options that are not supposed to be processed by the control plane should not be sent to the control plane, potentially causing the DoS attack. o Since generally the two types of HBH options (control plane and forwarding plane) serve different purposes and require different processing procedures on a node, they should be encoded separately and carried in different packets. o The packets carrying the HBH Forwarding Options are supposed to be maintained in the forwarding plane rather than being directly sent up to the control plane. While the packets carrying the HBH Control Options are supposed to be sent to the control plane. o The options aimed for the control plane are better not to consume the forwarding plane resources. o A simple and efficient way to discriminate the two types of HBH options is required. o The new deployments should be compatible with the existing deployments, since default configuration of some devices running in the networks cannot be changed or reconfigured. The update of the networks in operation will usually take time. o If the IPv6 extension header including the HBH options header of a packet cannot be recognized by the node, or the option in the HBH header is unknown to the node, and the node is not the destination of the packet, the packet should not be dropped or sent to the control plane, rather this unrecognized extension header should be skipped and the rest of the packet should be processed. 8. Migration strategies In order to achieve the desired processing behavior of the HBH options header and facilitate the ever-emerging new services to be deployed in operators' networks across multiple vendors' devices, the migration can happen in three parts as described below: 1. The source of the HBH options header encapsulation. The information to be carried in the HBH options header needs to be first categorized and encapsulated into either control options or forwarding options, and then encapsulated in different packets. Peng, et al. Expires June 4, 2021 [Page 8] Internet-Draft Processing HBH Opt Hdr December 2020 2. The nodes within the network. The nodes are updated to the proposed behavior introduced in the previous section. 3. The edge node of the network. The edge node should check whether the packet contains a HBH header with control or forwarding option. Packet with a control option may still be filtered and dropped while packets with forwarding option should be allowed by the ACL. If it is certain that there is no harm that can be introduced by the HBH options to the nodes and the services, they can also be allowed. Note: During the migration stage, the nodes that are not yet updated will stay with their existing configurations. 9. Security Considerations It is the same as the Security Considerations in [RFC8200] for the part related with the HBH Options header. 10. IANA Considerations This document does not include an IANA request. 11. Acknowledgements The authors would like to acknowledge Ron Bonica and Stefano Previdi for their valuable review and comments. 12. References 12.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, . [RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6 (IPv6) Specification", RFC 2460, DOI 10.17487/RFC2460, December 1998, . [RFC6192] Dugal, D., Pignataro, C., and R. Dunn, "Protecting the Router Control Plane", RFC 6192, DOI 10.17487/RFC6192, March 2011, . Peng, et al. Expires June 4, 2021 [Page 9] Internet-Draft Processing HBH Opt Hdr December 2020 [RFC7045] Carpenter, B. and S. Jiang, "Transmission and Processing of IPv6 Extension Headers", RFC 7045, DOI 10.17487/RFC7045, December 2013, . [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, . [RFC8200] Deering, S. and R. Hinden, "Internet Protocol, Version 6 (IPv6) Specification", STD 86, RFC 8200, DOI 10.17487/RFC8200, July 2017, . 12.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. [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. [I-D.ietf-ippm-ioam-data] Brockners, F., Bhandari, S., and T. Mizrahi, "Data Fields for In-situ OAM", draft-ietf-ippm-ioam-data-11 (work in progress), November 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", draft-ietf-ippm-ioam- ipv6-options-04 (work in progress), November 2020. [I-D.li-6man-hbh-fwd-hdr] Li, Z. and S. Peng, "Hop-by-Hop Forwarding Options Header", draft-li-6man-hbh-fwd-hdr-00 (work in progress), July 2020. Peng, et al. Expires June 4, 2021 [Page 10] Internet-Draft Processing HBH Opt Hdr December 2020 [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 Shuping Peng Huawei Technologies Beijing China Email: pengshuping@huawei.com Zhenbin Li Huawei Technologies Beijing China Email: lizhenbin@huawei.com Chongfeng Xie China Telecom China Email: xiechf@chinatelecom.cn Zhuangzhuang Qin China Unicom Beijing China Email: qinzhuangzhuang@chinaunicom.cn Gyan Mishra Verizon Inc. USA Email: gyan.s.mishra@verizon.com Peng, et al. Expires June 4, 2021 [Page 11]