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

DHCP определяет новую опцию 'client identifier', которая используется для прямой передачи идентификатора клиента DHCP серверу. Это изменение исключает перегрузку поля 'chaddr' в сообщениях BOOTP, где 'chaddr' используется как в качестве аппаратного адреса для пересылки сообщений откликов BOOTP, так и в качестве идентификатора клиента. Идентификатор клиента представляет собой непрозрачный ключ, который не должен интерпретироваться сервером; например, идентификатор клиента может содержать аппаратный адрес, идентичный тому, который лежит в поле 'chaddr', или он может содержать другой идентификатор типа, такой как DNS-имя. Идентификатор клиента, выбранный DHCP клиентом, должен быть уникальным для субсети, к которой он подключен. Если клиент использует идентификатор клиента в одном сообщении, он должен использовать тот же идентификатор во всех последующих сообщениях, чтобы гарантировать корректную идентификацию клиента всеми серверами. DHCP определяет поле 'siaddr' как адрес сервера для использования во время следующего шага процесса начальной загрузки клиента. DHCP-сервер может прислать свой собственный адрес в поле 'siaddr', если сервер готов обеспечить последующую загрузку (например, доставку образа операционной системы). DHCP-сервер всегда присылает свой адрес в опции 'server identifier'. Назначения полей заголовка представлены в таблице 1.

Таблица 1. Описание полей сообщения DHCP

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

В случае, когда клиент использует DHCP для начальной конфигурации (прежде чем программа клиента TCP/IP полностью сконфигурирована), DHCP требует использования клиентского программного обеспечения TCP/IP в вольной интерпретации RFC-1122. Программа TCP/IP должна принять и передать IP-уровню любой IP-пакет, доставленный по аппаратному адресу клиента, до того как IP-адрес будет сконфигурирован; DHCP-серверы и агенты транспортировки BOOTP могут быть неспособны доставить DHCP-сообщения клиентам, которые не могут принимать уникастные дейтограммы, до того, как программа TCP/IP сконфигурирована должным образом.

Для того чтобы работать с клиентами, которые не могут воспринимать уникастные IP-дейтограммы до того, как будет сконфигурирована программа TCP/IP, DHCP использует поле 'флаги' [21]. Самый левый бит определен как флаг BROADCAST (B). Остающиеся биты поля флаги зарезервированы на будущее. Они должны быть установлены равными нулю клиентами и игнорироваться серверами и агентами транспортировки. На рис. 2 показан формат поля флаги.

B: флаг BROADCAST
MBZ: должно быть равно нулю (must be zero; зарезервировано на будущее)

Рис. .2: Формат поля 'флаги'

Первым видом сервиса, предоставляемого DHCP, является запоминание сетевых параметров для клиента. Модель DHCP памяти характеризуется записями ключ - значение для каждого клиента, где ключ представляет собой некоторый уникальный идентификатор (например, номер IP-субсети и уникальный идентификатор в пределах субсети), а значение содержит набор конфигурационного параметров клиента.

Например, ключ может представлять собой пару (номер IP-субсети, аппаратный адрес), чтобы допустить повторное или даже одновременное применение одних и тех же аппаратных адресов в различных субсетях. Заметим, что должен быть определен тип "аппаратного адреса" с тем, чтобы можно было решить проблему возможного дублирования при изменении порядка бит в случае смешения типов оборудования. В качестве альтернативы, ключ может представлять собой пару (номер IP-субсети, имя ЭВМ), позволяя серверу присвоить параметры DHCP-клиенту, который переместился в другую субсеть или сменил свой аппаратный адрес (возможно из-за выхода из строя и замены сетевого интерфейса). Протокол определяет то, что ключ представляет собой (номер IP-субсети, аппаратный адрес), если только клиент не прелагает идентификатор в явном виде, используя опцию 'client identifier'. Клиент может запросить DHCP-сервис, чтобы получить свои конфигурационные параметры. Интерфейс клиента к депозитарию конфигурационных параметров реализуется с помощью протокольных сообщений запроса и откликов серверов, несущих в себе конфигурационные параметры.

Вторым видом сервиса, предоставляемым DHCP, является временное или постоянное выделение клиенту сетевого (IP) адреса. Основной механизм для динамического присвоения сетевых адресов достаточно прост: клиент запрашивает использование адреса на определенный период времени. Механизм выделения адреса (ассоциация DHCP-серверов) гарантирует, что адрес в течение оговоренного времени не будет использован для других целей, и пытается прислать тот же сетевой адрес всякий раз, когда клиент его запрашивает. Клиент может расширить это время последующими запросами. Клиент может послать серверу сообщение об освобождении адреса, когда клиент более не нуждается в этом адресе. Клиент может запросить постоянное присвоение адреса, потребовав бесконечное значение времени выделения адреса. Даже при "постоянном" выделении адресов, сервер может определить большой, но не бесконечный срок аренды адреса, чтобы позволить детектирование факта, что клиент перестал работать.

