Кратко

  • В IPv6 достижимость соседа опиралась на недавнее положительное подтверждение. Когда оно устаревало, запись переходила в STALE, но не удалялась и не порождала служебный трафик, пока оставалась невостребованной.
  • Первый пакет переводил STALE в DELAY и давал верхнему уровню время показать прогресс. Лишь затем начинался PROBE; RFC 7048 позже добавил UNREACHABLE и экспоненциальное отступление, разделив выбор альтернативы и окончательный отказ от единственного пути.

STALE говорил о давности знания

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

В RFC 1970 1996 года это состояние получило имя STALE. RFC 2461, а затем RFC 4861 сохранили модель. После ReachableTime без нового положительного подтверждения REACHABLE становится STALE. До следующей отправки никаких действий не требуется.

Неиспользуемая старая запись может оставаться в кэше без ущерба корректности. Её допустимо вытеснить из-за нехватки памяти, но это уже управление ресурсами, а не вывод о недостижимости. Периодическая очистка всей таблицы только превратила бы бездействие в лишнее multicast-разрешение.

Сообщение от соседа не доказывало путь к соседу

NUD оценивает прямое направление глазами отправителя. Полученная Router Advertisement показывает путь от маршрутизатора к хосту. Незапрошенная Neighbor Advertisement показывает то же направление. Они не доказывают, что недавний пакет хоста дошёл до IP-уровня соседа.

Спецификация признавала два вида положительного подтверждения. Первый — solicited Neighbor Advertisement в ответ на собственную Neighbor Solicitation: запрос дошёл до цели, ответ вернулся. Второй — прогресс протокола верхнего уровня, невозможный без доставки предыдущих пакетов.

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

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

Сначала отвечал полезный трафик

Первый пакет через STALE отправлялся по сохранённому адресу канального уровня и переводил запись в DELAY. Стандартная задержка составляла пять секунд.

За это время обычное соединение могло само дать доказательство. После паузы TCP-рукопожатие быстро показывает прогресс; тогда запись возвращается в REACHABLE без дополнительной Neighbor Solicitation.

Если подтверждения нет, по истечении DELAY узел отправляет unicast-запрос и входит в PROBE. Отображение ещё известно, поэтому сначала проверяется именно оно. Multicast нужен позже, когда требуется заново выяснить адрес канального уровня.

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

Тридцать секунд не были общим дедлайном

RFC 4861 задавал базовое время 30 секунд, секунду между повторами, пять секунд до первой пробы и три unicast-запроса. Но фактический ReachableTime выбирался случайно между 0,5 и 1,5 базового значения. Router Advertisement могла также передать ненулевые значения базы и повтора.

Случайность не давала множеству узлов проверять соседей синхронно. Поэтому формула «через 30 секунд сосед мёртв» никогда не соответствовала стандарту.

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

Быстрое удаление иногда усиливало сбой

В исходной машине RFC 4861 PROBE повторял unicast Neighbor Solicitation и после предельного числа безответных попыток удалял запись. По умолчанию это три передачи с секундным интервалом. Затем хост выбирал другой маршрутизатор либо возвращался к multicast-разрешению.

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

RFC 6583 показал контур перегрузки. Обращения к множеству несуществующих адресов в /64 способны занять NDP. Если из-за них не обслуживаются действующие записи и ответы NUD, корректные соседи исчезают из кэша, multicast растёт, а существующие потоки останавливаются. Документ рекомендовал ставить обслуживание используемых соседей выше спекулятивного создания новых записей.

В 2014 году RFC 7048 назвал NUD «слишком нетерпеливым». Обновление ввело концептуальное состояние UNREACHABLE. После порога сосед переставал считаться заведомо достижимым при выборе маршрутизатора, поэтому можно было опробовать альтернативу. Но адрес канального уровня сохранялся, пакеты при необходимости продолжали отправляться, а интервалы проб росли экспоненциально.

Позже проверки должны перейти к multicast, чтобы обнаружить смену канального адреса. Если запись не используется, повторы можно остановить. Пример RFC размещал попытки на 1-й, 4-й, 13-й и 40-й секундах и приводил 60 секунд как возможный максимум интервала. Это образец алгоритма, не статистика реализации.

UNREACHABLE отделил смену предпочтения от капитуляции

Решение «предпочесть другой next hop» не равно решению «больше никогда не пробовать этого соседа». При наличии резервного маршрутизатора первое должно быть быстрым. При отсутствии замены второе может подождать восстановления радио, интерфейса или spanning tree.

Экспоненциальное отступление сохраняет шанс возврата без постоянного потока. Критерий доказательства не смягчился: прогресс верхнего уровня или solicited-ответ восстанавливают REACHABLE, незапрошенное объявление — нет. RFC 7048 изменил последствия неудачи, а не определение успеха.

DAD использовал те же сообщения для другого вопроса

RFC 4862 применяет Neighbor Solicitation и Advertisement для Duplicate Address Detection. DAD до назначения проверяет, не занят ли tentative-адрес другим узлом. NUD во время работы проверяет прямой путь к уже выбранному соседу.

Ограниченное молчание в DAD может разрешить использование адреса. В NUD молчание только старит подтверждение, а DELAY и PROBE запускает реальный трафик. Совпадение формата пакетов не делает выводы взаимозаменяемыми.

Источники и пределы

История и состояния основаны на RFC 1970, 2461 и 4861. RFC 4862 задаёт границу с DAD, RFC 6583 описывает эксплуатационную нагрузку, RFC 7048 обновляет восстановление. Эти документы не доказывают современные настройки производителей, распространённость, размеры таблиц, частоту отказов или соответствие конкретной сети.