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

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

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

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

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

лей о возникшей у него проблеме.

IV. ИСПОЛЬЗОВАНИЕ И ОБРАБОТКА

DHCP-СООБЩЕНИЙ

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

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

удовлетворения поступающих запросов на такие адреса. Также предполагается,

что каждый DHCP-сервер обслуживает БД с выделенными адресами и органи-

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

§4.1. Формирование и отправка DHCP-сообщений

DHCP-клиенты и DHCP-серверы формируют DHCP-сообщения путём за-

полнения фиксированных полей сообщения и присоединения пронумерованных

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

параметры). Переменная часть сообщения начинается с четырёх октетов, име-

нуемых как “Уникальная метка” (“magic cookie”), за которыми следуют допол-

нительные параметры. Последним дополнительным параметром всегда должен

быть параметр “Окончание” (“end”).

DHCP-протокол

в качестве транспортного протокола использует UDP-

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

на 67 UDP-порт DHCP-сервера, а DHCP-сообщения, транслируемые от сервера

к клиенту, поступают на 68 UDP-порт DHCP-клиента. Сервер с несколькими

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

щих DHCP-сообщениях.

Поле “Идентификатор сервера” используется для идентификации DHCP-

сервера в DHCP-сообщении

и в качестве адреса получателя в сообщениях,

транслируемых от клиентов на серверы. Сервер с несколькими сетевыми адре-

сами должен “подготовить” для доступа один из своих сетевых адресов с целью

идентификации этого сервера в DHCP-сообщении. С целью обеспечения мак-

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

ного идентификатора (наилучший

из всех известных) обязан выбрать такой ад-

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

сервер и DHCP-клиент подключены к одной и той же подсети (то есть, поле

“IP-адрес агента/ретранслятора” в сообщение клиента заполнено нулями), то

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

в качест-

ве собственного идентификатора (“server identifier”) при установлении соеди-

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

рой подсети, то может использоваться любой из этих адресов. Если сервер при-

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

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

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

держательной информацией, на основании которой он сможет сделать выбор).

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

“Идентификатор сервера” при формировании однонаправленных запросов на

DHCP-сервер.

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

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

IP-адрес отправителя.

Если поле “IP-адрес агента/ретранслятора” (giaddr) в DHCP-сообщении

клиента — не нулевое, то сервер в любом передаваемом BOOTP-

агенту/ретранслятору (с этим IP-адресом) сообщении указывает номер порта

DHCP-

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

клиента — нулевое, а поле “IP-адрес клиента” (ciaddr) — не нулевое, то сервер

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

IP-адресом клиента. Если поля “IP-адрес агента/ретранслятора” и “IP-адрес

клиента” в DHCP-сообщении клиента — нулевые, а широковещательный бит

(рис.2) равен “1”, то сервер передает DHCPOFFER- и DHCPACK-сообщения

клиенту в

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

“0xffffffff”. Если поля “IP-адрес агента/ретранслятора” и “IP-адрес клиента” в

DHCP-сообщении клиента — нулевые, а широковещательный бит (рис.2) равен

“0”, то сервер передает однонаправленные DHCPOFFER- и DHCPACK-

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

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

агента/

ретранслятора” (giaddr) — нулевое, сервер передает любые DHCPNAK-

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

“0xffffffff”.

Если в DHCP-сообщении поле “Дополнительные параметры” расширено

за счёт полей “Дополнительное имя устройства, со встроенным сервером”

(sname) и “Имя файла загрузки” (file), то в поле “Дополнительные параметры”

должен быть включён параметр “Расширенное поле “Дополнительные парамет-

ры”, имеющий значение “1”, “2” или

“3” (RFC-1533). Если в поле “Дополни-

тельные параметры” включён параметр “Расширенное поле “Дополнительные

параметры”, то параметры в поле “Дополнительные параметры” должны за-

вершаться параметром “Окончание” (“end”), а само поле должно (если это не-

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

нулями” — “pad”). Дополнительные параметры, размещаемые в полях “Допол-

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

сервером” и “Имя файла загрузки”

(если конечно они используются для этого, как указано в параметре “Расши-

ренное поле “Дополнительные параметры”), должны начинаться сразу с перво-

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

рым должно следовать дополнение нулями до границы этих полей (рис.6). Лю-

бой отдельный дополнительный параметр в полях “Дополнительные парамет-

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

загрузки” должен

быть полностью размещён в одном из этих полей. Параметры

в поле “Дополнительные параметры” должны интерпретироваться как первые

для того, чтобы все последующие расширения (параметр “Расширенное поле

“Дополнительные параметры”) этого поля могли быть корректно интерпрети-

