RFC-2131. Протокол динамической настройки сетевых устройств (компьютеров) (DHCPv4). Март 1997 года (категория: стандарт)

Подождите немного. Документ загружается.

RFC-2131 март 1997 года

категория: стандарт

(

)

I. ВВЕДЕНИЕ

Протокол динамической настройки сетевых устройств (компьютеров)

(Dynamic Host Configuration Protocol — DHCPv4-протокол) обеспечивает уста-

новку и корректировку параметров сетевых устройств в Internet-сети. Данный

протокол состоит из двух частей:

c собственно протокол доставки параметров настройки специализирован-

ный сетевых устройств;

d описание способа размещения сетевых IPv4-адресов в сетевых устройст-

вах.

В основе DHCP-протокола лежит известная модель взаимодействия “кли-

ент-сервер”, в которой выделенный DHCP-сервер размещает IPv4-адреса в ди-

намически настраиваемых сетевых устройствах, а также доставляет им соответ-

ствующие параметры настройки. В этом стандарте термин “сервер” означает

лишь только то, что одно сетевое

устройство обеспечивает установку парамет-

ров с помощью DHCP-протокола, а термин “клиент” означает лишь только то,

что другое сетевое устройство запрашивает у DHCP-сервера установку пара-

метров.

Целесообразно, чтобы какое-либо сетевое устройство “самостоятельно не

выступало в роли” DHCP-сервера до тех пор, пока оно не будет в явной форме

назначено (определено) и

настроено системным администратором для реализа-

ции такой функции. Многообразие программно-аппаратных комплексов (ПАК)

и прикладных систем в Internet-сети могло бы нарушить их реальной функцио-

нирования, если бы произвольным сетевым устройствам не было разрешено от-

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

протокол (IP-модуль), запрашивает установку нескольких параметров. И по-

этому IP-модуль

может быть использован в различных типах ПАК, значения

параметров которых не могут быть оценены даже приблизительно или произ-

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

мы назначения и распределения IP-адресов зависят от способов опроса и обес-

печения безопасности при определении уже используемых адресов. IP-узлы не

всегда

способны “защитить себя” от используемых сетевых адресов, и поэтому

такая схема назначения IP-адресов не может гарантировать исключение дубли-

рования сетевых адресов при их распределении.

DHCP-протокол обеспечивает три способа назначения IP-адресов:

n “автоматическое назначение”, при котором DHCP-протокол назначает

постоянный IP-адрес клиенту;

o “динамическое назначение”, при котором DHCP-протокол назначает IP-

адрес клиенту на ограниченный интервал времени (или до тех пор, пока

клиент в явной форме отказывается от адреса);

p “ручное назначение”, при котором IP-адрес клиента назначается сетевым

администратором, а DHCP-протокол используется просто для доставки

выделенного адреса клиенту.

В конкретной сети может использоваться один или более указанных спо-

собов в зависимости от стратегии безопасности администратора сети.

Динамическое назначение является только одним из существующих спо-

собов, автоматически позволяющим повторное использование адреса,

который

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

ческое назначение является наиболее практичным при назначении адреса кли-

енту, который будет только временно соединяться с сетью или при коллектив-

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

тов, которым не нужны постоянные IP-адреса. Динамическое назначение может

быть вполне приемлемым

для назначения IP-адресов для новых клиентов,

имеющих постоянные соединения с сетью, в которой IP-адреса являются весь-

ма дефицитными, и в которой весьма важно их восстанавливать при “отключе-

нии старых” клиентов.

Ручное назначение позволяет применять DHCP-протокол для снижения

числа ошибочных процессов в настраиваемых вручную сетевых устройствах с

IP-адресами, причём в тех

областях, в которых (по каким-либо причинам) же-

лательно управлять IP-адресом, не используя способы, предусмотренные

DHCP-протоколом.

§1.1. “Родственные” протоколы

В Internet-сети существует несколько протоколов и “родственных” спосо-

бов, которые решают некоторые вопросы динамической настройки сетевых

