Internet-Draft HBH Options Processing June 2024
Hinden & Fairhurst Expires 7 December 2024 [Page]
Workgroup:
Network Working Group
Internet-Draft:
draft-ietf-6man-hbh-processing-20
Updates:
8200 (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 in IPv6 routers and hosts. It modifies the procedures specified in the IPv6 Protocol Specification (RFC 8200) to make processing of the IPv6 Hop-by-Hop Options header practical with the goal of making IPv6 Hop-by-Hop options useful to deploy and use in the Internet. When published, this document updates RFC 8200.

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 7 December 2024.

Table of Contents

1. Introduction

This document specifies procedures for processing IPv6 Hop-by-Hop options in IPv6 routers and hosts. It modifies the procedures specified in the IPv6 Protocol Specification [RFC8200] to make processing of IPv6 Hop-by-Hop Options header practical with the goal of making IPv6 Hop-by-Hop options useful to deploy and use at IPv6 routers and hosts.

An IPv6 packet includes Hop-by-Hop options by including a Hop-by-Hop Options header. The current list of defined Hop-by-Hop options can be found at [IANA-HBH]. The focus for this document is to set the minimum requirements for router processing of Hop-by-Hop options. It also discusses how Hop-by-Hop options are used by hosts. This document does not propose a specific bound to the number or size of Hop-by-Hop options that ought to be processed.

When published, this document updates [RFC8200].

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 and forwarding plane 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 for Hop-by-Hop options.

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, as observed in Section 2.2 of RFC7045: "it is to be expected that high-performance routers will either ignore it or assign packets containing it to a slow processing path". The reason behind this includes:

[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 specified ([RFC8200], Section 4) 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 whether they process the Hop-by-Hop Options header. In practice, routers may include configuration options to control which Hop-by-Hop options they will process.

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

The main issues remain:

Section 3 of RFC 6398 includes a summary of processing the IP Router Alert Option:

This is an example of the need to limit the resources that can be consumed when a particular function is executed and to avoid consuming control-plane resources where support for a function has not been configured.

There has been research that has 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". Operational aspects of the topics discussed in this section are further discussed in [I-D.ietf-v6ops-hbh].

"Transmission and Processing of IPv6 Extension Headers" [RFC7045] clarified how intermediate nodes should process Extension Headers. The present document is generally consistent with [RFC7045], and addresses an issue that was raised for discussion when [RFC2460] was updated and replaced by [RFC8200]. This document updates [RFC8200] as described in the next section and consequently clarifies the description in Section 2.2 of [RFC7045], using the language of BCP 14 [RFC2119] [RFC8174].

This document defines a set of procedures for the Hop-by-Hop Options header that are intended to make the processing of Hop-by-Hop options practical in modern routers. The common cases are that some Hop-by-Hop options will be processed across the Internet, while others will only be processed within a limited domain [RFC8799] (e.g., where a specific service is 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]. Section 5.1 describes processing of the Hop-by-Hop options Extension Header, and Section 5.2 describes processing of individual Hop-by-Hop Options. These sections updates the text in paragraphs 5 and 6 of Section 4 of [RFC8200] and as noted in Section 5.2 modifies Section 4.2 of [RFC8200].

5.1. Processing the Extension Header Carrying Hop-by-Hop Options

When a packet includes one or more Extension Headers, the Next Header field of the IPv6 Header identifies the type of Extension Header. It does not identify the transport protocol.

The Extension Header used to carry Hop-by-Hop options is defined in Section 4.3 of [RFC8200] and is identified by a Next Header value of 0 in the IPv6 header. Section 4.1 of [RFC8200] requires this Hop-by-Hop Options header to appear immediately after the IPv6 header. [RFC8200] also requires that a Hop-by-Hop Options header only appear at most once in a packet.

The Hop-by-Hop Options Header as defined in [RFC8200] can contain one or more Hop-by-Hop options.

Routers that process the Hop-by-Hop Options header SHOULD do so using the method defined in this document. Exceptions to this "SHOULD" include routers that are configured to drop packets with a Hop-by-Hop Options header to protect downstream devices that do not comply with this specification (see [RFC9288]).

Even if a router does not process the Hop-by-Hop Options header (for example, based on configuration), it MUST forward the packet normally based on the remaining Extension Header(s) after the Hop-by-Hop Options header. A router MUST NOT drop a packet solely because it contains an Extension Header carrying Hop-by-Hop options. A configuration could control that normal processing skips any or all of the Hop-by-Hop options carried in the Hop-by-Hop Options header.

It is expected that the Hop-by-Hop Options header will be processed by the destination(s). Hosts SHOULD process the Hop-by-Hop Options header in received packets. A constrained host is an example of a node that does not process the Hop-by-Hop Options header. If a destination does not process the Hop-by-Hop Options header, it MUST process the remainder of the packet normally.

5.1.1. Configuration Enabling Hop-by-Hop Header Processing

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 the path only examine and process the Hop-by-Hop Options header if explicitly configured to do so.

This document clarifies that a configuration could control whether processing skips any specific Hop-by-Hop options carried in the Hop-by-Hop Options header. A router that does not process the contents of the Hop-by-Hop Options header does not therefore process the option types of individual Option Types to perform any specified action.

5.2. Hop-by-Hop Options Processing

A source creating packets with a Hop-by-Hop Options header SHOULD use a method that is robust to network nodes selectively processing only some of the Hop-by-Hop options that are included in the packet, or that forward packets without the option(s) being processed (see Section 6.1). A source MAY, based on local configuration, allow only one Hop-by-Hop option to be included in a packet, or could allow more than one Hop-by-Hop options, but limit their size to increase the likelihood of successful transfer across a network path. Because some routers might only process one or a limited number of options in the Hop-by-Hop Option header, sources are motivated to order the placement of Hop-by-Hop options within the Hop-by-Hop Options header in decreasing order of importance for their processing by nodes on the path.

A router configuration needs to avoid vulnerabilities that arise when it cannot process the first Hop-by-Hop option at full forwarding rate. A router SHOULD NOT therefore be configured to process the first Hop-by-Hop option if this adversely impacts the aggregate forwarding rate. A router SHOULD process additional Hop-by-Hop options, if configured to do so, providing that these also do not adversely impact the aggregate forwarding rate.

If a router is unable to process a specific Hop-by-Hop option (or is not configured to do so), it SHOULD behave in the way specified for an unrecognized Option Type when the action bits were set to "00" and SHOULD skip the remaining options using the "Hdr Ext Len" field in the Hop-by-Hop Options header. This field specifies the length of the Options Header in 8-octet units. After skipping an option, the router continues processing the remaining options in the header. Skipped options do not need to be verified.

The Router Alert Option [RFC2711] is an exception to this because it is designed to tell a router that the packet needs additional processing, usually done in the control plane, see Section 5.2.1.

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 [RFC4443], 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 "01", "10", and "11" action bits, so that if a router is unable to process a specific Hop-by-Hop option (or is not configured to do so), it SHOULD behave in the way specified for an unrecognized Option Type when the action bits were set to "00". It also modifies the behaviour for the "10" and "11" values for the case when the packet is discarded, the node MAY send an ICMP Parameter Problem, Code 2 [RFC4443], message to the packet's Source Address, pointing to the unrecognized Option Type.

The modified text for "01", "10", and "11" values is:

    01 - MAY discard the packet, if so configured. Nodes should not
         rely on routers dropping these unrecognized Option Types.

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

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

When an ICMP Parameter Problem, Code 2, message is delivered to the source, it indicates that at least one node on the path has failed to recognize the option [RFC4443]. Generating any ICMP message incurs additional router processing. Reception of this message is not guaranteed, routers might be unable to be configured so that they do not generate these messages, and they are not always forwarded to the source. The motivation here is to loosen the requirement to send an ICMPv6 Parameter Problem message when a router forwards a packet without processing the list of all options.

5.2.1. Router Alert Option

The purpose of the Router Alert Option [RFC2711] is to tell a router that the packet needs additional processing in the control plane.

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

DISCUSSION

  • The function of a Router Alert Option can result in the processing that this specification is proposing to eliminate, that is, to instruct a router to process the packet in the control plane. This results in the concerns discussed in section 4. One approach would be to deprecate this, because current usage beyond the local network 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 Router Alert Option could have a potential for use with new functions that have to be processed in the control plane. Keeping this as the single exception for processing in the control plane with the following restrictions is a reasonable compromise to allow future flexibility. These restrictions are compatible with Section 5 of [RFC6398].

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

A node that is configured to process a Router Alert option MUST protect itself from infrastructure attack that could result from processing in the control plane. This might include some combination of an access control list to only permit this from trusted nodes, rate limiting of processing, or other methods [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 as if it does not recognize the Option Type and continue processing the header. An implementation that does recognize the Router Alert Option SHOULD verify that a Router Alert Option 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 to the control plane for further processing [RFC6398]. Otherwise, the router implementation SHOULD forward this packet subject to all normal policies and forwarding rules.

5.2.2. Configuration of Hop-by-Hop Option Processing

A router can be configured to process a specific Option. The set of enabled options SHOULD be configurable by the operator of the router.

A possible approach to implementing this is to maintain a lookup table based on Option Type of the IPv6 options that can be processed at full forwarding rate. This would allow a router to quickly determine if an option is supported and can be processed. If the option is not supported, then the router processes the option as described in Section 5.1 of this document.

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

6. Defining 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. 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 must include in the specification a detailed explanation why this cannot be accomplished and to show that there is a reasonable expectation that the option can be proceed at full forwarding rate. This is consistent with [RFC6564].

The general issue of robust operation of packets with new Hop-by-Hop options is described in Section 6.1 below.

6.1. Example of Robust Usage

Recent measurement surveys (e.g., [Cus23a]) show that packets that include Extension Headers can cause the packets to be dropped by some Internet paths. In a limited domain, routers can be configured or updated to provide support for any required Hop-by-Hop options.

The primary motivation of this document is to make it more practical to use Hop-by-Hop options beyond such a limited domain, with the expectation that applications can improve the quality of or add new features to their offered service when the path successfully forwards packets with the required Hop-by-Hop options and otherwise refrains from using these options. The focus is on incremental deployability. A protocol feature (such as using Hop-by-Hop options) is incrementally deployable if early adopters gain some benefit on the paths being used, even though other paths do not support the protocol feature. A source ought to order the Hop-by-Hop options that are carried in the Hop-by-Hop Options header in decreasing order of importance for processing by nodes on the path.

Methods can be developed that do not rely upon all routers to implement a specific Hop-by-Hop option (e.g., [RFC9268]), and that are robust when the current path drops packets that contain a Hop-by-Hop option (e.g., [RFC9098]).

For example, an application can be designed to first send a test packet that includes the required option or combination of options, and sends other packets without including the option. The application then does not send additional packets that include this option (or set of options) until the test packet(s) is acknowledged. The need for potential loss recovery when a path drops these test packets can be avoided by choosing packets that do not carry application data that needs to be reliably delivered.

Since the set of nodes forming a path can change with time, this discovery process ought to be repeated from time-to-time. The process of sending packets both with and without a specific header to discover whether a path can support a specific header is sometimes called "racing". Transport protocol racing is explained in [I-D.ietf-taps-arch], and "A/B protocol feature testing" is described in [Tram17].

7. IANA Considerations

This document requires no assignment actions by IANA.

The document updates the processing of Hop-by-Hop options. IANA is requested to add the published RFC as an additional reference for "Destination Options and Hop-by-Hop Options" in the Internet Protocol Version 6 (IPv6) Parameters Registry.

8. Security Considerations

Security issues with including 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 control plane or slow path can be exploited as a Denial-of-Service attack on a router by saturating the resources needed for router management (routing protocols, network management protocols, etc.) and cause the router to fail or perform sub-optimally.

While Hop-by-Hop options are not required to be processed in the control plane, the Router Alert Option is the one exception that is designed to be processed in the control plane.

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 Denial-of-Service 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. For example, a packet with an excessive number of options could consume significant resources; inclusion of a large extension header could potentially cause an on-path router to be unable to utilise hardware optimisations to process later headers (e.g., to perform equal cost multipath forwarding or port filtering). 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 the Hop-by-Hop Options header is processed in several ways that significantly reduce the attack surface. These changes include:

The intent of this document is that these changes significantly reduce the security issues relating to processing the IPv6 Hop-by-Hop Options header and to enable Hop-by-Hop options to be safely used in the Internet.

9. Acknowledgments

Helpful comments were received from Brian Carpenter, Ron Bonica, Ole Troan, Mike Heard, Tom Herbert, Cheng Li, Eric Vyncke, Greg Mirksy, Xiao Min, Fernando Gont, Darren Dukes, Peng Shuping, Dave Thaler, Ana Custura, Tim Winters, Jingrong Xie, Lorenzo Colitti, Toerless Eckert, Suresh Krishnan, Mikael Abrahamsson, Adrian Farrel, Jie Dong, Jen Linkova, Erik Kline, and other members of the 6MAN working group.

10. Change log [RFC Editor: Please remove]

draft-ietf-6man-hbh-processing-20, 2024-June 5

draft-ietf-6man-hbh-processing-19, 2024-June 4

draft-ietf-6man-hbh-processing-18, 2024-May 29:

draft-ietf-6man-hbh-processing-17, 2024-May 16:

draft-ietf-6man-hbh-processing-16, 2024-April 30:

draft-ietf-6man-hbh-processing-15, 2024-April 13:

draft-ietf-6man-hbh-processing-14, 2024-February-25:

draft-ietf-6man-hbh-processing-13, 2024-February-18:

draft-ietf-6man-hbh-processing-12, 2023-November-21:

draft-ietf-6man-hbh-processing-11, 2023-November-5:

draft-ietf-6man-hbh-processing-10, 2023-September-26:

draft-ietf-6man-hbh-processing-09, 2023-July-4:

draft-ietf-6man-hbh-processing-08, 2023-April-30:

draft-ietf-6man-hbh-processing-07, 2023-April-6:

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

[Cus23a]
Custura, A. and G. Fairhurst, "Internet Measurements: IPv6 Extension Header Edition", , IEPG, IETF-116 , , <http://www.iepg.org/2023-03-26-ietf116/eh.pdf>.
[Cus23b]
Custura, A., Secchi, R., Boswell, E., and G. Fairhurst, "Is it possible to extend IPv6?", Computer Communications X, , <https://www.sciencedirect.com/science/article/pii/S0140366423003705>.
[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-taps-arch]
Pauly, T., Trammell, B., Brunstrom, A., Fairhurst, G., and C. Perkins, "Architecture and Requirements for Transport Services", Work in Progress, Internet-Draft, draft-ietf-taps-arch-19, , <https://datatracker.ietf.org/doc/html/draft-ietf-taps-arch-19>.
[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-10, , <https://datatracker.ietf.org/doc/html/draft-ietf-v6ops-hbh-10>.
[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>.
[RFC4443]
Conta, A., Deering, S., and M. Gupta, Ed., "Internet Control Message Protocol (ICMPv6) for the Internet Protocol Version 6 (IPv6) Specification", STD 89, RFC 4443, DOI 10.17487/RFC4443, , <https://www.rfc-editor.org/info/rfc4443>.
[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>.
[RFC8799]
Carpenter, B. and B. Liu, "Limited Domains and Internet Protocols", RFC 8799, DOI 10.17487/RFC8799, , <https://www.rfc-editor.org/info/rfc8799>.
[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>.
[RFC9268]
Hinden, R. and G. Fairhurst, "IPv6 Minimum Path MTU Hop-by-Hop Option", RFC 9268, DOI 10.17487/RFC9268, , <https://www.rfc-editor.org/info/rfc9268>.
[RFC9288]
Gont, F. and W. Liu, "Recommendations on the Filtering of IPv6 Packets Containing IPv6 Extension Headers at Transit Routers", RFC 9288, DOI 10.17487/RFC9288, , <https://www.rfc-editor.org/info/rfc9288>.
[Tram17]
Trammell, B., Kuehlewind, M., De Vaere, P., Learmonth, IR., and G. Fairhurst, "Tracking Transport-Layer Evolution with PATH Spider", , ANRW , , <https://irtf.org/anrw/2017/anrw17-final16.pdf>.

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