рованы. Поле “Имя файла загрузки” должно интерпретироваться как следую-

щее (если параметр “Расширенное поле “Дополнительные параметры

” указыва-

ет на то, что поле “Имя файла загрузки” содержит DHCP-параметры), а за ним

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

0 … 0

Окончание Дополнительный параметр

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

(64 октета)

или

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

(128 октетов)

Рис.6. Формат полей “Дополнительное имя устройства, со встроенным

сервером” и “Имя файла загрузки” при размещении в них дополнительных

параметров в случае расширения поля “Дополнительные параметры”

(параметр “Расширенное поле “Дополнительные параметры”)

Значения параметров, размещаемых в поле “Дополнительные парамет-

ры”, могут оказаться длиннее разрешённых 255 октетов, отводимых для одного

параметра (например, перечень маршрутизаторов в параметре “Маршрутиза-

тор” (“router”), RFC-1542). Дополнительные параметры могут быть представле-

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

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

настройки.

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

вторной передачи сообщений. Клиент должен адаптировать стратегию повтор-

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

между процедурами повторной передачи. Задержка между процедурами по-

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

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

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

вых характеристик Internet-сети от сервера клиенту.

Поле “Идентификатор процедуры информационного обмена” (xid) ис-

пользуется клиентом для идентификации входящих DHCP-сообщений относи-

тельно отправленных запросов. DHCP-клиент обязан выбирать идентификатор

процедуры информационного обмена таким образом, чтобы минимизировать

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

катором другого клиента. Например, DHCP-клиент может каждый раз непо-

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

в дальнейшем использовать его до следующей перезагрузки. Выбор нового

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

том, зависящим от конкретной программной реализации DHCP-протокола.

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

иденти-

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

дуры повторной передачи.

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

тавить DHCPOFFER-, DHCPACK- и DHCPNAK-сообщения непосредственно

клиенту, используя для этого однонаправленные IP-адреса. В поле “«Ваш»

(клиента) IP-адрес” устанавливается IP-адрес получателя (в заголовке IP-

пакета), а в поле “Адреса устройства клиента” — адрес канального уровня

по-

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

собны принимать такие IP-пакеты (дейтаграммы) с однонаправленными IP-

адресами, причём до тех пор, пока программному модулю клиента не будет

присвоен разрешённый IP-адрес (возникает “тупиковая” ситуация, при которой

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

будет

присвоен IP-адрес).

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

тех пор, пока его программный DHCP-модуль не получит разрешённый IP-

адрес, должен в любом отправляемом им DHCPDISCOVER- или DHCPRE-

QUEST-сообщении установить широковещательный бит поля “Флаги” (рис.2) в

значение “1”. Этот бит будет “намекать” DHCP-серверу и BOOTP-

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

любых

сообщений клиенту по клиентской подсети. Клиент, который может

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

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

вещательный бит поля “Флаги” (рис.2) в значение “0”.

Сервер или агент/ретранслятор, передающий или принимающий DHCP-

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

ту/ретранслятору, адрес которого указан в поле “IP-адрес аген-

та/ретранслятора”) должен проверять широковещательный бит поля “Флаги”.

Если этот бит имеет значение “1”, то DHCP-сообщение должно быть передано в

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

вещательный IP-адрес (предпочтительнее “0xffffffff”) и широковещательный

адрес канального уровня в качестве адреса получателя канального уровня. Если

же этот бит имеет значение “0”, то DHCP-сообщение должно быть передано с

однонаправленным IP-адресом, который указан в поле

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

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

ента”. Если однонаправленный режим передачи не возможен, то DHCP-

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

качестве адреса получателя широковещательный IP-адрес (предпочтительнее

“0xffffffff”) и широковещательный адрес канального уровня в качестве адреса

получателя канального уровня.

§4.2. Средства административного

управления DHCP-сервером

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

нятое ими DHCPDISCOVER- и DHCPREQUEST-сообщение. Например, сетевой

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

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

чтобы они реагировали только на ответы тех клиентов, которые были ранее за-

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

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

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

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

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

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

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

DHCPREQUEST-сообщения,

при определении корректных параметров на-

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

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

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

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

метр “Идентификатор клиента”. Если клиент применил прикладной параметр

“Идентификатор клиента”, то он обязан использовать один и

тот же идентифи-

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

идентификатор для опознания клиента. Если клиент не применил прикладной

параметр “Идентификатор клиента”, то сервер для опознания клиента обязан

использовать значение из поля “Адрес устройства клиента” (chaddr). Это очень

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

ном параметре “

Идентификатор клиента” и являющийся уникальным для соот-

