Кратко

  • Опубликованный 4 сентября рассказ о GRAND объясняет мартовские изменения в FreeBSD. Это повод разобраться в реализации, а не свидетельство нового релиза или измеренного эффекта во всех производственных сетях.
  • Упреждающие объявления и отложенные ответы могут использовать общий механизм отправки, но требуют различного учёта, отмены и освобождения памяти. Проверять нужно их совместную работу, а не только успешную отправку объявления.

Что остаётся неизвестным после первого пакета

Узел уже может отправлять трафик через маршрутизатор, а маршрутизатор ещё не обязательно знает, куда на канальном уровне доставить ответ этому узлу. Причина — новый глобальный IPv6-адрес: знание узлом маршрута наружу не создаёт автоматически обратного соответствия в кэше соседей маршрутизатора. Приход первого ответного пакета тогда запускает разрешение адреса и добавляет ожидание.

GRAND, или Gratuitous Neighbor Discovery, предлагает сообщить это соответствие заранее. В статье от 4 сентября Seyed Pouria Mousavizadeh Tehrani разбирает реализацию такого подхода в FreeBSD. Временная последовательность здесь существенна: статья новая, а приведённые в ней изменения кода относятся к марту 2026 года. Считать публикацию объявлением о новом выпуске операционной системы было бы ошибкой.

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

Ускорение зависит от обеих сторон

В RFC 9131 описана отправка узлом незапрошенных Neighbor Advertisement после настройки нового глобального адреса. Получатели — все маршрутизаторы на соответствующем multicast-адресе. Число сообщений ограничено, между ними выдерживается интервал, связанный с RetransTimer. Это не непрерывное напоминание о существовании узла.

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

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

Изменение FreeBSD от 5 марта включает объявления после завершения проверки нового глобального адреса на дублирование, реакцию на изменение адреса канального уровня и инфраструктуру отложенной отправки. Исторический патч содержит ip6.grand_count, связанный с количеством объявлений. Однако один патч не устанавливает ни текущие значения по умолчанию для всех выпусков, ни настройки конкретного развёртывания.

Два вида работы внутри одной механики

Отложенная отправка нужна не только GRAND. У Neighbor Discovery есть правила времени отправки для ряда других ситуаций, включая несколько адресов, anycast и ответы от имени другого узла. Использовать общую инфраструктуру для ожидания разумно. Неразумно считать, что все ожидающие элементы поэтому должны иметь одинаковую судьбу.

В изменении, внесённом 19 марта, это различие становится явным. Описание коммита отделяет GRAND от ответов на запросы, разбирает отмену более старых ожидающих объявлений для того же адреса интерфейса, повторное использование памяти и освобождение элементов, не относящихся к GRAND, без дополнительного удержания после отправки, предусмотренного для объявлений. В самом изменении счётчика из квоты GRAND исключаются элементы другого типа.

За этой деталью стоит важная граница обязательств. Инициатор объявления пытается предупредить будущий запрос; отправитель ответа уже обслуживает поступивший запрос. Ограничение, полезное для первого, не обязательно годится для второго. Если забыть различие, оптимизация может создать конкуренцию с той работой, которую должна была облегчить.

При этом освобождение от одной квоты не предоставляет ответам бесконечную память и не гарантирует абсолютный приоритет. Речь также не о доказанном разделении на две физические очереди. История изменений показывает замысел и конкретные правки общей механики; она сама по себе не доказывает правильность всех возможных чередований выполнения.

Для этого материала мы не собирали FreeBSD, не снимали пакетные трассы и не проводили нагрузочные измерения. В использованных источниках нет независимого результата, позволяющего назвать универсальный выигрыш в миллисекундах или долю внедрений. Их практическая ценность в другом: они дают проверяемый вопрос к реализации. Сможет ли она ускорить раннее уведомление, не нарушая завершение и отмену других отложенных действий?