diff options
Diffstat (limited to 'doc/rfc/rfc9268.txt')
| -rw-r--r-- | doc/rfc/rfc9268.txt | 1086 |
1 files changed, 1086 insertions, 0 deletions
diff --git a/doc/rfc/rfc9268.txt b/doc/rfc/rfc9268.txt new file mode 100644 index 0000000..127af78 --- /dev/null +++ b/doc/rfc/rfc9268.txt @@ -0,0 +1,1086 @@ + + + + +Internet Engineering Task Force (IETF) R. Hinden +Request for Comments: 9268 Check Point Software +Category: Experimental G. Fairhurst +ISSN: 2070-1721 University of Aberdeen + August 2022 + + + IPv6 Minimum Path MTU Hop-by-Hop Option + +Abstract + + This document specifies a new IPv6 Hop-by-Hop Option that is used to + record the Minimum Path MTU (PMTU) along the forward path between a + source host to a destination host. The recorded value can then be + communicated back to the source using the return Path MTU field in + the Option. + +Status of This Memo + + This document is not an Internet Standards Track specification; it is + published for examination, experimental implementation, and + evaluation. + + This document defines an Experimental Protocol for the Internet + community. This document is a product of the Internet Engineering + Task Force (IETF). It represents the consensus of the IETF + community. It has received public review and has been approved for + publication by the Internet Engineering Steering Group (IESG). Not + all documents approved by the IESG are candidates for any level of + Internet Standard; see Section 2 of RFC 7841. + + Information about the current status of this document, any errata, + and how to provide feedback on it may be obtained at + https://www.rfc-editor.org/info/rfc9268. + +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 + 1.1. Example Operation + 1.2. Use of the IPv6 Hop-by-Hop Options Header + 2. Motivation and Problem Solved + 3. Requirements Language + 4. Applicability Statements + 5. IPv6 Minimum Path MTU Hop-by-Hop Option + 6. Router, Host, and Transport Layer Behaviors + 6.1. Router Behavior + 6.2. Host Operating System Behavior + 6.3. Transport Layer Behavior + 6.3.1. Including the Option in an Outgoing Packet + 6.3.2. Validation of the Packet that Includes the Option + 6.3.3. Receiving the Option + 6.3.4. Using the Rtn-PMTU Field + 6.3.5. Detecting Path Changes + 6.3.6. Detection of Dropping Packets that Include the Option + 7. IANA Considerations + 8. Security Considerations + 8.1. Router Option Processing + 8.2. Network-Layer Host Processing + 8.3. Validating Use of the Option Data + 8.4. Direct Use of the Rtn-PMTU Value + 8.5. Using the Rtn-PMTU Value as a Hint for Probing + 8.6. Impact of Middleboxes + 9. Experiment Goals + 10. Implementation Status + 11. References + 11.1. Normative References + 11.2. Informative References + Appendix A. Examples of Usage + Acknowledgments + Authors' Addresses + +1. Introduction + + This document specifies a new IPv6 Hop-by-Hop (HBH) Option to record + the minimum Maximum Transmission Unit (MTU) along the forward path + between a source and a destination host. The source host creates a + packet with this Option and initializes the Min-PMTU field with the + value of the MTU for the outbound link that will be used to forward + the packet towards the destination host. + + At each subsequent hop where the Option is processed, the router + compares the value of the Min-PMTU field in the Option and the MTU of + its outgoing link. If the MTU of the link is less than the Min-PMTU, + it rewrites the value in the Option Data with the smaller value. + When the packet arrives at the destination host, the host can send + the value of the minimum Reported MTU for the path back to the source + host using the Rtn-PMTU field in the Option. The source host can + then use this value as input to the method that sets the Path MTU + (PMTU) used by upper-layer protocols. + + The IPv6 Minimum Path MTU Hop-by-Hop (MinPMTU HBH) Option is designed + to work with packet sizes that can be specified in the IPv6 header. + The maximum packet size that can be specified in an IPv6 header is + 65,535 octets (2^16). + + This method has the potential to complete Path MTU Discovery (PMTUD) + in a single round-trip time, even over paths that have successive + links, each with a lower MTU. + + The mechanism defined in this document is focused on unicast; it does + not describe multicast. That is left for future work. + +1.1. Example Operation + + The figure below illustrates the operation of the method. In this + case, the path between the source host and the destination host + comprises three links: the source has a link MTU of size MTU-S, the + link between routers R1 and R2 has an MTU of size 9000 bytes, and the + final link to the destination has an MTU of size MTU-D. + + +--------+ +----+ +----+ +-------+ + | | | | | | | | + | Sender +---------+ R1 +--------+ R2 +-------- + Dest. | + | | | | | | | | + +--------+ MTU-S +----+ 9000B +----+ MTU-D +-------+ + + Figure 1: An Example Path between the Source Host and the + Destination Host + + Three scenarios are described: + + * Scenario 1 considers all links to have a 9000 byte MTU, and the + method is supported by both routers. The initial Min-PMTU is not + modified along the path. Therefore, the PMTU is 9000 bytes. + + * Scenario 2 considers the link between R2 and the destination host + (MTU-D) to have an MTU of 1500 bytes. This is the smallest MTU. + Router R2 updates the Min-PMTU to 1500 bytes, and the method + correctly updates the PMTU to 1500 bytes. Had there been another + smaller MTU at a link further along the path that also supports + the method, the lower MTU would also have been detected. + + * Scenario 3 considers the case where the router preceding the + smallest link (R2) does not support the method, and the link to + the destination host (MTU-D) has an MTU of 1500 bytes. Therefore, + router R2 does not update the Min-PMTU to 1500 bytes. The method + then fails to detect the actual PMTU. + + In Scenarios 2 and 3, a lower PMTU would also fail to be detected in + the case where PMTUD had been used and an ICMPv6 Packet Too Big (PTB) + message had not been delivered to the sender [RFC8201]. + + These scenarios are summarized in the table below. "H" in R1 and/or + R2 columns means the router understands the MinPMTU HBH Option. + + +===+========+========+====+====+==========+=======================+ + | | MTU-S | MTU-D | R1 | R2 | Rec PMTU | Note | + +===+========+========+====+====+==========+=======================+ + | 1 | 9000 B | 9000 B | H | H | 9000 B | Endpoints attempt to | + | | | | | | | use a 9000 B PMTU. | + +---+--------+--------+----+----+----------+-----------------------+ + | 2 | 9000 B | 1500 B | H | H | 1500 B | Endpoints attempt to | + | | | | | | | use a 1500 B PMTU. | + +---+--------+--------+----+----+----------+-----------------------+ + | 3 | 9000 B | 1500 B | H | - | 9000 B | Endpoints attempt to | + | | | | | | | use a 9000 B PMTU but | + | | | | | | | need to implement a | + | | | | | | | method to fall back | + | | | | | | | to discover and use a | + | | | | | | | 1500 B PMTU. | + +---+--------+--------+----+----+----------+-----------------------+ + + Table 1: Three Scenarios That Arise from Using the Path Shown in + Figure 1 + +1.2. Use of the IPv6 Hop-by-Hop Options Header + + As specified in [RFC8200], IPv6 allows nodes to optionally process + the Hop-by-Hop header. Specifically, from Section 4 of [RFC8200]: + + | 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 Hop-by-Hop Option defined in this document is designed to take + advantage of this property of how Hop-by-Hop Options are processed. + Nodes that do not support this Option SHOULD ignore them. This can + mean that the Min-PMTU value does not account for all links along a + path. + +2. Motivation and Problem Solved + + The current state of Path MTU Discovery on the Internet is + problematic. The mechanisms defined in [RFC8201] are known to not + work well in all environments. It fails to work in various cases, + including when nodes in the middle of the network do not send ICMPv6 + PTB messages or rate-limited ICMPv6 messages or do not have a return + path to the source host. This results in many transport-layer + connections being configured to use smaller packets (e.g., 1280 + bytes) by default and makes it difficult to take advantage of paths + with a larger PMTU where they do exist. Applications that send large + packets are forced to use IPv6 fragmentation [RFC8200], which can + reduce the reliability of Internet communication [RFC8900]. + + Encapsulations and network-layer tunnels further reduce the payload + size available for a transport protocol to use. Also, some use cases + increase packet overhead, for example, Network Virtualization Using + Generic Routing Encapsulation (NVGRE) [RFC7637] encapsulates Layer 2 + (L2) packets in an outer IP header and does not allow IP + fragmentation. + + Sending larger packets can improve host performance, e.g., avoiding + limits to packet processing by the packet rate. An example of this + is how the packet-per-second rate required to reach wire speed on a + 10G link with 1280 byte packets is about 977K packets per second + (pps) vs. 139K pps for 9000 byte packets. + + The purpose of this document is to improve the situation by defining + a mechanism that does not rely on reception of ICMPv6 PTB messages + from nodes in the middle of the network. Instead, this provides + information to the destination host about the Minimum Path MTU and + sends this information back to the source host. This is expected to + work better than the current mechanisms based on [RFC8201]. + + A similar mechanism was proposed in 1988 for IPv4 in [RFC1063] by + Jeff Mogul, C. Kent, Craig Partridge, and Keith McCloghire. It was + later obsoleted in 1990 by [RFC1191], which is the current deployed + approach to Path MTU Discovery. In contrast, the method described in + this document uses the Hop-by-Hop Option of IPv6. It does not + replace PMTUD [RFC8201], Packetization Layer Path MTU Discovery + (PLPMTUD) [RFC4821], or Datagram Packetization Layer PMTU Discovery + (DPLPMTUD) [RFC8899] but rather is designed to compliment these + methods. + +3. 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. + +4. Applicability Statements + + The Path MTU Option is designed for environments where there is + control over the hosts and nodes that connect them and where there is + more than one MTU size in use, for example, in data centers and on + paths between data centers to allow hosts to better take advantage of + a path that is able to support a large PMTU. + + The design of the Option is so sufficiently simple that it can be + executed on a router's fast path. A successful experiment depends on + both implementation by host and router vendors and deployment by + operators. The contained use case of connections within and between + data centers could be a driver for deployment. + + The method could also be useful in other environments, including the + general Internet, and offers an advantage when this Hop-by-Hop Option + is supported on all paths. The method is more robust when used to + probe the path using packets that do not carry application data and + when also paired with a method like Packetization Layer PMTUD + [RFC4821] or Datagram Packetization Layer PMTU Discovery (DPLPMTUD) + [RFC8899]. + +5. IPv6 Minimum Path MTU Hop-by-Hop Option + + The Minimum Path MTU Hop-by-Hop Option has the following format: + + Option Option Option + Type Data Len Data + +--------+--------+--------+--------+---------+-------+-+ + |BBCTTTTT|00000100| Min-PMTU | Rtn-PMTU |R| + +--------+--------+--------+--------+---------+-------+-+ + + Figure 2: Format of the Minimum Path MTU Hop-by-Hop Option + + Option Type (see Section 4.2 of [RFC8200]): + + BB 00 Skip over this Option and continue processing. + + C 1 Option Data can change en route to the packet's final + destination. + + TTTTT 10000 Option Type assigned from IANA [IANA-HBH]. + + Length: 4 The size of the value field in Option Data + field supports PMTU values from 0 to 65,534 + octets, the maximum size represented by the + Path MTU Option. + + + Min-PMTU: n 16-bits. The minimum MTU recorded along the path + in octets, reflecting the smallest link MTU that + the packet experienced along the path. + A value less than the IPv6 minimum link + MTU [RFC8200] MUST be ignored. + + Rtn-PMTU: n 15-bits. The returned Path MTU field, carrying the 15 + most significant bits of the latest received Min-PMTU + field for the forward path. The value zero means that + no Reported MTU is being returned. + + R n 1-bit. R-Flag. Set by the source to signal that + the destination host should include the received + Rtn-PMTU field updated by the reported Min-PMTU value + when the destination host is to send a PMTU Option back + to the source host. + + NOTE: The encoding of the final two octets (Rtn-PMTU and R-Flag) + could be implemented by a mask of the latest received Min-PMTU value + with 0xFFFE, discarding the right-most bit and then performing a + logical 'OR' with the R-Flag value of the sender. This encoding fits + in the minimum-sized Hop-by-Hop Option header. + +6. Router, Host, and Transport Layer Behaviors + +6.1. Router Behavior + + Routers that are not configured to support Hop-by-Hop Options are not + expected to examine or process the contents of this Option [RFC8200]. + + Routers that support Hop-by-Hop Options but are not configured to + support this Option SHOULD skip over this Option and continue to + process the header [RFC8200]. + + Routers that support this Option MUST compare the value of the Min- + PMTU field with the MTU configured for the outgoing link. If the MTU + of the outgoing link is less than the Min-PMTU, the router rewrites + the Min-PMTU in the Option to use the smaller value. (The router + processing is performed without checking the valid range of the Min- + PMTU or the Rtn-PMTU fields.) + + A router MUST ignore and MUST NOT change the Rtn-PMTU field or the + R-Flag in the Option. + +6.2. Host Operating System Behavior + + The PMTU entry associated with the destination in the host's + destination cache [RFC4861] SHOULD be updated after detecting a + change using the IPv6 Minimum Path MTU Hop-by-Hop Option. This + cached value can be used by other flows that share the host's + destination cache. + + The value in the host destination cache SHOULD be used by PLPMTUD to + select an initial PMTU for a flow. The cached PMTU is only increased + by PLPMTUD when the Packetization Layer determines the path actually + supports a larger PMTU [RFC4821] [RFC8899]. + + When requested to send an IPv6 packet with the MinPMTU HBH Option, + the source host includes the Option in an outgoing packet. The + source host MUST fill the Min-PMTU field with the MTU configured for + the link over which it will send the packet on the next hop towards + the destination host. + + When a host includes the Option in a packet it sends, the host SHOULD + set the Rtn-PMTU field to the previously cached value of the received + Minimum Path MTU for the flow in the Rtn-PMTU field (see + Section 6.3.3). If this value is not set (for example, because there + is no cached reported Min-PMTU value), the Rtn-PMTU field value MUST + be set to zero. + + The source host MAY request the destination host to return the + reported Min-PMTU value by setting the R-Flag in the Option of an + outgoing packet. The R-Flag SHOULD NOT be set when the MinPMTU HBH + Option was sent solely to provide requested feedback on the return + Path MTU to avoid each response generating another response. + + The destination host controls when to send a packet with this Option + in response to an R-Flag, as well as which packets to include it in. + The destination host MAY limit the rate at which it sends these + packets. + + A destination host only sets the R-Flag if it wishes the source host + to also return the discovered PMTU value for the path from the + destination to the source. + + The normal sequence of operation of the R-Flag using the terminology + from the diagram in Figure 1 is: + + 1. The source sends a probe to the destination. The sender sets the + R-Flag. + + 2. The destination responds by sending a probe including the + received Min-PMTU as the Rtn-PMTU. A destination that does not + wish to probe the return path sets the R-Flag to 0. + +6.3. Transport Layer Behavior + + This Hop-by-Hop Option is intended to be used with a Path MTU + Discovery method. + + PLPMTUD [RFC8899] uses probe packets for two distinct functions: + + * Probe packets are used to confirm connectivity. Such probes can + be of any size up to the Packetization Layer Path MTU (PLPMTU). + These probe packets are sent to solicit a response using the path + to the remote node. These probe packets can carry the Hop-by-Hop + PMTU Option, providing the final size of the packet does not + exceed the current PLPMTU. After validating that the packet + originates from the path (Section 4.6.1 of [RFC8899]), the PLPMTUD + method can use the reported size from the Hop-by-Hop Option as the + next search point when it resumes the search algorithm. (This use + resembles the use of the PTB_SIZE information in Section 4.6.2 of + [RFC8899].) + + * A second use of probe packets is to explore if a path supports a + packet size greater than the current PLPMTU. If this probe packet + is successfully delivered (as determined by the source host), then + the PLPMTU is raised to the size of the successful probe. These + probe packets do not usually set the Path MTU Hop-by-Hop Option. + See Section 1.2 of [RFC8899]. Section 4.1 of [RFC8899] also + describes ways that a probe packet can be constructed, depending + on whether the probe packets carry application data. + + The PMTU Hop-by-Hop Option probe can be sent on packets that include + application data but needs to be robust to potential loss of the + packet (i.e., with the possibility that retransmission might be + needed if the packet is lost). + + Using a PMTU probe on packets that do not carry application data will + avoid the need for loss recovery if a router on the path drops + packets that set this Option. (This avoids the transport needing to + retransmit a lost packet that includes this Option.) This is the + normal default format for both uses of probes. + +6.3.1. Including the Option in an Outgoing Packet + + The upper-layer protocol can request the MinPMTU HBH Option to be + included in an outgoing IPv6 packet. A transport protocol (or upper- + layer protocol) can include this Option only on specific packets used + to test the path. This Option does not need to be included in all + packets belonging to a flow. + + NOTE: Including this Option in a large packet (e.g., one larger than + the present PMTU) is not likely to be useful, since the large packet + would itself be dropped by any link along the path with a smaller + MTU, preventing the Min-PMTU information from reaching the + destination host. + + Discussion: + + * In the case of TCP, the Option could be included in a packet that + carries a TCP segment sent after the connection is established. A + segment without data could be used to avoid the need to retransmit + this data if the probe packet is lost. The discovered value can + be used to inform PLPMTUD [RFC4821]. + + NOTE: A TCP SYN can also negotiate the Maximum Segment Size (MSS), + which acts as an upper limit to the packet size that can be sent + by a TCP sender. If this Option were to be included in a TCP SYN, + it could increase the probability that the SYN segment is lost + when routers on the path drop packets with this Option (see + Section 6.3.6), which could have an unwanted impact on the result + of racing Options [TAPS-ARCH] or feature negotiation. + + * The use with datagram transport protocols (e.g., UDP) is harder to + characterize because applications using datagram transports range + from very short-lived (low data-volume applications) exchanges to + longer (bulk) exchanges of packets between the source and + destination hosts [RFC8085]. + + * Simple-exchange protocols (i.e., low data-volume applications + [RFC8085] that only send one or a few packets per transaction) + might assume that the PMTU is symmetrical. That is, the PMTU is + the same in both directions or at least not smaller for the return + path. This optimization does not hold when the paths are not + symmetric. + + * The MinPMTU HBH Option can be used with ICMPv6 [RFC4443]. This + requires a response from the remote node and therefore is + restricted to use with ICMPv6 echo messages. The MinPMTU HBH + Option could provide additional information about the PMTU that + might be supported by a path. This could be used as a diagnostic + tool to measure the PMTU of a path. As with other uses, the + actual supported PMTU is only confirmed after receiving a response + to a subsequent probe of the PMTU size. + + * A datagram transport can utilize DPLPMTUD [RFC8899]. For example, + QUIC (see Section 14.3 of [RFC9000]) can use DPLPMTUD to determine + whether the path to a destination will support a desired maximum + datagram size. When using the IPv6 MinPMTU HBH Option, the Option + could be added to an additional QUIC PMTU probe that is of minimal + size (or one no larger than the currently supported PMTU size). + Once the return Path MTU value in the MinPMTU HBH Option has been + learned, DPLPMTUD can be triggered to test for a larger PLPMTU + using an appropriately sized PLPMTU probe packet (see + Section 5.3.1 of [RFC8899]). + + * The use of this Option with DNS and DNSSEC over UDP is expected to + work for paths where the PMTU is symmetric. The DNS server will + learn the PMTU from the DNS query messages. If the Rtn-PMTU value + is smaller, then a large DNSSEC response might be dropped and the + known problems with PMTUD will then occur. DNS and DNSSEC over + transport protocols that can carry the PMTU ought to work. + + * This method also can be used with anycast to discover the PMTU of + the path, but the use needs to be aware that the anycast binding + might change. + +6.3.2. Validation of the Packet that Includes the Option + + An upper-layer protocol (e.g., transport endpoint) using this Option + needs to provide protection from data injection attacks by off-path + devices [RFC8085]. This requires a method to assure that the + information in the Option Data is provided by a node on the path. + This validates that the packet forms a part of an existing flow, + using context available at the upper layer. For example, a TCP + connection or UDP application that maintains the related state and + uses a randomized ephemeral port would provide this basic validation + to protect from off-path data injection; see Section 5.1 of + [RFC8085]. IPsec [RFC4301] and TLS [RFC8446] provide greater + assurance. + + The upper layer discards any received packet when the packet + validation fails. When packet validation fails, the upper layer MUST + also discard the associated Option Data from the MinPMTU HBH Option + without further processing. + +6.3.3. Receiving the Option + + For a connection-oriented upper-layer protocol, caching of the + received Min-PMTU could be implemented by saving the value in the + connection context at the transport layer. A connectionless upper + layer (e.g., one using UDP) requires the upper-layer protocol to + cache the value for each flow it uses. + + A destination host that receives a MinPMTU HBH Option with the R-Flag + SHOULD include the MinPMTU HBH Option in the next outgoing IPv6 + packet for the corresponding flow. + + A simple mechanism could only include this Option (with the Rtn-PMTU + field set) the first time this Option is received or when it notifies + a change in the Minimum Path MTU. This limits the number of packets, + including the Option packets, that are sent. However, this does not + provide robustness to packet loss or recovery after a sender loses + state. + + Discussion: + + * Some upper-layer protocols send packets less frequently than the + rate at which the host receives packets. This provides less + frequent feedback of the received Rtn-PMTU value. However, a host + always sends the most recent Rtn-PMTU value. + +6.3.4. Using the Rtn-PMTU Field + + The Rtn-PMTU field provides an indication of the PMTU from on-path + routers. It does not necessarily reflect the actual PMTU between the + source and destination hosts. Care therefore needs to be exercised + in using the Rtn-PMTU value. Specifically: + + * The actual PMTU can be lower than the Rtn-PMTU value because the + Min-PMTU field was not updated by a router on the path that did + not process the Option. + + * The actual PMTU may be lower than the Rtn-PMTU value because there + is a Layer 2 device with a lower MTU. + + * The actual PMTU may be larger than the Rtn-PMTU value because of a + corrupted, delayed, or misordered response. A source host MUST + ignore a Rtn-PMTU value larger than the MTU configured for the + outgoing link. + + * The path might have changed between the time when the probe was + sent and when the Rtn-PMTU value received. + + IPv6 requires that every link in the Internet have an MTU of 1280 + octets or greater. A node MUST ignore a Rtn-PMTU value less than + 1280 octets [RFC8200]. + + To avoid unintentional dropping of packets that exceed the actual + PMTU (e.g., Scenario 3 in Section 1.1), the source host can delay + increasing the PMTU until a probe packet with the size of the Rtn- + PMTU value has been successfully acknowledged by the upper layer, + confirming that the path supports the larger PMTU. This probing + increases robustness but adds one additional path round-trip time + before the PMTU is updated. This use resembles that of PTB messages + in Section 4.6 of DPLPMTUD [RFC8899] (with the important difference + being that a PTB message can only seek to lower the PMTU, whereas + this Option could trigger a probe packet to seek to increase the + PMTU). + + Section 5.2 of [RFC8201] provides guidance on the caching of PMTU + information and also the relation to IPv6 flow labels. + Implementations should consider the impact of Equal-Cost Multipath + (ECMP) [RFC6438], specifically, whether a PMTU ought to be maintained + for each transport endpoint or for each network address. + +6.3.5. Detecting Path Changes + + Path characteristics can change, and the actual PMTU could increase + or decrease over time, for instance, following a path change when + packets are forwarded over a link with a different MTU than that + previously used. To bound the delay in discovering an increase in + the actual PMTU, a host with a link MTU larger than the current PMTU + SHOULD periodically send the MinPMTU HBH Option with the R-bit set. + DPLPMTUD provides recommendations concerning how this could be + implemented (see Section 5.3 of [RFC8899]). Since the Option + consumes less capacity than a full-sized probe packet, there can be + an advantage in using this to detect a change in the path + characteristics. + +6.3.6. Detection of Dropping Packets that Include the Option + + There is evidence that some middleboxes drop packets that include + Hop-by-Hop Options. For example, a firewall might drop a packet that + carries an unknown extension header or Option. This practice is + expected to decrease as an Option becomes more widely used. It could + result in the generation of an ICMPv6 message that indicates the + problem. This could be used to (temporarily) suspend use of this + Option. + + A middlebox that silently discards a packet with this Option results + in the dropping of any packet using the Option. This dropping can be + avoided by appropriate configuration in a controlled environment, + such as within a data center, but it needs to be considered for + Internet usage. Section 6.2 recommends that this Option is not used + on packets where loss might adversely impact performance. + +7. IANA Considerations + + IANA has registered an IPv6 Hop-by-Hop Option type in the + "Destination Options and Hop-by-Hop Options" registry within the + "Internet Protocol Version 6 (IPv6) Parameters" registry group + [IANA-HBH]. This assignment is shown in Section 5. + +8. Security Considerations + + This section discusses the security considerations. It first reviews + router Option processing. It then reviews host processing when + receiving this Option at the network layer. It then considers two + ways in which the Option Data can be processed, followed by two + approaches for using the Option Data. Finally, it discusses + middlebox implications related to use in the general Internet. + +8.1. Router Option Processing + + This Option shares the characteristics of all other IPv6 Hop-by-Hop + Options, in that, if not supported at line rate, it could be used to + degrade the performance of a router. This Option, while simple, is + no different than other uses of IPv6 Hop-by-Hop Options. + + It is common for routers to ignore the Hop-by-Hop Option header or to + drop packets containing a Hop-by-Hop Option header. Routers + implementing IPv6 according to [RFC8200] only examine and process the + Hop-by-Hop Options header if explicitly configured to do so. + +8.2. Network-Layer Host Processing + + A malicious attacker can forge a packet directed at a host that + carries the MinPMTU HBH Option. By design, the fields of this IP + Option can be modified by the network. + + For comparison, the ICMPv6 PTB message used in Path MTU Discovery + [RFC8201] and the source host have an inherent trust relationship + with the destination host including this Option. This trust + relationship can be used to help verify the Option. ICMPv6 PTB + messages are sent from any router on the path to the destination + host. The source host has no prior knowledge of these routers + (except for the first hop router). + + Reception of this packet will require processing as the network stack + parses the packet before the packet is delivered to the upper-layer + protocol. This network-layer Option processing is normally completed + before any upper-layer protocol delivery checks are performed. + + The network layer does not normally have sufficient information to + validate that the packet carrying an Option originated from the + destination (or an on-path node). It also does not typically have + sufficient context to demultiplex the packet to identify the related + transport flow. This can mean that any changes resulting from + reception of the Option applies to all flows between a pair of + endpoints. + + These considerations are no different than other uses of Hop-by-Hop + Options, and this is the use case for PMTUD. The following section + describes a mitigation for this attack. + +8.3. Validating Use of the Option Data + + Transport protocols should be designed to provide protection from + data injection attacks by off-path devices, and mechanisms should be + described in the Security Considerations section for each transport + specification (see Section 5.1 of "UDP Usage Guidelines" [RFC8085]). + For example, a TCP or UDP application that maintains the related + state and uses a randomized ephemeral port would provide basic + protection. TLS [RFC8446] or IPsec [RFC4301] provide cryptographic + authentication. An upper-layer protocol that validates each received + packet discards any packet when this validation fails. In this case, + the host MUST also discard the associated Option Data from the + MinPMTU HBH Option without further processing (Section 6.3). + + A network node on the path has visibility of all packets it forwards. + By observing the network packet payload, the node might be able to + construct a packet that might be validated by the destination host. + Such a node would also be able to drop or limit the flow in other + ways that could be potentially more disruptive. Authenticating the + packet, for example, using IPsec [RFC4301] or TLS [RFC8446] mitigates + this attack. Note that the authentication style of the + Authentication Header (AH) [RFC4302], while authenticating the + payload and outer IPv6 header, does not check Hop-by-Hop Options that + change on route. + +8.4. Direct Use of the Rtn-PMTU Value + + The simplest way to utilize the Rtn-PMTU value is to directly use + this to update the PMTU. This approach results in a set of security + issues when the Option carries malicious data: + + * A direct update of the PMTU using the Rtn-PMTU value could result + in an attacker inflating or reducing the size of the host PMTU for + the destination. Forcing a reduction in the PMTU can decrease the + efficiency of network use, might increase the number of packets/ + fragments required to send the same volume of payload data, and + can prevent sending an unfragmented datagram larger than the PMTU. + Increasing the PMTU can result in a path silently dropping packets + (described as a black hole in [RFC8899]) when the source host + sends packets larger than the actual PMTU. This persists until + the PMTU is next updated. + + * The method can be used to solicit a response from the destination + host. A malicious attacker could forge a packet that causes the + destination to add the Option to a packet sent to the source host. + A forged value of Rtn-PMTU in the Option Data might also impact + the remote endpoint, as described in the previous bullet. This + persists until a valid MinPMTU HBH Option is received. This + attack could be mitigated by limiting the sending of the MinPMTU + HBH Option in reply to incoming packets that carry the Option. + +8.5. Using the Rtn-PMTU Value as a Hint for Probing + + Another way to utilize the Rtn-PMTU value is to indirectly trigger a + probe to determine if the path supports a PMTU of size Rtn-PMTU. + This approach needs context for the flow and hence assumes an upper- + layer protocol that validates the packet that carries the Option (see + Section 8.3). This is the case when used in combination with + DPLPMTUD [RFC8899]. A set of security considerations result when an + Option carries malicious data: + + * If the forged packet carries a validated Option with a non-zero + Rtn-PMTU field, the upper-layer protocol could utilize the + information in the Rtn-PMTU field. A Rtn-PMTU larger than the + current PMTU can trigger a probe for a new size. + + * If the forged packet carries a non-zero Min-PMTU field, the upper- + layer protocol would change the cached information about the path + from the source. The cached information at the destination host + will be overwritten when the host receives another packet that + includes a MinPMTU HBH Option corresponding to the flow. + + * Processing of the Option could cause a destination host to add the + MinPMTU HBH Option to a packet sent to the source host. This + Option will carry a Rtn-PMTU value that could have been updated by + the forged packet. The impact of the source host receiving this + resembles that discussed previously. + +8.6. Impact of Middleboxes + + There is evidence that some middleboxes drop packets that include + Hop-by-Hop Options. For example, a firewall might drop a packet that + carries an unknown extension header or Option. This practice is + expected to decrease as the Option becomes more widely used. Methods + to address this are discussed in Section 6.3.6. + + When a forged packet causes a packet that includes the MinPMTU HBH + Option to be sent and the return path does not forward packets with + this Option, the packet will be dropped (see Section 6.3.6). This + attack is mitigated by validating the Option Data before use and by + limiting the rate of responses generated. An upper layer could + further mitigate the impact by responding to an R-Flag by including + the Option in a packet that does not carry application data. + +9. Experiment Goals + + This section describes the experimental goals of this specification. + + A successful deployment of the method depends upon several components + being implemented and deployed: + + * Support in the sending node (see Section 6.2). This also requires + corresponding support in upper-layer protocols (see Section 6.3). + + * Router support in nodes (see Section 6.1). The IETF continues to + provide recommendations on the use of IPv6 Hop-by-Hop Options, for + example, see Section 2.2.2 of [RFC9099]. This document does not + update the way router implementations configure support for Hop- + by-Hop Options. + + * Support in the receiving node (see Section 6.3.3). + + Experience from deployment is an expected input to any decision to + progress this specification from Experimental to IETF Standards + Track. Appropriate inputs might include: + + * reports of implementation experience, + + * measurements of the number paths where the method can be used, or + + * measurements showing the benefit realized or the implications of + using specific methods over specific paths. + +10. Implementation Status + + At the time this document was published, there are two known + implementations of the Path MTU Hop-by-Hop Option. These are: + + * Wireshark dissector. This is shipping in production in Wireshark + version 3.2 [WIRESHARK]. + + * A prototype in the open source version of the FD.io Vector Packet + Processing (VPP) technology [VPP]. At the time this document was + published, the source code can be found [VPP_SRC]. + +11. References + +11.1. Normative References + + [IANA-HBH] IANA, "Destination Options and Hop-by-Hop Options", + <https://www.iana.org/assignments/ipv6-parameters/>. + + [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate + Requirement Levels", BCP 14, RFC 2119, + DOI 10.17487/RFC2119, March 1997, + <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, + May 2017, <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, July 2017, + <https://www.rfc-editor.org/info/rfc8200>. + + [RFC8201] McCann, J., Deering, S., Mogul, J., and R. Hinden, Ed., + "Path MTU Discovery for IP version 6", STD 87, RFC 8201, + DOI 10.17487/RFC8201, July 2017, + <https://www.rfc-editor.org/info/rfc8201>. + +11.2. Informative References + + [RFC1063] Mogul, J., Kent, C., Partridge, C., and K. McCloghrie, "IP + MTU discovery options", RFC 1063, DOI 10.17487/RFC1063, + July 1988, <https://www.rfc-editor.org/info/rfc1063>. + + [RFC1191] Mogul, J. and S. Deering, "Path MTU discovery", RFC 1191, + DOI 10.17487/RFC1191, November 1990, + <https://www.rfc-editor.org/info/rfc1191>. + + [RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6 + (IPv6) Specification", RFC 2460, DOI 10.17487/RFC2460, + December 1998, <https://www.rfc-editor.org/info/rfc2460>. + + [RFC4301] Kent, S. and K. Seo, "Security Architecture for the + Internet Protocol", RFC 4301, DOI 10.17487/RFC4301, + December 2005, <https://www.rfc-editor.org/info/rfc4301>. + + [RFC4302] Kent, S., "IP Authentication Header", RFC 4302, + DOI 10.17487/RFC4302, December 2005, + <https://www.rfc-editor.org/info/rfc4302>. + + [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, March 2006, + <https://www.rfc-editor.org/info/rfc4443>. + + [RFC4821] Mathis, M. and J. Heffner, "Packetization Layer Path MTU + Discovery", RFC 4821, DOI 10.17487/RFC4821, March 2007, + <https://www.rfc-editor.org/info/rfc4821>. + + [RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman, + "Neighbor Discovery for IP version 6 (IPv6)", RFC 4861, + DOI 10.17487/RFC4861, September 2007, + <https://www.rfc-editor.org/info/rfc4861>. + + [RFC6438] Carpenter, B. and S. Amante, "Using the IPv6 Flow Label + for Equal Cost Multipath Routing and Link Aggregation in + Tunnels", RFC 6438, DOI 10.17487/RFC6438, November 2011, + <https://www.rfc-editor.org/info/rfc6438>. + + [RFC7637] Garg, P., Ed. and Y. Wang, Ed., "NVGRE: Network + Virtualization Using Generic Routing Encapsulation", + RFC 7637, DOI 10.17487/RFC7637, September 2015, + <https://www.rfc-editor.org/info/rfc7637>. + + [RFC8085] Eggert, L., Fairhurst, G., and G. Shepherd, "UDP Usage + Guidelines", BCP 145, RFC 8085, DOI 10.17487/RFC8085, + March 2017, <https://www.rfc-editor.org/info/rfc8085>. + + [RFC8446] Rescorla, E., "The Transport Layer Security (TLS) Protocol + Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018, + <https://www.rfc-editor.org/info/rfc8446>. + + [RFC8899] Fairhurst, G., Jones, T., Tüxen, M., Rüngeler, I., and T. + Völker, "Packetization Layer Path MTU Discovery for + Datagram Transports", RFC 8899, DOI 10.17487/RFC8899, + September 2020, <https://www.rfc-editor.org/info/rfc8899>. + + [RFC8900] Bonica, R., Baker, F., Huston, G., Hinden, R., Troan, O., + and F. Gont, "IP Fragmentation Considered Fragile", + BCP 230, RFC 8900, DOI 10.17487/RFC8900, September 2020, + <https://www.rfc-editor.org/info/rfc8900>. + + [RFC9000] Iyengar, J., Ed. and M. Thomson, Ed., "QUIC: A UDP-Based + Multiplexed and Secure Transport", RFC 9000, + DOI 10.17487/RFC9000, May 2021, + <https://www.rfc-editor.org/info/rfc9000>. + + [RFC9099] Vyncke, É., Chittimaneni, K., Kaeo, M., and E. Rey, + "Operational Security Considerations for IPv6 Networks", + RFC 9099, DOI 10.17487/RFC9099, August 2021, + <https://www.rfc-editor.org/info/rfc9099>. + + [TAPS-ARCH] + Pauly, T., Ed., Trammell, B., Ed., Brunstrom, A., + Fairhurst, G., and C. Perkins, "An Architecture for + Transport Services", Work in Progress, Internet-Draft, + draft-ietf-taps-arch-12, June 2022, + <https://datatracker.ietf.org/doc/bibxml3/draft-ietf-taps- + arch.xml>. + + [VPP] FD.io, "VPP/What is VPP?", + <https://wiki.fd.io/view/VPP/What_is_VPP%3F>. + + [VPP_SRC] "vpp", commit 21948, ip: HBH MTU recording for IPv6, + <https://gerrit.fd.io/r/c/vpp/+/21948>. + + [WIRESHARK] + "Wireshark Network Protocol Analyzer", + <https://www.wireshark.org>. + +Appendix A. Examples of Usage + + This section provides examples that illustrate a use of the MinPMTU + HBH Option by a source using DPLPMTUD to discover the PLPMTU + supported by a path. They consider a path where the on-path router + has been configured with an outgoing MTU of d'. The source starts by + transmission of packets of size a and then uses DPLPMTUD to seek to + increase the size in steps resulting in sizes of b, c, d, e, etc. + (chosen by the search algorithm used by DPLPMTUD). The search + algorithm terminates with a PLPMTU that is at least d and is less + than or equal to d'. + + The first example considers DPLPMTUD without using the MinPMTU HBH + Option. In this case, DPLPMTUD searches using a probe packet that + increases in size. Probe packets of size e are sent, which are + larger than the actual PMTU. In this example, PTB messages are not + received from the routers, and repeated unsuccessful probes result in + the search phase completing. Packets of data are never sent with a + size larger than the size of the last confirmed probe packet. + Acknowledgments (ACKs) of data packets are not shown. + + ----Packets of data size a ------------------------------> + ----Probe size b ----------------------------------------> + <---------------------------------- ACK of probe -------- + ----Packets of data size b ------------------------------> + ----Probe size c ----------------------------------------> + <---------------------------------- ACK of probe -------- + ----Packets of data size c ------------------------------> + ----Probe size d ----------------------------------------> + <---------------------------------- ACK of probe -------- + ----Packets of data size d ------------------------------> + <---------------------------------- ACK of probe -------- + ... + ----Probe size e --------------X + X----ICMPv6 PTB d' ----| + ----Packets of data size d ------------------------------> + ----Probe size e --------------X (again) + X----ICMPv6 PTB d' ----| + ----Packets of data size d ------------------------------> + ... + etc. until MaxProbes are unsuccessful and search phase completes. + ----Packets of data size d ------------------------------> + + Figure 3 + + The second example considers DPLPMTUD with the MinPMTU HBH Option set + on a connectivity probe packet. + + The IPv6 Option is sent end to end, and the Min-PMTU is updated by a + router on the path to d', which is returned in a response that also + sets the MinPMTU HBH Option. Upon receiving the Rtn-PMTU value, + DPLPMTUD immediately sends a probe packet of the target size d'. If + the probe packet is confirmed for the path, the PLPMTU is updated, + allowing the source to use data packets up to size d'. (The search + algorithm is allowed to continue to probe to see if the path supports + a larger size.) Packets of data are never sent with a size larger + than the last confirmed probe size d'. + + ----Packets of data size a ------------------------------> + ----Connectivity probe with MinPMTU- + +--updated to minPMTU=d'-----> + <-----------------ACK with Rtn-PMTU=d'-------------------- + ----Packets of data size a ------------------------------> + ----Probe size d' ---------------------------------------> + <---------------------------------- ACK of probe --------- + -----Packets of data size d' ----------------------------> + Search phase completes. + -----Packets of data size d' ----------------------------> + + Figure 4 + + The final example considers DPLPMTUD with the MinPMTU HBH Option set + on a connectivity probe packet but shows the effect when this + connectivity probe packet is dropped. + + In this case, the packet with the MinPMTU HBH Option is not received. + DPLPMTUD searches using probe packets of increasing size, increasing + the PLPMTU when the probes are confirmed. An ICMPv6 PTB message is + received when the probed size exceeds the actual PMTU, indicating a + PTB_SIZE of d'. DPLPMTUD immediately sends a probe packet of the + target size d'. If the probe packet is confirmed for the path, the + PLPMTU is updated, allowing the source to use data packets up to size + d'. If the ICMPv6 PTB message is not received, the DPLPMTU will be + the last confirmed probe size, which is d. + + ----Packets of data size a -------------------------------> + ----Connectivity probe with MinPMTU --------X + ----Packets of data size a -------------------------------> + ----Probe size b -----------------------------------------> + <---------------------------------- ACK of probe -------- + ----Packets of data size b -------------------------------> + ----Probe size c -----------------------------------------> + <---------------------------------- ACK of probe -------- + ----Packets of data size c -------------------------------> + ----Probe size d -----------------------------------------> + <---------------------------------- ACK of probe -------- + ----Packets of data size d -------------------------------> + ----Probe size e ------------X + <--ICMPv6 PTB PTB_SIZE d' --| + ----Packets of data size d -------------------------------> + ----Probe size d' using target set by PTB_SIZE -----------> + <---------------------------------- ACK of probe -------- + Search phase completes. + ----Packets of data size d' ------------------------------> + + Figure 5 + + The number of probe rounds depends on the number of steps needed by + the search algorithm and is typically larger for a larger PMTU. + +Acknowledgments + + Helpful comments were received from Tom Herbert, Tom Jones, Fred + Templin, Ole Troan, Tianran Zhou, Jen Linkova, Brian Carpenter, Peng + Shuping, Mark Smith, Fernando Gont, Michael Dougherty, Erik Kline, + and other members of the 6MAN Working Group. + +Authors' Addresses + + Robert M. Hinden + Check Point Software + 959 Skyway Road + San Carlos, CA 94070 + United States of America + Email: bob.hinden@gmail.com + + + Godred Fairhurst + University of Aberdeen + School of Engineering + Fraser Noble Building + Aberdeen + AB24 3UE + United Kingdom + Email: gorry@erg.abdn.ac.uk |