TCP最大段大小(MSS)是否“钳位”与IPv6兼容?


9

使用IPv4,当路径最大传输单位发现不起作用时,TCP MSS“钳制”(在TCP报头中编辑MSS值的网络设备)可以提供帮助。(例如,当ICMP被阻塞在路径中的某个位置时。)由于IPv6中没有碎片,因此我们仍然有ICMPv6的“数据包太大”,无法用信号通知始发端点。

是否有专门针对通过IPv6夹紧TCP MSS的指南?

Answers:


14

从技术上讲,IPv6中可能会发生碎片;是关于它的维基百科文章。

Juniper页面有些陈旧,但它表明您可以像使用IPv4中一样使用相同命令来为Junos上的IPv6夹紧TCP的MSS tcp mss。这同样示出在文章的Cisco IOS 15,采用传统IP TCP adjust-mss命令。

因此,如果PMTUD不能正常工作,您可以配置MSS限制,因为它应该在网络的一部分中,否则,您应确保您正在协助整个网络中PTMUD的平滑运行,从而不需要MSS限制(我了解这并不总是在您的控制之下)。

更新资料

是指向Junos 10x(而不是9)的Junos文章的链接,我找不到11的文章,并且我现在不在11的前面,但是我希望它会保持不变。


...我能正确阅读碎片说明吗?IPv4分段可能在路由的任何跃点上发生,而在IPv6中,路由器必须丢弃数据包(通过ICMPv6进行通知),然后由端点完成分段?
克雷格·君士坦丁

2
对,那是正确的。除非路由器充当主机,否则路由器不会完成v6中的分段。IE:通过v6等管理流量
-bigmstone

1
这里有一个细微之处,至少调整-MSS的IOS版本被打破,因为它夹V6,但不正确:blog.ioshints.info/2013/01/...
LapTop006

2

肯定存在某些情况-通常在路径上的某些点涉及IPv6-in-IPv4隧道-即使PMTUD正常工作,MSS协商也会失败。在这种情况下,TCP会话可能会正确启动(因为SYN / ACK数据包很小),但是没有数据包到达(因为这些数据包对于隧道而言太大)。在这种情况下,远端的MSS钳位将有所帮助,但不受“受害者”等待数据包的控制。故障安全解决方案是为两端将IPv6 MTU设置为1280,该MTU应该通过任何隧道。

By using our site, you acknowledge that you have read and understand our Cookie Policy and Privacy Policy.
Licensed under cc by-sa 3.0 with attribution required.