устройств. Протокол Reverse Address Resolution Protocol (RARP, RFC-903) и его

усовершенствованная версия Dynamic RARP (DRARP) однозначно решают

проблему нахождения сетевого адреса на основе способа автоматического на-

значения IP-адреса. Протокол Trivial File Transfer Protocol (TFTP, RFC-783)

обеспечивает доставку копии загрузочного программного обеспечения (ПО) из

сервера загрузки ПО. Протокол Internet Control Message Protocol (ICMP, RFC-

792) способен

“информировать” сетевые устройства о дополнительных мар-

шрутизаторах и масках подсетей, используя для этого ICMP-пакеты о перена-

правлении трафика “ICMP redirect” и масках подсетей “ICMP mask request”. Се-

тевые устройства могут определять местонахождение маршрутизаторов с по-

мощью ICMP-протокола, используя процедуру поиска маршрутизатора (ICMP

router discovery).

Протокол начальной загрузки (протокол Bootstrap — BOOTP, RFC-951,

RFC-1048, RFC-1532) представляет собой способ доставки совокупности дан-

ных настройки. BOOTP-протокол является расширяемым протоколом, и на него

была возложена настройка нескольких дополнительных параметров (RFC-

1497). В частности, BOOTP-протокол способен осуществлять назначение IP-

адресов в локальной Ethernet-сети.

Подобно ему, протокол сетевой информации

(Network Information Protocol — NIP), используемый в проекте “Athena” Масса-

чусетским технологическим институтом (США), представляет собой распреде-

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

вого ресурса (Resource Location Protocol — RLP, RFC-887) обеспечивает поиск

прикладных служб, на вышележащих уровнях. Бездисковые рабочие станции

компании “Sun Microsystems” используют процедуру загрузки (“boot”), кото-

рую выполняют протоколы RARP, TFTP и RPC, называемую “bootparams” и

предназначенную для доставки

параметрических данных и кода операционной

системы (ОС) в бездисковые сетевые устройства. Некоторые сети компании

“Sun Microsystems” (Sun-сети) также используют DRARP-протокол и алгоритм

автоматической инсталляции для автоматической настройки новых сетевых

устройств в существующей сети.

Другой близкой работой является алгоритм поиска промежуточного ин-

тервала маршрута передачи IP-пакета, на котором транслируются сообщения

самой минимальной длины

(Minimum Transmission Unit — MTU, RFC 1191).

Протокол назначения адресов (Address Resolution Protocol — ARP, RFC-826)

используется в качестве транспортного средства при поиске и выборе сетевых

ресурсов. И в заключение этого параграфа, Требования к ГВМ (Host Require-

ments), изложенные в RFC-1122 и RFC-1123, представляют собой специфиче-

ские требования для перенастройки сетевых устройств и описывают возмож-

ный сценарий для начальной настройки бездисковых сетевых устройств.

§1.2. Описание проблемы и противоречия

DHCP-протокол разработан для обслуживания DHCP-клиентов с целью

настройки соответствующих параметров, определенных в RFC-1122 и RFC-

1123. После получения параметров, DHCP-клиент должен обменяться IP-

пакетами с любым другим сетевым устройством в Internet-сети. Параметры

Internet-архитектуры, которые поддерживаются DHCP-протоколом, представ-

лены в Приложении А.

Не все из этих параметров необходимы для вновь инициализируемого

клиента. Клиент и

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

параметры, которые востребованы клиентом или являются специфическими для

конкретной подсети.

DHCP-протокол позволяет, но не требует настройки клиентских парамет-

ров, которые напрямую не связаны с IP-протоколом. Кроме этого, DHCP-

протокол не обеспечивает регистрацию вновь настраиваемых клиентов в DNS-

системе.

§1.3. Терминология

В этом стандарте используются следующие термины:

c DHCP-клиент (DHCP client) — сетевое устройство (ГВМ, РС) в Internet-

сети, использующее DHCP-протокол для получения параметров настрой-

ки, например, сетевой адрес;

