Bootstrap protocol что это

Обновлено: 04.07.2024

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

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

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

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

Bog BOS: Протокол BOOTP/DHCP

Порт сервера - UDP/67 (BOOTPS), клиента - UDP/68 (BOOTPC). Клиент делает широковещательный (255.255.255.255 - всем в локальной сети, номера которой я не знаю) запрос bootrequest (один нефрагментированный пакет): обязательно содержит аппаратный MAC адрес клиента и может содержать преполагаемый IP-адрес клиента, имя сервера и обобщенное имя файла для загрузки. Сервер отвечает пакетом bootreply (обычно unicast, т.к. MAC и IP адреса клиента ему известны): IP-адрес клиента, обобщенное имя файла замещается на полное имя файла исходя из конфигурации сервера, типа и адреса клиента и др. Собственно загрузка файла осуществляется клиентом с помощью протокола TFTP. Клиент должен быть в состоянии ответить на ARP запросы, чтобы мог работать TFTP-сервер.

  • тип пакета: bootrequest или bootreply
  • тип оборудования (ethernet 10 Mbit = 1, ht, hardware ethernet)
  • длина MAC адреса (6)
  • число пройденных прокси, каждый прокси добавляет 1 (не более 16?)
  • номер транзакции (0 или случайное число, позволяет клиенту отличить ответ на свой запрос от чужого)
  • число секунд после первого bootrequest (позволяет запасному BOOTP серверу заметить неработоспособность основного)
  • требование к серверу отвечать широковещательным пакетом
  • IP адрес клиента, предполагаемый самим клиентом (должен уметь отвечать на запросы ARP) или 0.0.0.0
  • IP адрес клиента, возвращаемый сервером (ip, fixed-address)
  • IP адрес следующего сервера (сюда же будет направлен TFTP запрос, sa, next-server)
  • IP адрес прокси (это не обязательно маршрутизатор!)
  • MAC адрес клиента (ha)
  • имя сервера (64 байта)
  • имя загрузочного файла (128 байт, filename)
  • дополнительная информация (vendor-specific или options, 64 байта для BOOTP, переменная длина для DHCP)

Средств обеспечения безопасности нет, в ответ клиент может получить фальшивый пакет. Поэтому на периферии сети порты UDP/67 и UDP/68 должны быть заблокированы сетевым экраном, а на сервере BOOTP должны быть проделаны дырки в ipchains (привожу формат /etc/sysconfig/ipchains):

Аналогичные дырки надо проделать для исходящих пакетов сервера и пакетов, пересылаемых DHCP прокси.

Если в ядре включена фильтрация поддельных IP-адресов (martian address filtering), то ее придется отключить (по крайней мере для адресов 0.0.0.0 и 255.255.255.255).

Экран можно усилить, заменив "универсальные" 0.0.0.0/0.0.0.0 на адреса ваших клиентов/сервера, но учитывайте, что исходящими IP адресами клиентов могут быть также 0.0.0.0, а входным - 255.255.255.255.

  • DHCPDISCOVER (1) - широковещательный запрос клиента при первоначальном поиске сервера, может содержать желаемый для получения IP адрес и время аренды
  • DHCPREQUEST (3) - широковещательный ответ на DHCPOFFER (должен содержать идентификатор сервера), либо запрос на возобновление аренды адреса после перезагрузки клиента или истечения предыдущего интервала аренды; клиент может выбирать из нескольких предложений DHCPOFFER; может включать список требуемых параметров
  • DHCPDECLINE (4) - ответ на DHCPOFFER с отказом принять адрес (например, клиент выяснил с помощью ARP или ICMP, что адрес занят); клиент начинает всё с начала
  • DHCPRELEASE (7) - освобождение адреса
  • DHCPINFORM (8) - клиент получил адрес с помощью другого механизма и нуждается только в прочих параметрах
  • DHCPOFFER (2) - ответ на DHCPDISCOVER, поле yiaddr содержит предлагаемый адрес (он пока не зарезервирован!)
  • DHCPACK (5) - согласие на выделение адреса по DHCPREQUEST или DHCPINFORM (в этом случае сервер не проверяет допустимость адреса); клиент может пользоваться им оговоренное время
  • DHCPNAK (6) - отказ на выделение адреса по DHCPREQUEST (например, в промежутке между DHCPOFFER и DHCPREQUEST адрес был выделен другому); клиент начинает всё с начала

