Кратко

  • DHCPv6 Reconfigure не доставляет новую конфигурацию. Это просьба к заранее согласившемуся клиенту начать Renew, Rebind или Information-request; новое состояние может возникнуть только в следующем обмене.
  • RFC 6977 разрешает Reconfigure-Reply со статусом Success, даже если сервер не отправит Reconfigure ни одному запрошенному клиенту. Обработка, выбор, доставка, аутентификация, транзакция, установка и работа сервиса требуют разных доказательств.

Первым изменился цвет панели

Ретранслятор в сети доступа узнаёт, что сведения о предоставлении услуги для некоторого канала изменились. Он помещает адрес канала и несколько DUID в Reconfigure-Request. Сервер возвращает Reconfigure-Reply со статусом Success, и система управления закрывает операцию.

При этом ни один клиент ещё не обязан измениться. Для одних идентификаторов у сервера нет пригодной записи, другие никогда не присылали Reconfigure Accept. Часть сообщений ждёт ограничения скорости. Доставленный пакет может не пройти аутентификацию; Renew может начаться, но не получить Reply; клиент DHCP может установить состояние, а приложение — продолжать держать старый адрес.

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

RFC 6977 проводит границу предельно явно. Список клиентов в успешной Reconfigure-Reply содержит тех, кому сервер не станет отправлять Reconfigure. В нём могут оказаться все запрошенные клиенты, а код всё равно останется Success. Подтверждение между ретранслятором и сервером намеренно не является квитанцией исполнения от конечного устройства.

Действующий механизм выбирает следующий диалог

RFC 9915 — нынешняя базовая спецификация DHCPv6, заменившая RFC 8415. В реестре IANA тип RECONFIGURE имеет значение 10. Общая функция узка: предложить одному клиенту начать новый обмен DHCPv6.

Reconfigure передаётся unicast и содержит Server Identifier, соответствующий Client Identifier, приемлемую аутентификацию и опцию Reconfigure Message. Она может выбрать только Renew, Rebind или Information-request. Новые адреса, префиксы и обычные параметры конфигурации не должны находиться в триггере; они появляются, если нужны, в Reply следующего обмена.

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

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

Добровольное участие остаётся видимым

Клиент объявляет готовность опцией Reconfigure Accept. Без неё сервер не вправе считать его участником. Устройство остаётся полноценным клиентом DHCPv6 и получает изменения через обычные сроки действия, инициированный им Renew или стандартный Information-request.

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

RFC 8947 напоминает, что у малых устройств аутентификация и постоянное состояние имеют заметную стоимость. Сокращённая реализация меняет скорость реакции, но не лишает устройство совместимости.

Аутентификация подтверждает отправителя, а не итог

Reconfigure Key Authentication Protocol передаёт 128-битный ключ в первоначальной Reply и применяет HMAC-MD5 к последующим Reconfigure. Первая доставка ключа идёт открытым текстом по пути DHCPv6. Эту границу угроз нельзя скрыть словом «аутентифицировано».

Значение обнаружения повтора должно монотонно расти и переживать перезапуск сервера. Резервный узел может восстановить leases, но потерять ключи или счётчики. Тогда он знает кандидатов, однако не может создать принимаемый ими триггер. Репликация секретов повышает доступность и одновременно расширяет область возможной компрометации.

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

Считать «аутентифицировано» синонимом «верно от начала до конца» значит стереть границу, которую криптография помогла увидеть.

Ретранслятор предлагает, сервер решает

RFC 6977 определяет Reconfigure-Request и Reconfigure-Reply между ретранслятором и сервером. Ретранслятор может указать адрес канала и идентификаторы предположительно затронутых клиентов. Сервер решает, известен ли источник, следует ли ему доверять, достаточно ли состояния, какие клиенты подходят и с какой скоростью действовать.

По умолчанию такие запросы не принимаются, а сообщения неизвестного ретранслятора отбрасываются. RFC 8213 позволяет защищать канал между сервером и ретранслятором посредством IPsec. Целостность канала не подтверждает правильность выбранной группы. Скомпрометированный ретранслятор способен передать неверный список по полностью защищённому соединению.

