大家好，我最近在MikroTik上按照官方帮助文档里Hurricane Electric的示例搭建了6to4 SIT隧道，遇到了MTU相关的棘手问题，想请教下各位大佬怎么解决：

最开始我用的是文档推荐的1280 MTU，隧道能正常连通，但访问部分资源时速度慢到离谱，还经常超时。比如在升级和配置Guix时，默认服务器的下载速度一直卡在50 KiB/s左右，下载内核这种大体积包的时候基本都会失败。

后来隧道服务商的技术支持说1280的MTU太小，建议改成1480。我改完之后，速度直接恢复正常，能跑到MiB级。我猜应该是减少了数据包分片的额外开销，但具体原理也不是太清楚。

但新问题又来了：现在访问某些服务器时，连接会直接挂住。比如guix pull会卡住不动，用curl -v访问有问题的URL，要么是TLS协商超时（提示curl: (28) SSL connection timeout），要么是加密库报错（curl: (35) gnutls_handshake() failed: Помилка у функції pull.）。

我试了下ping这些服务器是能通的，但如果用MTU大小的包去ping（也就是ping6 -s指定对应字节数），第一个包会返回“Packet too big”，后面的包就直接丢了。TCP连接能建立，但TLS协商就是超时，明显是这条路径的MTU比我隧道设置的1480要小。

查了相关RFC的内容：

RFC 4213规定：使用静态隧道MTU的节点，隧道接口的MTU必须在1280到1480字节之间（包含两端值），默认推荐用1280字节。
RFC 6343里有一节讲“PMTUD Failure”，里面提到如果遇到ICMP黑洞问题，应该回退到1280的IPv6 MTU，除非能解决黑洞问题。

MikroTik的示例配置用1280也是为了避免MTU协商的麻烦，而且默认开启了clamp-tcp-mss设置，它的作用是：

控制是否修改收到的TCP SYN包的MSS大小。开启后，如果当前MSS超过隧道接口的MTU（考虑TCP/IP开销），路由器会修改MSS值。封装后的包还是保留原始MSS，只有在解封装后才会修改。

这个设置可能解释了为什么我有时候能通过隧道发送大到65527字节的包（应该是65535减8），但它只是匹配隧道的MTU，而我需要的是针对每个连接动态判断合适的MTU，而不是为了兼容少数服务器就把全局隧道MTU降回1280牺牲速度。有没有什么办法能实现这个需求呢？

备注：内容来源于stack exchange，提问作者Roman Riabenko