Кратко

  • RFC 3925 позволил передавать данные нескольких поставщиков в одном сообщении DHCPv4, задав явные границы между записями.
  • Внешние номера опций были зарегистрированы, но внутренние коды и их значения остались за поставщиками; PEN обозначает пространство имён, а не удостоверяет утверждение.

Долгое время у обмена данными поставщиков в DHCPv4 была узкая схема. Опция 60 из RFC 2132 позволяла клиенту передать строку класса поставщика, а опция 43 несла непрозрачный объект с данными, определяемыми поставщиком. Сервер интерпретировал опцию 43 в контексте поставщика, указанного опцией 60. Это работало, пока хватало словаря одного поставщика. Неоднозначность возникала, когда устройству или отраслевому профилю требовались сведения, независимо определённые несколькими поставщиками. RFC 3925 описывает проблему обрамления данных, а не сбой выдачи DHCP-адреса.

Решением стала новая пара опций. Опция 124, Vendor-Identifying Vendor Class, и опция 125, Vendor-Identifying Vendor-Specific Information, помещают номер частного предприятия IANA рядом с данными каждого поставщика. В опции 125 может быть несколько записей: номер предприятия, длина и байты данных поставщика. Длина отделяет одну нагрузку от другой, а номер выбирает контекст её интерпретации. RFC 3925 прямо сохраняет старые опции 60 и 43, поэтому реализация может встретить и прежнюю, и новую форму.

Так видна граница между регистрацией и смыслом. IANA назначает внешний код опции DHCP, а реестр Enterprise Numbers — номер, обозначающий пространство поставщика. Ни один реестр не определяет значение нагрузки. Внутренние подопции используют формат «код/длина/значение», но RFC 3925 говорит, что их коды задают поставщики и IANA ими не управляет. Стандарт создал рамку, позволяющую не смешивать несколько диалектов, а не общий словарь для их перевода.

Размер пакета тоже ограничивает конструкцию. Совокупные данные могут превышать максимальную длину одной опции, поэтому RFC 3925 объявляет опции 124 и 125 требующими конкатенации по RFC 3396. Получатель сначала объединяет повторяющиеся фрагменты в одну логическую опцию, затем разбирает записи. Нельзя считать каждый фрагмент новой записью поставщика. Спецификация рекомендует, чтобы номер предприятия встречался только один раз среди всех экземпляров; при повторе поведение не определено. Контейнер допускает несколько поставщиков, но не придаёт смысл любой ошибочной или повторяющейся комбинации.

RFC 3925 заимствовал модель опций класса поставщика и его данных из DHCPv6, ранее описанную в RFC 3315. Это документированное повторное использование проектного решения, а не доказательство совпадения семантики нагрузок или распространённости двух протокольных семейств. Расширение также не удостоверяет поставщика: RFC 3925 само по себе не добавляет защиты, а RFC 3118 отдельно описывает механизм аутентификации DHCP, который можно применять при необходимости. Номер в опции выбирает пространство, но не является подписью.

В этом и состоит историческая роль RFC 3925: он сделал границы явными ради сосуществования, оставив локальные значения локальными. Внешний реестр помогает разобрать контейнер и назвать его пространство. Но он не сообщает клиенту, что именно делает байт поставщика, действительно ли устройство принадлежит этому поставщику и поддерживает ли реализация данную опцию. Для этого нужны отдельные свидетельства. RFC и реестры IANA подтверждают проектирование и назначение кодов, но не измеряют внедрение, совместимость или эксплуатационный результат.

Источники