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