Кратко

  • Активный проект рабочей группы INTAREA авторства Remco van Mook предлагает 192.0.0.11/32 как маркер шлюза. Поддерживающий его хост не посылает ARP, а использует MAC выбранного маршрутизатора IPv6.
  • Пакет остаётся нативным IPv4: нет ни туннеля, ни трансляции. Однако для возврата нужен маршрут к IPv4 /32 хоста через маршрутизируемый следующий узел IPv6 GUA или ULA.
  • Конфигурация DHCP, выбор RA, состояние NUD, пересылка IPv4, обратный маршрут и ARP для старых хостов — разные свидетельства, даже если механизм выглядит единым.

Адрес, который ничего не адресует

Маркер не является интерфейсом маршрутизатора. Его нельзя разрешать через ARP, распространять как обычный маршрут или помещать в поле источника либо назначения пересылаемого пакета. Запись в таблице IPv4 меняет только локальное поведение: выбери IPv6-маршрутизатор по умолчанию на том же интерфейсе и возьми его канальный адрес из Neighbor Cache.

Приложение продолжает работать с IPv4-сокетом, хост формирует IPv4-пакет, сеть пересылает IPv4. NAT64 не выполняется, оболочки IPv6 нет. Исключается отдельное обнаружение первого перехода для IPv4.

В августе 2026 года документ стал проектом рабочей группы INTAREA. В нём сообщается о проверке без изменения приложений и DHCPv4 на Windows 11, macOS, Android, iOS, Linux, FreeBSD и ChromeOS. Это вывод авторов проекта, а не независимая сертификация. Internet-Draft может измениться, поэтому маркер нельзя называть уже принятым универсальным стандартом.

Lease подтверждает лишь начало

Получение параметра DHCP не означает, что маршрут готов. До первой Router Advertisement у хоста нет IPv6-маршрутизатора, чьё состояние можно использовать; очередь пакетов должна быть ограничена. При нескольких кандидатах сначала применяется preference из RFC 4191, затем достижимость, после чего остаётся выбор реализации.

При смене маршрутизатора IPv4-маршрут требуется оценить заново, а существующие соединения могут оборваться. На IETF 126 Lorenzo Colitti отдельно спросил о следовании за изменениями маршрутизации IPv6 и предупредил, что неверная реализация способна сломать IPv4. Remco van Mook подтвердил эту зависимость.

Neighbor Cache даёт ещё одно свидетельство, но не окончательный ответ. Состояния reachable, stale, delay и probe из RFC 4861 разрешают использование с разной степенью уверенности. Сохранённый MAC не доказывает, что устройство пересылает IPv4. Рабочее устройство также не поможет, если RA или ND уже утрачены.

Обратная сторона требует глобального следующего узла

Для исходящего первого перехода достаточно link-local адреса IPv6. Между маршрутизаторами он непригоден. Оператор должен объявить индивидуальный IPv4-маршрут /32 хоста через достижимый IPv6 GUA или ULA. RFC 8950 задаёт BGP-представление IPv4 NLRI с IPv6 next hop; проект v4-via-v6 развивает межмаршрутизаторную часть.

Успешный исходящий ping поэтому доказывает не всю услугу. Нужны отдельные отметки: lease принят, выбрана ожидаемая RA, получен правильный MAC, выбранное устройство пересылает IPv4, а /32 виден на обратном пути.

Маска /32 удерживает границу

Более широкий префикс заставит хост считать другие IPv4-адреса локальными и снова отправлять ARP. /32 не просто экономит адреса, а предотвращает возврат скрытой IPv4-подсети. Маркер должен оставаться только локальной инструкцией.

Проект приводит Hetzner, OVH и Scaleway как примеры хостингов, где отдельный IPv4 и off-link gateway сегодня требуют системных обходных настроек. Это объясняет спрос на общее поведение, но не является независимым доказательством внедрения нового маркера этими компаниями.

RFC 8925 предлагает способ предпочесть IPv6-only для способных клиентов. Здесь решается иная задача: сохранить нативный IPv4 для dual-stack хостов в сегменте, построенном вокруг IPv6. Механизмы могут сочетаться, но не подтверждают друг друга.

Старые хосты образуют отдельный уровень

Неизменённый хост воспримет 192.0.0.11 как обычный шлюз и отправит ARP. Проект рекомендует маршрутизатору ответить собственным MAC, чтобы новые и старые системы сосуществовали.

Так появляются два пути. Работа старого клиента подтверждает ARP-ответ, но не выбор через IPv6. Работа нового не подтверждает поддержку старого. Общая метрика доступности скроет один сбой другим.

Tobias Fiebig на IETF 126 назвал подход элегантным по сравнению с DHCPv4-over-DHCPv6. Элегантность означает меньше обмена на линии, но не отсутствие состояний выбора, соседства, пересылки и возврата.

Реализация не скрывает незрелость

В репозитории v4-with-v6-nh есть пользовательский daemon для Linux. Он обнаруживает маркер, выбирает по RFC 4191, устанавливает IPv4-маршрут через IPv6 next hop, отслеживает изменения и удаляет маршрут при потере предпосылки. Linux умеет представлять такие маршруты с ядра 5.2.

До первой RA daemon не может ставить в очередь отдельные пакеты, поэтому запуск лишь приближает требование проекта. Интеграция с systemd-networkd существует как патч, синтаксис FreeBSD проверен без исполнения, коммерческие конфигурации не испытаны на оборудовании, помеченного релиза нет. Код подтверждает осуществимость, но не одинаковую производственную готовность.

Проверять следует переходы: окончание DHCP, задержку первой RA, уход предпочтительного маршрутизатора, старение NUD, исчезновение обратного /32, равную preference и смешанный парк хостов.

Доверие переходит от ARP к RA

Устранение ARP уменьшает поверхность подмены и шум. Доверие первого перехода остаётся. Ошибочная RA может выбрать MAC для IPv4, а сбой ND способен одновременно остановить обе адресные семьи.

RA Guard, доверенные порты, наблюдение за соседями и явные preference становятся мерами защиты IPv4. Самый опасный отказ тихий: DHCP раздаёт маркер там, где есть лишь половина поддержки. Проверка DHCP также может заранее отвергнуть off-link gateway. «Конфигурация принята» и «пакет пересылается» должны иметь разные индикаторы.

Источники