У меня есть сервер с туннелем IPv6 (sixxs) и локальной сетью за ним. Туннель имеет MTU 1470, и префикс с этим MTU объявляется radvd и принимается локальным клиентом:
root@host:~# ip -6 route
2001:xxxx:xxxx::/64 dev eth1 proto kernel metric 256 expires 298sec mtu 1470
fe80::/64 dev eth1 proto kernel metric 256 mtu 1470
default via fe80::dad3:85ff:feaf:7e77 dev eth1 proto kernel metric 1024 expires 28sec mtu 1470 hoplimit 64
Интерфейс клиента, как обычно, имеет MTU 1500. Теперь, когда я передаю файл на удаленный хост IPv6, происходит следующее (дамп пакета wirehark на сервере, интерфейс LAN, соответствующей части):
15.034320 host -> remote SSHv2 Encrypted request packet len=2796
15.034408 server -> host ICMPv6 Too big
15.241163 host -> remote SSHv2 [TCP Retransmission] Encrypted request packet len=1398
15.252193 remote -> host TCP ssh > 58188 [ACK] Seq=2658 Ack=121902 Win=64128 Len=0 TSV=2205083594 TSER=4294965684
15.252480 host -> remote SSHv2 [TCP Retransmission] Encrypted request packet len=2796
15.252558 server -> host ICMPv6 Too big
15.461151 host -> remote SSHv2 [TCP Retransmission] Encrypted request packet len=1398
Таким образом, хост отправляет пакет размером 2796 (даже не должно быть возможным, MTU канала - 1500), и сервер правильно отвечает ICMPv6 Too big. Затем пакет повторно передается с правильным размером и подтверждается. Но затем следующий пакет снова оказывается слишком большим, и процесс повторяется бесконечно, а файл передается с улиткой ... Что здесь происходит? Кеш маршрута показывает, что MTU маршрута подобрано правильно (адреса IPv6 заменены именами):
root@host:~# ip -6 route show cached
remote via fe80::dad3:85ff:feaf:7e77 dev eth1 metric 0
cache mtu 1470 hoplimit 64
server via server dev eth1 metric 0
cache mtu 1470
Ладно, дома в сети происходили более странные проблемы. Я пошел по пути Microsoft и перезагрузил сервер. Кажется, проблема ушла.