При некоторых обстоятельствах может оказаться необходимым повторно присваивать сетевые адреса из-за отсутствия свободных адресов. При таких условиях, механизм выделения будет повторно присваивать адреса, чье время действительности истекло. Сервер должен использовать информацию, которая доступна в конфигурационном депозитарии, чтобы выбрать адрес, который может быть использован повторно. Например, сервер может выбрать последний из присвоенных адресов. В качестве проверки совместимости сервер должен проверить повторно используемые адреса, прежде чем их повторно пускать в оборот. Это может быть, например, контроль посредством ICMP эхо-запроса, а клиент должен проверить вновь полученный адрес, например, посредством ARP.

DHCP использует формат сообщение BOOTP, определенный в RFC-951 и представленный в таблице 1 и на рис. 1. Поле 'op' каждого сообщения DHCP, посланного клиентом серверу, содержит BOOTREQUEST. В поле 'op' DHCP-сообщения, посланного сервером клиенту, заносится BOOTREPLY.

Первые 4 октета поля 'опции' сообщения DHCP содержат (десятичные) коды 99, 130, 83 и 99, соответственно (это те же коды (magic cookie), что определены в RFC-1497 [17]). Остальная часть поля 'опции' состоит из списка помеченных параметров, которые называются "опции". Все "vendor extensions" перечисленные в RFC-1497, являются также опциями DHCP. Документ RFC-1533 предоставляет полный набор опций, определенных для использования с DHCP.

Несколько опций уже определено. Одной из них является опция "DHCP message type", которая должна включаться во все DHCP-сообщения. Эта опция определяет тип DHCP-сообщения. Дополнительные опции могут допускаться, требоваться или не разрешаться в зависимости от типа DHCP-сообщения.

В рамках данного документа, DHCP-сообщения, которые содержат опцию 'тип сообщения DHCP' будут восприниматься согласно типу сообщения; например, сообщение DHCP с типом опции равным 1 будет восприниматься как сообщение "DHCPDISCOVER".

Ниже рассматривается протокольный обмен между клиентом и сервером DHCP-сообщениями, описанными в таблице 2. Временная диаграмма на рис. 3 демонстрирует типичную схему взаимодействия клиента и сервера. Если клиент уже знает свой адрес, некоторые шаги могут быть опущены; такое упрошенное взаимодействие описано в разделе 3.2.

1.

Клиент широковещательно пересылает сообщение DHCPDISCOVER по локальной физической субсети. Сообщение DHCPDISCOVER может включать опции, которые предлагают значения для сетевого адреса и длительности его использования. Агент транспортировки BOOTP может передать сообщение DHCP-серверам, которые размещены за пределами данной физической субсети.

2.

Каждый сервер может откликнуться сообщением DHCPOFFER, которое содержит сетевой адрес в поле 'yiaddr' (и другие конфигурационные параметры в опциях DHCP). Серверы не должны резервировать предлагаемый сетевой адрес, хотя протокол будет работать более эффективно, если сервер избегает присвоения предлагаемого сетевого адреса другому клиенту. При выделении нового адреса, серверы должны проверять, чтобы предлагаемый сетевой адрес не использовался где-то еще; например, сервер может протестировать предлагаемый адрес с помощью эхо-запроса ICMP. Серверы должны быть реализованы так, чтобы сетевые администраторы могли выбрать желательные тесты для вновь выделяемых адресов. Сервер отправляет клиенту сообщение DHCPOFFER, используя, если необходимо транспортные средства BOOTP.

Таблица 2: Сообщения DHCP

