Кратко

  • RFC 9928 поручает 4o6RA инкапсулировать DHCPv4 в DHCPv6 от имени устаревшего IPv4-клиента, который нельзя обновить для RFC 7341.
  • Такая замена меняет наблюдателя: правильный обмен не доказывает передачу Layer 2 Interface-ID, верный выбор топологической политики, принятие конфигурации клиентом или достижимость.

В отчёте о миграции всё выглядело завершённым. Клиент отправил DHCPv4, промежуточный узел сформировал DHCPV4-QUERY, сервер ответил, внутреннее сообщение вернулось к клиенту. Но в отчёте не было привязки транзакции к входному порту. Ответ доказывал работу транспорта; он не показывал, что политика получила правильное представление о месте подключения.

RFC 7341 переносит сообщения DHCPv4 поверх DHCPv6, чтобы выдавать параметры IPv4 через IPv6-сеть. В исходной схеме клиент сам поддерживает DHCP 4o6. RFC 9928 рассчитан на встроенные и долгоживущие IPv4-only устройства, которые трудно заменить или обновить. Капсулирование переносится в промежуточный коммутатор или маршрутизатор — 4o6RA.

Для конечного узла это обычный DHCPv4. В отношениях RFC 7341 клиентом становится 4o6RA. Он выбирает DHCPv6-интерфейс, находит подходящий сервер или relay, получает IPv6-конфигурацию, запрашивает DHCP 4o6 Server Address option и создаёт инкапсулированный запрос из сообщения старого клиента.

Обратная обработка столь же конкретна. Ответ без DHCPv4 message option или с неверной формой должен быть отброшен. Правильное внутреннее сообщение извлекается и отправляется клиенту только тогда, когда его действительно можно переслать. RFC не вводит новый формат и не добавляет требований совместимому серверу 4o6. Он определяет небольшой проверяемый транспортный контракт.

Но выбор адреса и параметров может зависеть от топологии. RFC 7969 показывает различие. В DHCPv4 giaddr обычно заполняет первый relay, поэтому цепочка передаёт лишь часть пути. В DHCPv6 значения link-address и Interface-ID от нескольких relay могут описать путь до сервера полнее.

Если DHCP 4o6 выполняет сам клиент, DHCPv6 relay знает интерфейс прихода инкапсулированного запроса. После переноса функции в 4o6RA на границе IPv6 именно 4o6RA выглядит как DHCPv6-клиент, а Layer 2-сегмент за ним исчезает. RFC 9928 прямо предупреждает: схема только с 4o6RA нарушает передачу топологии, потому что инкапсулированное сообщение не содержит интерфейсных данных скрытой сети.

Рекомендовано поставить рядом LDRA из RFC 6221, чтобы он добавлял Interface-ID в исходящий запрос. При этом внутренний обмен сведениями между 4o6RA и LDRA, его формат и даже отметка об участии 4o6RA остаются вне стандарта. Значит, происхождение этой связи должен устанавливать и проверять местный оператор.

Принцип Heng Lu о минимальной начальной спецификации хорошо объясняет границу. Общий протокол содержит только необходимое для совместимости и локальной проверки. Будущие решения остаются у участников, которые внедряют механизм и несут последствия. Ссылка на RFC не заменяет доказательство внутренней таблицы. Локальная свобода требует локального владельца, версии и возможности воспроизвести решение.

Отдельная обязанность — направлять через 4o6RA весь DHCPv4 broadcast и unicast, поскольку клиент о посреднике не знает. RFC допускает центральное размещение или NAT. Если в том же Layer 2 остаётся напрямую доступный DHCPv4-сервер, запрос способен обойти 4o6RA. Тогда у клиентов и серверов возникает ошибочное состояние, а конфигурация может нарушить доступность. Документ называет это ошибкой развёртывания, а не новой угрозой безопасности; для эксплуатации это всё равно отказ.

Доказательство следует собирать по границам: transaction ID и hash клиентского запроса; входной порт, VLAN или интерфейс; выбранный 4o6RA DHCPv6-интерфейс; обнаружение сервера; hash query и response; порядок relay, link-address и Interface-ID; фактические входы политики сервера; выбранные адрес и параметры; проверка формы и решение пересылки; lease и options, принятые клиентом; проверка конфликта; независимая проба маршрута, доступности или сервиса.

У каждого факта свой ответственный. Команда доступа подтверждает точку появления узла. Владелец relay — преобразование. DHCP-служба — правило выбора. Владелец устройства — установленное состояние. Сервисная команда — наблюдаемый эффект. Даже если это одна группа, записи нельзя сжимать в общий статус: они по-разному устаревают и требуют разного отката.

Running-Code Primacy не превращает зелёный индикатор в абсолют. Он требует уважать реальный локальный результат. Успешный relay доказывает транзакцию relay. Ответ сервера — его решение по имевшимся входам. Bound state — состояние клиента. Probe — наблюдение в определённый момент. Операционная истина появляется, когда эти записи связаны, а не когда первой присваивают имена остальных.

Источники