TCP的路径MTU发现问题

【TCP的路径MTU发现问题】本备忘录的状态
本文档为Internet社区提供信息 。它并不定义任何Internet标准 。本备忘录的发布不受任
何限制 。
版权声明
Copyright(C)TheInternetSociety(2000).AllRightsReserved.
摘要
本备忘录编制了几个已知和路径最大传输单元发现(PMTUD)相关的传输控制协议(TCP)实
现问题,包括长期存在的黑洞问题,由于最大段长(MSS)和段长的混淆造成的弹性确认
(ACKs)问题,以及基于PMTU的MSS通告问题 。
目录
1介绍 2
2已知的实现问题 2
2.1问题名字 2
2.2问题名字 4
2.3问题名字 7
3安全考虑 9
4致谢 9
5参考 9
6作者地址: 10
7完整的版权说明 10
1介绍
本备忘录编制了几个已知和路径最大传输单元发现(PMTUD)相关的传输控制协议(TCP)实
现问题,包括长期存在的黑洞问题,由于最大段长(MSS)和段长的混淆造成的弹性确认
(ACKs)问题,以及基于PMTU的MSS通告问题 。这么做的目的是通过改进当前TCP/IP实现
的质量来改善目前Internet的环境 。
路径MTU发现(PMTUD)可被任何上层协议使用,但通常TCP用得最多 。本文档不打算涉及
其它上层协议碰到的问题 。Ipv6的路径MTU发现[RFC1981]只处理与Ipv6相关的情况,不
是本文档要讨论的情况 。
每个问题按如下定义:
问题名字
与问题相联系的名字 。在本备忘录中,名字作为子小节的标题 。
分类
该问题的更多分类是:“拥塞控制”,“性能”,“可靠性”,“非互操作――连接
失败” 。
描述
问题定义,简洁但包括了必要的背景材料 。
意义
对几个环境的简单总结表明问题的意义 。
含义
为什么这个问题被当作一个问题 。
相关RFC
和该问题相抵触的定义TCP的RFC 。这些RFC通常使用术语如必须,应该,可以及其它
大写的词语指示该如何动作 。这些术语的确切解释见RFC2119 。
阐述问题的输出文件
若合适的话,给出一个或多个ASCII输出文件阐述问题
解释什么是正确处理的输出文件
若合适的话,给出一个或多个ASCII输出文件解释正确处理的输出
参考
对问题进一步讨论的参考材料
如何检测
如何对实现测试来检查是否有这个问题 。
如何修改
对原因已明的问题,如何改正实现 。
2已知的实现问题
2.1问题名字
黑洞检测
分类
非交互操作――连接失败
描述
主机执行路径MTU发现方法是发送尽可能大的包,在IP头置上不要分片位(DF) 。若
包太大无法由路由器转发到特定路径,路由器必须给源地址发送一个目的不可达――需要
分片的ICMP消息 。主机将基于这个ICMP消息调整包大小 。
正如[RFC1435]中指出的,路由器并不总能正确处理这种事件――许多路由器未能发送
ICMP消息,或是由于核心的bug或是由于配置原因等 。若实现遵守相关文档的建议,
Ipsec[RFC2401]和IP-in-IP[RFC2003]隧道不应引起这种问题 。
如[RFC1191]中指出的,当原始主机未能收到合适的ICMP消息时PMTUD失败 。没有
ICMP消息通知就无法发现需要减小包大小,上层协议则继续尝试发送大包 。它发的包在
PMTUD黑洞中消失 。
意义
当由于没有ICMP消息导致PMTUD失败时,TCP在某些条件下也会完全失效 。
含义
因为到目的主机的ping和某些交互式TCP连接是正常的,这种故障尤其难查 。大流量
传输在第一个大包即失败而连接最终超时 。

推荐阅读