RFC8899-数据报分组层路径MTU发现DPLPMTUD

摘要

       本文规定了数据报分组层路径MTU发现（DPLPMTUD，Datagram Packetization Layer Path MTU Discovery）。这是一种用于数据报分组层（PL）的路径MTU发现（PMTUD，Path MTU Discovery）的强大方法。PL或使用PL的数据报应用可以使用DPLPMTUD发现网络路径是否能支持当前数据报的大小。当发送方遇到报文黑洞时，这可以用来检测和减少消息大小。它还可以探测网络路径以发现是否可以增加最大报文大小。这为数据报传输提供了功能，相当于RFC 4821中规定的TCP的PLPMTUD规范，但更新了该规范。它还更新了UDP使用指南，以参考该方法用于UDP数据报，并更新了SCTP。

       该文提供了将数据报PMTUD纳入IETF数据报传输或使用数据报传输的应用程序的实施说明。

      本规范更新了RFC 4960、RFC 4821、RFC 6951、RFC 8085和RFC 8261。

1. 介绍

        IETF规定了使用UDP、SCTP和数据报拥塞控制协议（DCCP）的数据报传输，以及在这些传输之上的协议（如SCTP/UDP、DCCP/UDP、QUIC/UDP）和IP网络层上的直接数据报传输。本文描述了一种强大的路径MTU发现（PMTUD）方法，可以与这些传输协议（或使用其传输服务的应用程序）一起使用，以发现在互联网路径上使用的适当大小的数据包。

1.1 经典路径MTU发现

        经典的路径MTU发现（PMTUD）可以与任何能够处理ICMP数据包过大（PTB，ICMP Packet Too Big）消息（例如[RFC1191]和[RFC8201]）的传输一起使用。在本文中，术语PTB消息适用于携带错误Fragmentation Needed（类型3，码点4）[RFC0792]的IPv4 ICMP Unreachable消息（类型3）和ICMPv6 Packet Too Big消息（类型2）[RFC4443]。当发送方收到PTB消息时，它将有效MTU减少到PTB消息中报告的MTU值。经典的PMTUD规定了一种定期增加数据包大小的方法，试图发现支持的PMTU的增加。以大于当前有效PMTU的大小发送的数据包被称为探测数据包。

       不打算作为探测包的数据包要么被分割到当前有效的PMTU，要么发送尝试失败，并出现错误码。可以为应用程序提供一个接口，让它们读取最大数据包大小（MPS），该大小是由当前有效PMTU得出的。

       经典的PMTUD受到协议失败的影响。当使用大于实际PMTU的数据包大小的流量被黑洞（所有大于实际PMTU的数据报被丢弃）时，就会出现故障。当PTB消息由于某种原因没有发回给发送方时，就会出现这种情况（例如，见[RFC2923]）。

PTB消息未被送达的例子包括如下：

1. ICMP消息的生成通常有速率限制。这可能导致没有PTB消息没有生成并发给发送方（见[RFC4443]2.4）。
2. ICMP消息可以被中间件过滤，包括防火墙[RFC4890]。防火墙可以配置一个策略来阻止传入的ICMP消息，这将阻止该防火墙后面的发送端点接收PTB消息。
3. 当发出ICMP消息的路由器丢弃一个隧道数据包时，产生的ICMP消息被引向隧道入口。这个隧道端点负责转发ICMP报文，处理有效载荷字段内的引用包，以消除隧道的影响，并返回一个正确格式的ICMP报文给发送者[TUNNELS]。如果不这样做，PTB消息就无法到达原始发送者。
4. 转发中的不对称会导致没有返回原发送者的路由，这将阻止ICMP消息被传递到发送方那里。当使用基于策略或等成本多路径（ECMP，Equal-Cost Multipath）路由时，或者当中间件作为应用负载平衡器时，也会出现这个问题。其中的一个例子是ECMP路由器根据IP有效载荷中的字节来选择通往服务器的路径。在这种情况下，如果服务器发送的数据包在ECMP路由器之后遇到问题，那么ECMP路由器需要将任何产生的ICMP消息指向原始发送者。
5. 还有一些情况，下一跳的目的地由于数据包的大小而无法接收。这可能是由于节点之间第二层路径的错误配置，例如第二层交换机中配置的MTU，或最大接收单元（MRU）的错误配置。如果一个数据包被链路丢弃，这将会导致PTB消息无法发送到原始发送者那里。

        如果一个不在网络路径上的节点发送PTB消息，试图迫使发送方改变有效的PMTU[RFC8201]，则可能导致另一个失败。发送方可以通过利用PTB消息有效载荷中的引用包来验证收到的PTB消息是为响应实际来自发送方的数据包而产生的，从而保护自己不对此类消息作出反应。然而，在有些情况下，发送方将无法提供这种验证。不可能验证PTB消息的例子包括以下情况：

• 当发出ICMP消息的路由器执行RFC792[RFC0792]时，它只需要在引用的有效载荷中包括数据包的IP有效载荷的前64位。剩余的字节数可能不足以让发送者解释所引用的传输信息。

注意：RFC 1812 [RFC1812]中的建议是，IPv4路由器在返回引用数据包时，应尽可能多地包含原始数据报的内容，且ICMP数据报的长度不超过576字节。IPv6路由器包括尽可能多的引用数据包，而ICMPv6数据包的长度不超过1280字节[RFC4443]。

• 使用隧道和/或加密可以减少返回到原始源地址的引用包的大小，增加了风险，即可能没有足够的字节剩余给发送者来解释引用的传输信息。
• 即使PTB消息包括足够的引用包字节，网络层也可能缺乏足够的上下文来验证该消息，因为验证取决于端点节点的活动传输流量信息（例如，正在使用的套接字/地址对和其他协议头信息）。
• 当数据包通过加密传输进行封装/隧道时，隧道/封装入口可能没有足够的上下文或计算能力来重建执行验证所需的传输头。
• 当ICMP消息是由网段中的路由器产生的，该路由器在数据包中插入了一个头，被引用的数据包可能包含了额外的协议头信息，这些信息没有包括在原始发送的数据包中，而且PL发送者没有处理或可能不知道如何处理。这可能会破坏发送方验证该PTB信息的能力。
• 翻译数据包头的网络地址转换（NAT）设备应该也翻译ICMP消息，并更新该消息中的ICMP引用包[RFC5508]。如果这没有被正确翻译，那么发送者将无法将该消息与发起该数据包的PL联系起来，因此该ICMP消息无法被验证。

1.2. 分组层路径MTU发现（Packetization Layer Path MTU Discovery）

        术语分组层（PL，Packetization Layer）被引入，来描述负责将数据块放入IP数据包的有效载荷并选择适当的MPS的那一层。这一功能通常由传输协议执行（如DCCP、RTP、SCTP、QUIC），但也可以由工作在传输层之上的其他封装方法执行。

       与PMTUD相比，分组层路径MTU发现（PLPMTUD）[RFC4821]引入了一种不依赖PTB消息的接收和验证的方法。因此，它比经典的PMTUD更强大。这已经成为实现发现PMTU的推荐方法[BCP145]。

       本文更新了[RFC4821]，为数据报PL指定了PLPMTUD方法，还更新了[BCP145]，以引用本文指定的用于UDP数据报的方法，而不是[RFC4821]的方法。

       它使用一个一般的策略，其中PL发送探测报文来搜索可以在网络路径上发送的最大尺寸的不分片的数据报。发送探测报文是为了探索使用更大的报文大小。如果一个探测报文成功传递（由PL决定），那么PLPMTU就被提高到成功探测的大小。如果检测到黑洞（例如，尺寸为PLPMTU的数据包一直没有收到），该方法会减少PLPMTU。

      数据报PLPMTUD在实施中引入了灵活性。在一个极端，它可以被配置为只执行黑洞检测和恢复，与经典PMTUD相比具有更强的稳健性。在另一个极端，所有的PTB处理可以被禁用，而PLPMTUD取代了经典PMTUD。

       PLPMTUD还可以包括额外的一致性检查，而不增加探测发现路径MTU时数据丢失的风险。例如，在PL或更高层次的可用信息，使收到的PTB消息在使用之前得到验证。

