Кратко

  • Нужны прежний Reply с опцией, новый запрос этой опции и валидный ответ на Renew, Rebind либо Information-Request без неё.
  • Такой ответ фиксирует решение сервера и обязанность клиента, но не удаление локального значения, перезагрузку процесса или прекращение трафика.
  • IA обрабатываются отдельно, а одинаковые данные могут законно прийти из другого источника.

Отсутствие с контекстом

Раздел 18.2.10.5 RFC 9915 описывает не сравнение двух снимков, а связанную транзакцию. Без старого предоставления нельзя доказать, что отзывается прежнее значение. Без нового запроса нельзя считать молчание ответом на эту опцию. Без проверки сообщения нельзя приписать его нужному клиенту.

При выполнении условий клиент SHOULD прекратить использование и вернуться к соответствующему состоянию по умолчанию. Это нормативное действие, не телеметрия. Сервер не видит запись конфигурации, reload потребителя и закрытие старых соединений.

Разные последствия для FQDN и NTP

Сохранение MAY допустимо только при отсутствии практического способа удаления, другого источника и внешнего эффекта. Пример — hostname из Client FQDN, описанного RFC 4704. Для адреса NTP правило жёстче: после квалифицирующего пропуска клиент MUST перестать использовать адрес, определённый RFC 5908.

Но RFC допускает тот же параметр из другого источника. RFC 3646 выдаёт DNS-серверы через DHCPv6, RFC 8106 — RDNSS через Router Advertisement. Совпадение адреса не доказывает сохранение отозванного полномочия.

Не переносить правило на IA

IA_NA и IA_PD исключены и следуют разделу 18.2.10.1. Reconfigure тоже лишь запускает Renew, Rebind или Information-Request. Получение триггера, завершение обмена, применение и результат сервиса — разные события.

Довести доказательство до исполнения

Нужны прежняя выдача, повторный запрос, валидный пропуск, версия локального состояния, реакция процессов, источник оставшегося значения и последний трафик. RFC 8415 уже содержал эту семантику; RFC 9915 выделил её, но не доказал соответствие конкретной реализации.

Источники