d DHCP-сервер (DHCP server) — сетевое устройство (ГВМ) в Internet-сети,

использующее DHCP-протокол для доставки DHCP-клиентам параметров

настройки;

e BOOTP-агент/ретранслятор (BOOTP relay agent) — (или просто агент-

ретранслятор) сетевое устройство (ГВМ, маршрутизатор), которое

ретранслирует DHCP-сообщения между DHCP-клиентами и DHCP-

серверами. DHCP-протокол использует только один и тот же режим

функционирования агента-ретранслятора, который представлен в проце-

дурной характеристике BOOTP-протокола;

f совокупность (группа) параметров настройки (binding) — набор техноло-

гических параметров, включая как минимум IP-адрес, или “ограничений”,

относящихся к DHCP-клиенту. Группы параметров настроек обеспечива-

ются и регулируются DHCP-серверами.

§1.4. Цели стандарта

Стандарт DHCP-протокол преследует следующие общие цели:

n DHCP-протокол представляет собой способ, а не стратегию. DHCP-

протокол должен предоставлять администраторам ЛВС возможность

управлять параметрами настройки там, где это необходимо (например,

администраторы ЛВС должны иметь способность “воплощать в жизнь”

локальные стратегии размещения локальных ресурсов и доступа к ним,

особенно там, где это необходимо);

o клиенты не должны требовать ручной настойки. Каждый DHCP-клиент

должен иметь способность отыскать соответствующие параметры на-

стройки без участия и вмешательства пользователя в эти параметры, пу-

тём проведения “собственной настойки”;

p сети не должны требовать ручной настойки индивидуальных клиентов.

При штатных условиях функционирования сети её менеджер не должен

настраивать параметры персонально у каждого клиента;

q DHCP-протокол не должен требовать наличия DHCP-сервера в каждой

подсети. В целях обеспечения эффективного режима функционирования

DHCP-протокол должен работать с использованием маршрутизаторов и с

участием BOOTP-агентов/ретрансляторов;

r DHCP-клиент должен настраиваться путём получения нескольких ответ-

ных сообщений на его запрос о параметрах настройки. Некоторые систе-

мы могут включать несколько взаимно перекрывающихся DHCP-

серверов с целью повышения надёжности и эффективности;

s DHCP-протокол должен “сосуществовать” вместе со статически настраи-

ваемыми сетевыми устройствами, которые “не реагируют” на DHCP-

сообщения, и существующими программными модулями, реализующими

сетевые протоколы;

t DHCP-протокол должен быть функционально совместим с процедурной

характеристикой BOOTP-агента/ретранслятора, представленной в стан-

дартах RFC-951 и RFC-1542;

u DHCP-протокол должен обслуживать существующих BOOTP-клиентов.

В целях обеспечения передачи параметров сетевого уровня DHCP-

протокол должен:

c гарантировать, что в любой, случайным образом выбранный момент

времени какой бы то ни было специфический сетевой адрес не будет ис-

пользоваться более чем одним DHCP-клиентом;

d помнить настройки DHCP-клиента, после его перезагрузки. DHCP-

клиенту должны, насколько это возможно, передаваться одни и те же

параметры настройки (например, сетевой адрес), причём в ответе на ка-

ждый запрос;

e помнить настройки DHCP-клиента, после перезагрузки DHCP-сервера,

и, насколько это возможно, DHCP-клиенту должны передаваться одни и

те же параметры настройки, несмотря на повторный запуск процедур

самого DHCP-протокола;

f разрешать автоматические процедуры назначения параметров настройки

для новых клиентов с целью запрета их ручной настройки;

g обеспечивать установленный или постоянный поиск параметров настой-

ки для определённых клиентов.

II. ОБЩАЯ ХАРАКТЕРИСТИКА ПРОТОКОЛА

С точки зрения клиента, DHCP-протокол представляет собой функцио-

нальное расширение BOOTP-протокола. Он позволяет существующим BOOTP-

