Кратко

  • Положительный ответ доказывает, что идентифицированная проба данного размера достигла удалённого уровня пакетизации по наблюдавшемуся пути.
  • RFC 8201 рассматривает MTU пути как изменяющееся состояние; RFC 8899 требует повторного подтверждения и отдельного автомата для каждого пути при multipath или multihoming.
  • Проверяемая запись должна связывать конечные точки, поток или путь, накладные расходы, пробу, ответ, время и доставку репрезентативных данных.

Верное измерение с неверно расширенной областью

Сервис отправляет пробу, дополненную до 1450 байт. Получатель подтверждает именно её, и отправитель повышает PLPMTU. Вскоре прикладная датаграмма такого же размера назначается другому члену ECMP. Там туннель добавляет больше заголовков либо встречается канал с меньшей эффективной MTU, и пакет не доходит.

Первое наблюдение остаётся истинным. Оно описывает конкретный пакет и путь в конкретный момент. Оно не измеряло все параллельные члены и будущую трассу. Запись «MTU OK» выбрасывает идентификатор пробы, ключи потока, поколение маршрута, накладные расходы и возраст подтверждения.

IPv6 PMTUD поддерживает оценку

RFC 8201 определяет PMTU как минимальную MTU канала на пути между источником и назначением. Источник может начать с MTU первого перехода и уменьшить оценку после проверки ICMPv6 Packet Too Big. Иногда требуется несколько циклов: ещё более узкое звено может находиться дальше.

При изменении топологии меняется и PMTU. Снижение выявляется через PTB, а рост — периодическими попытками отправить пакет большего размера. После снижения RFC 8201 рекомендует пробовать повышение не чаще одного раза в пять минут. Значение в кэше имеет срок и правило обновления, а не является вечным свойством назначения.

Даже проверенное PTB свидетельствует лишь об ограничении для связанной отправки. Оно само по себе не объясняет, какой маршрут сменился, какой туннель добавил байты и одинаковы ли пределы всех параллельных путей.

Что подтверждает DPLPMTUD

RFC 8899 переносит поиск на уровень, формирующий датаграммы. Отправитель выбирает размер и получает обратную связь, что именно эта проба достигла удалённого уровня. После подтверждения размер может стать текущей PLPMTU.

Это надёжнее вывода об успехе по молчанию, но область доказательства узка. Одна потеря не означает проблему MTU: возможны перегрузка, ошибка и переупорядочивание. Одно подтверждение также не превращает Search Complete в пожизненную гарантию. Если иных данных о доставке нет, таймер подтверждения повторно проверяет текущий размер.

Метод должен выдерживать смену пути, противоречивые сведения, задержку, дублирование, переупорядочивание и разделение трафика по нескольким путям. При multipath или multihoming RFC 8899 требует отдельный автомат состояния для каждого пути. Единого зелёного признака назначения недостаточно.

Накладные расходы входят в бюджет

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

Поэтому в записи нужны уровень измерения и бюджет заголовков. Повторные потери, связанные с размером, оправдывают осторожное снижение, но не доказывают причину. Фильтрация, перегрузка, состояние получателя и обычная потеря остаются отдельными версиями.

Источники