Internet-Draft HBH Options Processing March 2023
Hinden & Fairhurst Expires 12 September 2023 [Page]
Workgroup:
Network Working Group
Internet-Draft:
draft-ietf-xml2rfc-template-06
Updates:
8200, 7045 (if approved)
Published:
Intended Status:
Standards Track
Expires:
Authors:
R. Hinden
Check Point Software
G. Fairhurst
University of Aberdeen

IPv6 Hop-by-Hop Options Processing Procedures

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 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 and RFC7045.

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 12 September 2023.

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.

The editors focus for this document is to set a lower bound for the minimum number of hop-by-hop options that a node should process. This document does not discuss an upper bound. That topic is discussed in [I-D.ietf-6man-eh-limits].

When published, this document updates [RFC8200] and updates section 2.2 of [RFC7045].

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.

3. Terminology

This document uses the following loosely defined terms:

NOTE: [RFC6192] is an example of how designs can separate control plane (Slow Path) and forwarding plane (Fast Path) functions. The separation between hardware and software processing described in [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).

4. Background

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

[RFC6564] specified a uniform format for new IPv6 Extension Headers. It updated [RFC2460] and this update was incorporated into Section 4.8 of [RFC8200].

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

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.

The text regarding processing Hop-by Hop Options in [RFC8200] was not intended to change the processing of Hop-by-Hop options. It only documented how they were being used in the Internet at the time RFC8200 was published. This was a constraint on publishing the IPv6 specification as an IETF Standard.

The main issues remain:

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 Extension Headers we therefore recommend to support at least one EH".

The topic discussed in this section is also discussed in [I-D.ietf-v6ops-hbh].

"Transmission and Processing of IPv6 Extension Headers" [RFC7045] clarified how intermediate nodes should process extension headers. This document is generally consistent with [RFC7045], and was considered when [RFC2460] was updated and was itself replaced by [RFC8200]. This document updates [RFC8200] as described in the next section and consequently updates the description in Section 2.2 of [RFC7045].

This document defines a set of procedures for the Hop-by-Hop Option header that are intended to make the processing of hop-by-hop options practical in modern transit routers. The authors expectations are that some hop-by-hop options will be processed across the Internet while others will only be processed in a limited domain (e.g., where there is a specific service made available in that network segment that relies on one or more hop-by-hop options).

5. Hop-by-Hop Header Processing Procedures

