Протокол динамического конфигурирования ЭВМ DHCP

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

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

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

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

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

   Если giaddr в сообщении DHCPREQUEST равен 0x0, клиент находится в той же субсети, что и сервер. Сервер должен широковещательно послать сообщение DHCPNAK по адресу 0xffffffff, так как клиент может не иметь правильного сетевого адреса или сетевой маски, и клиент может не отвечать на ARPзапрос. В противном случае, сервер должен послать сообщение DHCPNAK по IP-адресу транспортного агента BOOTP, записанного в giaddr. Транспортный агент, в свою очередь, переадресует сообщение непосредственно по аппаратному адресу клиента, так что DHCPNAK будет доставлен, даже если клиент переместился в другую сеть.
3. Клиент получает сообщение DHCPACK, содержащее конфигурационные параметры. Клиент выполняет окончательную проверку параметров, и отмечает время действия конфигурации, специфицированное в сообщении DHCPACK. Значение времени действия неявно задается client identifier или chaddr и сетевым адресом. С этого момента клиент считается сконфигурированным

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

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

   Клиент выполняет таймаут и повторно посылает сообщение DHCPREQUEST. Если клиент не получает ни сообщения DHCPACK, ни DHCPNAK, он повторно посылает сообщение DHCPREQUEST. Клиент должен выбрать число повторных передач сообщения DHCPREQUEST адекватным, чтобы обеспечить достаточную вероятность доступа к серверу, не заставляя клиента (и пользователя этого клиента) ждать слишком долго. Например, клиент, осуществляя повторную пересылку, может повторно передать сообщение DHCPREQUEST четыре раза при полной задержке 60 секунд, прежде чем запустит процедуру инициализации. Если клиент после повторной пересылки не получил ни сообщения DHCPACK, ни DHCPNAK, он может решить использовать присвоенный ранее сетевой адрес и конфигурационные параметры вплоть до истечения срока их действия. Это соответствует переходу в состояние BOUND на диаграмме состояний клиента, показанной на рис. 6.5.
4. Клиент может решить отказаться от сетевого адреса путем посылки серверу сообщения DHCPRELEASE. Клиент идентифицирует набор параметров, от которого он отказывается, с помощью идентификатора клиента или chaddr и сетевого адреса в сообщении DHCPRELEASE

Заметим, что в случае, когда клиент сохраняет свой сетевой адрес локально, при корректном прерывании сессии (shutdown) он не должен отказываться от конфигурационного набора. Только в случае, когда клиенту нужно отказаться от конфигурационного набора (например, клиент намеривается перейти в другую субсеть), он будет должен послать сообщение DHCPRELEASE.

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

Клиент получает сетевой адрес на определенный период времени (который может быть бесконечным). В данном протоколе время измеряется в секундах. Значение времени 0xffffffff зарезервировано для обозначения бесконечности.

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

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