Протокол динамической конфигурации ЭВМ DHCP
1. Введение
Протокол динамической конфигурации ЭВМ DHCP (Dynamic Host Configuration Protocol, RFC-2131, -2132, -2485, -2563, -2610, -2855, -2937, -2939, -3004, -3011, -3046; [22], [23], [24] и [25]) служит для предоставления конфигурационных параметров ЭВМ, подключенных к Интернет. DHCP имеет два компонента: протокол предоставления специфических для ЭВМ конфигурационных параметров со стороны DHCP-сервера и механизм предоставления ЭВМ сетевых адресов.
Протокол DHCP используется, помимо загрузки бездисковых станций или Х-терминалов (BOOTP), сервис-провайдерами для пулов модемов, когда число одновременно занятых модемов существенно меньше их полного числа. Это позволяет сэкономить заметное число IP-адресов. Протокол эффективен для случая распределения адресов за Firewall, где ЭВМ в защищенной зоне все равно бессмысленно выделять реальные IP-адреса.
DHCP построен по схеме клиент-сервер, где DHCP-сервер выделяет сетевые адреса и доставляет конфигурационные параметры динамически конфигурируемым ЭВМ.
ЭВМ не должна действовать как DHCP-сервер, если только она специально не сконфигурирована системным администратором. IP-протокол требует установки многих параметров. Так как IP-протокол может быть использован самым разным сетевым оборудованием, значения этих параметров не могут быть угаданы заранее. Кроме того, схема распределенного присвоения адресов зависит от механизма выявления уже используемых адресов. ЭВМ могут не всегда корректно зарезервировать свои сетевые адреса, таким образом, схема распределенного выделения адресов не может гарантировать уникальности сетевых адресов.
DHCP поддерживает три механизма выделения IP-адресов. При "автоматическом выделении", DHCP присваивает клиенту постоянный IP-адрес. При "динамическом присвоении", DHCP присваивает клиенту IP-адрес на ограниченное время. При "ручном выделении", IP-адрес выделяется клиенту сетевым администратором, а DHCP используется просто для передачи адреса клиенту. Конкретная сеть использует один или более этих механизмов, в зависимости от политики сетевого администратора.
Динамическое присвоение адресов представляет собой единственный механизм, который позволяет автоматически повторно использовать адрес, который не нужен клиенту. Таким образом,
динамическое присвоение адресов является оптимальной схемой для клиентов, подключаемых к сети временно, или совместно использующих один и тот же набор IP-адресов и не нуждающихся в постоянных адресах.
Формат сообщений DHCP базируется на формате сообщений BOOTP, чтобы можно было воспользоваться процедурами транспортировки данных, описанными в спецификации BOOTP [7, 21] и обеспечить совместимость DHCP-серверов с существующими клиентами BOOTP. Использование агентов транспортировки BOOTP исключает необходимость наличия DHCP-серверов в каждом физическом сегменте сети.
1.1. Сопряженные разработки
Существует несколько протоколов Интернет, которые так или иначе связаны с проблемой присвоения сетевых адресов. Протокол RARP (Reverse Address Resolution Protocol) [10] через расширения, описанные в DRARP (Dynamic RARP [5]), не только позволяет определить сетевой адрес, но и включает в себя автоматический механизм распределения IP-адресов. Протокол TFTP (Trivial File Transfer Protocol) [20] обеспечивает транспортировку загрузочного модуля от boot-сервера. Протокол ICMP (Internet Control Message Protocol) [16] с помощью сообщений "ICMP redirect" информирует ЭВМ о дополнительных маршрутизаторах. ICMP может также предоставить информацию о масках субсетей (сообщения "ICMP mask request"). ЭВМ могут найти маршрутизатор через ICMP-механизм поиска маршрутизаторов [8].
BOOTP является транспортным механизмом сбора конфигурационной информации. Протокол BOOTP является масштабируемым, определены стандартные расширения [17] для нескольких конфигурационных параметров. Морган предложил расширение BOOTP для динамического присвоения IP-адресов [15]. Протокол NIP (Network Information Protocol), использованный в проекте Athena МТИ, предоставляет распределенный динамический механизм выделения IP-адресов [19].
Протокол RLP (Resource Location Protocol [1]) служит для нахождения серверов, предоставляющих услуги верхнего уровня. Бездисковые рабочие станции компании Sun Microsystems используют процедуру загрузки, которая с привлечением механизма RARP, TFTP и RPC, называемого "bootparams", предоставляет бездисковой ЭВМ конфигурационную информацию и фрагменты операционной системы.
Существуют разработки, которые позволяют определить для заданного пути максимальный размер пакета (MTU) [14]. Существуют предложение по использованию протокола ARP (Address Resolution Protocol) для нахождения и выбора ресурсов [6]. Наконец, в RFC Host Requirements [3, 4] упоминаются специфические требования к конфигурированию ЭВМ, и предлагается сценарий инициализации бездисковых ЭВМ.
1.2. Постановка задачи
Протокол DHCP предназначен для предоставления клиентам DHCP конфигурационных параметров, описанных в RFC Host Requirements. После получения через DHCP необходимых параметров, клиент DHCP должен быть готов к обмену пакетами с любой другой ЭВМ в Интернет. Параметры стека TCP/IP, предоставляемые протоколом DHCP перечислены в приложении A. Не все эти параметры необходимы для первичной инициализации клиента. Клиент и сервер могут согласовывать список необходимых параметров.
Протокол DHCP позволяет, но не требует конфигурации параметров клиента, не имеющих прямого отношения к IP-протоколу. DHCP не обращается к системе DNS для регистрации адреса [12, 13]. DHCP не может использоваться для конфигурации маршрутизаторов.
1.3. Терминология
В данном документе применены следующие определения:
DHCP клиент |
Клиент DHCP является ЭВМ, подключенной к Интернет, которая использует DHCP, чтобы получить конфигурационные параметры, например сетевой адрес. |
DHCP сервер |
Сервер DHCP является ЭВМ, подключенной к Интернет, которая присылает клиенту DHCP параметры конфигурации. |
Агент пересылки BOOTP |
Агент пересылки BOOTP представляет собой ЭВМ, подключенную к Интернет, или маршрутизатор, который осуществляет связь между клиентом и сервером DHCP. DHCP спроектирован так, чтобы обеспечить совместимость со спецификациями протокола BOOTP. |
Binding |
Сопряжение (binding) представляет собой совокупность конфигурационных параметров, включая, как минимум, IP-адрес, присваиваемый DHCP-клиенту. Сопряжением управляют DHCP-серверы. |
<
1.4. Цели
Ниже предлагается список основных задач DHCP.
o |
DHCP представляет собой механизм, а не политику. DHCP должен управляться местными системными администраторами, путем задания желательных конфигурационных параметров. |
o |
Клиенты не должны требовать ручной конфигурации. Каждый клиент должен быть способен прочесть локальные конфигурационные параметры. |
o |
Сети не должны требовать ручной конфигурации для отдельных клиентов. В нормальных условиях, сетевой администратор не должен вводить какие-либо индивидуальные конфигурационные параметры клиента. |
o |
DHCP не требует отдельного сервера для каждой субсети. |
o |
Клиент DHCP должен быть готов получить несколько откликов на запрос конфигурационных параметров. Для повышения надежности и быстродействия можно использовать несколько DHCP-серверов, обслуживающих перекрывающиеся области сети. |
o |
DHCP должен сосуществовать с ЭВМ, которые сконфигурированы вручную. |
o |
DHCP должен быть совместим с логикой работы BOOTP-агента, описанной в RFC-951 и RFC-1542 [21]. |
o |
DHCP должен обслуживать существующих клиентов BOOTP. |
DHCP должен:
o |
Гарантировать, что любой специфический сетевой адрес не будет использоваться более чем одним клиентом DHCP одновременно. |
o |
Поддерживать DHCP конфигурацию клиента при стартовой перезагрузке DHCP-клиента. Клиенту DHCP должен, при каждом запросе по мере возможности, присваиваться один и тот же набор конфигурационных параметров (например, сетевой адрес). |
o |
Поддерживать конфигурацию DHCP-клиента при перезагрузке сервера, и, по мере возможности, DHCP-клиенту должен присваиваться один и тот же набор конфигурационных параметров. |
o |
Позволяет автоматически присваивать конфигурационные параметры новым клиентам, чтобы избежать ручной конфигурации. |
o |
Поддерживать фиксированное или постоянное присвоение конфигурационных параметров для заданного клиента. |
2. Краткий обзор протокола
С точки зрения клиента, DHCP является расширением механизма BOOTP. Такая схема позволяет существующим BOOTP-клиентам успешно сотрудничать с DHCP-серверами без необходимости изменения стартовой программы клиента.
В RFC-1542 [2] детализировано взаимодействие между BOOTP- и DHCP-клиентами и серверами [9]. Имеется несколько новых, опционных операций, которые оптимизируют взаимодействие между DHCP-клиентами и серверами (смотри разделы 3 и 4).
На Рисунок .1 представлен формат сообщения DHCP, а в таблице 1 перечислены поля этого сообщения. Числа в скобках указывают размер каждого из полей в октетах.
Существует два принципиальных отличия между DHCP и BOOTP. Во-первых, DHCP определяет механизмы, через которые клиентам на определенное время могут быть присвоены сетевые адреса, позволяя последовательное присвоение сетевого адреса различным клиентам. Во-вторых, DHCP предоставляет механизм, который позволяет клиенту получить все необходимые им для работы конфигурационные параметры.
DHCP вводит небольшое изменение в терминологию, имеющее целью прояснить значение одного из полей. Поле "vendor extensions" в BOOTP переименовано в поле "опции" в DHCP. Аналогично, помеченные информационные элементы, использованные в поле BOOTP "vendor extensions", которые именовались как "расширения производителя", теперь называются просто "опции".
0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 |
op (1) |
htype (1) |
hlen (1) |
Шаги (1) |
xid (4) |
secs (2) |
Флаги (2) |
ciaddr (4) |
yiaddr (4) |
siaddr (4) |
chaddr (4) |
chaddr (16)
|
sname (64)
|
Файл (128)
|
Опции (длина переменная) |
Содержание раздела