Bootstrap Protocol

BOOTP
Название	bootstrap protocol
Уровень (по модели OSI)	сетевой
Семейство	TCP/IP
Создан в	1985
Порт/ID	67, 68 / UDP
Назначение протокола	получение сетевой конфигурации
Спецификация	RFC 951

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

BOOTP (Bootstrap Protocol) как и 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-адрес и, при необходимости, местоположение файла загрузки.
• С помощью простейшего протокола пересылки файлов (Trivial File Transfer Protocol — TFTP) клиент загружает в собственную память необходимое программное обеспечение и начинает работу.

Формат сообщения BOOTP

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

Сообщение BOOTP состоит из :

Opcode	Тип оборудования	Длина аппаратного адреса	Количество пересылок
Идентификатор транзакции (одинаков для запроса и ответа)
Счетчик секунд от момента отправки клиентом первого запроса		Поле флагов (устарело)
IP-адрес клиента (если он известен клиенту, иначе — 0)
IP-адрес, предоставленный клиенту сервером
IP-адрес сервера
IP-адрес промежуточного маршрутизатора
Аппаратный адрес клиента
Имя хоста сервера
Имя конфигурационного файла
Область для разработчиков и Дополнительные параметры

Далее рассмотрим все параметры подробней.

Opcode

Код операции (opcode) равен 1 для запроса и 2 для отклика.

Идентификатор транзакции

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

Счетчик секунд

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

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

IP-адрес клиента

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

IP-адрес, предоставленный клиенту сервером

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

Имя хоста сервера

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

Область для разработчиков

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

Номера портов

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

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

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

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

См. также

• DHCP
• PXE