Кратко

  • BOOTP позволял бездисковому клиенту запросить IP-адрес, сервер и имя загрузочного файла ещё до появления обычного IP-соединения; затем файл передавался отдельно, обычно по TFTP.
  • Ответ создавал новую проблему: не зная адреса, клиент не мог ответить на ARP. RFC 951 описывал временную запись ARP-кэша на сервере или широковещательный ответ; позднее правила ретрансляции позволили передавать запрос через подсети.

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

В сентябре 1985 года Билл Крофт и Джон Гилмор описали эту проблему в RFC 951. BOOTP не передавал файлы. Он обслуживал первый этап — определение адреса и выбор загрузочного файла. PROM клиента мог запросить адрес, сервер и имя файла; после ответа второй этап, обычно через TFTP, загружал файл в память. Предполагался автоматический запуск без участия человека при включении машины. Документ описывал проект протокола, а не подсчитывал число реально использовавших его устройств. (RFC 951, §§ 2, 7.5.)

Для отправки запроса не требовался IP-адрес, которого клиент ещё не знал. Если сервер также не был задан, клиент мог послать IP/UDP-пакет с нулевым исходным адресом на 255.255.255.255 — широковещательный адрес локального сегмента. Запрос содержал также тип и аппаратный адрес клиента, а ещё идентификатор транзакции. Сервер мог найти соответствующий аппаратному адресу IP-адрес в собственной базе, записать результат в поле ответа yiaddr и выбрать полный путь к загрузочному файлу. Общий запрос вроде unix мог разрешиться в файл, назначенный именно этому клиенту. Локальная запись на сервере становилась частью процесса запуска. (RFC 951, §§ 2–3, 7.1, 7.3, 9.)

У первого ответа была своя проблема курицы и яйца. Обычно серверу нужен ARP, чтобы определить канальный адрес получателя IP-пакета. Но клиент ещё не знал собственного адреса и не мог ответить на ARP-запрос сервера. RFC 951 предлагал два обхода. Если ядро или драйвер передающей стороны это позволяли, можно было создать временную запись ARP-кэша по аппаратному адресу клиента и предложенному IP-адресу с ограниченным сроком действия. В RFC особо отмечалось, что такую возможность имела UNIX 4.2 BSD. Без неё сервер мог отправить ответ широковещательно через интерфейс клиентской сети. Выбор зависел от локальных возможностей системы, отправлявшей ответ. (RFC 951, § 4.)

Два UDP-порта помогали доставлять ответ. Запросы шли на порт BOOTP-сервера 67, а ответы — на клиентский порт 68. RFC 951 объяснял: ядро могло отфильтровать широковещательные ответы на компьютерах, где клиентский порт не прослушивался, и не будить демоны BOOTP-серверов на других узлах. Случайный порт клиента мог также сделать широковещательный ответ похожим на сообщение для процесса, запущенного на другом компьютере. Это было не простое соглашение о номерах: оно не позволяло ответу для одной загружающейся машины стать событием приложения для всего сегмента. (RFC 951, § 3.)

Загрузочный сервер находился не обязательно в том же сегменте. RFC 951 допускал загрузку через шлюзы как необязательную функцию, требующую сотрудничества шлюза с сервером. Шлюз или другой агент мог принять широковещательный запрос, указать в giaddr сеть клиента и передать запрос серверу. Авторы предостерегали от безусловной повторной рассылки повсюду: так могли образоваться петли. В октябре 1993 года RFC 1542 точнее определил эту границу: агент ретрансляции BOOTP — не обычный IP-маршрутизатор, прозрачно пересылающий датаграмму. Он мог принять сообщение BOOTP как конечный адресат и сформировать новое сообщение BOOTP. Функция могла работать на маршрутизаторе или на отдельном узле в подсети клиента. Ретрансляция была специально настроенной службой со своими правилами обработки. (RFC 951, § 8; RFC 1542, §§ 4–4.1.)

Поэтому не стоит сводить BOOTP к «старому DHCP». В RFC 2131 DHCP позже описан как расширение механизма BOOTP; формат сообщений и поведение ретрансляторов сохранены ради взаимодействия с уже существовавшими клиентами. Главное добавление — ограниченная по сроку аренда адреса: адрес можно использовать повторно после того, как клиент в нём перестал нуждаться. Модель BOOTP 1985 года искала адрес и загрузочный файл в серверных записях. DHCP также поддерживает ручное назначение. Разница не в том, что все адреса стали временными, а в появлении динамического назначения на уровне протокола. (RFC 2131, §§ 1–2.)

Историческая задача BOOTP была ограниченной, но необходимой. Протокол не делал бездисковый компьютер независимым, не подтверждал личность пользователя и сам не передавал образ операционной системы. Он задавал, как компьютеру с аппаратным адресом, но без пригодной IP-идентичности, запросить следующие данные для запуска; как сервер выбирает их; и как ответ возвращается до того, как ARP начинает работать обычным образом. В этом случае подключение начиналось с широковещательного запроса в локальном сегменте, явной записи на сервере и ответа, требовавшего особой обработки.

Источники и ограничения

RFC 951 был предложением для обсуждения; он фиксирует предполагаемое поведение, а не распространённость протокола. Упоминание кэша ARP в 4.2 BSD не доказывает, что такая функция была в каждой реализации. RFC 1542 описывает более поздние правила ретрансляции, но не подтверждает их повсеместное соблюдение. BOOTP выбирал сетевые параметры и имя файла; передачу файла выполнял отдельный этап. DHCP добавил динамические аренды, сохранив также ручное назначение адресов.