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

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

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

пользования.

III. ПРОЦЕДУРНАЯ ХАРАКТЕРИСТИКА

DHCP-ПРОТОКОЛА

DHCP-протокол использует формат BOOTP-сообщения, который пред-

ставлен на рис.1 и в стандарте RFC-951. Поле “Дополнительные параметры”

(options) в каждом DHCP-сообщении, передаваемом клиентом серверу, содер-

жит запрос “BOOTREQUEST”, а в ответном DHCP-сообщении, передаваемом

сервером клиенту — ответ “BOOTREPLY”.

Первые четыре октета поля “Дополнительные параметры” DHCP-

сообщения содержат десятичные числа 99, 130, 83 и 99, соответственно (это —

так называемая “магическая” метка,

описываемая в стандарте RFC-1497). Ос-

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

рые именуются как дополнительные параметры. Все дополнительные парамет-

ры вендоров, перечисленные в RFC-1497, также используются в DHCP-

сообщениях. В стандарте RFC-1533 представлены все возможные параметры,

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

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

, который

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

“Тип DHCP-сообщения” (“DHCP message type”). Дополнительные параметры

могут обязательными, востребованными или не обязательными в зависимости

от типа DHCP-сообщения.

§3.1. Процедура назначения сетевого адреса (клиент/сервер)

Эта процедура включает следующие итерации (рис.3):

n клиент в широковещательном режиме передаёт DHCPDISCOVER-

сообщение по своей локальной подсети. Это сообщение может включать

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

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

o каждый сервер может в ответ направить DHCPOFFER-сообщение, кото-

рое будет содержать приемлемый сетевой адрес в поле “«Ваш» (клиента)

IP-адрес” (yiaddr), а также другие параметры настройки. Серверам нет не-

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

что протокол функционировал бы эффективнее, если бы сервер запретил

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

Когда на-

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

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

жет отправить ICMP-запрос в режиме эхо-контроля. Серверы должны на-

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

ровать функцию тестирования вновь назначенных адресов. Сервер пере-

даёт ответное DHCPOFFER-сообщение, и если это необходимо “задейст-

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

Наименование

сообщения

Назначение

DHCPDISCOVER

Передаётся клиентом в широковещательном режиме по своей локальной под-

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

DHCPOFFER

Передаётся сервером в ответ на полученное DHCPDISCOVER-сообщение и

содержит предлагаемые параметры настройки.

DHCPREQUEST

Передаётся клиентом серверам, (а) либо для запроса предложенных одним из

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

ров, (б) либо для подтверждения корректности ранее назначенного адреса,

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

соответствующего сетевого адреса.

DHCPACK

Передаётся сервером и содержит параметры настройки, включая ранее пред-

ложенный сетевой адрес.

DHCPNAK

Передаётся сервером клиенту, указывая на то, что объявленный клиентом

сетевой адрес является корректным (например, при перемещении клиента в

другую (новую) подсеть), или, что срок аренды клиентом адреса истёк.

DHCPDECLINE

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

пользуется.

DHCPRELEASE

Передаётся клиентом серверу и указывает на то, что клиент отказывается от

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

DHCPINFORM

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

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

адрес из внешней сети.

Рис.3. Типы DHCP-сообщений

p клиент принимает одно или несколько DHCPOFFER-сообщений от одно-

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

скольких ответов. Клиент выбирает один сервер, который предложил

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

запроса этих предложенных параметров. Клиент передаёт DHCPRE-

QUEST-сообщение в широковещательном режиме, которое должно

включать дополнительный параметр “Идентификатор сервера” с

целью

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

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

ниями. В DHCPOFFER-сообщении сервера обязательно должен быть ука-

зан дополнительный параметр “Запрашиваемый IP-адрес” со значением в

поле “«Ваш» (клиента) IP-адрес” (yiaddr). Такое DHCPREQUEST-

сообщение является широковещательным и ретранслируется через

DHCP/BOOTP-агенты/ретрансляторы. С целью обеспечения гарантии

то-

го, что BOOTP-агенты/ретрансляторы перешлют DHCPREQUEST-

сообщение с такими же параметрами, какие были установлены DHCP-

серверами, получившими оригинальное DHCPDISCOVER-сообщение, в

заголовке DHCPREQUEST-сообщения должно быть продублировано по-

ле “Время начала процедуры” (secs), а также должен быть передан точно

такой же широковещательный IP-адрес, как и в оригинальном DHCPDIS-

COVER-сообщении. Клиент включает тайм-аут, и если по истечении ко-

торого не получит DHCPOFFER-сообщения, он повторно передаёт

DHCPDISCOVER-сообщение;

t tt

Завершение

срока аренды

DHCPRELEASE

Постепенное завершение аренды

Настройка завершена

DHCPASK

Фиксация

настроек