1.3 数据报服务的PMTU发现

        本文第5节介绍了一套用于数据报协议的算法，以发现可在网络路径上发送的最大尺寸的不分片数据报。该方法依赖于第3节中描述的PL的特点，适用于在IPv4和IPv6上运行的传输协议。它不需要下层的合作，但收到PTB消息也可以利用PTB消息。

        UDP使用指南[BCP145]3.2中的消息大小指南指出"应用程序应使用IP层提供的路径MTU信息或实现路径MTU发现（PMTUD）"，但没有提供一种机制来发现可在网络路径上使用的最大尺寸的不分片数据报。本文更新了RFC8085，以指定这种方法来代替PLPMTUD [RFC4821]，并提供了一种机制来分享发现的最大尺寸作为MPS（见4.4）。

        [RFC4821]10.2为SCTP推荐了一种PLPMTUD探测方法。SCTP利用由最小尺寸的HEARTBEAT块与[RFC4820]中定义的PAD块合并组成的探测报文。然而，RFC4821并没有提供完整的规范。本文通过提供完整的规范取代了该描述。

        数据报拥塞控制协议（DCCP）[RFC4340]要求实施者支持经典的PMTUD，并指出DCCP发送者"必须为每个活动的DCCP会话维护允许的MPS"。它还定义了网络路径所支持的当前拥塞控制MPS（CCMPS）。这建议使用PMTUD，并建议使用控制包（DCCP-Sync）作为路径探测包，因为它们没有应用数据丢失的风险。本规范中定义的方法可以与DCCP一起使用。

       第4节和第5节定义了DPLPMTUD的协议机制和规范。

      第6节规定了数据报传输的方法，并提供信息以使PLPMTUD与其他数据报传输和使用数据报传输的应用程序一起实施。

      第6节还为SCTP端点提供了建议，更新了[RFC4960]、[RFC6951]和[RFC8261]，以使用本文中指定的方法，而不是[RFC4821]中的方法。

2. 术语

Acknowledged PL：一个PL可以确认数据报成功交付的远程PL端点（如SCTP）。通常情况下，PL接收方返回相应的确认，这可以用来检测数据包的黑洞（比方说，未确认的PL）。

Actual PMTU：实际的PMTU是指发送PL和目的PL之间的网络路径的PMTU，DPLPMTUD算法试图确定它。

Black Hole：当发送方不知道数据包没有发送到目的端点时，就会遇到黑洞。两种类型的黑洞与DPLPMTUD有关。

1. 当数据包没有发送到目的端点时，就会遇到数据包黑洞（例如，当发送方以先前已知的有效PMTU传送特定大小的数据包时，它们被网络丢弃）。
2. 当发送方不知道数据包没有交付给目的端点时，就会遇到ICMP黑洞，因为发端PL没有收到PTB消息。

Classical Path MTU Discovery：经典的PMTUD是在[RFC1191]和[RFC8201]中描述的一个过程，其中节点依靠PTB消息来了解可在网络路径上使用的最大尺寸的不分组的数据包。

Datagram：数据报是一个传输层协议数据单元，在IP包的有效载荷中传输。

DPLPMTUD：数据报分组化层路径MTU发现，PLPMTUD使用数据报传输协议执行。

Effective PMTU：有效PMTU是PMTUD使用的PMTU的当前估计值。这相当于由PLPMTUD得出的PLPMTU加上在PL下面添加的任何头的大小，包括IP头。

EMTU_S：发送的有效MTU（EMTU_S）在[RFC1122]中被定义为"对于IP源和目标地址的特定组合，可能发送的最大IP数据报大小......"。

EMTU_R：接收的有效MTU（EMTU_R）在[RFC1122]中被指定为"可重组的最大数据报大小"。

Link：链接是一种通信设施或媒介，节点可以通过它在链接层进行通信，即IP层以下的一层。例子是以太网局域网和互联网（或更高）层的隧道。

Link MTU：链路最大传输单元（MTU）是指可以在链路上传输的最大IP数据包（包括IP头和有效载荷）的字节大小。请注意，这可以更恰当地称为IP MTU，以便与其他标准组织使用该缩写的方式相一致。这包括IP头，但不包括链接层头和其他不属于IP或IP有效载荷的帧。其他标准组织通常将链接MTU定义为包括链接层头。本规范延续了[RFC4821]中的要求，即"所有链路必须强制执行其MTU：可能非决定性地传送大于其额定MTU的数据包的链路必须持续丢弃此类数据包"。

MAX_PLPMTU：DPLPMTUD将尝试使用的最大的PLPMTU大小（见5.1.2中定义的常量）。

MIN_PLPMTU：DPLPMTUD将尝试使用的最小的PLPMTU大小（见5.1.2中定义的常量）。

MPS：最大数据包大小（MPS，Maximum Packet Size）是指PL使用单个数据报在网络路径上可以发送的最大应用数据块大小（见4.4）。

MSL：最大段寿命（MSL，Maximum Segment Lifetime）是报文在路径上预计会经历的最大延迟，取为2分钟[BCP145]。

Packet：IP头和任何扩展头/选项加上IP有效载荷。

Packetization Layer (PL)：PL是网络栈的一个层，将数据放入报文并执行传输协议功能。PL的例子包括TCP、SCTP、SCTP over UDP、SCTP over DTLS或QUIC。

Path：报文在源节点和目的节点之间通过特定流量所穿越的link和路由器的集合。

Path MTU (PMTU)：PMTU是构成源节点和目的节点之间网络路径的所有链路MTU的最小值，由PMTUD使用。

PTB：在本文中，术语PTB消息适用于携带错误Fragmentation Needed（类型3，码点4）[RFC0792]的IPv4 ICMP Unreachable消息（类型3）和ICMPv6 Packet Too Big消息（类型2）[RFC4443]。

PTB_SIZE：PTB报文中报告的一个值，表示路径上的路由器的下一跳链路MTU。

PL_PTB_SIZE：PTB消息中报告的大小，减去由PL以下各层添加的所有头的大小。

PLPMTU：分组层PMTU是对PL数据报最大尺寸的估计，可由PLPMTUD控制的路径发送。

PLPMTUD：本文中描述的方法，用于数据报PL，是对经典PMTU发现的扩展。

Probe packet：探测报文是以特意选择的大小（通常是当前的PLPMTU或更大）发送的数据报，以检测该大小的报文是否能成功地在网络路径上进行端对端发送。

Unacknowledged PL：PL本身不提供确认数据报送至远程PL端点的机制（例如UDP），因此需要DPLPMTUD提供一个检测数据包黑洞的机制（比方说，Acknowledged PL）。