клиентам взаимодействовать с DHCP-серверами, причём без какого-либо пред-

варительного информационного обмена с целью установки необходимого на-

чального ПО в компьютере клиента. Стандарт RFC-1542 детализирует проце-

дурную характеристику взаимодействия BOOTP-клиентов с DHCP-клиентами и

DHCP-серверами. В настоящем стандарте представлено несколько новых до-

полнительных процедур, которые оптимизируют взаимодействие DHCP-

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

На рис.1

представлен формат DHCP-сообщения, поля которого имеют

следующее кодирование и назначение:

0 7 8 15 16 23 24 31

Тип сообщения

Тип адреса

устройства

Длина адреса

устройства

Число

ретрансляционных

участков

Идентификатор процедуры информационного обмена

Время начала процедуры (сек.) Флаги

IP-адрес клиента

«Ваш» (клиента) IP-адрес

IP-адрес следующего сервера

IP-адрес агента/ретранслятора

Адрес устройства клиента (16 октетов)

Дополнительное имя устройства, со встроенным сервером

(64 октета)

Имя файла загрузки

(128 октетов)

Дополнительные параметры (переменная длина)

Рис.1. Формат DHCP-сообщения

0 1 15

Бит

широковещательного

режима

0…0

Рис.2. Формат поля “Флаги” DHCP-сообщения

 “Тип сообщения” (op) — 1 октет, определяет тип DHCP-сообщения (“1”

— BOOTREQUEST, запрос; “2” — BOOTREPLY, ответ на запрос);

 “Тип адреса устройства” (htype) — 1 октет, определяет тип адреса сетево-

го устройства (RFC-1700, например, “1” — для 10 Мбит/сек Ethernet-

сети);

 “Длина адреса устройства” (hlen) — 1 октет, определяет длину адреса се-

тевого устройства (например, “6” — для 10 Мбит Ethernet-сети);

 “Число ретрансляционных участков” (hops) — 1 октет, клиент заполняет

это поле нулями, дополнительно используется агентами/ретрансляторами,

когда через них осуществляется загрузка параметров;

 “Идентификатор процедуры информационного обмена (DHCP-

процедуры)” (xid) — 4 октета, идентификатор транзакции — случайное

число, выбранное клиентом и используемое им и сервером для идентифи-

кации транслируемых между ними сообщений-запросов и ответов;

 “Время начала процедуры” (secs) — 2 октета, заполняется клиентом, чис-

ло секунд, которые прошли с момента, как клиент начал процедуру полу-

чения или обновления адреса;

 “Флаги” (flags) — 2 октета, кодирование поля представлено на рис.2;

 “IP-адрес клиента” (ciaddr) — 4 октета, IP-адрес клиента. Это поле запол-

няется только тогда, когда клиент находится в одном из следующих со-

стояний “BOUND”, “RENEW” или “REBINDING”, — и может отвечать

на ARP-запросы;

 “«Ваш» (клиента) IP-адрес” (yiaddr) — 4 октета, содержит назначенный

IP-адрес клиента;

 “IP-адрес следующего сервера” (siaddr) — 4 октета, содержит IP-адрес

следующего сервера при использовании Bootstrap-протокола, а также со-

держится в ответных DHCPOFFER- и DHCPACK-сообщениях сервера;

 “IP-адрес агента/ретранслятора” (giaddr) — 4 октета, IP-адрес аген-

та/ретранслятора, используется при загрузке параметров через аген-

та/ретранслятора;

 “Адрес устройства клиента” (chaddr) — 16 октетов, адрес сетевого уст-

ройства клиента;

 “Дополнительное имя устройства, со встроенным сервером” (sname) — 64

октета, дополнительное имя сетевого устройства, со встроенным серве-

ром (дополняется нулями до 32-битовой границы);

 “Имя файла загрузки” (file) — 128 октетов, имя загружаемого файла (до-

полняется нулями до 32-битовой границы). В DHCPDISCOVER-

сообщениях заполняется нулями или имеет значение “Generic”. В

