Кратко

  • Перенумерация IPv6 — это сначала создание, затем отключение, а не одна команда маршрутизатору. Старый и новый префиксы должны сосуществовать, пока маршруты, фильтры, адреса, DNS и приложения переходят с разной скоростью.
  • Операционный вывод: предпочтительный и действительный сроки адреса, сроки делегированного префикса и настройки резолвера, положительные и отрицательные кеши DNS, выбор исходного адреса и долгие сессии образуют одну границу изменения.
  • Откат не является атомарной функцией протокола. Его надо испытать, пока оператор управляет старым префиксом, обратной зоной и обоими путями трафика.

Переключение, которое уже разделилось

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

Каждая подсистема сообщает правду: маршрут работает, DNS изменён, у клиента есть новый адрес, сервис доступен. Вся операция всё ещё опасна, потому что эти факты относятся к разным часам.

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

Префикс находится не только в маршруте

IPv6-адреса встречаются в плане линков, интерфейсах, Router Advertisement, DHCPv6, делегировании префикса, входных и выходных фильтрах, ACL, настройках сервисов, прямом и обратном DNS, списках разрешений, мониторинге и кешах приложений. RFC 6879 добавляет ручные настройки, долгие сессии и системы вне прямого контроля сетевой команды.

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

Предпочтительный, действительный и используемый — разные статусы

RFC 4862 задаёт автоконфигурированному адресу два срока. После preferred lifetime адрес становится устаревшим, после valid lifetime — недействительным. RFC 6724 требует при выборе исходного адреса избегать устаревшего, если есть подходящий предпочтительный.

Устаревание меняет выбор для новых соединений. Оно не доказывает завершение старых сессий, обновление сохранённого узла или исчезновение старого AAAA из кеша внешнего клиента. Сохранение действительности старого адреса оставляет путь восстановления, но скрывает зависимости, если потоки не измеряются по префиксу и возрасту.

Правило двух часов из RFC 4862 ограничивает, насколько резко неаутентифицированный Router Advertisement может сократить оставшийся valid lifetime. Это защищает от мгновенного злонамеренного отключения адресов, но означает, что центральная аварийная команда не обязательно станет единым выключателем. План должен учитывать поведение хоста, а не только намерение контроллера.

У филиала и резолвера разные часы

RFC 8415 переносит preferred и valid lifetime для DHCPv6-адресов и делегированных префиксов, а также определяет renewal и rebinding. Клиентский маршрутизатор может удерживать старый IA_PD после того, как верхний маршрут, SLAAC-хост и авторитетная зона уже перешли. Выключенный во время перекрытия филиал вернётся с локальным состоянием, которое не проверялось.

RFC 8978 показывает, что устаревший префикс SLAAC может сохраняться после быстрой перенумерации. RFC 9096 рекомендует согласовывать сроки в соответствующих Router Advertisement с оставшейся действительностью делегированного префикса. Это эксплуатационные соображения, а не гарантия одинакового поведения всех клиентских маршрутизаторов. RFC 4472 также отмечает, что долгоживущие приложения могут хранить результаты DNS дольше TTL записи; поэтому поведение приложения нужно измерять, а не выводить универсальный срок кеширования.

DNS добавляет другие часы. TTL управляет кешем AAAA и PTR. Публикация между авторитетными серверами имеет собственную задержку. Адреса резолверов и поисковые списки, полученные через Router Advertisement, имеют сроки RDNSS и DNSSL по RFC 8106. Перенумеровать сервис и перенумеровать резолвер, который его находит, — разные переходы.

Положительные ответы — не весь кеш. RFC 2308 задаёт отрицательное кеширование. Если резолвер спросил новое имя до создания записи, он может после публикации продолжать отвечать, что её нет. Учёт только TTL записи AAAA эту аварию не ограничивает.

RFC 4861 завершает локальную картину: хосты во времени интерпретируют сведения о маршрутизаторе и префиксе из объявлений. Наблюдать надо то, что хост действительно усвоил, а не только настройки отправителя.

Сходимость определяется максимумом

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

Среднее скрывает выключенный филиал, резолвер с более длинным отрицательным кешем, ACL партнёра, меняемую заявкой, и устройство, которое разрешает имя только при запуске. Правильный знаменатель — все заявленные зависимости и точки наблюдения, а не только устройства, сообщившие о себе в окне.

Проба маршрута доказывает доступность нового префикса. Запрос DNS доказывает текущий ответ одного резолвера. Журнал потоков доказывает наблюдавшееся использование. Ни один факт отдельно не разрешает изъятие. Решением они становятся, когда привязаны к одной версии изменения и одному реестру исключений.

Источники