TCP/IP Архитектура, протоколы, реализация (включая IP версии 6 и IP Security) - читать бесплатно онлайн полную версию книги автора Сидни М. Фейт (Глава 11 Конфигурация с помощью BOOTP и DHCP) #15

Глава 11 Конфигурация с помощью BOOTP и DHCP

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) выглядел следующим образом:

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

■ Сервер возвращает клиенту его IP-адрес и, при необходимости, местоположение файла загрузки.

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

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

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

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

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

11.6 Эволюция BOOTP

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

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

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

■ Клиент может не загружать программное обеспечение, загрузить его по умолчанию или загрузить определенный файл.

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

Список дополнительных параметров постоянно увеличивался (полный список параметров BOOTP на момент выхода книги приведен в таблице 11.1), и скоро даже их часть уже не могла разместиться в сообщении UDP реалистичного размера. Для решения этой проблемы избыточные значения поместили в конфигурационном файле, который должен загружаться клиентом через TFTP. Идентификатор этого файла находится в основном сообщении UDP.

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

Конфигурационные параметры IP
Subnet mask (маска подсети)
Time Offset Difference (различия в смещениях времени)	Разность в секундах между местным и универсальным временем (Coordinated Universal Time — UTC)
Client Host Name (имя хоста клиента)	С использованием или без применения локального имени домена
Domain Name (имя домена)	Используется для разрешения имен хостов
Enable/Disable IP Forwarding (разрешение/запрещение перенаправления в IP)	Указывает на маршрутизацию системой датаграмм
Enable/Disable Non-Local Source Routing (разрешение/запрещение нелокальной маршрутизации от источника)	Указывает на перенаправление датаграмм с маршрутизацией от источника
Policy Filter (фильтр политики безопасности)	Список IP-адресов и масок подсети для фильтрации маршрутов, поступающих от источника
Maximum Datagram Reassembly Size (максимальный размер перепостроения датаграмм)	Максимальный размер датаграммы, которую клиент должен подготовить для повторного создания
Default IP Time-to-Live (время жизни по умолчанию для IP)	Начальное значение для поля TTL
Списки IP-адресов
Routers (маршрутизаторы)
Time Servers (серверы времени)
IEN 116 Name Servers (серверы имен по спецификации IEN 116)	(Устарело)
Domain Name Servers (серверы имен доменов)
Log Servers (серверы регистрации)
Cookie Servers (серверы цитат)	Ежедневно обновляемые цитаты от сервера Fortune Cookie.
LPR Servers (серверы построчной печати)	Серверы построчных принтеров
Imagen Impress Print Servers (серверы литерной печати)
Resource Location Servers (серверы размещения ресурсов)	Серверы по спецификации RFC 887
Различные параметры
Boot File Size (размер файла загрузки)	Размер файла загрузки в 512-октетных блоках
Dump File (файл дампа)	Путь к файлу дампа образа ядра операционной системы, создаваемого при крахе клиента
Swap Server (сервер свопинга)	IP-адрес сервера для свопинга диска
Root Path (корневой путь)	Путь к корневому диску клиента
Extensions Path (расширенный путь)	Путь к файлу с загружаемыми через TFTP конфигурационными параметрами
Параметры Maximum Transmission Unit (MTU)
Path MTU Aging Timeout (тайм-аут по возрасту пути MTU)	Тайм-аут для возобновления исследования пути MTU
Path MTU Plateau Table (стабилизационная таблица значений для пути MTU)	Серия значений для размера MTU, используемая в исследовании пути MTU, когда маршрутизатор не может предоставить в сообщении ICMP допустимое значение
Параметры IP для интерфейса
Interface MTU (интерфейс MTU)	Наибольший размер датаграммы, способной пройти через интерфейс
All Subnets Are Local (все подсети локальные)	Указывает, поддерживается ли всеми подсетями тот же самый MTU, что и для локальной подсети
Broadcast Address for the Interface (широковещательный адрес интерфейса)
Perform Mask Discovery (выполнение поиска маски)	Указывает на использование клиентом ICMP для получения маски подсети
Mask Supplier (система, предоставляющая маску)	Указывает, должен ли клиент отвечать на запросы ICMP при исследовании маски подсети
Perform Router Discovery (выполнение поиска маршрутизаторов)	Указывает на использование клиентом процедуры Router Discovery
Router Solicitation Address (адрес для ходатайства к маршрутизатору)	Адрес, на который клиент должен пересылать запросы ходатайства к маршрутизатору)
Static Routes (статические маршруты)	Список статических маршрутов (пары назначение/маршрутизатор) для таблицы маршрутизации клиента
Параметры уровня связи данных для интерфейса
Trailer Encapsulation (инкапсуляция заключительной части)	Применяется при согласовании (уже устарело) заключительных частей сообщений ARP
ARP Cache Timeout (тайм-аут кеша ARP)	Тайм-аут для обновления таблицы ARP
Ethernet Encapsulation (инкапсуляция Ethernet)	Ethernet версии 2 (DIX) или IEEE 802.3
Параметры TCP
TCP Default TTL (значение времени жизни по умолчанию для TCP)	Время жизни (Time-To-Live) для пересылки сегментов TCP
TCP Keep-Alive Interval (интервал поддержания сеанса TCP)	Тайм-аут для проверки сообщениями Keep-Alive внешне неактивных сеансов TCP. 0 означает отмену отправки таких сообщений, пока это не будет затребовано приложением.
Send TCP Keep-Alive Garbage Octet (отправка случайного октета при поддержании сеанса TCP)	Включает в сообщения Keep-Alive ненужный октет
Параметры приложений и служб
NIS Domain (домен сетевой информационной службы)	Имя домена Network Information Service (когда запущена служба базы данных NIS)
Network Information Server (NIS) Addresses (адреса NIS)
Network Time Protocol Server Addresses (адреса сервера для протокола сетевого времени)
Vendor Specific Information (область для "разработчиков)	Разработчик указывается через идентификатор класса
List of NetBIOS over TCP/IP Name Servers (список имен серверов NetBIOS, работающих поверх TCP/IP)
NetBIOS over TCP/IP Datagram Distribution Server (серверы распространения данных NetBIOS датаграммами TCP/IP)
NetBIOS over TCP/IP Node Type (тип узла, работающего в режиме NetBIOS поверх TCP/IP)
NetBIOS over TCP/IP Scope (уровень вложенности режима NetBIOS поверх TCP/IP)
X Window System Font Server (сервер системных шрифтов для X Window)	Список IP-адресов
X Window System Display Managers (диспетчер монитора системы X Window)	Список IP-адресов

11.7 Протокол BOOTP

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

■ Клиент отсылает сообщение запроса на загрузку (bootrequest) из порта 68 на порт 67 сервера.

■ Сервер реагирует на это сообщением ответа на загрузку (bootreply), отсылая его на порт 68 клиента.

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

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

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

Рис. 11.4. Формат запроса и ответа сообщения загрузки

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

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

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

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

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

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

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

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

Промежуточный агент (relay agent) помогает системе отправить локальный запрос BOOTP на удаленный сервер. В качестве промежуточных агентов используются маршрутизаторы (хотя стандарты позволяют работать в этом режиме и хостам).

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

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

■ Затем агент пересылает запрос клиента на один или несколько предварительно указанных адресов серверов.

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-адреса:

■ Клиент отправляет в широковещательной рассылке запрос (на порт 67 сервера).

■ Сервер получает этот запрос.

■ По типу оборудования и аппаратному адресу клиента сервер выбирает в таблице IP-адрес.

■ Если клиент расположен локально, сервер отправляет ответ в широковещательной рассылке (на порт 68 клиента).

■ Если клиент удален от сервера, ответ посылается на порт 67 по адресу, указанному в поле 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

Клиент BOOTP посылает соответствующее короткое имя на сервер в поле имени загружаемого файла (вместо этого в DHCP используется отдельное поле идентификатора класса). По короткому имени сервер выбирает из таблицы нужные, сведения и помещает полный путь к файлу в поле имени загружаемого файла, а IP-адрес сервера TFTP записывает в поле "IP-адрес сервера" сообщения.

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

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

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

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

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

■ Применение заголовка IP с новым IP-адресом в качестве адреса назначения

■ Заключение датаграммы в кадр, адресованный на физический адрес клиента

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

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

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

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

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

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

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

■ Упрощение администрирования

■ Автоматизация конфигурирования

■ Поддержка перемещений или изменений сети

■ Возможность запроса клиентом значений определенных параметров

■ Новые типы сообщений DHCP, обеспечивающие более надежное соединение между клиентом и сервером

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

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

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

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

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

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

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

11.9 Механизмы DHCP

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

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

■ Ручное, когда IP-адрес вводится на сервере и назначается клиенту постоянно

■ Автоматическое, когда IP-адрес выбирается сервером из пула доступных адресов и назначается клиенту постоянно

■ Динамическое, когда IP-адрес присваивается клиенту на ограниченный срок или до завершения его использования данным клиентом

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

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

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

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

11.9.3 Связывание

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

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

Для обеспечения совместимости с BOOTP формат сообщений DHCP идентичен сообщениям BOOTP. В результате:

■ Клиент BOOTP может обращаться к серверу DHCP

■ Клиент DHCP может использовать службу промежуточных агентов BOOTP

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

■ Поле для параметра DHCP Class Identifier (идентификатор класса DHCP). Этот параметр клиент отправляет серверу с целью использования в качестве ключа при поиске специфичных для клиента конфигурационных сведений.

■ Клиент идентифицируется арендой и связыванием (с набором конфигурационных параметров), а не типом оборудования и аппаратным адресом.

■ Введен параметр для указания максимального размера сообщения, которое может получить клиент от сервера.

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

11.10.1 Типы сообщений

Тип сообщения DHCP определяется полем DHCP Message Type (тип сообщения DHCP). Пользоваться этим может только клиент DHCP, но не клиент BOOTP. Имеются следующие типы сообщений:

DHCPDISCOVER	Клиент посылает сообщение для поиска серверов.
DHCPOFFER	Сервер отвечает клиенту и предоставляет ему IP-адрес и конфигурационные параметры.
DHCPREQUEST	Клиент выбирает один из серверов и посылает запрос. При необходимости можно запросить у сервера дополнительные параметры.
DHCPACK	Сервер отвечает и предоставляет дополнительные параметры, если они были запрошены.
DHCPNAK	Сервер отменяет запрос (например, клиент мог запросить уже используемый IP-адрес). Клиент должен возобновить процесс загрузки с самого начала.
DHCPDECLINE	Клиент отменяет принятые конфигурационные параметры, поскольку один из них был некорректным.
DHCPRELEASE	Клиенту более не нужен IP-адрес, и поэтому он освобождает его.

11.10.2 Типичный начальный обмен сообщениями между клиентом и сервером

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

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

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

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

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

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

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

■ Предварительно сконфигурированный клиент может посылать DHCPREQUEST с указанием в нем своего IP-адреса.

■ Сервер (или серверы), хранящий конфигурацию клиента, отвечает сообщением DHCPACK (если все будет успешно).

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

■ Клиент должен снова начать конфигурирование, если в сообщении DHCPNAK информация от сервера некорректна.

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

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

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

Дополнительные параметры только для DHCP
Requested IP Address (запрошенный IP-адрес)	Клиент запросил выделение определенного IP-адреса.
IP Address Lease Time (время аренды IP-адреса)	В запросе клиент указывает необходимое время аренды адреса, реальное значение которого содержится в ответе сервера.
Option Overload (дополнительная нагрузка)	Указывает, что в сообщении, кроме стандартных значений, находятся поля сервера имен хостов DHCP или имя файла загрузки.
DHCP Message Type (тип сообщения DHCP)	Например, DISCOVER, OFFER или REQUEST.
Server Identifier (идентификатор сервера)	Используется для разделения серверов, чтобы клиент мог выяснить, от какого из них используется аренда.
Parameter Request List (список запрашиваемых параметров)	Список необязательных кодов, разрешающих клиенту запрос значений определенных параметров.
Message (сообщение)	Используется как сообщение об ошибке в ответе сервера (например, о недоступности IP-адресов). Клиент может применить его для указания причины отклонения предложенного ему набора параметров.
Maximum DHCP Message Size (максимальный размер сообщения DHCP)	Максимальный размер сообщения DHCP, которое желает получать клиент.
Renewal (T1) Time Value (значение времени восстановления)	Интервал времени от назначения адреса клиенту до попытки взаимодействия клиента с сервером для продления аренды IP-адреса.
Rebinding (T2 > T1) Time Value (значение времени повторного связывания)	Интервал времени от назначения адреса клиенту до попытки продления аренды IP-адреса у любого из серверов, если клиент не может получить ответ от исходного сервера.
Class Identifier (идентификатор класса)	Локально назначенный идентификатор, используемый клиентом для определения своего типа и конфигурации. Некоторые параметры могут быть возвращены на основе указанного класса.
Client Identifier (идентификатор клиента)	Уникальный идентификатор для клиента, включенный в сообщение DHCPDISCOVER. Идентификатором может быть имя DNS или другой присвоенный клиенту идентификатор. Используется для связи клиента с данными о его аренде IP-адреса.

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

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

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

Было предпринято несколько других попыток автоматизировать отдельные части процесса конфигурирования. Подключенные к локальной сети системы могут использовать обратные ARP (RARP), чтобы обнаружить свой IP-адрес. Запрос ICMP Address Mask (маска адреса ICMP) и ответ на него обеспечивают получение маски подсети. Но нет никакого смысла применять несколько отдельных протоколов и сообщений для получения сведений, предоставляемых в одном ответе BOOTP или DHCP.

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