3. 提供数据报PLPMTUD 需要的特征

      [RFC4821]中表述的原则适用于该技术在任何PL中的使用。TCP PLPMTUD已经使用标准的TCP协议机制进行了定义。与TCP不同，数据报PL需要额外的机制和考虑来实现PLPMTUD。对数据报PLPMTUD的要求是：

1.    管理PLPMTU：对于数据报PL，PLPMTU由DPLPMTUD管理。PL不得在PL处发送尺寸大于当前PLPMTU的数据报（除探测包外）。

2.    探测报文：PL下面的网络接口必须提供一种方法来传输大于PLPMTU的探测报文。在IPv4中，探测报文的发送必须在IP头中设置Don't Fragment（DF）位，并且没有网络层端点分片。在IPv6中，探测报文总是在没有源分片的情况下发送（如[RFC8201]5.4所规定）。

3.    接收反馈：目的PL端点必须提供一种反馈方法，当目的PL端点收到探测报文时，告诉DPLPMTUD发送方。第6节提供了PL如何提供这种对收到的探测报文确认的例子。

4. 探测丢失恢复：建议使用不携带任何用户数据的探测报文，如果丢失，需要重传。大多数数据报传输允许这样做。如果探测报文包含需要在丢失时重传的用户数据，则要求PL（或以上各层）安排任何重传和/或修复任何导致的丢包。在探测报文由于其他原因（包括链路传输错误、拥堵）而丢失的情况下，PL必须是健壮的。

5.    PMTU参数：建议DPLPMTUD发送方利用本地链路上可以传输的最大数据包的信息（例如，本地链路MTU）。PL发送方可以利用类似的信息，比如接收方可以接受的网络层数据包的最大尺寸（注意这可能小于EMTU_R）。这可以避免实施者试图发送无法由本地链路传输的探测报文。太高的值会降低搜索算法的效率。一些应用程序也有一个最大的传输协议数据单元（PDU）大小，在这种情况下，探测大于这个大小没有好处（除非传输允许将多个应用程序的PDU复用到同一个数据报中）。