This section describes several 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 of [RFC8200] 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] to specify that a node MUST process the first Option in the Hop-by-Hop Header at full forwarding rate (e.g. on the router's Fast Path) and MAY process additional Hop-by-Hop Options if configured to do so. The motivation for this change is to simplify the processing of Hop-by-Hop options as a part of normal forwarding.

Nodes creating packets with a Hop-by-Hop option header SHOULD by default include a single Hop-by-Hop Option in the packet and based on local configuration MAY include more Hop-by-Hop Options.

5.2. Hop-by-Hop Options Header Processing

Nodes SHOULD process the Hop-by-Hop Option header. If the node does not process the Hop-by-Hop Option header, it MUST forward the packet normally.

Nodes MUST process all Hop-by-Hop options at full forwarding rates. The one exception to this is the Router Alert Option [RFC2711]. See Section 5.3 for discussion of the Router Alert Option.

If the node is unable to process an option at the full forwarding rate, it MUST behave in the way specified for an unrecognized Option Type when the action bits were set to "00". That is, it must skip over this option and continue processing the header (as described in the next paragraph).

If there are more than one Hop-by-Hop options in the Hop-by-Hop Options header, the node MAY skip the rest of the options without having to examine these options using the "Hdr Ext Len" field in the Hop-by-Hop Options header. This field specifies the length of the Option Header in 8-octet units. The additional options do not need to be processed or verified.

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. The text is:

   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
        ICMPv6 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 ICMPv6 Parameter
        Problem, Code 2, message to the packet's Source Address,
        pointing to the unrecognized Option Type.

This document modifies this behaviour for the "10" and "11" values that the node MAY send an ICMP Parameter Problem, Code 2, message to the packet's Source Address, pointing to the unrecognized Option Type. The modified text for "10" and 11" values is:

   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.

The motivation for this change is to loosen the requirement to send ICMPv6 Parameter Problem messages by simplifying what the router needs to do when it performs forwarding of an Option Type it does not recognize.

When an ICMP Parameter Problem, Code 2, message is delivered to the source, the source can become aware that at least one node on the path has failed to recognize the option.

5.3. Router Alert Option

The Router Alert option [RFC2711] purpose is to tell the node that the packet needs additional processing on the Slow Path.

The Router Alert option includes a two-octet Value field that describes the protocol that is carried in the packet. The current values can be found in the IANA Router Alert Value registry [IANA-RA].

DISCUSSION

  • The Router Alert Option is a problem since its function is to do what this specification is proposing to eliminate, that is, to instruct a router to process the packet in the Slow Path. One approach would be to deprecate because current usage appears to be limited and packets containing Hop-by-Hop options are frequently dropped. Deprecation would allow current implementations to continue and its use could be phased out over time.
  • The authors' current thinking is that the Router Alert function may have reasonable potential use for new functions that have to be processed in the Slow Path. We think that keeping it as the single exception for Slow Path processing with the following restrictions is a reasonable compromise to allow future flexibility. These are compatible with Section 5 of [RFC6398].

As specified in [RFC2711] the top two bits of Option Type for the Router Alert option are always set to "00" indicating the node should skip over this option and continue processing the header in this case. A Fast Path implementation SHOULD verify that a Router Alert contains a protocol, as indicated by the Value field in the Router Alert option, that is configured as a protocol of interest to that router. A verified packet SHOULD be sent on the Slow Path for processing [RFC6398]. Otherwise, the router implementation SHOULD forward within the Fast Path (subject to all normal policies and forwarding rules).

Implementations of the IP Router Alert Option SHOULD offer the configuration option to simply ignore the presence of "IP Router Alert" in IPv4 and IPv6 packets" [RFC6398].

A node that is configured to process a Router Alert option using the Slow Path MUST protect itself from infrastructure attack that could result from processing on the Slow Path. This might include some combination of access control list to only permit from trusted nodes, rate limiting of processing, or other methods [RFC6398].

5.4. Configuration

Section 4 of [RFC8200] allows a router to control its 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.

This requires the node to examine the first two bits of the option even if it does not support the specific option. A node MUST drop the packet if the top two bits of the Option Type field of the first HBH option is non-zero as specified in Section 5.2.

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

6. New Hop-by-Hop Options

This section updates Section 4.8 of [RFC8200].

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, or at least without slowing processing of other packets). New options SHOULD NOT be defined that are not expected to be executed at full forwarding rate. New Hop-by-Hop options should have the following characteristics:

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 at full forwarding rate. This is consistant with [RFC6564].

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], [RFC7045] 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 needed for router management protocols (e.g., routing protocols, network management protocols, etc.) that may cause the router to fail or perform sub-optimally. Due to this it’s common for transit routers to drop packets with a Hop-by-Hop options header.

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

Some IPv6 nodes implement features that access more of the protocol information than a typical IPv6 router (e.g. [RFC9098]). Examples are nodes that provide virus-scanning, DDOS mitigation, Firewall/access control, traffic engineering, or traffic normalization. These nodes could be configured to drop packets when they are unable to access and process all extension headers, or are unable to locate and process the higher-layer packet information. This document provides guidance on the requirements concerning Hop-by-Hop Options.

Finally, the document notes that Internet protocol processing needs to be robust to malformed/malicious protocol fields. This requirement is not specific to Hop-by-Hop Options. It is important that implementations fail gracefully when a malformed or malicious Hop-by-Hop Option is encountered.

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

The authors intent is that these changes significantly reduce 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, Cheng Li, Eric Vyncke, Greg Mirksy, Xiao Min, Fernando Gont, Darren Dukes, Peng Shuping, Dave Thaler, [your name here], and other members of the 6MAN working group.

