Кратко

  • Версия 03 индивидуального черновика Mark Smith добавляет вариант для клиентов, которым нужна DHCPv4 Router Option 3: собственный DHCP-адрес хоста или 127.0.0.1.
  • В документе предполагается, что эти значения удержат пакеты к нелокальным IPv4-адресам внутри хоста и вызовут ICMP Destination Unreachable. Это предположение черновика, а не опубликованный результат испытаний совместимости.
  • Тесты, упомянутые в блоге LACNIC 2 октября, относились к версии 02 и проводились до появления нового варианта.

Анализ

Шлюз по умолчанию обычно направляет трафик в другую сеть. Новая редакция черновика DHCPv4 допускает, что для некоторых старых клиентов это поле может указывать обратно на сам клиент.

16 октября Mark Smith опубликовал версию 03 документа “Nearly IPv6 Only Dual Stack Hosts”. Версия 02 завершила срок действия 15 июня. Новый текст сохраняет основной вариант без DHCP Router Option 3 для клиентов, которые принимают отсутствие опции, но добавляет другой путь для тех, кому она, предположительно, необходима: передать в качестве маршрутизатора собственный DHCP-адрес хоста либо 127.0.0.1.

Это не обычный шлюз. RFC 2132 определяет Option 3 как список маршрутизаторов, который DHCP-сервер передает хосту. По тексту черновика, при маске /32 оба адреса должны удерживать внутри хоста пакеты к нелокальным целям IPv4 и немедленно вызывать ICMPv4 Destination Unreachable. Но результат зависит от того, как клиент интерпретирует маршрут. В документе нет матрицы испытаний, которая показывала бы, какие клиенты принимают каждое значение, какие маршруты устанавливают и переходят ли приложения после ошибки на IPv6.

Ранее опубликованные испытания не закрывают этот пробел. Статья Alejandro Acosta в блоге LACNIC от 2 октября ссылается на версию 02 и перечисляет Windows 11, Fedora 43, Raspberry Pi OS на базе Debian Trixie, Chromecast и Google Nest. В ней также сказано, что смартфоны не проверялись и нужны дополнительные тесты. Эти наблюдения сделаны до версии 03 и не подтверждают новый вариант Router.

Поэтому недостаточно проверить, способен ли DHCP-сервер отправить значение. В пилотном тесте нужно раздельно сравнить адрес самого хоста и 127.0.0.1, затем повторить проверку на разных клиентах, версиях ОС и конфигурациях DHCP-сервера или ретранслятора. Следует сохранить DHCP ACK, сверить фактическую таблицу маршрутизации, захватить пакеты к внешним IPv4-адресам, проверить доставку ICMP приложению и его повторную попытку через IPv6. Отдельно нужно проверить связь внутри канального сегмента: прекращение маршрутизируемого трафика не доказывает, что локальная IPv4-связность тоже исчезла.

Этот черновик не заменяет DHCPv4 Option 108. RFC 8925 позволяет совместимому хосту сообщить о предпочтении IPv6-only на заданный период. Новый вариант рассчитан на устройства, не поддерживающие эту опцию или продолжающие ожидать ответ DHCPv4. Изменение в версии 03 ставит вопрос совместимости, а не вводит новый стандарт.

Datatracker указывает версию 03 как активный индивидуальный Internet-Draft без RFC-потока и со статусом IESG “I-D Exists”. В самом документе сказано, что он не одобрен IETF и не имеет формального статуса в процессе стандартизации. Предполагаемый статус — Informational; срок действия редакции заканчивается 19 апреля 2027 года. Новая версия показывает, что предложение обновляется, но не доказывает его принятие IETF или поставщиками ОС.

Для сетевых команд это повод провести ограниченный тест, а не основание для массового переключения. Значения адреса хоста и loopback следует испытывать раздельно в небольших группах с возможностью отката, пока не подтверждены маршруты и переход приложений на IPv6. Успешный обмен DHCP доказывает только выдачу аренды. Поведение хоста при шлюзе, указывающем на него самого, остается открытым вопросом.

Источники