Кратко

  • После окончания Preferred Lifetime IPv6-адрес становится deprecated, но остаётся valid до второго срока. Не выбирать для новой связи и не признавать адрес вообще — разные решения.
  • Переходный период направляет новые соединения на замену, а существующим позволяет сохранить конечную точку, которую они не умеют менять без разрыва.
  • Двухчасовая защита ограничивает неаутентифицированное обнуление Valid Lifetime. Если маршрутизатор после перезагрузки забыл старый префикс, она же может задержать законный отзыв.

У адреса появилось полезное старение

Уже RFC 1971 в 1996 году различал состояния preferred, deprecated, valid и invalid. Пока адрес предпочтителен, верхние уровни свободно его используют. После окончания Preferred Lifetime использование не запрещено, но не рекомендуется. Только истечение Valid Lifetime прекращает привязку к интерфейсу.

Промежуточная стадия учитывает устройство транспортов. Открытое TCP-соединение обычно не меняет адреса конечных точек на ходу. Если удалить старый адрес сразу после появления нового префикса, исправные сессии оборвутся лишь потому, что начались раньше. Поэтому deprecated-адрес продолжает принимать пакеты и может служить источником для уже идущего обмена.

Устаревший не значит недостижимый. Первый таймер отвечает за будущий выбор. Второй — за само право считать адрес локальным.

В объявлении находятся два независимых времени

RFC 4861 помещает Preferred Lifetime и Valid Lifetime в Prefix Information Option сообщения Router Advertisement. Оба поля имеют 32 бита и измеряются в секундах; все единицы означают бесконечность. Preferred не может быть больше Valid. RFC 4862 требует игнорировать противоречивую опцию.

Флаг Autonomous отдельно разрешает использовать префикс для SLAAC. Одни только числа не создают адрес. Префикс, флаги и сроки вместе описывают область полномочий объявления.

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

Правило выбора отклоняет, но не изгоняет

После окончания предпочтительного срока новые коммуникации должны использовать подходящий неустаревший источник, если он доступен. Правило 3 в RFC 6724 предпочитает источник, который не находится в состоянии deprecated.

Это стандартный выбор, а не абсолютный запрет. Приложение может явно указать ещё действительный источник. Старое соединение вправе сохранить его. Новый SYN, пришедший на deprecated-адрес, может получить SYN-ACK с того же адреса, если соединение допустимо. Приём на адрес и его выбор для исходящей новой связи не совпадают.

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

Ноль предпочтения начинает отток

Администратор может объявить для старого префикса Preferred Lifetime равным нулю, оставив положительный Valid Lifetime. Узел немедленно помечает адрес deprecated, но не удаляет. Новые соединения переходят на замену, а старые получают время завершиться.

RFC 5887 описывает плановую перенумерацию через такое перекрытие: ввести новый префикс, перестать направлять новые сессии на старый и позднее прекратить его действительность. Но состояние адреса — лишь одна зависимость.

DNS, маршруты, межсетевые экраны, ACL, сертификаты и приложения могут хранить старое значение независимо. Адрес бывает valid на узле, когда обратного маршрута уже нет. Состояние deprecated не удаляет DNS-запись. Два срока дают порядок координации, но не выполняют атомарную замену во всей сети.

Быстрое уничтожение требует более сильного доказательства

Обычный Router Advertisement может не иметь аутентификации. Если поддельный пакет способен сократить Valid Lifetime до секунд, злоумышленник в канале получает кнопку удаления адресов. RFC 4862 устанавливает двухчасовой предел ущерба. Небольшое неаутентифицированное значение обычно не заставляет прежде долгоживущий адрес истечь раньше этого порога; если осталось не более двух часов, дальнейшее сокращение для valid игнорируется.

Preferred Lifetime обновляется даже тогда, когда valid защищён. Разница соответствует последствиям: убрать адрес из нового выбора менее необратимо, чем удалить его, а законному оператору нужна быстрая deprecation.

Аутентифицированное объявление может обрабатываться иначе. Два часа — не универсальная длительность миграции, а граница полномочий слабого свидетельства.

После перезагрузки может исчезнуть предмет отзыва

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

RFC 8978 исследует такую flash renumbering. Приведённые там значения по умолчанию из RFC 4861 показывают масштаб: семь дней preferred и тридцать дней valid. Это не статистика современных устройств, а длительность обещания без явной отмены.

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

Надёжный отзыв должен пережить потерю и рестарт

RFC 9096 рекомендует клиентским пограничным маршрутизаторам сохранять ранее объявленные префиксы в устойчивой памяти, ограничивать LAN-сроки оставшимся upstream-сроком и повторно объявлять старые префиксы с обоими нулями.

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

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