1.简介
当一台IP主机有大量的数据要发送给另一台主机的时候，数据是作为一系列的IP数据报传输。数据报最好具有在从源点到目的点的路径上不需要分片的最大尺寸。（避免分片的情况，见[5]。）这种数据报的尺寸称作为路径MTU（PMTU）,它等于路径上每一跳的MTU之中的最小值。当前因特网协议族的缺点就是对一台主机来说缺乏发现任意一条路径的PMTU的标准机制。
注重：路径MTU在[1]中被称作为“用于发送的有效MTU"(EMTU_S).
PMTU与一条路径相关，路径是IP的源地址、目的地址，也许还有
服务类型（TOS）的特定组合。
当前实际[1]采用的是576和第一跳MTU中的较小者作为任何不与源地址网络或者子网直接相连的目的地址的PMTU。在许多情况下，这导致了使用比必须要求小的数据报，因为许多路径的PMTU比576大。一台主机发送比路径MTU小的多的数据报是浪费因特网的资源，达不到最优的吞吐量。而且，当前的实现在所有的情况下不防止分片，因为一些路径的MTU比576小。
期望未来的路由协议将能够在一个路径区域中提供准确的PMTU信息，尽管也许不能越过多级路由层次。还要多久这种未来的路由协议才能广泛应用现在还不清楚。所以在以后的几年中，因特网在所有主机和路由器被修改前为了不浪费资源需要一种简单的发现PMTU的机制。
2.协议概览
在此备忘录中，我们描述了一种技术，在IP首部使用不分片(DF)比特位动态发现一条路径的PMTU。基本思想就是源主机开始假定一条路径的PMTU是它的（已知的）第一跳的MTU，在这条路径上发送的数据报都设置DF比特位。假如有的数据报太大，不被路径中的某些路由器分片就不能转发，那么路由器将丢弃这些数据报，然后返回一个意思为“需要分片，设置了DF位[7]”的ICMP目的不可达报文。在收到这样一条报文后（以后称它为“数据报太大”报文），源主机减小它假定的这条路径的PMTU。
当主机对PMTU的估计值小到它的数据报不需要分片也能转发的时候，PMTU发现过程结束。或者，主机可以选择停止在数据报首部中设置DF比特位来结束发现过程；它可能会这样做，例如主机想在某些情况下让数据报分片。通常，主机继续在所有的数据报中设置DF，这是为了假如路由改变并且新的PMTU减小的时候，将会被发现。
不幸的是，当前指定的数据报太大报文不报告拒绝太大数据报的那一跳的MTU。所以源主机不能准确地判定把它假设的PMTU减小多少。为了弥补这个缺点，我们建议使用当前在数据报太大报文中没有使用的一个报头字段来报告减小的那一跳的MTU。这是支持PMTU发现的路由器唯一被指定的改变。
路径的PMTU可能随着时间而改变，因为路由的拓扑结构可能改变。PMTU的减小通过数据报太大报文被检测到，除非主机停止设置沿此路径的数据报的DF比特位。为了检测路径的PMTU值的增加，主机周期地增加它假定的PMTU（假如它已经停止，再重新设置DF比特位）。这几乎总是导致数据报被丢弃，数据报太大报文产生，因为在大多数情况下，路径的PMTU不会改变，所以不应该频繁地做这种工作。
因为这种机制本质上保证了主机接收不到来自另一台进行PMTU发现的对等者的分片，它可能对与某个不能重新装配分片的数据报的主机进行互操作有帮助。
3,主机规范
当主机收到一个数据报太大报文时，它必须基于此报文中的下一跳MTU字段中的值（见第四节），减少对相关路径的PMTU估计值。因为不同的应用程序有不同的需要，不同的实现体系倾向于不同的策略，所以我们不能在这种情况下指定确定的行为。
我们要求在收到数据报太大报文后，主机必须尽量去避免在最近一段时间再引出这样的报文。主机可以减小沿着这条路径发送的数据报的尺寸，或者在这些数据报首部停止设置不分段比特位。显然，前一种策略在一段时间内可能继续导致产生数据报太大报文，但是因为这些报文中任何一个（和它们所响应的被丢弃的数据报）都消耗因特网的资源，主机必须强迫PMTU发现过程汇聚。
使用PMTU发现的主机一定要尽可能快地检测到路径MTU的减少。主机可以检测到路径MTU的增加，但是，因为这样做需要发送比当前估计的PMTU大的数据报，而且PMTU很可能不增加，所以这种工作一定不要频繁地做。检测一个增加的尝试（通过发送一个比当前估计值大的数据报）一定不要在数据报太大报文收到后5分钟内做，或者在前一个成功的增加尝试之后1分钟内做。我们建议把计时器设置为它们最小值的两倍（分别为10分钟和2分钟）。
主机必须能够处理不包括下一跳MTU的数据报太大报文，因为不可能在有限的时间内升级因特网中的所有路由器。来自一个没有修改的路由器的数据报太大报文中的下一跳MTU字段（新定义的）中的值为0（这对于ICMP规范[7]是必需的，ICMP规范要求“未使用”字段必须要是0）。在第五节中，我们讨论响应老式的数据报太大报文（由一个没有修改的路由器发出）的主机可能遵守的策略。
主机一定不要使对路径MTU的估计值低于68字节。
主机一定不能增加它对路径MTU的估计值来响应数据报太大报文的内容。一个通告路径MTU增加的报文可能是一个在因特网中飘移的过时的数据报，一个作为服务拒绝攻击一部分的虚假的数据报，或者是由于到目的地址有多条路径造成的结果。
3.1TCPMSS选项
作PMTU发现的主机一定要遵守不发送大于576字节的IP数据报的规则，除非它具有接收者的许可。对于TCP连接来说，这意味着主机一定不能发送大于40字节加上它的对等者发来的最大段尺寸（MSS）的数据报。
注重：TCPMSS被定义为相关的IP数据报尺寸减40[9]。最大IP数据报尺寸的默认值576将导致TCPMSS的默认值是536字节。
"RequirementsforInternetHosts--CommunicationLayers"[1]的4.2.2.6节中陈述了：
一些TCP实现只有当目的主机在一个非直接连接网络上才发送MSS选项。但是，通常TCP层不可能有适当地信息来作出这种决定，所有它更愿意把决定因特网路径合适的MTU的工作留给IP层来完成。
实际上，很多TCP实现总是发送MSS选项，但是，假如目的地不是本地的，把值设置为536。当因特网中布满了不遵守超过576字节的数据报不发给非本地的目的地址规则的主机的时候，这种行为是正确的。现在大多数主机遵守这个规则，所以对非本地的对等者来说也不必把TCPMSS选项的值限制为536。
而且，这样做防止发现超过576的PMTU，所以，主机应该不再减少它们在MSS选项中发送的值。MSS选项应该比主机能够重组的最大数据报（MSS_R,在[1]中定义）的尺寸小40字节；在许多情况下，这将有65495(65535-40)字节结构上的限制。主机可能发送从它连接网络上的MTU（对一个多宿主主机来说，是在它所有连接网络中的最大MTU）得到的MSS值；这应该不会对PMTU发现造成问题，可以阻止一个损坏的对等者发送巨大的数据报。
注重：这时，我们没有看到发送比连接的网络最大的MTU还要大的MSS的原因。我们建议主机不使用65495。因为一些IP实现可能有负比特位的错误，这种错误在在没有必要使用这么大的MSS的时候被触发。
4.路由器规范
路由器不能转发数据报，是因为数据报超过了下一跳网络的MTU并且它的不分段比特位被设置，路由器需要给数据报的源地址返回一个ICMP的目的不可达报文，此报文带有表示“需要分段，设置了DF位”的代码。为了支持在此备忘录中说明的路径MTU发现技术，路由器必须在ICMP首部字段中低序的16bit中包含下一跳网络的MTU，这个字段在ICMP规范[7]中被标记为“未使用”。高序的16bit保持未用，必须设置为0。因此，报文具有下面的格式：
0123
01234567890123456789012345678901
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
类型=3代码=4校验和
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
未使用=0下一跳MTU
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Internet首部+原始数据报中的前64bit
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
在下一跳MTU字段中的值是：
沿着原始数据报的路径，在此路由器上不需分段能够转发的最大数据报的用字节表示的尺寸，这个尺寸包含IP首部和IP数据，不包含任何低层的首部。
这个字段不会包含小于68字节的值，因为每一个路由器都“必须不分段转发68字节的数据报”[8]。
5.主机对老式报文的处理
在这一节中，我们概述几种主机接收来自没有修改的路由器所发出的数据报太大报文（即，下一跳的MTU字段为0的数据报太大报文）所遵守的策略。这一节不是协议规范的一部分。
主机响应这种报文所作的最简单的事就是假定PMTU是当前假定的PMTU和576之中的最小值，和停止设置在这条路径上发送的数据报的DF比特位。这样，主机会得到和当前实现中选择的相同的PMTU（见"RequirementsforInternetHosts--CommunicationLayers"[1]的3.3.3节）。这种策略的优点就是它终止很快，不差于现存的其他实现。它的缺点就是在一些情况下避免分段失败，在另一些情况不能最有效利用因特网。
更先进复杂的策略包含对一个精确PMTU估计值的“搜索”，当改变它们的尺寸时，继续发送带有DF比特位的数据报。一个好的搜索策略在执行过程中不必产生很多被丢弃的包就可以得到正确的路径MTU估计值。
一些可能的策略采用前一次估计PMTU的算法函数来产生一个新的估计值。例如，可以用一个常数（比如说，0.75）来乘旧的估计值，得到一个新的估计值。我们不推荐使用这种方法；它要么汇聚的太慢，要么则过多地低估了真正的PMTU。
一个更高级的方法是在包尺寸上作二进制搜索。这种方法汇聚得快了一些，尽管如此，它从FDDIMTU汇聚到以太网MTU仍然需要4至5步。一个严重的缺点就是当数据报到另一端的时候（指出当前的估计值太小）为了识别它需要一个复杂的实现。我们也不推荐使用这种方法。
从观察中发现有一种策略工作的相当好，实际上，相对较少的值使用在因特网中。因此，与其盲目搜索任意选择的值，不如只搜索那些可能出现的值。而且，因为设计者倾向于用相似的方法选择MTU，所以，可能收集到成组的相似的MTU值，使用组中的最小值作为“参考点”。（显然，低估MTU的百分之几比高估MTU甚至一个字节也要好）。
在第七节，我们描述了怎样使用在PMTU估计中有代表性的MTU参考点的表。使用这张表，在最坏情况下汇聚也与二进制搜索一样好，在普通的情况下则更好（例如，只花费两次往返的时间就从FDDIMTU到了以太网MTU）。因为参考点位于接近2的次幂的地方，所以假如一个MTU在表中没有描述，这个算法也不会低估它超过一个2的因数。
为了选择下一个值，任何搜索策略都必须记住以前的估计值。一种方法就是使用当前缓冲区来保存路径MTU的估计值，但是，实际上在数据报太大报文本身也包含较好的可用信息。所有ICMP目的不可达报文，包括这一种报文，都包含着原始数据报的IP首部，此IP首部包含着这个太大的不能分片转发的数据报的长度。因为总长度可能比当前估计的PMTU小，但是比实际的PMTU大，它对于选择下一个PMTU估计值的方法来说可能是一个好的输入。
注重：基于源自4.2BSDUnix实现的路由器对于原始IP数据报的总长度发送一个不正确的值。这些路由器发送的值是原始总长度与原始首部长度的总和（用字节表示）。因为收到数据报太大报文的主机不可能知道报文是否是由这种路由器中的一个发出的，所以主机必须保守的假定它是的。假如返回的总长字段不小于当前PMTU估计值，它必须减去返回的首部长度字段值的4倍
我们推荐的策略是使用小于返回总长字段的最大的参考值来作为下一个PMTU的估计值（假如必要，根据上面的注重事项进行修改）。
6.主机实现
在这一节中，我们讨论PMTU发现怎样在主机软件中实现。这不是一个规范，而是一组建议。
要点包括：
－PMTU发现实现在哪一层或者哪几层？
－PMTU信息缓存在哪里？
－陈旧的PMTU信息怎样被删除？
－传输层和更高层必须做什么？
6.1分层
在IP体系中，选择发送数据报的尺寸在IP层上层的协议执行。我们把这样一种协议称作“打包协议”。打包协议通常是传输层协议（例如TCP）,但是也可能是更高层的协议（例如，建立在UDP上层的协议）。
在打包层实现PMTU发现使层内部的一些问题简化，但是也有一些缺点：实现可能必须在每一个打包协议中再重做一遍，在不同的打包层之间很难共享PMTU信息，由一些打包层保持的面向连接的状态不轻易扩展来长时间的保存PMTU信息。
因此我们认为IP层应该存储PMTU信息，ICMP层应该处理收到的数据报太大报文。通过改变它们发送的数据报的尺寸，打包层必须仍然能够响应路径MTU的改变，也必须能确定设置了DF比特位的数据报被发送。我们不想IP层简单的在每一个包中都设置DF比特位，因为，打包层，也许是核心外部的UDP应用程序可能不能改变它的数据报的尺寸。包含有意分片的协议有时是成功的（NFS是最主要的例子），我们不想打破这种协议。
为了支持分层，打包层需要定义在[1]中的IP服务接口的扩展：
一种得知MMS_S值改变的方法是“最大发送传输层报文尺寸”，
它通过路径MTU减去最小IP首部尺寸得到。
6.2存储PMTU信息
通常，IP层应该与它从一条特定的路径获得的每一个PMTU值联系起来。一条路径是由一个源地址，一个目的地址和一个IP服务类型共同确定的。（一些实现不记录路径的源地址；这对于单宿主主机是可接受的，这种主机仅有一个可能的源地址。）
注重：一些路径可以通过不同的安全分类来进一步区分。
这种分类的详情超过了本备忘录的范围。
存储这些联合的明显的地方是在路由表的条目中作为一个字段。主机不会对每一个可能的目的地都有一个路由，但是对每一个活动的目的地都应该缓存一条主机路由。（必要的条件是需要处理ICMP重定向报文。）
当给主机路由不存在的主机发送第一个数据报的时候，一条路由从一组网络路由中或者从一组默认路由中选出。在路由条目中的PMTU字段应该被初始化为关联的第一跳数据链路的MTU，而且在PMTU发现过程中不再被改变（PMTU发现仅仅创建或者改变主机路由条目）。关联于最初选择路由的PMTU被假定为正确的，直到接收到数据报太大报文。
当收到一个数据报太大报文时，ICMP层为路径MTU决定一个新的估计值（要么来自包中的下一跳MTU中的非0值，或者使用第五节描述的方法）。假如这条路径的主机路由不存在，那么将创建一个（几乎就象主机ICMP重定向被处理一样；新的路由使用与当前路由一样的第一跳路由器）。假如与主机路由关联的PMTU估计值比新值高，那么此路由条目中的PMTU值将改变。
打包层必须被通知PMTU减小。任意正在使用这条路径的打包层实例（例如，TCP连接）必须在PMTU估计值减小的时候被通知。
注重：即使数据报太大报文包含一个引用UDP包的源数据报首部，假如有的TCP连接使用这条给定的路径，TCP层也必须被通知。
同样，发送引起数据报太大报文的数据报的实例应该被通知它的数据报已经被丢弃了，即使PMTU估计值没有改变。这是为了它可以重传丢弃的数据报。
注重：这种通知机制与ICMP源路由抑止提供的通知机制是类似的。在一些实现中（诸如源自4.2BSD的系统），现在存在的通知机制不能识别非凡的相关连接，所以，一个附加的机制是必要的。
作为选择，一种实现能够避免使用对于PMTU减小的异步通知机制，这种机制是通过延迟通知直到下一次尝试发送一个比PMTU估计值大的数据报。在这种方法中，当尝试发送一个带有DF比特位设置的数据报，并且这个数据报比PMTU估计值大，SEND函数会失败，返回一个适当的错误指示。这种方法可能更适合于非连接的打包层（例如使用UDP的打包层），它（在一些实现中）可能很难从ICMP层通报。在这种情况下，正常的基于超时的重传输机制被使用于从丢失的数据报中恢复。
应该知道打包层实例使用的PMTU改变路径的通知与包被丢弃的非凡通知有区别，了解这一点很重要。后者是比较实用的（即，从打包层实例的观点来看是异步的），而前者可能有延迟直到打包层实例想创建一个包。仅当已知包丢失，才应该重传，这由数据报太大报文指定。
6.3清除过时的PMTU信息
互联网网络拓扑结构是动态变化的；路由随着时间改变。假如新的路由开始被使用，对指定目的地已发现的PMTU可能是错误的。因此，在主机中缓存的PMTU信息可能变得过时。
因为使用PMTU发现的主机总是设置DF比特位，假如过时的PMTU值太大，一旦一个数据报被发送给指定的目的地，就会立即发现这种情况。认为过时的值太小的机制不存在，所以一个实现应该使缓冲值“变老”。当一个PMTU值一段时间内没有减少（在预订的10分钟内），PMTU估计值应该被设置为第一跳数据链路MTU，打包层应该被通知这种改变。这将导致完全的PMTU发现过程再次发生。
注重：实现应该提供改变超时持续时间的方法，包括设置它为“无限”。例如，连接在FDDI网络上的主机通过一条低速的串行线接入因特网将不会发现一个新的非本地的PMTU，所以它们不必忍受每十分钟丢弃数据报。
在响应PMTU估计值增长的时候，上层不必重传数据报。因为在响应丢弃数据报的指示的时候，增长从不发生。
一种实现PMTU老化的方法是在路由表条目中加入时间戳字段。这个字段初始化为一个“保留”值，表明PMTU从没改变过。当响应一个数据报太大报文，PMTU减少的时候，时间戳被设置为当前时间。
通过时间驱动的过程将立即处理路由表，对于时间戳不是“保留”并且比超时时间间隔老的条目：
－PMTU估计值被设置为第一跳的MTU。
－使用路由的打包层被通知这种增长。
假如主机路由被删除，PMTU估计值可能从路由表中消失；这可能发生在响应一个ICMP重定向报文的情况中，或者因为某些路由表守护程序在几分钟后删除了旧的路由。在一个多宿主主机上拓扑改变也可能导致使用不同的源接口。当这种情况发生，假如打包层没有被通知，那么它可能继续使用对现在来说太小的缓冲PMTU值。一种解决方法就是当重定向报文导致路由改变和路由从路由表中删除时通知打包层PMTU可能改变。
注重：检测PMTU增长的更高级复杂的方法在7.1节中描述。
6.4TCP层的行为
TCP层必须追踪连接到目的地的PMTU；不应该发送比它还大的数据报。一个简单的实现可能在每次创建一个新的段的时候，向IP层请求这个值（使用在[1]中描述的GET_MAXSIZES接口），但是这种方法效率不高。而且遵守“慢启动”避免阻塞算法[4]的TCP实现计算和缓存从PMTU得到的一些其它的值。当PMTU改变的时候接收异步的通知较为简单，以至于这些变量可以更新。
TCP实现也必须存储从它的对等者那里接收的MSS值（默认为536），不发送任何比MSS大的段，而不管PMTU的值是多少。在源自4.xBSD的实现中，这需要加入一个附加的字段给TCP状态记录。
最后，当收到数据报太大报文的时候，这意味着一个数据报被发送这个ICMP报文的路由器丢弃。把它作为任意其它种类被丢弃的段，等待重传计时器期满导致这个段重传，这样的行为就足够了。假如PMTU发现过程需要一些步骤来估计正确的PMTU，这可能因为要往返许多次数据报而造成连接延迟。
作为选择，重传可以在对路径MTU已改变的通知立即响应时发生，但是这仅仅对于由数据报太大报文指定的特定连接。使用在重传中的数据报尺寸当然应该没有新的PMTU大。
注重：在响应每一个数据报太大报文的时候一定不要重传相同大小的段，因为特大型的段的突发将造成这样的报文，所以会重传同样的数据。假如新估计的PMTU值仍然错误，这个过程重复，送的多余段的数量将成几何级增长。
这意味着当数据报太大通知实际上减少已经使用在给定的连接中发送数据报的PMTU时，TCP层必须能够识别，并且忽略任何其它的通知。
现代的TCP实现把“避免阻塞”和“慢启动”算法结合起来提高性能[4]。不象由TCP重传超时导致的重传，由数据报太大报文导致的重传不应该改变拥塞窗口。然而，它应该触发慢启动机制（即，只有一个段将被重传直到确认开始到达）。
假如发送者最大窗口的尺寸不是使用中段尺寸的准确的倍数（这不是拥塞窗口尺寸，它总是段尺寸的倍数），TCP性能可能降低。在许多系统中（诸如从4.2BSD中发展的系统），段尺寸总是设置为1024字节，最大窗口尺寸（“发送空间”）总是1024字节的倍数，所以，这种适当的关系保持为默认。然而，假如PMTU发现被使用，段尺寸可能不是发送空间的约数，而且它可能在连接中改变；这意味着当PMTU发现改变PMTU值时，TCP层可能需要改变传输窗口尺寸。最大窗口尺寸应该被设置为小于或等于发送者缓冲区空间尺寸的段尺寸(PMTU-40)的最大倍数。
PMTU发现不影响在TCPMSS选项中发送的值，因为这个值用在连接的另一端，它可能使用一个不相关的PMTU值。
6.5其它传输协议的问题
一些传输层协议（例如ISOTP4[3]）在重传的时候，不答应重新打包。也就是说，一旦试图传输某种尺寸的数据报，它的内容就不能分成较小的数据报重传。在这种情况下，原始数据报应该不设置DF比特位重传，答应它作必要的分段来到达它的目的地。当第一次传输的时候，后来的数据报应该没有路径MTU答应值大，并且应该设置DF比特位。
在许多情况下，Sun网络文件系统（NFS）使用远程过程调用（RPC）协议[11]发送必须分段的数据报，甚至对第一跳链路也是如此。在某些情况下，这可能提高性能，但是众所周知它也导致可靠性和性能的问题，尤其是当客户端和服务器被路由器分开的时候。
当涉及到路由器的时候，我们建议NFS实现使用PMTU发现。大多数NFS实现答应在安装的时候改变RPC数据报尺寸（间接的，通过改变有效文件系统块尺寸），但是可能需要一些修改来支持以后的改变。
而且，因为一个单一的NFS操作不能分开成一些UDP数据报，某些操作（主要是在文件名和目录上的操作）需要可能比PMTU大的最小数据报的尺寸。NFS实现不应该减少数据报的尺寸小于这个极限值，即使PMTU发现建议了一个较小的值。（当然，在这种情况下数据报发送时不应该再设置DF比特位。）
6.6治理接口
我们建议实现提供一种适合于系统公用程序的方法：
-确定在给定的路由上没有使用PMTU发现。
-改变与给定路由相关的PMTU值。
前者通过与路由条目关联一个标志来完成。当一个发送的包经过具有这个标志的路由的时候，IP层把DF比特位清除，而不管上层的请求如何。
这些特性可以使用在不规则的情况中，或者用在能够得到路径MTU值的路由协议实现中。
实现应该提供一种方法改变使PMTU信息变老的超时周期。
7.路径MTU的可能值
在第五节建议的“搜索”路径MTU空间的算法基于严格限制搜索空间的取值表。我们在这里描述的MTU取值表声明了在因特网中使用的所有主要的数据链路技术。
在表7－1中，数据链路以减少的MTU顺序列出，并且为了每组相似的MTU与等于这组中最小MTU的“参考点”关联在一起而进行了分组。（这个表也包括一些不与当前数据链路关联的条目，并且给出在哪里可用的参考）。在那里一个参考点代表了不止一个MTU，此表显示了与参考点关联的最大误差，用一个百分数来表示。
我们不希望表中的值，尤其对于较高级别的MTU值，永远是有效的。这里给出的值是对实现的建议，不是一个规范或者要求必备。实现者应该使用最新的参考来挑选一组参考点；这个表不应该包含太多的条目，否则检索PMTU的过程可能浪费因特网的资源。实现者应该使没有源代码的用户方便地更新他们系统中的表值（例如，在源自BSDUnix内核中的表可以使用"ioctl"命令来改变）。
注重：加入值等于2的较小此幂加40（IP和TCP的首部）的新的表项，可能是个好主意。在那里，没有相似的值存在，因为这看起来是不能随意选择任意值的情况。
这个表也可能包含值仅比的2的较大次幂小一点的条目，以防MTU被定义为接近这些值（这种情况下，表中的条目值低一点比高一点好，否则，下一个最小的参考值可能代替被选择）。
7.1一种较好的检测PMTU增长的方法
6.3节建议通过周期性地增长对第一跳MTU的估计值来检测PMTU值的增长。这个过程简化“重新发现”当前PMTU估计值，要以丢失一些数据报作为代价，所以这种工作不应该经常做。
一种较好的方法是周期性地增长PMTU的估计值到参考点表中下一个最高值（假如它太小，就采用第一跳MTU）。假如增长的估计值是错误的，在正确值被重新发现之前，至多有一次往返时间浪费。假如增长的估计值仍然太低，一个较高的估计值将在以后的时间尝试。
因为需要几个这样的周期来发现在PMTU中重要的增长，我们推荐在估计值增长后，使用较短的超时周期。
PlateauMTUCommentsReference
--------------------------
65535OfficialmaximumMTURFC791
65535HyperchannelRFC1044
65535
32000Justincase
1791416MbIBMTokenRingref.[6]
17914
8166IEEE802.4RFC1042
8166
4464IEEE802.5(4Mbmax)RFC1042
4352FDDI(Revised)RFC1188
4352(1%)
2048WidebandNetworkRFC907
2002IEEE802.5(4Mbrecommended)RFC1042
2002(2%)
1536EXP.EthernetNetsRFC895
1500EthernetNetworksRFC894
1500Point-to-Point(default)RFC1134
1492IEEE802.3RFC1042
1492(3%)
1006SLIPRFC1055
1006ARPANETBBN1822
1006
576X.25NetworksRFC877
544DECIPPortalref.[10]
512NETBIOSRFC1088
508IEEE802/Source-RtBridgeRFC1042
508ARCNETRFC1051
508(13%)
296Point-to-Point(lowdelay)RFC1144
296
68OfficialminimumMTURFC791
Table7-1:CommonMTUsintheInternet
在PTMU估计值因为数据报太大报文而减小后，使用一个较长的超时。例如，在PMTU估计值减少后，超时应该被设置为10分钟；一旦计时器超期，一个较大的MTU值被尝试，这个超时可能被设置为一个较小的值（比如说，2分钟）。超时决不能比估计的往返时间短。
8.安全性的考虑
路径MTU发现机制可能造成两种服务拒绝攻击，两者都基于有恶意的一方发送伪造的数据报太大报文给一个因特网主机。
在第一种攻击中，伪造的报文指明一个比实际PMTU小的多的PMTU。因为受害主机不会设置PMTU估计值低于真正的最小值，所以这不会完全停止数据流，但是，在每一个数据报中可能只有8字节IP数据，所以传送数据的进展将非常慢。
在另一种攻击中，伪造报文指示一个比真实值大的PMTU。假如相信了这个值，当受害者发送将被路由器丢弃的数据报的时候，将可能导致临时阻塞。在一个往返时间中，主机应该能发现它的错误（从那个丢弃数据报的路由器中接收数据报太大报文而得知），但是这种攻击频繁重复可能导致许多数据报被丢弃。然而，主机不会基于数据报太大报文来提高它对PMTU的估计值，所以也不会轻易受到这种攻击。
假如恶意的一方阻止受害者接收合法的数据报太大报文，也会产生问题，但是在这种情况下，仅可用较简单的服务拒绝攻击。
参考书目：
[1]R.Braden,ed.RequirementsforInternetHosts--Communication
Layers.RFC1122,SRINetworkInformationCenter,October,1989.
[2]GeofCooper.IPDatagramSizes.Electronicdistributionofthe
TCP-IPDiscussionGroup,Message-ID
<8705240517.AA01407@apolling.imagen.uucp>.
[3]ISO.ISOTransportProtocolSpecification:ISODP8073.RFC905,
SRINetworkInformationCenter,April,1984.
[4]VanJacobson.CongestionAvoidanceandControl.InProc.SIGCOMM
"88SymposiumonCommunicationsArchitecturesandProtocols,pages
314-329.Stanford,CA,August,1988.
[5]C.KentandJ.Mogul.FragmentationConsideredHarmful.InProc.
SIGCOMM"87WorkshoponFrontiersinComputerCommunications
Technology.August,1987.
[6]DrewDanielPerkins.PrivateCommunication.
[7]J.Postel.InternetControlMessageProtocol.RFC792,SRI
NetworkInformationCenter,September,1981.
[8]J.Postel.InternetProtocol.RFC791,SRINetworkInformation
Center,September,1981.
[9]J.Postel.TheTCPMaximumSegmentSizeandRelatedTopics.RFC
879,SRINetworkInformationCenter,November,1983.
[10]MichaelReilly.PrivateCommunication.
[11]SunMicrosystems,Inc.RPC:RemoteProcedureCallProtocol.RFC
1057,SRINetworkInformationCenter,June,1988.
作者地址：
JeffreyMogul
DigitalEquipmentCorporationWesternResearchLaboratory
100HamiltonAvenue
PaloAlto,CA94301
Phone:(415)853-6643
EMail:mogul@decwrl.dec.com
SteveDeering
XeroxPaloAltoResearchCenter
3333CoyoteHillRoad
PaloAlto,CA94304
Phone:(415)494-4839
EMail:deering@xerox.com