为什么开启 ipv6 就会有大量 tcp 重传，兄弟们也这样吗？

[sartner]

开启 ipv6 就会有大量 tcp 重传（有公网 v6 地址），卡的要死。关了 v6 就正常，几乎没有重传。

mtu 1492
mss 1360

测试方式：
curl -6 https://test.ipw.cn ，抓包
基本上 5 次里面就有 1 次大量重传。
兄弟们也这样吗？
武汉电信

[buf1024]

因为有针对 ipv6 的 tcp 阻断

[Int100]

@buf1024 ？这么搞意义何在

[heiher]

进一步降低 mtu 试试？

[iijboom]

https://v2ex.com/t/800024

[xqzr]

提供抓包截图/文件

[liuyee]

同电信，一模一样，现在已经把 IPv6 关了

[465456]

主路由 openwrt ，刚试了抓包，没问题

[miaomiao888]

曾经遇过 IPV6 路由黑洞，原本用的很旧的路由器里有个 MTU 设置，改了也不行，后来怀疑这个设置应该只针对 IPV4 而对 IPV6 无效，最终换了个华硕路由器就没问题了。

[xqzr]

> 原本用的很旧的路由器里有个 MTU 设置，改了也不行

正常的路由器都是这样
https://www.v2ex.com/t/1125564?p=1#r_16144828

[pagxir]

DNS 作下处理，IPv4 优先就好了。v6 目前路由还是不太行

[c398425861]

开启 MSS 钳制

[TonyBoney]

由于 ipv6 不能在中途分片，而且某些运营商会丢弃提示包过大的 ICMP 信息，导致了许多包石沉大海，最终连接失败。看看这篇 cloudflare 的博客文章，按照他们的测试结果不断调整自己的 mtu 和 mss ，直到连接正常，他们观察到 89.8%对端的 MTU 大于 1380+40=1420 ，75%的 MTU >= 1452:
https://blog.cloudflare.com/increasing-ipv6-mtu/

[swananan]

tcp 重传会持续很久吗？给个复现的抓包看看？
理论上 TCP 协议栈早早支持了 https://datatracker.ietf.org/doc/html/rfc4821
所以哪怕有 ICMP 黑洞，也能依赖 TCP 数据段快速探测出来真实的 MTU ，然后自动调整

[JensenQian]

上网的话直接屏蔽 ipv6 解析算了

[sartner]

截图和抓包文件在这，实在没招了
https://github.com/Sartner/share/tree/main/20240428


@swananan
@xqzr

[xqzr]

抓包文件只有，客户端发送（上行）包，反方向的（下行）包没有。
ping 会丢包吗？

[sartner]

抱歉，刚又重新抓包重传了一下。 @xqzr
试了一下，ping 也丢
直接在主路由（ ikuai ）上 ping6 ，也丢

root:~# dig AAAA www.baidu.com
www.a.shifen.com. 493 IN AAAA 240e:ff:e020:99b:0:ff:b099:cff1

root:~# ping 240e:ff:e020:99b:0:ff:b099:cff1
PING 240e:ff:e020:99b:0:ff:b099:cff1(240e:ff:e020:99b:0:ff:b099:cff1) 56 data bytes
64 bytes from 240e:ff:e020:99b:0:ff:b099:cff1: icmp_seq=2 ttl=53 time=20.8 ms
64 bytes from 240e:ff:e020:99b:0:ff:b099:cff1: icmp_seq=4 ttl=53 time=20.8 ms
64 bytes from 240e:ff:e020:99b:0:ff:b099:cff1: icmp_seq=5 ttl=53 time=21.0 ms
64 bytes from 240e:ff:e020:99b:0:ff:b099:cff1: icmp_seq=6 ttl=53 time=20.9 ms
64 bytes from 240e:ff:e020:99b:0:ff:b099:cff1: icmp_seq=7 ttl=53 time=20.7 ms
64 bytes from 240e:ff:e020:99b:0:ff:b099:cff1: icmp_seq=8 ttl=53 time=20.8 ms
64 bytes from 240e:ff:e020:99b:0:ff:b099:cff1: icmp_seq=11 ttl=53 time=20.8 ms
^C
--- 240e:ff:e020:99b:0:ff:b099:cff1 ping statistics ---
11 packets transmitted, 7 received, 36.3636% packet loss, time 10134ms
rtt min/avg/max/mdev = 20.724/20.842/21.036/0.095 ms

