3

I have configured an IPv6-over-IPv4 tunnel via Hurricane Electric on my Linux machine. While I can ping ipv6.google.com:

bash-4.4# ping ipv6.google.com
PING ipv6.google.com(lhr48s09-in-x0e.1e100.net (2a00:1450:4009:819::200e)) 56 data bytes
64 bytes from lhr48s09-in-x0e.1e100.net (2a00:1450:4009:819::200e): icmp_seq=1 ttl=57 time=10.9 ms
64 bytes from lhr48s09-in-x0e.1e100.net (2a00:1450:4009:819::200e): icmp_seq=2 ttl=57 time=10.7 ms

HTTPS requests over IPv6 seem to time out:

bash-4.4# curl --happy-eyeballs-timeout-ms 60000 'https://mirrors.fedoraproject.org/metalink?repo=fedora-modular-29&arch=x86_64'
curl: (28) Operation timed out after 300258 milliseconds with 0 out of 0 bytes received

This is a classic sign of an MTU issue, so I suspected an MTU issue, and sure enough:

[user@nuc ~]$ tracepath6 mirrors.fedoraproject.org
 1?: [LOCALHOST]                        0.004ms pmtu 1480
 1:  xxxxxxxxxxxx-pt.tunnel.tserv1.lon2.ipv6.he.net        0.057ms pmtu 1472
 1:  xxxxxxxxxxxx.tunnel.tserv1.lon2.ipv6.he.net          22.524ms 
 2:  10ge3-20.core1.lon2.he.net                           20.266ms 
 3:  100ge7-1.core1.fra1.he.net                           32.051ms 
 4:  bb01.muc01.net.internetx.com                         47.579ms asymm  6 
 5:  no reply
 6:  no reply
 7:  no reply
 8:  no reply
 9:  no reply
10:  no reply
11:  no reply
12:  no reply
13:  no reply
14:  no reply
15:  no reply
16:  no reply
17:  no reply
18:  no reply
19:  no reply
20:  no reply
21:  no reply
22:  no reply
23:  no reply
24:  no reply
25:  no reply
26:  no reply
27:  no reply
28:  no reply
29:  no reply
30:  no reply
     Too many hops: pmtu 1472
     Resume: pmtu 1472 

The MTU of my connection is set too high (1480 instead of 1472). (The lower-than-expected MTU might be related to the fact that I have a wifi connection between my PC and my primary router.)

However, this tracepath6 command is not able to see the full path, so theoretically there could still be something with an even lower pmtu along the way. I have found RFC4821 that describes a way to do path MTU discovery even in the presence of ICMP blackholes, which I seem to be encountering here, but I haven't found a sofware implementation of RFC4821 for IPv6 in Linux. For IPv4, one can set net.ipv4.tcp_mtu_probing to 1 in sysctl, and this will make the kernel fix MTU issues transparently by probing. But I haven't found any similar setting - or userland software - for IPv6 for Linux.

So how can I do an RFC4821-style path MTU probe for IPv6 on Linux?

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Browse other questions tagged or ask your own question.