Краткий обзор протокола
С точки зрения клиента, DHCP является расширением механизма BOOTP. Такая схема позволяет существующим BOOTP-клиентам успешно сотрудничать с DHCP-серверами без необходимости изменения стартовой программы клиента. В RFC-1542 [2] детализировано взаимодействие между BOOTP- и DHCP-клиентами и серверами [9]. Имеется несколько новых, опционных операций, которые оптимизируют взаимодействие между DHCP-клиентами и серверами (смотри разделы 3 и 4).
На рис. .1 представлен формат сообщения DHCP, а в таблице 1 перечислены поля этого сообщения. Числа в скобках указывают размер каждого из полей в октетах.
Существует два принципиальных отличия между DHCP и BOOTP. Во-первых, DHCP определяет механизмы, через которые клиентам на определенное время могут быть присвоены сетевые адреса, позволяя последовательное присвоение сетевого адреса различным клиентам. Во-вторых, DHCP предоставляет механизм, который позволяет клиенту получить все необходимые им для работы конфигурационные параметры.
DHCP вводит небольшое изменение в терминологию, имеющее целью прояснить значение одного из полей. Поле "vendor extensions" в BOOTP переименовано в поле "опции" в DHCP. Аналогично, помеченные информационные элементы, использованные в поле BOOTP "vendor extensions", которые именовались как "расширения производителя", теперь называются просто "опции".
| 0 | 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 | 9 | 10 | 11 | 12 | 13 | 14 | 15 | 16 | 17 | 18 | 19 | 20 | 21 | 22 | 23 | 24 | 25 | 26 | 27 | 28 | 29 | 30 | 31 |
| op (1) | htype (1) | hlen (1) | Шаги (1) | ||||||||||||||||||||||||||||
| xid (4) | |||||||||||||||||||||||||||||||
| secs (2) | Флаги (2) | ||||||||||||||||||||||||||||||
| ciaddr (4) | |||||||||||||||||||||||||||||||
| yiaddr (4) | |||||||||||||||||||||||||||||||
| siaddr (4) | |||||||||||||||||||||||||||||||
| chaddr (4) | |||||||||||||||||||||||||||||||
chaddr (16)
DHCP определяет новую опцию 'client identifier', которая используется для прямой передачи идентификатора клиента DHCP серверу. Это изменение исключает перегрузку поля 'chaddr' в сообщениях BOOTP, где 'chaddr' используется как в качестве аппаратного адреса для пересылки сообщений откликов BOOTP, так и в качестве идентификатора клиента. Идентификатор клиента представляет собой непрозрачный ключ, который не должен интерпретироваться сервером; например, идентификатор клиента может содержать аппаратный адрес, идентичный тому, который лежит в поле 'chaddr', или он может содержать другой идентификатор типа, такой как DNS-имя. Идентификатор клиента, выбранный DHCP клиентом, должен быть уникальным для субсети, к которой он подключен. Если клиент использует идентификатор клиента в одном сообщении, он должен использовать тот же идентификатор во всех последующих сообщениях, чтобы гарантировать корректную идентификацию клиента всеми серверами. DHCP определяет поле 'siaddr' как адрес сервера для использования во время следующего шага процесса начальной загрузки клиента. DHCP-сервер может прислать свой собственный адрес в поле 'siaddr', если сервер готов обеспечить последующую загрузку (например, доставку образа операционной системы). DHCP-сервер всегда присылает свой адрес в опции 'server identifier'. Назначения полей заголовка представлены в таблице 1.
Таблица 1. Описание полей сообщения DHCP
| Поле | Байт | Описание |
| op | 1 | Код операции сообщения / тип сообщения. |
| 1 | = BOOTREQUEST, 2 = BOOTREPLY | |
| htype | 1 | Тип аппаратного адреса, смотри раздел ARP в RFC "Assigned Numbers"; например, '1' для 10 мегабитного Ethernet. |
| Hlen | 1 | Длина аппаратного адреса (например, '6' для 10 мегабитного Ethernet). |
| Шаги | 1 | Клиент устанавливает это поле равным нулю, поле используется опционно агентами транспортировки, когда загрузка осуществляется через посредника. |
| Xid | 4 | ID-транзакции, случайное число, выбираемое клиентом, и используемое как клиентом, так и сервером для установления соответствия между запросами и откликами. |
| Secs | 2 |
Заполняется клиентом, число секунд с момента начала запроса адреса или рестарта процесса.
В случае, когда клиент использует 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 показан формат поля флаги.
| 0 | 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 | 9 | 10 | 11 | 12 | 13 | 14 | 15 |
B
MBZ: должно быть равно нулю (must be zero; зарезервировано на будущее)
Рис. .2: Формат поля 'флаги'
2.1. Основные конфигурационные параметры
Первым видом сервиса, предоставляемого DHCP, является запоминание сетевых параметров для клиента. Модель DHCP памяти характеризуется записями ключ - значение для каждого клиента, где ключ представляет собой некоторый уникальный идентификатор (например, номер IP-субсети и уникальный идентификатор в пределах субсети), а значение содержит набор конфигурационного параметров клиента.
Например, ключ может представлять собой пару (номер IP-субсети, аппаратный адрес), чтобы допустить повторное или даже одновременное применение одних и тех же аппаратных адресов в различных субсетях. Заметим, что должен быть определен тип "аппаратного адреса" с тем, чтобы можно было решить проблему возможного дублирования при изменении порядка бит в случае смешения типов оборудования. В качестве альтернативы, ключ может представлять собой пару (номер IP-субсети, имя ЭВМ), позволяя серверу присвоить параметры DHCP-клиенту, который переместился в другую субсеть или сменил свой аппаратный адрес (возможно из-за выхода из строя и замены сетевого интерфейса). Протокол определяет то, что ключ представляет собой (номер IP-субсети, аппаратный адрес), если только клиент не прелагает идентификатор в явном виде, используя опцию 'client identifier'. Клиент может запросить DHCP-сервис, чтобы получить свои конфигурационные параметры. Интерфейс клиента к депозитарию конфигурационных параметров реализуется с помощью протокольных сообщений запроса и откликов серверов, несущих в себе конфигурационные параметры.
2.2. Динамическое выделение сетевых адресов
Вторым видом сервиса, предоставляемым DHCP, является временное или постоянное выделение клиенту сетевого (IP) адреса. Основной механизм для динамического присвоения сетевых адресов достаточно прост: клиент запрашивает использование адреса на определенный период времени. Механизм выделения адреса (ассоциация DHCP-серверов) гарантирует, что адрес в течение оговоренного времени не будет использован для других целей, и пытается прислать тот же сетевой адрес всякий раз, когда клиент его запрашивает. Клиент может расширить это время последующими запросами. Клиент может послать серверу сообщение об освобождении адреса, когда клиент более не нуждается в этом адресе. Клиент может запросить постоянное присвоение адреса, потребовав бесконечное значение времени выделения адреса. Даже при "постоянном" выделении адресов, сервер может определить большой, но не бесконечный срок аренды адреса, чтобы позволить детектирование факта, что клиент перестал работать.
При некоторых обстоятельствах может оказаться необходимым повторно присваивать сетевые адреса из-за отсутствия свободных адресов. При таких условиях, механизм выделения будет повторно присваивать адреса, чье время действительности истекло. Сервер должен использовать информацию, которая доступна в конфигурационном депозитарии, чтобы выбрать адрес, который может быть использован повторно. Например, сервер может выбрать последний из присвоенных адресов. В качестве проверки совместимости сервер должен проверить повторно используемые адреса, прежде чем их повторно пускать в оборот. Это может быть, например, контроль посредством ICMP эхо-запроса, а клиент должен проверить вновь полученный адрес, например, посредством ARP.
3. Протокол клиент-сервер
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".
3.1. Взаимодействие клиента и сервера при выделении сетевого адреса
Ниже рассматривается протокольный обмен между клиентом и сервером DHCP-сообщениями, описанными в таблице 2. Временная диаграмма на рис. 3 демонстрирует типичную схему взаимодействия клиента и сервера. Если клиент уже знает свой адрес, некоторые шаги могут быть опущены; такое упрошенное взаимодействие описано в разделе 3.2.
| 1. |
Клиент широковещательно пересылает сообщение DHCPDISCOVER по локальной физической субсети. Сообщение DHCPDISCOVER может включать опции, которые предлагают значения для сетевого адреса и длительности его использования. Агент транспортировки BOOTP может передать сообщение 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.
| 6. | Клиент может решить отказаться от аренды сетевого адреса путем посылки серверу сообщения DHCPRELEASE. Клиент идентифицирует набор параметров, от которого он отказывается, с помощью своего идентификатора, или 'chaddr' и сетевого адреса в сообщении DHCPRELEASE. Если клиент использовал идентификатор клиента, когда он получил набор конфигурационных параметров, клиент должен использовать тот же идентификатор клиента (client identifier) в сообщении DHCPRELEASE. |
3.2. Взаимодействие клиента и сервера при повторном использовании ранее выделенных сетевых адресов
Если клиент помнит и желает использовать выделенный ранее сетевой адрес, он может опустить некоторые шаги, рассмотренные в предыдущем разделе. Временная диаграмма на рис. 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.
3.3. Интерпретация и представление значений времени
Клиент получает сетевой адрес на определенный период времени (который может быть бесконечным). В данном протоколе время измеряется в секундах. Значение времени 0xffffffff зарезервировано для обозначения бесконечности.
Так как клиент и сервер могут не иметь синхронизованных часов, значения времени в 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-сервером, клиент должен немедленно прекратить использование текущего сетевого адреса и может проинформировать о данной проблеме локального пользователя.
4. Спецификация протокола DHCP для системы клиент-сервер
В этом разделе, мы предполагаем, что DHCP-сервер имеет блок сетевых адресов, из которого он может удовлетворять запросы. Каждый сервер поддерживает базу данных присвоенных адресов и времен их действия.
4.1. Формирование и посылка сообщений 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.
4.2. Административное управление сервером DHCP
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'.
4.3. Поведение сервера DHCP
DHCP-сервер обрабатывает приходящие от клиента DHCP-сообщения на основе текущего состояния набора конфигурирующих параметров клиента. DHCP-сервер может получать от клиента следующие сообщения:
o DHCPDISCOVER
o DHCPREQUEST
o DHCPDECLINE
o DHCPRELEASE
o DHCPINFORM
В таблице 3 рассмотрено использование полей и опций в DHCP-сообщении сервера.
4.3.1. Сообщение DHCPDISCOVER
Когда сервер получает от клиента сообщение DHCPDISCOVER, он выбирает сетевой адрес для клиента, приславшего запрос. Если нет свободного адреса, сервер может проинформировать о проблеме системного администратора. Если адрес доступен, новый адрес должен быть выбран следующим образом:
| o |
Текущий адрес клиента, как это записано в текущем блоке параметров клиента, в противном случае
Заметим, что в некоторых сетевых архитектурах (например, в Интернет с более чем одной IP-субсетью, сопряженной с физическим сетевым сегментом), DHCP-клиенту должен быть присвоен адрес из другой субсети, а не адрес, записанный в 'giaddr'. Таким образом, DHCP не требует, чтобы клиенту был присвоен адрес из субсети 'giaddr'. Сервер волен выбрать какую-то другую субсеть. Механизм выбора IP-адреса находится вне пределов данной спецификации.
Если это не требуется для корректной работы DHCP, сервер не должен повторно использовать выбранный сетевой адрес, прежде чем клиент пришлет сообщение серверу DHCPOFFER. Сервер может решить записать этот адрес, как предложенный клиенту. Он должен также выбрать время действия конфигурационного набора, согласно следующим правилам:
| o | Если клиент не запросил специальный конфигурационный набор в сообщении DHCPDISCOVER и клиент уже имеет сетевой адрес, сервер присылает значение времени действия, ранее присвоенное данному адресу (заметим, что клиент должен явно запросить установления времени действия набора, чтобы переписать значение, ассоциированное с данным адресом), в противном случае |
| o | Если клиент не запросил определенное значение времени действия конфигурационного набора в сообщении DHCPDISCOVER и клиент не имеет сетевого адреса, сервер присваивает времени действия набора местное значение по умолчанию, в противном случае |
| o | Если клиент запросил специальный конфигурационный набор параметров в сообщении DHCPDISCOVER (вне зависимости оттого, имел ли он уже сетевой адрес), сервер может либо предоставить запрошенный набор (если это согласуется с местной политикой) или выбрать другой набор. |
Таблица 3. Поля и опции, используемые DHCP-серверами
| Поле | DHCPOFFER | DHCPACK | DHCPNAK |
| 'op' | BOOTREPLY | BOOTREPLY | BOOTREPLY |
| 'htype' | Из RFC "Assigned Numbers" | ||
| 'hlen' | Длина аппаратного адреса в октетах | ||
| 'hops' | 0 | 0 | 0 |
| 'xid' | 'xid' из сообщения клиента DHCPDISCOVER | 'xid' из сообщения клиента DHCPREQUEST | 'xid' из сообщения клиента DHCPREQUEST |
| 'secs' | 0 | 0 | 0 |
| 'ciaddr' | 0 | 'ciaddr' из DHCPREQUEST или 0 | 0 |
| 'yiaddr' | IP-адрес предложенный клиенту | IP-адрес присвоенный клиенту | 0 |
| 'siaddr' | IP-адрес следующего сервера загрузки | IP-адрес следующего сервера загрузки | 0 |
| 'flags' | 'flags' из сообщения клиента DHCPDISCOVER | флаги' из сообщения клиента DHCPREQUEST | 'flags' из сообщения клиента DHCPREQUEST |
| 'giaddr' | 'giaddr' из сообщения клиента DHCPDISCOVER | 'giaddr' из сообщения клиента DHCPREQUEST | 'giaddr' >из сообщения клиента DHCPREQUEST |
| 'chaddr' | 'chaddr' из сообщения клиента DHCPDISCOVER | 'chaddr' из сообщения клиента DHCPREQUEST | 'chaddr' из сообщения клиента DHCPREQUEST |
| 'sname' |
Имя ЭВМ сервера
или опции
или опции
имя или опции
имя или опции
| Опция | DHCPOFFER | DHCPACK | DHCPNAK |
| Запрошенный IP-адрес | не должен | не должен | не должен |
| IP-адрес lease time | должен |
должен (DHCPREQUEST)
не должен (DHCPINFORM)
Раз сетевой адрес и конфигурационный набор параметров определены, сервер формирует сообщение DHCPOFFER с предлагаемыми конфигурационными параметрами. Для всех DHCP-серверов важно прислать одни и те же параметры (с единственно возможным исключением - новым предлагаемым сетевым адресом), что гарантирует предсказуемое поведение клиента вне зависимости от того, какой из серверов он выберет. Конфигурация параметров должна быть выбрана согласно следующим правилам, представленным ниже. Сетевой администратор ответственен за конфигурацию всех DHCP-серверов, что гарантирует однородность откликов этих серверов. Сервер должен прислать клиенту:
| o | Сетевой адрес клиента, как это определено правилами приведенными выше, |
| o | Время действия клиентского набора, как это определено правилами из данного раздела, |
| o |
| o | Любые параметры из существующего набора, которые отличаются от значений по умолчанию документа Host Requirements, |
| o | Любые параметры, специфичные для клиента (как это с пецифицировано в содержимом 'chaddr' или 'client identifier' сообщения DHCPDISCOVER или DHCPREQUEST), например, сконфигурированные сетевым администратором, |
| o | Любые параметры специфичные для этого класса клиента (как это идентифицировано в опции 'vendor class identifier' сообщения DHCPDISCOVER или DHCPREQUEST), например, сконфигурированные сетевым администратором; |
| o | Параметры со значениями, неравными величинам по умолчанию для клиентской субсети. |