root:~# ping -s 1300 240e:ff:e020:99b:0:ff:b099:cff1
PING 240e:ff:e020:99b:0:ff:b099:cff1(240e:ff:e020:99b:0:ff:b099:cff1) 1300 data bytes
1308 bytes from 240e:ff:e020:99b:0:ff:b099:cff1: icmp_seq=4 ttl=53 time=20.9 ms
1308 bytes from 240e:ff:e020:99b:0:ff:b099:cff1: icmp_seq=5 ttl=53 time=21.0 ms
1308 bytes from 240e:ff:e020:99b:0:ff:b099:cff1: icmp_seq=6 ttl=53 time=20.9 ms
1308 bytes from 240e:ff:e020:99b:0:ff:b099:cff1: icmp_seq=7 ttl=53 time=20.6 ms
1308 bytes from 240e:ff:e020:99b:0:ff:b099:cff1: icmp_seq=9 ttl=53 time=20.7 ms
1308 bytes from 240e:ff:e020:99b:0:ff:b099:cff1: icmp_seq=13 ttl=53 time=20.7 ms
1308 bytes from 240e:ff:e020:99b:0:ff:b099:cff1: icmp_seq=14 ttl=53 time=21.0 ms
^C
--- 240e:ff:e020:99b:0:ff:b099:cff1 ping statistics ---
14 packets transmitted, 7 received, 50% packet loss, time 13237ms
rtt min/avg/max/mdev = 20.640/20.834/21.045/0.148 ms

[swananan]

看了抓包，我觉得不是 mtu 的问题，中间有丢包和乱序，但是对端最后都 ack 了，所以长度比较大的包（比如 1414 字节的）还是最终到了对端。

我更感觉是 ipv6 链路有问题，在主路由上面 ping6 也丢包，是不是主路由的网线松了（考虑到 ipv4 不受影响，感觉概率很低）。。。或者你再梳理下家里的网络拓扑线路，排除法看看哪个线路有问题。

[xqzr]

运行 mtr

[xqzr]

从外部运行 mtr ，显示从城域网开始丢包

目标：240e:368:20b:44c:e036:7a94:8c06:971a
Host % Sent Recv Best Avrg Wrst Last
2409:8080:0:2:306:372:: [中国 中国移动骨干网] 0 543 543 6 6 28 7
2409:8080:0:1:306:504:1:1 [中国 中国移动骨干网] 0 543 543 21 22 40 23
2409:8080:0:1:504:5e2:0:1 [中国 中国移动骨干网] 50 185 94 21 21 28 27
2409:8080:0:3:5e2:580:17:1 [中国 中国移动骨干网] 74 140 37 22 24 50 24
240e::d:5:5100:402 [中国 中国电信 163 骨干网] 1 539 538 22 23 50 23
240e:d:1001:f018::3 [中国 湖北省 武汉市 中国电信城域网] 58 168 72 0 26 30 27
240e:d:1001:fd2::3 [中国 湖北省 武汉市 中国电信城域网] 46 195 106 24 24 30 25
240e:368:20b:44c:e036:7a94:8c06:971a [中国 湖北省 武汉市 江汉区 中国电信公众宽带] 41 211 126 0 25 27 25