DHCPREQUEST DHCPREQUEST

Выбор

настроек

Приём ответов

DHCPOFFER

Определяет

настройки

Определяет

настройки

DHCPDISCOVER DHCPDISCOVER

Инициализирует

соединение

Рис.4. Временная диаграмма обмена DHCP-сообщениями между

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

q серверы получают широковещательное DHCPREQUEST-сообщение от

клиента. Те серверы, которые не были отобраны клиентом с помощью

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

того, что клиент “отверг” их предложения. Сервер, который был отобран

клиентом в DHCPREQUEST-сообщении, фиксирует настройки для кли-

ента в постоянном хранилище и отвечает клиенту DHCPACK-

сообщением, включающим востребованные клиентом параметры на-

стройки. Комбинация значений “Идентификатор клиента” или “Адрес

устройства клиента” (chaddr) и назначенного сетевого адреса составляют

уникальный идентификатор срока аренды клиентом адреса и

используют-

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

ваемого в любых DHCP-сообщениях. Любые параметры настройки в

DHCPACK-сообщении не должны “вступать в противоречие” с теми па-

раметрами, которые содержались в более раннем DHCPOFFER-

сообщении, на которое отвечает клиент. В этот момент сервер не должен

проверять предлагаемый сетевой адрес. В

поле “«Ваш» (клиента) IP-

адрес” (yiaddr) DHCPACK-сообщения записывается выбранный сетевой

адрес.

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

параметры в DHCPREQUEST-сообщении (например, запрошенный сете-

вой адрес уже был назначен другому клиенту), то серверу целесообразно

направить в ответ DHCPACK-сообщение.

Сервер может пометить адреса, предложенные клиенту в DHCPOFFER-

сообщениях, как недопустимые. Сервер должен пометить

адреса, пред-

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

не получил DHCPREQUEST-сообщение от клиента;

r клиент получает DHCPACK-сообщение с параметрами настройки. Клиент

должен провести окончательную проверку параметров (например, с по-

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

фиксировать продолжительность срока аренды, указанной в DHCPACK-

сообщении. С этого момента клиент считается “настроенным”. Если кли-

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

мер, с помощью

ARP-протокола), он должен передать серверу DHCPDE-

CLINE-сообщение и снова начать процедуру настройки. Клиенту реко-

мендуется выждать как минимум 10 секунд и только потом начать по-

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

фика в случае петлевого маршрута.

Если клиент получает DHCPNAK-сообщение, то клиент начинает по-

вторную процедуру настройки.

Если клиент получает

либо DHCPACK-сообщение, либо DHCPNAK-

сообщение, то по окончании тайм-аута он повторно передаёт DHCPRE-

QUEST-сообщение. Клиент повторно передаёт DHCPREQUEST-

сообщение в соответствие с алгоритмом повторной передачи. Клиент

должен определить необходимое число повторных передач DHCPRE-

QUEST-сообщения, что обеспечить гарантированное соединение с серве-

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

ентского программного модуля), а также должен достаточно долго ждать

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

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

QUEST-сообщения

в течение интервала времени, равного 60 секундам,

ещё до начала проведения повторной процедуры инициализации. Если

клиент получает, либо DHCPACK-сообщение, либо DHCPNAK-

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

возвращается в предшествующее состояние “Инициализация соединения”

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

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

что

процедуру инициализации соединения с сервером завершилась “не-

удачей”, и он начинает повторную процедуру инициализации;

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

отправки серверу DHCPRELEASE-сообщения. Клиент в этом сообщении

с помощью своего идентификатора “Идентификатор клиента” или “Адрес

устройства клиента” (chaddr) и сетевого адреса обозначает срок аренды,

от которого он хочет отказаться. Если клиент использует “Идентифика-

тор клиента”, который указывал при назначении срока аренды, то

DHCPRELEASE-сообщении он должен использовать точно такое же зна-

чение идентификатора.

§3.2. Процедура повторного назначения сетевого адреса (клиент/сервер)

Если клиент “запомнил” и желает повторно использовать ранее назначен-

ный ему сетевой адрес, то клиент может пропустить описанные выше итерации

процедуры назначения сетевого адреса

Временная диаграмма на рис.5 раскрывает сущность типовой процедуры

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

щие итерации:

c клиент в широковещательном режиме передаёт DHCPREQUEST-

сообщение в своей локальной подсети. Сообщение содержит сетевой ад-

рес клиента (параметр “Запрашиваемый IP-адрес) в поле “Дополнитель-

ные параметры”. Так как клиент не получал этого адреса в данной проце-

дуре, то он не должен размещать его в поле “IP-адрес клиента” (ciaddr).

BOOTP-агенты/ретрансляторы пересылают сообщение DHCP-серверам,

размещённым не в одной и той же посети. Если клиент использовал

