Bootstrap Protocol
| BOOTP | |
|---|---|
| Название | Bootstrap Protocol |
| Уровень (по модели OSI) | прикладной |
| Семейство | TCP/IP |
| Создан в | 1985 |
| Порт/ID |
67/UDP (сервер), 68/UDP (клиент)[1] |
| Назначение протокола | получение сетевой конфигурации |
| Спецификация | RFC 951, RFC 1542 |
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
Для запроса и ответа загрузки используется одинаковый формат сообщения. В запросе некоторые поля имеют нулевые значения.
Структура пакета BOOTP[2]:
| Смещение сегмента |
Длина, октет |
Описание |
|---|---|---|
| 0 | 1 | Op Код операции |
| 1 | 1 | HType Тип оборудования |
| 2 | 1 | HLen Длина аппаратного адреса |
| 3 | 1 | Hops Количество пересылок |
| 4 | 4 | XID Идентификатор транзакции |
| 8 | 2 | Secs Счетчик секунд от момента отправки клиентом первого запроса |
| 10 | 2 | Не использовалось в RFC 951 Flags — поле флагов в RFC 1542 |
| 12 | 4 | CIAddr IP-адрес клиента |
| 16 | 4 | YIAddr IP-адрес, предоставленный клиенту сервером |
| 20 | 4 | SIAddr IP-адрес сервера |
| 24 | 4 | GIAddr IP-адрес промежуточного маршрутизатора |
| 28 | 16 | CHAddr Аппаратный адрес клиента |
| 44 | 64 | SName Имя хоста сервера |
| 108 | 128 | File Имя загрузочного файла |
| 236 | 64 | Vend Область для разработчиков и Дополнительные параметры |
Рассмотрим все параметры подробнее.
Код операции
Код операции (opcode) указывает на тип сообщения:
- 1 — для запроса (BOOTREQUEST);
- 2 — для отклика (BOOTREPLY).
Тип оборудования
Определяет тип используемого сетевого оборудования, используя значения аналогичные полю Hardware Type (HType, HRD) в спецификации протокола ARP[3][4].
Некоторые часто используемые значения:
| HType | Описание |
|---|---|
| 1 | Ethernet (10Mb) |
| 6 | IEEE 802 Networks |
| 7 | ARCNET |
| 15 | Frame Relay |
| 16 | Asynchronous Transfer Mode (ATM) |
| 18 | Fibre Channel |
| 20 | Serial Line |
Длина аппаратного адреса
Определяет длину аппаратного адреса в сообщении. Для сетей Ethernet и прочих, использующих IEEE 802, значение этого параметра равно 6.
Аналогичное поле в ARP-пакете — HLN.
Количество пересылок
Данный сегмент используется ретрансляторами для контроля пересылки сообщения. Значение поля устанавливается в 0 перед отправкой и увеличивается на 1 при прохождении через каждый ретранслятор.
Идентификатор транзакции
Идентификатор транзакции (transaction ID) — 32-битное целое число, которое устанавливается клиентом и возвращается сервером. Оно позволяет клиенту сопоставить отклик с запросом. Клиент устанавливает в это поле случайное число для каждого запроса.
Счетчик секунд
Когда клиент отсылает первый запрос на загрузку данных, поле счетчика секунд имеет нулевое значение. Если на запрос не приходит ответа, по завершении тайм-аута клиент снова отправляет запрос, изменяя значение в поле счетчика секунд. Для тайм-аута клиент использует случайный интервал, увеличивающийся до значения 60 с.
Данное поле не имеет специального назначения. Его содержимое может проверять сервер или сетевой монитор для определения длительности ожидания клиентом загрузки по сети. Сервер может использовать значения из поля счетчика секунд для ранжирования запросов по приоритетам, однако в настоящее время в большинстве реализаций это поле игнорируется.
Флаги
В оригинальном стандарте RFC 951 это двухбайтовое поле не заполнялось. Согласно RFC 1542 оно используется для установки флагов[5].
| Имя флага | Размер, бит | Описание |
|---|---|---|
| B | 1 | Широковещательная рассылка: при отправке оригинального сообщения клиенту неизвестен собственный IP-адрес, и этот флаг выставляется в значение "1". Такое состояние указывает получившим пакет BOOTP-серверам и ретрансляторам, что запрос от этого клиента должен быть разослан как широковещательный. |
| Reserved | 15 | Зарезервированы и не используются, значения выставлены в 0. |
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 заголовке, чтобы сопоставить отклик с запросом, или же серверы просматривают возвращенный аппаратный адрес клиента.
См. также
Примечания
- ↑ RFC951, p. 3: «The BOOTP protocol uses two reserved port numbers, 'BOOTP client' (68) and 'BOOTP server' (67)».
- ↑ RFC951, pp. 3-4.
- ↑ RFC951, p. 3: «Hardware address type, see ARP section in "Assigned Numbers" RFC».
- ↑ RFC1700, Address Resolution Protocol Parameters, pp. 163-164.
- ↑ RFC1542, Definition of the 'flags' Field, pp. 5-6: «This memo hereby designates this two-octet field as the 'flags' field».
Ссылки
- 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.
