我们推荐的策略是使用小于返回总长字段的最大的参考值来作为下一个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估计值没有改变 。这是为了它可以重传丢弃的数据报 。
推荐阅读
- 最大分段 小议TCP的MSS以及MTU
- Z710c的r1jc002版本软件的新发现
- vivox23幻彩版怎么去掉照片水印
- P768暂时发现的不足和我的感觉
- 关注P768真机以来，发现的几个缺点！
- 联想z6怎么修改照片存储路径
- TCP的路径MTU发现问题
- 美颜相机中打马赛克具体操作流程
- 关于p768的功能和待机时间
- 世界上最长的蚯蚓是在哪里发现的