Кратко

  • Опция 52 явно объявляет использование file, sname или обоих полей для дополнительных опций DHCP. Историческое название поля перестаёт быть достаточным описанием его содержимого.
  • Части одной опции соединяются в логическом порядке options, file, sname, а не в порядке физического расположения полей. Каждое закодированное вхождение при этом остаётся внутри своего поля.
  • Заимствование места и разделение значения — разные механизмы. Их правильная работа требует совместимых получателей и не доказывает ни доверия к настройке, ни успешной загрузки.

Повторение кода не даёт права выбрать удобную часть

При повторном появлении параметра программа может сохранить первое значение, заменить его последним или сформировать список из двух объектов. Для разделённой опции DHCP все три решения способны оказаться неверными. Перед ней могут быть части одного значения, которое ещё предстоит собрать.

RFC 3396, опубликованный в ноябре 2002 года, требует объединять данные повторных вхождений одного кода в установленном порядке. Рамки с кодом и длиной в результат не входят. Граница между частями не имеет самостоятельного смысла.

Документ иллюстрирует это коротким загрузочным путём /diskless/foo. Тринадцать байтов могут быть разделены на семь и шесть, причём разрыв проходит внутри слова diskless. Это не два файла и не список компонентов каталога. Пока части не соединены, параметр не восстановлен.

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

Старое сообщение имело места для старых задач

BOOTP помогал машине получить адрес, сервер и файл до того, как её полноценная рабочая среда была готова. В RFC 951 сентября 1985 года формат отводил конкретные участки под эту информацию.

sname занимало 64 октета для необязательного имени сервера. file занимало 128 октетов для имени загрузочного файла. Оба поля были строками с нулевым завершением. Ещё 64 октета в vend предназначались для сведений, специфичных для поставщика.

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

DHCP сохранил каркас и расширил конфигурационную задачу. RFC 2131, опубликованный в марте 1997 года, сделал options переменным по длине, сохранив размеры полей имён. Клиент должен был принимать область опций как минимум в 312 октетов; для более крупных сообщений существовал отдельный механизм согласования.

Размер всей области не следует путать с длиной одного обычного вхождения опции. Её однобайтовое поле длины может описать до 255 байтов данных. Это не означает, что весь DHCP ограничен сообщением такого размера.

Разрешение на новое назначение появилось раньше

Option Overload был определён уже в RFC 1533 октября 1993 года. Код 52 несёт один байт данных: значение 1 обозначает использование file под опции, 2 — sname, 3 — обоих полей.

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

Объявление относится к выбранным полям данного конкретного DHCP-сообщения. Оно не разрешает считать опциями любые непонятные байты и не изменяет навсегда смысл всех последующих пакетов. Неуказанное поле не становится частью дополнительного пространства по усмотрению анализатора.

RFC 2131 требует помещать объявление в обычную область options. Получатель читает её первой, затем при необходимости file и после него sname. Он узнаёт о смене интерпретации в месте, грамматика которого уже известна.

Иначе возник бы круг: чтобы обнаружить разрешение читать поле иначе, пришлось бы заранее прочитать его именно этим новым способом. Явная точка объявления устраняет догадку и делает местный выбор отправителя доступным проверке получателем.

Заимствованные байты не стали бесконечной лентой

Обычная область опций начинается с четырёхоктетного magic cookie. Далее идут элементы с кодами. Типичная переменная опция содержит код, длину и указанное число байтов данных. Код и сама длина не входят в размер данных. Pad и End — однооктетные исключения.

В переиспользуемых file и sname опции начинаются с первого байта поля. Дополнительный cookie там не ставится. Каждая используемая область должна завершить свою последовательность через End и заполнить остаток Pad. Отдельное закодированное вхождение обязано целиком помещаться в одном поле.

Даже если за соседней границей остаётся место, нельзя продолжить вхождение сквозь неё как по непрерывной физической ленте. В то же время End одной области не отменяет другие области, указанные в объявлении. Завершение контейнера и завершение всей логической конфигурации — разные события.

