Кратко

  • RFC 3396 определил повторные экземпляры одного кода DHCPv4 как последовательные фрагменты логического значения — из-за предела 255 октетов или нехватки места в перегруженном поле.
  • Сборка шла в логическом порядке options, file, sname, отличавшемся от физического. Граница не несла смысла, а правильная отправка не доказывала, что установленный получатель умеет собрать объект.

У старого формата могут быть два порядка. Один задаёт физическое размещение полей. Другой появляется, когда содержимое этих полей используется как продолжение одной структуры. RFC 3396 обязал DHCPv4-разборщик следовать второму прежде, чем объяснять байты.

Документ был опубликован в ноябре 2002 года как стандарт. Переменная опция состояла из октета кода, октета длины и от нуля до 255 октетов значения. Более длинный объект не помещался в один экземпляр.

RFC 2131 уже требовал объединять повторы, но не полностью определял порядок и одновременно говорил, что опция появляется один раз, если её документ не разрешает иное. RFC 3396 удалил эту фразу. Одинаковый код стал общим признаком частей одного объекта, собираемого до обработки.

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

Три места пришли из BOOTP. Помимо обычной области options, режим option overload разрешал использовать file и sname. RFC создал логический агрегированный буфер: сначала options, затем file, затем sname.

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

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

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

Пример делил Bootfile Name /diskless/foo на два экземпляра кода 67. Ни /diskle, ни ss/foo не были самостоятельными именами. Небольшой пример показывал, что правило защищает идентичность, а не только большие объёмы.

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

RFC ввёл категории обязательного и необязательного объединения. Опция становилась обязательной лишь тогда, когда её спецификация прямо ссылалась на RFC 3396. Делить следовало только при необходимости, наличии свидетельства способности партнёра или явной административной настройке.

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

Опция аутентификации RFC 3118 тоже могла быть разделена. При обнулении поля перед созданием или проверкой MAC код учитывал его прохождение через несколько экземпляров. Обработка контейнеров вместо логического объекта могла защищать неверное представление.

RFC 3397, RFC 3361, RFC 3442 и RFC 3925 применили основу к поиску доменов, SIP-прокси, бесклассовым маршрутам и структурам поставщиков. Их грамматика была самостоятельной; RFC 3396 сначала поставлял ей единый поток значения.

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

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

Принцип Лу Хэна о минимальной начальной спецификации объясняет общий договор: код, порядок, непрерывность и отсутствие смысла у границы без навязывания буферов. Приоритет работающего кода требует испытать неудобные разрывы, три поля и конечное применение.

RFC 3396 поставил идентичность выше местоположения. Части могли быть разными и далёкими. Первая обязанность получателя состояла не в быстром понимании каждого фрагмента, а в отказе понимать его до появления целого.

Источники