DHCPOFFER-сообщениях полное конкретное наименование, содержа-

щееся в перечне имен для данного маршрута;

 “Дополнительные параметры” (options) — имеет переменную длину, со-

держит дополнительные параметры.

Между DHCP- и BOOTP-протоколами существуют два основных разли-

чия:

n во-первых, DHCP-протокол определяет способы, с помощью которых

клиенты могут получить сетевой адрес на ограниченный срок, что по-

зволяет последовательно переназначать сетевые адреса различным кли-

ентам;

o во-вторых, DHCP-протокол реализует способ, при котором клиент по-

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

стройки.

DHCP-протокол вносит небольшие изменения в терминологии, связанные

с однозначным толкованием одного из полей. Поле, именуемое в BOOTP-

сообщении как “Расширения вендора” (“Vendor extensions”), в DHCP-

сообщении называется “Дополнительные параметры”.

Кроме того, DHCP-протокол описывает новую дополнительную функцию

“Идентификатор клиента” (“Client identifier”), которая используется для пере-

дачи определённого идентификатора клиента на DHCP-сервер. Это изменение

исключает заполнение поле “Адрес устройства клиента” (“chaddr”) в BOOTP-

сообщениях, в которых это поле используется двояко: для передачи адреса се-

тевого устройства в ответных BOOTP-сообщениях или для передачи идентифи-

катора клиента. Идентификатор клиента представляет собой уникальный код,

который

никак не интерпретируется сервером: например, идентификатор кли-

ента может быть адресом сетевого устройства и совпадать с полем “Адрес уст-

ройства клиента” (“chaddr”), или может быть DNS-именем. Идентификатор

клиента, выбранный DHCP-клиентом должен быть уникальным для данного

клиента в пределах той подсети, к которой он присоединён. Если клиент ис-

пользует “идентификатора клиента” в одном

сообщении, то во всех последую-

щих сообщениях должен использоваться точно такой же идентификатор с це-

лью обеспечения гарантий того, что все серверы корректно идентифицируют

клиента.

Логическая характеристика DHCP-протокола уточняет назначение поля

“IP-адрес следующего сервера” (siaddr): адрес сервера, который будет исполь-

зоваться в следующей итерации процесса начальной загрузки клиента. DHCP-

сервер может передать

в ответном сообщении свой собственный адрес в поле

“IP-адрес следующего сервера” (siaddr), если сервер был предварительно на-

строен для взаимодействия с “соседней” службой начальной загрузки (напри-

мер, доставка загружаемой копии операционной системы). DHCP-сервер всегда

указывает свой собственный адрес в дополнительном параметре “Идентифика-

тор сервера” (“Server identifier”) ответного сообщения.

Поле “Дополнительные параметры” (options) имеет переменную

длину.

DHCP-клиент должен быть настроен для приёма DHCP-сообщений, в которых

поле “Дополнительные параметры” имеет длину по крайней мере 312 октетов.

Это требование означает, что DHCP-клиент должен быть настроен для приема

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

IP-дейтаграмм минимальной длины. DHCP-клиенты могут согласовывать при-

ем и обработку DHCP-сообщений и большей длины с использованием допол-

нительного параметра “

Максимальный размер DHCP-сообщения” (“Maximum

DHCP message size”). Поле “Дополнительные параметры” может расширяться и

больше, включая в себя поля “Дополнительное имя устройства, со встроенным

сервером” (sname) и “Имя файла загрузки” (file).

Если клиент использует DHCP-протокол для первоначальной настройки

(до тех пор, пока полностью не настроено программный модуль, реализующий

TCP/IP-протоколы, — TCP/IP-модуль), DHCP-протокол требует “вдумчивого”

использования TCP/IP-модуля и

всестороннего анализа стандарта RFC-1122.

Программный TCP/IP-модуль должен принимать и пересылать на IP-уровень

IP-пакеты, направляемые по адресу сетевого устройства клиента, причём еще

до того, как будет настроен IP-адрес. DHCP-серверы и BOOTP-