file и sname вместе дают 192 сырых октета пространства, но не гарантированные 192 октета полезных данных. Коды, длины, завершения, заполнение, объявление и перемещённая загрузочная информация занимают часть ёмкости. Это ограниченное повторное использование, а не безграничное расширение и не разновидность фрагментации IP.

Файл мог остаться, хотя его прежнее поле изменилось

RFC 2132 марта 1997 года определяет опцию 66 для имени TFTP-сервера, когда sname используется под опции, и опцию 67 для имени загрузочного файла при переиспользовании file.

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

В текущем реестре BOOTP/DHCP IANA присутствуют эти коды и более поздняя Domain Search с кодом 119. Это номера опций, не транспортные порты. Совпадение 67 с номером UDP-порта сервера DHCP не делает опцию указанием порта.

Реестр помогает узнавать тип параметра, но не подтверждает его эксплуатационную истинность. Имя файла не доказывает существование файла, возможность передачи или право на исполнение. Представление настройки и последующая загрузка остаются разными действиями.

Длина значения и остаток места требовали разных ответов

Один логический параметр может быть длиннее 255 байтов. Тогда даже при достаточном размере сообщения он не представим одним обычным полем длины. Другой параметр может быть короче, но не помещаться в остаток текущей области, хотя часть можно разместить в другой разрешённой области.

Ted Lemon и Stuart Cheshire рассмотрели оба случая в RFC 3396. Документ также прямо удалил предложение RFC 2131, которое по умолчанию ограничивало опцию одним появлением, и закрепил правила разделения и соединения. Это последующее уточнение, а не свидетельство, что все старые реализации уже вели себя одинаково.

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

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

Заимствование и соединение при этом независимы. Дополнительное поле может содержать целые опции. Несколько частей длинной опции могут полностью уместиться в обычной options без использования именных полей. Один механизм меняет доступные места, другой — способ восстановления одного значения.

Читатель должен был изменить порядок, не двигая поля

Физически sname стоит перед file, а оба находятся перед options. Логический агрегат RFC 3396 организован иначе: options, затем file, затем sname. Поля, которые не выбраны для переиспользования, в него не включаются.

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

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

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

Осторожный отправитель не отменял обязанностей получателя

RFC 3396 отмечал, что многие развёрнутые тогда DHCP-агенты не поддерживали соединение опций. Поэтому делить значение рекомендовалось лишь при необходимости или при уверенности, что другая сторона справится. Это наблюдение 2002 года, не оценка нынешнего распространения функции.

Уверенность могла опираться на то, что участник предоставил или запросил опцию, чья спецификация требует соединения. Администратор также мог явно настроить соответствующее предположение. Нового универсального бита способности из этого не возникало.

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

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

Координата появляется после восстановления целого

В том же ноябре 2002 года RFC 3397 определил опцию 119 для списка поиска доменов DNS. Список можно передавать несколькими вхождениями, а повторяющиеся суффиксы имён экономить через сжатие.

Указатели сжатия отсчитываются от полного соединённого блока данных опции. Коды и длины отдельных вхождений не входят в этот блок. Началом координат не является ни начало DHCP-пакета, ни начало каждого отдельного фрагмента.

Следовательно, сначала требуется логическое соединение, а уже затем разбор имён. Часть может заканчиваться внутри метки: это ещё не самостоятельное полное имя, к которому можно применить все правила завершения. Нужная граница возникает только у восстановленного объекта.

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

И правильная сборка не удостоверяет конфигурацию. RFC 3397 предупреждает, что список поиска способен направить короткое имя к другой полной доменной записи, даже если данные другого домена подписаны корректно. Валидная подпись не доказывает, что пользователь хотел выбрать именно это имя или что DHCP-сервер вправе навязать выбор.

Переиспользование оказалось полезным потому, что сохраняло ясность объявления и восстановления. Протокол не заставил всех искать смысл по внешнему виду байтов. Он определил, когда старое место читается иначе и как несколько частей снова становятся одной настройкой.