10. Change log [RFC Editor: Please remove]

draft-ietf-6man-hbh-processing-06, 2023-March-11:

draft-ietf-6man-hbh-processing-05, 2023-February-23:

draft-ietf-6man-hbh-processing-04, 2022-October-21:

draft-ietf-6man-hbh-processing-03, 2022-October-12:

draft-ietf-6man-hbh-processing-02, 2022-August-23:

draft-ietf-6man-hbh-processing-01, 2022-June-15:

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

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

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

11. 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, , <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, , <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, , <https://www.rfc-editor.org/info/rfc8200>.

12. Informative References

[Hendriks]
Hendriks, L., Velan, P., Schmidt, RO., Boer, P., and A. Aiko, "Threats and Surprises behind IPv6 Extension Headers", , , , <http://dl.ifip.org/db/conf/tma/tma2017/tma2017_paper22.pdf>.
[I-D.ietf-6man-eh-limits]
Herbert, T., "Limits on Sending and Processing IPv6 Extension Headers", Work in Progress, Internet-Draft, draft-ietf-6man-eh-limits-02, , <https://datatracker.ietf.org/doc/html/draft-ietf-6man-eh-limits-02>.
[I-D.ietf-v6ops-hbh]
Peng, S., Li, Z., Xie, C., Qin, Z., and G. S. Mishra, "Operational Issues with Processing of the Hop-by-Hop Options Header", Work in Progress, Internet-Draft, draft-ietf-v6ops-hbh-04, , <https://datatracker.ietf.org/doc/html/draft-ietf-v6ops-hbh-04>.
[IANA-RA]
"IPv6 Router Alert Option Values", <https://www.iana.org/assignments/ipv6-routeralert-values/ipv6-routeralert-values>.
[RFC1883]
Deering, S. and R. Hinden, "Internet Protocol, Version 6 (IPv6) Specification", RFC 1883, DOI 10.17487/RFC1883, , <https://www.rfc-editor.org/info/rfc1883>.
[RFC2460]
Deering, S. and R. Hinden, "Internet Protocol, Version 6 (IPv6) Specification", RFC 2460, DOI 10.17487/RFC2460, , <https://www.rfc-editor.org/info/rfc2460>.
[RFC2711]
Partridge, C. and A. Jackson, "IPv6 Router Alert Option", RFC 2711, DOI 10.17487/RFC2711, , <https://www.rfc-editor.org/info/rfc2711>.
[RFC6192]
Dugal, D., Pignataro, C., and R. Dunn, "Protecting the Router Control Plane", RFC 6192, DOI 10.17487/RFC6192, , <https://www.rfc-editor.org/info/rfc6192>.
[RFC6398]
Le Faucheur, F., Ed., "IP Router Alert Considerations and Usage", BCP 168, RFC 6398, DOI 10.17487/RFC6398, , <https://www.rfc-editor.org/info/rfc6398>.
[RFC6564]
Krishnan, S., Woodyatt, J., Kline, E., Hoagland, J., and M. Bhatia, "A Uniform Format for IPv6 Extension Headers", RFC 6564, DOI 10.17487/RFC6564, , <https://www.rfc-editor.org/info/rfc6564>.
[RFC7045]
Carpenter, B. and S. Jiang, "Transmission and Processing of IPv6 Extension Headers", RFC 7045, DOI 10.17487/RFC7045, , <https://www.rfc-editor.org/info/rfc7045>.
[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, , <https://www.rfc-editor.org/info/rfc7872>.
[RFC9098]
Gont, F., Hilliard, N., Doering, G., Kumari, W., Huston, G., and W. Liu, "Operational Implications of IPv6 Packets with Extension Headers", RFC 9098, DOI 10.17487/RFC9098, , <https://www.rfc-editor.org/info/rfc9098>.

Authors' Addresses

Robert M. Hinden
Check Point Software
959 Skyway Road
San Carlos, CA 94070
United States of America
Godred Fairhurst
University of Aberdeen
School of Engineering
Fraser Noble Building
Aberdeen
AB24 3UE
United Kingdom