ветствующей подсети, к которой подключен клиент. Использование поля “Ад-

рес устройства клиента” в качестве уникального идентификатора клиента мо-

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

может быть связан с физическим интерфейсом устройства, к которому мог быть

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

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

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

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

терфейсов между компьютерами. Сетевые устройства также могут использо-

вать в качестве идентификатора клиента DNS-имя, вследствие чего сроки арен-

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

ройством.

Поле

DHCP-сообщения

DHCPOFFER-

сообщение

DHCPACK-

сообщение

DHCPNAK-

сообщение

“Тип сообщения” (op)

BOOTREPLY,

ответ на зап

ос

BOOTREPLY,

ответ на зап

ос

BOOTREPLY,

ответ на зап

ос

“Тип адреса

ст

ойства”

(

)

RFC-1700

“Длина адреса

ст

ойства”

(

hlen

)

Длина адреса сетевого устройства (в октетах)

“Число

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

частков”

(

)

“Идентификатор

процедуры

информационного

обмена”

(

xid

)

Из аналогичного поля

DHCPDISCOVER-

сообщения клиента

Из аналогичного поля DHCPREQUEST-

сообщения клиента

“Время начала

дур

ы”

(

secs

)

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

(ciaddr)

Из аналогичного поля

DHCPREQUEST-сообщения

клиента или “0

”

“«Ваш» (клиента)

IP-а

др

ес”

(

iadd

)

Предложенный

клиент

IP-а

др

ес

Назначенный

клиент

IP-а

др

ес

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

се

ве

а”

(

siadd

)

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

“Флаги”

(

fla

)

“IP-адрес

агента/ретранслятора”

(

iadd

)

Адрес устройства

клиента”

(

chadd

)

Из аналогичного поля

DHCPDISCOVER-

сообщения клиента

Из аналогичного поля

DHCPREQUEST-сообщения клиента

“Дополнительное имя

устройства, со

встроенным

се

ве

ом”

(

sname

)

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

расширение поля “Дополнительные параметры”

(options)

Не используется

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

(file)

Имя файла загрузки клиента или расширение

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

Не используется

“Дополнительные

параметры” (options)

Значения дополнительных параметров Не используется

Рис.7,а. Порядок использования DHCP-сервером полей DHCP-сообщения

DHCP-клиенты свободны в определении стратегии отбора DHCP-сервера

среди тех, от которых клиент получил DHCPOFFER-сообщения. Программный

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

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

ний-вендоров.

Дополнительный

параметр

DHCPOFFER-

сообщение

DHCPACK-

сообщение

DHCPNAK-

сообщение

Запрашиваемый

IP-адрес

Должен отсутствовать

Время срока аренды

IP-адреса

Должен

присутствовать

Должен присутствовать если принято

DHCPREQUEST-сообщение. Должен

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

DHCPINFORM-сообщение.

Должен

отсутствовать

Использование полей

“Дополнительное имя

устройства, со

встроенным сервером”

и “Имя файла

загрузки”

Допускается Не допускается

Тип DHCP-сообщения DHCPOFFER-сообщение DHCPACK-сообщение DHCPNAK-сообщение

Перечень

запрашиваемых

параметров

Должен отсутствовать

Сообщение Целесообразно

Идентификатор клиента Не допускается Допускается

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

класса вендоров

Допускается

Идентификатор сервера Должен присутствовать

Максимальный размер

сообщения

Должен отсутствовать

Все остальные

параметры

Допускаются Не допускаются

Рис.7,б. Порядок использования DHCP-сервером дополнительных

параметров DHCP-сообщения

§4.3. Процедурная характеристика DHCP-сервера

DHCP-сервер обрабатывает входящие DHCP-сообщения клиента, учиты-

вая текущее состояние настройки параметров в интересах соответствующего

клиента. Он может принимать от клиента следующие сообщения:

• “DHCPDISCOVER”;

• “DHCPREQUEST”;

• “DHCPDECLINE”;

• “DHCPRELEASE”;

• “DHCPINFORM”.

На рис.7(а,б) представлены таблицы использования сервером полей и до-

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

§4.3.1. Обработка DHCPDISCOVER-сообщения

Когда сервер получает от клиента DHCPDISCOVER-сообщение, он вы-

бирает сетевой адрес для запрашивающего клиента. В случае отсутствия при-

емлемого адреса сервер сообщит системному администратору о возникшей

проблеме. Если же соответствующий адрес существует, то его целесообразно

выбирать следующим образом:

1. Текущий адрес клиента из хранящейся совокупности параметров на-

стройки клиента. В противном случае;

2. Предшествующий адрес клиента из хранящейся совокупности параметров

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

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