6.    处理PTB消息：DPLPMTUD发送者可以选择利用从网络层收到的PTB消息来帮助识别网络路径何时不支持当前大小的探测报文。任何收到的PTB消息在用于更新PLPMTU发现信息之前必须进行验证[RFC8201]。这种验证确认PTB消息是为了响应由发送方发起的数据包而发送的，并且需要在PLPMTU发现方法对PTB消息做出反应之前执行。PTB消息决不能用来增加PLPMTU [RFC8201]，但可以触发一个探针来测试更大的PLPMTU。有效的PTB_SIZE在被用于DPLPMTUD状态机之前被转换为PL_PTB_SIZE。大于当前探测值的PL_PTB_SIZE应该被忽略。(这个PTB消息应该被丢弃，而不需要进一步处理，但可以作为一个输入，启用一个弹性模式）。

7.    探测和拥塞控制：PL可能使用拥塞控制器来决定何时发送探测。如果探测的传输受到拥塞控制器的限制，可能导致在拥塞期间探测的传输被延迟或暂停。当探测报文的传输不受拥塞控制器控制时，探测报文之间的间隔必须至少是一个RTT。探测报文的丢失不应视为拥塞的迹象，不应触发拥塞控制反应[RFC4821]，因为这可能导致不必要的发送速率降低。对PLPMTU（或MPS）的更新不得增加以字节为单位的拥塞窗口[RFC4821]。因此，报文大小的增加不会导致以字节/秒为单位的数据速率的增加。以未完成的固定大小报文的数量限制来维持拥塞窗口的PL应该调整这个限制，以补偿实际数据包的大小。探测报文的传输可以与执行突发缓解或节奏的PL的操作相互影响，PL可能需要通过这些方法来调节探测报文的传输。

8. 探测和流量控制：PL的流量控制涉及使用PL服务的端到端数据流。当探测报文使用不携带用户数据到远程应用的设计时，流量控制不应该用于DPLPMTU。

9.    共享PLPMTU状态：从PLPMTU计算出的PMTU值可能也会与IP层缓存中与目的地相关的相应条目一起存储，并被其他PL实例使用。PLPMTUD的规范[RFC4821]指出："如果PLPMTUD更新了某个路径的MTU，那么所有共享路径表示（如5.2所述）的分组层会话都应该被通知使用新的MTU"。这种方法必须对各种各样的基础网络转发行为具有鲁棒性。[RFC8201]5.2提供了关于PMTU信息的缓存以及与IPv6流标签关系的指导。

此外，DPLPMTUD方法的设计还应遵循

• PL可能设计为将大于MPS的数据块分割成多个数据报。然而，并非所有的数据报PL都支持数据块的分割。建议在搜索当前支持的PLPMTU时，避免强迫应用程序使用任意小的MPS进行传输。减少的MPS会对应用的性能产生不利的影响。
• 为了帮助应用选择合适的数据块大小，建议PL提供接口将从PLPMTU得出的MPS返回给使用PL的高层。MPS的值可以在路径变化或探测报文丢失后变化。
• 路径验证：建议对自上次确认路径特征以来可能发生的路径变化以及对收到的不一致的路径信息的可能性具有很强的适应性。
• 数据报重新排序：必须对流量遇到重新排序或流量（包括探测包）被分到多个网络路径的可能性具有鲁棒性。
• 数据报延迟和复制：反馈机制必须对数据包在网络路径上明显延迟或重复的可能性具有鲁棒性。
• 何时探测：建议决定上次测量路径以来，路径是否有变化。这可以帮助确定何时再次探测路径。

4. DPLPMTUD机制

本节列出了本规范中使用的协议机制。

4.1. PLPMTU探测报文

        DPLPMTUD方法依赖于PL发送者能够生成特定大小的探测报文。TCP能够通过选择适当地分割正在发送的数据来生成这些探测报文[RFC4821]。相比之下，构建探测报文的数据报PL必须要求应用程序发送一个比应用程序生成的数据块大的数据，或者利用填充功能将数据报扩展到应用程序数据块的大小之外。允许交换控制信息（没有应用数据块）的协议可以通过用填充数据扩展控制信息来生成一个探测包。探针包的总大小包括所有头和添加到正在发送的有效载荷数据的填充（例如，包括协议选项字段、安全相关字段，如AEAD标签和TLS记录层填充）。

       接收者必须能够将带内数据块与填充区分开来。这需要确保填充不会传递给接收方的应用程序。

      这导致发送者有三种可能的方式来创建一个探测包：

1）使用填充数据进行探测：

探测包只包含控制信息和填充，这需要填充到探测包的大小。由于这些探测包不携带应用程序提供的数据块，通常不需要重传，尽管它们仍然消耗网络容量并引起终端处理。

2）使用应用数据和填充数据进行探测：

探测包包含由应用程序提供的数据块和填充，填充到探测包的大小。

3）使用应用程序数据进行探测：

探测包包含由应用程序提供的数据块，该数据块与探测包的大小一致。这种方法要求应用程序发出所需探测尺寸的数据块。

       使用携带应用数据的探测包并需要保护该探测包不被丢失的PL可以执行传输层重传/修复数据块（例如，检测到丢失后重传或在没有填充的数据报中复制数据块）。这种重传的数据块可能需要使用较小的PLPMTU来发送，这可能迫使PL使用较小的数据包大小来穿越端到端路径。(这可以利用端点网络层分片或可以将数据块重新分割成多个数据报的PL）。

      DPLPMTUD可以选择只使用这些方法中的一种来简化实现。

      PL发送的探测消息必须包含足够的信息，以便在最大段寿命内唯一地识别探测（例如，包括PL或DPLPMTUD实现的唯一标识），同时对探测响应和PTB消息的重新排序和重放具有鲁棒性。

4.2. 确认探测报文大小

        PL需要一种方法来确定（确认）探测包何时在网络路径上端到端成功接收。

      传输协议可以包括检测和报告他们所发送的特定数据报的接收情况的端到端方法（例如，DCCP、SCTP和QUIC提供keep-alive/heartbeat功能）。当支持时，这种机制也可以被DPLPMTUD用来确认探测包的接收。

       不确认数据接收的PL（如UDP和UDP-Lite）本身无法检测到因为大小大于实际的PMTU而丢失的报文。这些PL需要依靠应用协议来检测这种丢包。

        第6节为一组IETF指定的协议规定了这个功能。

4.3. 黑洞探测和减少PLPMTU

        下面的描述使用了5.1.2中定义的常数集和5.1.3中定义的变量。

       黑洞检测是由网络路径可能无法支持当前PLPMTU大小触发的。

       有三个指标可用于检测黑洞：

• - 收到经过验证的PTB消息，表明PL_PTB_SIZE小于当前的PLPMTU。DPLPMTUD方法决不能仅仅依赖这种方法。
• - PL可以使用DPLPMTUD探测机制来定期生成当前PLPMTU大小的探测包（例如，使用CONFIRMATION_TIMER，5.1.1）。使用一个定时器跟踪是否收到确认。探针的连续丢失表明当前路径不再支持PLPMTU（例如，当发送的多个探测包没有收到确认，PROBE_COUNT开始大于MAX_PROBES）。
• - PL可以利用表明网络路径不再维持发送方的PLPMTU大小的事件。这可以利用PL内部实现的机制来检测以特定数据包大小发送的数据的过度丢包，然后得出结论，这种过度丢包可能是无效的PLPMTU的结果（如TCP的PLPMTUD [RFC4821]）。

        这三种方法可能会导致探测的不同传输模式，预计在实际PMTU改变后会导致不同的响应。

       当自上一探测包以来没有发送应用数据时，PL可能会抑制发送探测包。恢复发送用户数据的PL可能会继续为每个路径发现PLPMTU。这样可以使用最新的PLPMTU。然而，这可能会导致额外的数据包发送。

       当该方法检测到当前的PLPMTU不支持时，DPLPMTUD设置一个较低的PLPMTU和较低的MPS。然后，PL确认新的PLPMTU可以在整个路径上成功使用。一个探测包可能需要小于应用程序生成的数据块的大小。

4.4. 最大报文大小(MPS，Maximum Packet Size)

       探测的结果决定了可用的PLPMTU，被用来设置应用程序使用的MPS。MPS比PLPMTU小，因为它被PL头的大小减少了（包括安全相关字段的开销，如AEAD标签和TLS记录层的填充）。图1说明了MPS和PLPMTUD之间的关系。

                          图1：MPS和PLPMTU的关系

       PL无法在网络层发送大于当前PLPMTU的数据包（除探测包外）。为了避免这种情况，PL可能设计为将大于MPS的数据块分割成多个数据报。

       DPLPMTUD试图避免IP分片。因此，如果PL不能分割数据，发送大于MPS的数据块的尝试将失败。为了确定可以发送的最大数据块，PL应该为应用程序提供一个查询MPS的接口，MPS来自当前的PLPMTU。

      如果DPLPMTUD导致MPS的改变，应用程序需要适应新的MPS。当数据包小于MPS，而PLPMTU随后减少时，就会出现一种特殊情况。如果这些数据包丢失，PL可能会使用新的MPS对数据进行分段。如果PL无法重新分割先前发送的数据报（例如，[RFC4960]），那么发送者要么丢弃该数据报，要么可以使用网络层分片执行重传，形成不大于PLPMTU的多个IP包。对于IPv4来说，发送方使用端点分片比清除IPv4头中的DF位要好。运行经验表明，IP分片会降低互联网通信的可靠性[RFC8900]，这可能会降低成功重传的概率。

4.5. 禁用PMTUD影响

       实施本规范的PL必须暂停网络层对出站数据包PMTU处理（[RFC1191][RFC8201]）（对每个流使用DPLPMTUD），而是使用DPLPMTUD来控制流所发送的数据包的大小。这消除了网络层放弃或分割尺寸大于PMTU的发送数据包的需要。

4.6. 回复PTB消息

        这种方法要求DPLPMTUD发送者在使用PTB消息之前验证收到的所有PTB消息。对PTB消息的响应取决于从PTB消息中的PTB_SIZE计算出的PL_PTB_SIZE、PLPMTUD状态机的状态以及正在使用的IP协议。

       4.6.1描述了对IPv4 ICMP Unreachable消息（Type 3）和ICMPv6 Packet Too Big消息的验证，这两种消息在本文中都被称为PTB消息。

4.6.1. 验证PTB消息

    本节规定了PTB消息的使用和验证。

• - 一个简单的实现可能会忽略收到的PTB消息，在这种情况下，当收到PTB消息时，PLPMTU不会被更新。
• - 支持PTB消息的PL必须在进一步处理这些消息之前对其进行验证。

      从路由器或中间件收到PTB消息的PL会执行ICMP验证（见[RFC8201]第4节和[BCP145]5.2）。因为DPLPMTUD是在PL上操作的，所以PL需要检查每个收到的PTB消息是否是对执行DPLPMTUD的端点PL所发送数据包的响应。

        PL必须检查ICMP PTB消息有效载荷中携带的引用报文中的协议信息，以验证该消息来自于发送节点。这种验证包括确定IP地址、协议、源端口和目的端口的组合与引用报文中返回的数据相匹配--这对于PTB消息传递给相应的PL也是必要的。

        验证应利用路径外攻击者不容易确定的信息[BCP145]。例如，它可以检查只有两个PL端点知道的协议头字段的值。使用知名源端口和目的端口的数据报应用程序也应该依靠其他信息来完成这一验证。

       这些检查的目的是提供保护，防止来自网络路径外节点的数据包。没有完成验证的PTB消息决不能被DPLPMTUD方法进一步使用，这一点在安全考虑部分（第8节）有讨论。

     4.6.2描述了PTB消息的这种处理。

4.6.2. 使用PTB消息

      经过验证的PTB消息可以被DPLPMTUD算法使用，但绝不能直接用来设置PLPMTU。

     在使用PTB消息中报告的大小之前，必须先将其转换为PL_PTB_SIZE。PL_PTB_SIZE比PTB_SIZE小，因为它被PL下面的头减少了，包括添加到PL包的任何IP选项或扩展。

     使用这些PTB消息的方法可以提高算法检测适当PLPMTU的速度，因为它触发了对PL_PTB_SIZE的立即探测（导致大小为PTB_SIZE的网络层数据包），与只依靠使用基于定时器的搜索算法的探测相比。

       一组检查旨在防止路由器报告意外PTB_SIZE。PL还需要检查指示的PL_PTB_SIZE小于探测包使用的大小，至少是接收的最小大小。

     本节提供了如何利用PTB消息的总结，使用5.1.2中定义的一组常量。这种处理取决于PL_PTB_SIZE和一组变量的当前值：

PL_PTB_SIZE < MIN_PLPMTU

• 无效PL_PTB_SIZE，见 4.6.1.
• PTB消息应该被丢弃而不作进一步处理（即PLPMTU不被修改）。
• 该信息可以作为触发启用弹性模式的输入（见5.3.3）。

MIN_PLPMTU < PL_PTB_SIZE < BASE_PLPMTU

• 当PTB消息中报告的PL_PTB_SIZE大于或等于68字节[RFC0791]且小于BASE_PLPMTU时，对于IPv4路径，健壮的PL可能会进入错误状态（见5.2）。
• 当PTB消息中报告的PL_PTB_SIZE大于或等于1280字节[RFC8200]且小于BASE_PLPMTU时，对于IPv6路径，健壮的PL可能会进入错误状态（见5.2）。

BASE_PLPMTU <= PL_PTB_SIZE < PLPMTU

• 这可能是一个黑洞迹象。PLPMTU应该被设置为BASE_PLPMTU（当遇到黑洞时，PLPMTU被减少到BASE_PLPMTU以避免不必要的丢包）。
• PL应该开始搜索以迅速发现新PLPMTU。PTB消息中报告的PL_PTB_SIZE可以用来初始化搜索算法。

PLPMTU < PL_PTB_SIZE < PROBED_SIZE

• PLPMTU继续有效，但用于搜索的数据包大小（PROBED_SIZE）大于实际的PMTU。
• PLPMTU不被更新。
• PL可以在恢复搜索算法时使用PTB消息中报告的PL_PTB_SIZE作为下一个搜索点。

PL_PTB_SIZE >= PROBED_SIZE

• 网络信号不一致。
• PTB消息应该被丢弃而不作进一步处理（即PLPMTU不被修改）。
• 可以使用该信息作为输入，触发弹性模式的启用。

5. 数据报分组层PMTUD

      本节规定了数据报PLPMTUD（DPLPMTUD）。该方法可以在IP协议栈中的不同点（如图2中的*号所示）引入，以发现PLPMTU，从而使应用程序能够为当前的网络路径使用适当的MPS。

      DPLPMTUD应该只在端点之间的一个层进行。因此，当下层已经启用DPLPMTUD时，上层的PL或应用应该避免使用DPLPMTUD。PL必须调整由DPLPMTUD指示的MPS，以考虑由PL引入的任何额外开销。

图2 可以实现DPLPMTUD的位置示例 

       DPLPMTUD的中心思想是由发送方进行探测。发送探测包是为了找到可以完全通过网络路径从发送方传输到目的地的最大用户消息大小。

      下面几节确定了实现所需的组件，提供了操作阶段的概述，并说明了状态机和搜索算法。

5.1. DPLPMTUD组件

本节描述了DPLPMTUD的定时器、常量、变量。

5.1.1. 定时器

本方法使用了三个定时器：

PROBE_TIMER：PROBE_TIMER被配置为在比接收探测包的最大确认时间更长的时间内失效。这个值不能小于1秒，应该大于15秒。UDP使用指南[BCP145]3.1.1中提供了关于选择定时器值的指导。

PMTU_RAISE_TIMER：PMTU_RAISE_TIMER被配置为发送者继续使用当前PLPMTU的期限，之后重新进入搜索阶段。根据PLPMTUD [RFC4821]的建议，这个定时器的周期为600秒。

       当上一个探测包后没有发送应用数据时，DPLPMTUD可能会抑制发送探测包。一旦用户数据再次发送，喜欢使用最新PMTU的PL可以选择继续为每个路径发现PMTU。然而，这将导致发送额外的数据包。

CONFIRMATION_TIMER：当使用确认的PL时，这个定时器一定不能使用。对于其他PL，CONFIRMATION_TIMER被配置为PL发送者在确认当前PLPMTU仍被支持之前所等待的时间。这比PMTU_RAISE_TIMER小，用于减少PLPMTU（例如，当遇到黑洞时）。当数据流动时，确认需要足够频繁，以便发送PL不黑洞大量的流量。UDP使用指南[BCP145]的3.1.1中提供了关于选择定时器值的指导。

       DPLPMTUD可能会抑制发送探测包，因为上一个探测包以来没有发送任何应用数据。一旦用户数据被再次发送，希望使用最新的PMTU的PL可以选择继续为每个路径发现PMTU。然而，这可能会导致发送额外的数据包。

      DPLPMTUD规定了各种定时器；然而，实施方案可以选择使用单个定时器来实现这些定时器功能。

5.1.2. 常量

定义了如下常量：

MAX_PROBES：MAX_PROBES是PROBE_COUNT计数器的最大值（见5.1.3）。MAX_PROBES表示任何规模的连续探测尝试的数量限制。搜索算法受益于大于1的MAX_PROBES值，因为这可以提供对孤立丢包的稳健性。MAX_PROBES的默认值是3。

MIN_PLPMTU：MIN_PLPMTU是DPLPMTUD尝试使用的最小的PLPMTU大小。一个端点可能需要配置MIN_PLPMTU，以便为扩展头和PL下面各层的其他分组提供空间。这个值可能与接口和路径有关。对于IPv6，该大小大于或等于[RFC8200]中规定的1280字节IPv6数据包的PL大小。对于IPv4，该大小大于或等于68字节IPv4数据包的PL的大小。注意：一个IPv4路由器需要能够转发68字节的数据报，而不需要进一步分片。这是一个IPv4头和8字节的最小碎片大小的组合。此外，如[RFC1122]3.3.3所述，接收者必须能够重新组装碎片，至少达到576字节。

MAX_PLPMTU：MAX_PLPMTU是PLPMTU的最大尺寸。这必须小于或等于可在出站接口上发送的PL包的最大尺寸（受本地接口MTU的限制）。当已知时，这也应该小于远程终端可以接收的PL包的最大尺寸（受EMTU_R的限制）。它可以由正在使用的PL的设计或配置来限制。当不需要发送大于特定大小的数据包时，应用程序或PL可能会选择一个较小的MAX_PLPMTU。

BASE_PLPMTU：BASE_PLPMTU是一个配置的大小，对大多数路径有效。这个大小等于或大于MIN_PLPMTU，小于MAX_PLPMTU。对于大多数PL来说，合适的BASE_PLPMTU大于1200字节。当使用IPv4时，目前没有指定相应的大小，建议使用默认的BASE_PLPMTU-1200字节。

5.1.3. 变量

PROBED_SIZE：PROBED_SIZE是PL确定的当前探测包的大小。这是PLPMTU的一个暂定值，正在等待确认。

PROBE_COUNT：PROBE_COUNT是对已发送的连续不成功的探测包数量的计数。每次探测包被确认后，该值被设置为零。(在搜索过程中会有一些探针丢失，因此单个探针的丢失并不表明PMTU有问题）。

图3说明了当DPLPMTUD算法执行路径探测以增加PLPMTU的大小时，数据包大小常数和变量之间的关系。一个大小为PROBED_SIZE的探测包已发送。一旦被确认，PLPMTU将提高到PROBED_SIZE，允许DPLPMTUD算法进一步增加PROBED_SIZE，朝着发送实际PMTU大小的探针。

图3 报文大小常量和变量的关系

5.1.4. DPLPMTUD阶段预览

       本节通过描述该方法在几个运行阶段的运动，提供了关于DPLPMTUD方法的高层次、信息性的观点。更多的细节可以在5.2的状态机中找到。

                                    图4： DPLPMTUD阶段

Base：基础阶段（Base Phase）使用BASE_PLPMTU的数据包确认与对端的连接。对于面向连接的PL来说，连接的确认是隐含的（可以在PL连接握手中执行）。无连接的PL发送探测包，并使用探测包的确认来确认对端是可到达的。

        发送者还确认整个网络路径支持BASE_PLPMTU。这可以通过使用PL机制（例如，使用大小为BASE_PLPMTU的握手报文）或通过发送大小为BASE_PLPMTU的探测报文并确认其被接收来实现。

       大小为BASE_PLPMTU的探测包可以在最初进入基础阶段时立即发送（在连接性检查之后）。不希望支持PLPMTU小于BASE_PLPMTU的路径的PL可以通过用BASE_PLPMTU大小的探针进行连接性检查将该阶段简化为一个步骤。

      一旦确认，DPLPMTUD进入搜索阶段。如果基础阶段未能确认BASE_PLPMTU，DPLPMTUD进入错误阶段。

Search：搜索阶段（Search Phase）使用一个搜索算法来发送探测包，以寻求增加PLPMTU。当该算法找到一个合适的PLPMTU时，进入搜索完成阶段，该算法就结束了。

PL可以利用PTB消息来推进或终止搜索，见4.6。

Search Complete：当整个网络路径支持PLPMTU时，进入搜索完成阶段。PL可以使用CONFIRMATION_TIMER来定期重复当前PLPMTU大小的探测包。如果发送方无法确认可达性（例如，CONFIRMATION_TIMER过期）或PL发出缺乏可达性的信号，则检测到一个黑洞，DPLPMTUD进入基础阶段。

PMTU_RAISE_TIMER用来定期恢复搜索阶段，以发现是否可以提高PLPMTU。黑洞检测导致发送方进入基础阶段。

Error：当路径的PLPMTU信息出现冲突或无效时（例如，不支持BASE_PLPMTU），导致DPLPMTUD无法进行，PLPMTU被降低，就会进入错误阶段。

DPLPMTUD一直处于错误阶段，直到可以发现路径的一致视图，并且也确认了路径支持BASE_PLPMTU（或者DPLPMTUD被暂停）。

只把PLPMTU减少到合适大小的方法足以保证可靠的运行，但是当实际的PMTU发生变化或者方法（无论什么原因）对PLPMTU做出次优选择时，效率会非常低。

DPLPMTUD的完整实现提供了一种算法，使DPLPMTUD发送方能够在路径特征发生变化后增加PLPMTU，例如当一条链路被重新配置为更大的MTU时，或者当端到端流量所穿越的链路集发生变化时（例如，在路由或路径故障切换决定后）。

5.2. 状态机

图5描述了DPLPMTUD的状态机。如果支持多路径或多宿主，每个路径都需要一个状态机。

注意：为了简化图表，没有显示所有的变化。                                                   

图5：数据报PLPMTUD状态机

DISABLED：

DISABLED状态是探测开始前的初始状态。当PL表示失去连接时，也可以从任何其他状态进入该状态。一旦PL表明与远程PL的连接成功，就会离开这个状态。当过渡到BASE状态时，可以立即发送一个大小为BASE_PLPMTU的探测包。

BASE：

       BASE状态用于确认网络路径支持BASE_PLPMTU大小，旨在允许应用程序在实际PMTU出现瞬时减少时继续工作。它也是为了避免在寻找更大的PLPMTU的发送者不知道数据包由于数据包或ICMP黑洞而没有被传送的漫长时期。

       进入时，PROBED_SIZE被设置为BASE_PLPMTU，而PROBE_COUNT被设置为零。

      每当发送一个探测包，PROBE_TIMER就会启动。当探测包被确认时，该状态退出，PL发送者进入Search状态。

      当PROBE_COUNT达到MAX_PROBES或收到的PTB消息被验证时，该状态也会离开。这将导致PL发送者进入ERROR状态。

SEARCHING：

      SEARCHING状态是主要的探测状态。当BASE_PLPMTU的探测完成后，就进入这个状态。

      每次探测包被确认后，PROBE_COUNT被设置为零，PLPMTU被设置为PROBED_SIZE，然后使用搜索算法增加PROBED_SIZE（如5.3所述）。

        当一个探测包被发送且在PROBE_TIMER期间没有被确认时，PROBE_COUNT增加，发送一个新的探测包。

        当PROBE_COUNT达到MAX_PROBES时，或者收到一个与最后成功探测的大小相对应的有效PTB（PL_PTB_SIZE = PLPMTU），或者一个大小为MAX_PLPMTU的探测被确认（PLPMTU = MAX_PLPMTU），Search状态退出，进入SEARCH_COMPLETE。

        当SEARCHING状态检测到黑洞时， PL发送者将进入BASE状态。

SEARCH_COMPLETE：

     SEARCH_COMPLETE状态表示搜索已经完成。这是正常的维护状态，PL没有探测更新PLPMTU。DPLPMTUD一直处于这种状态，直到PMTU_RAISE_TIMER过期或检测到黑洞。

    当DPLPMTUD使用不提供确认的PL，并且处于SEARCH_COMPLETE状态时，CONFIRMATION_TIMER会定期重置PROBE_COUNT，并发送一个PLPMTU的探测包。如果MAX_PROBES连续的PLPMTUD大小的探测未能被确认，该方法进入BASE状态。当与支持确认的PL（例如SCTP）一起使用时，DPLPMTUD不应该在此状态下继续产生PLPMTU探测。

ERROR：

       ERROR状态代表的情况是，要么不知道网络路径支持至少BASE_PLPMTU的PLPMTU，要么有关于网络路径的矛盾信息，会导致带给上层的MPS的过度变化。该状态实现了一种缓解状态事件引擎的振荡的方法。它通过PL向上层发出MPS的保守值。当数据包探测不再检测到错误时，该状态就退出了。然后PL发送者进入搜索状态。

      如果DPLPMTUD无法在PROBE_COUNT个探针中验证MIN_PLPMTU，则允许实施者启用端点分片。如果DPLPMTUD无法验证MIN_PLPMTU，实现将过渡到DISABLED状态。

     注意：MIN_PLPMTU可以与BASE_PLPMTU相同，从而简化该状态下的操作。

5.3. 搜索更大PLPMTU

    本节描述了DPLPMTUD用来搜索更大的PLPMTU的算法。

5.3.1. 更大PLPMTU的探测

      实施方案在搜索范围内使用搜索算法，以确定整个网络路径是否可以支持更大的PLPMTU。

     该方法通过确认最小的PLPMTU来发现搜索范围，然后使用探测方法来选择一个小于等于MAX_PLPMTU的PROBED_SIZE。MAX_PLPMTU是本地MTU和EMTU_R的最小值（当这是从远端得知的）。应用程序对发送数据报的大小设置了一个最大值时，MAX_PLPMTU可能会被减少。

      当发送第一个大于等于PLPMTU的探针时，PROBE_COUNT初始化为零。每一个成功发送到远端的探测包都会在PL上得到确认（4.1）。

      每当一个探测包发送到目的地，PROBE_TIMER就会启动。当PL收到探测包已成功通过路径发送的确认时，取消该计时器（4.1）。这确认了支持PROBED_SIZE，然后PROBED_SIZE赋值给PLPMTU。搜索算法可以继续发送后续的探测包，大小不断增加。

      如果定时器在探测包被确认之前过期，则探针未能确认PROBED_SIZE。每次PROBE_TIMER过期，PROBE_COUNT递增，PROBE_TIMER重新初始化，并且可以发送相同大小或任何其他大小（由搜索算法决定）的新探测。连续失败探针的最大数量是配置的（MAX_PROBES）。如果PROBE_COUNT的值达到MAX_PROBES，探测将停止，PL发送方进入SEARCH_COMPLETE状态。

5.3.2. 选择探测大小

       搜索算法确定了PLPMTU的最小有用增益。对于PL发送者来说，试图探测所有的尺寸是没有建设性的。这将在路径上产生不必要的负载。实现应选择一组探测包的大小，以使每个搜索步骤中的PLPMTU收益最大化。

      实现可以通过从常见的PMTU大小表中选择步长来优化搜索程序。当选择适当的下一步搜索大小时，实施者还应该考虑到，可能存在应用程序寻求使用的MPS的常见大小，并且可能存在网络内使用的MTU的常见大小。

5.3.3. 对不一致路径信息的弹性

    增加PLPMTU的决定需要对了解到的网络路径信息不一致的可能性具有弹性。例如，当探测包由于其他原因（即不是包大小）或由于频繁的路径变化而丢失时，路径就不一致。频繁的路径变化可能是由意外的"flapping"引起的--即一个流的一些包沿着一条路径通过，但其他包则沿着不同的路径，具有不同的属性。

   PL发送方能够从被确认的PLPMTU探测序列或从它收到的PTB消息序列中检测到不一致。当检测到不一致的路径信息时，PL发送方可以使用一种替代的搜索模式，将提供的MPS在一段时间内夹在一个较小的值中。这就避免了不必要的丢包。

5.4. 对不一致路径的鲁棒性

     一些路径可能无法维持BASE_PLPMTU大小的包。可以实施错误状态，为这种路径提供稳健性。这允许回退到比期望的PLPMTU更小，而不是遭受连接失败。这可以利用端点IP分片等方法，使PL发送者能够使用小于BASE_PLPMTU的包进行通信。

6. 协议特定方法的规定

    DPLPMTUD要求为每个使用的PL指定特定的协议细节。

     第一小节提供了如何实现DPLPMTUD方法的指导，作为使用UDP或UDP-Lite的应用程序的一部分。该指导也适用于其他不包括特定传输协议（如隧道封装）的数据报服务。下面的小节描述了如何将DPLPMTUD作为传输服务的一部分来实现，使用该服务的应用程序从PLPMTU的发现中获益，而在使用SCTP和QUIC时，它们本身不需要实现这种方法。

6.1. 使用UDP或UDP-Lite的DPLPMTUD的应用支持

UDP[RFC0768]和UDP-Lite[RFC3828]的当前规范没有定义RFC系列中支持PLPMTUD的方法。特别是，UDP传输没有提供实现数据报PLPMTUD所需的传输功能。

DPLPMTUD方法可以作为直接或间接建立在UDP或UDP-Lite上的应用程序的一部分来实现，但要依靠更高层的协议特性来实现该方法[BCP145]。

DPLPMTUD使用的一些接口可能无法通过数据报API获得（例如，从IP层缓存访问PLPMTU的能力或解释收到的PTB消息）。

此外，建议PMTU发现不由多个协议层执行。当底层传输系统提供这种能力时，应用程序应该避免使用DPLPMTUD。管理PLPMTU的通用方法有很多好处，包括在不同进程之间共享状态的能力和协调不同PL实例探测的机会。

6.1.1. 应用请求

应用程序需要应用层协议机制（比如消息确认方法），从目标端点征求响应。该方法应该允许发送方检查响应中返回的值，以提供额外的保护，防止路径外的数据插入[BCP145]。合适的方法包括只有两个端点知道的参数，例如会话ID或初始化序列号。

6.1.2. 应用响应

应用程序需要应用层协议机制来传达来自目的端点的响应。这个响应可以表示成功接收了整个路径上的探针，但也可以表示一些（或所有）包未能到达目的地。

6.1.3. 发送应用探测包

探测包可以携带一个应用数据块，但用于探测时，该数据的成功传输有风险。一些应用可能倾向于使用不携带应用数据块的探测包，以避免数据传输的中断。

6.1.4. 初始连接

没有其他高层信息确认与远端连接的应用程序应该在进入BASE状态之前使用确认的探测包实现连接机制。

6.1.5. 验证路径

没有其他高层信息确认数据报正确交付的应用应实现CONFIRMATION_TIMER，以便在SEARCH_COMPLETE状态下定期发送探测包。

6.1.6. 处理PTB消息

能够并希望接收PTB消息的应用程序必须按照[BCP145]5.2的规定执行ICMP验证。这要求应用程序检查每个收到的PTB消息，以验证消息是响应传输流量的，并且报告的PL_PTB_SIZE小于当前探测的大小（见4.6.2）。经过验证的PTB消息可以作为DPLPMTUD算法的输入，但决不能直接用于设置PLPMTU。

6.2. SCTP的DPLPMTUD

[RFC4821] 10.2规定了SCTP的推荐PLPMTUD探测方法，[RFC4960]7.3建议终端在每个目的地址的基础上应用RFC4821中的技术。DPLPMTUD的规范继续使用PL来发现PMTU的做法，但对RFC4960进行了更新，建议使用本文中指定的方法。推荐用于生成探针的方法是向SCTP消息中添加一个仅由填充组成的块。[RFC4820]中定义的填充块应该附加到最小长度的HEARTBEAT(HB)块中以组建一个探测包。这样就可以在不影响用户信息传输的情况下进行探测，并且不受拥塞控制或流量控制的限制。这比使用数据块（如果需要加上填充）作为路径探测要好。

[RFC4960] 6.9描述了在使用SCTP时将用户消息分成由PL发送的DATA块。这指出，一旦SCTP消息被发送，就不能再进行重新分割。[RFC4960]描述了当MPS减少时重传DATA块的方法，[RFC4960] 6.9描述了在这种情况下使用IP分片。这一点在本文中没有改变。

6.2.1. SCTP/IPv4和SCTP/IPv6

6.2.1.1. 初始连接

基本协议在[RFC4960]中规定。这提供了一个确认的PL。因此，一旦连接性得到确认，发送方就可以进入BASE状态。

6.2.1.2. 发送SCTP探测包

探针包由一个SCTP通用头组成、一个HEARTBEAT块和一个PAD块组成。PAD块用于控制探测包的长度。HEARTBEAT块用于触发HEARTBEAT ACK块的发送。接收到HEARTBEAT ACK块，就确认接收到了一个成功的探测。成功的探针会更新偶联和路径计数器，但不成功的探针会被打折扣（假定是选择过大的PLPMTU的结果）。

SCTP发送方需要能够确定探测包的大小。HEARTBEAT块可以携带一个心跳信息参数，除了[RFC4960]中建议的信息外，还包括探测大小，以帮助实现将HEARTBEAT ACK与发送的探测大小联系起来。发送方也可以使用其他方法，如发送一个nonce并验证返回的信息也包含相应的nonce。PAD块的长度是通过探测大小减去SCTP通用头和HEARTBEAT块的大小来计算的。PAD块的有效载荷包含任意数据。当在IP层传输时，PMTU大小还包括IPv4或IPv6头。

探测可以在PL握手后直接开始，可以在数据发送前完成。假设这种行为（即PMTU小于等于接口MTU），这个过程将需要几个往返的时间段，取决于发送的DPLPMTUD探测的数量。Heartbeat定时器可以用来实现PROBE_TIMER。

6.2.1.3. 用SCTP验证路径

由于SCTP提供了一个确认的PL，在SEARCH_COMPLETE状态下，发送方不得实施CONFIRMATION_TIMER。

6.2.1.4. SCTP处理PTB消息

必须按照[RFC4960]附录C的规定执行正常的ICMP验证。这要求在PTB报文的有效载荷中引用SCTP通用头的前8个字节，这对ICMPv4来说可能是这样的，对ICMPv6来说通常是这样的。

当PTB报文被验证后，从PTB报文中报告的PTB_SIZE计算出的PL_PTB_SIZE应与DPLPMTUD算法一起使用，前提是报告的PL_PTB_SIZE小于当前探针大小（见4.6）。

6.2.2.  SCTP/UDP的DPLPMTUD

SCTP的UDP封装在[RFC6951]中规定。

本规范更新了RFC 6951第5.6节中对RFC 4821的引用，代之以引用本文（RFC 8899）。RFC 6951的更新是在5.6的末尾增加了以下句子：

The RECOMMENDED method for determining the MTU of the path is specified in RFC 8899.

6.2.2.1. 初始连接

一旦SCTP连接确认了，发送方就可以进入BASE状态。

6.2.2.2. 发送SCTP/UDP探测包

包探测可以按照6.2.1.2的规定进行。探测包的大小包括8字节的UDP头。在用PAD块填充探测包时，必须考虑到这一点。

6.2.2.3. 使用SCTP/UDP验证路径

SCTP提供了一个确认的PL；因此，在SEARCH_COMPLETE状态下，发送者不实施CONFIRMATION_TIMER。

6.2.2.4.  SCTP/UDP 处理PTB消息

必须按照[RFC4960]附录C的规定对PTB消息进行ICMP验证。这要求PTB报文中包含SCTP通用头的前8个字节，对于ICMPv4来说可以是这种情况（但要注意UDP头也会消耗引用包头的一部分），对于ICMPv6来说通常是这种情况。当验证完成后，从PTB报文中的PTB_SIZE计算出的PL_PTB_SIZE应该与DPLPMTUD一起使用，前提是报告的PL_PTB_SIZE小于当前的探测大小。

6.2.3. SCTP/DTLS的DPLPMTUD

SCTP的DTLS封装在[RFC8261]中指定。用于WebRTC实现中的数据通道。本规范更新了RFC 8261第5节中对RFC 4821的引用，代之以引用本文（RFC 8899）。

6.2.3.1. 初始连接

一旦确认SCTP连接，发送方就可以进入BASE状态。

6.2.3.2. 发送SCTP/DTLS探测包

包探测可以按照6.2.1.2的规定进行。最大有效载荷因DTLS头的大小而减少，这在填充PAD块时必须考虑。探针包的大小包括DTLS PL头。在用PAD块填充探测包时，必须考虑到这一点。

6.2.3.3. 使用SCTP/DTLS验证路径

由于SCTP提供了一个确认的PL，在SEARCH_COMPLETE状态下，发送方不得实施CONFIRMATION_TIMER。

6.2.3.4. SCTP/DTLS处理PTB消息

[RFC4960]没有指定验证SCTP/DTLS ICMP消息有效载荷的方法，本文也没有。这可能会阻止PL的PTB消息的处理。

6.3. QUIC的DPLPMTUD

       QUIC[QUIC]是一种基于UDP的PL，提供接收反馈。UDP有效载荷包括一个QUIC头、一个受保护的有效载荷和任何认证字段。它支持填充和数据包聚合，可用于构建探测包。从DPLPMTUD的角度来看，QUIC可以作为一个确认的PL发挥作用。[QUIC]描述了通过QUIC包使用DPLPMTUD的方法。

7. IANA考虑

无

8. 安全考虑

使用UDP和SCTP的安全考虑在引用的RFC中提供。

为了避免过多的负载，各个探测包之间的间隔必须至少是一个RTT，各轮探测的间隔由PMTU_RAISE_TIMER决定。

PL发送者需要确保用于确认接收探测包的方法能够防止路径外攻击者将数据包注入路径。这种保护在IETF定义的协议（如TCP、SCTP）中使用随机初始化的序列号提供。 [BCP145]5.1中提供了使用UDP时的方法描述。

有些情况下，由于政策、配置或设备设计的原因，ICMP包太大（PTB）消息无法被传递（见1.1）。因此，这种方法并不依赖于PTB消息的接收，而是能够在发送方收到这些消息时加以利用。PTB消息有可能被用来导致一个节点不适当地减少PLPMTU。因此，支持DPLPMTUD的节点必须适当地验证PTB消息的有效载荷，以确保这些消息是对传输流量的响应（即报告的错误条件与路径层实际发送的数据报相对应，见4.6.1）。

能够创建PTB消息的路径攻击者可以伪造PTB消息，其中包括一个有效的引用IP包。这种攻击可以用来降低PLPMTU。路径上的设备同样可以通过实施丢弃大于配置大小的包的策略来强制减少PLPMTU。有两种方法可以缓解这种攻击：第一，确保PL发送者永远不会仅仅因为收到PTB消息而将PLPMTU降低到基本大小以下。这是通过在收到此类消息时首先进入BASE状态来实现的。其次，该设计不需要处理PTB消息；因此，PL发送方可以暂停处理PTB消息（例如，在检测到后续探测实际确认路径支持大于PTB_SIZE的大小后的稳健性模式）。

解析PTB消息内的引用包可以在PL发送方引入额外的每包处理。这种处理应该是有限的，以避免在包括任意头信息时出现拒绝服务攻击。限制处理的速度可能会导致PTB消息不能被PL接收；然而，DPLPMTUD方法对这种丢失是健壮的。

报告的PTB大小有效时，ICMP消息的成功处理可以触发一个探测，但这并不直接更新路径的PLPMTU。这可以防止消息通过指示大于路径支持的大小而试图黑洞数据。

关于路径的信息有可能不稳定。这可能是由于在一个以上的路径上转发，这些路径有不同的实际PMTU，或者一个路径呈现不同的PMTU。PLPMTUD实现的设计应该考虑如何减轻不同路径信息的影响。一个可能的缓解措施是在避免MPS振荡的方法中提供健壮性（见5.4节）。

DPLPMTUD方法可以引入填充数据，将数据报的长度膨胀到探测包所需的大小。一个探测包的总大小包括所有的头和添加到正在发送的有效载荷数据的填充（例如，包括安全相关的字段，如AEAD标签和TLS记录层的填充）。填充数据的值不影响DPLPMTUD的搜索算法，因此需要根据PL的策略来设置。

如果PL可以利用加密的保密性或数据完整性机制，那么设计应该避免向DPLPMTUD探测包添加任何不受这些加密机制保护的东西（如填充）。