Пакет bootp-2.4.3-7.i386.rpm (Red Hat Linux 5.2). Содержит программы bootpd и bootptest. Конфигурационный файл - /etc/bootptab (см. bootptab(8)):

Устанавливается и на нынешние версии Red Hat Linux, только надо создать файл /etc/xinetd.d (не забыть презапустить xinetd: "/etc/rc.d/init.d/xinetd reload")

Сервер bootpd от HP в комплекте программ для JetDirect. Тестовая программа bootpquery делает запрос и выводит ответ BOOTP сервера. В качестве параметров можно указать MAC адрес клиента (если не совпадает с настоящим, то сервер д.б. возвращать широковещательный ответ) и имя сервера (ключ -s). Конфигурационный файл - /etc/bootptab (см. bootptab(8)):

rpc.bootparamd в Solaris использует данные из /etc/bootparams, реализует специфическую для Sun RPC версию сервера, обеспечивающего дополнительные параметры для загрузки. Скрипт /etc/init.d/nfs.server (AKA /etc/rc3.d/S15nfs.server) запускает "/usr/sbin/rpc.bootparamd", если существует директория /tftproot. Если у вас нет бездисковых станций Sun, то он вам не нужен.

Сервер bootparamd в Red Hat Linux поставляется в виде пакета bootparamd-0.17-7 (RH 7.2) и реализует ту же самую специфическую для Sun RPC версию сервера, обеспечивающего дополнительные параметры для загрузки.

Столкнулся с забавной "плюшкой" firmware JetDirect: все IP-адреса в списке дополнительных элементов должны быть выровнены на границу слова, поэтому строки переменной длины (имена хостов и файлов) должны быть в конце списка, либо иметь четную длину. bootpd из поставки JetDirect знает об этом, а для dhcpd и стандартного bootpd пришлось менять имена хостов.

Пакет dhcp-2.0pl5-8 (RH 7.2) или dhcp-3.0pl1-15 (RH 8.0) или dhcp-3.0.1-11 (FC3) или dhcp-3.0.5-7.el5 (CentOS5.1) содержит BOOTP/DHCP сервер dhcpd и прокси dhcrelay от ISC (имеются также пакеты dhclient и dhcp-devel). Поддерживается работа DHCP клиента, сервера и прокси. Обеспечивается динамическое изменение DNS. Перед выдачей динамического адреса клиенту запись об этом заносится в конец специального файла (dhcpd.leases(5), /var/lib/dhcp/dhcpd.leases) для страховки, т.е. правильным является последнее значение. Время от времени создаётся новый файл и переименовывается, чтобы размер файла не вырос до бесконечности. Файл содержит записи аренды, объявления хостов, групп и подгрупп в формате dhcpd.conf (объявления хостов, групп и подгрупп для объектов, динамически созданных с помощью OMAPI, см. ниже). Каждая запись аренды содержит выделенный IP-адрес, время начала и конца аренды в человеколюбивом формате (но в UTC), тип оборудования и MAC адрес, идентификатор клиента, host-name, abandoned (адрес нельзя было выдавать), текущее и следующее состояния аренды, agent.circuit-id и agent.remote-id (см. описание опций). В версии 3.0 убрана поддержка неизвестных серверу опций в виде "option-144", теперь их необходимо описывать явно. Журнал записывается на syslog, источник - DAEMON. Процедура запуска в файле /etc/rc.d/init.d/dhcpd (start, stop, restart, status). Параметры командной строки хранятся в файле /etc/sysconfig/dhcpd. Для обеспечения запуска при загрузке надо выполнить

После запуска номер процесса сохраняется в файле /var/run/dhcpd.pid. После изменения конфигурационного файла /etc/dhcpd.conf (описание - dhcpd.conf(5), dhcp-options(5), dhcp-eval(5)) необходимо перезапустить сервер. Кроме сервера протокола BOOTP обеспечивает сервер протокола DHCP, поэтому имеет множество параметров настройки, но для каждого клиента BOOTP достаточно иметь секцию host в /etc/dhcpd.conf (subnet, естественно, общий для всей подсети), например, обеспечение загрузки сетевого принтера HP JetDirect для dhcp-2.0:

  • -p UDP-порт (по умолчанию - 67, клиентский порт принимается на 1 больше)
  • -cf имя-конфигурационного-файла (/etc/dhcpd.conf)
  • -lf имя-хранилища-выданных-адресов (/var/lib/dhcp/dhcpd.leases)
  • -q (не выводить copyright при запуске)
  • -t (только проверка синтаксиса конфигурационного файла)
  • -T (только проверка синтаксиса хранилища выданных адресов)
  • -tf имя-файла (записывать все транзакции в файл)
  • -play имя-файла (проиграть все транзакции из файла)
  • список интерфейсов, на которых слушать широковещательные пакеты (по умолчанию все активные широковещательные интерфейсы)