сервера и ещё никому не выделен. В противном случае;

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

адрес”, если такой адрес допустим и ещё никому не выделен. В против-

ном случае;

4. Вновь назначенный адрес, выбранный из диапазона допустимых адресов

сервера. Адрес выбирается учётом подсети, из которой поступило сооб-

щение (если поле “IP-адрес агента/ретранслятора” (giaddr) нулевое), или с

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

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

Сервер может (по административным “соображениям”) выделить иной

адрес, отличный от

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

ответствующим клиентом адрес, даже, несмотря на то, что это адрес входит в

диапазон свободных и допустимых адресов.

(

Замечание. В некоторых сетевых структурах (например, региональная Ин-

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

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

рес от другой подсети, а не от той, адрес которой указан в поле “IP-адрес аген-

та/ретранслятора”. Следовательно, DHCP-протокол не требует, чтобы клиент по-

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

та/ретранслятора”. Сервер свободен в выборе любой другой подсети, но это не

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

адресов).

Несмотря на то, что это не влияет на корректное функционирование

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

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

сервера. Сервер может сохранить адрес в качестве “предлагаемого серверу”.

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

разом:

1. Если клиент не запросил конкретного срока аренды в своём DHCPDIS-

COVER-сообщении, и он уже имеет выделенный сетевой адрес, то сервер

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

его аренды (

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

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

са.). В противном случае;

2. Если клиент не запросил конкретного срока аренды в своём DHCPDIS-

COVER-сообщении и клиенту ещё не выделен сетевой адрес, то сервер

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

умолчанию”. В противном случае;

3. Если клиент запросил конкретный срок аренды в своём DHCPDIS-

COVER-сообщении (невзирая на то, есть ли клиента назначенный ему ад-

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

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

деляет иной срок аренды.

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

форми-

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

ры настройки. Очень важно, чтобы все DHCP-серверы в ответных сообщениях

размещали одни и те же параметры настройки (за вероятным исключением

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

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

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

на основе следующих правил в указан-

ном порядке. Сетевой администратор несёт ответственность за настройку не-

скольких DHCP-серверов с целью обеспечения гарантий того, что последние

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

ном сообщении клиенту обязан направлять:

# сетевой адрес клиента (по правилам представленным выше);

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

ленным выше);

# параметры, запрошенные клиентом по следующим правилам:

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

метра в режиме “по-умолчанию”, то он обязан включить такое значе-

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

противном случае;

2. Если сервер определяет, что параметр относится к числу параметров,

устанавливаемых на основании стандартов RFC-1122 и RFC-1123

“Требования к сетевым Internet-устройствам”, то сервер обязан вклю-

чить такое значение из стандартов RFC-1122 и RFC-1123 в соответст-

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

чае;

3. сервер обязан не отправлять значение того параметра, если:

 какие-либо параметры из существующей группы параметров отли-

чаются от значений параметров из стандартов RFC-1122 и RFC-1123

в режиме “по-умолчанию”;

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

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

параметре “Идентификатор клиента” DHCPDISCOVER- или

DHCPREQUEST-сообщения), например, настроенные сетевым адми-

нистратором;

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

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

ров” DHCPDISCOVER- или DHCPREQUEST-сообщения), например,

настроенные сетевым администратором. Параметры должны распо-

знаваться путём внешнего сравнения идентификаторов классов вен-

доров клиентов и классов клиентов, идентифицированных в сервере;

 параметры, устанавливаемые не в режиме “по-умолчанию” в подсети

клиента.

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

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

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

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

делён в стандарте RFC-2132.

Сервер

может указать в ответном DHCPOFFER-сообщении “Идентифика-

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

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

из всех полученных DHCPOFFER-сообщений. Сервер извлекает значение поля

“Идентификатор процедуры информационного обмена” (xid) DHCPDIS-

COVER-сообщения и размещает его в аналогичном поле DHCPOFFER-

сообщения, которое направляет запрашивающему клиенту.

§4.3.2. Обработка DHCPREQUEST-сообщения

DHCPREQUEST-сообщение может поступить, либо от клиента, который

отвечает на DHCPOFFER-сообщение сервера, либо от клиента, проверяющего

ранее выделенный (назначенный ему) IP-адрес, либо от клиента, продлевающе-

го срок аренды сетевого адреса. Если DHCPREQUEST-сообщение содержит

параметр “Идентификатор сервера”, то оно является ответом на DHCPOFFER-

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

продление существующего срока аренды. Если клиент указывает “Идентифика-

тор клиента” в DHCPREQUEST-сообщении, то он обязан использовать точно

такой же “Идентификатор клиента” во всех последующих сообщениях. Если