Временная диаграмма обмена

Рисунок 3. Временная диаграмма обмена сообщениями между DHCP-клиентом и сервером в ходе присвоения нового сетевого адреса

3. Клиент получает одно или более сообщений DHCPOFFER от одного или более серверов. Клиент может предпочесть дождаться нескольких откликов. Клиент выбирает один сервер, которому пошлет запрос конфигурационных параметров, согласно предложению, содержащемуся в сообщении DHCPOFFER. Клиент широковещательно отправляет сообщение DHCPREQUEST, которое должно содержать опцию 'server identifier', чтобы указать, какой сервер им выбран, и которое может включать в себя другие опции, специфицирующие желательные конфигурационные значения. Опция 'requested IP-адрес' в сообщении сервера DHCPOFFER должна содержать значение 'yiaddr'. Сообщение DHCPREQUEST посылается широковещательно агентами транспортировки DHCP/BOOTP. Для того чтобы быть уверенным, что любой агент транспортировки BOOTP направляет сообщение DHCPREQUEST тому же набору DHCP-серверов, которые получили исходное сообщение DHCPDISCOVER, сообщение DHCPREQUEST должно использовать то же значение поля 'secs' заголовка DHCP-сообщения и должно посылаться по тому же широковещательному IP-адресу, что и оригинальное сообщение DHCPDISCOVER. Клиент реализует таймаут и повторно посылает сообщение DHCPDISCOVER, если не получает сообщений DHCPOFFER.

Серверы получают широковещательное сообщение DHCPREQUEST от клиента. Серверы, не выбранные сообщением DHCPREQUEST, используют сообщение как уведомления о том, что клиент отверг предложение сервера. Сервер, выбранный сообщением DHCPREQUEST, осуществляет запись конфигурационного набора клиента в постоянную память и реагирует сообщением DHCPACK, содержащим конфигурационные параметры для клиента, приславшего запрос. Комбинация 'client identifier' или 'chaddr' и присвоенного сетевого адреса представляет собой уникальный идентификатор для времени действия адреса клиента и используется клиентом и сервером для идентификации этого времени в любом DHCP-сообщения. Любые конфигурационные параметры в сообщении DHCPACK не должны конфликтовать с параметрами из сообщения DHCPOFFER, на которое клиент откликается. Сервер не должен проверять предложенный сетевой адрес. В поле 'yiaddr' сообщений DHCPACK записывается выбранный сетевой адрес.

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

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

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

< и повторно посылает сообщение DHCPREQUEST,

Интегрированные сети ISDN

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

/p> Клиент реализует таймаут и повторно посылает сообщение DHCPREQUEST, если клиент не получает ни сообщения DHCPACK ни DHCPNAK. Клиент повторно посылает DHCPREQUEST согласно алгоритму повторной пересылки, описанному в разделе 4.1. Клиент должен выбрать число повторных передач сообщения DHCPREQUEST адекватным, чтобы обеспечить достаточную вероятность доступа к серверу, не заставляя клиента (и пользователя этого клиента) ждать слишком долго; например, клиент, осуществляя повторную пересылку так, как это описано в разделе 4.1, может повторно послать сообщение DHCPREQUEST четыре раза, при полной задержке 60 секунд, прежде чем повторно запустит процедуру инициализации. Если клиент не получает ни сообщения DHCPACK ни DHCPNAK после применения алгоритма повторной пересылки, клиент возвращается в исходное состояние и перезапускает процесс инициализации. Клиент должен уведомить пользователя о том, что процесс инициализации не прошел и делается повторная попытка.

Клиент может решить отказаться от аренды сетевого адреса путем посылки серверу сообщения DHCPRELEASE. Клиент идентифицирует набор параметров, от которого он отказывается, с помощью своего идентификатора, или 'chaddr' и сетевого адреса в сообщении DHCPRELEASE. Если клиент использовал идентификатор клиента, когда он получил набор конфигурационных параметров, клиент должен использовать тот же идентификатор клиента (client identifier) в сообщении DHCPRELEASE.

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

Если клиент помнит и желает использовать выделенный ранее сетевой адрес, он может опустить некоторые шаги, рассмотренные в предыдущем разделе. Временная диаграмма на Рисунок 4 показывает типовое взаимодействие клиента и сервера в случае повторного использования старого сетевого адреса.