Сообщение	Использование
DHCPDISCOVER	Клиент посылает сообщение широковещательно, чтобы обнаружить доступный сервер.
DHCPOFFER	Посылается сервером клиенту в ответ на сообщение DHCPDISCOVER и содержит предложение по конфигурационным параметрам.
DHCPREQUEST	Сообщение клиента серверу либо (a) запрашивающее параметры от одного сервера и неявно отвергающее предложения других серверов, (b) подтверждающее корректность ранее присвоенного адреса после, например, перезагрузки системы, или (c) запрос расширения времени жизни конкретного сетевого адреса.
DHCPACK	Посылается сервером клиенту и содержит конфигурационные параметры, включая присвоенный сетевой адрес.
DHCPNAK	Посылается сервером клиенту, сообщая о том, что сетевой адрес не корректен (например, клиент переместился в новую субсеть), или время использования адреса клиентом истекло
DHCPDECLINE	Клиент и сервер обнаружили, что сетевой адрес уже используется.
DHCPRELEASE	Посылается клиентом серверу с целью отказа от сетевого адреса и аннулирует оставшееся время действия адреса.
DHCPINFORM	Посылается клиентом серверу с просьбой о локальных конфигурационных параметрах; клиент уже имеет полученный извне сетевой адрес.

Рис. 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.

4.

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

5.

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

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

6.

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

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

1.

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

2.

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

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

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

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

3.

Клиент получает сообщение DHCPACK, содержащее конфигурационные параметры. Клиент выполняет окончательную проверку параметров (как в разделе 3.1), и отмечает время действия конфигурации, специфицированное в сообщении DHCPACK. Значение времени действия неявно задается 'client identifier' или 'chaddr' и сетевым адресом. С этого момента клиент считается сконфигурированным.

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

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

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

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

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

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

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

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

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

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

Не все клиенты требуют инициализации всех параметров, перечисленных в приложении 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 и может уведомить о проблеме системного администратора. Сервер может включить код ошибки в опцию сообщения.

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

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

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

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

Клиенты и серверы DHCP конструируют DHCP-сообщения путем заполнения полей в секции сообщения с фиксированным форматом и присоединяя помеченные информационные элементы переменной длины в секции опций. Область опций включает в себя 4-октетную секцию 'magic cookie' (которая описана в разделе 3), за которой следуют собственно опции. Последняя опция должна быть всегда опцией 'end'.

DHCP использует в качестве транспортного протокола UDP. DHCP-сообщения от клиента к серверу посылаются через порт DHCP-сервера (67), а DHCP-сообщения от сервера к клиенту посылаются через порт DHCP-клиента (68). Сервер с несколькими сетевыми адресами (например, ЭВМ с несколькими сетевыми интерфейсами) может использовать для передачи исходящего DHCP-сообщения любой из своих сетевых адресов.

Поле 'server identifier' используется как для идентификации DHCP-сервера в DHCP-сообщении, так и в качестве адреса места назначения при передаче информации от клиента серверу. Сервер с несколькими сетевыми адресами должен быть готов воспринимать любой из своих сетевых адресов в качестве идентификатора в DHCP-сообщении. Чтобы адаптироваться к потенциально не полной сетевой коннективности, сервер должен выбрать адрес в качестве 'server identifier', который по информации сервера доступен со стороны клиента. Например, если DHCP-сервер и DHCP-клиент подключены к одной субсети (т.e., поле 'giaddr' в сообщении от клиента равно нулю), сервер должен выбрать свой IP-адрес, используемый для передачи в пределах субсети в качестве 'server identifier'. Если сервер использует несколько IP-адресов в субсети, он может воспользоваться любым таким адресом. Если сервер получил сообщение через DHCP-агента доставки, сервер должен в качестве 'server identifier' выбрать адрес интерфейса, через который получено сообщение, (если только сервер не имеет других, лучших идей по поводу такого выбора). DHCP-клиенты должны использовать IP-адрес, переданный через опцию 'server identifier', для любого уникастного запроса, адресованного DHCP-серверу.

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

Если поле 'giaddr' в DHCP-сообщении клиента не равно нулю, сервер посылает любой отклик в порт 'DHCP server' агента транспортировки BOOTP, чей адрес указан в 'giaddr'. Если поле 'giaddr' равно нулю, а поле 'ciaddr' не равно нулю, тогда сервер посылает сообщения DHCPOFFER и DHCPACK по уникастному адресу, записанному в поле 'ciaddr'. Если 'giaddr' равно нулю и 'ciaddr' равно нулю, а бит broadcast =1, тогда сервер посылает сообщения DHCPOFFER и DHCPACK по адресу 0xffffffff. Если бит broadcast =1 и 'giaddr' равно нулю и 'ciaddr' равно нулю, тогда сервер посылает сообщения DHCPOFFER и DHCPACK по аппаратному адресу клиента и адресу 'yiaddr'. Во всех случаях, когда 'giaddr' равно нулю, сервер широковещательно посылает любое сообщение DHCPNAK по адресу 0xffffffff.

