Кратко

  • Reconfigure — аутентифицированный триггер для Renew, Rebind или Information-request; факт отправки не доказывает новую конфигурацию клиента.
  • Получив выбранный клиентский запрос, сервер считает свою Reconfigure-заявку выполненной, но Reply, локальное применение и рабочий эффект остаются отдельными фактами.

Опасная подмена начинается со слова «отправлено». По RFC 9915 сервер посылает Reconfigure, чтобы клиент начал один из последующих обменов. Это не сообщение о готовом результате. Если панель сразу рисует «клиент обновлён», она пропускает именно те проверки, которые стандарт оставляет самостоятельными.

Сначала нужно установить готовность и валидность. Опция Reconfigure Accept сообщает серверу, готов ли клиент принимать Reconfigure; без неё стандартное поведение — не готов. Клиент обязан отбросить сообщение, которое не было unicast, не содержит нужных идентификаторов сервера или клиента, нужной опции, допустимого типа либо корректной аутентификации. Поэтому запись об отправке подтверждает действие сервера, но не доставку пригодного сообщения.

Даже после получения валидной Reconfigure следующий факт ограничен. Опция выбирает Renew, Rebind или Information-request; клиент начинает указанный обмен и во время него игнорирует дополнительные Reconfigure. RFC называет исходное сообщение trigger. Оно запускает другую транзакцию, но не устанавливает само по себе адрес, префикс, резолвер или иной параметр.

Позднее сервер может получить узкое, но полезное подтверждение. RFC 9915 разрешает считать полученный запрошенный Renew, Rebind или Information-request выполнением его Reconfigure-запроса. Честная формулировка здесь: сервер получил требуемый тип клиентского сообщения. Из неё не следует, что Reply был получен или обработан, что его значения приняты или что система клиента их применила.

Последующие обмены также имеют разный смысл. Renew и Rebind подчиняются собственным правилам привязки и выбора сервера; Information-request запрашивает сведения без адресов и префиксов. Reply — объект, который может нести сведения о конфигурации в соответствующем обмене. Утверждение о конкретном изменении требует Reply и нужных option/IA. Утверждение об установке, маршруте, DNS, трафике или успехе приложения требует дополнительного наблюдения там, где это произошло.

Аутентификация Reconfigure защищает определённую границу, а не все последующие результаты. RFC 9915 требует её из-за риска DoS. RFC 9096, где Вольц также назван среди авторов, даёт контекст улучшений безопасности и приватности DHCPv6. Ни один из документов не превращает аутентифицированное управляющее сообщение в доказательство доступности или сквозного успеха.

Проверяемая запись хранит DUID клиента, идентификатор сервера, отправку и проверку Reconfigure, требуемый msg-type, соответствующий запрос, полученный сервером, Reply и относящиеся поля. Для операционного вывода добавляется независимое наблюдение за установкой или исполнением. Реестр IANA помогает распознать коды DHCPv6, но не удостоверяет последующие стадии.

Это соответствует дисциплине Хэн Лу: называть минимальный действительно наблюдаемый факт. «Сервер отправил Reconfigure» и «сервер получил запрошенный запрос» — содержательные утверждения. «Клиент настроен» без дальнейших записей — ожидание, выданное за доказательство. Вольц здесь один из пяти авторов коллективного стандарта, а не владелец реального клиента, сервера или сети.

Источники