TCP最大段大小（MSS）是否“钳位”与IPv6兼容？

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

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

从技术上讲，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的前面，但是我希望它会保持不变。

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