Если опции в DHCP-сообщении распространяются на поля 'sname' и 'файл', в поле 'опции' должна появиться опция 'option overload', со значением 1, 2 или 3, как это специфицировано в RFC-1533. Если в поле 'опции' присутствует опция 'option overload', опции в этом поле должны завершаться опцией 'end', и могут содержать один или более опций 'pad' (заполнитель). Опции в полях 'sname' и 'файл' (если их применение индицировано опцией 'options overload') должны начинаться с первого октета поля, завершаться опцией 'end', и за ними для заполнения пространства до конца поля должны следовать опции 'pad'. Любая индивидуальная опция в полях 'опции', 'sname' и 'файл' должна полностью умещаться в поле. Опции в поле 'options' должны интерпретироваться первыми, так чтобы любая 'option overload' могла быть воспринята. Поле 'файл' должно интерпретироваться следующим (если опция 'option overload' указывает, что поле 'файл' содержит опции DHCP), за ним должно следовать поле 'sname'.

Значения, передаваемые в метку 'option' могут превосходить по длине 255 октетов, выделенных на одну опцию (например, список маршрутизаторов опции 'router' [21]). Опции могут появляться только раз, если только явно не указано обратного. Клиент присоединяет значения кратных опций к общему списку параметров для конфигурации.

Клиенты DHCP ответственны за доставку всех сообщений. Клиент должен адаптировать стратегию повторных передач, которая включает в себя экспоненциальный алгоритм вычисления псевдослучайных задержек между повторными пересылками. Задержки между повторными пересылками должны быть выбраны так, чтобы предоставить достаточно времени для ответов сервера с учетом условия связи между клиентом и сервером. Например, в сети 10Mбит/c Ethernet, задержка перед первой повторной посылкой должна быть случайным образом равномерно распределенной при среднем значении 4 секунды. Задержка следующей (второй) ретрансмиссии должна быть также случайной и составлять 8 секунд. Значения последовательных повторных передач должны при каждой последующей попытке удваиваться. Максимальное значение равно 64 секунд. Клиент может обеспечить для пользователя индикацию попыток повторной передачи.

Поле 'xid' используется клиентом для установления соответствия между приходящим DHCP-сообщением и отправленного ранее запросом. DHCP-клиент должен выбрать 'xid так чтобы минимизировать вероятность получения идентичных 'xid' разными клиентами. Например, клиент может выбирать разные, случайные начальные 'xid' каждый раз, когда клиент перезагружается, а далее использует инкрементацию этого значения при последующих передачах вплоть до следующей перезагрузки. Выбор нового 'xid' для каждой последующей повторной передачи относится на усмотрение конкретной программной реализации. Клиент может решить повторно использовать то же самое значение 'xid' или выбрать новый 'xid' для передачи каждого сообщения.

В норме, DHCP-серверы и агенты доставки BOOTP пытаются доставить сообщения DHCPOFFER, DHCPACK и DHCPNAK непосредственно клиенту, используя уникастную адресацию. IP-адрес места назначения (в IP-заголовке) равен адресу 'yiaddr', а адрес связного уровня равен 'chaddr'. К сожалению, некоторые реализации клиентов не могут получать уникастные IP-дейтограммы до тех пор, пока приложение не будет сконфигурировано и клиент не получит корректный IP-адрес (это ведет к тупику, когда IP-адрес не может быть получен клиентом до тех пор, пока в результате конфигурационного процесса он этот самый адрес не получит).

Клиент, который не может получать уникастные IP-дейтограммы, пока его протокольная программа не сконфигурирована, должен установить бит BROADCAST=1 в поле флагов в любом сообщении DHCPDISCOVER или DHCPREQUEST, которые клиент посылает. Бит BROADCAST укажет, что DHCP-сервер и агент транспортировки BOOTP должны посылать клиенту сообщения широковещательно. Клиент, который может получать уникастные IP-дейтограммы до того как его программа сконфигурирована, должен сделать бит BROADCAST равным 0.

Сервер или агент доставки, посылающие или передающие DHCP-сообщение непосредственно DHCP-клиенту (т.e., не агенту транспортировки, указанному в поле 'giaddr'), должны анализировать бит BROADCAST поля 'флаги'. Если этот бит равен 1, DHCP-сообщение должно быть послано как широковещательное по адресу 0xffffffff. Если бит BROADCAST равен 0, сообщение должно быть послано по уникастному IP-адресу указанному в поле 'yiaddr'. Если уникастная транспортировка невозможна, сообщение может быть послано по широковещательному адресу 0xffffffff.