Протокол OMAPI позволяет подсоединяться к серверу по TCP/7911 (с аутентификацией, TSIG), чтобы проверить его состояние или изменить конфигурацию или содержимое БД (просмотр, создание, удаление, просмотр и изменение атрибутов для объектов типа аренда, хост, группа, управление). Имеется командная оболочка omshell(1).

  1. объявление host (по идентификатору клиента или MAC адресу; сначала просматриваются те, которые содержат фиксированный IP адрес, подходящий для подсети клиента, затем не содержащие фиксированных адресов)
  2. объявление class
  3. объявление pool (по IP адресу)
  4. объявление subnet (по IP адресу)
  5. объявление shared-network (по IP адресу)
  • known-clients;
  • unknown-clients;
  • members of "имя-класса";
  • dynamic bootp clients; (выделять ли адреса из пула клиентам BOOTP)
  • all clients;
  • выражение-1 = выражение-2
  • булевское-выражение-1 and булевское-выражение-2
  • булевское-выражение-1 or булевское-выражение-2
  • not булевское-выражение
  • exists имя-опции
  • known (т.е. имеется объявление host для этого клиента)
  • static
  • substring (выражение, смещение, длина)
  • suffix (выражение, длина)
  • option имя-опции-в-запросе
  • config-option имя-опции-в-конфиге
  • hardware
  • packet (смещение, длина)
  • строка в кавычках
  • шестнадцатеричная последовательность вида 17:23:19:a6:42:ea
  • concat (выражение, . выражение)
  • reverse (размер-блока, выражение)
  • leased-address
  • binary-to-ascii (система-счисления, число-бит-в-числе, разделитель, выражение)
  • encode-int (число, число-бит)
  • extract-int (выражение, число-бит)
  • pick-first-value (выражение-1, . )
  • host-decl-name
  • lease-time
  • число
  • client-state (только для конфигурации клиента)
    • Booting
    • Reboot
    • Select
    • Request
    • Bound
    • Renew
    • Rebind (запрос будет широковещательным)

    Сервер поддерживает протокол восстановления (failover, draft-ietf-dhc-failover-07.txt) - два DHCP сервера разделяют общий пул динамически распределяемых адресов и подменяют друг друга в случае падения. Протокол не стандартизован (и недодуман) до конца - чувствуйте себя бета-тестерами, если хотите. Описание опускаю.

    • ad-hoc (экспериментальный) - нестандартный и признанный устаревшим
    • interim (временный) - соответствует проектам стандартов draft-ietf-dhc-ddns-resolution-. txt, draft-ietf-dhc-fqdn-option-. txt и draft-ietf-dnsext-dhcid-rr-. txt, но не полностью
    • не реализованный пока алгоритм, соответствующий будущему стандарту

    Возможно назначить выполнение блока операторов при наступлении одного из типов событий: выделение адреса (commit), освобождение (release), истечение времени аренды (expiry).

    11.1 Введение

    Наиболее заметным явлением в компьютерной области, произошедшим в последние несколько лет, является распространение сетей TCP/IP на настольные системы. Необходимая для этого инфраструктура — маршрутизаторы, мосты, коммутаторы и концентраторы — увеличилась до соответствующего такому расширению количества.

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

    В этой главе мы познакомимся с двумя протоколами. Первым был создан протокол Bootstrap Protocol (BOOTP), обеспечивающий присваивание IP-адресов по таблице соответствия между физическими и IP-адресами. Администратор должен вручную создать такую таблицу на сервере BOOTP. Усовершенствованная версия BOOTP названа протоколом динамической конфигурации хостов (Dynamic Host Configuration Protocol — DHCP). DHCP позволяет полностью автоматизировать присваивание IP-адресов и обладает другими полезными свойствами.

    11.2 Требования протокола BOOTP

    Некоторым компьютерам для запуска требуется небольшое число конфигурационных параметров, другим — длинный подробный список значений множества таких параметров. Некоторым операционным системам, например настольным сетевым станциям, хостам Unix, требуется полная загрузка всего образа программного обеспечения. Системам, подобным маршрутизаторам, мостам, коммутаторам или концентраторам, требуется как получение конфигурационных параметров, так и загрузка необходимого программного обеспечения.

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

    11.3 Возможности BOOTP

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

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


    Рис. 11.1. Конфигурирование BOOTP на настольном клиентском компьютере

    11.4 Необходимость DHCP

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

    DHCP расширяет возможности BOOTP и устраняет некоторые неопределенности, возникающие при использовании BOOTP и приводящие к неоптимальному взаимодействию в сети.

    11.5 Первая версия BOOTP

    Первоначально BOOTP разрабатывался для бездисковых рабочих станций. Современные условия привели к необходимости автоматизации загрузки систем, имеющих в ПЗУ (постоянном запоминающем устройстве, которое сохраняет информацию даже после отключения компьютера от сети. — Прим. пер.) только базовые средства для IP, UDP и TFTP. Исходный сценарий загрузки (см. рис. 11.2) выглядел следующим образом:


    Рис. 11.2. Локальное взаимодействие между сервером загрузки и клиентом

    Администраторы быстро поняли, что лучше использовать BOOTP для загрузки большего объема конфигурационных данных и настраивать по этому протоколу системы с собственными жесткими дисками (которым не требуется загрузка программного обеспечения).

    Системам, которым требуется TFTP для загрузки программного обеспечения, удобнее использовать один сервер для параметров BOOTP, а другой (или несколько) — для загрузки программного обеспечения (см. рис. 11.3). Например, программное обеспечение операционной системы лучше получать с сервера с тем же типом операционной системы, что и у клиента.


    Рис. 11.3. Использование отдельных серверов для загрузки параметров и программного обеспечений

    11.6 Эволюция BOOTP

    Протокол BOOTP обеспечивает в работе достаточную гибкость:

    Таблица 11.1 Параметры BOOTP и DHCP

    Операция

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

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

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

    СОДЕРЖАНИЕ

    11.7 Протокол BOOTP

    Рассмотрим более подробно протокол начальной загрузки (Bootstrap Protocol — BOOTP). Он является простейшим приложением для запроса/ответа по протоколу UDP.


    11.7.2 Доставка запроса от клиента на сервер

    Клиент не имеет сведений об адресе для направления запроса и отправляет его с IP-адресом источника 0.0.0.0 и IP-адресом приемника 255.255.255.255.


    Рис. 11.5. Выбор заданного сервера

    11.7.3 Использование промежуточного агента

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


    Рис. 11.6. Промежуточная пересыпка запроса загрузки на удаленный сервер

    11.7.4 Присваивание IP-адресов

    Администратор конфигурирует сервер BOOTP для присваивания системам IP-адресов посредством ручного создания таблицы отображения на IP-адрес комбинации типа оборудования и аппаратного адреса клиента. Кодирование типов оборудования определяется документом Assigned Numbers. Например, для Ethernet код типа оборудования = 1. Таблица должна выглядеть как:

    Тип оборудования Аппаратный адрес IP-адрес
    1 02 60 8С 12 14 AA 128.121.2.5
    1 08 00 20 D3 20 14 128.121.2.19

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

    Простейший сценарий для клиента, не знающего своего IP-адреса:

    11.7.5 Загрузка клиента, знающего собственный IP-адрес

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

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

    11.7.6 Конфигурирование загрузки программного обеспечения

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

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

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

    Короткое имя IP-адрес сервера TFTP Путь к файлу
    SunOS 128.121.50.2 /bin/vmunix

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

    11.7.8 Ответ безадресному клиенту

    Если клиент не заполнил поле предварительно заданного IP-адреса, такой адрес присваивается сервером. Простейшим способом возврата ответа клиенту в этом случае будет такой:

    Однако некоторые старые клиенты неспособны принимать датаграммы IP с явно указанным IP-адресом, пока не будут сконфигурированы на этот адрес. Данная проблема называется "яйцо или курица" (что было раньше? — Прим. пер.).

    Такие клиенты могут принимать датаграммы на порт назначения 68 и с широковещательным IP-адресом 255.255.255.255. Новые клиенты BOOTP предпочитают прием ответа по широковещательному IP-адресу посредством установки в 1 флага широковещательной рассылки (находится в поле флагов) при отправке своего запроса.

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

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

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

    11.8 Возможности DHCP

    DHCP существенно расширяет возможности BOOTP. К наиболее значимым изменениям относятся:

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

    11.8.1 Администрирование и автоматизация конфигурирования

    DHCP позволяет существенно снизить объем администрирования для конфигурирования системы. При необходимости можно просто указать блок IP-адресов, из которого сервер DHCP будет присваивать адреса клиентам в локальной сети. Это легко может сделать администратор системы, освободив время для ввода данных о других критических параметрах (например, маски подсети, адресов DNS или адресов маршрутизаторов по умолчанию для данной локальной сети). Если необходимо, администратор может указать дополнительные конфигурационные параметры.

    Протокол позволяет серверу автоматически присвоить клиенту IP-адрес из выделенного блока и послать ему заданный набор параметров.

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

    История

    BOOTP был впервые определен в сентябре 1985 года в RFC 951 как замена протокола обратного разрешения адресов RARP , опубликованного в RFC 903 в июне 1984 года. Основная причина замены RARP на BOOTP заключается в том, что RARP был протоколом канального уровня . Это затрудняло реализацию на многих серверных платформах и требовало наличия сервера в каждой отдельной IP- подсети . BOOTP представил инновационные агенты ретрансляции, которые пересылали пакеты BOOTP из локальной сети с использованием стандартной IP-маршрутизации, так что один центральный сервер BOOTP мог обслуживать хосты во многих подсетях.

    11.8.2 Перемещения и изменения

    Что произойдет, если пользователь переместит компьютер в другое место, подключив его к иной сети или подсети? Во время загрузки компьютер, использующий DHCP, автоматически изменит свой IP-адрес и маску подсети, а также при необходимости — маршрутизатор по умолчанию и DNS. Без DHCP все эти изменения приходилось выполнять вручную.

    11.9 Механизмы DHCP

    11.9.1 Присваивание IP-адресов

    В DHCP поддерживаются три типа присвоения адресов:

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

    11.9.2 Аренда адресов

    Процесс выделения адресов предполагает запрос клиентом IP-адреса на определенный период времени (возможно, что и навсегда). Сервер предоставляет клиенту адрес в аренду, указывая период использования данного адреса. Клиент должен периодически обновлять свои права на аренду, иначе через заданный интервал времени он потеряет это право. Потерянный адрес можно использовать повторно (например, для другого клиента. — Прим. пер.).

    Для продления аренды адреса клиент идентифицирует свои права. При первичном выделении адреса клиенту через поле идентификатора клиента DHCP присваивается определенное значение, которое и будет применяться во всех последующих взаимодействиях с сервером. Иначе аренда идентифицируется типом оборудования клиента, аппаратным адресом и присвоенным IP-адресом,

    11.9.3 Связывание

    Сервер DHCP хранит таблицу соответствия между клиентами и их конфигурационными параметрами. Связывание заключается в назначении каждому клиенту IP-адреса и набора конфигурационных параметров.

    11.10 Совместимость и различия

    Самым заметным изменением стало переименование области для разработчика в поле Options (варианты). Добавлены и несколько дополнительных вторичных полей, включая следующие:

    Пример успешного начального взаимодействия между клиентом и сервером:

    1. Клиент посылает широковещательную рассылку (DHCPDISCOVER) для поиска одного или нескольких серверов.

    11.10.3 Возобновление

    Клиенты могут продлить аренду адресов посредством быстрого обмена с сервером:

    11.11 Параметры загрузки

    Параметры таблицы 11.1 могут содержаться в ответах протоколов BOOTP или DHCP, а параметры таблицы 11.2 могут использоваться только в DHCP.

    Таблица 11.2 Параметры DHCP

    Допустимо включать в списки большее число параметров. Текущие требования рассмотрены в последней версии RFC Assigned Numbers.

    Многие значения представляют собой списки IP-адресов, где адреса должны появляться в порядке предпочтения.

    11.12 Другие методы автоматизации конфигурирования

    Механизм исследования ICMP-маршрутизаторов имеет некоторое преимущество, поскольку предоставляет непрерывно обновляемую информацию о доступных в сети маршрутизаторах.

    11.13 Дополнительная литература

    Приведенный список литературы действителен на момент написания книги:

    Интернет технологии (архив ИПМ 2001-2010, Богомолов)

    DHCP (Dynamic Host Configuration Protocol) - протокол динамической конфигурации хоста.

    DHCP является расширением и дополнением протокола BOOTP, который предназначен для выдачи IP-адресов бездисковым машинам.

    Используется транспортный протокол UDP.

    DHCP построен по схеме клиент-сервер.

    Сервер должен отвечать на пакеты с IP-адресом 255.255.255.255, т.к. клиент может не знать где находится (какая IP-сеть, какой IP-адрес у DHCP).

    Порт сервера по умолчанию 67.

    Порт клиента по умолчанию 68.

    Механизмы выделения IP-адресов сервером DHCP:

    Динамическое присвоение - присваивает клиенту IP-адрес на ограниченное время.

    Ручное выделение - IP-адрес клиента привязывается к адресу канального уровня (MAC-адрес для Ethrnet) клиента в базе DHCP, сетевым администратором.

    Основные компоненты службы:

    Relay Agent (агент пересылки) BOOTP - хост (маршрутизатор), который осуществляет связь между клиентом и сервером DHCP. В 2001г принят стандарт DHCP Relay Agent - RFC3046, и в следующей версии, наверное, будет DHCP Relay Agent вместо Relay Agent BOOTP. В старой версии (RFC0951) Relay Agent назывался BOOTP forwarding agents.

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

    12.2 Протокол BOOTP.

    Создан для загрузки бездисковых машин.

    Стандарт BOOTP - RFC0951 (Bootstrap Protocol W.J. Croft, J. Gilmore Sep-01-1985).

    Последняя версия дополнений для BOOTP - RFC1542 (Clarifications and Extensions for the Bootstrap Protocol W. Wimer October 1993). Введено понятие Relay Agent.

    Первая версия расширения разработчиков (поле vend) для BOOTP - RFC1048 (BOOTP vendor information extensions P.A. Prindeville Feb-01-1988).

    Последняя версия расширения разработчиков (поле vend) для BOOTP - RFC2132 (DHCP Options and BOOTP Vendor Extensions S. Alexander, R. Droms March 1997).

    BOOTP является прототипом DHCP, в DHCP есть все что было в BOOTP.

    Поэтому BOOTP подробно рассматривать не будем.

    12.3 Протокол DHCP.

    Первый стандарт DHCP - RFC1531 (Dynamic Host Configuration Protocol R. Droms October 1993).

    Последняя версия DHCP - RFC2131 (Dynamic Host Configuration Protocol R. Droms March 1997).

    Последняя DHCP версия для IPv6 - RFC3315 (Dynamic Host Configuration Protocol for IPv6 (DHCPv6) R. Droms, Ed., J. Bound, B. Volz, T. Lemon, C. Perkins, M. Carney July 2003).

    Последняя версия дополнительных параметров (поле OPTIONS) для DHCP - RFC2132 (DHCP Options and BOOTP Vendor Extensions S. Alexander, R. Droms March 1997).

    Формат DHCP-пакета. Слова по 32 бита.


    12.4 Механизм динамического выделения адресов.

    Клиент посылается широковещательный (BROADCAST-255.255.255.255) запрос DHCPDISCOVER всем серверам DHCP.

    Все активные серверы посылают широковещательный ответ DHCPOFFER. Клиент принимает все ответы, инициализацию делает по адресу канального уровня (MAC-адрес для Ethrnet).

    Клиент выбирает один из предложенных адресов и посылает широковещательно DHCPREQUEST, которое должно содержать параметр Server Identifier (поле OPTIONS), чтобы указать, какой сервер им выбран.

    Сервер посылает широковещательно DHCPACK.

    Клиент может работать.

    Пример динамического выделения адреса (пошагово 1,2,3,4)

    • Запрашивающее параметры от одного сервера и неявно отвергающее предложения других серверов
    • Подтверждающее корректность ранее присвоенного адреса (например, после перезагрузки).
    • Запрос на продления времени жизни.

    12.4.1 Механизм повторного использования ранее выделеного адреса (RENEWING или Rebinding).

    Если клиент сохранил и желает использовать выделенный ранее IP-адрес, он может опустить некоторые шаги алгоритма.

    Алгоритм повторного получения:

    Клиент посылает DHCPREQUEST.

    Сервер, который узнает конфигурационные параметры клиента, посылает DHCPACK.

    Клиент может работать.

    12.5 База записей DHCP.

    Пример файла (dhcpd.leases) содержащего базу выданных IP-адресов. Приведено только две записи.


    lease 194.85.241.234 // Выданный IP-адрес
    starts 1 2003/11/17 11:42:13; // Время выдачи
    ends 1 2003/11/17 17:42:13; // Время истечения срока аренды
    binding state active; // Состояние сопряжения активно (время не истекло)
    next binding state free; // Следующее состояние сопряжения свободно (после истечения времени)
    hardware ethernet 00:50:22:bb:c0:0d; // etherne

    Читайте также: