Кратко

  • Опция 60 сообщает класс для интерпретации сервером; 61 служит ключом базы привязок адресов; 55 выражает запрос и предпочтения; 43 несёт непрозрачные данные в пространстве поставщика.
  • Захват пакета фиксирует значения в точке наблюдения, но сам по себе не удостоверяет изготовителя, физическое устройство, установленную конфигурацию или результат работы сети.

В архиве администратора одна DHCP-заявка может выглядеть как паспорт: строка с названием класса, устойчивый идентификатор и аккуратный перечень нужных параметров. Но составители RFC 2132 не объявляли такой паспорт. Steve Alexander и Ralph Droms в марте 1997 года описали набор способов передавать настройки, где одинаковая внешняя упаковка обслуживает разные решения сервера и клиента.

Опции продолжают грамматику BOOTP: обычно за кодом следует длина и указанное количество октетов данных; Pad и End являются исключениями. В поле сведений поставщика BOOTP четырёхоктетный magic cookie выбирает способ чтения последующих байтов. Историческую основу задавал RFC 1048. Это граница синтаксического разбора, а не проверка достоверности отправителя. Декодер способен правильно выделить значение, не зная, кто его заявил.

Опция 60 — необязательная строка класса поставщика, передаваемая клиентом и толкуемая сервером. Она может обозначать тип или особенности конфигурации. Если сервер не умеет интерпретировать сведения этого класса, он обязан их игнорировать, хотя может зарегистрировать. Для ответа с данными конкретного поставщика рекомендуется опция 43. Следовательно, строка может повлиять на ветвь настройки, но не доказывает подлинность марки оборудования и не принуждает сервер принимать утверждение клиента.

Опция 43 хранит непрозрачные сведения, смысл которых устанавливается поставщиком. Для нескольких элементов RFC рекомендует внутренние поля «код–длина–значение». Внутренние коды могут быть переопределены, не меняя глобальных номеров DHCP. Внутренний End завершает именно вложенные расширения, а не всё внешнее поле опций; если его нет, границу задаёт длина содержащей опции. Ошибка в этой области способна превратить частный код в ложный общий факт. Даже корректно пойманный ответ ещё не доказывает, что клиент использовал байты.

Опция 61 — отдельный ключ. Серверы индексируют по идентификатору клиента базу привязок адресов и должны считать значение непрозрачным. Оно может включать тип и адрес оборудования, но может строиться иначе. Требуется уникальность среди идентификаторов, используемых на подсети подключения; за выбор отвечают поставщик или администратор. Уникальность индекса нужна базе, но не равна аутентификации человека или физического узла. Одинаковая последовательность в двух записях не закрывает вопрос об источнике сообщений.

Опция 55 перечисляет коды желаемых параметров. Клиент вправе упорядочить их по предпочтению. Сервер не обязан вернуть опции в том же порядке, хотя должен попытаться включать запрошенные в указанном порядке. Ни полный ответ, ни применение параметров из списка не следуют. Опция 57 указывает наибольшую длину сообщения DHCP, которую клиент согласен принять; законный минимум — 576 октетов. Пожелания и предел размера ограничивают переговоры, а не измеряют состояние работающего хоста.

RFC 2131 отдельно описывает обнаружение, предложение, запрос, подтверждение и итоговую проверку клиента. Для вывода о результате потребовались бы связанные сообщения, политика сервера и запись привязки, принятые клиентом настройки и проверка нужной службы. Эти источники не дают статистики внедрения или измерений названного оператора. Раздел безопасности RFC 2132 прямо сообщает, что вопросы безопасности не обсуждаются. Из этого нельзя вывести неявную гарантию.

Исторический смысл — расширяемый язык настройки, в котором тип, привязка, запрос и частная информация остались разными сущностями. Идея Heng Lu о приоритете работающего кода здесь служит редакционной оптикой: спецификация и наблюдаемое действие требуют разных доказательств. Она не является дополнительным правилом DHCP.

Источники: RFC 2132, RFC 2131, RFC 1048 и Running-Code Primacy Heng Lu.