RFC8201：Path MTU Discovery for IP version 6，July 2017
梗概
本文档描述了 IPV6 的路径 MTU 发现 (Path MTU Discovery，PMTUD)。它主要源自 RFC 1191（你了解MTU和TCP MSS不？），它描述了 IPV4 的路径 MTU 发现。它已废弃 RFC 1981。
本备忘录的状态
这是一份 Internet 标准跟踪文档。
本文档是 Internet 工程任务组 (IETF) 的产品。它代表了 IETF 社区的共识。它已接受公众审查，并已获互联网工程指导小组 (IESG) 批准出版。有关 Internet 标准的更多信息，请参见 RFC 7841 的第 2 节。
有关本文档当前状态、勘误表以及如何提供反馈的信息，请访问 http://www.rfc-editor.org/info/rfc8201。
版权声明
版权所有 (c) 2017 IETF Trust 和文件作者。版权所有。
本文件受 BCP 78 和 IETF 信托关于 IETF 文件的法律规定 (http://trustee.ietf.org/license-info) 的约束，该条款在本文件发布之日生效。请仔细阅读这些文件，因为它们描述了您对本文件的权利和限制。从本文档中提取的代码组件必须包含 Trust Legal Provisions 第 4.e 节中所述的简化 BSD 许可文本，并且按照简化 BSD 许可中的说明在不保证的情况下提供。
本文档可能包含来自 2008 年 11 月 10 日之前发布或公开的 IETF 文档或 IETF 投稿的材料。控制本材料某些版权的人可能未授予 IETF 信托允许修改此类材料的权利在 IETF 标准流程之外。在未从控制此类材料版权的人那里获得充分许可的情况下，不得在 IETF 标准流程之外修改本文档，并且不得在 IETF 标准流程之外创建其衍生作品，除非将其格式化为作为 RFC 发布或将其翻译成英语以外的其他语言。
1、 简介
当一个 IPv6 节点有大量数据要发送到另一个节点时，数据以一系列 IPv6 数据包的形式传输。这些数据包的大小可以小于或等于路径 MTU (Path MTU，PMTU)。或者，它们可以是更大的数据包，被分成一系列分片，每个分片的大小小于或等于 PMTU。
通常最好是这些数据包具有最大的大小，可以成功地穿过从源节点到目标节点的路径，而无需 IPv6 分片。这个数据包大小称为Path MTU，它等于一条路径中所有链路的最小链路MTU。本文档定义了一个节点发现任意路径的 PMTU 的标准机制。
IPv6 节点应该实现路径 MTU 发现，以便发现和利用 PMTU 大于 IPv6 最小链路 MTU [RFC8200] 的路径。最小的 IPv6 实现（例如，在引导 ROM 中）可以选择省略路径 MTU 发现的实现。
未实现路径 MTU 发现的节点必须使用 [RFC8200] 中定义的 IPv6 最小链路 MTU 作为最大数据包大小。在大多数情况下，这将导致使用比所需更小的数据包，因为大多数路径的 PMTU 大于 IPv6 最小链路 MTU。发送比 Path MTU 允许的小得多的数据包的节点正在浪费网络资源并且可能获得次优吞吐量。
如果 ICMPv6 [ICMPv6] 消息被阻止或未传输，则实施路径 MTU 发现并发送大于 IPv6 最小链路 MTU 的数据包的节点很容易出现连接问题。例如，这将导致连接正确完成 TCP 三向握手，但在传输数据时会挂起。这种状态被称为黑洞连接 [RFC2923]。路径 MTU 发现依赖于 ICMPv6 数据包太大 (Packet Too Big，PTB) 来确定路径的 MTU。
本文档中定义的路径 MTU 发现的扩展可以在 [RFC4821] 中找到。RFC 4821 定义了一种用于分组层路径 MTU 发现 (Packetization Layer Path MTU Discovery，PLPMTUD) 的方法，该方法设计用于在无法保证将 ICMPv6 消息传递到主机的路径上使用。
注意：本文档是在 [RFC2119] 发布之前发布的 [RFC1981] 的更新。因此，尽管 RFC 1981 在大写和小写中使用了“should/must”样式语言，但本文档没有引用 RFC 2119 的定义，而仅对这些词使用小写。
2、 术语
node：节点，实现 IPv6 的设备。
router：路由器，转发未明确寻址到自身的 IPv6 数据包的节点。
host：主机，任何不是路由器的节点。
upper layer：上层，紧接在 IPv6 之上的协议层。例如 TCP 和 UDP 等传输协议、ICMPv6 等控制协议、OSPF 等路由协议，以及通过（即封装在）IPv6 上“隧道化”的互联网层或较低层协议，例如互联网数据包交换 (Internetwork Packet Exchange，IPX)、AppleTalk 或 IPv6 本身。
link：链路，一种通信设施或介质，节点可以在链路层（即 IPv6 紧接的层）进行通信。例如以太网（简单或桥接）；PPP链路；X.25、帧中继或 ATM 网络；互联网层或更高层的“隧道”，例如 IPv4 或 IPv6 本身的隧道。
interface：接口，节点对链路的连接。
address：地址，一个接口或一组接口的 IPv6 层标识符。
packet：包，IPv6 报文头加上有效负载。数据包的大小可以小于或等于 PMTU。或者，这可以是一个更大的数据包，它被分成一系列分片，每个分片的大小小于或等于 PMTU。
link MTU：链路 MTU，最大传输单元，即以八位字节为单位的最大数据包大小，可以在一条链路上以一个分片的形式传送。
path：路径，数据包在源节点和目的节点之间经过的链路集合。
path MTU：路径 MTU，源节点和目的节点之间路径中所有链路的最小链路MTU。
PMTU：path MTU，路径 MTU。
Path MTU Discovery：路径 MTU 发现，节点学习路径的 PMTU 的过程。
EMTU_S：Effective MTU for sending，发送的有效 MTU；上层协议使用它来限制它们排队发送的 IP 数据包的大小 [RFC6691] [RFC1122]。
EMTU_R：Effective MTU for receiving，接收的有效 MTU；接收端可以重组的最大数据包[RFC1122]。
flow：流，从特定源发送到特定（单播或组播）目的地的数据包序列，源需要中间路由器对其进行特殊处理。
flow id：流标识，源地址和非零流标签的组合。
3、 协议概述
本备忘录描述了一种动态发现路径 PMTU 的技术。基本思想是源节点最初假设路径的 PMTU 是路径中第一跳的（已知）MTU。如果在该路径上发送的任何数据包太大而无法被路径上的某个节点转发，则该节点将丢弃它们并返回 ICMPv6 Packet Too Big 消息。接收到这样的消息后，源节点会根据 Packet Too Big 消息中报告的收缩跳的 MTU 减少其假定的路径 PMTU。减小的 PMTU 会导致源发送更小的数据包或更改 EMTU_S 以导致上层减小它发送的 IP 数据包的大小。
当源节点对 PMTU 的估计小于或等于实际 PMTU 时，路径 MTU 发现过程结束。请注意，在路径 MTU 发现过程结束之前，可能会发生数据包发送/数据包太大消息接收周期的多次迭代，因为可能存在沿路径更远的具有较小 MTU 的链路。
或者，节点可以选择通过停止发送大于 IPv6 最小链路 MTU 的数据包来结束发现过程。
由于路由拓扑的变化，路径的 PMTU 可能会随时间而变化。通过 Packet Too Big 消息检测 PMTU 的减少。为了检测路径 PMTU 的增加，节点周期性地增加其假定的 PMTU。这几乎总是会导致数据包被丢弃并生成 Packet Too Big 消息，因为在大多数情况下，路径的 PMTU 不会改变。因此，应该不经常尝试检测路径 PMTU 的增加。
路径 MTU 发现支持组播和单播目的地。在组播目的地的情况下，数据包的副本可能经过许多不同的路径到达许多不同的节点。每条路径可能有不同的 PMTU，单个组播数据包可能会导致多个 Packet Too Big 消息，每个消息都报告不同的下一跳 MTU。正在使用的一组路径中的最小 PMTU 值决定了发送到组播目的地的后续数据包的大小。
请注意，即使在节点“认为”目的地与自身连接到同一链路的情况下，也必须执行路径 MTU 发现，因为它的 PMTU 可能低于链路 MTU。在诸如相邻路由器充当某个目的地的代理 [ND] 的情况下，该目的地可能看起来是直接连接的，但实际上它不止一跳。
4、 协议要求
如第 1 节所述，IPv6 节点不需要实现路径 MTU 发现。本节中的要求仅适用于那些包括路径 MTU 发现的实现。
节点应适当地验证 ICMPv6 PTB 消息的有效负载，以确保收到这些消息以响应每个 [ICMPv6] 传输的流量（即，与应用程序实际发送的 IPv6 数据包相对应的报告错误条件）。
如果一个节点收到一个报文报告下一跳 MTU 小于 IPv6 最小链路 MTU 的 Packet Too Big 消息，它必须丢弃它。节点在收到 Packet Too Big 消息时，不得将其 Path MTU 估计值降低到 IPv6 最小链路 MTU 以下。
当一个节点接收到一个 Packet Too Big 消息时，它必须根据消息中 MTU 字段的值来减少其对相关路径的 PMTU 的估计。由于不同的应用程序可能有不同的要求，并且不同的实现架构可能有不同的策略，因此没有指定在这种情况下节点的精确行为。
在收到 Packet Too Big 消息后，节点必须尝试避免在不久的将来引发更多此类消息。节点必须减小它沿路径发送的数据包的大小。使用大于 IPv6 最小链路 MTU 的 PMTU 估计值可能会继续引发 Packet Too Big 消息。因为这些消息中的每一个（以及它们响应的丢弃数据包）都会消耗网络资源，所以使用路径 MTU 发现的节点必须尽快检测到 PMTU 的降低。
节点可能会检测到 PMTU 的增加，但因为这样做需要发送比当前估计的 PMTU 更大的数据包，并且因为 PMTU 很可能不会增加，所以必须以不频繁的间隔进行。在收到给定路径的 Packet Too Big 消息后 5 分钟内不得尝试检测增加（通过发送大于当前估计的数据包）。此计时器的推荐设置是其最小值（10 分钟）的两倍。
节点不得增加其对路径 MTU 的估计以响应 Packet Too Big 消息的内容。声称增加路径 MTU 的消息可能是在网络中漂浮的陈旧数据包、作为拒绝服务 (denial-of-service，DoS) 攻击的一部分注入的虚假数据包，或者是具有多个路径的结果到目的地，每个都有不同的 PMTU。
5、 实施问题
本节讨论与实现路径 MTU 发现相关的一些问题。这不是一个规范，而是为实施者提供的一组注释。
这些问题包括：
- 哪些层或哪些层实现路径 MTU 发现？
- PMTU 信息是如何缓存的？
- 如何删除陈旧的 PMTU 信息？
- 传输层和更高层必须做什么？
5.1、 分层
在 IP 架构中，选择发送什么大小的数据包是由 IP 上一层的协议决定的。本备忘录将这样的协议称为“分组协议”。分组协议通常是传输协议（例如 TCP），但也可以是高层协议（例如，建立在 UDP 之上的协议）。
在分组层实现路径 MTU 发现简化了一些层间问题，但有几个缺点：可能必须为每个分组协议重做实现，在不同分组层之间共享 PMTU 信息变得困难，以及面向连接的某些分组层维护的状态可能不容易扩展以长时间保存 PMTU 信息。
因此建议 IP 层存储 PMTU 信息，并且 ICMPv6 层进程接收 Packet Too Big 消息。分组层可以通过改变它们发送的消息的大小来响应 PMTU 的变化。为了支持这种分层，分组层需要一种方法来了解 MMS_S 值的变化，即“最大发送传输消息大小”[RFC1122]。
MMS_S 是通过从可以发送的最大 IP 数据包 EMTU_S 中减去 IPv6 报文头（包括 IPv6 扩展报文头）的大小来计算的传输消息大小。MMS_S 受到多种因素的限制，包括 PMTU、对数据包分片和重组的支持以及数据包重组限制（参见 [RFC8200] 的第 4.5 节“分片头”）。当源分片可用时，EMTU_S 设置为 EMTU_R，由接收器使用上层协议或基于协议要求（IPv6 为 1500 个八位字节）指示。当要传输大于 PMTU 的消息时，源会创建分片，每个分片都受 PMTU 限制。当不需要源分片时，EMTU_S 设置为 PMTU，并且上层协议预计要么执行自己的分片和重组，要么相应地限制其消息的大小。
但是，鼓励分组层避免发送需要源分片的消息（关于反对分片的情况，请参阅 [FRAG]）。
5.2、 存储 PMTU 信息
理想情况下，PMTU 值应该与源节点和目标节点之间交换的数据包所经过的特定路径相链路。然而，在大多数情况下，节点将没有足够的信息来完全准确地识别这样的路径。相反，节点必须将 PMTU 值与路径的某些本地表示相链路。选择路径的本地表示留给实现。对于具有多个接口的节点，应为每个 IPv6 链路维护路径 MTU 信息。
在组播目标地址的情况下，数据包的副本可能会经过许多不同的路径到达许多不同的节点。到组播目的地的“路径”的本地表示必须代表一组潜在的大路径。
最低限度，一个实现可以维护一个单一的 PMTU 值，用于来自该节点的所有数据包。该 PMTU 值将是节点使用的所有路径集合中获知的最小 PMTU。这种方法可能会导致使用比许多路径所需的更小的数据包。在多路径路由（例如，等价多路径路由 (Equal-Cost Multipath Routing，ECMP)）的情况下，即使对于单个源和目标对，也可以存在一组路径。
实现可以使用目标地址作为路径的本地表示。与目的地相链路的 PMTU 值将是通过到该目的地使用的所有路径的集合中获知的最小 PMTU。这种方法将导致在每个目的地的基础上使用最佳大小的数据包。这种方法与 [ND] 中描述的主机概念模型很好地集成：PMTU 值可以与目标缓存中的相应条目一起存储。
如果流 [RFC8200] 正在使用中，则实现可以使用流 id 作为路径的本地表示。发送到特定目的地但属于不同流的数据包可能使用不同的路径，例如 ECMP，其中路径的选择可能取决于流 ID。这种方法可能会导致基于每个流使用最佳大小的数据包，提供比基于每个目标维护的 PMTU 值更精细的粒度。
对于源路由数据包（即包含 IPv6 路由报文头 [RFC8200] 的数据包），源路由可以进一步限定路径的本地表示。
最初，假设路径的 PMTU 值是第一跳链路的（已知）MTU。
当收到 Packet Too Big 消息时，节点根据 Packet Too Big 消息的内容确定该消息适用于哪个路径。例如，如果目标地址用作路径的本地表示，则原始数据包中的目标地址将用于确定消息适用于哪个路径。
注意：如果原始数据包包含路由报文头，则应使用路由报文头来确定原始数据包中目标地址的位置。如果 Segments Left 等于 0，则目标地址位于 IPv6 报文头的目标地址字段中。如果 Segments Left 大于零，则目标地址是 Routing 报文头中的最后一个地址 (Address[n])。
然后，节点使用 Packet Too Big 消息中 MTU 字分片中的值作为暂定 PMTU 值或 IPv6 最小链路 MTU（如果该值较大），并将暂定 PMTU 与现有 PMTU 进行比较。如果暂定 PMTU 小于现有 PMTU 估计值，则暂定 PMTU 替换现有 PMTU 作为路径的 PMTU 值。
必须通知分组层有关 PMTU 的减少。如果 PMTU 估计值降低，则必须通知正在使用该路径的任何分组层实例（例如 TCP 连接）。
注意：即使 Packet Too Big 消息包含引用 UDP 数据包的 Original Packet Header，如果其任何连接使用给定路径，则必须通知 TCP 层。
此外，发送引发 Packet Too Big 消息的数据包的实例应该被通知它的数据包已被丢弃，即使 PMTU 估计没有改变，以便它可以重新传输丢弃的数据。
注意：实现可以通过将通知推迟到下一次尝试发送大于 PMTU 估计值的数据包来避免使用异步通知机制来降低 PMTU。在这种方法中，当尝试发送一个大于 PMTU 估计值的数据包时，SEND 函数应该失败并返回一个合适的错误指示。这种方法可能更适合无连接分组层（例如使用 UDP 的层），这（在某些实现中）可能难以从 ICMPv6 层“通知”。在这种情况下，将使用正常的基于超时的重传机制从丢弃的数据包中恢复。
重要的是要理解，使用有关 PMTU 更改的路径的分组层实例的通知不同于包已被丢弃的特定实例的通知。后者应该尽快完成（即，从分组层实例的角度来看是异步的），而前者可能会延迟到分组层实例想要创建一个数据包。
5.3、 清除陈旧的 PMTU 信息
互联网络拓扑是动态的；路由随时间变化。虽然路径的本地表示可能保持不变，但实际使用的路径可能会发生变化。因此，节点缓存的 PMTU 信息可能会变得陈旧。
如果过时的 PMTU 值太大，一旦在路径上发送了足够大的数据包，就会立即发现这一点。不存在这样的机制来实现过时的 PMTU 值太小，因此实现应该“老化”缓存值。当 PMTU 值有一段时间（大约 10 分钟）没有减小时，它应该探测以查找是否支持更大的 PMTU。
注意：实现应提供更改超时持续时间的方法，包括将其设置为“无限”。例如，连接到具有大 MTU 的链路的节点，然后通过具有小 MTU 的链路连接到 Internet 的其余部分，永远不会发现新的非本地 PMTU，因此它们不必忍受每 10 分钟丢包一次。
5.4、 分组层操作
分组层（例如 TCP）必须将 PMTU 用于连接使用的路径；它不应发送会导致数据包大于 PMTU 的分片，除非在 PMTU 发现期间进行探测（此探测数据包不得分片到 PMTU）。一个简单的实现可以在每次创建新分片时向 IP 层询问该值，但这可能效率低下。实现通常缓存从 PMTU 派生的其他值。当 PMTU 改变时接收异步通知可能更简单，因此这些变量也可以更新。
TCP 实现还必须存储从其对等方接收到的最大分片大小 (Maximum Segment Size，MSS) 值，该值表示 EMTU_R，接收方可以重组的最大数据包，并且不得发送任何大于此 MSS 的分片，无论 PMTU是多少。
TCP MSS 选项中发送的值与 PMTU 无关；它由接收器重组限制 EMTU_R 确定。此 MSS 选项值由连接的另一端使用，它可能正在使用不相关的 PMTU 值。有关选择 TCP MSS 选项值的信息，请参见 [RFC8200] 的第 5 节“数据包大小问题”和第 8.3 节“最大上层有效负载大小”。
收到 Packet Too Big 消息意味着发送 ICMPv6 消息的节点丢弃了一个数据包。一个可靠的上层协议会通过自己的方式检测到这种丢失，并通过其正常的重传方法来恢复它。重传可能会导致延迟，这取决于上层协议使用的丢失检测方法。如果路径 MTU 发现过程需要几个步骤来找到完整路径的 PMTU，这最终可能会使重传延迟许多往返时间。
或者，可以立即响应路径 MTU 减少的通知进行重传，但仅针对 Packet Too Big 消息指定的特定连接。重传中使用的数据包大小不应大于新的 PMTU。
注意：确定探测包丢失的分组层需要调整重传的分片大小。然而，使用最后一个 Packet Too Big 消息中报告的大小可能会导致进一步的丢失，因为沿路径更远的路由器可能存在较小的 PMTU 限制。这将导致丢失所有重新传输的分片，从而导致不必要的拥塞以及每次新路由器宣布较小的 MTU 时要发送的额外数据包。因此，任何使用重传的分组层也负责其重传的拥塞控制[RFC8085]。
由接收到 Packet Too Big 消息指示的 PMTU 探测导致的丢失不能被视为拥塞通知，因此拥塞窗口可能不会改变。
5.5、 其他传输协议的问题
某些传输协议在进行重传时不允许重新分组。也就是说，一旦尝试传输某个大小的分片，传输就无法将该分片的内容拆分为更小的分片以进行重传。在这种情况下，原始分片可以在重传期间被 IP 层分片。第一次传输的后续分片不应大于路径 MTU 允许的大小。
IPv4 的路径 MTU 发现 [RFC1191] 使用 NFS 作为受益于 PMTU 发现的基于 UDP 的应用程序的示例。从那时起，[RFC7530] 声明 NFS 和 IP 之间支持的传输层必须是 IETF 标准化传输协议，该协议被指定以避免网络拥塞；此类传输包括 TCP、流控制传输协议 (Stream Control Transmission Protocol，SCTP) [RFC4960] 和数据报拥塞控制协议 (Datagram Congestion Control Protocol，DCCP) [RFC4340]。在这种情况下，传输负责确保传输的分片（探测除外）符合路径 MTU，包括根据需要支持 PMTU 发现探测传输。
5.6、 管理接口
建议实现为系统实用程序提供一种方法：
- 指定不在给定路径上进行路径 MTU 发现。
- 更改与给定路径链路的 PMTU 值。
前者可以通过将标志与路径相链路来完成；当在设置了此标志的路径上发送数据包时，IP 层不会发送大于 IPv6 最小链路 MTU 的数据包。
这些功能可用于解决异常情况或由能够获得路径 MTU 值的路由协议实现使用。
该实现还应提供一种方法来更改老化的陈旧 PMTU 信息的超时期限。
6、 安全考虑
这种路径 MTU 发现机制使两种 DoS 攻击成为可能，两种攻击都基于恶意方向节点发送错误的 Packet Too Big 消息。
在第一次攻击中，虚假消息表明 PMTU 比实际小得多。作为响应，受害节点不应将其 PMTU 估计值设置为低于 IPv6 最小链路 MTU。错误地减少到此 MTU 的发送方将观察到次优性能。
在第二次攻击中，虚假消息表明 PMTU 大于现实。如果相信，这可能会导致临时阻塞，因为受害者发送的数据包将被某些路由器丢弃。在一个往返时间内，节点会发现它的错误（从该路由器接收到 Packet Too Big 消息），但这种攻击的频繁重复可能会导致大量数据包被丢弃。但是，节点不得根据 Packet Too Big 消息提高其对 PMTU 的估计，因此它不应该容易受到这种攻击。
这两种攻击都可能导致黑洞连接，即TCP三次握手正确完成，但在传输数据时连接挂起。
如果恶意方可以阻止受害者接收合法的 Packet Too Big 消息，也可能会导致问题，但在这种情况下，可以使用更简单的 DoS 攻击。
如果 ICMPv6 过滤阻止接收 ICMPv6 Packet Too Big 消息，则源将无法获知实际路径 MTU。“分组层路径 MTU 发现”[RFC4821] 不依赖网络对 ICMPv6 消息的支持，因此被认为比标准 PMTUD 更健壮。它不易受到 ICMPv6 消息过滤引起的“黑洞”连接的影响。有关过滤 ICMPv6 消息的建议，请参阅 [RFC4890]。
7、 IANA 考虑因素
本文档不需要任何 IANA 操作。
8、 参考文献
8.1、 规范性参考
[ICMPv6] Conta, A., Deering, S., and M. Gupta, Ed., "Internet Control Message Protocol (ICMPv6) for the Internet Protocol Version 6 (IPv6) Specification", STD 89, RFC 4443, DOI 10.17487/RFC4443, March 2006, <http://www.rfc-editor.org/info/rfc4443>. [RFC8200] Deering, S. and R. Hinden, "Internet Protocol, Version 6 (IPv6) Specification", STD 86, RFC 8200, DOI 10.17487/RFC8200, July 2017, <http://www.rfc-editor.org/info/rfc8200>.
8.2、 参考资料
[FRAG] Kent, C. and J. Mogul, "Fragmentation Considered Harmful", In Proc. SIGCOMM '87 Workshop on Frontiers in Computer Communications Technology, DOI 10.1145/55483.55524, August 1987. [ND] Narten, T., Nordmark, E., Simpson, W., and H. Soliman, "Neighbor Discovery for IP version 6 (IPv6)", RFC 4861, DOI 10.17487/RFC4861, September 2007, <http://www.rfc-editor.org/info/rfc4861>. [RFC1122] Braden, R., Ed., "Requirements for Internet Hosts - Communication Layers", STD 3, RFC 1122, DOI 10.17487/RFC1122, October 1989, <http://www.rfc-editor.org/info/rfc1122>. [RFC1191] Mogul, J. and S. Deering, "Path MTU discovery", RFC 1191, DOI 10.17487/RFC1191, November 1990, <http://www.rfc-editor.org/info/rfc1191>. [RFC1981] McCann, J., Deering, S., and J. Mogul, "Path MTU Discovery for IP version 6", RFC 1981, DOI 10.17487/RFC1981, August 1996, <http://www.rfc-editor.org/info/rfc1981>. [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, <http://www.rfc-editor.org/info/rfc2119>. [RFC2923] Lahey, K., "TCP Problems with Path MTU Discovery", RFC 2923, DOI 10.17487/RFC2923, September 2000, <http://www.rfc-editor.org/info/rfc2923>. [RFC4340] Kohler, E., Handley, M., and S. Floyd, "Datagram Congestion Control Protocol (DCCP)", RFC 4340, DOI 10.17487/RFC4340, March 2006, <http://www.rfc-editor.org/info/rfc4340>. [RFC4821] Mathis, M. and J. Heffner, "Packetization Layer Path MTU Discovery", RFC 4821, DOI 10.17487/RFC4821, March 2007, <http://www.rfc-editor.org/info/rfc4821>. [RFC4890] Davies, E. and J. Mohacsi, "Recommendations for Filtering ICMPv6 Messages in Firewalls", RFC 4890, DOI 10.17487/RFC4890, May 2007, <http://www.rfc-editor.org/info/rfc4890>. [RFC4960] Stewart, R., Ed., "Stream Control Transmission Protocol", RFC 4960, DOI 10.17487/RFC4960, September 2007, <http://www.rfc-editor.org/info/rfc4960>. [RFC6691] Borman, D., "TCP Options and Maximum Segment Size (MSS)", RFC 6691, DOI 10.17487/RFC6691, July 2012, <http://www.rfc-editor.org/info/rfc6691>. [RFC7530] Haynes, T., Ed. and D. Noveck, Ed., "Network File System (NFS) Version 4 Protocol", RFC 7530, DOI 10.17487/RFC7530, March 2015, <http://www.rfc-editor.org/info/rfc7530>. [RFC8085] Eggert, L., Fairhurst, G., and G. Shepherd, "UDP Usage Guidelines", BCP 145, RFC 8085, DOI 10.17487/RFC8085, March 2017, <http://www.rfc-editor.org/info/rfc8085>.
附录 A、 与 RFC 1191 的比较
RFC 1981（被本文档废弃）在很大程度上基于 RFC 1191，它描述了 IPv4 的路径 MTU 发现。RFC 1981 中不需要 RFC 1191 的某些部分：
router specification：路由器规范，Packet Too Big 消息和相应的路由器行为在 [ICMPv6] 中定义
Don't Fragment bit：不要分片位，IPv6 数据包中没有 DF 位
TCP MSS discussion：TCP MSS 讨论，在 [RFC8200] 中讨论了在 TCP MSS 选项中选择要发送的值
old-style messages：旧式消息，所有 Packet Too Big 消息都报告限制链路的 MTU
MTU plateau tables：MTU 历史表，不需要，因为没有旧式消息
附录 B、 自 RFC 1981 以来的更改
本文档基于 RFC 1981，与 RFC 1981 相比有以下更改：
** 在第 1 节“简介”中阐明，PMTUD 的目的是减少对 IPv6 分片的需求。
** 在第 1 节“简介”中添加了有关 ICMPv6 消息被阻止时对 PMTUD 的影响的文本。
** 在文档介绍中添加了“注释”，说明本规范未引用 RFC 2119，仅使用小写“应该/必须”语言。将所有大写“应该/必须”更改为小写。
** 在第 1 节“简介”中添加了关于 PLPMTUD 的简短摘要以及对定义它的 RFC 4821 的引用。
** 对齐第 2 节“术语”中的文本，以匹配当前的分组层术语。
** 在第 4 节“协议要求”中添加了说明，即节点应根据 RFC 4443 验证 ICMP PTB 消息的有效负载，并且节点应尽快检测 PMTU 的降低。
** 从第 4 节“协议要求”中删除了一个“注释”，该注释是关于报告下一跳 MTU 小于 IPv6 最小链路 MTU 的 Packet Too Big 消息，因为这已从 [RFC8200] 中删除。
** 在第 5.2 节“存储 PMTU 信息”中添加了说明，如果 ICMPv6 Packet Too Big 消息包含的 MTU 小于 IPv6 最小链路 MTU，则该消息将被丢弃。
** 在第 5.2 节“存储 PMTU 信息”中添加了说明，即对于具有多个接口的节点，应为每个链路存储路径 MTU 信息。
** 删除了第 5.2 节“存储 PMTU 信息”中关于路由报文头类型 0 (Routing Header type 0，RH0) 的文本，因为它已被 RFC 5095 弃用。
** 从第 5.2 节“存储 PMTU 信息”中删除了有关过时安全分类的文本。
** 将第 5.4 节的标题更改为“分组层操作”，并更改了第一段中的文本以概括本节以涵盖所有分组层，而不仅仅是 TCP。
** 澄清第 5.4 节“分组层操作”中的文本，以使用正常的分组层重传方法。
** 删除了第 5.4 节“分组层操作”中描述 4.2 BSD 的文本，因为它已过时，并删除了对 TP4 的引用。
** 更新了第 5.5 节“其他传输协议的问题”中关于 NFS 的文本，包括添加对 NFS 的当前引用和删除过时的文本。
** 在第 6 节“安全注意事项”中添加了一段，关于未收到 PTB 消息时的黑洞连接以及与 PLPMTUD 的比较。
** 更新了“致谢”。
** 编辑更改。
致谢
我们要感谢 [RFC1191] 的作者和贡献者，本文档的大部分内容来自该文档。我们还要感谢 IPng 工作组成员的仔细审查和建设性的批评。
我们还要感谢本次“IPV6 的路径 MTU 发现”更新的贡献者。这包括 6MAN 工作组的成员、地区董事会审查员、IESG，尤其是 Joe Touch 和 Gorry Fairhurst。
