rfc1981.txt

RFC规范的翻译稿

注意：执行可以避免使用异步通知机制来通知PMTU的降低，通过延迟通知直到下一次尝试发送大于PMTU估计的分组时。使用这种方法，当尝试发送大于PMTU估计的分组时，发送失败并返回合适的错误指示。这种方法可能更适用于无连接分组层（如使用UDP），因为它们（在一些执行中）可能很难被ICMP层通知到。这样的话，普通的超时重发机制可以用来恢复丢弃的分组。
通知分组层实例使用的路径PMTU的改变和通知特殊的实例分组被丢弃是截然不同的，这一点很重要。后者一旦应用就实现（也就是说，对于分组层实例来说它是异步的），而前者可能要推迟到分组层实例想要创造分组时。只有当那些已知分组被丢弃时（由分组长度超限信息指示）重发才能实现。
5.3 清除陈旧PMTU信息
网间布局是动态的，路线会随时间的过去而改变。然而一个路径的本地代表是保持不变的，实际应用的路径却可能会改变。这样节点存储的PMTU信息可能会变得陈旧。
如果陈旧的PMTU值太大，一旦一个足够大的分组发送到该路径上就会被发现。没有相关的机制能够发现陈旧的PMTU值太小，所以应当采用一个执行来计算存储值的“年龄”。当PMTU值经过一段时间（规定是10分钟）后没有被降低，PMTU估计应当被设置为第一距离段的MTU，并且应当通知分组层这个改变。这样就使整个路径MTU发现过程重新进行。
注意：执行应当提供一种方法改变超时时间，包括设置为“无限”。例如，FDDI连接上的节点另一端连接在较小的MTU连接上，它永远无法发现新的非本地PMTU，所以它不应当10分钟丢弃分组。
上层不能因PMTU估计的增长而重发数据，因为这种增长永远无法产生丢弃分组的指示。
一种计算PMTU年龄的方法是让PMTU值有一个时标域。这个域初始化为“预留”值，指示PMTU与第一距离段的MTU相等。无论何时一旦PMTU因收到分组长度超限信息而减小时，时标被设为当前时间。
一旦计时器程序在所有PMTU开始运行，对每一个PMTU只要它的时标不是预留并且超过了超时间隔：
－PMTU估计设置为第一距离段的MTU。
－时标设置为预留状态。
－使用该路径通知分组层此增长。
5.4 TCP层动作
TCP层必须通过一种连接记录路径上的PMTU；它不能发送可能导致分组大于PMTU的分段。一个简单的执行过程应当在每次建立新的分段时询问IP层相应的值，但是它的效率很低。此外，TCP执行过程会遵循它典型的“慢启动”拥塞回避算法，计算并储存几个其他的PMTU数值。当PMTU改变时它可以更简单的接收异步通知，所以这些变量应当被更新。
TCP执行过程也必须等同的找到并存储MSS值，并且不能发送超过MSS的分段，不管PMTU是如何。在4.xBSD-derived执行中，还需要增加附加的区域记录TCP状态。
发送到TCP MSS选项中的值与PMTU是相互独立的。这个MSS选项值被连接的另一端使用，它可能使用无关的PMTU值。见[IPv6-SPEC]部分"Packet Size Issues" 和 "Maximum Upper-Layer Payload Size"，有选择TCP MSS选项值的信息。
当收到分组长度超限信息时，它意味着一个分组被节点丢弃并发送了ICMP信息。这就足够把这件事当作其他丢弃的分段，并等待重发计时器过期引起重发分段。如果路径MTU发现过程需要几个步骤去发现整个路径的PMTU，这样来回反复会延迟连接时间。
或者可以在收到路径MTU变化通知时立即重发，但是只能对指定了分组长度超限信息的特殊连接可行。重发中的分组长度不能超过新的PMTU。
注意：分组层不能对每个分组长度超限信息作出重发响应，因为几个分段超限的爆发会引起几个同样的信息从而重发相同的信息。如果新的PMTU仍是错的，那么过程重复，并且多余分段的发送会呈指数增长。这意味着TCP层必须能够在分组长度超限信息到达时认出真正的PMTU的降低，并忽视其他的通知。
许多TCP执行过程包含拥塞避免和满启动算法来提高性能[CONG]。与TCP重发超时引起的重发不同，由分组长度超限信息引起的重发不能改变拥塞窗口。然而，它可以引发满启动算法（也就是说，直到确认信息到达前只有一个分段可以被重发）。
当发送者的窗口大小不是使用的分段大小的整数倍时（这不是拥塞窗口大小），TCP性能会下降。在很多系统中（如4.2BSD中），分段大小经常被设为1024八位组，最大的窗口大小（“发送空间”）通常是1024八位组，所以保持者正确的关系。然而如果路径MTU发现被使用，分段大小就可能不会是发送空间的约数，它可能在连接时改变；这意味着在分组长度超限探索改变了PMTU的值时TCP层可能需要改变重发窗口大小。最大窗口大小应当设为分段大小的最大倍数，小于或等于发送者的缓存空间。
5.5 其他传输协议的运行问题
一些传输协议（如ISO TP4在[ISOTP]）不允许在重发的时候重新分组。更确切的说，一旦一个传输尝试开始进行，分段具有一特定的大小，那么不允许在重发中将分段内容分成更小的分段。在这种情况下，原始分段可以在IP层的重发过程中被分为更小的段。后来的段在第一次传输中，不能大于路径MTU的允许。
Sun网络文件系统（NFS）使用远距离程序调用（RPC）协议[RPC]，当在UDP上使用时，在很多情况下都会产生有效载荷即使实在第一距离段连接时，都要进行分段。这样可能提高性能，但会引发可靠性和执行问题，特别是当客户端和服务器被路由器分开时。
不管是否包含路由器，我们都建议NFS执行使用路径MTU发现。大多数的NFS执行允许RPC数据报长度在执行期间可变（通过改变有效的文件系统字区大小，间接的改变），但是可能为了支持后面的改变需要一些修改。
同样的，由于单一的NFS操作不能被分为几个UDP数据报，特别的操作（主要是那些对于文件名和目录的操作）需要最小的有效载荷长度，使当被送到单一的分组时会大于PMTU。NFS执行不能把有效载荷长度减小到低于这个门限，即使路径MTU发现建议一个更小的值。在这种情况下，有效载荷会被IP层分段。
5.6 管理界面
我们建议执行过程提供一种方法使系统能有效进行：
－确定路径MTU探索没有在该路径上被进行。
－在一指定路径上改变PMTU值。
前者可以通过给路径附加一标记完成；当分组被送到该路径上发现作有标记，那么IP层就不再发送比IPv6最小链接MTU大的分组。
这些特征可以被应用于一些反常的情形下，或应用于路由协议执行，可以获得路径MTU值。
执行过程还应当提供能够改变用于计算陈旧PMTU信息的超时时间的方法。
6 安全考虑
本路径MTU发现机制可能引起两个负面的攻击，都是基于恶毒团体发送给节点的错误的分组长度超限信息。
第一个攻击，错误的信息指示的PMTU远小于实际。这样不能完全停止数据流，因为受害的节点永远无法将它的PMTU估计小于IPv6最小链接MTU。这样就导致了不理想的性能。
第二个攻击，错误的信息指示了PMTU大于实际。如果相信它，就会引起暂时的阻塞，受害者发送的分组会被一些路由丢弃。在一个来回时间内，该节点会发现这个错误（从路由器收到分组长度超限信息），但是经常的收到这种攻击就会使大量分组丢失。一个节点决不应在收到分组长度超限信息后增加它的估计，所以不是很容易被这种攻击影响。
恶毒团体还可以通过停止受害者接收合法的分组长度超限信息来引发问题，但是这样的话还有更简单的攻击方式存在。
致谢
我们感谢[RFC-1191]的作者和捐助者，这里的大部分文章都是源自那里。我们还感谢IPng工作组的成员，感谢他们细心的评论和有建设性的评语。
附录A － 与RFC1191的对比
本文档很大程度上基于RFC1191（描述了IPv4的路径MTU探索）。在RFC1191里的一些部分这里是不需要的：
路由器说明		－分组长度超限信息和相应的路由动作在[ICMPv6]中定义
不分段比特位	－在IPv6分组里没有DF位
TCP MSS讨论		－选择值发送到TCP MSS选项在[IPv6-SPEC]里讨论
旧式信息		－所有分组长度超限信息报告了压缩连接的MTU
MTU曲线表格		－因为没有旧式信息，所以没有必要了
参考文献
[CONG]      Van Jacobson.  Congestion Avoidance and Control.  Proc.
            SIGCOMM '88 Symposium on Communications Architectures and
            Protocols, pages 314-329.  Stanford, CA, August, 1988.
