Кратко

  • В IPv4 сообщение Parameter Problem сопровождало отбрасывание пакета, а восьмибитный Pointer называл октет заголовка, где была обнаружена ошибка.
  • ICMPv6 расширил Pointer до 32 бит и разделил ошибочное поле, неизвестный Next Header и неизвестную опцию, позволив координате уходить вдоль цепочки расширений.
  • Pointer может указывать дальше конца возвращённой цитаты. Точное число не аутентифицирует сообщение, не доказывает первопричину и не разрешает читать за границей полученного буфера.

Отказ, у которого появилась координата

RFC 792 в 1981 году описал ситуацию, когда хост или шлюз IPv4 обнаруживает в заголовке параметр, из-за которого обработку невозможно завершить. Дейтаграмма подлежит отбрасыванию. Если именно эта ошибка заставила её отбросить, источнику можно было отправить ICMP Type 12 — Parameter Problem.

При Code 0 восьмибитное поле Pointer задавало номер октета исходного IPv4-заголовка, где нашли проблему. Значение 1 могло указывать на тогдашний Type of Service, а 20 при наличии опций — на тип первой опции. Координата могла попасть и внутрь опции.

Так немой результат «не сработало» получил проверяемую деталь. Источник мог сопоставить смещение со своим сериализатором, настройкой или записью пакета. Узел-получатель отвечал за решение отбросить; источник — за проверку созданных им байтов.

RFC 792 возвращал также Internet Header и первые 64 бита данных. Для ранних TCP и UDP восьми октетов часто хватало, чтобы увидеть порты и найти процесс. Цитата помогала понять, к какой отправке относится ошибка, Pointer — где остановился разбор.

Однако ICMP не обещал надёжной обратной связи. Управляющее сообщение могло не создаться, быть отфильтровано или потеряться. Отсутствие Parameter Problem никогда не доказывало, что пакет принят.

Ошибку нужно сообщить, но она не командует соединением

RFC 1122 включил Parameter Problem в требования к хостам. Если удаётся определить исходный процесс, информацию следует передать выше. Для TCP такая ошибка должна сообщаться приложению, но не является безусловной командой закрыть соединение. Решение остаётся у слоя, который знает состояние операции.

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

RFC 1812 уточнил проверку на IPv4-маршрутизаторе. Неверная дейтаграмма отбрасывается и обычно регистрируется. Если часть заголовка ещё безопасно читается, Pointer может назвать Internet Header Length или Total Length. Но один и тот же сбой проверки бывает следствием обрезки на канальном уровне, повреждения, другой версии IP или незаконной генерации источником. Позиция не выносит приговор о первопричине.

Цитировать разрешалось столько исходной дейтаграммы, сколько помещалось без превышения минимального буфера сборки IPv4 в 576 байт. Контекста стало больше, но ответ не превратился в неограниченное усиление.

IPv6 вынес ошибку за пределы фиксированного заголовка

IPv4-заголовок вместе с опциями не длиннее 60 байт, поэтому одного октета достаточно. В IPv6 после 40-байтного базового заголовка может идти упорядоченная цепочка расширений. Каждое поле Next Header выбирает следующий элемент, и ошибка способна находиться далеко от начала.

RFC 2463 в 1998 году определил ICMPv6 Parameter Problem Type 4 с 32-битным Pointer. Значение стало смещением в октетах от начала вызвавшего пакета. Code 0 означает ошибочное поле заголовка, Code 1 — неизвестный Next Header, Code 2 — неизвестную опцию IPv6. RFC 4443 сохранил эту модель в 2006 году.

Пример Code 1 и Pointer 40 означает: не распознано значение сразу после базового заголовка. Число 40 не обозначает количество переходов или серьёзность. Это адрес поля внутри конкретного пакета.

RFC 8200 связывает адрес с порядком обработки. Нельзя перескочить неизвестный переход и поискать знакомый протокол дальше. Если узел обязан продолжить, но не знает текущий Next Header, он отбрасывает пакет и указывает именно на это значение. Некоторые классы неизвестных опций используют Code 2; их action bits — отдельный механизм.

Pointer фиксирует границу понимания одного парсера. Он не подтверждает, что последующие заголовки проверены, и не обещает отсутствие других ошибок.

Координата переживает усечённую цитату

Ошибка ICMPv6 должна включать как можно больше вызвавшего пакета, но вся ответная дейтаграмма не может превысить минимальный MTU IPv6. Длинная цепочка расширений способна вынести ошибочное поле за пределы помещающегося фрагмента.

RFC 4443 не подменяет координату последним доступным байтом. Pointer вправе указывать за конец тех байтов исходного пакета, которые реально находятся в ICMPv6-сообщении. Источник узнаёт: сообщивший узел остановился на N. Самого байта N в ответе может не быть.

Это честная неполнота. Обрезать значение — значит обвинить другое поле. Раздувать ответ без предела — значит пожертвовать контролем ресурсов. Протокол одновременно хранит известное место и видимое отсутствие содержимого.

Поэтому Pointer нельзя без проверки использовать как индекс массива. Корректная координата полного пакета может находиться вне локального буфера. RFC 8883 прямо требует сначала сравнить значение с фактической длиной цитаты.

Цитата может закончиться и до заголовка верхнего уровня. Тогда хост не сумеет определить процесс для уведомления, и сообщение будет отброшено после сетевой обработки. Точная позиция не гарантирует доставку диагностики приложению.

Иногда проблема — это предел парсера, а не синтаксис

RFC 8883 в 2020 году добавил коды 5–10. Они сообщают о неизвестном Next Header на промежуточном узле, слишком большом расширении, слишком длинной цепочке, лишнем количестве заголовков или опций и слишком большой опции. Pointer указывает на неизвестное значение, первый октет за лимитом или первый элемент сверх допустимого количества.

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

Так ограничение реализации не выдаётся за всеобщую неправильность пакета. Другой узел может принять ту же цепочку. И наоборот, допустимый формат не обязывает каждый маршрутизатор выделять бесконечные ресурсы. Важно сделать отказ наблюдаемым и привязать его к тому, кто достиг предела.

Точность не делает ICMP авторитетным

Обычная ICMP-ошибка по умолчанию не аутентифицирована. RFC 4443 разбирает подмену источника, изменение полей, отказ в обслуживании и атаки через реакцию верхних слоёв. Перед изменением состояния нужно сопоставить адреса, протокол, порты и действительно отправленный трафик.

Генерация ICMPv6-ошибок должна ограничиваться по частоте. Поток плохих пакетов не должен вынуждать узел бесконечно отвечать. Multicast-правила, фильтры и обычные потери создают дополнительное молчание. Полученное сообщение доказывает, что кто-то сформулировал такой отчёт; отсутствие сообщения не доказывает успех всех парсеров на пути.

Исторический вклад Parameter Problem — разделение четырёх фактов: пакет отброшен, выбран класс причины, названо место остановки, возвращён только ограниченный контекст. Точность оказалась полезной именно потому, что не притворялась полнотой.

Источники