IPv4 фрагментирует в пути; IPv6 вместо этого отправляет сообщение о слишком большом пакете

Сбои IPv6 гораздо чаще списывают на протокол, чем на размер пакета, который их вызвал. Два семейства действительно по-разному обращаются с слишком большим пакетом, и именно туннель делает эту разницу важной. Маршрутизаторы IPv4 могут фрагментировать пакет, когда правила это разрешают, а маршрутизаторы IPv6 не должны фрагментировать в пути вовсе. IPv6 вместо этого сообщает отправителю, и от отправителя ожидают реакции. Всё, что потом идёт не так, зависит от того, доходит ли это сообщение.

Что делает каждое семейство

Таблица — это механизм в четырёх строках, и одна строка объясняет большую часть путаницы.

У IPv6 нет фрагментации в пути и нет флага DF, который нужно сбросить, поэтому не на что опереться, когда пакет слишком велик. Отправителю нужно сказать, и отправитель должен в это поверить.

Туннель тихо сужает путь

VPN добавляет внешние заголовки, а в зашифрованном случае и данные целостности, прежде чем пакет покинет хост. Внутренний пакет может уместиться в MTU интерфейса, который он видит, тогда как внешний пакет превышает предел следующего звена, и поэтому это в первую очередь проявляется в туннеле. Намеренно понизьте MTU интерфейса туннеля или зажмите TCP MSS на пути и запишите, какое число вы выбрали и почему.

Накладные расходы ESP зависят от режима и алгоритмов, поэтому правильный MTU туннеля — это расчёт, а не соглашение. Что бы вы ни выбрали, оно должно оставлять место для полного внутреннего пакета IPv6 размером 1280 байт, потому что каждое звено IPv6 обязано нести столько. Туннель, который не может нести 1280 байт IPv6, — это не проблема настройки; это сломанный путь для этого семейства. Именно это ограничение исчезает, когда значение MTU копируют из развёртывания только с IPv4.

Почему симптом выглядит как зависание

Сбой не является чистой ошибкой, и поэтому его неверно диагностируют. Рукопожатие TCP завершается, небольшие ответы приходят, и соединение замирает, как только начинается большой ответ или массовая загрузка, потому что это первые пакеты, достаточно большие, чтобы их отбросили. SSH подключается и затем зависает на первом большом выводе, а заголовок страницы загружается, пока тело так и не заканчивается.

Если сообщения ICMPv6 о слишком большом пакете фильтруются, отправитель так и не узнаёт и продолжает повторять тот же размер. Это чёрная дыра, а не медленный путь, и её признак — повторяемая граница размера, а не случайная потеря. Разрешать соответствующий управляющий трафик — часть работающего развёртывания IPv6, а не любезность.

Не отключайте сообщения, от которых зависит ваш собственный путь, и не описывайте результат как сбой IPv6. Тот же довод относится к сообщениям Fragmentation Needed в IPv4, которые столь же непопулярны у авторов межсетевых экранов и столь же необходимы.

Измерьте границу, затем исправьте уровень

Проверяйте, а не гадайте: используйте флаг don't-fragment в IPv4 и фиксированные размеры полезной нагрузки в IPv6, и записывайте, где ответы прекращаются. ping -M do -s 1472 и ping -6 -s 1400 достаточно, чтобы определить форму проблемы, а tracepath сообщает обнаруженный MTU пути по дороге.

Затем исправьте тот уровень, которому принадлежит число: MTU интерфейса туннеля, зажим MSS для TCP или сам путь. RFC 8200 — это ссылка для правила IPv6, и её читать короче, чем разбирать инцидент, который она предотвращает.

Проверяйте то семейство, которое приложение действительно использует, потому что имя с двойным стеком может отвечать в одном семействе и не отвечать в другом, а приложение может переключиться после изменения сети. Запишите адрес, который вы проверили, потому что результат по записи A ничего не говорит о записи AAAA.

Относитесь к границе размера как к доказательству

Повторяемая граница размера — одна из немногих сетевых неисправностей, которая воспроизводится точно, при том же числе байт, из того же источника, каждый раз. Это делает её подарком, а не загадкой, и означает также, что исправление можно проверить, а не надеяться на него.

Запишите в заявку обнаруженный MTU, настроенный MTU туннеля и тест, который доказал разницу. Следующий человек встретит ту же арифметику на другом звене.