IPv6 Hop-by-Hop Options Processing Procedures

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 2 August 2022.¶

Copyright Notice

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

Table of Contents

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 of IPv6 Hop-by-Hop options practical with the goal of making IPv6 Hop-by-Hop options useful to deploy and use in the Internet.¶

When published this document updates [RFC8200].¶

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

3. Terminology

This document uses the following loosely defined terms:¶

• Forwarding Plane: IPv6 hosts exchange user data through the forwarding plane. User data is processed by its recipient (i.e., an IPv6 host). User data can traverse intermediate nodes (i.e., routers) between its source and its destination. These intermediate nodes process metadata contained in packet headers. However, they do not process information contained in packet payloads.¶
• Control Plane: IPv6 routers exchange management and routing information with controllers. They also exchange routing information with one another. Management and routing information is processed by its recipient (i.e., an IPv6 router or controller). Management and control information can traverse intermediate nodes (i.e., routers) between its source and its destination. These intermediate nodes process metadata contained in packet headers. However, they do not process information contained in packet payloads. So, from their perspective, this information is user data.¶
• Fast Path: A path through a router that is optimized for forwarding packets without processing their payloads. The Fast Path may be supported by Application Specific Integrated Circuits (ASICS), Network Processor (NP), or other special purpose hardware. This is the usual processing path within a router taken by the forwarding plane.¶
• Slow Path: A path through a router that is capable of general purpose processing and is not optimized for any particular function. This is processing path is used for packets that require special processing or differ from assumptions made in Fast Path heuristics, or to process router control protocols used by the control plane.¶

NOTE: This distinct separation between hardware and software processing from [RFC6398] does not apply to all router architectures. However, a router that performs all or most processing in software might still incur more processing cost when providing special processing (aka Slow Path).¶

[RFC6192] is an example of how designs can separate control plane (Slow Path) and forwarding plane (Fast Path) functions.¶

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 full the forwarding rate (e.g., routers with no support on the Fast Path).¶
• Hop-by-Hop options would be sent to the Slow Path. This could could degrade the a router's performance and it's ability to process important control traffic.¶
• A mechanism that forces packets from any source to the routers "Slow Path" could be exploited as a Denial of Service attack against 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 were 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.¶
• 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 did not significantly improve deployment and use in the Internet. Essentially, it only documented how they were being used in the Internet at the time RFC8200 was published.¶

The main issues remain:¶

• Routers are commonly configured to drop transit packets containing hop-by-hop options that would have be processed in the Slow Path. This behavior is seen as protecting against a denial of service attack on the router. This is discussed in [RFC9098].¶
• Allowing multiple hop-by-hop options in a single packet makes it even more expensive in router resources to process these packets. It adds complexity to the number of permutations that might need to be processed.¶
• Any mechanism that can be used 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 needed 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 that RFC includes a good summary:¶

• "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 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 several changes to [RFC8200].¶

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

   01 - discard the packet.

   10 - discard the packet and, regardless of whether or not the
        packet's Destination Address was a multicast address, send an
        ICMP Parameter Problem, Code 2, message to the packet's
        Source Address, pointing to the unrecognized Option Type.

   11 - discard the packet and, only if the packet's Destination
        Address was not a multicast address, send an ICMP Parameter
        Problem, Code 2, message to the packet's Source Address,
        pointing to the unrecognized Option Type.

   10 - discard the packet and, regardless of whether or not the
        packet's Destination Address was a multicast address, MAY
        send an ICMP Parameter Problem, Code 2, message to the
        packet's Source Address, pointing to the unrecognized Option
        Type.

   11 - discard the packet and, only if the packet's Destination
        Address was not a multicast address, MAY send an ICMP
        Parameter Problem, Code 2, message to the packet's Source
        Address, pointing to the unrecognized Option Type.

6. New Hop-by-Hop Options

Any new IPv6 Hop-by-Hop option designed in the future should be designed to be processed at full forwarding rate (e.g., on a router's Fast Path). New options MUST NOT be defined that are not reasonably expected to be executed at full forwarding rates. New Hop-by-Hop options SHOULD have the following characteristics:¶

• Straight forward to process. That is, they should be designed to keep the time to process low.¶
• New Hop-by-Hop options should be designed to be the first option in a Hop-by-Hop options header.¶
• The size of an option should not extend beyond what can be reasonably expected to be executed at full forwarding rate (e.g., forwarded on a router's fast path).¶

Any new Hop-by-Hop option that is standardized that does not meet these criteria needs to explain in detail in its specification why this can not be accomplished and that there is a reasonable expectation that it can be proceed in most Fast Path implementations.¶

7. IANA Considerations

There are no actions required for IANA defined in this document.¶

8. Security Considerations

Security issues with IPv6 Hop-by-Hop options are well known and have been documented in several places, including [RFC6398], [RFC6192], and [RFC9098]. The main issue, as noted in Section 4, is that any mechanism that can be used 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. Due to this it's common for transit routers to drop packets with Hop-by-Hop options headers.¶

While Hop-by-Hop options are not required to be processed in the Slow Path, the Router Alert options is designed to do just that.¶

This document changes the way Hop-by-Hop options are processed in several ways that significantly reduces the attack surface. These changes include:¶

• All Hop-by-Hop options (with one exception) must be processed in the Fast Path. Only one HBH Option MUST be processed and additional HBH Options MAY be processed based on local configuration.¶
• Only the Router Alert option can be processed in the Slow Path, and the router must be configured to do so.¶
• Added criteria to allow control over how Router Alert options are processed and that a node configured to support these options must protect itself from attacks using the Router Alert.¶
• Limited the default number of Hop-by-Hop options that that can be in a packet to a single Hop-by-Hop option.¶
• Additional Hop-by-Hop options MAY be included, based on local configuration. Although nodes only process these additional Hop-by-Hop Options if configured to do so.¶
• Added restrictions to any future new Hop-by-Hop options that limit their size and computational requirements.¶

The authors believe that these changes significantly reduces the security issues relating to IPv6 Hop-by-Hop options and will enable them to be used safely in the Internet.¶

9. Acknowledgments

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

10. Change log [RFC Editor: Please remove]

draft-ietf-6man-hbh-processing-00, 2022-January-29:¶

• 6MAN Working Group Draft¶
• Reworked text to talk about processing HBH options at full forwarding rates, instead of "fast path"¶
• Revised Section 6 "New Hop-by-Hop Options" to allow variable sized HBH options, remove specific length requirements, and other clarifications.¶
• Editorial changes.¶

draft-hinden-6man-hbh-processing-01, 2021-June-2:¶

• Expanded terminology section to include Forwarding Plane and Control Plane.¶
• Changed draft that only one HBH Option MUST be processed and additional HBH Options MAY be processed based on local configuration.¶
• Clarified that all HBH options (with one exception) must be processed on the Fast Path.¶
• Kept the Router Alert options as the single exception for Slow Path processing.¶
• Rewrote and expanded section on New Hop-by-Hop Options.¶
• Removed requirement for HBH Option size and alignment.¶
• Removed sections evaluating currently defined HBH Options.¶
• Added content to the Security Considerations section.¶
• Added people to the acknowledgements section.¶
• Numerous editorial changes¶

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

• Initial draft.¶

Authors' Addresses