stringtranslate.com

Протокол начальной загрузки

Протокол начальной загрузки ( BOOTP ) — это протокол компьютерной сети , используемый в сетях Интернет-протокола для автоматического назначения IP-адреса сетевым устройствам с сервера конфигурации. Первоначально BOOTP был определен в RFC  951, опубликованном в 1985 году.

Хотя некоторые части BOOTP были фактически заменены протоколом динамической конфигурации хоста (DHCP), который добавляет функцию аренды, некоторые части BOOTP используются для обслуживания протокола DHCP. Некоторые DHCP-серверы также предоставляют устаревшие функции BOOTP.

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

BOOTP реализуется с использованием протокола пользовательских дейтаграмм (UDP) для транспортировки. Порт номер 67 используется сервером для приема запросов клиентов, а порт номер 68 используется клиентом для получения ответов сервера. BOOTP работает только в сетях IPv4 .

Исторически BOOTP также использовался для Unix-подобных бездисковых рабочих станций для получения сетевого местоположения их загрузочного образа в дополнение к назначению IP-адреса. Предприятия использовали его для развертывания предварительно настроенной установки клиента (например, Windows ) на вновь установленные ПК.

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

История

BOOTP был впервые определен в сентябре 1985 года [1] как замена протокола обратного разрешения адресов (RARP), опубликованного в июне 1984 года. [2] Основная причина замены RARP на BOOTP заключается в том, что RARP был протоколом канального уровня . Это затрудняло реализацию на многих серверных платформах и требовало наличия сервера в каждой отдельной IP- подсети . BOOTP представил инновацию в виде агентов ретрансляции, которые пересылали пакеты BOOTP из локальной сети с использованием стандартной IP-маршрутизации, так что один центральный сервер BOOTP мог обслуживать узлы во многих подсетях. [1] : §6 

Был определен увеличивающийся набор расширений информации о поставщиках BOOTP [3] [4] [5] [6] для предоставления клиентам BOOTP соответствующей информации о сети, такой как шлюз по умолчанию , IP-адрес сервера имен , имя домена и т. д.

С появлением протокола динамической конфигурации хоста расширения информации о поставщике BOOTP были включены в поля опций DHCP, [7] [8] , чтобы позволить DHCP-серверам также обслуживать клиентов BOOTP.

Операция

Случай 1. Клиент и сервер в одной сети.

Когда клиент BOOTP запускается, он не имеет IP-адреса, поэтому он передает в сеть сообщение, содержащее его MAC-адрес. Это сообщение называется «запросом BOOTP», и его принимает сервер BOOTP, который отвечает клиенту следующей информацией, необходимой клиенту:

  1. IP-адрес клиента, маска подсети и адрес шлюза по умолчанию.
  2. IP-адрес и имя хоста сервера BOOTP.
  3. IP-адрес сервера с загрузочным образом, который необходим клиенту для загрузки операционной системы.

Когда клиент получает эту информацию от сервера BOOTP, он настраивает и инициализирует свой стек протоколов TCP/IP, а затем подключается к серверу, на котором используется общий загрузочный образ. Клиент загружает загрузочный образ и использует эту информацию для загрузки и запуска своей операционной системы. [9]

Протокол динамической конфигурации хоста (DHCP) был разработан как расширение BOOTP. BOOTP определен в запросах на комментарии (RFC) 951 и 1084.

Случай 2. Клиент и сервер в разных сетях.

  1. Проблема с запросом bootp заключается в том, что запрос является широковещательным. Широковещательная IP-дейтаграмма не может пройти ни через один маршрутизатор . Маршрутизатор отбрасывает этот пакет.
  2. Для решения этой проблемы необходим посредник (реле).
  3. Один из хостов или маршрутизаторов можно настроить на уровне приложений для работы в качестве агента ретрансляции.
  4. Агент ретрансляции знает одноадресный адрес сервера загрузки и прослушивает широковещательные сообщения на порту 67.
  5. Когда он получает этот широковещательный пакет, он инкапсулирует сообщение в одноадресную дейтаграмму и отправляет запрос на сервер загрузки.
  6. Пакет, несущий одноадресный адрес назначения, маршрутизируется любым маршрутизатором и достигает сервера загрузки.
  7. Агент ретрансляции, получив ответ, отправляет его клиенту bootp.

Документация по стандартам IETF

Смотрите также

Рекомендации

  1. ^ AB Билл Крофт; Джон Гилмор (сентябрь 1985 г.). ПРОТОКОЛ ЗАГРУЗКИ (BOOTP). Сетевая рабочая группа. дои : 10.17487/RFC0951 . РФК 951. Проект стандарта. Обновлено RFC 1395, 1497, 1532, 1542 и 5494.
  2. ^ Р. Финлейсон; Т. Манн; Дж. Могул; М. Теймер (июнь 1984 г.). Протокол разрешения обратного адреса. Сетевая рабочая группа. дои : 10.17487/RFC0903 . СТД 38. RFC 903. Интернет-стандарт 38.
  3. ^ П. Приндевиль (февраль 1988 г.). Расширения информации о поставщиках BOOTP. Сетевая рабочая группа. дои : 10.17487/RFC1048 . РФК 1048. Устаревший. Устарело согласно RFC 1084, 1395, 1497 и 1533.
  4. ^ Дж. Рейнольдс (декабрь 1988 г.). Расширения информации о поставщиках BOOTP. Сетевая рабочая группа. дои : 10.17487/RFC1084 . РФК 1084. Устаревший. Устарело RFC 1395, 1497 и 1533. Устарело RFC 1048.
  5. ^ Дж. Рейнольдс (январь 1993 г.). Расширения информации о поставщиках BOOTP. Сетевая рабочая группа. дои : 10.17487/RFC1395 . РФК 1395. Устаревший. Устарело по RFC 1497 и 1533. Устарело по RFC 1084 и 1048. Обновляется RFC 951.
  6. ^ Дж. Рейнольдс (август 1993 г.). Расширения информации о поставщиках BOOTP. Сетевая рабочая группа. дои : 10.17487/RFC1497 . РФК 1497. Устаревший. Устарело по RFC 1533. Устарело по RFC 1395, 1084 и 1048. Обновляется RFC 951.
  7. ^ С. Александр; Р. Дромс (октябрь 1993 г.). Опции DHCP и расширения поставщиков BOOTP. Сетевая рабочая группа. дои : 10.17487/RFC1533 . РФК 1533. Устаревший. Устарело по RFC 2132. Устарело по RFC 1497, 1395, 1084 и 1048.
  8. ^ С. Александр; Р. Дромс (март 1997 г.). Опции DHCP и расширения поставщиков BOOTP. Сетевая рабочая группа. дои : 10.17487/RFC2132 . РФК 2132. Проект стандарта. Устаревший RFC 1533. Обновлен RFC 3442, 3942, 4361, 4833 и 5494.
  9. ^ «Протокол начальной загрузки (BOOTP)» . Сетевая энциклопедия .

Внешние ссылки