DHCP option 43 требует конкретной vendor-схемы
Фотография конкретного исполнения не приложена.
Два устройства могут оба использовать option 43 и ожидать совершенно разные значения. Общий option code не создаёт единого формата provisioning. Для интеграции нужны правила именно выбранного vendor и версии клиента.
RFC 2132 описывает Vendor Specific Information как vendor-defined объект. Внутренние suboptions могут использовать собственные codes и значения. Vendor Class Identifier помогает обозначить класс клиента, но не превращает содержимое option 43 в универсальный словарь адресов и настроек.
Нельзя копировать hex-значение из чужого примера только из-за совпадения номера option. Также присланный class identifier сам по себе не подтверждает подлинность оборудования. Его использование в политике выдачи требует понимания доверия к клиентскому сообщению.
В приёмке фиксируют точный vendor profile, firmware scope и полное декодирование значения. Проверяют подходящий и неподходящий класс клиента. Отчёт должен показывать, какие данные реально применены устройством. Успешный DHCPACK с option 43 не подтверждает совместимость provisioning, если схема внутреннего содержимого не установлена по документации конкретного продукта.
Основание — Numbered DHCPv4 base RFCs and selected lease, identity, option and reconfigure extensions, разделы RFC2132 8.4 Vendor Specific Information;9.13 Vendor Class Identifier. Сохранён текст публичной справочной публикации; конкретная реализация может поддерживать только часть возможностей. Основание — указанные номерные RFC DHCPv4 и дополнений. Поддержка options конкретными client, relay и server не проверялась. Это протокольный разбор и план приёмки, а не результат испытания оборудования; leases, адреса, маршруты и рабочая сеть не изменялись.