агенты/ретрансляторы не способны доставить DHCP-сообщения клиентам, у

которых сетевые устройства не могут воспринимать однонаправленные дейта-

граммы до настройки TCP/IP-модуля.

Для “работы”

с указанными выше клиентами DHCP-протокол использует

поле “Флаги” (flags). Самый крайний левый бит представляет собой широкове-

щательный (“Broadcast” или “В”) флаг (рис.2). Остальные биты зарезервирова-

ны для последующего использования, и поэтому они должны устанавливаться

клиентами в нулевые значения и игнорироваться серверами и агента-

ми/ретрансляторами.

§2.1. Репозитарий параметров настройки

Первой услугой, предоставляемой программным DHCP-модулем, являет-

ся постоянное хранение сетевых параметров в интересах сетевых клиентов.

DHCP-модель постоянного хранения заключается в том, что DHCP-служба

хранит запись с ключевыми значениями параметров для каждого клиента, в ко-

торой основным параметром является специфический уникальный идентифика-

тор (например, номер IP-подсети и уникальный идентификатор в рамках

этой

подсети), а также значения параметров настройки клиента.

Например, идентификатором может быть пара: номер IP-подсети и номер

сетевого устройства, — учитывающая последовательное или одновременное

повторное использование адреса сетевого устройства в различных подсетях,

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

уникальными. (

Замечание. Такой “адрес сетевого устройства” должен зависеть от

типа сетевого устройства в целях согласования возможного повторного исполь-

зования сетевых адресов, так как это может понадобиться в результате возникно-

вения проблем, связанных с порядком следования битов в составной физической

среде (радиоканалы, проводные и оптические каналы), образовавшейся при объ-

единении с помощью мостов нескольких разнородных подсетей в одну сеть.) С

другой стороны, идентификатором может быть пара: номер IP-подсети и имя

сетевого устройства, — учитывающая наличие сервера, предназначенного для

корректного назначения параметров DHCP-клиенту, который может переме-

щаться из одной подсети в другую или у которого может изменяться адрес се-

тевого устройства (последнее возможно при выходе из строя сетевого интер-

фейса или

его переустановке). Настоящий стандарт устанавливает, что иденти-

фикатором является пара: номер IP-подсети и номер сетевого устройства, — до

тех пора, пока клиент с помощью дополнительного параметра “идентификатор

клиента” не установит точное значение своего идентификатора. Клиент может

запросить DHCP-службу для корректировки своих параметров настройки.

Взаимодействие клиента с репозитарием параметров настройки включает за-

прос

параметров настройки и ответ сервера, содержащего значения таких пара-

метров.

§2.2. Динамическое назначение сетевых адресов

Второй услугой, предоставляемой программным DHCP-модулем, являет-

ся назначение временных или постоянных сетевых (IP) адресов клиентам. Ос-

новной способ динамического назначения сетевых адресов не сложен: клиент

запрашивает использование адреса в течение некоторого периода времени.

Способ назначения (совокупность DHCP-серверов) не гарантирует переназна-

чение тех адресов, которые были запрошены в течение определённого периода

времени,

а пытается назначить один и тот же адрес при каждом запросе клиента

на установку адреса. В данном стандарте период, в течение которого сетевой

адрес назначается клиенту, именуется как “срок аренды” (“lease”). Клиент мо-

жет продлить срок аренды с помощью последующих запросов. Клиент может

“вернуть” адрес обратно серверу после того, как необходимость

в адресе отпа-

ла. Клиент может запросить назначение постоянного адреса путём запроса не-

ограниченного срока аренды. Даже когда назначаются “постоянные” адреса,

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

чтобы иметь возможность выявлять случаи, когда клиент был отключён от се-

ти.

В некоторых сетях существует необходимость повторного назначения се

тевых адресов вследствие полного израсходования выделенного адресного про-

странства. В таких системах протокол назначения адресов будет повторно ис-

пользовать адреса, которые имеют ограниченные сроки аренды. Сервер должен

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