Кратко

  • REQ несёт четырёхоктетный маркер, EOL дополняет пакет до проверяемого размера, а совпавший RES подтверждает получение именно этого зонда обработчиком UDP Options.
  • Результат ограничен 5-tuple, путём и временем. ECMP, несколько путей и multihoming требуют отдельного состояния и периодической проверки PLPMTU.
  • Задержка RES может быть вызвана ожиданием обратного трафика, ограничением частоты или потерей ответа. Молчание само по себе не доказывает недостаточную ёмкость прямого пути.

Квитанция относится к одной попытке

RFC 9869 применяет DPLPMTUD к UDP Options. Отправитель помещает маркер в REQ и дополняет область опций с помощью EOL до выбранного размера. Зонд может быть больше текущей оценки PLPMTU, но не MTU интерфейса; IP-фрагментация запрещена. Получатель возвращает последний увиденный маркер в RES.

Совпадение устанавливает конкретный факт: этот зонд дошёл до удалённой обработки UDP Options. Оно не подтверждает доставку или принятие данных приложением, не измеряет максимальный размер обратного пути и не обещает, что следующий пакет пойдёт той же дорогой.

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

Срок жизни маркера сохраняет атрибуцию

В пределах одного 5-tuple маркер обязан быть уникальным на протяжении Maximum Segment Lifetime и не должен повторяться в этом окне. Случайное начало и непредсказуемая последовательность затрудняют подделку вне пути. Но одной итоговой PLPMTU недостаточно: нужны размер, адреса и порты, путь, время отправки и ответа, попытка, состояние и версия реализации.

Оба приложения должны явно включить услугу; до этого получатель не вправе отправлять RES. Если транспорт и верхний протокол одновременно запускают DPLPMTUD, им следует координировать или разделять маркеры. Настоящий ответ, отнесённый к чужому автомату, остаётся неверно связанным свидетельством.

Механизм предназначен прежде всего для unicast и не поддерживает multicast. Получатель может создать пустой ответ для ускорения процедуры, однако поток одних ответов должен ограничиваться по частоте.

Измеренный путь не представляет соседние

При ECMP, multipath или multihoming RFC 9869 требует независимого состояния на каждый путь. Ограничивающий канал принадлежит реально пройденному маршруту, а не имени адресата. Перенос успешного значения на альтернативу заменяет измерение предположением.

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

Молчание может возникнуть на обратном пути

Получатель вправе ждать запланированную обратную дейтаграмму, чтобы добавить RES. Если до неё придут несколько зондов, подтверждён может быть лишь последний маркер; более ранние успешно доставленные зонды покажутся потерянными. При редком обратном трафике отправитель способен остановиться ниже реальной ёмкости или на минимальной PLPMTU.

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

Обработка ICMP Packet Too Big необязательна. При использовании надо проверить процитированный протокол и по возможности маркер REQ. Непроверяемое сообщение следует игнорировать. Непредсказуемые маркеры мешают внедрению вне пути, но не устраняют возможность вмешательства на самом пути.

Источники