Кратко

  • RFC 1063 ввёл четырёхбайтовые опции Probe MTU (11) и Reply MTU (12), чтобы найти и вернуть наименьший MTU на IPv4-маршруте.
  • RFC 1191 заменил накопление данных в успешно идущем пакете сигналом об отказе: битом DF и ICMP Type 3, Code 4 со значением MTU следующего перехода.

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

Структура обеих опций была предельно короткой: байт типа, байт длины со значением четыре и два байта MTU. Тип 11 собирал минимум, тип 12 возвращал его. В предпочтительной для RFC 1063 реализации на уровне IP получение зонда создавало ровно одну ответную опцию в обратной дейтаграмме, после чего временное значение удалялось.

Измерение становилось обязанностью всего пути. Маршрутизатор должен был не только переслать пакет, но и обработать изменяемую опцию. Авторы отмечали, что некоторые шлюзы во время обработки IP-опций ещё не знали обе нужные интерфейсные MTU; поддержка могла потребовать серьёзной переделки. Поэтому зонды советовали посылать примерно раз за время кругового пути, а не с каждой дейтаграммой.

Кэш обновлялся несимметрично. Меньшее значение принималось сразу. К большему следовало переходить лишь после старения прежней оценки: при колебании маршрутов более безопасным считался сохранённый минимум.

RFC 1191 официально объявил RFC 1063 устаревшим и перенёс наблюдение в точку отказа. Хост выставлял Don't Fragment. Если дейтаграмма не помещалась в следующий канал, маршрутизатор отбрасывал её и отправлял ICMP Destination Unreachable, Type 3, Code 4. Младшие 16 бит прежде неиспользуемого поля содержали наибольший размер дейтаграммы, который можно было переслать без фрагментации; старшие 16 бит оставались нулевыми.

Успешные пакеты больше не несли изменяемый минимум. Для маршрутизатора новое поле было единственным требуемым изменением, но хосту приходилось быстро уменьшать оценку, понимать старые ICMP с нулём и редко проверять возможное увеличение. Иными словами, работа исчезла не полностью, а сменила место.

В 2014 году RFC 7126 назвал обе опции устаревшими, отметил риск искусственно завышенной или заниженной оценки и рекомендовал отбрасывать содержащие их пакеты. Это не статистика внедрения. Источники подтверждают устройство механизма, его замену и поздний операционный статус, но не масштабы реального использования.

Источники