Кратко

  • RFC 9928 разрешает 4o6RA инкапсулировать DHCPv4 в DHCPv6 и извлекать ответ за устаревший IPv4-клиент, который не осведомлён о механизме.
  • После переноса функции в промежуточный узел сегмент второго уровня может исчезнуть из топологии DHCPv6. RFC рекомендует схему 4o6RA и LDRA «спина к спине», но не стандартизирует внутренний обмен сведениями об интерфейсе.
  • Успешная аренда подтверждает выделение конфигурации и доставку ответа. Она сама по себе не подтверждает входной порт, локальное отображение непрозрачного Interface-ID, применённое правило пула или отсутствие прямого пути DHCPv4.
  • Квитанция передачи должна связать наблюдение на входе, инкапсуляцию, порядок вложенных ретрансляторов, решение сервера, доставку, обнаружение обхода и завершение или исправление состояния.

Совместимость скрывает середину обмена

Старая радиоустановка, поддерживающая только IPv4, подключена к коммутатору транспортной сети. Она отправляет обычный DHCPv4-запрос и получает адрес, шлюз и DNS. В журнале аренды операция успешна. Однако физический порт может определять, к какой соте относится устройство и какой пул или набор параметров должен выбрать сервер.

RFC 7341 определил DHCP 4o6 для клиента, который умеет помещать DHCPv4-сообщение в DHCPv6. Необновляемое оборудование этого не умеет. RFC 9928 переносит роль на DHCPv4-over-DHCPv6 Relay Agent.

4o6RA принимает DHCPv4, создаёт DHCPV4-QUERY и отправляет инкапсулированный запрос вверх. Получив корректный DHCPV4-RESPONSE, он извлекает ответ DHCPv4 и передаёт его запросившему клиенту. Стандарт прямо указывает: устаревший клиент не знает, что обслуживается через DHCP 4o6.

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

Место запроса может определять конфигурацию

RFC 7969 описывает настройку DHCP на основе топологии. Ретранслятор знает, откуда пришёл первоначальный запрос, и передаёт идентификатор, помогающий серверу выбрать адресный пул и параметры.

В DHCPv4 только первый ретранслятор обычно устанавливает giaddr, поэтому многоступенчатый путь представлен частично. DHCPv6 может вкладывать Relay-forward друг в друга и сохранять последовательность link-address и Interface-ID. Ответ идёт обратно в обратном порядке.

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

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

LDRA восстанавливает непрозрачную ссылку

RFC 9928 рекомендует сочетать 4o6RA с Lightweight DHCPv6 Relay Agent. LDRA получает сведения о клиентском интерфейсе и включает Interface-ID в исходящий DHCPV4-QUERY.

RFC 6221 требует Interface-ID во всех Relay-forward от LDRA. Значение должно быть стабильным для интерфейса, в том числе после перезапуска, потому что сервер может использовать точное совпадение в политике назначения.

Однако значение непрозрачно. Сервер не должен разбирать байты как шасси, слот, порт или личность клиента. Физический смысл находится во внешнем локальном отображении: в конкретный момент и в конкретном поколении таблицы это значение было создано для наблюдаемого порта.

RFC 9915 требует скопировать Interface-ID из Relay-forward в Relay-reply. Ретранслятор использует её, чтобы выбрать интерфейс к клиенту. Одна и та же строка участвует в политике сервера и обратной доставке, но не удостоверяет правильность локальной таблицы.

Внутренняя граница остаётся локальной

RFC 9928 не определяет внутренний механизм передачи сведений от 4o6RA к LDRA, формат сведений и признак участия 4o6RA. Одна реализация может объединить функции в процессе, другая — связать ASIC коммутатора, программный агент и сервис управления.

Следовательно, совместимые сообщения на линии не создают одинаковую provenance-запись. Эксплуатация должна зафиксировать, какой компонент наблюдал порт, какое поколение отображения породило Interface-ID, что именно было передано между функциями и как обрабатываются отсутствующие или устаревшие данные.

Есть и простой случай: если 4o6RA и DHCP 4o6-сервер находятся на одном узле, одного 4o6RA может быть достаточно. Нельзя превращать рекомендацию в требование отдельного LDRA в любой сети. Нужно проверить, получил ли сервер требуемую топологию и можно ли доказать её источник.

Обходной путь создаёт второе правдоподобное состояние

Клиент не знает о 4o6RA, поэтому сеть должна направлять через него и широковещательные, и одноадресные DHCPv4-сообщения. Доступный напрямую DHCPv4-сервер в том же сегменте второго уровня способен ответить без 4o6. RFC 9928 называет возникающее неверное состояние и возможное нарушение достижимости ошибкой развертывания, а не новой угрозой безопасности.

Для контроля это означает необходимость наблюдать оба пути. Прямой сервер и 4o6-служба могут выдать внешне нормальные аренды с разными правилами и сроками. Клиент не может объяснить, какой контур управления победил.

В квитанцию нужно включить отрицательное доказательство: broadcast был перехвачен, unicast-продление осталось на заданном пути, прямой сервер отсутствовал или был доказуемо заблокирован. Адрес в состоянии клиента этого не показывает.

Десять звеньев квитанции

Предлагаемая квитанция передачи — редакционная операционная мера, а не новое поле DHCP и не сертификат IETF.

Сначала сохраняются наблюдаемый DHCPv4-запрос, ограниченная привязка транзакции, время, узел доступа и клиентский интерфейс. Затем — поколение карты, 4o6RA, выбранный восходящий интерфейс и событие инкапсуляции. Внутренняя передача к LDRA записывается отдельно с версией реализации и поведением при ошибке.

Протокольная часть содержит непрозрачный Interface-ID, точный уровень Relay-forward, другие link-address и порядок, использованный политикой. Серверная часть называет совпавшее правило, пул и возвращённую конфигурацию. Обратная часть связывает вложенный Relay-reply, декапсуляцию и доставку на исходный порт.

Девятое звено — проверка прямого обхода. Десятое закрывает запись при Renew, Rebind, перемещении порта, исправлении, истечении или откате и задаёт срок хранения. Ни журнал сервера, ни журнал коммутатора по отдельности не доказывает всю цепь.

IETF задаёт совместимое поведение. Оператор доступа отвечает за порт и отображение, оператор relay — за перехват и инкапсуляцию, владелец DHCP — за правило и пул. Неосведомлённый клиент получает результат, но не является информированным принципалом невидимого решения.

Источники