[FRAG]      C. Kent and J. Mogul.  Fragmentation Considered Harmful.
            In Proc. SIGCOMM '87 Workshop on Frontiers in Computer
            Communications Technology.  August, 1987.
[ICMPv6]    Conta, A., and S. Deering, "Internet Control Message
            Protocol (ICMPv6) for the Internet Protocol Version 6
            (IPv6) Specification", RFC 1885, December 1995.
[IPv6-SPEC] Deering, S., and R. Hinden, "Internet Protocol, Version
            6 (IPv6) Specification", RFC 1883, December 1995.
[ISOTP]     ISO.  ISO Transport Protocol Specification: ISO DP 8073.
            RFC 905, SRI Network Information Center, April, 1984.
[ND]        Narten, T., Nordmark, E., and W. Simpson, "Neighbor
            Discovery for IP Version 6 (IPv6)", Work in Progress.
[RFC-1191]  Mogul, J., and S. Deering, "Path MTU Discovery",
            RFC 1191, November 1990.
[RPC]       Sun Microsystems, Inc., "RPC: Remote Procedure Call
            Protocol", RFC 1057, SRI Network Information Center,
            June, 1988.
作者地址
Jack McCann
Digital Equipment Corporation
110 Spitbrook Road, ZKO3-3/U14
Nashua, NH 03062
Phone: [phone]
Fax:   [phone]
Email: [e-mail]

Stephen E. Deering
Xerox Palo Alto Research Center
3333 Coyote Hill Road
Palo Alto, CA 94304
Phone: [phone]
Fax:   [phone]
EMail: [e-mail]

Jeffrey Mogul
Digital Equipment Corporation Western Research Laboratory
250 University Avenue
Palo Alto, CA 94301
Phone: [phone]
EMail: [e-mail]
RFC1981――Path MTU Discovery for IP version 6                         IP 版本 6的路径MTU探索