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

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

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.¶
• 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:¶

• "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].¶

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

    01 - discard the packet.

    10 - discard the packet.

    11 - discard the packet.

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

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

Authors' Addresses