Кратко

  • RFC 3736 позволил узлу, у которого уже есть IPv6-адрес, запросить дополнительные параметры обменом DHCPv6 Information-request/Reply, не прося сервер назначить адрес.
  • «Без состояния» означает, что серверу не требуется хранить динамическое состояние каждого клиента для этой услуги; необязательный идентификатор клиента, локальная политика и ретрансляторы остаются частью системы.

Адрес и резолвер — разные задачи

Автоматическая настройка адреса IPv6 без состояния позволяет узлу сформировать адрес по объявлениям маршрутизатора. Но это не закрывает все вопросы конфигурации. Узлу могут понадобиться адреса рекурсивных DNS-серверов, сведения о SIP-серверах или другие опции. DHCP легко представить как единый комплект: запросить у сервера адрес и получить вместе с ним все остальные настройки сети.

RFC 3736 разделил эти функции. Клиент уже получил адрес иным способом — обычно посредством автоматической настройки без состояния либо вручную — и имеет как минимум link-local адрес для связи. Он отправляет Information-request, указывая желаемые типы опций в Option Request. Сервер возвращает выбранные параметры в сообщении Reply. В этом режиме клиент не запрашивает Identity Association для адреса, а сервер адрес не назначает.

Обмен намеренно сводится к двум сообщениям: сначала Information-request, затем Reply. Узел может запросить настройки DNS, не превращая взаимодействие в аренду адреса. Одна серверная система может обслуживать и клиентов, которым нужны адреса, и клиентов, которым требуются только дополнительные параметры; ретрансляторы работают так же, как при DHCP с состоянием.

Но «без состояния» не означает, что у сервера нет настроек или политики. RFC 3736 говорит, что серверу не нужно хранить динамическое состояние о каждом клиенте. Клиент может передать Client Identifier, если администратор хочет настроить ответ для конкретного узла. Сервер по-прежнему выбирает опции согласно локальной политике, а ретранслятор может переслать сообщение. Не требуется именно клиентская привязка адреса для этого информационного сервиса.

Это различие помогает понять флаги IPv6 Router Advertisement. В RFC 4861 флаг Managed означает, что DHCPv6 может предоставить адреса; Other сообщает о доступности других параметров, например DNS. Если установлен Managed, флаг Other избыточен. Это сигналы доступности, а не доказательство, что узел завершил обмен DHCP, настроил резолвер или имеет к нему доступ.

Без аренды адреса пропадают и её часы

Назначенные адреса имеют предпочтительный и действительный сроки жизни, которые показывают клиенту, когда адрес ещё можно использовать и когда он становится недействительным. У других параметров такого срока может не быть. RFC 3736 прямо оставил открытым вопрос о том, когда узлу следует послать следующий Information-request для обновления значений; правил обновления после перехода на другой канал документ тоже не задавал.

Позднее RFC 4242 добавил опцию Information Refresh Time, задающую верхнюю границу ожидания перед новым запросом параметров DHCPv6. Причина показательна: если обмен не включает аренду адреса или префикса, у клиента может не быть срока действия, который подскажет время следующего обращения. Затем RFC 8415 объединил спецификации DHCPv6, заменив RFC 3736 и RFC 4242, и сохранил двухсообщенный запрос информации.

История не сводится к тезису «после появления адреса через SLAAC DHCP стал не нужен». Формирование адреса и получение других параметров можно разделить. Это сокращает состояние на каждого клиента, нужное информационному серверу, но оставляет отдельные задачи жизненного цикла: приоритет источников, обновление, область действия интерфейса и настройку резолвера на узле. Reply подтверждает, что протокол вернул опции; само по себе оно не доказывает, что узел их установил или что DNS-запрос прошёл успешно.

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

Источники