Кратко

  • Обнаружив изменение сетевой информации, DHCPv6-клиент посылает Confirm, чтобы проверить пригодность уже имеющихся адресов для текущего канала. Запрос намеренно не адресован серверу, который выдал аренду.
  • Ответ Success охватывает все переданные адреса, но не T1, T2, preferred lifetime или valid lifetime. Он не обновляет привязку и не прибавляет к ней время.
  • В RFC 9915 Tomek Mrugalski и его соавторы отделяют знание топологии от полномочия продлить аренду и от доказательства работающей связи. Сведение этих состояний к одному зелёному индикатору уничтожает границы исходного решения.

После перемещения остаются два разных вопроса

Ноутбук засыпает в одной сети и просыпается в другой. У него сохранились IPv6-адреса, но сведения о маршрутизаторе или канале изменились. Немедленно отказываться от конфигурации необязательно: клиент может отправить DHCPv6-сообщение Confirm.

Название звучит так, будто сервер подтверждает всё прежнее состояние. Формулировка RFC 9915 значительно уже. Клиент спрашивает, уместны ли имеющиеся адреса на канале, к которому он теперь подключён.

В запрос входят идентификатор клиента и ассоциации идентичности со всеми проверяемыми адресами. Делегированные префиксы для этой операции не предусмотрены. Не предусмотрен и Server Identifier. Если клиент всё же укажет конкретный сервер, сервер должен отбросить запрос.

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

Если подходят все адреса, Reply содержит Success. Если не подходит хотя бы один, результатом становится NotOnLink. Если сервер не знает префиксы канала или в запросе нет адреса, он не отвечает. Молчание означает отсутствие серверного заключения, а не неявное одобрение.

Нули в полях времени — содержательная граница

RFC просит клиента установить T1 и T2 в IA_NA, а также preferred и valid lifetime в IA Address в ноль: сервер всё равно проигнорирует их.

Это не просто правило кодирования. Адреса нужны отвечающему серверу как предмет проверки топологии. Сроки не предлагаются ему для пересмотра. Знание активного префикса не превращает сервер в владельца исходной привязки клиента.

Именно поэтому Renew устроен иначе. При наступлении T1 клиент обращается к серверу, у которого получил аренду. Тот может найти привязку и вернуть новые T1, T2, preferred lifetime и valid lifetime. Если ответа нет до T2, Rebind позволяет просить о продлении любой доступный сервер, способный принять это решение.

Реестр IANA закрепляет разные коды: 4 для Confirm, 5 для Renew, 6 для Rebind. Они обозначают не три оттенка успешной аренды, а три операции с разными центрами ответственности:

  • Confirm передаёт вопрос о канале серверу, знающему его префиксы.
  • Renew сохраняет первую возможность продления за выдавшим сервером.
  • Rebind ищет новую временную власть после неудачи первого пути.

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

Адрес остаётся на интерфейсе, но это ещё не рассказ о причине

Получив Success, клиент может продолжать использовать адреса. Действуют последние известные сроки. Если до запроса оставалось полчаса valid lifetime, ответ не создаёт новое получасовое окно.

RFC 9915 допускает внешне похожее поведение и при отсутствии Reply. После завершения Confirm-обмена клиент продолжает использовать аренды и другую конфигурацию по прежним срокам. Поэтому простой снимок интерфейса — адрес всё ещё назначен — не различает положительный ответ и тайм-аут.

Различие даёт только связанная запись: исходный request, transaction ID, идентичность ответившего сервера и status code. Без неё наблюдатель видит действие, но не доказательство, на котором оно основано.

Последствия прежнего таймера описывает RFC 4862. Адрес бывает preferred, затем deprecated, а после окончания valid lifetime — invalid. Устаревший адрес ещё может поддерживать существующую связь, но нежелателен для новой. Недействительный адрес нельзя использовать как источник или принимать как назначение. Confirm не отменяет эту последовательность.

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

Один положительный ответ сильнее нескольких отрицательных, но не стирает их

Поскольку Server Identifier отсутствует, на Confirm могут ответить несколько серверов. Если хотя бы один действительный Reply содержит Success, клиент может пользоваться адресами и игнорировать ответы NotOnLink. Только когда ответы были получены и все они содержат NotOnLink, клиент запускает поиск серверов заново.

