Кратко

  • Ответ DHCPv4 с маской /32 и без параметра маршрутизатора обслуживает старый клиент, одновременно убирая обычный маршрут IPv4 к адресатам за пределами канала.
  • Снижение числа повторов не возвращает адрес в пул и не изолирует хост: уникальная аренда сохраняется, а сосед по тому же каналу всё ещё может отправить ему пакет.

Тихий интерфейс — это ещё не свободный адрес

Старое устройство с двумя стеками может продолжать запрашивать IPv4, хотя оператор уже рассчитывает перевести приложения на IPv6. Простое прекращение ответов способно оставить клиенту новые безрезультатные запросы DHCPv4. Техническая запись в блоге LACNIC от 2 октября описывает более узкий способ совместимости из индивидуального Internet-Draft: сервер отвечает знакомыми старому клиенту параметрами DHCPv4, но на интерфейсе не появляется обычный маршрут IPv4 к адресатам за пределами локального канала.

Опция 1 DHCPv4 передаёт маску 255.255.255.255, то есть /32. Сервер не отправляет опцию 3 со сведениями о маршрутизаторе. При маске /32 любое другое IPv4-назначение оказывается вне единственного адреса интерфейса. Без сведений о маршрутизаторе у хоста нет обычного следующего перехода для такого трафика. Клиент получает запрошенную конфигурацию, и повторные поиски адреса могут прекратиться, но связность IPv4 за пределами канала не возникает.

Это не полное отключение IPv4. На настроенном интерфейсе остаётся IPv4-адрес, а DHCPv4 продолжает работать. Устройство может иметь второй интерфейс, статический маршрут, туннель или приложение с иным поведением. Некоторые приложения после неудачи IPv4 пробуют IPv6, однако Draft описывает ожидаемое поведение, а не гарантию для любой операционной системы или службы. Проверяемое утверждение должно относиться к конкретному интерфейсу и его таблице маршрутизации.

Каждому тихому хосту по-прежнему нужна уникальная аренда

Главная цена здесь скрыта не в количестве пакетов, а в состоянии распределения адресов. Для каждого хоста в одном канальном сегменте DHCPv4-серверу всё ещё требуется отдельный IPv4-адрес. Как правило, все молчащие устройства общего сегмента не могут одновременно пользоваться одним адресом. Перед использованием может выполняться обнаружение конфликтов; если один адрес всё же получат два клиента, конфликт станет виден. Draft также предупреждает, что повторная выдача уже конфликтного адреса способна загнать клиента в цикл DHCPDECLINE.

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

Стоимость зависит от выбранного пула. Если назначается дефицитный публичный IPv4-адрес, действующая аренда сохраняет альтернативную стоимость, даже если хост не может обычным путём обращаться к внешним адресатам. Draft рассматривает и адреса link-local или RFC1918. Выделенный частный пул помогает не расходовать публичные адреса, но всё равно нужны отдельный адрес каждому устройству, состояние сервера, обработка конфликтов и проверка пересечений с уже принятой частной адресацией.

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

Длинная аренда сокращает обновления, но продлевает резервирование

Для хостов, которым не предполагается выходить к внешним IPv4-адресатам, Draft предлагает рассматривать срок аренды от одного дня до нескольких недель. Обновлений и нагрузки на сервер будет меньше, но адрес дольше останется зарезервирован. В дефицитном публичном пуле сокращение DHCP-сообщений не гарантирует появления свободных адресов. Оператору следует сопоставлять частоту запросов с числом занятых адресо-дней. Это вывод из механики аренды, а не опубликованный в блоге результат измерений.

Опция 108 предлагает другой путь для другого класса устройств. RFC 8925 стандартизирует IPv6-Only Preferred для совместимых клиентов в явно настроенных IPv6-mostly-сетях. Если клиент и сервер поддерживают эту опцию, клиент в подходящей среде может отказаться от назначения IPv4, сохранив ёмкость пула. Подход с /32 адресован старым клиентам, которые не понимают опцию 108; Draft допускает совместное применение подходов. Ни один из вариантов DHCP сам по себе не подтверждает работу приложений, DNS64/NAT64 или необходимых сервисов.

Отсутствие маршрута по умолчанию не является входящим фильтром

Если не передать параметр маршрутизатора, у хоста пропадает обычный маршрут IPv4 к назначениям за пределами канала. Но для соседей по тому же каналу он не становится невидимым. Раздел безопасности Draft прямо отмечает, что другой хост может отправить IPv4-пакет устройству с маской /32. Рекомендация — включить локальный firewall и разрешить на этом интерфейсе только DHCPv4-трафик между клиентом и сервером либо relay.

«Не может обычным путём начать IPv4-соединение за пределы канала» и «не может получить IPv4-пакет» — разные утверждения. Первое следует из предложенной маршрутизации, второе — нет. Если на устройстве работают локальные службы или оно доступно через другой интерфейс, отсутствие шлюза не заменяет явных правил входящего трафика.

Что именно подтверждают опубликованные материалы

По сообщению блога LACNIC, автор Alejandro Acosta проверял подход на Windows 11, Fedora 43, Raspberry Pi OS на базе Debian Trixie, Chromecast и Google Nest. Смартфоны не тестировались; автор призывает к более широкой проверке совместимости. Это описанные автором испытания, а не независимое воспроизведение, репрезентативная выборка устройств или данные промышленного внедрения. Блог также говорит, что мнение автора не обязательно отражает позицию LACNIC.

В основе материала — версия 02 индивидуального Internet-Draft. IETF Datatracker указывает дату истечения 15 июня 2026 года и сообщает, что документ не имеет формального статуса в процессе разработки стандартов IETF. Истечение срока не означает технического опровержения, а наличие Draft не означает одобрения стандарта. Среди проверенных открытых источников нет измерений снижения DHCP-трафика, изменения загрузки адресного пула, успешности приложений через IPv6 или аудита входящей безопасности.

Оператор, проводящий пилот, должен раздельно публиковать: число повторных DHCP-запросов целевых устройств; активные аренды и занятые адресо-дни в публичном, частном и link-local пулах; освобождения, истечения и DHCPDECLINE; соответствие каналов, relay и выбранных пулов; успешность IPv6 в выборке приложений; фактически действующие правила входящего firewall. Успокоившийся канал, возвращённый дефицитный адрес, работающее приложение и контролируемая поверхность входящего трафика — разные результаты.

Источники: