Bootstrap Protocol — Википедия

BOOTP (от англ. bootstrap protocol) — сетевой протокол прикладного уровня, используемый для автоматического получения клиентом IP-адреса. Это обычно происходит во время загрузки компьютера. BOOTP определён в RFC 951.

BOOTP, как и RARP, обеспечивает определение с помощью специального сервера IP-адреса клиента по его MAC адресу (например, при загрузке устройства, не имеющего возможности хранить свой собственный IP-адрес), а также позволяет клиентам узнавать другие параметры загрузки (например, имя программы, загружаемой затем с помощью TFTP) и использует UDP в качестве протокола транспортного уровня. Это позволяет использовать маршрутизаторы (bootp relay) для передачи запросов и ответов из одного сегмента локальной сети в другой. Протокол DHCP (англ. Dynamic Host Configuration Protocol) является надстройкой над BOOTP (для совместимости с bootp relay) и позволяет серверу выделять IP-адреса клиентам динамически на ограниченный срок.

Обслуживающий персонал тех (?) лет столкнулся с проблемами постоянного подключения и перемещения новых устройств, а также с необходимостью изменения сетевой конфигурации для соответствия современным требованиям к сетям. Все это привело к необходимости создания механизма для автоматизации конфигурации сетевых узлов, распределенных операционных систем и сетевого программного обеспечения. Наиболее эффективным способом реализации такого механизма может быть сохранение конфигурационных параметров и образов программного обеспечения на одном или нескольких серверах загрузки (boot server). Во время запуска система взаимодействует с таким сервером, получает от него начальные параметры конфигурации и при необходимости загружает с него нужное программное обеспечение.

BOOTP был введен в RFC 951 как замена устаревшему RARP. Первоначально ВООТР разрабатывался для бездисковых рабочих станций. Современные условия привели к необходимости автоматизации загрузки систем, имеющих в ПЗУ только базовые средства для IP, UDP и TFTP. Исходный сценарий загрузки выглядел следующим образом:

• Клиент отправляет в широковещательной рассылке сообщение UDP на загрузочную информацию.
• Сервер возвращает клиенту его IP-адрес и, при необходимости, местоположение файла загрузки.
• С помощью простейшего протокола пересылки файлов TFTP (англ. Trivial File Transfer Protocol) клиент загружает в собственную память необходимое программное обеспечение и начинает работу.

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

Структура пакета BOOTP^[2]:

Рассмотрим все параметры подробнее.

Код операции (opcode) указывает на тип сообщения:

• 1 — для запроса (BOOTREQUEST);
• 2 — для отклика (BOOTREPLY).

Определяет тип используемого сетевого оборудования, используя значения аналогичные полю Hardware Type (HType, HRD) в спецификации протокола ARP^[3][4].

Некоторые часто используемые значения:

Определяет длину аппаратного адреса в сообщении. Для сетей Ethernet и прочих, использующих IEEE 802, значение этого параметра равно 6.

Аналогичное поле в ARP-пакете — HLN.

Данный сегмент используется ретрансляторами для контроля пересылки сообщения. Значение поля устанавливается в 0 перед отправкой и увеличивается на 1 при прохождении через каждый ретранслятор.

Идентификатор транзакции (transaction ID) — 32-битное целое число, которое устанавливается клиентом и возвращается сервером. Оно позволяет клиенту сопоставить отклик с запросом. Клиент устанавливает в это поле случайное число для каждого запроса.

Когда клиент отсылает первый запрос на загрузку данных, поле счетчика секунд имеет нулевое значение. Если на запрос не приходит ответа, по завершении тайм-аута клиент снова отправляет запрос, изменяя значение в поле счетчика секунд. Для тайм-аута клиент использует случайный интервал, увеличивающийся до значения 60 с.

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

В оригинальном стандарте RFC 951 это двухбайтовое поле не заполнялось. Согласно RFC 1542 оно используется для установки флагов^[5].

Если клиент уже знает свой IP адрес, он заполняет поле IP адрес клиента (client IP address). Если нет — клиент устанавливает это значение в 0. В последнем случае сервер вставляет в поле ваш IP адрес (your IP address) IP адрес клиента. Поле IP адрес сервера (server IP address) заполняется сервером. Если используется уполномоченный сервер, он заполняет IP адрес шлюза (gateway IP address).

Клиент должен установить свой аппаратный адрес клиента (client hardware address). Это то же значение, которое находится в заголовке Ethernet и в поле UDP датаграммы, благодаря чему оно становится доступным любому пользовательскому процессу (например, серверу BOOTP), который получил датаграмму. Обычно процессу, работающему с UDP датаграммами, сложно или практически невозможно определить значение, находящееся в поле заголовка Ethernet датаграммы, в которой передается UDP датаграмма.

Имя хоста сервера (server hostname) это строка, которая заполняется сервером (не обязательно).

Сервер также может заполнить поле имени загрузочного файла (boot filename). В это поле заносится полный путь к файлу, который используется при загрузке.

Первоначально область для разработчиков (vendor specific area) использовалась в сообщениях для пересылки сведений, специфичных для конкретной реализации. Однако в начале применения ВООТР эта область оставалась свободной, хотя большой объём информации (например, маска подсети или адрес маршрутизатора по умолчанию) формально не включался в сообщения. Область для разработчиков служила для размещения дополнительных конфигурационных параметров, а также сведений, специфичных для разработчика. В этой области определено достаточно много различных полей.

Для BOOTP выделено два заранее известных порта: 67 для сервера и 68 для клиента. Это означает, что клиент не выбирает неиспользуемый динамически назначаемый порт, а использует порт номер 68. Причина, по которой были выбраны два номера портов, вместо того чтобы использовать только один для сервера, заключается в том, что сервер может отправить отклик (хотя обычно он этого не делает) широковещательным образом.

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

Если клиент воспользуется заранее известным портом сервера (67), все сервера в сети будут вынуждены просматривать каждый широковещательный отклик. (Если все сервера были «разбужены», им придется проверить код операции, определить, что это отклик, а не запрос, и снова «уснуть».) Поэтому выбор был остановлен на том, как все сделано сейчас, то есть клиент имеет свой собственный единственный заранее известный порт, который отличается от заранее известного порта сервера.

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

• DHCP
• PXE

• Bill Croft, John Gilmore. Bootstrap Protocol (BOOTP) (англ.). IETF (сентябрь 1985). Дата обращения: 29 мая 2017.
• J. Reynolds, J. Postel. Assigned Numbers (англ.). IETF (октябрь 1994). Дата обращения: 29 мая 2017.
• W. Wimer. Clarifications and Extensions for the Bootstrap Protocol (англ.). IETF (октябрь 1993). Дата обращения: 29 мая 2017.