rfc9268.original.xml   rfc9268.xml 
<?xml version="1.0" encoding="US-ASCII"?> <?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE rfc SYSTEM "rfc2629-xhtml.ent">
<!-- <!DOCTYPE rfc SYSTEM "rfc2629.dtd"> --> <!DOCTYPE rfc [
<?xml-stylesheet type="text/xsl" href="rfc2629.xslt" ?> <!ENTITY nbsp "&#160;">
<?rfc strict="yes" ?> <!ENTITY zwsp "&#8203;">
<?rfc toc="yes"?> <!ENTITY nbhy "&#8209;">
<?rfc tocdepth="4"?> <!ENTITY wj "&#8288;">
<?rfc symrefs="yes"?> ]>
<?rfc sortrefs="yes" ?>
<?rfc compact="yes" ?> <rfc xmlns:xi="http://www.w3.org/2001/XInclude" docName="draft-ietf-6man-mtu-opt
<?rfc subcompact="no" ?> ion-15"
<rfc category="exp" docName="draft-ietf-6man-mtu-option-15" ipr="trust200902" number="9268" ipr="trust200902" obsoletes="" sortRefs="true" submissionType="IET
obsoletes="" sortRefs="true" submissionType="IETF" symRefs="true" F"
tocDepth="4" tocInclude="true" updates="" version="3" xml:lang="en"> category="exp" consensus="true" symRefs="true" tocDepth="4" tocInclude="true"
updates="" version="3" xml:lang="en">
<!-- xml2rfc v2v3 conversion 2.35.0 --> <!-- xml2rfc v2v3 conversion 2.35.0 -->
<front> <front>
<title abbrev="Path MTU Option">IPv6 Minimum Path MTU Hop-by-Hop <title abbrev="Path MTU Option">IPv6 Minimum Path MTU Hop-by-Hop
Option</title> Option</title>
<seriesInfo name="RFC" value="9268"/>
<seriesInfo name="Internet-Draft" value="draft-ietf-6man-mtu-option-15" />
<author fullname="Robert M. Hinden" initials="R" surname="Hinden"> <author fullname="Robert M. Hinden" initials="R" surname="Hinden">
<organization>Check Point Software</organization> <organization>Check Point Software</organization>
<address> <address>
<postal> <postal>
<street>959 Skyway Road</street> <street>959 Skyway Road</street>
<!-- Reorder these if your country does things differently -->
<city>San Carlos</city> <city>San Carlos</city>
<region>CA</region> <region>CA</region>
<code>94070</code> <code>94070</code>
<country>United States of America</country>
<country>USA</country>
</postal> </postal>
<phone />
<email>bob.hinden@gmail.com</email> <email>bob.hinden@gmail.com</email>
<!-- uri and facsimile elements may also be added -->
</address> </address>
</author> </author>
<author fullname="Godred Fairhurst" initials="G" surname="Fairhurst"> <author fullname="Godred Fairhurst" initials="G" surname="Fairhurst">
<organization>University of Aberdeen</organization> <organization>University of Aberdeen</organization>
<address> <address>
<postal> <postal>
<street>School of Engineering</street> <extaddr>School of Engineering</extaddr>
<street>Fraser Noble Building</street> <street>Fraser Noble Building</street>
<city>Aberdeen</city> <city>Aberdeen</city>
<region/>
<region />
<code>AB24 3UE</code> <code>AB24 3UE</code>
<country>United Kingdom</country>
<country>UK</country>
</postal> </postal>
<email>gorry@erg.abdn.ac.uk</email> <email>gorry@erg.abdn.ac.uk</email>
</address> </address>
</author> </author>
<date day="" month="" year="" /> <date year="2022" month="August"/>
<area>int</area>
<workgroup>6man</workgroup>
<keyword>DPLPMTUD</keyword>
<keyword>PMTUD</keyword>
<abstract> <abstract>
<t>This document specifies a new IPv6 Hop-by-Hop option that is used to <t>This document specifies a new IPv6 Hop-by-Hop Option that is used to
record the minimum Path MTU along the forward path between a source host 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 a destination host. The recorded value can then be communicated back
to the source using the return Path MTU field in the option.</t> to the source using the return Path MTU field in the Option.</t>
</abstract> </abstract>
</front> </front>
<middle> <middle>
<section anchor="Intro" numbered="true" title="Introduction" toc="default"> <section anchor="Intro" numbered="true" title="Introduction" toc="default">
<t>This document specifies a new IPv6 Hop-by-Hop (HBH) Option to record th e <t>This document specifies a new IPv6 Hop-by-Hop (HBH) Option to record th e
minimum Maximum Transmission Unit (MTU) along the forward path between a minimum Maximum Transmission Unit (MTU) along the forward path between a
source and a destination host. The source host creates a packet with 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 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 for the outbound link that will be used to forward the packet towards
the destination host.</t> the destination host.</t>
<t>At each subsequent hop where the option is processed, the router <t>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 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 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 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 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 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 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 input to the method that sets the Path MTU (PMTU) used by upper-layer
protocols.</t> protocols.</t>
<t>The IPv6 Minimum Path MTU Hop-by-Hop (MinPMTU HBH) Option <t>The IPv6 Minimum Path MTU Hop-by-Hop (MinPMTU HBH) Option
is designed to work with packet sizes that can be is designed to work with packet sizes that can be
specified in the IPv6 header. The maximum packet size 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> specified in an IPv6 header is 65,535 octets (2<sup>16</sup>).</t>
<t>This method has the potential to complete Path MTU discovery in a <t>This method has the potential to complete Path MTU Discovery (PMTUD) in
single round trip time, even over paths that have successive links each a
single round-trip time, even over paths that have successive links, each
with a lower MTU.</t> with a lower MTU.</t>
<t>The mechanism defined in this document is focused on Unicast, it does <t>The mechanism defined in this document is focused on unicast; it does
not describe Multicast. That is left for future work.</t> not describe multicast. That is left for future work.</t>
<section anchor="Intro1" numbered="true" title="Example Operation" <section anchor="Intro1" numbered="true" title="Example Operation"
toc="default"> toc="default">
<t>The figure below illustrates the operation of the method. In this <t>The figure below illustrates the operation of the method. In this
case, the path between the source host and the destination host 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 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 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> 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[ <artwork align="center" alt="" name="" type=""><![CDATA[
+--------+ +----+ +----+ +-------+
+--------+ +----+ +----+ +-------+ | | | | | | | |
| | | | | | | | | Sender +---------+ R1 +--------+ R2 +-------- + Dest. |
| Sender +---------+ R1 +--------+ R2 +-------- + Dest. | | | | | | | | |
| | | | | | | | +--------+ MTU-S +----+ 9000B +----+ MTU-D +-------+
+--------+ MTU-S +----+ 9000B +----+ MTU-D +-------+ ]]></artwork>
]]></artwork>
</figure> </figure>
<t>Three scenarios are described:</t> <t>Three scenarios are described:</t>
<ul spacing="normal"> <ul spacing="normal">
<li> <li>
<t>Scenario 1, considers all links to have an 9000 byte MTU and <t>Scenario 1 considers all links to have a 9000 byte MTU, and
the method is supported by both routers. The initial Min-PMTU is the method is supported by both routers. The initial Min-PMTU is
not modified along the path, and therefore the PMTU is 9000 not modified along the path. Therefore, the PMTU is 9000
bytes.</t> bytes.</t>
</li> </li>
<li> <li>
<t>Scenario 2, considers the link between R2 and destination host <t>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, (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 Router R2 updates the Min-PMTU to 1500 bytes, and the method
correctly updates the PMTU to 1500 bytes. Had there been another correctly updates the PMTU to 1500 bytes. Had there been another
smaller MTU at a link further along the path that also supports smaller MTU at a link further along the path that also supports
the method, the lower MTU would also have been detected.</t> the method, the lower MTU would also have been detected.</t>
</li> </li>
<li> <li>
<t>Scenario 3, considers the case where the router preceding the <t>Scenario 3 considers the case where the router preceding the
smallest link (R2) does not support the method, and the link to smallest link (R2) does not support the method, and the link to
the destination host (MTU-D) has an MTU of 1500 bytes. Therefore, 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 router R2 does not update the Min-PMTU to 1500 bytes. The method
then fails to detect the actual PMTU.</t> then fails to detect the actual PMTU.</t>
</li> </li>
</ul> </ul>
<t>In Scenarios 2 and 3, a lower PMTU would also fail to be detected <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 in the case where PMTUD had been used and an ICMPv6 Packet Too Big
(PTB) message had not been delivered to the sender <xref (PTB) message had not been delivered to the sender <xref
format="default" target="RFC8201" />.</t> format="default" target="RFC8201" />.</t>
<t>These scenarios are summarized in the table below. "H" in R1 and/or <t>These scenarios are summarized in the table below. "H" in R1 and/or
R2 columns means the router understands the MinPMTU HBH option.</t> R2 columns means the router understands the MinPMTU HBH Option.</t>
<table align="center">
<figure> <name>Three Scenarios That Arise from Using the Path Shown in Figure 1<
<artwork align="center" alt="" name="" type=""><![CDATA[ /name>
<thead>
+-+-----+-----+----+----+----------+-----------------------+ <tr>
| |MTU-S|MTU-D| R1 | R2 | Rec PMTU | Note | <th></th>
+-+-----+-----+----+----+----------+-----------------------+ <th>MTU-S</th>
|1|9000B|9000B| H | H | 9000 B | Endpoints attempt to | <th>MTU-D</th>
| | | | | | use a 9000 B PMTU. | <th>R1</th>
+-+-----+-----+----+----+----------+-----------------------+ <th>R2</th>
|2|9000B|1500B| H | H | 1500 B | Endpoints attempt to | <th>Rec&nbsp;PMTU</th>
| | | | | | | use a 1500 B PMTU. | <th>Note</th>
+-+-----+-----+----+----+----------+-----------------------+ </tr>
|3|9000B|1500B| H | - | 9000 B | Endpoints attempt to | </thead>
| | | | | | | use a 9000 B PMTU, | <tbody>
| | | | | | | but need to implement | <tr>
| | | | | | | a method to fall back | <td>1</td>
| | | | | | | to discover and use a | <td>9000&nbsp;B</td>
| | | | | | | 1500 B PMTU. | <td>9000&nbsp;B</td>
+-+-----+-----+----+----+----------+-----------------------+ <td>H</td>
<td>H</td>
]]></artwork> <td>9000&nbsp;B</td>
</figure> <td>Endpoints attempt to use a 9000 B PMTU.</td>
</tr>
<tr>
<td>2</td>
<td>9000&nbsp;B</td>
<td>1500&nbsp;B</td>
<td>H</td>
<td>H</td>
<td>1500&nbsp;B</td>
<td>Endpoints attempt to use a 1500 B PMTU.</td>
</tr>
<tr>
<td>3</td>
<td>9000&nbsp;B</td>
<td>1500&nbsp;B</td>
<td>H</td>
<td>-</td>
<td>9000&nbsp;B</td>
<td>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.</td>
</tr>
</tbody>
</table>
</section> </section>
<section anchor="Intro2" numbered="true" <section anchor="Intro2" numbered="true"
title="Use of the IPv6 Hop-by-Hop Options Header" toc="default"> title="Use of the IPv6 Hop-by-Hop Options Header" toc="default">
<t>IPv6 as specified in <xref format="default" target="RFC8200" /> <t>As specified in <xref format="default" target="RFC8200"/>, IPv6
allows nodes to optionally process the Hop-by-Hop header. allows nodes to optionally process the Hop-by-Hop header.
Specifically, from Section 4:</t> Specifically, from <xref target="RFC8200" sectionFormat="of" section="4"
format="default"/>:</t>
<ul spacing="normal"> <blockquote>
<li>
<t>The Hop-by-Hop Options header is not inserted or deleted, but <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 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 path, until the packet reaches the node (or each of the set of
nodes, in the case of multicast) identified in the Destination nodes, in the case of multicast) identified in the Destination
Address field of the IPv6 header. The Hop-by-Hop Options header, Address field of the IPv6 header. The Hop-by-Hop Options header,
when present, must immediately follow the IPv6 header. Its when present, must immediately follow the IPv6 header. Its
presence is indicated by the value zero in the Next Header field presence is indicated by the value zero in the Next Header field
of the IPv6 header.</t> of the IPv6 header.</t>
</li>
<li>
<t>NOTE: While <xref format="default" target="RFC2460" /> required <t>NOTE: While <xref format="default" target="RFC2460" /> required
that all nodes must examine and process the Hop-by-Hop Options that all nodes must examine and process the Hop-by-Hop Options
header, it is now expected that nodes along a packet's delivery header, it is now expected that nodes along a packet's delivery
path only examine and process the Hop-by-Hop Options header if path only examine and process the Hop-by-Hop Options header if
explicitly configured to do so.</t> explicitly configured to do so.</t>
</li> </blockquote>
</ul>
<t>The Hop-by-Hop Option defined in this document is designed to take <t>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. advantage of this property of how Hop-by-Hop Options are processed.
Nodes that do not support this Option SHOULD ignore them. This can Nodes that do not support this Option <bcp14>SHOULD</bcp14> ignore them.
This can
mean that the Min-PMTU value does not account for all links along a mean that the Min-PMTU value does not account for all links along a
path.</t> 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>
</section> </section>
<!-- End of Into Section-->
<section anchor="motivation" numbered="true" <section anchor="motivation" numbered="true"
title="Motivation and Problem Solved" toc="default"> title="Motivation and Problem Solved" toc="default">
<t>The current state of Path MTU Discovery on the Internet is <t>The current state of Path MTU Discovery on the Internet is
problematic. The mechanisms defined in <xref format="default" problematic. The mechanisms defined in <xref format="default"
target="RFC8201" /> are known to not work well in all environments. It 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 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 the network do not send ICMPv6 PTB messages or rate-limited ICMPv6
messages, or do not have a return path to the source host.</t> messages or do not have a return path to the source host. This results in
many transport-layer connections being configured to
<t>This results in many transport layer connections being configured to
use smaller packets (e.g., 1280 bytes) by default and makes it difficult 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. to take advantage of paths with a larger PMTU where they do exist.
Applications that send large packets are forced to use IPv6 Applications that send large packets are forced to use IPv6
Fragmentation <xref format="default" target="RFC8200" />, which can fragmentation <xref format="default" target="RFC8200" />, which can
reduce the reliability of Internet communication <xref format="default" reduce the reliability of Internet communication <xref format="default"
target="RFC8900" />.</t> target="RFC8900" />.</t>
<t>Encapsulations and network-layer tunnels further reduce the payload <t>Encapsulations and network-layer tunnels further reduce the payload
size available for a transport protocol to use. Also, some use-cases size available for a transport protocol to use. Also, some use cases
increase packet overhead, for example, Network Virtualization Using increase packet overhead, for example, Network Virtualization Using
Generic Routing Encapsulation (NVGRE) <xref format="default" Generic Routing Encapsulation (NVGRE) <xref format="default"
target="RFC7637" /> encapsulates L2 packets in an outer IP header and target="RFC7637" /> encapsulates Layer 2 (L2) packets in an outer IP heade
does not allow IP Fragmentation.</t> r and
does not allow IP fragmentation.</t>
<!--
<t>Sending larger packets can improve host performance, e.g.,
avoiding limits to packet processing by the packet rate.
The potential of multi-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 packets is about 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 <t>Sending larger packets can improve host performance, e.g., avoiding
limits to packet processing by the packet rate. For example, the packet limits to packet processing by the packet rate. An example of this is how
per second rate required to reach wire speed on a 10G link with 1280 the
byte packets is about 977K packets per second (pps), vs. 139K pps for 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.</t> 9000 byte packets.</t>
<t>The purpose of this document is to improve the situation by defining <t>The purpose of this document is to improve the situation by defining
a mechanism that does not rely on reception of ICMPv6 Packet Too Big a mechanism that does not rely on reception of ICMPv6 PTB
messages from nodes in the middle of the network. Instead, this provides messages from nodes in the middle of the network. Instead, this provides
information to the destination host about the minimum Path MTU, and information to the destination host about the Minimum Path MTU and
sends this information back to the source host. This is expected to work sends this information back to the source host. This is expected to work
better than the current RFC8201-based mechanisms.</t> better than the current mechanisms based on <xref target="RFC8201"
format="default"/>.</t>
<t>A similar mechanism was proposed in 1988 for IPv4 in <xref <t>A similar mechanism was proposed in 1988 for IPv4 in <xref
format="default" target="RFC1063" /> by Jeff Mogul, C. Kent, Craig format="default" target="RFC1063" /> by Jeff Mogul, C. Kent, Craig
Partridge, and Keith McCloghire. It was later obsoleted in 1990 by <xref Partridge, and Keith McCloghire. It was later obsoleted in 1990 by <xref
format="default" target="RFC1191" />, the current deployed approach to format="default" target="RFC1191" />, which is the current deployed approa ch to
Path MTU Discovery. In contrast, the method described in this document Path MTU Discovery. In contrast, the method described in this document
uses the Hop-by-Hop option of IPv6. It does not replace PMTUD <xref uses the Hop-by-Hop Option of IPv6. It does not replace PMTUD <xref
format="default" target="RFC8201" />, PLPPMTUD <xref format="default" format="default" target="RFC8201" />, Packetization Layer Path MTU Discove
target="RFC4821" /> or Datagram PLPMTUD <xref format="default" ry
target="RFC8899" />, but rather is designed to compliment these (PLPMTUD) <xref format="default"
target="RFC4821" />, or Datagram Packetization Layer PMTU Discovery (DPLPM
TUD) <xref format="default"
target="RFC8899" /> but rather is designed to compliment these
methods.</t> methods.</t>
</section> </section>
<section numbered="true" title="Requirements Language" toc="default"> <section numbered="true" title="Requirements Language" toc="default">
<t>The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", <t>The key words "<bcp14>MUST</bcp14>", "<bcp14>MUST NOT</bcp14>",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "<bcp14>REQUIRED</bcp14>", "<bcp14>SHALL</bcp14>", "<bcp14>SHALL NOT</bcp1
"OPTIONAL" in this document are to be interpreted as described in BCP 14 4>",
<xref format="default" target="RFC2119" /> <xref format="default" "<bcp14>SHOULD</bcp14>", "<bcp14>SHOULD NOT</bcp14>", "<bcp14>RECOMMENDED<
/bcp14>",
"<bcp14>NOT RECOMMENDED</bcp14>", "<bcp14>MAY</bcp14>", and
"<bcp14>OPTIONAL</bcp14>" in this document are to be interpreted as descri
bed in
BCP&nbsp;14 <xref format="default" target="RFC2119" /> <xref format="defau
lt"
target="RFC8174" /> when, and only when, they appear in all capitals, as target="RFC8174" /> when, and only when, they appear in all capitals, as
shown here.</t> shown here.</t>
</section> </section>
<!-- Requirements Language --> <section numbered="true" title="Applicability Statements" toc="default"
anchor="app-state">
<section numbered="true" title="Applicability Statements" toc="default"> <t>The Path MTU Option is designed for environments where there is
<t>The Path MTU option is designed for environments where there is control over the hosts and nodes that connect them and 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
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
between Data Centers, to allow hosts to better take advantage of a path
that is able to support a large PMTU.</t> that is able to support a large PMTU.</t>
<t>The design of the option is sufficiently simple that it can be <t>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 executed on a router's fast path. A successful experiment depends on
both implementation by host and router vendors and deployment by both implementation by host and router vendors and deployment by
operators. The contained use-case of connections within and between Data operators. The contained use case of connections within and between data
Centers could be a driver for deployment.</t> centers could be a driver for deployment.</t>
<t>The method could also be useful in other environments, including the <t>The method could also be useful in other environments, including the
general Internet, and offers advantage when this Hop-by-Hop Option is 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 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 path using packets that do not carry application data and when also
paired with a method such as Packetization Layer PMTUD <xref paired with a method like Packetization Layer PMTUD <xref
format="default" target="RFC4821" /> or Datagram PLPMTUD <xref format="default" target="RFC4821" /> or Datagram Packetization Layer PMTU
Discovery (DPLPMTUD) <xref
format="default" target="RFC8899" />.</t> format="default" target="RFC8899" />.</t>
</section> </section>
<!-- Applicability Statements -->
<section anchor="HBH" numbered="true" <section anchor="HBH" numbered="true"
title="IPv6 Minimum Path MTU Hop-by-Hop Option" toc="default"> 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> <t>The Minimum Path MTU Hop-by-Hop Option has the following format:</t>
<figure> <figure>
<name>Format of the Minimum Path MTU Hop-by-Hop Option</name>
<artwork align="center" alt="" name="" type=""><![CDATA[ <artwork align="center" alt="" name="" type=""><![CDATA[
Option Option Option Option Option Option
Type Data Len Data Type Data Len Data
+--------+--------+--------+--------+---------+-------+-+ +--------+--------+--------+--------+---------+-------+-+
|BBCTTTTT|00000100| Min-PMTU | Rtn-PMTU |R| |BBCTTTTT|00000100| Min-PMTU | Rtn-PMTU |R|
+--------+--------+--------+--------+---------+-------+-+ +--------+--------+--------+--------+---------+-------+-+
]]></artwork>
</figure>
Option Type (see Section 4.2 of [RFC8200]): <t>Option Type (see <xref target="RFC8200" section="4.2" sectionFormat="of"/>):<
/t>
BB 00 Skip over this option and continue processing. <artwork align="center" alt="" name="" type=""><![CDATA[
BB 00 Skip over this Option and continue processing.
C 1 Option data can change en route to the packet's final C 1 Option Data can change en route to the packet's final
destination. destination.
TTTTT 10000 Option Type assigned from IANA [IANA-HBH]. TTTTT 10000 Option Type assigned from IANA [IANA-HBH].
Length: 4 The size of the value field in Option Data Length: 4 The size of the value field in Option Data
field supports PMTU values from 0 to 65,534 octets, the field supports PMTU values from 0 to 65,534
maximum size represented by the Path MTU option. octets, the maximum size represented by the
Path MTU Option.
Min-PMTU: n 16-bits. The minimum MTU recorded along the path Min-PMTU: n 16-bits. The minimum MTU recorded along the path
in octets, reflecting the smallest link MTU that in octets, reflecting the smallest link MTU that
the packet experienced along the path. the packet experienced along the path.
A value less than the IPv6 minimum link A value less than the IPv6 minimum link
MTU [RFC8200] MUST be ignored. MTU [RFC8200] MUST be ignored.
Rtn-PMTU: n 15-bits. The returned Path MTU field, carrying the 15 Rtn-PMTU: n 15-bits. The returned Path MTU field, carrying the 15
most significant bits of the latest received Min-PMTU most significant bits of the latest received Min-PMTU
field for the forward path. The value zero means that field for the forward path. The value zero means that
no Reported MTU is being returned. no Reported MTU is being returned.
R n 1-bit. R-Flag. Set by the source to signal that R n 1-bit. R-Flag. Set by the source to signal that
the destination host should include the received the destination host should include the received
Rtn-PMTU field updated by the reported Min-PMTU value Rtn-PMTU field updated by the reported Min-PMTU value
when the destination host is to send a PMTU Option back when the destination host is to send a PMTU Option back
to the source host. to the source host.
]]></artwork> ]]></artwork>
</figure>
<t>NOTE: The encoding of the final two octets (Rtn-PMTU and R-Flag) <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 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 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 'OR' with the R-Flag value of the sender. This encoding fits in the
minimum-sized Hop-by-Hop Option header.</t> minimum-sized Hop-by-Hop Option header.</t>
</section> </section>
<!-- End of Option Defination section -->
<section anchor="Behavior" numbered="true" <section anchor="Behavior" numbered="true"
title="Router, Host, and Transport Layer Behaviors" toc="default"> title="Router, Host, and Transport Layer Behaviors" toc="default">
<section anchor="router" numbered="true" title="Router Behavior" <section anchor="router" numbered="true" title="Router Behavior"
toc="default"> toc="default">
<t>Routers that are not configured to support Hop-by-Hop Options are <t>Routers that are not configured to support Hop-by-Hop Options are
not expected to examine or process the contents of this option <xref not expected to examine or process the contents of this Option <xref
format="default" target="RFC8200" />.</t> format="default" target="RFC8200" />.</t>
<!-- <t>Routers that support Hop-by-Hop Options but are not configured to
<t>Routers that are not configured to support Hop-by-Hop Options support this Option <bcp14>SHOULD</bcp14> skip over this Option and cont
SHOULD ignore this option and SHOULD forward the packet <xref inue to
format="default" target="RFC8200" />.</t> process the header <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 this option SHOULD skip over this option and continue to
processing the header <xref format="default" target="RFC8200" />.</t>
<!--
<t>Routers that support Hop-by-Hop Options, but that are not
configured to support this option 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> </l
i>
</ul>
<t>Routers that support this option MUST compare the value of the <t>Routers that support this Option <bcp14>MUST</bcp14> compare the valu e of the
Min-PMTU field with the MTU configured for the outgoing link. If 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 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 rewrites the Min-PMTU in the Option to use the smaller value. (The
router processing is performed without checking the valid range of the router processing is performed without checking the valid range of the
Min-PMTU or the Rtn-PMTU fields.)</t> Min-PMTU or the Rtn-PMTU fields.)</t>
<t>A router MUST ignore and MUST NOT change the Rtn-PMTU field or the <t>A router <bcp14>MUST</bcp14> ignore and <bcp14>MUST NOT</bcp14> chang
R-Flag in the option.</t> e the
Rtn-PMTU field or the R-Flag in the Option.</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>
</section> </section>
<!--End of Router Behavior subsection-->
<section anchor="host-os" numbered="true" <section anchor="host-os" numbered="true"
title="Host Operating System Behavior" toc="default"> 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 <t>The PMTU entry associated with the destination in the host's
destination cache <xref format="default" target="RFC4861" /> SHOULD be destination cache <xref format="default" target="RFC4861" />
<bcp14>SHOULD</bcp14> be
updated after detecting a change using the IPv6 Minimum Path MTU 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 Hop-by-Hop Option. This cached value can be used by other flows that
share the host's destination cache.</t> share the host's destination cache.</t>
<!-- <t>The value in the host destination cache <bcp14>SHOULD</bcp14> be used
** Watch out for confusing use of PMTUD? Is it referring to 8201 or this mechani by
sm? PLPMTUD to select an initial PMTU for a flow. The cached PMTU is only
<!--
<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 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 increased by PLPMTUD when the Packetization Layer determines the path
actually supports a larger PMTU <xref format="default" actually supports a larger PMTU <xref format="default"
target="RFC4821" /> <xref format="default" target="RFC8899" />.</t> target="RFC4821" /> <xref format="default" target="RFC8899" />.</t>
<t>When requested to send an IPv6 packet with the MinPMTU HBH <t>When requested to send an IPv6 packet with the MinPMTU HBH
option, the source host includes the option in an outgoing packet. The 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 source host <bcp14>MUST</bcp14> fill the Min-PMTU field with the MTU
the link over which it will send the packet on the next hop towards configured for the link over which it will send the packet on the next ho
p towards
the destination host.</t> the destination host.</t>
<t>When a host includes the option in a packet it sends, the host <t>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 <bcp14>SHOULD</bcp14> set the Rtn-PMTU field to the previously cached va
lue of the
received Minimum Path MTU for the flow in the Rtn-PMTU field (see received Minimum Path MTU for the flow in the Rtn-PMTU field (see
<xref target="transportrec" />). If this value is not set (for <xref target="transportrec" />). If this value is not set (for
example, because there is no cached reported Min-PMTU value), the example, because there is no cached reported Min-PMTU value), the
Rtn-PMTU field value MUST be set to zero.</t> Rtn-PMTU field value <bcp14>MUST</bcp14> be set to zero.</t>
<t>The source host MAY request the destination host to return the <t>The source host <bcp14>MAY</bcp14> request the destination host to re
reported Min-PMTU value by setting the R-Flag in the option of an turn the
outgoing packet. The R-Flag SHOULD NOT be set when the MinPMTU reported Min-PMTU value by setting the R-Flag in the Option of an
outgoing packet. The R-Flag <bcp14>SHOULD NOT</bcp14> be set when the Mi
nPMTU
HBH Option was sent solely to provide requested feedback on the return HBH Option was sent solely to provide requested feedback on the return
Path MTU to avoid each response generating another response.</t> Path MTU to avoid each response generating another response.</t>
<t>The destination host controls when to send a packet with this <t>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 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 it in. The destination host <bcp14>MAY</bcp14> limit the rate at which i
t sends these
packets.</t> packets.</t>
<t>A destination host only sets the R Flag if it wishes the source <t>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 host to also return the discovered PMTU value for the path from the
destination to the source.</t> destination to the source.</t>
<!--
<t>The normal sequence of operation of the R-Flag using the terminolog
y from
the diagram in Figure 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 <t>The normal sequence of operation of the R-Flag using the
terminology from the diagram in Figure 1 is:</t> terminology from the diagram in <xref target="fig1"/> is:</t>
<ol type="1"> <ol type="1">
<li> <li>
<t>The source sends a probe to the destination. The sender sets <t>The source sends a probe to the destination. The sender sets
the R-Flag.</t> the R-Flag.</t>
</li> </li>
<li> <li>
<t>The destination responds by sending a probe including the <t>The destination responds by sending a probe including the
received Min-PMTU as the Rtn-PMTU. A destination that does not 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> wish to probe the return path sets the R-Flag to 0.</t>
</li> </li>
</ol> </ol>
</section> </section>
<!-- End of Host OS section-->
<section anchor="Transport" numbered="true" <section anchor="Transport" numbered="true"
title="Transport Layer Behavior" toc="default"> title="Transport Layer Behavior" toc="default">
<t>This Hop-by-Hop option is intended to be used with a path MTU <t>This Hop-by-Hop Option is intended to be used with a Path MTU
discovery method.</t> Discovery 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" /> uses probe <t>PLPMTUD <xref format="default" target="RFC8899" /> uses probe
packets for two distinct functions:</t> packets for two distinct functions:</t>
<ul> <ul>
<li>Probe packets are used to confirm connectivity. Such probes can <li>Probe packets are used to confirm connectivity. Such probes can
be of any size up to the PLPMTU. These probe packets are sent to be of any size up to the Packetization Layer Path MTU (PLPMTU). These
solicit a response use the path to the remote node. These probe probe packets are sent to
packets can carry the Hop-by-Hop PMTU option, providing the final 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 size of the packet does not exceed the current PLPMTU. After
validating that the packet originates from the path (section 4.6.1), validating that the packet originates from the path (<xref target="RFC
the PLPMTUD method can use the reported size from the Hop-by-Hop optio 8899"
n as section="4.6.1" sectionFormat="of"/>),
the PLPMTUD method can use the reported size from the Hop-by-Hop Optio
n as
the next search point when it resumes the search algorithm. (This 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 use resembles the use of the PTB_SIZE information in <xref format="def
of <xref format="default" target="RFC8899" /></li> ault"
target="RFC8899" section="4.6.2" sectionFormat="of"/>.)</li>
<li>A second use of probe packets is to explore if a path supports a <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 packet size greater than the current PLPMTU. If this probe packet is
successfully delivered (as determined by the source host), then the successfully delivered (as determined by the source host), then the
PLPMTU is raised to the size of the successful probe. These probe 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 packets do not usually set the Path MTU Hop-by-Hop Option. See
section 1.2 of <xref format="default" target="RFC8899" />. Section <xref target="RFC8899" section="1.2" sectionFormat="of"/>. <xref
4.1 of <xref format="default" target="RFC8899" /> also describes format="default" target="RFC8899" section="4.1" sectionFormat="of"/> al
ways that a Probe Packet can be constructed, depending on whether so
describes ways that a probe packet can be constructed, depending on whe
ther
the probe packets carry application data.</li> the probe packets carry application data.</li>
</ul>
<li>The PMTU Hop-by-Hop Option Probe can be sent on packets that <t>The PMTU Hop-by-Hop Option probe can be sent on packets that
include application data, but needs to be robust to potential loss include application data but needs to be robust to potential loss
of the packet (i.e., with the possibility that retransmission might of the packet (i.e., with the possibility that retransmission might
be needed if the packet is lost).</li> be needed if the packet is lost).</t>
<li>Using a PMTU Probe on packets that do not carry application data <t>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 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 packets that set this Option. (This avoids the transport needing to
retransmit a lost packet that includes this option.) This is the retransmit a lost packet that includes this Option.) This is the
normal default format for both uses of probes.</li> normal default format for both uses of probes.</t>
</ul>
<!-- subsections... -->
<section anchor="transportsend" numbered="true" <section anchor="transportsend" numbered="true"
title="Including the Option in an Outgoing Packet" title="Including the Option in an Outgoing Packet"
toc="default"> toc="default">
<t>The upper layer protocol can request the MinPMTU HBH option <t>The upper-layer protocol can request the MinPMTU HBH Option
to be included in an outgoing IPv6 packet. A transport protocol (or to be included in an outgoing IPv6 packet. A transport protocol (or
upper layer protocol) can include this option only on specific upper-layer protocol) can include this Option only on specific
packets used to test the path. This option does not need to be packets used to test the path. This Option does not need to be
included in all packets belonging to a flow.</t> included in all packets belonging to a flow.</t>
<t>NOTE: Including this option in a large packet (e.g., one larger <t>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 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 packet would itself be dropped by any link along the path with a
smaller MTU, preventing the Min-PMTU information from reaching the smaller MTU, preventing the Min-PMTU information from reaching the
destination host.</t> destination host.</t>
<t>Discussion:</t> <t>Discussion:</t>
<ul spacing="normal"> <ul spacing="normal">
<li> <li>
<t>In the case of TCP, the option could be included in a packet <t>In the case of TCP, the Option could be included in a packet
that carries a TCP segment sent after the connection is that carries a TCP segment sent after the connection is
established. A segment without data could be used, to avoid the established. A segment without data could be used to avoid the
need to retransmit this data if the probe packet is lost. The need to retransmit this data if the probe packet is lost. The
discovered value can be used to inform PLPMTUD <xref discovered value can be used to inform PLPMTUD <xref
format="default" target="RFC4821" />.</t> format="default" target="RFC4821" />.</t>
<t>NOTE: A TCP SYN can also negotiate the Maximum Segment Size <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 (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 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 TCP SYN, it could increase the probability that the SYN segment
is lost when routers on the path drop packets with this option is lost when routers on the path drop packets with this Option
(see <xref target="HBHblackhole" />), which could have an (see <xref target="HBHblackhole" />), which could have an
unwanted impact on the result of racing options <xref unwanted impact on the result of racing Options <xref
format="default" target="I-D.ietf-taps-arch" /> or feature format="default" target="I-D.ietf-taps-arch" /> or feature
negotiation.</t> negotiation.</t>
</li> </li>
<li> <li>
<t>The use with datagram transport protocols (e.g., UDP) is <t>The use with datagram transport protocols (e.g., UDP) is
harder to characterize because applications using datagram harder to characterize because applications using datagram
transports range from very short-lived (low data-volume transports range from very short-lived (low data-volume
applications) exchanges, to longer (bulk) exchanges of packets applications) exchanges to longer (bulk) exchanges of packets
between the source and destination hosts <xref format="default" between the source and destination hosts <xref format="default"
target="RFC8085" />.</t> target="RFC8085" />.</t>
</li> </li>
<li> <li>
<t>Simple-exchange protocols (i.e., low data-volume applications <t>Simple-exchange protocols (i.e., low data-volume applications
<xref format="default" target="RFC8085" /> that only send one or <xref format="default" target="RFC8085" /> that only send one or
a few packets per transaction), might assume that the PMTU is a few packets per transaction) might assume that the PMTU is
symmetrical. That is, the PMTU is the same in both directions, symmetrical. That is, the PMTU is the same in both directions
or at least not smaller for the return path. This optimization or at least not smaller for the return path. This optimization
does not hold when the paths are not symmetric.</t> does not hold when the paths are not symmetric.</t>
</li> </li>
<li> <li>
<t>The MinPMTU HBH option can be used with ICMPv6 <t>The MinPMTU HBH Option can be used with ICMPv6
<xref format="default" target="RFC4443" />. This requires a <xref format="default" target="RFC4443" />. This requires a
response from the remote node and therefore is restricted to use response from the remote node and therefore is restricted to use
with ICMPv6 echo messages. The MinPMTU HBH option with ICMPv6 echo messages. The MinPMTU HBH Option
could provide additional information about the PMTU that might could provide additional information about the PMTU that might
be supported by a path. This could be use as a diagnostic tool 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 to measure the PMTU of a path. As with other uses, the actual
supported PMTU is only confirmed after receiving a response to a supported PMTU is only confirmed after receiving a response to a
subsequent probe of the PMTU size.</t> subsequent probe of the PMTU size.</t>
</li> </li>
<li> <li>
<t>A datagram transport can utilise DPLPMTUD <xref <t>A datagram transport can utilize DPLPMTUD <xref format="default
format="default" target="RFC8899" />. For example, QUIC (see "
section 14.3 of <xref format="default" target="RFC9000" />), can target="RFC8899" />. For
example, QUIC (see <xref format="default" target="RFC9000"
sectionFormat="of" section="14.3"/>) can
use DPLPMTUD to determine whether the path to a destination will use DPLPMTUD to determine whether the path to a destination will
support a desired maximum datagram size. When using the IPv6 support a desired maximum datagram size. When using the IPv6
MinPMTU HBH option, the option could be added to an MinPMTU HBH Option, the Option could be added to an
additional QUIC PMTU Probe that is of minimal size (or one no additional QUIC PMTU probe that is of minimal size (or one no
larger than the currently supported PMTU size). Once the return larger than the currently supported PMTU size). Once the return
Path MTU value in the MinPMTU HBH option has been Path MTU value in the MinPMTU HBH Option has been
learned, DPLPMTUD can be triggered to test for a larger PLPMTU learned, DPLPMTUD can be triggered to test for a larger PLPMTU
using an appropriately sized PLPMTU Probe Packet (see section using an appropriately sized PLPMTU probe packet (see <xref
5.3.1 of <xref format="default" target="RFC8899" />).</t> format="default" target="RFC8899" sectionFormat="of" section="5.3.1
"/>).</t>
</li> </li>
<li> <li>
<t>The use of this option with DNS and DNSSEC over UDP is <t>The use of this Option with DNS and DNSSEC over UDP is
expected to work for paths where the PMTU is symmetric. The DNS expected to work for paths where the PMTU is symmetric. The DNS
server will learn the PMTU from the DNS query messages. If the server will learn the PMTU from the DNS query messages. If the
Rtn-PMTU value is smaller, then a large DNSSEC response might be Rtn-PMTU value is smaller, then a large DNSSEC response might be
dropped and the known problems with PMTUD will then occur. DNS dropped and the known problems with PMTUD will then occur. DNS
and DNSSEC over transport protocols that can carry the PMTU and DNSSEC over transport protocols that can carry the PMTU
ought to work.</t> ought to work.</t>
</li> </li>
<li> <li>
<t>This method also can be used with Anycast to discover the <t>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 PMTU of the path, but the use needs to be aware that the anycast
binding might change.</t> binding might change.</t>
</li> </li>
</ul> </ul>
</section> </section>
<!-- End of IPv6 outgoing transport processing -->
<section anchor="transportvalid" numbered="true" <section anchor="transportvalid" numbered="true"
title="Validation of the Packet that includes the Option" title="Validation of the Packet that Includes the Option"
toc="default"> toc="default">
<t>An upper layer protocol (e.g., transport endpoint) using this <t>An upper-layer protocol (e.g., transport endpoint) using this
option needs to provide protection from data injection attacks by Option needs to provide protection from data injection attacks by
off-path devices <xref format="default" target="RFC8085" />. This off-path devices <xref format="default" target="RFC8085" />. This
requires a method to assure that the information in the Option Data 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 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 forms a part of an existing flow, using context available at the
upper layer. For example, a TCP connection or UDP application that upper layer. For example, a TCP connection or UDP application that
maintains the related state and uses a randomized ephemeral port maintains the related state and uses a randomized ephemeral port
would provide this basic validation to protect from off-path data would provide this basic validation to protect from off-path data
injection, see Section 5.1 of <xref format="default" injection; see <xref format="default" target="RFC8085" sectionFormat="
target="RFC8085" />. IPsec <xref format="default" of"
section="5.1"/>. IPsec <xref format="default"
target="RFC4301" /> and TLS <xref format="default" target="RFC4301" /> and TLS <xref format="default"
target="RFC8446" /> provide greater assurance.</t> target="RFC8446" /> provide greater assurance.</t>
<t>The upper layer discards any received packet when the packet <t>The upper layer discards any received packet when the packet
validation fails. When packet validation fails, the upper layer MUST validation fails. When packet validation fails, the upper layer <bcp14 >MUST</bcp14>
also discard the associated Option Data from the MinPMTU HBH also discard the associated Option Data from the MinPMTU HBH
option without further processing.</t> Option without further processing.</t>
</section> </section>
<!-- End of Validation -->
<section anchor="transportrec" numbered="true" <section anchor="transportrec" numbered="true"
title="Receiving the Option" toc="default"> title="Receiving the Option" toc="default">
<t>For a connection-oriented upper layer protocol, caching of the <t>For a connection-oriented upper-layer protocol, caching of the
received Min-PMTU could be implemented by saving the value in the received Min-PMTU could be implemented by saving the value in the
connection context at the transport layer. A connection-less upper connection context at the transport layer. A connectionless upper
layer (e.g., one using UDP), requires the upper layer protocol to layer (e.g., one using UDP) requires the upper-layer protocol to
cache the value for each flow it uses.</t> cache the value for each flow it uses.</t>
<t>A destination host that receives a MinPMTU HBH Option with <t>A destination host that receives a MinPMTU HBH Option with
the R-Flag SHOULD include the MinPMTU HBH option in the next the R-Flag <bcp14>SHOULD</bcp14> include the MinPMTU HBH Option in the next
outgoing IPv6 packet for the corresponding flow.</t> outgoing IPv6 packet for the corresponding flow.</t>
<t>A simple mechanism could only include this option (with the <t>A simple mechanism could only include this Option (with the
Rtn-PMTU field set) the first time this option is received or when 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 it notifies a change in the Minimum Path MTU. This limits the number
of packets including the option packets that are sent. However, this of packets, including the Option packets, that are sent. However, this
does not provide robustness to packet loss or recovery after a does not provide robustness to packet loss or recovery after a
sender loses state.</t> sender loses state.</t>
<t>Discussion:</t> <t>Discussion:</t>
<ul spacing="normal"> <ul spacing="normal">
<li> <li>
<t>Some upper layer protocols send packets less frequently than <t>Some upper-layer protocols send packets less frequently than
the rate at which the host receives packets. This provides less the rate at which the host receives packets. This provides less
frequent feedback of the received Rtn-PMTU value. However, a frequent feedback of the received Rtn-PMTU value. However, a
host always sends the most recent Rtn-PMTU value.</t> host always sends the most recent Rtn-PMTU value.</t>
</li> </li>
</ul> </ul>
</section> </section>
<!-- End of IPv6 incoming transport processing -->
<section anchor="Rtn-MTU" numbered="true" <section anchor="Rtn-MTU" numbered="true"
title="Using the Rtn-PMTU Field" toc="default"> title="Using the Rtn-PMTU Field" toc="default">
<t>The Rtn-PMTU field provides an indication of the PMTU from <t>The Rtn-PMTU field provides an indication of the PMTU from
on-path routers. It does not necessarily reflect the actual PMTU on-path routers. It does not necessarily reflect the actual PMTU
between the source and destination hosts. Care therefore needs to be between the source and destination hosts. Care therefore needs to be
exercised in using the Rtn-PMTU value. Specifically:</t> exercised in using the Rtn-PMTU value. Specifically:</t>
<ul spacing="normal"> <ul spacing="normal">
<li>The actual PMTU can be lower than the Rtn-PMTU value because <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 the Min-PMTU field was not updated by a router on the path that
did not process the option.</li> did not process the Option.</li>
<li>The actual PMTU may be lower than the Rtn-PMTU value because <li>The actual PMTU may be lower than the Rtn-PMTU value because
there is a layer-2 device with a lower MTU.</li> there is a Layer 2 device with a lower MTU.</li>
<li>The actual PMTU may be larger than the Rtn-PMTU value because <li>The actual PMTU may be larger than the Rtn-PMTU value because
of a corrupted, delayed or mis-ordered response. A source host of a corrupted, delayed, or misordered response. A source host
MUST ignore a Rtn-PMTU value larger than the MTU configured for <bcp14>MUST</bcp14> ignore a Rtn-PMTU value larger than the MTU conf
igured for
the outgoing link.</li> the outgoing link.</li>
<li>The path might have changed between the time when the probe <li>The path might have changed between the time when the probe
was sent and when the Rtn-PMTU value received.</li> was sent and when the Rtn-PMTU value received.</li>
</ul> </ul>
<t>IPv6 requires that every link in the Internet have an MTU of 1280 <t>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 octets or greater. A node <bcp14>MUST</bcp14> ignore a Rtn-PMTU value less than
1280 octets <xref format="default" target="RFC8200" />.</t> 1280 octets <xref format="default" target="RFC8200" />.</t>
<t>To avoid unintentional dropping of packets that exceed the actual <t>To avoid unintentional dropping of packets that exceed the actual
PMTU (e.g., Scenario 3 in <xref target="Intro1" />), the source host 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 can delay increasing the PMTU until a probe packet with the size of
the Rtn-PMTU value has been successfully acknowledged by the upper the Rtn-PMTU value has been successfully acknowledged by the upper
layer, confirming that the path supports the larger PMTU. This layer, confirming that the path supports the larger PMTU. This
probing increases robustness, but adds one additional path round probing increases robustness but adds one additional path round-trip
trip time before the PMTU is updated. This use resembles that of PTB time before the PMTU is updated. This use resembles that of PTB
messages in section 4.6 of DPLPMTUD <xref format="default" messages in <xref format="default" target="RFC8899"
target="RFC8899" /> (with the important difference that a PTB sectionFormat="of" section="4.6">DPLPMTUD</xref> (with the important di
message can only seek to lower the PMTU, whereas this option could fference
trigger a probe packet to seek to increase the PMTU.)</t> 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).</t>
<t>Section 5.2 of <xref format="default" target="RFC8201" /> <t><xref format="default" target="RFC8201" sectionFormat="of" section= "5.2"/>
provides guidance on the caching of PMTU information and also the provides guidance on the caching of PMTU information and also the
relation to IPv6 flow labels. Implementations should consider the relation to IPv6 flow labels. Implementations should consider the
impact of Equal Cost Multipath (ECMP) <xref format="default" impact of Equal-Cost Multipath (ECMP) <xref format="default"
target="RFC6438" />. Specifically, whether a PMTU ought to be target="RFC6438" />, specifically, whether a PMTU ought to be
maintained for each transport endpoint, or for each network maintained for each transport endpoint or for each network
address.</t> address.</t>
</section> </section>
<!-- End of Rtn-MTU -->
<section numbered="true" title="Detecting Path Changes" toc="default"> <section numbered="true" title="Detecting Path Changes" toc="default">
<t>Path characteristics can change and the actual PMTU could <t>Path characteristics can change, and the actual PMTU could
increase or decrease over time. For instance, following a path increase or decrease over time, for instance, following a path
change when packets are forwarded over a link with a different MTU change when packets are forwarded over a link with a different MTU
than that previously used. To bound the delay in discovering an 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 increase in the actual PMTU, a host with a link MTU larger than the
current PMTU SHOULD periodically send the MinPMTU HBH Option current PMTU <bcp14>SHOULD</bcp14> periodically send the MinPMTU HBH O ption
with the R-bit set. DPLPMTUD provides recommendations concerning how with the R-bit set. DPLPMTUD provides recommendations concerning how
this could be implemented (see Section 5.3 of <xref format="default" this could be implemented (see <xref format="default" target="RFC8899"
target="RFC8899" />). Since the option consumes less capacity than a sectionFormat="of" section="5.3"/>). Since the Option consumes less cap
full-sized probe packet, there can be advantage in using this to acity
than a full-sized probe packet, there can be an advantage in using this
to
detect a change in the path characteristics.</t> detect a change in the path characteristics.</t>
</section> </section>
<!-- End of Detecting Path Changes -->
<section anchor="HBHblackhole" numbered="true" <section anchor="HBHblackhole" numbered="true"
title="Detection of Dropping Packets that include the Option" title="Detection of Dropping Packets that Include the Option"
toc="default"> toc="default">
<t>There is evidence that some middleboxes drop packets that include <t>There is evidence that some middleboxes drop packets that include
Hop-by-Hop options. For example, a firewall might drop a packet that Hop-by-Hop Options. For example, a firewall might drop a packet that
carries an unknown extension header or option. This practice is carries an unknown extension header or Option. This practice is
expected to decrease as an option becomes more widely used. It could expected to decrease as an Option becomes more widely used. It could
result in generation of an ICMPv6 message indicating the problem. result in the generation of an ICMPv6 message that indicates the probl
This could be used to (temporarily) suspend use of this option.</t> em.
This could be used to (temporarily) suspend use of this Option.</t>
<t>A middlebox that silently discards a packet with this option <t>A middlebox that silently discards a packet with this Option
results in dropping of any packet using the option. This dropping results in the dropping of any packet using the Option. This dropping
can be avoided by appropriate configuration in a controlled can be avoided by appropriate configuration in a controlled
environment, such as within a data centre, but needs to be environment, such as within a data center, but it needs to be
considered for Internet usage. <xref target="host-os" /> recommends considered for Internet usage. <xref target="host-os" /> recommends
that this option is not used on packets where loss might adversely that this Option is not used on packets where loss might adversely
impact performance.</t> impact performance.</t>
</section> </section>
<!-- End of HBH Drop -->
</section> </section>
<!-- End of Transport Main subSection -->
</section> </section>
<!-- End of Router,Host, Transport Section-->
<section anchor="IANA" numbered="true" title="IANA Considerations" <section anchor="IANA" numbered="true" title="IANA Considerations"
toc="default"> toc="default">
<t>IANA has assigned and registered an IPv6 Hop-by-Hop Option type with <t>IANA has registered an IPv6 Hop-by-Hop Option type
Temporary status from the "Destination Options and Hop-by-Hop Options" in the "Destination Options and Hop-by-Hop Options"
registry <xref format="default" target="IANA-HBH" />. This assignment is registry within the "Internet Protocol Version 6 (IPv6) Parameters" regist
ry group <xref format="default" target="IANA-HBH"/>. This assignment is
shown in <xref format="default" target="HBH" />.</t> 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> </section>
<!-- End of IANA Main Section-->
<section anchor="Security" numbered="true" title="Security Considerations" <section anchor="Security" numbered="true" title="Security Considerations"
toc="default"> toc="default">
<t>This section discusses the security considerations. It first reviews <t>This section discusses the security considerations. It first reviews
router option processing. It then reviews host processing when receiving router Option processing. It then reviews host processing when receiving
this option at the network layer. It then considers two ways in which 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 can be processed, followed by two approaches for using
the Option Data. Finally, it discusses middlebox implications related to the Option Data. Finally, it discusses middlebox implications related to
use in the general Internet.</t> use in the general Internet.</t>
<section anchor="Security-router" numbered="true" <section anchor="Security-router" numbered="true"
title="Router Option Processing" toc="default"> title="Router Option Processing" toc="default">
<t>This option shares the characteristics of all other IPv6 Hop-by-Hop <t>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 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 degrade the performance of a router. This Option, while simple, is no
different to other uses of IPv6 Hop-by-Hop options.</t> different than other uses of IPv6 Hop-by-Hop Options.</t>
<t>It is common for routers to ignore the Hop-by-Hop Option header or <t>It is common for routers to ignore the Hop-by-Hop Option header or
drop packets containing a Hop-by-Hop Option header. Routers to drop packets containing a Hop-by-Hop Option header. Routers
implementing IPv6 according to <xref format="default" implementing IPv6 according to <xref format="default"
target="RFC8200" /> only examine and process the Hop-by-Hop Options target="RFC8200" /> only examine and process the Hop-by-Hop Options
header if explicitly configured to do so.</t> header if explicitly configured to do so.</t>
</section> </section>
<section anchor="Security-net" numbered="true" <section anchor="Security-net" numbered="true"
title="Network Layer Host Processing" toc="default"> title="Network-Layer Host Processing" toc="default">
<t>A malicious attacker can forge a packet directed at a host that <t>A malicious attacker can forge a packet directed at a host that
carries the MinPMTU HBH option. By design, the fields of this IP carries the MinPMTU HBH Option. By design, the fields of this IP
option can be modified by the network.</t> Option can be modified by the network.</t>
<t>For comparison, the ICMPv6 Packet Too Big message used in <xref <t>For comparison, the ICMPv6 PTB message used in Path MTU Discovery <xr
format="default" target="RFC8201" /> Path MTU Discovery, the source ef
host has an inherent trust relationship with the destination host format="default" target="RFC8201"/> and the source
including this option. This trust relationship can be used to help host have an inherent trust relationship with the destination host
verify the option. ICMPv6 Packet Too Big messages are sent from any including this Option. This trust relationship can be used to help
router on the path to the destination host, the source host has no 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 prior knowledge of these routers (except for the first hop
router).</t> router).</t>
<t>Reception of this packet will require processing as the network <t>Reception of this packet will require processing as the network
stack parses the packet before the packet is delivered to the upper stack parses the packet before the packet is delivered to the
layer protocol. This network layer option processing is normally upper-layer protocol. This network-layer Option processing is normally
completed before any upper layer protocol delivery checks are completed before any upper-layer protocol delivery checks are
performed.</t> performed.</t>
<t>The network layer does not normally have sufficient information to <t>The network layer does not normally have sufficient information to
validate that the packet carrying an option originated from the validate that the packet carrying an Option originated from the
destination (or an on-path node). It also does not typically have destination (or an on-path node). It also does not typically have
sufficient context to demultiplex the packet to identify the related sufficient context to demultiplex the packet to identify the related
transport flow. This can mean that any changes resulting from transport flow. This can mean that any changes resulting from
reception of the option applies to all flows between a pair of reception of the Option applies to all flows between a pair of
endpoints.</t> endpoints.</t>
<t>These considerations are no different to other uses of Hop-by-Hop <t>These considerations are no different than other uses of Hop-by-Hop
options, and this is the use case for PMTUD. The following section Options, and this is the use case for PMTUD. The following section
describes a mitigation for this attack.</t> describes a mitigation for this attack.</t>
</section> </section>
<section anchor="Security-upp" numbered="true" <section anchor="Security-upp" numbered="true"
title="Validating use of the Option Data" toc="default"> title="Validating Use of the Option Data" toc="default">
<t>Transport protocols should be designed to provide protection from <t>Transport protocols should be designed to provide protection from
data injection attacks by off-path devices and mechanisms should be data injection attacks by off-path devices, and mechanisms should be
described in the Security Considerations for each transport described in the Security Considerations section for each transport
specification (see Section 5.1 of the UDP Guidelines <xref specification (see <xref target="RFC8085" sectionFormat="of"
format="default" target="RFC8085" />). For example, a TCP or UDP section="5.1">"UDP Usage Guidelines"</xref>). For example, a TCP or UDP
application that maintains the related state and uses a randomized application that maintains the related state and uses a randomized
ephemeral port would provide basic protection. TLS <xref ephemeral port would provide basic protection. TLS <xref
format="default" target="RFC8446" /> or IPsec <xref format="default" format="default" target="RFC8446" /> or IPsec <xref format="default"
target="RFC4301" /> provide cryptographic authentication. An upper target="RFC4301" /> provide cryptographic authentication. An upper-layer
layer protocol that validates each received packet discards any packet protocol that validates each received packet discards any packet
when this validation fails. In this case, the host MUST also discard when this validation fails. In this case, the host <bcp14>MUST</bcp14> a
the associated Option Data from the MinPMTU HBH option without lso discard
the associated Option Data from the MinPMTU HBH Option without
further processing (<xref target="Transport" />).</t> further processing (<xref target="Transport" />).</t>
<t>A network node on the path has visibility of all packets it <t>A network node on the path has visibility of all packets it
forwards. By observing the network packet payload, the node might be forwards. By observing the network packet payload, the node might be
able to construct a packet that might be validated by the destination 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 host. Such a node would also be able to drop or limit the flow in
other ways that could be potentially more disruptive. Authenticating other ways that could be potentially more disruptive. Authenticating
the packet, for example, using IPsec <xref format="default" the packet, for example, using IPsec <xref format="default"
target="RFC4301" /> or TLS <xref format="default" target="RFC8446" /> target="RFC4301" /> or TLS <xref format="default" target="RFC8446" />
mitigates this attack. Note that AH style authentication <xref mitigates this attack. Note that the authentication style of the Authent
format="default" target="RFC4302" /> while authenticating the payload ication
and outer IPv6 header, does not check Hop-by-Hop options that change Header (AH)
<xref format="default" target="RFC4302" />, while authenticating the payl
oad
and outer IPv6 header, does not check Hop-by-Hop Options that change
on route.</t> on route.</t>
</section> </section>
<section anchor="Security-pmtud" numbered="true" <section anchor="Security-pmtud" numbered="true"
title="Direct use of the Rtn-PMTU Value" toc="default"> title="Direct Use of the Rtn-PMTU Value" toc="default">
<t>The simplest way to utilize the Rtn-PMTU value is to directly use <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 this to update the PMTU. This approach results in a set of security
issues when the option carries malicious data:</t> issues when the Option carries malicious data:</t>
<ul> <ul>
<li> <li>
<t>A direct update of the PMTU using the Rtn-PMTU value could <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 result in an attacker inflating or reducing the size of the host
PMTU for the destination. Forcing a reduction in the PMTU can PMTU for the destination. Forcing a reduction in the PMTU can
decrease the efficiency of network use, might increase the number decrease the efficiency of network use, might increase the number
of packets/fragments required to send the same volume of payload of packets/fragments required to send the same volume of payload
data, and prevents sending an unfragmented datagram larger than data, and can prevent sending an unfragmented datagram larger than
the PMTU. Increasing the PMTU can result in black-holing (see the PMTU. Increasing the PMTU can result in a path silently dropping
Section 1.1 of <xref format="default" target="RFC8899" />) when packets
(described as a black hole in <xref format="default" target="RFC8899
"/>) when
the source host sends packets larger than the actual PMTU. This the source host sends packets larger than the actual PMTU. This
persists until the PMTU is next updated.</t> persists until the PMTU is next updated.</t>
</li> </li>
<li> <li>
<t>The method can be used to solicit a response from the <t>The method can be used to solicit a response from the
destination host. A malicious attacker could forge a packet that destination host. A malicious attacker could forge a packet that
causes the destination to add the option to a packet sent to the 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 source host. A forged value of Rtn-PMTU in the Option Data might
also impact the remote endpoint, as described in the previous also impact the remote endpoint, as described in the previous
bullet. This persists until a valid MinPMTU HBH option is bullet. This persists until a valid MinPMTU HBH Option is
received. This attack could be mitigated by limiting the sending received. This attack could be mitigated by limiting the sending
of the MinPMTU HBH option in reply to incoming packets that of the MinPMTU HBH Option in reply to incoming packets that
carry the option.</t> carry the Option.</t>
</li> </li>
</ul> </ul>
</section> </section>
<!-- End of security PMTUD subsection -->
<section anchor="Security-dplpmtud" numbered="true" <section anchor="Security-dplpmtud" numbered="true"
title="Using the Rtn-PMTU Value as a Hint for Probing" title="Using the Rtn-PMTU Value as a Hint for Probing"
toc="default"> toc="default">
<t>Another way to utilize the Rtn-PMTU value is to indirectly trigger <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. 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 This approach needs context for the flow and hence assumes an upper-laye
layer protocol that validates the packet that carries the option (see r
protocol that validates the packet that carries the Option (see
<xref target="Security-upp" />). This is the case when used in <xref target="Security-upp" />). This is the case when used in
combination with DPLPMTUD <xref format="default" target="RFC8899" />. combination with DPLPMTUD <xref format="default" target="RFC8899" />.
A set of security considerations result when an option carries A set of security considerations result when an Option carries
malicious data:</t> malicious data:</t>
<ul> <ul>
<li>If the forged packet carries a validated option with a non-zero <li>If the forged packet carries a validated Option with a non-zero
Rtn-PMTU field, the upper layer protocol could utilize the Rtn-PMTU field, the upper-layer protocol could utilize the
information in the Rtn-PMTU field. A Rtn-PMTU larger than the information in the Rtn-PMTU field. A Rtn-PMTU larger than the
current PMTU can trigger a probe for a new size.</li> current PMTU can trigger a probe for a new size.</li>
<li>If the forged packet carries a non-zero Min-PMTU field, the <li>If the forged packet carries a non-zero Min-PMTU field, the
upper layer protocol would change the cached information about the upper-layer protocol would change the cached information about the
path from the source. The cached information at the destination host path from the source. The cached information at the destination host
will be overwritten when the host receives another packet that will be overwritten when the host receives another packet that
includes a MinPMTU HBH option corresponding to the flow.</li> includes a MinPMTU HBH Option corresponding to the flow.</li>
<li>Processing of the option could cause a destination host to add <li>Processing of the Option could cause a destination host to add
the MinPMTU HBH option to a packet sent to the source host. 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 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 by the forged packet. The impact of the source host receiving this
resembles that discussed previously.</li> resembles that discussed previously.</li>
</ul> </ul>
</section> </section>
<!-- End of security subsection -->
<section anchor="Security-mbox" numbered="true" <section anchor="Security-mbox" numbered="true"
title="Impact of Middleboxes" toc="default"> title="Impact of Middleboxes" toc="default">
<t>There is evidence that some middleboxes drop packets that include <t>There is evidence that some middleboxes drop packets that include
Hop-by-Hop options. For example, a firewall might drop a packet that Hop-by-Hop Options. For example, a firewall might drop a packet that
carries an unknown extension header or option. This practice is carries an unknown extension header or Option. This practice is
expected to decrease as the option becomes more widely used. Methods expected to decrease as the Option becomes more widely used. Methods
to address this are discussed in <xref target="HBHblackhole" />.</t> to address this are discussed in <xref target="HBHblackhole" />.</t>
<t>When a forged packet causes a packet to be sent including the <t>When a forged packet causes a packet that includes the MinPMTU HBH
MinPMTU HBH option, and the return path does not forward packets Option to be sent and the return path does not forward packets with
with this option, the packet will be dropped <xref this Option, the packet will be dropped (see <xref
target="HBHblackhole" />. This attack is mitigated by validating the target="HBHblackhole"/>). This attack is mitigated by validating the
option data before use and by limiting the rate of responses Option Data before use and by limiting the rate of responses
generated. An upper layer could further mitigate the impact by generated. An upper layer could further mitigate the impact by
responding to an R-Flag by including the option in a packet that does responding to an R-Flag by including the Option in a packet that does
not carry application data.</t> not carry application data.</t>
</section> </section>
<!-- End of security mbox subsection -->
</section> </section>
<!-- End of Security Consideraions main section-->
<section anchor="EXP" numbered="true" title="Experiment Goals" <section anchor="EXP" numbered="true" title="Experiment Goals"
toc="default"> toc="default">
<t>This section describes the experimental goals of this <t>This section describes the experimental goals of this
specification.</t> specification.</t>
<t>A successful deployment of the method depends upon several components <t>A successful deployment of the method depends upon several components
being implemented and deployed:</t> being implemented and deployed:</t>
<ul spacing="normal"> <ul spacing="normal">
<li>Support in the sending node (see <xref format="default" <li>Support in the sending node (see <xref format="default"
target="host-os" />). This also requires corresponding support in target="host-os" />). This also requires corresponding support in
upper layer protocols (see <xref format="default" upper-layer protocols (see <xref format="default"
target="Transport" />).</li> target="Transport" />).</li>
<li>Router support in nodes (see <xref format="default" <li>Router support in nodes (see <xref format="default"
target="router" />). The IETF continues to provide recommendations on target="router" />). The IETF continues to provide recommendations on
the use of IPv6 Hop-by-Hop options, for example <xref format="default" the use of IPv6 Hop-by-Hop Options, for example, see <xref format="defau lt"
section="2.2.2" target="RFC9099" />. This document does not update the section="2.2.2" target="RFC9099" />. This document does not update the
way router implementations configure support for Hop-by-Hop options.</li > way router implementations configure support for Hop-by-Hop Options.</li >
<li>Support in the receiving node (see <xref format="default" <li>Support in the receiving node (see <xref format="default"
target="transportrec" />).</li> target="transportrec" />).</li>
</ul> </ul>
<t>Experience from deployment is an expected input to any decision to <t>Experience from deployment is an expected input to any decision to
progress this specification from Experimental to IETF Standards Track. progress this specification from Experimental to IETF Standards Track.
Appropriate inputs might include:</t> Appropriate inputs might include:</t>
<ul spacing="normal"> <ul spacing="normal">
<li>Reports of implementation experience;</li> <li>reports of implementation experience,</li>
<li>measurements of the number paths where the method can be
<li>Measurements of the number paths where the method can be used, or</li>
used;</li> <li>measurements showing the benefit realized or the implications of
<li>Measurements showing the benefit realized or the implications of
using specific methods over specific paths.</li> using specific methods over specific paths.</li>
</ul> </ul>
</section> </section>
<!-- End of Experiment Status section-->
<section anchor="IMP" numbered="true" title="Implementation Status" <section anchor="IMP" numbered="true" title="Implementation Status"
toc="default"> toc="default">
<t>At the time this document was published there are two known <t>At the time this document was published, there are two known
implementations of the Path MTU Hop-by-Hop option. These are:</t> implementations of the Path MTU Hop-by-Hop Option. These are:</t>
<ul spacing="normal"> <ul spacing="normal">
<li>Wireshark dissector. This is shipping in production in Wireshark <li>Wireshark dissector. This is shipping in production in Wireshark
version 3.2 <xref format="default" target="WIRESHARK" />.</li> version 3.2 <xref format="default" target="WIRESHARK" />.</li>
<li>A prototype in the open source version of the FD.io Vector Packet <li>A prototype in the open source version of the FD.io Vector Packet
Processing (VPP) technology <xref format="default" target="VPP" />. At Processing (VPP) technology <xref format="default" target="VPP" />. At
the time this document was published, the source code can be found the time this document was published, the source code can be found
<xref format="default" target="VPP_SRC" />.</li> <xref format="default" target="VPP_SRC" />.</li>
</ul> </ul>
</section> </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="appen
dix" />.</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> </middle>
<back> <back>
<displayreference target="I-D.ietf-taps-arch" to="TAPS-ARCH"/>
<references> <references>
<name>References</name> <name>References</name>
<references> <references>
<name>Normative References</name> <name>Normative References</name>
<xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/refer
ence.RFC.8200.xml"/>
<xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/refer
ence.RFC.8201.xml"/>
<xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/refer
ence.RFC.2119.xml"/>
<xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/refer
ence.RFC.8174.xml"/>
<xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/refer <reference anchor="IANA-HBH" target="https://www.iana.org/assignments/ip
ence.RFC.8200.xml" v6-parameters/">
xmlns:xi="http://www.w3.org/2001/XInclude" />
<xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/refer
ence.RFC.8201.xml"
xmlns:xi="http://www.w3.org/2001/XInclude" />
<xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/refer
ence.RFC.2119.xml"
xmlns:xi="http://www.w3.org/2001/XInclude" />
<xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/refer
ence.RFC.8174.xml"
xmlns:xi="http://www.w3.org/2001/XInclude" />
<reference anchor="IANA-HBH"
target="https://www.iana.org/assignments/ipv6-parameters/ipv6
-parameters.xhtml#ipv6-parameters-2">
<front> <front>
<title>Destination Options and Hop-by-Hop Options</title> <title>Destination Options and Hop-by-Hop Options</title>
<author>
<author /> <organization>IANA</organization>
</author>
<date />
</front> </front>
</reference> </reference>
</references> </references>
<references> <references>
<name>Informative References</name> <name>Informative References</name>
<xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/refer
ence.RFC.1063.xml"/>
<xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/refer
ence.RFC.1191.xml"/>
<xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/refer
ence.RFC.2460.xml"/>
<xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/refer
ence.RFC.4301.xml"/>
<xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/refer
ence.RFC.4302.xml"/>
<xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/refer
ence.RFC.4443.xml"/>
<xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/refer
ence.RFC.4861.xml"/>
<xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/refer
ence.RFC.4821.xml"/>
<xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/refer
ence.RFC.6438.xml"/>
<xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/refer
ence.RFC.7637.xml"/>
<xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/refer
ence.RFC.8085.xml"/>
<xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/refer
ence.RFC.8446.xml"/>
<xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/refer
ence.RFC.8899.xml"/>
<xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/refer
ence.RFC.8900.xml"/>
<xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/refer
ence.RFC.9000.xml"/>
<xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/refer
ence.RFC.9099.xml"/>
<xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/refer <reference anchor="I-D.ietf-taps-arch" target="https://datatracker.ietf.
ence.RFC.1063.xml" org/doc/bibxml3/draft-ietf-taps-arch.xml">
xmlns:xi="http://www.w3.org/2001/XInclude" /> <front>
<title>An Architecture for Transport Services</title>
<xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/refer <author initials='T' surname='Pauly' fullname='Tommy Pauly' role='ed
ence.RFC.1191.xml" itor'>
xmlns:xi="http://www.w3.org/2001/XInclude" /> <organization/>
</author>
<xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/refer <author initials='B' surname='Trammell' fullname='Brian Trammell' ro
ence.RFC.2460.xml" le='editor'>
xmlns:xi="http://www.w3.org/2001/XInclude" /> <organization/>
</author>
<xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/refer <author initials='A' surname='Brunstrom' fullname='Anna Brunstrom'>
ence.RFC.4301.xml" <organization/>
xmlns:xi="http://www.w3.org/2001/XInclude" /> </author>
<author initials='G' surname='Fairhurst' fullname='Godred Fairhurst'
<xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/refer >
ence.RFC.4302.xml" <organization/>
xmlns:xi="http://www.w3.org/2001/XInclude" /> </author>
<author initials='C' surname='Perkins' fullname='Colin Perkins'>
<xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/refer <organization/>
ence.RFC.4443.xml" </author>
xmlns:xi="http://www.w3.org/2001/XInclude" /> <date month='June' year='2022'/>
</front>
<xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/refer <seriesInfo name="Internet-Draft" value="draft-ietf-taps-arch-12"/>
ence.RFC.4861.xml" </reference>
xmlns:xi="http://www.w3.org/2001/XInclude" />
<xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/refer
ence.RFC.4821.xml"
xmlns:xi="http://www.w3.org/2001/XInclude" />
<xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/refer
ence.RFC.6438.xml"
xmlns:xi="http://www.w3.org/2001/XInclude" />
<xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/refer
ence.RFC.7637.xml"
xmlns:xi="http://www.w3.org/2001/XInclude" />
<xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/refer
ence.RFC.8085.xml"
xmlns:xi="http://www.w3.org/2001/XInclude" />
<xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/refer
ence.RFC.8446.xml"
xmlns:xi="http://www.w3.org/2001/XInclude" />
<xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/refer
ence.RFC.8899.xml"
xmlns:xi="http://www.w3.org/2001/XInclude" />
<xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/refer
ence.RFC.8900.xml"
xmlns:xi="http://www.w3.org/2001/XInclude" />
<xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/refer
ence.RFC.9000.xml"
xmlns:xi="http://www.w3.org/2001/XInclude" />
<xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/refer
ence.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" />
<reference anchor="VPP" <reference anchor="VPP"
target="https://wiki.fd.io/view/VPP/What_is_VPP%3F"> target="https://wiki.fd.io/view/VPP/What_is_VPP%3F">
<front> <front>
<title>VPP/What is VPP?</title> <title>VPP/What is VPP?</title>
<author>
<author /> <organization>FD.io</organization>
</author>
<date />
</front> </front>
</reference> </reference>
<reference anchor="VPP_SRC" <reference anchor="VPP_SRC"
target="https://gerrit.fd.io/r/c/vpp/+/21948"> target="https://gerrit.fd.io/r/c/vpp/+/21948">
<front> <front>
<title>VPP Source</title> <title>vpp</title>
<author/>
<author />
<date /> <date />
</front> </front>
<refcontent>commit 21948, ip: HBH MTU recording for IPv6</refcontent>
</reference> </reference>
<reference anchor="WIRESHARK" target="https://www.wireshark.org"> <reference anchor="WIRESHARK" target="https://www.wireshark.org">
<front> <front>
<title>Wireshark Network Protocol Analyzer</title> <title>Wireshark Network Protocol Analyzer</title>
<author /> <author />
<date /> <date />
</front> </front>
</reference> </reference>
</references> </references>
</references> </references>
<!--Appendix on Useage
-->
<section anchor="appendix" numbered="true" toc="default"> <section anchor="appendix" numbered="true" toc="default">
<name>Examples of Usage</name> <name>Examples of Usage</name>
<t>This section provides examples that illustrate a use of the MinPMTU <t>This section provides examples that illustrate a use of the MinPMTU
HBH option by a source using DPLPMTUD to discover the PLPMTU supported 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 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 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 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 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 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> 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 HBH <t>The first example considers DPLPMTUD without using the MinPMTU HBH
option. In this case, DPLPMTUD searches using an increasing size of Option. In this case, DPLPMTUD searches using a probe packet that increase
probe packet. Probe packets of size (e) are sent, which are larger than s 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 the actual PMTU. In this example, PTB messages are not received from the
routers and repeated unsuccessful probes result in the search phase routers, and repeated unsuccessful probes result in the search phase
completing. Packets of data are never sent with a size larger than the completing. Packets of data are never sent with a size larger than the
size of the last confirmed probe packet. ACKs of data packets are not size of the last confirmed probe packet. Acknowledgments (ACKs) of data pa
shown.</t> ckets
are not shown.</t>
<figure> <figure>
<artwork align="center" alt="" <artwork align="center" alt=""
name="DPLPMTUD without the MinPMTU HBH option" type=""><![CDATA name="DPLPMTUD without the MinPMTU HBH Option" type=""><![CDATA
[ [
----Packets of data size a ------------------------------>
----Probe size b ---------------------------------------->
<---------------------------------- ACK of probe -------- <---------------------------------- ACK of probe --------
----Packets of data size b ------------------------------>
----Probe size c ---------------------------------------->
<---------------------------------- ACK of probe -------- <---------------------------------- ACK of probe --------
----Packets of data size c ------------------------------>
----Probe size d ---------------------------------------->
<---------------------------------- ACK of probe -------- <---------------------------------- ACK of probe --------
----Packets of data size d ------------------------------>
<---------------------------------- ACK of probe -------- <---------------------------------- ACK of probe --------
... ...
X----ICMPv6 PTB (d') --| ----Probe size e --------------X
X----ICMPv6 PTB (d') --| 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. etc. until MaxProbes are unsuccessful and search phase completes.
----Packets of data size d ------------------------------>
]]></artwork> ]]></artwork>
</figure> </figure>
<t>The second example considers DPLPMTUD with the MinPMTU HBH option set <t>The second example considers DPLPMTUD with the MinPMTU HBH Option set
on a connectivity probe packet.</t> on a connectivity probe packet.</t>
<t>The IPv6 option is sent end-to-end, and the Min-PMTU is updated by a <t>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 router on the path to d', which is returned in a response that also sets
the MinPMTU HBH option. Upon receiving Rtn-PMTU value is received, the MinPMTU HBH Option. Upon receiving the Rtn-PMTU value,
DPLPMTUD immediately sends a probe packet of the target size (d'). If DPLPMTUD immediately sends a probe packet of the target size d'. If
the probe packet is confirmed for the path, the PLPMTU is updated, 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 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 algorithm is allowed to continue to probe to see if the path supports a
larger size.) larger size.)
Packets of data are never sent with a size larger than the last Packets of data are never sent with a size larger than the last
confirmed probe size, d'. confirmed probe 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> </t>
<figure> <figure>
<artwork align="center" alt="" <artwork align="center" alt=""
name="DPLPMTUD with the MinPMTU HBH Option" type=""><![CDATA[ name="DPLPMTUD with the MinPMTU HBH Option" type=""><![CDATA[
----Packets of data size a ------------------------------>
----Connectivity probe with MinPMTU- ----Connectivity probe with MinPMTU-
+--updated to minPMTU=d'-----> +--updated to minPMTU=d'----->
<-----------------ACK with Rtn-PMTU=d'-------------------- <-----------------ACK with Rtn-PMTU=d'--------------------
----Packets of data size a ------------------------------>
----Probe size d' --------------------------------------->
<---------------------------------- ACK of probe --------- <---------------------------------- ACK of probe ---------
-----Packets of data size d' ---------------------------->
Search phase completes. Search phase completes.
-----Packets of data size d' ---------------------------->
]]></artwork> ]]></artwork>
</figure> </figure>
<t>The final example considers DPLPMTUD with the MinPMTU HBH option set <t>The final example considers DPLPMTUD with the MinPMTU HBH Option set
on a connectivity probe packet, but shows the effect when this on a connectivity probe packet but shows the effect when this
connectivity probe packet is dropped.</t> connectivity probe packet is dropped.</t>
<t>In this case, the packet with the MinPMTU HBH option is not received. <t>In this case, the packet with the MinPMTU HBH Option is not received.
DPLPMTUD searches using probe packets of increasing size, increasing the DPLPMTUD searches using probe packets of increasing size, increasing the
PLPMTU when the probes are confirmed. An ICMPv6 PTB message is received 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 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'. DPLPMTUD immediately sends a probe packet of the target size d'.
If the probe packet is confirmed for the path, the PLPMTU is updated, 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 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 message is not received, the DPLPMTU will be the last confirmed probe
size, d.</t> size, which is d.</t>
<figure> <figure>
<artwork align="center" alt="" name="" <artwork align="center" alt="" name=""
type="DPLPMTUD with dropped MinPMTU HBH option"><![CDATA[ type="DPLPMTUD with Dropped MinPMTU HBH Option"><![CDATA[
----Packets of data size a ------------------------------->
----Connectivity probe with MinPMTU --------X ----Connectivity probe with MinPMTU --------X
----Packets of data size a ------------------------------->
----Probe size b ----------------------------------------->
<---------------------------------- ACK of probe -------- <---------------------------------- ACK of probe --------
----Packets of data size b ------------------------------->
----Probe size c ----------------------------------------->
<---------------------------------- ACK of probe -------- <---------------------------------- ACK of probe --------
----Packets of data size c ------------------------------->
----Probe size d ----------------------------------------->
<---------------------------------- ACK of probe -------- <---------------------------------- ACK of probe --------
<--ICMPv6 PTB PTB_SIZE(d') -| ----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 -------- <---------------------------------- ACK of probe --------
Search phase completes. Search phase completes.
----Packets of data size d' ------------------------------>
]]></artwork> ]]></artwork>
</figure> </figure>
<t>The number of probe rounds depends on the number of steps needed by <t>The number of probe rounds depends on the number of steps needed by
the search algorithm, and is typically larger for a larger PMTU.</t> the search algorithm and is typically larger for a larger PMTU.</t>
</section> </section>
<!-- <section anchor="exp" numbered="true" toc="default"> <section anchor="Ack" numbered="false" title="Acknowledgments"
<name>Planned Experiments</name> toc="default">
<t>TBD </t> <t>Helpful comments were received from <contact fullname="Tom Herbert"/>,
<t>This section will describe a set of experiments planned for the use <contact fullname="Tom Jones"/>, <contact fullname="Fred
of the option defined in this document. There are many aspects of the Templin"/>, <contact fullname="Ole Troan"/>, <contact fullname="Tianran Zh
design that require experimental data or experience to evaluate this ou"/>,
experimental specification.</t> <contact fullname="Jen Linkova"/>, <contact fullname="Brian Carpenter"/>,
<t>This includes experiments to understand the pathology of packets sent <contact fullname="Peng Shuping"/>, <contact fullname="Mark Smith"/>,
with the specified option to determine the likelihood that they are lost <contact fullname="Fernando Gont"/>, <contact fullname="Michael Dougherty"
within specific types of network segment.</t> />,
<t>This includes consideration of the cost and alternatives for <contact fullname="Erik Kline"/>, and
providing the feedback required by the mechanism and how to effectively other members of the 6MAN Working Group.</t>
limit the rate of transmission.</t>
<t>This includes consideration of the potential 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</x
ref>.</t>
</section> </section>
-->
</back> </back>
</rfc> </rfc>
 End of changes. 239 change blocks. 
897 lines changed or deleted 553 lines changed or added

This html diff was produced by rfcdiff 1.48.