组织：中国互动出版网（http://www.china-pub.com/）<br />
RFC文档中文翻译计划（http://www.china-pub.com/compters/emook/aboutemook.htm）<br />
E-mail：ouyang@china-pub.com<br />
译者：李海鹏（leehp327&nbsp;&nbsp;&nbsp;&nbsp;leehp327@sina.com&nbsp;）<br />
译文发布时间：2002-6-11<br />
版权：本中文翻译文档版权归中国互动出版网所有。可以用于非商业用途自由转载，但必须保留本文档的翻译及版权信息。<br />
<br />
Network&nbsp;Working&nbsp;Group&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;J.&nbsp;McCann<br />
Request&nbsp;for&nbsp;Comments:&nbsp;1981&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;Digital&nbsp;Equipment&nbsp;Corporation<br />
Category:&nbsp;Standards&nbsp;Track&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;S.&nbsp;Deering<br />
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;Xerox&nbsp;PARC<br />
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;J.&nbsp;Mogul<br />
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;Digital&nbsp;Equipment&nbsp;Corporation<br />
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;August&nbsp;1996<br />
<br />
IP&nbsp;版本&nbsp;6的路径MTU探索<br />
（RFC&nbsp;1981，Path&nbsp;MTU&nbsp;Discovery&nbsp;for&nbsp;IP&nbsp;version&nbsp;6）<br />
本备忘录的状态<br />
本文档讲述了一种Internet社区的Internet标准跟踪协议，它需要进一步进行讨论和建议以得到改进。请参考最新版的“Internet正式协议标准”(STD1)来获得本协议的标准化程度和状态。本备忘录的发布不受任何限制。<br />
摘要<br />
本文档描述了对于IPv6的路径MTU探索。它很大程度上是从RFC1191（描述了对于IPv4的路径MTU探索）发展而来的。<br />
目&nbsp;&nbsp;录<br />
摘&nbsp;&nbsp;要	1<br />
1&nbsp;引言	2<br />
2&nbsp;术语	2<br />
3&nbsp;协议概述	3<br />
4&nbsp;协议需求	4<br />
5&nbsp;执行问题	5<br />
5．1&nbsp;分层	5<br />
5．2&nbsp;存储PMTU信息	5<br />
5．3&nbsp;清除陈旧PMTU信息	7<br />
5．4&nbsp;TCP层动作	7<br />
5．5&nbsp;其他传输协议的运行问题	8<br />
5．6&nbsp;管理界面	9<br />
6&nbsp;安全考虑	9<br />
致谢	10<br />
附录A&nbsp;－&nbsp;与RFC1191的对比	10<br />
参考	10<br />
作者地址	11<br />
<br />
1&nbsp;引言<br />
当一个IPv6节点发送大量数据到另一节点时，数据通过一系列IPv6分组传送。当这些分组具有从源节点到信宿节点能够成功传送所允许的最大长度时，我们认为它达到理想状态。这个分组长度被称为路径MTU（PMTU），并且它等于在这个路径里所有链接的最小链接MTU。IPv6定义了一个标准机制，使节点可以发现任一路径的PMTU。IPv6节点应当实现路径MTU的发现，从而发现并利用那些具有比IPv6最小链接MTU大的PMTU的路径。一个最小的IPv6执行可以选择忽略路径MTU发现的执行。那些不执行路径MTU发现的节点使用IPv6最小链接MTU（定义于[IPv6-SPEC]）作为分组的最大长度。在大多情况下，这样会导致使用了小于必需长度的分组，因为大部分路径的PMTU大于IPv6最小链接MTU。一个节点所发送的分组远小于路径MTU的允许，这是对网络资源的一种浪费并可能产生不理想的处理能力。<br />
2&nbsp;术语<br />
节点			－指一种执行IPv6的设备<br />
路由器			－指一种节点转发IPv6分组，本身没有明确的地址<br />
主机			－不是路由器的任何节点<br />
上层			－紧接在IPv6的上层协议。如传输协议TCP和UDP，控制协议ICMP，路由协议OSPF，和在IPv6上“挖隧道”的网络或下层协议IPX，AppleTalk，以及IPv6本身。<br />
链接			－一种使节点可以在链路层（紧接着低于IPv6的层）上通信的通信设备或媒介。如以太网（简单的或桥路的），PPP链接，X.25，帧中继，ATM网，和网络层或更高的“隧道”，例如在IPv4或IPv6本身上的隧道。<br />
接口			－指一种连接节点的附加装置。<br />
地址			－指一个接口或一系列接口的IPv6层的标识符。<br />
分组			－IPv6头加上有效载荷。<br />
链接MTU			－最大传输单元，分组所具有的8位字节最大长度，可以在某一链接上被一次性传输。<br />
路径			－传输一分组时从源节点到信宿节点所经过的一系列链接。<br />
路径MTU			－在源节点到信宿节点的路径里所有链接中的最小链接MTU。<br />
PMTU			－路径MTU。<br />
路径MTU发现	－一个节点了解某一路径的PMTU的过程。<br />
流				－从某个源点向（单播或组播的）信宿发送的分组群中，源点要求中间路由器作出特殊处理的那些分组。<br />
流标记			－指由源地址和非零流标识的组合体。<br />
3&nbsp;协议概述<br />
该协议描述了一种动态发现任一路径的PMTU的方法。其基本原理是由某一源节点最初假设路径的PMTU为路径中第一段距离的MTU（已知）。如果分组对于沿路径中的某节点来说长度超限，那么该节点将丢弃分组并返回ICMPv6指示分组长度超限[ICMPv6]。收到该信息后，源节点就会减少假设的PMTU。当节点估计的PMTU小于或等于实际的PMTU时，路径MTU发现过程结束。请注意由于可能会在路径的远处存在具有更小MTU的链接，因而在路径MTU发现过程结束前可能会出现分组发送/分组长度超限信息接收这样的反复数次过程。<br />
节点也可以在停止发送大于IPv6最小链接MTU分组时选择中止探索过程。<br />
随着时间的过去原先的路径MTU可能改变，主要因为路由布局的改变。PMTU的减小可以被分组长度超限信息发现。为了检测到某路径的PMTU的增长，节点定期的增加它假设的PMTU。这样很可能会导致分组被丢弃并且产生分组长度超限信息，因为大多数情况下某路径的PMTU不会改变。因此，很少进行某路径的PMTU是否增加的测试。<br />
路径MTU发现支持组播和单播传送的信宿。在组播传送时，相同的分组经过不同的路径传送到不同的节点上。每个路径具有不同的PMTU，并且一个组播传送分组可能产生很多分组长度超限信息，每个信息指示了不同的下一路程段的MTU。这一系列路径中的最小PMTU被用来决定后面的将要进行组播传送的分组长度。<br />
注意：路径MTU发现必须被执行，即使当一个节点认为目的地和它自己是相同的链接。在特殊情况下如邻居路由器对一些目的地作为代理[ND]，目的地可以被认为直接链接的，但实际上多于一个路程段。<br />
4&nbsp;协议需求<br />
就像在一开始所说的，IPv6节点没有必需要实现路径MTU发现。在本节中所叙述的需求只是应用于那些包含路径MTU发现的执行过程中。<br />
当某一节点收到分组长度超限信息，它必须减少它对相应路径所估计的PMTU，基于信息中的MTU域中的值。由于不同的应用程序会有不同的需求，并且不同的执行体系又会支持不同的策略，所以一个节点在这种情况下的准确动作没有被详细说明。<br />
当收到分组长度超限信息后，节点必须尽量避免在以后引起更多的此类信息。该节点必须减小发送的分组长度。当使用大于IPv6最小MTU的PMTU时，可能还会导致产生分组长度超限信息。由于这些信息中的任何信息（包括丢弃分组时它们的回答）都会消耗网络资源，该节点必须强迫路径MTU发现过程结束。<br />
使用路径MTU发现的节点必须尽快探测到PMTU的减小。节点也可以探测到PMTU的增长，但这样做需要发送比当前估计的PMTU大的分组，并且由于PMTU增长的可能性很低，要求节点必须少做这种探测。一个对增长的探测尝试（发送大于当前估计的分组），不能在收到该路径的分组长度超限信息后5分钟之内进行。建议设置该计时器两倍于最小时间值（也就是10分钟）。<br />
一个节点不能减少它所估计的路径MTU低于IPv6最小链接MTU。<br />
注意：节点可能收到分组长度超限信息指示下一路程段MTU小于IPv6最小链接MTU。在这种情况下，该节点不需要使后来在此路径中发送的分组长度低于IPv6最小链接MTU，但必须包含一个分段头标在这些分组中。（定义于[IPv6-SPEC]）<br />
节点不允许增加估计的路径MTU值作为对分组长度超限信息的回应。一个信息声称增加路径MTU，它可能是一个陈旧的分组，在网络里到处游荡，或一个虚假的分组作为对拒绝服务攻击的一部分，或者可能是组播传送的结果，因为每个路径都有不同的PMTU。<br />
5&nbsp;执行问题<br />
这一部分讨论了许多关于路径MTU的执行问题。这不是一个规范，但是它是一系列的注解来帮助执行者。这些问题包括：<br />
－什么层执行路径MTU发现?<br />
－PMTU信息是如何储存的?<br />
－陈旧的PMTU信息是如何删除的?<br />
－传输层和高层必须做什么?<br />
5.1&nbsp;分层<br />
在IP体系中，对发送分组长度的选择是由IP层以上层的协议所作出的。本文指的是被称为“分组协议”（packetization&nbsp;protocol）的协议。分组协议通常为传输协议（如TCP）但是还可以是高层协议（如，紧接着建立在UDP上层的协议）。在分组层（packetization&nbsp;layer）上执行路径MTU发现简化为几个层内的执行问题，但是还有一些缺陷：执行可能被每个分组协议重新执行，这样很难在不同分组层之间分享PMTU信息，而且在维持面相连接的情况下，一些分组层可能不会容易的去长时间存储PMTU信息。<br />
所以建议由IP层存储PMTU信息，ICMP层处理收到的分组长度超限信息。分组层可以对PMTU的改变作出响应，改变它们所发出的信息大小。为了支持这种分层，分组层需要能够知道MMS_S（最大发送传输信息大小maximum&nbsp;send&nbsp;transport-message&nbsp;size）值的改变。MMS_S是源自路径MTU，值为PMTU减去IPv6头标的大小加上IP层为扩展头标（如果有）预留的空间的值。<br />
对于分组层它可能是一个UDP核心程序之外的应用程序，它有可能无法改变它所发出信息的大小。这样会使分组长度超过路径MTU。为了解决这个问题，IPv6定义了一种机制它允许很大的有效载荷被分段，每段被一单独分组发送（见[IPv6-SPEC]section&nbsp;"Fragment&nbsp;Header"）。然而，我们还是希望分组层避免发送信息分段（对分段的不利情况，见[FRAG]）。<br />
5.2&nbsp;存储PMTU信息<br />
理想来说，PMTU值应当由在指定路径上的源点和信宿之间反复交换分组而来。但是，大多数情况下，节点没有足够的信息能够充分而准确的识别那样一个路径。不过节点应当有一些本地的有代表性的路径的PMTU。这样就只能选择路径的本地代表。<br />
在组播传送的时候，分组可能经由不同的路径到达不同的节点。路径的本地代表对于组播传送来说实际上代表潜在的大量的路径。<br />
一个执行过程最少应当维持一个PMTU值，并应用于所以从该节点出发的分组。这个PMTU值从所有该节点上使用该路径中的PMTU中选择最小的一个而来。这种方法对于大多数路径可能导致使用了比最大长度小的分组。<br />
执行可以把信宿地址作为路径的本地代表。在该信宿上使用过的所有路径的PMTU中最小的一个作为该信宿自带的PMTU值。到达一特殊信宿所使用的路径数量是不多的，很多时候只有一个。这种方法就使那些按信宿为准的分组长度理想化。这种方法很好的符合了在[ND]中描述的主机的概念模型：PMTU值应当存储在信宿地存储区内。<br />
如果使用了流，执行应当使用流标志作为路径的本地代表。发送到相同信宿的分组由于分别属于不同的流可能使用不同的路径，应当通过流标志来选择路径。这种方法使按流为准的分组长度最佳，比按信宿为准所产生的PMTU值更准确。<br />
对于源定义路径的分组（也就是说分组包含IPv6寻路头标[IPv6-SPEC]），源路径可能更能作为路径的本地代表。特别是当分组包含类型为0的寻路头标，包含了一个完整的路径说明。执行可以使用源路径信息到路径的本地代表中。<br />
最初某一路径的PMTU值假设为第一路程段的MTU（已知）。当收到分组长度超限信息，该节点根据分组长度超限信息内容确定信息适用的路径。例如，如果信宿地址被用作路径的本地代表，原始分组的地址信息就能用来决定信息适用的路径。<br />
注意：如果原始分组包含寻路头标，那么寻路投标应当被用于确定原始信息内的信宿地址的位置。如果剩余中继点数为0，那么信宿地址是IPv6头标中的目的地址。而当剩余中继点数大于0时，则是是寻路头标中的最后的地址（地址[n]）。<br />
然后该节点使用分组长度超限信息中MTU域中的值，作为尝试的PMTU值，并与当前的PMTU进行比较。如果尝试的PMTU小于当前PMTU估计，那么尝试PMTU将代替当前PMTU作为该路径的PMTU值。<br />
必须将PMTU的降低对分组层进行通报。任何正在使用该路径的分组层（如TCP链接）必须在PMTU估计降低时被通知到。注意：即使分组长度超限信息包含的源分组头标指示使用UDP分组，只要TCP层上有链接使用该路径，那么它就必须被通知到。<br />
同样当发送分组引起分组长度超限信息时，应当通知这个分组被丢弃，即使是PMTU估计不变，它还是要重发丢弃的数据。<br />
注意：执行可以避免使用异步通知机制来通知PMTU的降低，通过延迟通知直到下一次尝试发送大于PMTU估计的分组时。使用这种方法，当尝试发送大于PMTU估计的分组时，发送失败并返回合适的错误指示。这种方法可能更适用于无连接分组层（如使用UDP），因为它们（在一些执行中）可能很难被ICMP层通知到。这样的话，普通的超时重发机制可以用来恢复丢弃的分组。<br />
通知分组层实例使用的路径PMTU的改变和通知特殊的实例分组被丢弃是截然不同的，这一点很重要。后者一旦应用就实现（也就是说，对于分组层实例来说它是异步的），而前者可能要推迟到分组层实例想要创造分组时。只有当那些已知分组被丢弃时（由分组长度超限信息指示）重发才能实现。<br />
5.3&nbsp;清除陈旧PMTU信息<br />
网间布局是动态的，路线会随时间的过去而改变。然而一个路径的本地代表是保持不变的，实际应用的路径却可能会改变。这样节点存储的PMTU信息可能会变得陈旧。<br />
如果陈旧的PMTU值太大，一旦一个足够大的分组发送到该路径上就会被发现。没有相关的机制能够发现陈旧的PMTU值太小，所以应当采用一个执行来计算存储值的“年龄”。当PMTU值经过一段时间（规定是10分钟）后没有被降低，PMTU估计应当被设置为第一距离段的MTU，并且应当通知分组层这个改变。这样就使整个路径MTU发现过程重新进行。<br />
注意：执行应当提供一种方法改变超时时间，包括设置为“无限”。例如，FDDI连接上的节点另一端连接在较小的MTU连接上，它永远无法发现新的非本地PMTU，所以它不应当10分钟丢弃分组。<br />
上层不能因PMTU估计的增长而重发数据，因为这种增长永远无法产生丢弃分组的指示。<br />
一种计算PMTU年龄的方法是让PMTU值有一个时标域。这个域初始化为“预留”值，指示PMTU与第一距离段的MTU相等。无论何时一旦PMTU因收到分组长度超限信息而减小时，时标被设为当前时间。<br />
一旦计时器程序在所有PMTU开始运行，对每一个PMTU只要它的时标不是预留并且超过了超时间隔：<br />
－PMTU估计设置为第一距离段的MTU。<br />
－时标设置为预留状态。<br />
－使用该路径通知分组层此增长。<br />
5.4&nbsp;TCP层动作<br />
TCP层必须通过一种连接记录路径上的PMTU；它不能发送可能导致分组大于PMTU的分段。一个简单的执行过程应当在每次建立新的分段时询问IP层相应的值，但是它的效率很低。此外，TCP执行过程会遵循它典型的“慢启动”拥塞回避算法，计算并储存几个其他的PMTU数值。当PMTU改变时它可以更简单的接收异步通知，所以这些变量应当被更新。<br />
TCP执行过程也必须等同的找到并存储MSS值，并且不能发送超过MSS的分段，不管PMTU是如何。在4.xBSD-derived执行中，还需要增加附加的区域记录TCP状态。<br />
发送到TCP&nbsp;MSS选项中的值与PMTU是相互独立的。这个MSS选项值被连接的另一端使用，它可能使用无关的PMTU值。见[IPv6-SPEC]部分"Packet&nbsp;Size&nbsp;Issues"&nbsp;和&nbsp;"Maximum&nbsp;Upper-Layer&nbsp;Payload&nbsp;Size"，有选择TCP&nbsp;MSS选项值的信息。<br />
当收到分组长度超限信息时，它意味着一个分组被节点丢弃并发送了ICMP信息。这就足够把这件事当作其他丢弃的分段，并等待重发计时器过期引起重发分段。如果路径MTU发现过程需要几个步骤去发现整个路径的PMTU，这样来回反复会延迟连接时间。<br />
或者可以在收到路径MTU变化通知时立即重发，但是只能对指定了分组长度超限信息的特殊连接可行。重发中的分组长度不能超过新的PMTU。<br />
注意：分组层不能对每个分组长度超限信息作出重发响应，因为几个分段超限的爆发会引起几个同样的信息从而重发相同的信息。如果新的PMTU仍是错的，那么过程重复，并且多余分段的发送会呈指数增长。这意味着TCP层必须能够在分组长度超限信息到达时认出真正的PMTU的降低，并忽视其他的通知。<br />
许多TCP执行过程包含拥塞避免和满启动算法来提高性能[CONG]。与TCP重发超时引起的重发不同，由分组长度超限信息引起的重发不能改变拥塞窗口。然而，它可以引发满启动算法（也就是说，直到确认信息到达前只有一个分段可以被重发）。<br />
当发送者的窗口大小不是使用的分段大小的整数倍时（这不是拥塞窗口大小），TCP性能会下降。在很多系统中（如4.2BSD中），分段大小经常被设为1024八位组，最大的窗口大小（“发送空间”）通常是1024八位组，所以保持者正确的关系。然而如果路径MTU发现被使用，分段大小就可能不会是发送空间的约数，它可能在连接时改变；这意味着在分组长度超限探索改变了PMTU的值时TCP层可能需要改变重发窗口大小。最大窗口大小应当设为分段大小的最大倍数，小于或等于发送者的缓存空间。<br />
5.5&nbsp;其他传输协议的运行问题<br />
一些传输协议（如ISO&nbsp;TP4在[ISOTP]）不允许在重发的时候重新分组。更确切的说，一旦一个传输尝试开始进行，分段具有一特定的大小，那么不允许在重发中将分段内容分成更小的分段。在这种情况下，原始分段可以在IP层的重发过程中被分为更小的段。后来的段在第一次传输中，不能大于路径MTU的允许。<br />
Sun网络文件系统（NFS）使用远距离程序调用（RPC）协议[RPC]，当在UDP上使用时，在很多情况下都会产生有效载荷即使实在第一距离段连接时，都要进行分段。这样可能提高性能，但会引发可靠性和执行问题，特别是当客户端和服务器被路由器分开时。<br />
不管是否包含路由器，我们都建议NFS执行使用路径MTU发现。大多数的NFS执行允许RPC数据报长度在执行期间可变（通过改变有效的文件系统字区大小，间接的改变），但是可能为了支持后面的改变需要一些修改。<br />
同样的，由于单一的NFS操作不能被分为几个UDP数据报，特别的操作（主要是那些对于文件名和目录的操作）需要最小的有效载荷长度，使当被送到单一的分组时会大于PMTU。NFS执行不能把有效载荷长度减小到低于这个门限，即使路径MTU发现建议一个更小的值。在这种情况下，有效载荷会被IP层分段。<br />
5.6&nbsp;管理界面<br />
我们建议执行过程提供一种方法使系统能有效进行：<br />
－确定路径MTU探索没有在该路径上被进行。<br />
－在一指定路径上改变PMTU值。<br />
前者可以通过给路径附加一标记完成；当分组被送到该路径上发现作有标记，那么IP层就不再发送比IPv6最小链接MTU大的分组。<br />
这些特征可以被应用于一些反常的情形下，或应用于路由协议执行，可以获得路径MTU值。<br />
执行过程还应当提供能够改变用于计算陈旧PMTU信息的超时时间的方法。<br />
6&nbsp;安全考虑<br />
本路径MTU发现机制可能引起两个负面的攻击，都是基于恶毒团体发送给节点的错误的分组长度超限信息。<br />
第一个攻击，错误的信息指示的PMTU远小于实际。这样不能完全停止数据流，因为受害的节点永远无法将它的PMTU估计小于IPv6最小链接MTU。这样就导致了不理想的性能。<br />
第二个攻击，错误的信息指示了PMTU大于实际。如果相信它，就会引起暂时的阻塞，受害者发送的分组会被一些路由丢弃。在一个来回时间内，该节点会发现这个错误（从路由器收到分组长度超限信息），但是经常的收到这种攻击就会使大量分组丢失。一个节点决不应在收到分组长度超限信息后增加它的估计，所以不是很容易被这种攻击影响。<br />
恶毒团体还可以通过停止受害者接收合法的分组长度超限信息来引发问题，但是这样的话还有更简单的攻击方式存在。<br />
致谢<br />
我们感谢[RFC-1191]的作者和捐助者，这里的大部分文章都是源自那里。我们还感谢IPng工作组的成员，感谢他们细心的评论和有建设性的评语。<br />
附录A&nbsp;－&nbsp;与RFC1191的对比<br />
本文档很大程度上基于RFC1191（描述了IPv4的路径MTU探索）。在RFC1191里的一些部分这里是不需要的：<br />
路由器说明		－分组长度超限信息和相应的路由动作在[ICMPv6]中定义<br />
不分段比特位	－在IPv6分组里没有DF位<br />
TCP&nbsp;MSS讨论		－选择值发送到TCP&nbsp;MSS选项在[IPv6-SPEC]里讨论<br />
旧式信息		－所有分组长度超限信息报告了压缩连接的MTU<br />
MTU曲线表格		－因为没有旧式信息，所以没有必要了<br />
参考文献<br />
[CONG]&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;Van&nbsp;Jacobson.&nbsp;&nbsp;Congestion&nbsp;Avoidance&nbsp;and&nbsp;Control.&nbsp;&nbsp;Proc.<br />
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;SIGCOMM&nbsp;'88&nbsp;Symposium&nbsp;on&nbsp;Communications&nbsp;Architectures&nbsp;and<br />
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;Protocols,&nbsp;pages&nbsp;314-329.&nbsp;&nbsp;Stanford,&nbsp;CA,&nbsp;August,&nbsp;1988.<br />
[FRAG]&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;C.&nbsp;Kent&nbsp;and&nbsp;J.&nbsp;Mogul.&nbsp;&nbsp;Fragmentation&nbsp;Considered&nbsp;Harmful.<br />
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;In&nbsp;Proc.&nbsp;SIGCOMM&nbsp;'87&nbsp;Workshop&nbsp;on&nbsp;Frontiers&nbsp;in&nbsp;Computer<br />
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;Communications&nbsp;Technology.&nbsp;&nbsp;August,&nbsp;1987.<br />
[ICMPv6]&nbsp;&nbsp;&nbsp;&nbsp;Conta,&nbsp;A.,&nbsp;and&nbsp;S.&nbsp;Deering,&nbsp;"Internet&nbsp;Control&nbsp;Message<br />
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;Protocol&nbsp;(ICMPv6)&nbsp;for&nbsp;the&nbsp;Internet&nbsp;Protocol&nbsp;Version&nbsp;6<br />
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;(IPv6)&nbsp;Specification",&nbsp;RFC&nbsp;1885,&nbsp;December&nbsp;1995.<br />
[IPv6-SPEC]&nbsp;Deering,&nbsp;S.,&nbsp;and&nbsp;R.&nbsp;Hinden,&nbsp;"Internet&nbsp;Protocol,&nbsp;Version<br />
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;6&nbsp;(IPv6)&nbsp;Specification",&nbsp;RFC&nbsp;1883,&nbsp;December&nbsp;1995.<br />
[ISOTP]&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;ISO.&nbsp;&nbsp;ISO&nbsp;Transport&nbsp;Protocol&nbsp;Specification:&nbsp;ISO&nbsp;DP&nbsp;8073.<br />
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;RFC&nbsp;905,&nbsp;SRI&nbsp;Network&nbsp;Information&nbsp;Center,&nbsp;April,&nbsp;1984.<br />
[ND]&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;Narten,&nbsp;T.,&nbsp;Nordmark,&nbsp;E.,&nbsp;and&nbsp;W.&nbsp;Simpson,&nbsp;"Neighbor<br />
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;Discovery&nbsp;for&nbsp;IP&nbsp;Version&nbsp;6&nbsp;(IPv6)",&nbsp;Work&nbsp;in&nbsp;Progress.<br />
[RFC-1191]&nbsp;&nbsp;Mogul,&nbsp;J.,&nbsp;and&nbsp;S.&nbsp;Deering,&nbsp;"Path&nbsp;MTU&nbsp;Discovery",<br />
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;RFC&nbsp;1191,&nbsp;November&nbsp;1990.<br />
[RPC]&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;Sun&nbsp;Microsystems,&nbsp;Inc.,&nbsp;"RPC:&nbsp;Remote&nbsp;Procedure&nbsp;Call<br />
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;Protocol",&nbsp;RFC&nbsp;1057,&nbsp;SRI&nbsp;Network&nbsp;Information&nbsp;Center,<br />
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;June,&nbsp;1988.<br />
作者地址<br />
Jack&nbsp;McCann<br />
Digital&nbsp;Equipment&nbsp;Corporation<br />
110&nbsp;Spitbrook&nbsp;Road,&nbsp;ZKO3-3/U14<br />
Nashua,&nbsp;NH&nbsp;03062<br />
Phone:&nbsp;+1&nbsp;603&nbsp;881&nbsp;2608<br />
Fax:&nbsp;&nbsp;&nbsp;+1&nbsp;603&nbsp;881&nbsp;0120<br />
Email:&nbsp;mccann@zk3.dec.com<br />
<br />
Stephen&nbsp;E.&nbsp;Deering<br />
Xerox&nbsp;Palo&nbsp;Alto&nbsp;Research&nbsp;Center<br />
3333&nbsp;Coyote&nbsp;Hill&nbsp;Road<br />
Palo&nbsp;Alto,&nbsp;CA&nbsp;94304<br />
Phone:&nbsp;+1&nbsp;415&nbsp;812&nbsp;4839<br />
Fax:&nbsp;&nbsp;&nbsp;+1&nbsp;415&nbsp;812&nbsp;4471<br />
EMail:&nbsp;deering@parc.xerox.com<br />
<br />
Jeffrey&nbsp;Mogul<br />
Digital&nbsp;Equipment&nbsp;Corporation&nbsp;Western&nbsp;Research&nbsp;Laboratory<br />
250&nbsp;University&nbsp;Avenue<br />
Palo&nbsp;Alto,&nbsp;CA&nbsp;94301<br />
Phone:&nbsp;+1&nbsp;415&nbsp;617&nbsp;3304<br />
EMail:&nbsp;mogul@pa.dec.com<br />
RFC1981――Path&nbsp;MTU&nbsp;Discovery&nbsp;for&nbsp;IP&nbsp;version&nbsp;6&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;IP&nbsp;版本&nbsp;6的路径MTU探索&nbsp;&nbsp;&nbsp;&nbsp;<br />
<br />