Кратко

  • Способный клиент добавляет код 108 в Parameter Request List DHCPv4. Сервер должен возвращать «IPv6-Only Preferred» только из пула, явно настроенного как IPv6-mostly; после этого клиент не запрашивает предложенный IPv4-адрес.
  • Минимальное ожидание составляет 300 секунд, значение по умолчанию в RFC — 1800. По истечении времени или при новом сетевом подключении DHCPv4 может начаться снова. Пять минут — механизм быстрого возврата, а не постоянное отключение IPv4.

Предложение, которое не должны принимать

Обычный DHCPOFFER приглашает клиента запросить адрес. Опция 108 позволяет той же беседе закончиться без аренды. Клиент помещает код в список параметров DHCPDISCOVER или DHCPREQUEST. Он не посылает четырёхбайтовое значение таймера, а лишь сообщает: на этом интерфейсе IPv4-адрес необязателен, если сеть предоставляет функции для работы только по IPv6.

Сервер не вправе принимать молчание за согласие. Опция должна быть запрошена, а выбранный пул — явно обозначен как IPv6-mostly. Только тогда сервер передаёт V6ONLY_WAIT. RFC рекомендует предложить 0.0.0.0. Если инфраструктура этого не допускает, можно указать реальный свободный адрес, но его не следует резервировать: клиент, как ожидается, не станет его запрашивать.

Так разные устройства остаются в одном сегменте. Не знающий опции клиент получает IPv4 обычным способом. Способный клиент отказывается. IPv4-only, dual stack и IPv6-only-способные системы делят один SSID или VLAN без удвоения сети и без центральной системы допуска, которая должна заранее угадать возможности каждого приложения.

Механизм намеренно узок. Он не оценивает современность устройства, не устанавливает политический срок перехода и не объявляет неучастника недействительным. Один интерфейс и один настроенный пул согласуют ограниченный выбор.

Пять минут как бюджет восстановления

V6ONLY_WAIT — 32-битное число секунд. Если сервер присылает меньше нижней границы, клиент использует 300 секунд. Значение по умолчанию в RFC 8925 равно 1800, поэтому пять минут нельзя называть стандартным интервалом.

Во время ожидания клиенту следует остановить настройку DHCPv4; он также может отключить стек IPv4 на затронутом интерфейсе. Решение прекращает действовать по таймеру или при событии нового подключения, смотря что произойдёт раньше. Выбор, сделанный в офисной сети, не переносится без проверки в гостиничную сеть, где может быть только IPv4.

Версия 07 проекта 6MOPS от марта 2026 года рекомендует начинать с 300 секунд ради быстрого отката и увеличивать срок после подтверждения надёжности. Это Internet-Draft в работе, а не RFC. Но его гипотеза проверяема: если обнаружилась критическая зависимость, оператор перестаёт отправлять опцию, и клиенты возвращаются к DHCPv4 после таймера или переподключения.

Короткий срок создаёт нагрузку. Большой парк, повторяющий DHCPDISCOVER каждые пять минут, способен заметно загрузить серверы. Меньшее время сокращает продолжительность ошибочного решения, большее — управляющий трафик. Настройку должны определять число клиентов, ёмкость DHCP, частота отказов и реальное время восстановления.

Таймер — не нерешительность. Это страховка от ситуации, когда объявленная способность интерфейса оказалась ложной.

Шесть состояний вместо одной галочки

Надпись «опция 108 включена» почти ничего не доказывает. В эксплуатационной квитанции нужны по меньшей мере шесть отдельных строк.

Первая — политика интерфейса. Кто признал устройство способным, на основании какой версии ОС, наличия CLAT и тестов приложений? RFC прямо называет это политическим решением, а не автоматическим сканированием программ.

Вторая — наблюдаемый запрос. Был ли код 108 в реальном Parameter Request List? Без него клиент не сделал заявления.

Третья — область сервера. Ответил ли именно пул IPv6-mostly? Общая поддержка функции на сервере не подтверждает конфигурацию выбранного пула.

Четвёртая — предложение. Имела ли опция допустимую длину четыре байта, каков таймер и был ли указан 0.0.0.0 либо незарезервированный реальный адрес? Это видно в контролируемом захвате пакетов.

Пятая — состояние клиента. Действительно ли он отказался от адреса и остановил DHCPv4? Как повёл себя при INIT-REBOOT, продлении и новом подключении? Сообщение сервера не доказывает исполнение на конечной системе.

