Кратко

  • RFC 1048 поместил 99.130.83.99 в начало поля поставщика BOOTP. Дальше обычная опция объявляет тег, длину и значение, поэтому незнакомый элемент можно пропустить, сохранив границу следующего.
  • Cookie выбирает способ разбора, но никого не аутентифицирует. Ограничение в 64 октета, Pad, End и распределение кодов обеспечивают совместимость; правильность адресов, полномочия сервера и безопасность загрузки проверяются отдельно.

Клиент RFC 951 ещё не располагает обычным сетевым контекстом. Он может знать аппаратный адрес и выполнять короткую программу начальной загрузки, но не знает собственного IP-адреса, подходящего сервера или имени файла. Сначала BOOTP сообщает конфигурацию и место файла, затем другой протокол переносит сам файл.

В сообщении существовало 64-октетное поле vend для данных поставщика. Оно позволяло вернуть маску, шлюз и другие параметры, однако одинаковые байты могли иметь разные значения у разных производителей. RFC 951 рекомендовал начинать используемые данные четырёхбайтовым magic number, обозначающим вид информации. Общего способа пройти по остальному содержимому ещё не было.

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

Открытая метка выбирает разбор, а не собеседника

Magic cookie имеет десятичное значение 99.130.83.99, шестнадцатеричное 63.82.53.63 и передаётся в сетевом порядке байтов. RFC 1048 определяет его как идентификатор режима интерпретации последующих данных.

Увидев эти четыре октета, клиент выбирает парсер RFC 1048 вместо частной схемы производителя. Но константа общеизвестна. Она не является ключом или подписью, не удостоверяет сервер BOOTP, не доказывает неизменность сообщения после релея и не подтверждает права на объявленный маршрутизатор.

Transaction ID, аппаратный адрес и поля IP решают другие задачи: связывают ответ с ожидающим запросом и помогают доставке. Корреляция уменьшает путаницу между попытками, однако не создаёт криптографическую личность. Пакет может подходить к текущей транзакции и исходить от неполномочного сервера.

RFC 1542 позднее сформулировал риск прямо: у BOOTP нет разумного механизма аутентификации, а посторонний сервер способен выдать ложные IP-адрес, маршрутизатор или DNS. Для этого не нужно нарушать формат. Аккуратно размеченная ложь как раз проще принимается автоматически.

Длина ограничивает область незнания

После cookie обычная опция состоит из октета тега, октета длины и указанного числа октетов значения. В длину не входят тег и сама длина. Многооктетные числа используют сетевой порядок.

Благодаря этому старый клиент может встретить новую опцию и не потерять всё сообщение. Известный тег интерпретируется; неизвестный пропускается на объявленное расстояние, после чего можно искать следующий. Незнакомое содержание остаётся незнакомым, но получает чёткую границу.

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

Однако длина не подтверждает смысл. Четырёхоктетный адрес может быть устаревшим или вредоносным. Локальный тег может означать разное в двух организациях. Верное смещение не гарантирует отсутствие ошибки памяти в реализации. RFC 1084 и RFC 1497 меняли каталог, сохраняя cookie и структуру. Это свидетельство устойчивости рамки, а не одинакового качества всех программ.

Pad и End управляют остановкой

Тег 0, Pad, занимает один октет и не имеет длины. Он выравнивает данные или заполняет свободное место. Тег 255, End, тоже занимает один октет и завершает последовательность; остаток поля заполняется нулями.

Это не обычные опции с пустыми значениями. Если ждать длину после Pad, все дальнейшие границы сдвинутся. Если продолжать разбор после End, заполнение превратится в выдуманные настройки. Расширяемый формат обязан определять не только добавление, но и прекращение чтения.

В одном случае важен порядок. Если присутствуют маска подсети и шлюз, RFC 1048 требует сначала маску. Клиент должен понять локальную сеть, чтобы правильно применить шлюз. Отдельные теги делают поля различимыми, но не отменяют смысловой зависимости.

Полная небольшая грамматика поэтому включает cookie, обычные элементы, два исключения без длины, требование порядка и конец. Одного сокращения TLV недостаточно, чтобы описать безопасное поведение по краям.

Жёсткий объём превращает расширение в выбор

Cookie забирает четыре из 64 октетов. Обычная опция тратит ещё два на структуру до значения. IPv4-адресу нужны четыре, списку — кратно больше. RFC 1048 запрещает выход за vend и предлагает получать несущественные сведения через другие службы.

В первый ответ нельзя включить бесконечный каталог. Маска, маршрутизаторы, серверы времени, имён и журналирования конкурируют за место. Стандарт задаёт представление, но не выбирает местный приоритет за оператора и клиента.

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

Такой механизм удешевляет добавление опции и удорожает замену внешней границы. Когда прошивки, серверы и процессы зависят от одного синтаксиса, новый тег проще нового формата. Внутренняя гибкость может на годы закрепить исторический предел и его исключения.

Централизованная таблица может уверенно ошибаться

RFC 1048 сравнивает администрируемую базу BOOTP с распределённым обнаружением. Один ответ со всеми нужными данными эффективен: клиент быстро продолжает работу по локальной таблице. Но централизованные сведения могут быть неполными или старыми.

Администратор базы контролирует опубликованную конфигурацию BOOTP. Это не удостоверяет файл-сервер, указанный в записи, и не доказывает целостность его образа. RFC 1048 отдельно говорит, что база BOOTP недостаточна для сильной аутентификации файл-сервера; её должен обеспечивать сам сервис.

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

RFC 1542 рекомендует посылать cookie даже без опций, затем End и нулевое заполнение. Сервер узнаёт ожидаемый формат ответа. Это почти пустое высказывание о синтаксисе, а не переносимое разрешение.

DHCP унаследовал оболочку, а не гарантию

RFC 1533 применяет формат расширений BOOTP к опциям DHCP: тег, длина и значение, кроме Pad и End. Сохраняются cookie, сетевой порядок и местный диапазон. RFC 2132 позднее описывает более развитый каталог DHCP в той же линии.

Документы подтверждают преемственность формата. Они не позволяют переносить все поздние практики DHCP в сети BOOTP 1988 года или считать смысл каждой опции неизменным. RFC 1533 прямо не рассматривает вопросы безопасности. Контейнер продолжил жизнь, но не приобрёл доказательство происхождения.

Вклад RFC 1048 точен: четыре октета выбирают правила чтения, длины сохраняют границы неизвестного, Pad и End управляют проходом, а малый размер заставляет расставлять приоритеты. Личность, свежесть, полномочие и исход службы остаются за пределами cookie.

Источники и пределы доказательств

RFC 951 описывает исходный BOOTP, 64-октетное поле и рекомендацию magic number. RFC 1048 определяет cookie, грамматику, порядок, распределение и размер. RFC 1084 и RFC 1497 фиксируют редакции расширений. RFC 1533, RFC 1542 и RFC 2132 показывают линию DHCP и границу безопасности BOOTP.

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