При повторной передаче ретранслятор может убрать клиентов, но не добавить. Эта асимметрия не позволяет незаметно расширить уже начатую операцию. Она не заменяет проверку канала, DUID, binding и полномочий источника.

Если запрос получают несколько серверов, различия состояния и политики приводят к разным выборам. Несколько ответов Success не создают консенсус о конечном результате. Каждый триггер должен быть связан с отправившим сервером, конкретным клиентом и последующей транзакцией.

Шесть фактов вместо одной отметки

Надёжный операционный журнал отдельно хранит как минимум:

  1. наблюдавшееся исходное изменение и предложенную ретранслятором группу;
  2. приём или отказ определённого сервера;
  3. выбор клиента и фактическую отправку Reconfigure;
  4. принятую аутентификацию и последующий запрос клиента;
  5. завершённую и обработанную Reply;
  6. установленное состояние и проверенный путь приложения.

Доказательства возникают в разных местах: журнале ретранслятора, Reconfigure-Reply, решении выбора, счётчике отправки, результате аутентификации, идентификаторе транзакции, локальном состоянии и тесте сервиса. Разница между соседними уровнями — диагностический сигнал, а не шум.

Success со всеми DUID в списке исключений означает успешную обработку и нулевой охват. Renew без Reply означает успешный триггер и незавершённую транзакцию. Установленное состояние DHCP при приложении на старом адресе означает успех конфигурации и неудачу миграции. Одна отметка завершения не способна выразить эти факты.

Очередь меняет значение времени

Одно событие может развернуться в множество индивидуальных Reconfigure и столько же новых обменов DHCPv6. RFC 6977 предусматривает ограничение скорости, чтобы сохранить ресурсы для обычного назначения, продления и восстановления.

Принять запрос сейчас — не значит отправить все триггеры сейчас. Существенная шкала времени проходит через наблюдение, выбор, очередь, отправку, клиентский запрос, Reply и установку. Задержка Reconfigure-Reply измеряет только начало.

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

Максимальное ожидание должно укладываться в период безопасного сосуществования старого состояния. Если очередь длиннее, допустимая протоколом задержка становится отказом.

Восстановленная запись не равна текущему устройству

Leasequery, Bulk Leasequery и Active Leasequery из RFC 5007, RFC 5460 и RFC 7653 помогают восстановить bindings и поддерживать более свежую копию. Они уменьшают неизвестность после failover, но не превращают прежнее наблюдение в нынешнее присутствие.

Записанный клиент мог уйти с канала. Активный поток может запаздывать, менять порядок или требовать повторной синхронизации. Lease может быть восстановлен без ключа Reconfigure и replay-состояния. Происхождение, возраст и полнота должны сопровождать состояние до широкого действия.

Модель YANG в RFC 9243 делает конфигурацию службы DHCPv6 более наблюдаемой. Она описывает намерение управляющей плоскости, а не фактическое состояние конечного устройства. Это отдельное свидетельство, не замена проверке.

Перенумерация показывает цену неверного вывода

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

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

Reconfigure — необязательный ускоритель внутри плана перехода, а не разрешение на мгновенное отключение.

Общий слой должен знать границы своего знания

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

Ретранслятор решает, какое событие заслуживает запроса, и предлагает кандидатов. Сервер определяет доверие, сопоставление, выбор и бюджет. Клиент исполняет свой код. Оператор выбирает защиту, доказательства и возврат. Небольшое общее ядро оставляет будущие решения действующим участникам.

Дисциплина Heng Lu ставит running code на первое место. Записи, рекомендации и подтверждения описывают действительность, но не создают её. Изменение становится реальным после исполнения, проверки оператором и подтверждения использованием.

Minimum Initial Specification предоставляет небольшой совместимый триггер. Localized Future Decision оставляет доверие, выбор, реализацию и защиту на местах. Voluntary Adoption виден в опции, которую клиент вправе не отправлять. Стандарт описывает приглашение; работающие системы определяют результат.

Источники