Клиент широковещательно рассылает по локальной субсети сообщение DHCPREQUEST. Сообщение включает в себя сетевой адрес клиента в опции 'requested IP-адрес'. Раз клиент не получил свой сетевой адрес, он не должен заполнять поле 'ciaddr'. Агенты транспортировки BOOTP передают сообщение DHCP-серверам за пределами данной субсети. Если клиент использует 'client identifier' для получения своего адреса, клиент должен использовать тот же 'client identifier' в сообщении DHCPREQUEST.

Серверы, которые знают конфигурационные параметры клиента, откликаются сообщением DHCPACK. Серверы не должны проверять, используется ли уже сетевой адрес клиента; клиент может реагировать посылкой запроса эхо ICMP.

Содержание раздела

Так как клиент и сервер могут не иметь синхронизованных часов, значения времени в DHCP-сообщения являются относительными, и должны интерпретироваться с учетом показаний локальных часов клиента. Время измеряется в секундах и представляется в виде 32-битных кодов без знака. Это позволяет описывать относительные интервалы времени от 0 до примерно 100 лет, что вполне приемлемо для целей протокола DHCP.

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

3.4. Получение параметров при внешне заданных адресах

Если клиент получил сетевой адрес каким-то другим образом (например, при ручной конфигурации), он может использовать запрос-сообщение DHCPINFORM, чтобы получить другие локальные конфигурационные параметры. Серверы, получив сообщение DHCPINFORM, формируют сообщение DHCPACK с любыми конфигурационными параметрами, приемлемыми для клиента. При этом сетевой адрес не присваивается, не проверяется существующий набор параметров, не заполняется 'yiaddr' и не задаются параметры времени действия конфигурационного набора. Серверы должны послать ответ DHCPACK по уникастному адресу, заданному в поле 'ciaddr' сообщения DHCPINFORM.

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

3.5. Параметры клиента в DHCP

Не все клиенты требуют инициализации всех параметров, перечисленных в приложении A.

Используются два способа сокращения числа параметров, пересылаемых от сервера клиенту. 1. Большинство параметров имеет значения по умолчанию, определенные в Host Requirements RFC; если клиент не получил параметров от сервера, которые переписывают значения по умолчанию, клиент использует эти значения. 2. В своем исходном сообщении DHCPDISCOVER или DHCPREQUEST, клиент может предоставить серверу список специфических параметров, которые ему нужны. Если клиент включает список параметров в сообщение DHCPDISCOVER, он должен включать этот список в любое последующее сообщение DHCPREQUEST.

Клиент должен включить опцию 'maximum DHCP message size', чтобы позволить серверу знать, максимальный размер его DHCP-сообщений. Параметры, присланные в ответ клиенту, могут иметь размер больший, чем выделено для опций в сообщении DHCP. В этом случае, два дополнительных опционных флага (которые должны присутствовать в поле 'опции' сообщения) индицируют, что для опций должны использоваться поля 'file' и 'sname'.

Клиент может проинформировать сервер о том, в каких конфигурационных параметрах заинтересован клиент, включив опцию 'parameter request list'.

Кроме того, клиент может предложить значения для сетевого адреса и времени его действия в сообщении DHCPDISCOVER. Клиент может включить опцию 'requested IP-адрес', чтобы предложить конкретное значение IP-адреса, которое он хотел бы получить, и может включить опцию 'IP-адрес lease time', чтобы предложить предпочтительное значение времени действия конфигурационного набора. Другие опции, представляющие рекомендации по конфигурационным параметрам, допустимы в сообщении DHCPDISCOVER или DHCPREQUEST. Однако дополнительные опции могут игнорироваться серверами, и разные серверы могут прислать различные отклики на одни и те же опции. Опция 'requested IP-адрес' должна заноситься только в сообщение DHCPREQUEST, когда клиент проверяет конфигурационные параметры, полученные ранее. Клиент заполняет поле 'ciaddr', только когда он имеет корректный IP-адрес в состояниях BOUND, RENEWING или REBINDING.

Если сервер получает сообщение DHCPREQUEST с некорректным 'запрошенным IP-адресом', он должен прислать клиенту сообщение DHCPNAK и может уведомить о проблеме системного администратора. Сервер может включить код ошибки в опцию сообщения.

3.6. Применение DHCP для клиентов с несколькими интерфейсами

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

3.7. Когда клиентам следует использовать DHCP?

Клиент должен использовать DHCP для нового запроса или верификации своего IP-адреса и сетевых параметров всякий раз, когда локальные конфигурационные параметры изменились; например, во время перезагрузки системы или после сетевого разрыва, так как локальная сетевая конфигурация может измениться без информирования об этом клиента или пользователя.

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

Содержание раздела