DHCP-серверы не обязаны откликаться на каждое сообщение DHCPDISCOVER и DHCPREQUEST, которое они получают. Например, сетевой администратор с целью сохранения строгого контроля за клиентами, подключенными к сети, может захотеть сконфигурировать DHCP-серверы так, чтобы они реагировали только на клиентов, которые были зарегистрированы ранее с помощью некоторого внешнего механизма. Спецификация DHCP описывает только взаимодействие между клиентами и серверами, когда они хотят этого; описание административного контроля со стороны системного администратора находится вне пределов данной спецификации. Специальные реализации DHCP-серверов могут включать в себя любые механизмы административного контроля.

При некоторых условиях, DHCP-сервер будет должен проанализировать значения опций vendor class, включенные в сообщения DHCPDISCOVER или DHCPREQUEST с тем, чтобы определить корректные параметры для конкретного клиента.

DHCP-сервер должен использовать некоторый уникальный идентификатор, для того чтобы установить соответствие между клиентом и его набором конфигурационных параметров. Клиент может решить выдать идентификатор с помощью опции 'client identifier'. Если клиент предоставляет 'client identifier', он должен использовать его во всех последующих сообщениях, а сервер должен использовать этот идентификатор для распознавания клиента. Если клиент не предоставляет опцию 'client identifier', сервер должен для идентификации клиента использовать содержимое поля 'chaddr'. Для клиента DHCP весьма важно использовать уникальный идентификатор в пределах субсети, к которой он подключен согласно опции 'client identifier'. Использование 'chaddr' в качестве уникального идентификатора клиента может вызвать непредсказуемые результаты, так как такой идентификатор может быть ассоциирован с аппаратным интерфейсом, который может быть передан новому клиенту. Чтобы избежать непредсказуемых изменений сетевого адреса клиента (из-за переноса аппаратного интерфейса) некоторые узлы могут использовать в качестве идентификатора клиента серийный номер производителя. Сетевые узлы могут также использовать в качестве идентификатора клиента DNS-имя.

Клиенты DHCP вольны использовать любую стратегию при выборе DHCP-сервера из числа тех, список которых клиент получает в сообщении DHCPOFFER. Реализация клиента должна предоставлять для пользователя механизм выбора значений 'vendor class identifier'.

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

o DHCPDISCOVER
o DHCPREQUEST
o DHCPDECLINE
o DHCPRELEASE
o DHCPINFORM

В таблице 3 рассмотрено использование полей и опций в DHCP-сообщении сервера.

Когда сервер получает от клиента сообщение DHCPDISCOVER, он выбирает сетевой адрес для клиента, приславшего запрос. Если нет свободного адреса, сервер может проинформировать о проблеме системного администратора. Если адрес доступен, новый адрес должен быть выбран следующим образом:

o	Текущий адрес клиента, как это записано в текущем блоке параметров клиента, в противном случае
o	Предшествующий адрес клиента, как это записано в текущем блоке параметров клиента (срок действия которого истек или использование которого прекратилось), если этот адрес находится в пуле доступных адресов сервера, в противном случае
o	Адрес запрошенный в опции 'Запрошенный IP-адрес', если адрес корректен и еще не присвоен, в противном случае
o	Новый адрес, полученный из пула свободных адресов; адрес выбирается с учетом субсети, откуда получено сообщение (если 'giaddr' = 0) или с учетом адреса агента транспортировки, который доставил сообщение (когда 'giaddr' не равен 0).

Как это описано в разделе 4.2, сервер может, по административным причинам, присвоить адрес отличный от запрошенного, или может повторно использовать адрес для конкретного клиента, даже если имеются свободные адреса.

Заметим, что в некоторых сетевых архитектурах (например, в Интернет с более чем одной IP-субсетью, сопряженной с физическим сетевым сегментом), DHCP-клиенту должен быть присвоен адрес из другой субсети, а не адрес, записанный в 'giaddr'. Таким образом, DHCP не требует, чтобы клиенту был присвоен адрес из субсети 'giaddr'. Сервер волен выбрать какую-то другую субсеть. Механизм выбора IP-адреса находится вне пределов данной спецификации.

Если это не требуется для корректной работы DHCP, сервер не должен повторно использовать выбранный сетевой адрес, прежде чем клиент пришлет сообщение серверу DHCPOFFER. Сервер может решить записать этот адрес, как предложенный клиенту. Он должен также выбрать время действия конфигурационного набора, согласно следующим правилам:

Таблица 3. Поля и опции, используемые DHCP-серверами