С IPv4 «зажим» TCP MSS (сетевое устройство, редактирующее значение MSS в заголовке TCP) может помочь, когда не работает обнаружение максимального блока передачи. (например, когда ICMP блокируется где-то в пути.) Поскольку в IPv6 нет фрагментации, у нас все еще есть «слишком большой» пакет ICMPv6, чтобы сигнализировать исходную конечную точку.
Существуют ли какие-либо рекомендации относительно ограничения TCP MSS через IPv6?
Технически фрагментация может произойти в IPv6; Это статья в Википедии об этом.
Эта страница можжевельника старовата , но это показывает , что вы можете зажать МАС для TCP через IPv6 на Junos то же самое , как если бы в IPv4 , используя ту же самую команду, tcp mss. То же самое показано в этой статье для Cisco IOS 15 с использованием традиционной команды ip tcp adjust-mss.
Таким образом, вы можете настроить MSS-фиксацию, если PMTUD не работает должным образом в части вашей сети, в противном случае вы должны убедиться, что вы помогаете сглаживанию работы PTMUD в вашей сети, чтобы MSS-фиксация не требовалась ( Я понимаю, это не всегда под вашим контролем).
Обновить
Вот ссылка на более новую статью о Junos для Junos 10x, а не 9, я не могу найти один для 11, и сейчас я не впереди 11, но я ожидаю, что это будет то же самое.
Определенно существуют случаи, обычно связанные с туннелями IPv6-in-IPv4 в некоторой точке пути, где, даже если PMTUD работает правильно, согласование MSS не выполняется. В этом случае сеанс TCP может начаться правильно (поскольку пакеты SYN / ACK малы), но пакеты данных не поступают (так как эти пакеты слишком велики для туннеля). В этом случае может помочь ограничение MSS на дальнем конце, но он не находится под контролем «жертвы», ожидающей пакеты. Отказоустойчивое решение для обоих концов - установить MTU IPv6 равным 1280, который должен пройти через любой туннель.
источник