目标：240e:36d:304:3801::3ee
Host % Sent Recv Best Avrg Wrst Last
2409:8080:0:2:306:372:: [中国 中国移动骨干网] 1 283 282 6 6 20 7
2409:8080:0:1:306:504:0:1 [中国 中国移动骨干网] 0 287 287 25 26 36 26
2409:8080:0:1:504:5e2:0:1 [中国 中国移动骨干网] 87 66 9 21 21 24 22
2409:8080:0:3:5e1:581:0:1 [中国 中国移动骨干网] 68 78 25 0 27 28 27
240e::d:5:7100:302 [中国 中国电信 163 骨干网] 3 266 260 34 35 51 35
240e:d:1001:f024::3 [中国 湖北省 武汉市 中国电信城域网] 27 142 104 0 24 27 26
240e:d:1001:fd2::3 [中国 湖北省 武汉市 中国电信城域网] 50 98 49 24 24 27 25
240e:368:20b:44c:e036:7a94:8c06:971a [中国 湖北省 武汉市 江汉区 中国电信公众宽带] 44 106 60 24 25 28 25
Destination host unreachable. 100 61 0 0 0 0 0
Destination host unreachable. 100 62 0 0 0 0 0
Destination host unreachable. 100 62 0 0 0 0 0
Destination host unreachable. 100 61 0 0 0 0 0
Destination host unreachable. 100 61 0 0 0 0 0
Destination host unreachable. 100 61 0 0 0 0 0
Request timed out. 100 61 0 0 0 0 0
Request timed out. 100 61 0 0 0 0 0
Request timed out. 100 61 0 0 0 0 0
Request timed out. 100 62 0 0 0 0 0

[sartner]

试了一下 mtr ，目标是阿里云 v4 和 v6 的 dns 地址。
v6 的第二跳是不丢包的，第三跳开始就有点奇怪了。
我反馈给电信那边了，还没回复我。

> mtr -6 -c 100 -r 2400:3200:baba::1
HOST: dns Loss% Snt Last Avg Best Wrst StDev
1.|-- ikuai.lan 0.0% 100 0.2 0.2 0.1 0.3 0.0
2.|-- 240e:d:1000::fd 0.0% 100 3.9 4.1 3.3 9.2 1.0
3.|-- 240e:d:1002:fd2::2 92.0% 100 5.0 7.0 3.2 10.6 2.6
4.|-- 240e:d:1002:f00d::2 61.0% 100 3.0 4.5 2.9 20.8 3.9
5.|-- 240e::1:32:91:1302 67.0% 100 19.2 19.4 18.6 26.3 1.8
6.|-- 240e:1f:6000:83::3 44.0% 100 19.3 19.9 19.1 31.7 2.2
7.|-- ??? 100.0 100 0.0 0.0 0.0 0.0 0.0
8.|-- 240e:97c:4000:0:113:96:60 47.0% 100 34.9 22.6 19.6 42.1 5.5
9.|-- ??? 100.0 100 0.0 0.0 0.0 0.0 0.0
10.|-- ??? 100.0 100 0.0 0.0 0.0 0.0 0.0
11.|-- 2400:3200:baba::1 45.0% 100 20.7 20.6 20.4 20.8 0.1

v4 完全不丢
> mtr -4 -c 100 -r 223.5.5.5
Start: 2025-04-29T10:41:50+0800
HOST: dns Loss% Snt Last Avg Best Wrst StDev
1.|-- ikuai.lan 0.0% 100 0.1 0.1 0.1 0.5 0.1
2.|-- 100.64.0.1 0.0% 100 4.1 4.2 3.4 12.8 1.2
3.|-- 111.175.172.161 0.0% 100 3.6 7.3 3.2 11.3 2.3
4.|-- 116.211.80.166 0.0% 100 3.3 3.3 3.1 10.3 0.7
5.|-- 116.211.88.2 0.0% 100 4.3 4.4 4.0 10.4 0.7
6.|-- 116.211.226.46 0.0% 100 5.8 6.7 5.6 45.0 4.4
7.|-- ??? 100.0 100 0.0 0.0 0.0 0.0 0.0
8.|-- ??? 100.0 100 0.0 0.0 0.0 0.0 0.0
9.|-- public1.alidns.com 0.0% 100 5.2 5.2 4.9 5.4 0.1