Это правило не подсчитывает большинство. Серверы могут работать с разными ревизиями конфигурации, relay-контекстами или административными областями. Протокол принимает достаточное положительное знание ради непрерывности, но не объявляет отрицательные наблюдения бесполезными.

Для эксплуатации расхождение часто важнее итогового зелёного статуса. Если один сервер вернул Success, а два — NotOnLink, следует сохранить все DUID, relay-пути, интерфейс, набор адресов и версии использованных префиксов. Так можно обнаружить отставшую конфигурацию до следующего отказа.

Проверка также атомарна для набора адресов. Одного неподходящего элемента достаточно для NotOnLink; сам status code не называет виновника. Без исходного набора поздняя диагностика не восстановит предмет решения.

Пять утверждений, которых в Success нет

Пригодный для префикса адрес может не пройти Duplicate Address Detection. Топологическое соответствие не доказывает уникальность.

Адрес может быть on-link, а ближайший маршрутизатор или сосед — недоступен. Neighbor Unreachability Detection из RFC 4861 использует другой автомат состояний и другие сигналы.

Действительный адрес источника может не иметь рабочего маршрута вверх по сети. Знание DHCP-сервера о префиксе не служит квитанцией доставки пакета.

Живая аренда не гарантирует живую сессию приложения. Сетевая конфигурация не восстанавливает транспортное состояние.

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

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

Работа Tomek Mrugalski соединяет текст стандарта с реализацией

RFC 9915 опубликован как Internet Standard STD 102. Его авторами названы Tomek Mrugalski, Bernie Volz, Michael C. Richardson, Sheng Jiang и Timothy Winters; список благодарностей отражает участие более широкого сообщества. Авторство объясняет происхождение текста, но не даёт его авторам контроля над конкретным продуктом или операторской сетью.

Публичная биография Mrugalski делает его особенно уместной фигурой для разговора об этой границе. IETF Datatracker фиксирует многочисленные работы по DHCP. Письменный профиль ISC рассказывает, как его университетский проект Dibbler вырос в реализацию DHCPv6 и как позднее он участвовал в разработке Kea. Это датированный профессиональный контекст, а не гарантия поведения каждой версии.

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

Примат работающего кода добавляет проверку исполнения. Название сообщения в журнале ещё не говорит, какой путь прошёл клиент: получил Success, получил только NotOnLink или дождался тайм-аута. Кратковременно результат на интерфейсе может совпасть, но последующая история различается.

Проблема принципала и агента возникает, когда стоимость доказательств распределена неравномерно. Поставщику легко показать счётчик «Confirm success». Оператор доступа хранит контекст канала и relay. Служба аренды владеет историей привязки. Пользователь несёт ущерб, когда время заканчивается. Если самый дешёвый показатель заменяет все записи, одна сторона определяет обещание, а другие оплачивают ошибку.

Шесть квитанций для адреса, который продолжил работать

Первая фиксирует причину проверки: интерфейс, старые и новые сведения о маршрутизаторе или канале, состояние клиента и время. Иначе запрос нельзя связать с конкретным перемещением.

Вторая сохраняет аренду до запроса: DUID выдавшего сервера, IAID, адрес, время выдачи, T1, T2, preferred lifetime, valid lifetime и оставшиеся секунды. Именно этот таймер продолжает работу.

Третья описывает request: DUID клиента, transaction ID, полный набор адресов, интерфейс и отсутствие Server Identifier. Отсутствие подтверждает, что задан вопрос о канале, а не запрос конкретному владельцу привязки.

Четвёртая содержит каждый Reply: DUID ответчика, relay-путь, контекст канала, status code и ревизию префиксов или конфигурации, использованную для решения. Молчание записывается как окончание обмена, а не синтетический Success.

Пятая объясняет агрегацию: существовал хотя бы один Success, все полученные Replies были NotOnLink или действительных ответов не было. Здесь же сохраняется действие клиента — продолжение или новый поиск.

Шестая отделяет последующие полномочия и наблюдения: Renew или Rebind, новые сроки, переходы в deprecated и invalid, проверку уникальности, соседство, маршрут и приложение. Эти факты могут вместе доказать здоровую услугу, но ни один нельзя дописать задним числом из Success.

Честная строка состояния звучит так: «сервер S в момент T признал адреса подходящими для канала; исходные сроки аренды не изменены». Она длиннее зелёного значка, зато сохраняет смысл, когда часы доходят до нуля.

Источники