“Идентификатор клиента” при получении своего адреса, то в DHCPRE-

QUEST-сообщении он должен использовать точно такое же значение

идентификатора;

Начало установления

соединения

DHCPDISCOVER DHCPDISCOVER

Определяет

настройки

Определяет

настройки

t tt

Игнорирование последующих

DHCPACK-сообщений

Завершение

соединения

DHCPACK

Рис.5. Временная диаграмма обмена DHCP-сообщениями между

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

d серверы, “знающие” параметры настройки клиента, направляют послед-

нему ответное DHCPACK-сообщение. Серверам необязательно проверять

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

может ответить на поступившие ICMP-сообщения/запросы в режиме эхо-

контроля.

Если запрос клиента является не корректным (например, вследствие пе-

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

дожны направить кли-

енту ответное DHCPNAK-сообщение. Серверы не должны отвечать, если

их информация не является гарантировано точной. Например, сервер, ко-

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

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

ное DHCPNAK-сообщение, если серверы не используют вполне конкрет-

ный способ обеспечения взаимной согласованности.

Если

в DHCPREQUEST-сообщении поле “IP-адрес агента/ретранслятора”

(giaddr) имеет нулевое значение (“0x0”), то клиент расположен в той же

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

DHCPNAK-сообщение в широковещательном режиме с широковеща-

тельным адресом “0xffffffff”, так как клиент может не иметь корректного

сетевого адреса или маски подсети, и кроме этого клиент может не отве-

чать запросы ARP-протоколы. В противном случае, сервер должен пере-

дать DHCPNAK-сообщение по IP-адресу BOOTP-агента/ретранслятора,

указанному в поле “IP-адрес агента/ретранслятора” (giaddr).

Агент/ретранслятор будет по очереди перенаправлять сообщение напря-

мую

по адресу сетевого устройства клиента, и поэтому указанное

DHCPNAK-сообщение может быть доставлено даже в том случае, когда

клиент был перемещён в новую сеть;

e клиент принимает DHCPNAK-сообщение, содержащее параметры на-

стройки. Клиент проводит заключительную проверку параметров и фик-

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

сообщении. Зафиксированный срок аренды в неявной форме идентифи-

цируется с помощью “Идентификатора клиента” или “Адреса устройства

клиента” (chaddr) и сетевого адреса. С этой точки зрения, клиент считает-

ся настроенным.

Если клиент обнаружит

, что указанный в DHCPACK-сообщении IP-адрес

уже используется, то клиент должен передать DHCPDECLINE-сообщение

серверу и повторно начать процесс настройки путём запроса нового сете-

вого адреса. Эта процедура означает переход клиента в состояние начала

установления соединения “INIT” (рис.5).

Если клиент принял DHCPNAK-сообщение, то он не может повторно ис-

пользовать ранее сохранённый сетевой адрес.

В ответ он должен повто-

рить запрос сетевого адреса путём повторной инициализации процесса

настройки параметров (данная процедура представлена в §3.1). Эта про-

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

нения “INIT” (рис.5).

Если клиент принял, либо DHCPACK-сообщение, либо DHCPNAK-

сообщение, то он, “выждав” тайм-аут, повторно передаёт DHCPRE-

QUEST-сообщение (в соответствии с

алгоритмом повторной передачи —

§4.1). Клиент должен определить необходимое число повторных передач

DHCPREQUEST-сообщения, что обеспечить гарантированное соединение

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

ля клиентского программного модуля), а также должен достаточно долго

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

Например, клиент может четыре раза продублировать

передачу

DHCPREQUEST-сообщения в течение интервала времени, равного 60 се-

кундам, ещё до начала проведения повторной процедуры инициализации.

Если клиент получает, либо DHCPACK-сообщение, либо DHCPNAK-

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

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

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

(рис.5) переход клиентского модуля в состояние “Готовности к настрой-

ке” (“Bound”);

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

передачи серверу DHCPRELEASE-сообщения. Клиент в этом сообщении

с помощью своего идентификатора “Идентификатор клиента” или “Адрес

устройства клиента” (chaddr) и сетевого адреса обозначает срок аренды,

от которого он хочет отказаться.

(

Замечание. В случае, когда клиент хранит свой сетевой адрес локально, он

обычно не отказывается от своего срока аренды до его естественного окон-

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

нии аренды своего сетевого адреса (например, клиент собирается перемес-

титься в другую подсеть), он отправит DHCPRELEASE-сообщение.)

§3.3. Интерпретация и представление значений времени

Клиент получает в аренду сетевой адрес в течение определенного (фик-

сированного) периода времени (может быть и бесконечным). В данном стан-

дарте время представлено в единицах секунд. Значение времени “0xffffffff”

обозначает бесконечный временной интервал (бесконечность, “infinity”).

