<?xml version="1.0"encoding="US-ASCII"?>encoding="UTF-8"?> <!DOCTYPE rfcSYSTEM "rfc2629-xhtml.ent"> <!-- <!DOCTYPE rfc SYSTEM "rfc2629.dtd"> --> <?xml-stylesheet type="text/xsl" href="rfc2629.xslt" ?> <?rfc strict="yes" ?> <?rfc toc="yes"?> <?rfc tocdepth="4"?> <?rfc symrefs="yes"?> <?rfc sortrefs="yes" ?> <?rfc compact="yes" ?> <?rfc subcompact="no" ?>[ <!ENTITY nbsp " "> <!ENTITY zwsp "​"> <!ENTITY nbhy "‑"> <!ENTITY wj "⁠"> ]> <rfccategory="exp"xmlns:xi="http://www.w3.org/2001/XInclude" docName="draft-ietf-6man-mtu-option-15" number="9268" ipr="trust200902" obsoletes="" sortRefs="true" submissionType="IETF" category="exp" consensus="true" symRefs="true" tocDepth="4" tocInclude="true" updates="" version="3" xml:lang="en"> <!-- xml2rfc v2v3 conversion 2.35.0 --> <front> <title abbrev="Path MTU Option">IPv6 Minimum Path MTU Hop-by-Hop Option</title> <seriesInfoname="Internet-Draft" value="draft-ietf-6man-mtu-option-15" />name="RFC" value="9268"/> <author fullname="Robert M. Hinden" initials="R" surname="Hinden"> <organization>Check Point Software</organization> <address> <postal> <street>959 Skyway Road</street><!-- Reorder these if your country does things differently --><city>San Carlos</city> <region>CA</region> <code>94070</code><country>USA</country><country>United States of America</country> </postal><phone /><email>bob.hinden@gmail.com</email><!-- uri and facsimile elements may also be added --></address> </author> <author fullname="Godred Fairhurst" initials="G" surname="Fairhurst"> <organization>University of Aberdeen</organization> <address> <postal><street>School<extaddr>School ofEngineering</street>Engineering</extaddr> <street>Fraser Noble Building</street> <city>Aberdeen</city><region /><region/> <code>AB24 3UE</code><country>UK</country><country>United Kingdom</country> </postal> <email>gorry@erg.abdn.ac.uk</email> </address> </author> <dateday="" month="" year="" />year="2022" month="August"/> <area>int</area> <workgroup>6man</workgroup> <keyword>DPLPMTUD</keyword> <keyword>PMTUD</keyword> <abstract> <t>This document specifies a new IPv6 Hop-by-HopoptionOption that is used to record theminimumMinimum 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 theoption.</t>Option.</t> </abstract> </front> <middle> <section anchor="Intro" numbered="true" title="Introduction" toc="default"> <t>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 thisoptionOption 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.</t> <t>At each subsequent hop where theoptionOption is processed, the router compares the value of the Min-PMTUFieldfield in theoptionOption and the MTU of its outgoing link. If the MTU of the link is less than the Min-PMTU, it rewrites the value in theoption dataOption Data with the smaller value. When the packet arrives at the destination host, the host can send the value of the minimumreportedReported MTU for the path back to the source host using the Rtn-PMTU field in theoption.Option. The source host can then use this value as input to the method that sets the Path MTU (PMTU) used byupper layerupper-layer protocols.</t> <t>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).</t>(2<sup>16</sup>).</t> <t>This method has the potential to complete Path MTUdiscoveryDiscovery (PMTUD) in a singleround tripround-trip time, even over paths that have successivelinkslinks, each with a lower MTU.</t> <t>The mechanism defined in this document is focused onUnicast,unicast; it does not describeMulticast.multicast. That is left for future work.</t> <section anchor="Intro1" numbered="true" title="Example Operation" toc="default"> <t>The figure below illustrates the operation of the method. In this case, the path between the source host and the destination host comprises threelinks,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.</t><figure><figure anchor="fig1"> <name>An Example Path between the Source Host and the Destination Host</name> <artwork align="center" alt="" name="" type=""><![CDATA[ +--------+ +----+ +----+ +-------+ | | | | | | | | | Sender +---------+ R1 +--------+ R2 +-------- + Dest. | | | | | | | | | +--------+ MTU-S +----+ 9000B +----+ MTU-D +-------+ ]]></artwork> </figure> <t>Three scenarios are described:</t> <ul spacing="normal"> <li> <t>Scenario1,1 considers all links to haveana 9000 byteMTUMTU, and the method is supported by both routers. The initial Min-PMTU is not modified along thepath, and thereforepath. Therefore, the PMTU is 9000 bytes.</t> </li> <li> <t>Scenario2,2 considers the link between R2 and the destination host (MTU-D) to have an MTU of 1500 bytes. This is the smallestMTU, routerMTU. Router R2 updates the Min-PMTU to 1500bytesbytes, 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.</t> </li> <li> <t>Scenario3,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.</t> </li> </ul> <t>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 <xref format="default" target="RFC8201" />.</t> <t>These scenarios are summarized in the table below. "H" in R1 and/or R2 columns means the router understands the MinPMTU HBHoption.</t> <figure> <artwork align="center" alt="" name="" type=""><![CDATA[ +-+-----+-----+----+----+----------+-----------------------+ | |MTU-S|MTU-D| R1 | R2 | Rec PMTU | Note | +-+-----+-----+----+----+----------+-----------------------+ |1|9000B|9000B| H | H | 9000 B | EndpointsOption.</t> <table align="center"> <name>Three Scenarios That Arise from Using the Path Shown in Figure 1</name> <thead> <tr> <th></th> <th>MTU-S</th> <th>MTU-D</th> <th>R1</th> <th>R2</th> <th>Rec PMTU</th> <th>Note</th> </tr> </thead> <tbody> <tr> <td>1</td> <td>9000 B</td> <td>9000 B</td> <td>H</td> <td>H</td> <td>9000 B</td> <td>Endpoints attempt to| | | | | | |use a 9000 BPMTU. | +-+-----+-----+----+----+----------+-----------------------+ |2|9000B|1500B| H | H | 1500 B | EndpointsPMTU.</td> </tr> <tr> <td>2</td> <td>9000 B</td> <td>1500 B</td> <td>H</td> <td>H</td> <td>1500 B</td> <td>Endpoints attempt to| | | | | | | |use a 1500 BPMTU. | +-+-----+-----+----+----+----------+-----------------------+ |3|9000B|1500B| H | - | 9000 B | EndpointsPMTU.</td> </tr> <tr> <td>3</td> <td>9000 B</td> <td>1500 B</td> <td>H</td> <td>-</td> <td>9000 B</td> <td>Endpoints attempt to| | | | | | | |use a 9000 BPMTU, | | | | | | | |PMTU but need to implement| | | | | | | |a method to fall back| | | | | | | |to discover and use a| | | | | | | |1500 BPMTU. | +-+-----+-----+----+----+----------+-----------------------+ ]]></artwork> </figure>PMTU.</td> </tr> </tbody> </table> </section> <section anchor="Intro2" numbered="true" title="Use of the IPv6 Hop-by-Hop Options Header" toc="default"><t>IPv6 as<t>As specified in <xref format="default"target="RFC8200" />target="RFC8200"/>, IPv6 allows nodes to optionally process the Hop-by-Hop header. Specifically, fromSection 4:</t> <ul spacing="normal"> <li><xref target="RFC8200" sectionFormat="of" section="4" format="default"/>:</t> <blockquote> <t>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.</t></li> <li><t>NOTE: While <xref format="default" target="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.</t></li> </ul></blockquote> <t>The Hop-by-Hop Option defined in this document is designed to take advantage of this property of how Hop-by-HopoptionsOptions are processed. Nodes that do not support this OptionSHOULD<bcp14>SHOULD</bcp14> ignore them. This can mean that the Min-PMTU value does not account for all links along a path.</t><!-- <t>The Hop-by-Hop option defined in this document is designed to work with PMTUs up to 65,574 bytes (the maximum size represented by the encoding format).</t> --></section> </section><!-- End of Into Section--><section anchor="motivation" numbered="true" title="Motivation and Problem Solved" toc="default"> <t>The current state of Path MTU Discovery on the Internet is problematic. The mechanisms defined in <xref format="default" target="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 PTBmessages,messages or rate-limited ICMPv6messages,messages or do not have a return path to the sourcehost.</t> <t>Thishost. This results in manytransport layertransport-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 IPv6Fragmentationfragmentation <xref format="default" target="RFC8200" />, which can reduce the reliability of Internet communication <xref format="default" target="RFC8900" />.</t> <t>Encapsulations and network-layer tunnels further reduce the payload size available for a transport protocol to use. Also, someuse-casesuse cases increase packet overhead, for example, Network Virtualization Using Generic Routing Encapsulation (NVGRE) <xref format="default" target="RFC7637" /> encapsulatesL2Layer 2 (L2) packets in an outer IP header and does not allow IPFragmentation.</t> <!--fragmentation.</t> <t>Sending larger packets can improve host performance, e.g., avoiding limits to packet processing by the packet rate.The potentialAn example ofmulti-gigabit Ethernet will only be realized if the packet size is increased above 1280 bytes, to avoid exceeding a packet per second sending rate that most hosts can process. For example, the packet per second rate required to reach wire speed on a 10G Ethernet link with 1280 byte packetsthis isabout 977K packets per second (pps), vs. 139K pps for 9000 byte packets. A significant difference.</t> --> <t>Sending larger packets can improve host performance, e.g., avoiding limits to packet processing by the packet rate. For example,how thepacket per secondpacket-per-second rate required to reach wire speed on a 10G link with 1280 byte packets is about 977K packets per second(pps),(pps) vs. 139K pps for 9000 byte packets.</t> <t>The purpose of this document is to improve the situation by defining a mechanism that does not rely on reception of ICMPv6Packet Too BigPTB messages from nodes in the middle of the network. Instead, this provides information to the destination host about theminimumMinimum PathMTU,MTU and sends this information back to the source host. This is expected to work better than the currentRFC8201-based mechanisms.</t>mechanisms based on <xref target="RFC8201" format="default"/>.</t> <t>A similar mechanism was proposed in 1988 for IPv4 in <xref format="default" target="RFC1063" /> by Jeff Mogul, C. Kent, Craig Partridge, and Keith McCloghire. It was later obsoleted in 1990 by <xref format="default" target="RFC1191" />, which is the current deployed approach to Path MTU Discovery. In contrast, the method described in this document uses the Hop-by-HopoptionOption of IPv6. It does not replace PMTUD <xref format="default" target="RFC8201" />,PLPPMTUDPacketization Layer Path MTU Discovery (PLPMTUD) <xref format="default" target="RFC4821"/>/>, or DatagramPLPMTUDPacketization Layer PMTU Discovery (DPLPMTUD) <xref format="default" target="RFC8899"/>,/> but rather is designed to compliment these methods.</t> </section> <section numbered="true" title="Requirements Language" toc="default"> <t>The key words"MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY","<bcp14>MUST</bcp14>", "<bcp14>MUST NOT</bcp14>", "<bcp14>REQUIRED</bcp14>", "<bcp14>SHALL</bcp14>", "<bcp14>SHALL NOT</bcp14>", "<bcp14>SHOULD</bcp14>", "<bcp14>SHOULD NOT</bcp14>", "<bcp14>RECOMMENDED</bcp14>", "<bcp14>NOT RECOMMENDED</bcp14>", "<bcp14>MAY</bcp14>", and"OPTIONAL""<bcp14>OPTIONAL</bcp14>" in this document are to be interpreted as described inBCP 14BCP 14 <xref format="default" target="RFC2119" /> <xref format="default" target="RFC8174" /> when, and only when, they appear in all capitals, as shown here.</t> </section><!-- Requirements Language --><section numbered="true" title="Applicability Statements"toc="default">toc="default" anchor="app-state"> <t>The Path MTUoptionOption is designed for environments where there is control over the hosts and nodes that connectthem,them and where there is more than one MTU size inuse. Foruse, for example, inData Centersdata centers and on paths betweenData Centers,data centers to allow hosts to better take advantage of a path that is able to support a large PMTU.</t> <t>The design of theoptionOption 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 containeduse-caseuse case of connections within and betweenData Centersdata centers could be a driver for deployment.</t> <t>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 methodsuch aslike Packetization Layer PMTUD <xref format="default" target="RFC4821" /> or DatagramPLPMTUDPacketization Layer PMTU Discovery (DPLPMTUD) <xref format="default" target="RFC8899" />.</t> </section><!-- Applicability Statements --><section anchor="HBH" numbered="true" title="IPv6 Minimum Path MTU Hop-by-Hop Option" toc="default"> <t>The Minimum Path MTU Hop-by-Hop Option has the following format:</t> <figure> <name>Format of the Minimum Path MTU Hop-by-Hop Option</name> <artwork align="center" alt="" name="" type=""><![CDATA[ Option Option Option Type Data Len Data +--------+--------+--------+--------+---------+-------+-+ |BBCTTTTT|00000100| Min-PMTU | Rtn-PMTU |R| +--------+--------+--------+--------+---------+-------+-+Option]]></artwork> </figure> <t>Option Type (seeSection 4.2 of [RFC8200]):<xref target="RFC8200" section="4.2" sectionFormat="of"/>):</t> <artwork align="center" alt="" name="" type=""><![CDATA[ BB 00 Skip over thisoptionOption and continue processing. C 1 OptiondataData 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 MTUoption.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. ]]></artwork></figure><t>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.</t> </section><!-- End of Option Defination section --><section anchor="Behavior" numbered="true" title="Router, Host, and Transport Layer Behaviors" toc="default"> <section anchor="router" numbered="true" title="Router Behavior" toc="default"> <t>Routers that are not configured to support Hop-by-Hop Options are not expected to examine or process the contents of thisoptionOption <xref format="default" target="RFC8200" />.</t><!--<t>Routers thatare not configured tosupport Hop-by-Hop OptionsSHOULD ignore this option and SHOULD forward the packet <xref format="default" target="RFC8200" />.</t> <t>PROPOSED by Alvaro Retana</t> <ul> <li><t>Routers that are not configured to support Hop-by-Hop Options are not expected to examine or process the contents <xref format="default" target="RFC8200" />.</t></li> </ul> --> <t>Routers that support Hop-by-Hop Options,but are not configured to support thisoption SHOULDOption <bcp14>SHOULD</bcp14> skip over thisoptionOption and continue toprocessingprocess the header <xref format="default" target="RFC8200" />.</t><!--<t>Routers that supportHop-by-Hop Options, but that are not configured to supportthisoption SHOULD ignore the option and SHOULD forward the packet.</t> <t>PROPOSED by Alvaro Retana</t> <ul> <li><t>Routers that support Hop-by-Hop Options, but that do not recognize this new option will skip over the option and continue processing the header.<xref format="default" target="RFC8200" />.</t> </li> </ul> --> <t>Routers that support this option MUSTOption <bcp14>MUST</bcp14> 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.)</t> <t>A routerMUST<bcp14>MUST</bcp14> ignore andMUST NOT<bcp14>MUST NOT</bcp14> change the Rtn-PMTU field or the R-Flag in theoption.</t> <!-- <t>Discussion:</t> <ul spacing="normal"> <li> <t>The design of this option makes it feasible to be implemented within the fast path of a router, because the processing requirements are minimal.</t> </li> </ul> -->Option.</t> </section><!--End of Router Behavior subsection--><section anchor="host-os" numbered="true" title="Host Operating System Behavior" toc="default"><!-- <t>The PMTU entry associated with the destination in the IP layer cache can be updated using PMTUD 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 IP cache.</t> --><t>The PMTU entry associated with the destination in the host's destination cache <xref format="default" target="RFC4861" />SHOULD<bcp14>SHOULD</bcp14> 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.</t><!-- ** Watch out for confusing use of PMTUD? Is it referring to 8201 or this mechanism? --> <!-- <t>The value in the host IP layer cache could, for instance, be used by PLPMTUD to select an initial PMTU for each flow before a flow determines a PMTU for the specific path it is using (e.g., using the IPv6 Minimum Path MTU Hop-by-Hop Option and DPLPMTUD). The cached PMTU is only increased by PLPMTUD when the PL determines the path actually supports a larger PMTU <xref format="default" target="RFC4821" /> <xref format="default" target="RFC8899" />. </t> --><t>The value in the host destination cacheSHOULD<bcp14>SHOULD</bcp14> 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 <xref format="default" target="RFC4821" /> <xref format="default" target="RFC8899" />.</t> <t>When requested to send an IPv6 packet with the MinPMTU HBHoption,Option, the source host includes theoptionOption in an outgoing packet. The source hostMUST<bcp14>MUST</bcp14> 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.</t> <t>When a host includes theoptionOption in a packet it sends, the hostSHOULD<bcp14>SHOULD</bcp14> 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 <xref target="transportrec" />). If this value is not set (for example, because there is no cached reported Min-PMTU value), the Rtn-PMTU field valueMUST<bcp14>MUST</bcp14> be set to zero.</t> <t>The source hostMAY<bcp14>MAY</bcp14> request the destination host to return the reported Min-PMTU value by setting the R-Flag in theoptionOption of an outgoing packet. The R-FlagSHOULD NOT<bcp14>SHOULD NOT</bcp14> 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.</t> <t>The destination host controls when to send a packet with thisoptionOption in response to anR-flag,R-Flag, as well as which packets to include it in. The destination hostMAY<bcp14>MAY</bcp14> limit the rate at which it sends these packets.</t> <t>A destination host only sets theR FlagR-Flag if it wishes the source host to also return the discovered PMTU value for the path from the destination to the source.</t><!--<t>The normal sequence of operation of the R-Flag using the terminology from the diagram inFigure 1 is:</t> <ol type="1"> <li><t>Sender sends probe to Dest. Sender MUST set the R-Flag</t></li> <li><t>Dest responds by sending a probe including the received Min-PMTU as the Rtn-PMTU. Dest sets R-Flag only if response is desired</t></li> <li><t>Sender sends response probe back to Dest, MUST NOT set R-Flag.</t></li> </ol> --> <t>The normal sequence of operation of the R-Flag using the terminology from the diagram in Figure 1<xref target="fig1"/> is:</t> <ol type="1"> <li> <t>The source sends a probe to the destination. The sender sets the R-Flag.</t> </li> <li> <t>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.</t> </li> </ol> </section><!-- End of Host OS section--><section anchor="Transport" numbered="true" title="Transport Layer Behavior" toc="default"> <t>This Hop-by-HopoptionOption is intended to be used with apathPath MTUdiscoveryDiscovery method.</t><!-- <t>Section 4.1 of <xref format="default" target="RFC9000" /> describes different types of PMTU Probe, depending on whether the probe packets carry application data. When the path is expected to support use of the option, the PMTU Probe can be sent on packets that include application data, but needs to be robust to potential loss of the packet with the possibility that retransmission might be needed. 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 later drops packets that set this option. This avoids the transport needing to retransmit a lost packet that includes this option. </t> --><t>PLPMTUD <xref format="default"target="RFC9000"target="RFC8899" /> uses probe packets for two distinct functions:</t> <ul> <li>Probe packets are used to confirm connectivity. Such probes can be of any size up to thePLPMTU.Packetization Layer Path MTU (PLPMTU). These probe packets are sent to solicit a responseuseusing the path to the remote node. These probe packets can carry the Hop-by-Hop PMTUoption,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),(<xref target="RFC8899" section="4.6.1" sectionFormat="of"/>), the PLPMTUD method can use the reported size from the Hop-by-HopoptionOption as the next search point when it resumes the search algorithm. (This use resembles the use of the PTB_SIZE information insection 4.6.2 of<xref format="default" target="RFC8899"/></li>section="4.6.2" sectionFormat="of"/>.)</li> <li>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-Hopoption.Option. Seesection 1.2 of<xrefformat="default"target="RFC8899"/>. Section 4.1 ofsection="1.2" sectionFormat="of"/>. <xref format="default" target="RFC8899"/>section="4.1" sectionFormat="of"/> also describes ways that aProbe Packetprobe packet can be constructed, depending on whether the probe packets carry application data.</li><li>The</ul> <t>The PMTU Hop-by-Hop OptionProbeprobe can be sent on packets that include applicationdata,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 islost).</li> <li>Usinglost).</t> <t>Using a PMTUProbeprobe 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 thisoption.Option. (This avoids the transport needing to retransmit a lost packet that includes thisoption.)Option.) This is the normal default format for both uses ofprobes.</li> </ul> <!-- subsections... -->probes.</t> <section anchor="transportsend" numbered="true" title="Including the Option in an Outgoing Packet" toc="default"> <t>Theupper layerupper-layer protocol can request the MinPMTU HBHoptionOption to be included in an outgoing IPv6 packet. A transport protocol (orupper layerupper-layer protocol) can include thisoptionOption only on specific packets used to test the path. ThisoptionOption does not need to be included in all packets belonging to a flow.</t> <t>NOTE: Including thisoptionOption 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.</t> <t>Discussion:</t> <ul spacing="normal"> <li> <t>In the case of TCP, theoptionOption could be included in a packet that carries a TCP segment sent after the connection is established. A segment without data could beused,used to avoid the need to retransmit this data if the probe packet is lost. The discovered value can be used to inform PLPMTUD <xref format="default" target="RFC4821" />.</t> <t>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 thisoptionOption 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 thisoptionOption (see <xref target="HBHblackhole" />), which could have an unwanted impact on the result of racingoptionsOptions <xref format="default" target="I-D.ietf-taps-arch" /> or feature negotiation.</t> </li> <li> <t>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,exchanges to longer (bulk) exchanges of packets between the source and destination hosts <xref format="default" target="RFC8085" />.</t> </li> <li> <t>Simple-exchange protocols (i.e., low data-volume applications <xref format="default" target="RFC8085" /> that only send one or a few packets pertransaction),transaction) might assume that the PMTU is symmetrical. That is, the PMTU is the same in bothdirections,directions or at least not smaller for the return path. This optimization does not hold when the paths are not symmetric.</t> </li> <li> <t>The MinPMTU HBHoptionOption can be used with ICMPv6 <xref format="default" target="RFC4443" />. This requires a response from the remote node and therefore is restricted to use with ICMPv6 echo messages. The MinPMTU HBHoptionOption could provide additional information about the PMTU that might be supported by a path. This could beuseused 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.</t> </li> <li> <t>A datagram transport canutiliseutilize DPLPMTUD <xref format="default" target="RFC8899" />. For example, QUIC (seesection 14.3 of<xref format="default" target="RFC9000"/>),sectionFormat="of" section="14.3"/>) can use DPLPMTUD to determine whether the path to a destination will support a desired maximum datagram size. When using the IPv6 MinPMTU HBHoption,Option, theoptionOption could be added to an additional QUIC PMTUProbeprobe that is of minimal size (or one no larger than the currently supported PMTU size). Once the return Path MTU value in the MinPMTU HBHoptionOption has been learned, DPLPMTUD can be triggered to test for a larger PLPMTU using an appropriately sized PLPMTUProbe Packetprobe packet (seesection 5.3.1 of<xref format="default" target="RFC8899"/>).</t>sectionFormat="of" section="5.3.1"/>).</t> </li> <li> <t>The use of thisoptionOption 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.</t> </li> <li> <t>This method also can be used withAnycastanycast to discover the PMTU of the path, but the use needs to be aware that theAnycastanycast binding might change.</t> </li> </ul> </section><!-- End of IPv6 outgoing transport processing --><section anchor="transportvalid" numbered="true" title="Validation of the Packet thatincludesIncludes the Option" toc="default"> <t>Anupper layerupper-layer protocol (e.g., transport endpoint) using thisoptionOption needs to provide protection from data injection attacks by off-path devices <xref format="default" target="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 datainjection,injection; seeSection 5.1 of<xref format="default" target="RFC8085"/>.sectionFormat="of" section="5.1"/>. IPsec <xref format="default" target="RFC4301" /> and TLS <xref format="default" target="RFC8446" /> provide greater assurance.</t> <t>The upper layer discards any received packet when the packet validation fails. When packet validation fails, the upper layerMUST<bcp14>MUST</bcp14> also discard the associated Option Data from the MinPMTU HBHoptionOption without further processing.</t> </section><!-- End of Validation --><section anchor="transportrec" numbered="true" title="Receiving the Option" toc="default"> <t>For a connection-orientedupper layerupper-layer protocol, caching of the received Min-PMTU could be implemented by saving the value in the connection context at the transport layer. Aconnection-lessconnectionless upper layer (e.g., one usingUDP),UDP) requires theupper layerupper-layer protocol to cache the value for each flow it uses.</t> <t>A destination host that receives a MinPMTU HBH Option with the R-FlagSHOULD<bcp14>SHOULD</bcp14> include the MinPMTU HBHoptionOption in the next outgoing IPv6 packet for the corresponding flow.</t> <t>A simple mechanism could only include thisoptionOption (with the Rtn-PMTU field set) the first time thisoptionOption is received or when it notifies a change in the Minimum Path MTU. This limits the number ofpacketspackets, including theoption packetsOption packets, that are sent. However, this does not provide robustness to packet loss or recovery after a sender loses state.</t> <t>Discussion:</t> <ul spacing="normal"> <li> <t>Someupper layerupper-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.</t> </li> </ul> </section><!-- End of IPv6 incoming transport processing --><section anchor="Rtn-MTU" numbered="true" title="Using the Rtn-PMTU Field" toc="default"> <t>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:</t> <ul spacing="normal"> <li>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 theoption.</li>Option.</li> <li>The actual PMTU may be lower than the Rtn-PMTU value because there is alayer-2Layer 2 device with a lower MTU.</li> <li>The actual PMTU may be larger than the Rtn-PMTU value because of a corrupted,delayeddelayed, ormis-orderedmisordered response. A source hostMUST<bcp14>MUST</bcp14> ignore a Rtn-PMTU value larger than the MTU configured for the outgoing link.</li> <li>The path might have changed between the time when the probe was sent and when the Rtn-PMTU value received.</li> </ul> <t>IPv6 requires that every link in the Internet have an MTU of 1280 octets or greater. A nodeMUST<bcp14>MUST</bcp14> ignore a Rtn-PMTU value less than 1280 octets <xref format="default" target="RFC8200" />.</t> <t>To avoid unintentional dropping of packets that exceed the actual PMTU (e.g., Scenario 3 in <xref target="Intro1" />), 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 increasesrobustness,robustness but adds one additional pathround tripround-trip time before the PMTU is updated. This use resembles that of PTB messages insection 4.6 of DPLPMTUD<xref format="default" target="RFC8899"/>sectionFormat="of" section="4.6">DPLPMTUD</xref> (with the important difference being that a PTB message can only seek to lower the PMTU, whereas thisoptionOption could trigger a probe packet to seek to increase thePMTU.)</t> <t>Section 5.2 of <xrefPMTU).</t> <t><xref format="default" target="RFC8201"/>sectionFormat="of" section="5.2"/> provides guidance on the caching of PMTU information and also the relation to IPv6 flow labels. Implementations should consider the impact ofEqual CostEqual-Cost Multipath (ECMP) <xref format="default" target="RFC6438"/>. Specifically,/>, specifically, whether a PMTU ought to be maintained for each transportendpoint,endpoint or for each network address.</t> </section><!-- End of Rtn-MTU --><section numbered="true" title="Detecting Path Changes" toc="default"> <t>Path characteristics canchangechange, and the actual PMTU could increase or decrease overtime. Fortime, 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 PMTUSHOULD<bcp14>SHOULD</bcp14> periodically send the MinPMTU HBH Option with the R-bit set. DPLPMTUD provides recommendations concerning how this could be implemented (seeSection 5.3 of<xref format="default" target="RFC8899"/>).sectionFormat="of" section="5.3"/>). Since theoptionOption 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.</t> </section><!-- End of Detecting Path Changes --><section anchor="HBHblackhole" numbered="true" title="Detection of Dropping Packets thatincludeInclude the Option" toc="default"> <t>There is evidence that some middleboxes drop packets that include Hop-by-Hopoptions.Options. For example, a firewall might drop a packet that carries an unknown extension header oroption.Option. This practice is expected to decrease as anoptionOption becomes more widely used. It could result in the generation of an ICMPv6 messageindicatingthat indicates the problem. This could be used to (temporarily) suspend use of thisoption.</t>Option.</t> <t>A middlebox that silently discards a packet with thisoptionOption results in the dropping of any packet using theoption.Option. This dropping can be avoided by appropriate configuration in a controlled environment, such as within a datacentre,center, but it needs to be considered for Internet usage. <xref target="host-os" /> recommends that thisoptionOption is not used on packets where loss might adversely impact performance.</t> </section><!-- End of HBH Drop --></section><!-- End of Transport Main subSection --></section><!-- End of Router,Host, Transport Section--><section anchor="IANA" numbered="true" title="IANA Considerations" toc="default"> <t>IANA hasassigned andregistered an IPv6 Hop-by-Hop Option typewith Temporary status fromin the "Destination Options and Hop-by-Hop Options" registry within the "Internet Protocol Version 6 (IPv6) Parameters" registry group <xref format="default"target="IANA-HBH" />.target="IANA-HBH"/>. This assignment is shown in <xref format="default" target="HBH" />.</t><t>IANA is requested to update this registry to point to this document and remove the Temporary status.</t></section><!-- End of IANA Main Section--><section anchor="Security" numbered="true" title="Security Considerations" toc="default"> <t>This section discusses the security considerations. It first reviews routeroptionOption processing. It then reviews host processing when receiving thisoptionOption 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.</t> <section anchor="Security-router" numbered="true" title="Router Option Processing" toc="default"> <t>ThisoptionOption shares the characteristics of all other IPv6 Hop-by-Hop Options, inthatthat, if not supported at lineraterate, it could be used to degrade the performance of a router. Thisoption,Option, while simple, is no differenttothan other uses of IPv6 Hop-by-Hopoptions.</t>Options.</t> <t>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 <xref format="default" target="RFC8200" /> only examine and process the Hop-by-Hop Options header if explicitly configured to do so.</t> </section> <section anchor="Security-net" numbered="true"title="Network Layertitle="Network-Layer Host Processing" toc="default"> <t>A malicious attacker can forge a packet directed at a host that carries the MinPMTU HBHoption.Option. By design, the fields of this IPoptionOption can be modified by the network.</t> <t>For comparison, the ICMPv6Packet Too BigPTB message used in<xref format="default" target="RFC8201" />Path MTUDiscovery,Discovery <xref format="default" target="RFC8201"/> and the source hosthashave an inherent trust relationship with the destination host including thisoption.Option. This trust relationship can be used to help verify theoption.Option. ICMPv6Packet Too BigPTB messages are sent from any router on the path to the destinationhost, thehost. The source host has no prior knowledge of these routers (except for the first hop router).</t> <t>Reception of this packet will require processing as the network stack parses the packet before the packet is delivered to theupper layerupper-layer protocol. Thisnetwork layer optionnetwork-layer Option processing is normally completed before anyupper layerupper-layer protocol delivery checks are performed.</t> <t>The network layer does not normally have sufficient information to validate that the packet carrying anoptionOption 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 theoptionOption applies to all flows between a pair of endpoints.</t> <t>These considerations are no differenttothan other uses of Hop-by-Hopoptions,Options, and this is the use case for PMTUD. The following section describes a mitigation for this attack.</t> </section> <section anchor="Security-upp" numbered="true" title="ValidatinguseUse of the Option Data" toc="default"> <t>Transport protocols should be designed to provide protection from data injection attacks by off-pathdevicesdevices, and mechanisms should be described in the Security Considerations section for each transport specification (seeSection 5.1 of the UDP Guidelines<xrefformat="default"target="RFC8085"/>).sectionFormat="of" section="5.1">"UDP Usage Guidelines"</xref>). For example, a TCP or UDP application that maintains the related state and uses a randomized ephemeral port would provide basic protection. TLS <xref format="default" target="RFC8446" /> or IPsec <xref format="default" target="RFC4301" /> provide cryptographic authentication. Anupper layerupper-layer protocol that validates each received packet discards any packet when this validation fails. In this case, the hostMUST<bcp14>MUST</bcp14> also discard the associated Option Data from the MinPMTU HBHoptionOption without further processing (<xref target="Transport" />).</t> <t>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 <xref format="default" target="RFC4301" /> or TLS <xref format="default" target="RFC8446" /> mitigates this attack. Note thatAH stylethe authentication style of the Authentication Header (AH) <xref format="default" target="RFC4302"/>/>, while authenticating the payload and outer IPv6 header, does not check Hop-by-HopoptionsOptions that change on route.</t> </section> <section anchor="Security-pmtud" numbered="true" title="DirectuseUse of the Rtn-PMTU Value" toc="default"> <t>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 theoptionOption carries malicious data:</t> <ul> <li> <t>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, andpreventscan prevent sending an unfragmented datagram larger than the PMTU. Increasing the PMTU can result inblack-holing (see Section 1.1 ofa path silently dropping packets (described as a black hole in <xref format="default"target="RFC8899" />)target="RFC8899"/>) when the source host sends packets larger than the actual PMTU. This persists until the PMTU is next updated.</t> </li> <li> <t>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 theoptionOption 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 HBHoptionOption is received. This attack could be mitigated by limiting the sending of the MinPMTU HBHoptionOption in reply to incoming packets that carry theoption.</t>Option.</t> </li> </ul> </section><!-- End of security PMTUD subsection --><section anchor="Security-dplpmtud" numbered="true" title="Using the Rtn-PMTU Value as a Hint for Probing" toc="default"> <t>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 theflow,flow and hence assumes anupper layerupper-layer protocol that validates the packet that carries theoptionOption (see <xref target="Security-upp" />). This is the case when used in combination with DPLPMTUD <xref format="default" target="RFC8899" />. A set of security considerations result when anoptionOption carries malicious data:</t> <ul> <li>If the forged packet carries a validatedoptionOption with a non-zero Rtn-PMTU field, theupper layerupper-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.</li> <li>If the forged packet carries a non-zero Min-PMTU field, theupper layerupper-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 HBHoptionOption corresponding to the flow.</li> <li>Processing of theoptionOption could cause a destination host to add the MinPMTU HBHoptionOption to a packet sent to the source host. ThisoptionOption 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.</li> </ul> </section><!-- End of security subsection --><section anchor="Security-mbox" numbered="true" title="Impact of Middleboxes" toc="default"> <t>There is evidence that some middleboxes drop packets that include Hop-by-Hopoptions.Options. For example, a firewall might drop a packet that carries an unknown extension header oroption.Option. This practice is expected to decrease as theoptionOption becomes more widely used. Methods to address this are discussed in <xref target="HBHblackhole" />.</t> <t>When a forged packet causes a packetto be sent includingthat includes the MinPMTU HBHoption,Option to be sent and the return path does not forward packets with thisoption,Option, the packet will be dropped (see <xreftarget="HBHblackhole" />.target="HBHblackhole"/>). This attack is mitigated by validating theoption dataOption 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 theoptionOption in a packet that does not carry application data.</t> </section><!-- End of security mbox subsection --></section><!-- End of Security Consideraions main section--><section anchor="EXP" numbered="true" title="Experiment Goals" toc="default"> <t>This section describes the experimental goals of this specification.</t> <t>A successful deployment of the method depends upon several components being implemented and deployed:</t> <ul spacing="normal"> <li>Support in the sending node (see <xref format="default" target="host-os" />). This also requires corresponding support inupper layerupper-layer protocols (see <xref format="default" target="Transport" />).</li> <li>Router support in nodes (see <xref format="default" target="router" />). The IETF continues to provide recommendations on the use of IPv6 Hop-by-Hopoptions,Options, forexampleexample, see <xref format="default" section="2.2.2" target="RFC9099" />. This document does not update the way router implementations configure support for Hop-by-Hopoptions.</li>Options.</li> <li>Support in the receiving node (see <xref format="default" target="transportrec" />).</li> </ul> <t>Experience from deployment is an expected input to any decision to progress this specification from Experimental to IETF Standards Track. Appropriate inputs might include:</t> <ul spacing="normal"><li>Reports<li>reports of implementationexperience;</li> <li>Measurementsexperience,</li> <li>measurements of the number paths where the method can beused;</li> <li>Measurementsused, or</li> <li>measurements showing the benefit realized or the implications of using specific methods over specific paths.</li> </ul> </section><!-- End of Experiment Status section--><section anchor="IMP" numbered="true" title="Implementation Status" toc="default"> <t>At the time this document waspublishedpublished, there are two known implementations of the Path MTU Hop-by-Hopoption.Option. These are:</t> <ul spacing="normal"> <li>Wireshark dissector. This is shipping in production in Wireshark version 3.2 <xref format="default" target="WIRESHARK" />.</li> <li>A prototype in the open source version of the FD.io Vector Packet Processing (VPP) technology <xref format="default" target="VPP" />. At the time this document was published, the source code can be found <xref format="default" target="VPP_SRC" />.</li> </ul> </section><!-- End of Implementation Status section--> <section anchor="Ack" numbered="true" title="Acknowledgments" toc="default"> <t>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.</t> </section> <!-- End of Ack Main Section --> <section anchor="changes" numbered="true" title="Change log [RFC Editor: Please remove]" toc="default"> <t>draft-ietf-6man-mtu-option-15, 2022-May-10</t> <ul spacing="compact"> <li>Correcting an editing mistake in <xref format="default" target="appendix" />.</li> <li>Editorial Change.</li> </ul> <t>draft-ietf-6man-mtu-option-14, 2022-April-15</t> <ul spacing="compact"> <li> <t>Area Director Reviews:</t> <ul spacing="compact"> <li>Lars Eggert's Review: Fixed "nits".</li> <li>Eric Vyncke's Review: Added that this work is focused on Unicast, removed Discussion from <xref format="default" target="router" />, revised text on PLPMTUD probing, changed SHOULD to MUST in <xref format="default" target="Rtn-MTU" />, and fixed several NITs.</li> <li>Alvaro Retana's Review: Changed SHOULD language to more general text in <xref format="default" target="router" /></li> <li>ARTART Review: Added new Appendix "Examples of Usage" with diagrams showing examples of use.</li> <li>Zaheduzzaman Sarker's Review: Fixed some editorial issues, and updated SHOULD language.</li> </ul> </li> <li>Editorial Changes.</li> </ul> <t>draft-ietf-6man-mtu-option-13, 2022-February-28</t> <ul spacing="compact"> <li> <t>Area Directorate Reviews:</t> <ul spacing="compact"> <li>SECDIR Review: Fixed "nit".</li> <li>TSVART Review: Restructured <xref format="default" target="Behavior" /> including making Transport Behavior more prominent, added text about ICMPv6 to <xref format="default" target="transportsend" />, moved the text about prior work in RFC1063 to <xref format="default" target="motivation" />.</li> <li>GENART Review: Added text to <xref format="default" target="Intro" /> that this option was designed to work with packet sizes that can be specified in the IPv6 Header.</li> </ul> </li> <!--- <li>Added a new subsection to Router Behavior describing an optimization that can be done if all of the routers interfaces are configured with the same MTU.</li> --> <li>Editorial Changes.</li> </ul> <t>draft-ietf-6man-mtu-option-12, 2022-January-26</t> <ul spacing="compact"> <li>Clarified a few issues raised by AD review by Erik Kline AD review.</li> </ul> <t>draft-ietf-6man-mtu-option-11, 2021-September-30</t> <ul spacing="compact"> <li>Clarifications and editorial changes to the Security Considerations section based on early AD review by Erik Kline.</li> </ul> <t>draft-ietf-6man-mtu-option-10, 2021-September-27</t> <ul spacing="compact"> <li>Clarifications and editorial changes based on second chair review by Ole Troan.</li> <li>Editorial changes.</li> </ul> <t>draft-ietf-6man-mtu-option-09, 2021-September-23</t> <ul spacing="compact"> <li>Clarifications and editorial changes based on review by Michael Dougherty.</li> </ul> <t>draft-ietf-6man-mtu-option-08, 2021-September-7</t> <ul spacing="compact"> <li>Clarifications and editorial changes based on chair review by Ole Troan.</li> <li>Correction and clarifications based on review by Fernando Gont.</li> </ul> <t>draft-ietf-6man-mtu-option-07, 2021-August-31</t> <ul spacing="compact"> <li>Added Experiment Goals section.</li> <li>Added Implementation Status section.</li> <li>Updated the IANA Considerations section to point to this document and remove Temporary status.</li> <li>Clarifications and editorial changes based on review by Mark Smith.</li> </ul> <t>draft-ietf-6man-mtu-option-06, 2021-August-7</t> <ul spacing="compact"> <li>Transport usage of the mechanism clarified in response to feedback and suggestions from Jen Linkova.</li> <li>Restructured <xref format="default" target="Behavior" /> to improve readability.</li> <li>Editorial changes.</li> </ul> <t>draft-ietf-6man-mtu-option-05, 2021-April-28</t> <ul spacing="compact"> <li>Editorial changes.</li> </ul> <t>draft-ietf-6man-mtu-option-04, 2020-Oct-23</t> <ul spacing="compact"> <li>Fixes for typos.</li> </ul> <t>draft-ietf-6man-mtu-option-03, 2020-Sept-14</t> <ul spacing="compact"> <li>Rewrite to make text and terminology more consistent.</li> <li>Added the notion of validating the packet before use of the HBH option data.</li> <li>Method aligned with the way common APIs send/receive HBH option data.</li> <li>Added reference to DPLPMTUD and clarified upper layer usage.</li> <li>Completed security considerations section.</li> </ul> <t>draft-ietf-6man-mtu-option-02, 2020-March-9</t> <ul spacing="compact"> <li>Editorial changes to make text and terminology more consistent.</li> <li>Added reference to DPLPMTUD.</li> </ul> <t>draft-ietf-6man-mtu-option-01, 2019-September-13</t> <ul spacing="compact"> <li>Changes to show IANA assigned code point.</li> <li>Editorial changes to make text and terminology more consistent.</li> <li>Added a reference to RFC8200 in <xref format="default" target="motivation" /> and a reference to RFC6438 in <xref format="default" target="Transport" />.</li> </ul> <t>draft-ietf-6man-mtu-option-00, 2019-August-9</t> <ul spacing="compact"> <li>First 6man w.g. draft version.</li> <li>Changes to request IANA allocation of code point.</li> <li>Editorial changes.</li> </ul> <t>draft-hinden-6man-mtu-option-02, 2019-July-5</t> <ul spacing="compact"> <li>Changed option format to also include the Returned PMTU value and Return flag and made related text changes in <xref format="default" target="host-os" /> to describe this behavior.</li> <li>ICMPv6 Packet Too Big messages are no longer used for feedback to the source host.</li> <li>Added to Acknowledgements Section that a similar mechanism was proposed for IPv4 in 1988 in <xref format="default" target="RFC1063" />.</li> <li>Editorial changes.</li> </ul> <t>draft-hinden-6man-mtu-option-01, 2019-March-05</t> <ul spacing="compact"> <li>Changed requested status from Standards Track to Experimental to allow use of experimental option type (11110) to allow for experimentation. Removed request for IANA Option assignment.</li> <li>Added <xref format="default" target="motivation" /> "Motivation and Problem Solved" section to better describe what the purpose of this document is.</li> <li>Added appendix describing planned experiments and how the results will be measured.</li> <li>Editorial changes.</li> </ul> <t>draft-hinden-6man-mtu-option-00, 2018-Oct-16</t> <ul spacing="compact"> <li>Initial draft.</li> </ul> </section></middle> <back> <displayreference target="I-D.ietf-taps-arch" to="TAPS-ARCH"/> <references> <name>References</name> <references> <name>Normative References</name> <xi:includehref="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.8200.xml" xmlns:xi="http://www.w3.org/2001/XInclude" />href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.8200.xml"/> <xi:includehref="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.8201.xml" xmlns:xi="http://www.w3.org/2001/XInclude" />href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.8201.xml"/> <xi:includehref="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.2119.xml" xmlns:xi="http://www.w3.org/2001/XInclude" />href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.2119.xml"/> <xi:includehref="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.8174.xml" xmlns:xi="http://www.w3.org/2001/XInclude" />href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.8174.xml"/> <reference anchor="IANA-HBH"target="https://www.iana.org/assignments/ipv6-parameters/ipv6-parameters.xhtml#ipv6-parameters-2">target="https://www.iana.org/assignments/ipv6-parameters/"> <front> <title>Destination Options and Hop-by-Hop Options</title><author /> <date /><author> <organization>IANA</organization> </author> </front> </reference> </references> <references> <name>Informative References</name> <xi:includehref="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.1063.xml" xmlns:xi="http://www.w3.org/2001/XInclude" />href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.1063.xml"/> <xi:includehref="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.1191.xml" xmlns:xi="http://www.w3.org/2001/XInclude" />href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.1191.xml"/> <xi:includehref="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.2460.xml" xmlns:xi="http://www.w3.org/2001/XInclude" />href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.2460.xml"/> <xi:includehref="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.4301.xml" xmlns:xi="http://www.w3.org/2001/XInclude" />href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.4301.xml"/> <xi:includehref="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.4302.xml" xmlns:xi="http://www.w3.org/2001/XInclude" />href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.4302.xml"/> <xi:includehref="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.4443.xml" xmlns:xi="http://www.w3.org/2001/XInclude" />href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.4443.xml"/> <xi:includehref="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.4861.xml" xmlns:xi="http://www.w3.org/2001/XInclude" />href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.4861.xml"/> <xi:includehref="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.4821.xml" xmlns:xi="http://www.w3.org/2001/XInclude" />href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.4821.xml"/> <xi:includehref="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.6438.xml" xmlns:xi="http://www.w3.org/2001/XInclude" />href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.6438.xml"/> <xi:includehref="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.7637.xml" xmlns:xi="http://www.w3.org/2001/XInclude" />href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.7637.xml"/> <xi:includehref="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.8085.xml" xmlns:xi="http://www.w3.org/2001/XInclude" />href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.8085.xml"/> <xi:includehref="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.8446.xml" xmlns:xi="http://www.w3.org/2001/XInclude" />href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.8446.xml"/> <xi:includehref="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.8899.xml" xmlns:xi="http://www.w3.org/2001/XInclude" />href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.8899.xml"/> <xi:includehref="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.8900.xml" xmlns:xi="http://www.w3.org/2001/XInclude" />href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.8900.xml"/> <xi:includehref="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.9000.xml" xmlns:xi="http://www.w3.org/2001/XInclude" />href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.9000.xml"/> <xi:includehref="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.9099.xml" xmlns:xi="http://www.w3.org/2001/XInclude" /> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml3/reference.I-D.ietf-taps-arch.xml" xmlns:xi="http://www.w3.org/2001/XInclude" />href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.9099.xml"/> <reference anchor="I-D.ietf-taps-arch" target="https://datatracker.ietf.org/doc/bibxml3/draft-ietf-taps-arch.xml"> <front> <title>An Architecture for Transport Services</title> <author initials='T' surname='Pauly' fullname='Tommy Pauly' role='editor'> <organization/> </author> <author initials='B' surname='Trammell' fullname='Brian Trammell' role='editor'> <organization/> </author> <author initials='A' surname='Brunstrom' fullname='Anna Brunstrom'> <organization/> </author> <author initials='G' surname='Fairhurst' fullname='Godred Fairhurst'> <organization/> </author> <author initials='C' surname='Perkins' fullname='Colin Perkins'> <organization/> </author> <date month='June' year='2022'/> </front> <seriesInfo name="Internet-Draft" value="draft-ietf-taps-arch-12"/> </reference> <reference anchor="VPP" target="https://wiki.fd.io/view/VPP/What_is_VPP%3F"> <front> <title>VPP/What is VPP?</title><author /> <date /><author> <organization>FD.io</organization> </author> </front> </reference> <reference anchor="VPP_SRC" target="https://gerrit.fd.io/r/c/vpp/+/21948"> <front><title>VPP Source</title> <author /><title>vpp</title> <author/> <date /> </front> <refcontent>commit 21948, ip: HBH MTU recording for IPv6</refcontent> </reference> <reference anchor="WIRESHARK" target="https://www.wireshark.org"> <front> <title>Wireshark Network Protocol Analyzer</title> <author /> <date /> </front> </reference> </references> </references><!--Appendix on Useage --><section anchor="appendix" numbered="true" toc="default"> <name>Examples of Usage</name> <t>This section provides examples that illustrate a use of the MinPMTU HBHoptionOption 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 sizea,a and then uses DPLPMTUD to seek to increase the size in steps resulting in sizes ofb,c,d,e, etc.,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'.</t> <t>The first example considers DPLPMTUD without using the MinPMTU HBHoption.Option. In this case, DPLPMTUD searches usingan increasing size ofa probepacket.packet that increases in size. Probe packets of size(e)e are sent, which are larger than the actual PMTU. In this example, PTB messages are not received from theroutersrouters, 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.ACKsAcknowledgments (ACKs) of data packets are not shown.</t> <figure> <artwork align="center" alt="" name="DPLPMTUD without the MinPMTU HBHoption"Option" type=""><![CDATA[ ----Packets of data size(a) ---------------------------->a ------------------------------> ----Probe size(b) -------------------------------------->b ----------------------------------------> <---------------------------------- ACK of probe -------- ----Packets of data size(b) ---------------------------->b ------------------------------> ----Probe size(c) -------------------------------------->c ----------------------------------------> <---------------------------------- ACK of probe -------- ----Packets of data size(c) ---------------------------->c ------------------------------> ----Probe size(d) -------------------------------------->d ----------------------------------------> <---------------------------------- ACK of probe -------- ----Packets of data size(d) ---------------------------->d ------------------------------> <---------------------------------- ACK of probe -------- ... ----Probe size(e) ------------Xe --------------X X----ICMPv6 PTB(d') --|d' ----| ----Packets of data size(d) ---------------------------->d ------------------------------> ----Probe size(e) ------------Xe --------------X (again) X----ICMPv6 PTB(d') --|d' ----| ----Packets of data size(d) -----------------------------d ------------------------------> ...etc,etc. until MaxProbes are unsuccessful and search phase completes. ----Packets of data size(d) ---------------------------->d ------------------------------> ]]></artwork> </figure> <t>The second example considers DPLPMTUD with the MinPMTU HBHoptionOption set on a connectivity probe packet.</t> <t>The IPv6optionOption is sentend-to-end,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 HBHoption.Option. Upon receiving the Rtn-PMTUvalue is received,value, DPLPMTUD immediately sends a probe packet of the target size(d').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 probesize,size d'.<!-- If an ICMPv6 PTB message is received, the algorithm finally probes for the indicated PTB_SIZE (d'), otherwise the final PLPMTU is d. --></t> <figure> <artwork align="center" alt="" name="DPLPMTUD with the MinPMTU HBH Option" type=""><![CDATA[ ----Packets of data size(a) ---------------------------->a ------------------------------> ----Connectivity probe with MinPMTU- +--updated to minPMTU=d'-----> <-----------------ACK with Rtn-PMTU=d'-------------------- ----Packets of data size(a) ---------------------------->a ------------------------------> ----Probe size(d') ------------------------------------->d' ---------------------------------------> <---------------------------------- ACK of probe --------- -----Packets of data size(d') -------------------------->d' ----------------------------> Search phase completes. -----Packets of data size(d') -------------------------->d' ----------------------------> ]]></artwork> </figure> <t>The final example considers DPLPMTUD with the MinPMTU HBHoptionOption set on a connectivity probepacket,packet but shows the effect when this connectivity probe packet is dropped.</t> <t>In this case, the packet with the MinPMTU HBHoptionOption 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').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.</t> <figure> <artwork align="center" alt="" name="" type="DPLPMTUD withdroppedDropped MinPMTU HBHoption"><![CDATA[Option"><![CDATA[ ----Packets of data size(a) ----------------------------->a -------------------------------> ----Connectivity probe with MinPMTU --------X ----Packets of data size(a) ----------------------------->a -------------------------------> ----Probe size(b) --------------------------------------->b -----------------------------------------> <---------------------------------- ACK of probe -------- ----Packets of data size(b) ----------------------------->b -------------------------------> ----Probe size(c) --------------------------------------->c -----------------------------------------> <---------------------------------- ACK of probe -------- ----Packets of data size(c) ----------------------------->c -------------------------------> ----Probe size(d) --------------------------------------->d -----------------------------------------> <---------------------------------- ACK of probe -------- ----Packets of data size(d) ----------------------------->d -------------------------------> ----Probe size(e) ----------Xe ------------X <--ICMPv6 PTBPTB_SIZE(d') -|PTB_SIZE d' --| ----Packets of data size(d) ----------------------------->d -------------------------------> ----Probe size(d')d' using target set by PTB_SIZE--------->-----------> <---------------------------------- ACK of probe -------- Search phase completes. ----Packets of data size(d') ---------------------------->d' ------------------------------> ]]></artwork> </figure> <t>The number of probe rounds depends on the number of steps needed by the searchalgorithm,algorithm and is typically larger for a larger PMTU.</t> </section><!--<sectionanchor="exp" numbered="true"anchor="Ack" numbered="false" title="Acknowledgments" toc="default"><name>Planned Experiments</name> <t>TBD </t> <t>This section will describe a set of experiments planned for the use of the option defined in this document. There are many aspects of the design that require experimental data or experience to evaluate this experimental specification.</t> <t>This includes experiments to understand the pathology of packets sent with the specified option to determine the likelihood that they are lost within specific types of network segment.</t> <t>This includes consideration of the cost and alternatives for providing the feedback required by the mechanism<t>Helpful comments were received from <contact fullname="Tom Herbert"/>, <contact fullname="Tom Jones"/>, <contact fullname="Fred Templin"/>, <contact fullname="Ole Troan"/>, <contact fullname="Tianran Zhou"/>, <contact fullname="Jen Linkova"/>, <contact fullname="Brian Carpenter"/>, <contact fullname="Peng Shuping"/>, <contact fullname="Mark Smith"/>, <contact fullname="Fernando Gont"/>, <contact fullname="Michael Dougherty"/>, <contact fullname="Erik Kline"/>, andhow to effectively limit the rate of transmission.</t> <t>This includes considerationother members of thepotential for integration in frameworks such as that offered by DPLPMTUD.</t> <t>There are also security-related topics to be understood as described in the <xref target="Security" format="default">Security Considerations</xref>.</t>6MAN Working Group.</t> </section>--></back> </rfc>