Шестая — результат для сервиса. Получен ли PREF64, доступен ли NAT64, активировался ли CLAT для старого ПО и завершил ли пользователь свою задачу? Пустая строка в таблице аренд этого не показывает.

Только раздельная запись позволяет сказать: этот клиент в этом пуле отказался от адреса на такой срок, а такие-то приложения работали или не работали. Фраза «IPv4 выключен» уничтожает место для диагностики.

Трансляция остаётся отдельной зависимостью

RFC 8925 предполагает NAT64 для доступа к назначениям, имеющим лишь IPv4. Сама опция 108 не согласовывает технологию трансляции, не сообщает префикс NAT64 и не проверяет маршрут к транслятору.

RFC 8781, также написанный при участии Linkova, определяет опцию PREF64 в Router Advertisement. RFC 9872 рекомендует этот RA-метод для новых развёртываний, оставляя DNS-обнаружение запасным вариантом, если опция недоступна или не поддерживается. Пока PREF64 не получен, IPv4-only-приложения и связь с IPv4-only-назначениями могут быть нарушены.

464XLAT закрывает другую брешь. Клиентский CLAT показывает старой программе поверхность IPv4 и переносит трафик по IPv6. Однако RFC 6877 называет это ограниченной связностью IPv4, а не полной заменой один к одному. Входящий IPv4 и все одноранговые модели он не воссоздаёт.

Поэтому опция 108 может сработать правильно, а сервис — нет. Клиент отказался, но RA не принёс PREF64. Префикс правильный, но маршрут NAT64 сломан. Трансляция доступна, но VPN блокирует расширенные заголовки IPv6. Браузер работает по нативному IPv6, а приложение с литералом IPv4 не находит CLAT.

Отчёт об инциденте должен назвать конкретный слой. Общее «проблема IPv6» не позволяет ни проверить DHCP, ни определить ремонт.

Что скрывал dual stack

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

Проект 6MOPS предлагает поэтапность: сначала сигнализировать PREF64, затем активировать опцию 108 на DHCPv4-сервере, а при управляемых устройствах — включать поведение поштучно. Он предупреждает, что некоторые ОС обрабатывают опцию по умолчанию и не имеют переключателя. Для них небольшое серверное изменение мгновенно превращает весь совместимый набор в IPv6-only.

Слайды Jen Linkova на IETF 118 описывали пилоты в офисах Google, расширение по площадкам и постепенное увеличение доли включения. Там же сообщались уменьшение использования DHCP и ожидаемое высвобождение адресов. Это показатели, приписанные конкретной презентации и среде, а не независимые универсальные нормы.

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

Какой спрос доказывает отказ от аренды

Не взятый адрес остаётся другому устройству. При прямой выдаче публичного IPv4 это может снизить публичное потребление. В сетях RFC 1918 — облегчить нехватку частных адресов или избежать дополнительного NAT. Новый сегмент можно сразу спроектировать с меньшим пулом, а старый, возможно, придётся перенумеровать, прежде чем свободное место станет используемым блоком.

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

Дефицит от этого не исчезает. Спрос может сосредоточиться там, где от IPv4 нельзя отказаться. Экономическая польза опции — отделить автоматическую раздачу от наблюдаемой потребности, а не объявить адрес утратившим ценность.

Следует раздельно считать запросивших код клиентов, допустимые ответы, предотвращённые аренды, последующие возвраты, состояние NAT64/CLAT, ошибки по приложениям и адреса, которые действительно удалось вывести из пула или применить снова. Свободная строка ещё не равна возвращённой ёмкости.

Пятиминутные часы не дают временному ответу стать догмой. Сеть записывает «сейчас не нужно», наблюдает последствия и сохраняет право позже ответить иначе.

Документированная роль Jen Linkova

Авторы RFC 8925 — Lorenzo Colitti, Jen Linkova, Michael C. Richardson и Tomek Mrugalski. Linkova также указана вместе с другими авторами в RFC 8781, RFC 9872 и текущем проекте 6MOPS. Это подтверждает последовательный вклад в связанные механизмы эксплуатации IPv6, но не единоличное изобретение и не контроль над реализациями или сетями.

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

Устойчивый вклад — не дата конца IPv4, а способ уменьшить большой вопрос до проверяемого: может ли этот адрес при этих условиях ненадолго остаться наготове? Через пять минут система вправе спросить снова.

Источники