Так как клиенты и серверы могут иметь часы, не синхронизированные

между собой, значения времени, представленные в DHCP-сообщениях,

являют-

ся относительными и связаны с показаниями локальных часов клиентов. Значе-

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

которая позволяет закодировать значение времени в диапазоне от 0 сек до ≈ 136

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

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

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

клиента

и сервера синхронизируются относительно друг друга (взаимная син-

хронизация). Если имеет место расхождение между значениями времени этих

часов, то сервер может полагать срок аренды истёкшим ещё до того, как это

сделает клиент. Для выравнивания значений времени сервер может назначить

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

в ло-

кальной БД сервера в записях об этом клиенте.

§3.4. Получение значений параметров при использовании

внешненазначаемых адресов

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

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

параметров настройки он может использовать DHCPINFORM-сообщение в ка-

честве запроса. Серверы после получения DHCPINFORM-сообщения форми-

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

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

вующих настроек, без заполнения поля “«Ваш» (клиента) IP-адрес” (yiaddr) или

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

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

поле

“IP-адрес клиента” (ciaddr) DHCPINFORM-сообщения.

Сервер должен проверить сетевой адрес в DHCPINFORM-сообщении на

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

аренды. Сервер по запросу клиента формирует DHCPACK-сообщение, содер-

жащее параметры настройки, и передаёт ему это сообщение напрямую.

§3.5. Параметры клиента в DHCP-протоколе

Не все клиенты запрашивают настройку всех параметров, которые приве-

дены в Приложении А. Существуют два способа для уменьшения числа пара-

метров, транслируемых от сервера к клиенту:

c значения большинства параметров устанавливаются в режиме “по умол-

чанию” (RFC-1122, RFC-1123). Если клиент не получает от сервера зна-

чений параметров, которые принимаются по умолчанию, то клиент ис-

пользует значения “по умолчанию”;

d в своём начальном DHCPDISCOVER- или DHCPREQUEST-сообщении

клиент может предоставить серверу перечень специфических параметров,

в которых заинтересован сам клиент. Если клиент включает DHCPDIS-

COVER-сообщение перечень параметров, он должен включить этот пере-

чень и во все последующие DHCPREQUEST-сообщения.

Кроме того, клиент должен включить дополнительный параметр “Макси-

мальный размер DHCP-сообщения” (“Maximum DHCP message size”), что по-

зволит серверу понять,

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

сообщения. И все-таки параметры, направляемые клиенту, могут превышать

допустимую длину поля “Дополнительные параметры” в DHCP-сообщении. В

этом случае, используется обязательное субполе “Флаги” в поле “Дополнитель-

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

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

и “Имя файла

загрузки” (file) для размещения значений параметров настройки.

Клиент может информировать сервер о том, какие параметры настройки

его интересуют, с помощью размещения в поле “Дополнительные параметры”

дополнительного параметра “Перечень запрашиваемых параметров” (“Parame-

ter request list”). Часть данных из этого перечня однозначно устанавливает спи-

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

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

времени срока аренды в DHCPDISCOVER-сообщении. Для этого он может ука-

зать необходимый ему адрес в дополнительном параметре “Запрашиваемый IP-

адрес” (“Requested IP address”) и желаемый срок аренды в дополнительном па-

раметре “Время срока аренды IP-адреса” (“IP address lease time”). Другие пара-

метры настойки, на которые “намекает” клиент, размещаются

в поле “Дополни-

тельные параметры” DHCPDISCOVER- или DHCPREQUEST-сообщений. Од-

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

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

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

тельный параметр “Запрашиваемый IP-адрес” должен размещаться только в

DHCPREQUEST-сообщении, если клиент поверяет ранее установленные

сете-

вые параметры. Клиент заполняет поле “IP-адрес клиента” (ciaddr) только когда

он корректно настроен и имеет IP-адрес в состояниях “Готовность к настройке”

(“Bound”), “Обновление” (“Renewing”) или “Полная смена параметров” (“Re-

binding”).

Если сервер получает DHCPREQUEST-сообщение с неприемлемым за-

прашиваемым IP-адресом, то он должен отправить клиенту ответное

DHCPNAK-сообщение и может оповестить системного администратора о воз-

никшей проблеме. Сервер может включить сообщение об ошибке в дополни-

тельный параметр “Сообщение” (“Message”).

§3.6. Использование DHCP-протокола клиентами, имеющими несколько

интерфейсов

Клиент, имеющий несколько интерфейсов должен использовать DHCP-

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

настройки для каждого отдельного интерфейса.

§3.7. Когда клиенты должны использовать DHCP-протокол

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

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

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

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

стройки локальной сети могут измениться независимо от того, знает о них кли-

ент

или нет).

Если клиенту известен предшествующий сетевой адрес, но он не спосо-

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

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

течет время аренды этого адреса.