缘起

在使用OpenWRT作为主路由之后，由于网上一直说ipv6如何如何好，所以顺手将ipv6也开启了，现在基本上新安装的Openwrt都是默认将ipv6开启的。
之后上网一些正常，直到我打开微信，然后发现需要转圈很长时间才能刷新信息，而且公众号列表预览中，好多图片也无法正常显示。
网上找了一圈之后，说可能是ipv6的mtu问题。

配置

进入到 “网络”->“接口”->“设备”：

点击wan口配置，按照图中进行配置：

这里IPv6 MTU，最小设置1280，最大1472（ipv6的头比ipv4多20字节）

保存之后，就可以愉快访问了。

以前时候ipv6老是出现问题，所以一直是将ipv6进行关闭，这次研究之后，发现是mtu设置问题，看来很多问题还是需要研究一下才行

知识补充

关于 PMTU 黑洞

MTU (Maximum transmission unit) 是一条链路上可以通过的三层数据包的最大尺寸（包含 IP 包头）。以太网上默认的 MTU 是 1500 字节，但是你和目标服务器之间的路径上可能存在小于 MTU 1500 的链路。这条路径上最小的 MTU 值就是整条路径的 PMTU 值。路由器在转发包时，超过 MTU 大小的包会被分片（ Fragmentation ），也就是一个大包会被分切为多个不超过 MTU 的小包进行传输，传输效率会下降。

终端设备在发包时，也可以设置 DF （ Don’t Fragment ）标记来告诉路由器不要分片。这时中间路由器会丢掉超过 MTU 的包，回复一条 ICMP Fragmentation Needed 消息。发送者收到这个包后，下次就会发小一点的包，这个过程叫做 PMTU Discovery 。现实中可以看到 HTTPS （ TLS ）的流量大都是带 DF 标记的。

然而，互联网上有大量的中间设备为了所谓的“安全”或者没有正确配置，不回应 ICMP Fragmentation Needed 包，这使得访问某些网站时如果某个包的大小超过了 PMTU，会被无声地丢弃，直到 TCP 协议发现超时丢包进行重传，这非常缓慢。遇到这种情况，我们可以说你和目标服务器的路径上存在 PMTU 黑洞。

此外，IPv6 不支持分片，换句话说可以理解为 IPv6 下所有的包都是带 DF 标记的。中间路由器在遇到包尺寸大于 MTU 的情况时，应该回应 ICMPv6 Packet Too Big 消息。同样的，由于种种原因，某些中间设备可能会直接丢包而不回应 ICMPv6 Packet Too Big 消息，直到 TCP 协议发现超时丢包进行重传。。。

为什么 IPv4 没有这个问题

其实 IPv4 也有这个问题，我不只一次见网友说自己搭的软路由访问某些网站非常慢，而换回硬路由就正常。这是因为多数家用路由器默认对 IPv4 下的 TCP 开启了 MSS (maximum segment size) Clamping （使用 OpenWRT 软路由的朋友们可以在防火墙设置中找到 MSS Clamping 开关）。MSS Clamping 是针对 PMTU 黑洞的 Workaround，简单来说就是 TCP 握手时有个 MSS 字段决定单个 TCP 包的最大尺寸。路由器可以通过嗅探 TCP 握手包，把 MSS 值改小，使最终的三层 IP 包的尺寸（ MSS+TCP 头大小+IP 头大小）不超过某个特定的值。

总结

现在国内 ISP 一般都是通过 PPPoE 虚拟拨号建立 WAN 口连接的。Ethernet 的默认 MTU 是 1500，但是 PPPoE 隧道有 8 个 bytes 的开销，所以 PPPoE 虚连接的 MTU 就是 1500-8=1492，减掉 IPv4 包头（ 20 字节）和 TCP 包头（ 20 字节），可以得知 IPv4 下需要把 MSS 设为 1452 以下。

IPv6 的包头是 40 字节，所以 IPv6 下需要把 MSS 设为 1432 以下，所以如何不会设置MSS的话，直接将IPv6的MTU设置成1472（MTU of IPv6 - 20）。

这时问题来了，目前很多光猫、家用路由器对 IPv6 的优化很差，不支持对 IPv6 下的 TCP 包进行 MSS Clamping，这就导致访问 IPv6 网站时，若路径中存在 PMTU 黑洞，则打开很慢。