Кратко

  • 28 сентября 2026 года рабочая группа IETF Internet Area выпустила шестую редакцию проекта об идентификации узла в ошибках ICMP. Документ проходит оценку IESG, но ещё не является утверждённым RFC.
  • Новый пункт описывает неизвестное значение идентификатора семейства адресов AFI. При значениях 1 и 2 длина адреса известна: 32 бита для IPv4 и 128 для IPv6. Для другого значения длину переменного подобъекта определить нельзя, поэтому обработку Node Identification Object необходимо прекратить.
  • Пакет следует рассматривать так, будто этого объекта нет. Внешняя длина расширений по RFC 4884 позволяет перейти к последующим сообщениям расширения; требования отбросить весь ICMP-пакет здесь нет.

Сначала длина, потом вывод о личности

Адрес источника ответа ICMP не всегда однозначно указывает узел, создавший ошибку. Такое возможно, например, при трассировке IPv4 через участки с узлами только IPv6. Проект IETF предлагает добавлять к некоторым ответам адрес, имя или оба признака. Они помогают оператору в диагностике, но сами по себе не удостоверяют отправителя.

У адресного подобъекта нет одной неизменной длины. Согласно редакции 06, её задаёт AFI. Если получатель не распознаёт номер семейства, он не знает, где заканчивается адрес и начинается возможное имя. Продолжить чтение по догадке значило бы придать неопределённым байтам вид осмысленного узлового идентификатора. Новая формулировка предписывает остановиться в пределах Node ID и считать его отсутствующим.

Внешняя рамка работает иначе. RFC 4884 определяет длины в структуре расширений ICMP, так что частично разобранный объект можно пропустить, не отказываясь от следующих расширений. Будущие изменения значений и смысла AFI в RFC 5837 должны отражаться и здесь; это не означает, что неизвестный номер уже сегодня допустимо толковать произвольно.

Поправка имеет собственный предмет

В пятой редакции явного правила для неизвестного AFI не было. Экспертиза по безопасности поставила вопрос о судьбе остатка объекта, когда длину адреса узнать невозможно. Журнал изменений шестой редакции связывает новое разъяснение с отзывами транспортной и безопасностной дирекций. Отзыв не сообщает о реальной атаке, дефекте поставщика или распространённости реализации.

Предыдущая статья Daniel Kade по этому проекту разбирала решение отправителя: включать ли разглашение идентификатора и когда возникает обязанность его добавить. Здесь решение принимает получатель — какой объём информации вообще допускает синтаксис пришедших данных.

Источники