на каком уровне работает протокол dhcp
На каком уровне работает протокол dhcp
DHCP (англ. Dynamic Host Configuration Protocol — протокол динамической настройки узла) — сетевой протокол, позволяющий компьютерам автоматически получать IP-адрес и другие параметры, необходимые для работы в сети.
Был предложен в 1993 г., и наиболее полное современное описание DHCP содержится в документе RFC 2131 (март 1997 г.).
DHCP является расширением протокола BOOTP, использовавшегося ранее для обеспечения бездисковых рабочих станций IP-адресами при их загрузке, и сохраняет с ним обратную совместимость.
Цель DHCP — устранить два основных ограничения, накладывающихся на другие анагологичные протоколы, а именно: отсутствие поддержки динамического назначения IP-адресов и возможность передавать от сервера на станцию-клиент лишь небольшое число параметров конфигурации.
Содержание
Архитектура [ править ]
Работа протокола DHCP базируется на классической схеме клиент-сервер.
Сервер поддерживает пул свободных адресов и, кроме того, ведет собственную регистрационную базу данных.
Сообщения [ править ]
Взаимодействие DHCP-серверов с клиентами осуществляется путем обмена сообщениями.
Структура сообщения показана на рисунке, где в скобках указан размер поля в байтах.
Опишем подробнее поля:
| Поле | Описание |
|---|---|
| op | Тип сообщения (1 = BOOTREQUEST, 2 = BOOTREPLY) |
| htype | Тип адреса оборудования |
| hlen | Длина адреса оборудования |
| hops | Используется ретранслирующим агентом |
| xid | Идентификатор транзакции между сервером и клиентом |
| secs | Время с момента выдачи DHCPREQUEST или начала обновления конфигурации |
| flags | Флаги (первый бит маркирует широковещательные сообщения) |
| ciaddr | IP-адрес клиента |
| yiaddr | (клиентский) IP-адрес |
| siaddr | IP-адрес следующего сервера, участвующего в загрузке |
| giaddr | IP-адрес ретранслирующего агента |
| chaddr | адрес клиента |
| sname | Хост-имя сервера (опция) |
| file | Имя загрузочного файла |
| options | Поле дополнительных параметров |
В роли транспортного протокола для обмена DHCP-сообщениями выступает UDP.
Эти номера портов, как и схожая структура сообщений, обеспечивают обратную совместимость DHCP с BOOTP. Конкретные процедуры взаимодействия клиентов и серверов BOOTP и DHCP регламентирует документ RFC 1542.
Алгоритм работы [ править ]
Получение IP адреса [ править ]
Выбор адреса DHCP-сервером [ править ]
Алгоритм работы DHCP-сервера при получении DHCPDISCOVER:
Следует отметить, что сервер не обязан отвечать на каждый поступивший запрос DHCPDISCOVER. Такой подход дает возможность управления использованием сети: например, можно разрешить серверу отвечать только тем клиентам, которые предварительно зарегистрировались с помощью специальной процедуры.
Истечение срока аренды адреса [ править ]
Когда срок аренды адреса подходит к концу клиент может:
Параметры конфигурации [ править ]
Для каждого клиента DHCP-сервер заводит в своей базе запись с параметрами конфигурации. Каждой записи соответствует уникальный ключ (например, ). Поддерживаемые параметры конфигурации определены в RFC 1122, RFC 1123, RFC 1196, RFC 1256.
Наиболее важные параметры:
Передача параметров конфигурации происходит в процессе получения IP-адреса. Если на клиенте адрес был задан вручную, то он отправляет сообщение DHCPINFORM, содержащее уже имеющийся адрес и запрос об отдельных параметрах конфигурации. DHCP-сервер проверяет правильность адреса клиента (но не наличие аренды) и отправляет DHCPACK с требуемыми параметрами конфигурации.
Записки IT специалиста
Технический блог специалистов ООО»Интерфейс»
Как устроен и работает протокол DHCP
В современных сетях служба DHCP является одной из базовых, обеспечивая автоматическую настройку сетевых параметров у клиентов и от правильности ее работы зависит надежное функционирование всей сети. Поэтому важно иметь хотя бы базовые представления о работе одноименного протокола, что позволит не только грамотно подойти к настройке, но и оперативно устранить возможные проблемы. Тем более что протокол DHCP достаточно прост и разобраться в нем может каждый, достаточно иметь начальные знания о работе сетей.
Получение адреса
Рассмотрим процесс получения IP-адреса, он достаточно прост и состоит из четырех этапов, которые в упрощенном виде показаны на следующей схеме:
Все это можно увидеть, если заглянуть внутрь DHCP-пакета:
В данном случае это запрос обнаружения (Discover), цветом мы отметили упоминавшиеся выше поля и опции. Вроде бы все просто, но есть некоторые моменты, которые обычно обходятся молчанием, но способны вызвать определенные затруднения от неверного их понимания.
Запрос обнаружения рассылается для всех узлов сети, но отвечают на него только DHCP-сервера, формируя сообщение Предложения DHCP (DHCP OFFER), которое содержит предлагаемую сервером сетевую конфигурацию. Если серверов несколько, то предложений клиент получит несколько. Из предложенных конфигураций клиент выбирает одну, как правило полученную первой. Предлагаемый клиенту адрес содержится в специальном поле yiaddr, а поле siaddr передается адрес DHCP-сервера.
Так как MAC-адрес отправителя известен, то сервер направляет ответ непосредственно клиенту (unicast), хотя в некоторых случаях может ответить и широковещательным пакетом. Например, DHCP-сервера dnsmasq и Mikrotik отвечает непосредственно клиенту (юникастом), в то время как DHCP Windows Server отвечает широковещательным пакетом. По большому счету это не имеет особого значения, просто вы должны знать, что это вполне допустимые режимы работы DHCP-сервера и не являются признаком неправильной работы.
В структуре ответа мы также отметили цветом вышеописанные опции, также обратите внимание, что в данном случае ответ был отправлен широковещательным пакетом (Windows Server). Ниже показана структура ответа dnsmasq:
Здесь видно, что сервер ответил непосредственно клиенту (отправив фрейм на его MAC-адрес), не прибегая к широковещательной рассылке.
Остальные сетевые параметры передаются в виде опций, в нашем случае это опции 1, 3 и 6 (маска, шлюз, DNS):
Приняв предложение клиент официально запрашивает у сервера данную конфигурацию, для чего отправляет широковещательно Запрос DHCP (DHCP REQUEST), он полностью повторяет по структуре сообщение обнаружения (Discover), только добавляет к нему опцию 54 с адресом сервера, конфигурацию которого клиент принял. Опция 50 содержит предложенный сервером IP-адрес. Несмотря на то, что MAC-адрес DHCP-сервера известен, запрос (Request) рассылается широковещательно, это нужно для того, чтобы остальные DHCP-сервера понимали, что их предложение отвергнуто.
Выше показана структура запроса, можете сравнить его с пакетом обнаружения, обратите внимание на заполненное значение опции 54.
Получив запрос сервер направляет клиенту в ответ Подтверждение DHCP (DHCP ACK), которое отправляется на MAC-адрес клиента (хотя может и широковещательно) и получив которое клиент должен настроить свой сетевой адаптер согласно указанного адреса и опций.
По структуре сообщение подтверждения (Ask) практически не отличается от предложения (Offer), за исключением того, что поле siaddr с адресом DHCP-сервера не заполняется, но его адрес передается в опции 54.
Получив адрес клиент может проверить его на предмет использования при помощи широковещательного ARP-запроса (в большинстве реализаций так и происходит) и если будет обнаружено, что выделенный адрес уже используется (скажем, назначен вручную), то клиент посылает широковещательное сообщение Отказа DHCP (DHCP DECLINE) и начинает процесс получения адреса заново. Сервер, получив сообщение отказа, должен пометить указанный адрес как недоступный и уведомить администратора о возможной проблеме в конфигурации (например, записью в логе).
Также клиент может самостоятельно отказаться от выданного адреса, отправив серверу сообщение Освобождения DHCP (DHCP RELEASE), в отличии от других сообщений, освобождение направляется юникастом серверу, выдавшему адрес. Получив такое сообщение сервер помечает адрес как доступный, но на всякий случай оставляет запись о клиенте, если он захочет получить адрес повторно. Это поведение не является обязательным, но реализовано в большинстве DHCP-серверов.
Обновление адреса
В зависимости от срока прошедшего с момента получения адреса клиент может находится в одном из нескольких состояний.
Для этого он отправляет сообщение запроса (Request), в котором указывает текущий IP-адрес. Если сервер подтверждает аренду, то отвечает сообщением подтверждения (Ask), клиент сбрасывает счетчики T1 и T2 и начинает отсчет срока аренды заново.
Данные о сроке аренды и времени обновления адреса и обновлении конфигурации передаются сервером в опциях 51, 58 и 59:
Если сервер не ответил клиенту, то он берет промежуток времени до окончания состояния обновления и делит его пополам, в это время будет отправлен повторный запрос, при его отсутствии промежуток времени снова будет поделен пополам, потом снова пополам, при этом полученный промежуток времени не может быть меньше 60 сек. Таким образом, чем ближе окончание срока обновления, тем чаще будут делаться запросы.
После наступления момента времени T2, если клиенту не удалось обновить адрес, он переходит в состояние обновления Обновления конфигурации (REBINDING). В этом случае он посылает сообщение Обнаружения DHCP, теперь клиенту может ответить любой DHCP-сервер, а не только тот, который выдал IP-адрес. Если ответа от сервера не было, то оставшееся время также делится пополам и запрос повторяется. Все это время клиент может продолжать пользоваться уже полученной сетевой конфигурацией и нормально работать.
Если же до окончания срока аренды ответ так и не был получен, то клиент прекращает все сетевые операции и переходит в состояние Инициализации (INIT). В последствии, при получении предложений (Offer) от различных серверов клиент предпочтет выбрать предложение от сервера, который выдавал ему адрес прошлый раз и продолжит пользоваться старым адресом.
Также при обновлении могут быть иные сценарии развития событий. Скажем, клиент был включен в другую подсеть. В этом случае при получении запроса DHCP (клиент не знает, что он в другой подсети и пытается продлить аренду) сервер определяет неподходящий адрес в запросе и отвечает ему сообщением Отмены DHCP (DHCP NAK), после чего клиент должен начать процедуру получения адреса заново.
Если сеть клиента корректна, но запрашиваемый адрес занят, то сервер также ответит сообщением отмены (Nak) и клиент начнет получение адреса повторно.
Получение дополнительной информации
Если клиент имеет статически назначенный IP-адрес, но хочет получить дополнительные параметры, скажем адрес серверов имен или статические маршруты, то он отправляет специальное широковещательное сообщение Информации DHCP (DHCP INFORM), в ответ сервера отправляют сообщение подтверждения (Ask) без выделения IP-адреса.
Помогла статья? Поддержи автора и новые статьи будут выходить чаще:
Или подпишись на наш Телеграм-канал: 
Национальная библиотека им. Н. Э. Баумана
Bauman National Library
Персональные инструменты
DHCP (Dynamic Host Configuration Protocol)
| Уровень (по модели OSI): | Прикладной |
|---|---|
| Семейство: | стек протоколов TCP/IP |
| Порт/ID: | 67, 68/UDP |
| Назначение протокола: | Получение сетевой конфигурации |
| Спецификация: | RFC 2131 |
| Основные реализации (серверы): | dhcpd, ISC DHCP Server, Infoblox |
| Вступил в силу с: | 1990 |
DHCP (англ. Dynamic Host Configuration Protocol — протокол динамической настройки узла) — сетевой протокол, позволяющий компьютерам автоматически получать IP-адрес и другие параметры, необходимые для работы в сети TCP/IP. Данный протокол работает по модели «клиент-сервер». Для автоматической конфигурации компьютер-клиент на этапе конфигурации сетевого устройства обращается к так называемому серверу DHCP и получает от него нужные параметры. Сетевой администратор может задать диапазон адресов, распределяемых сервером среди компьютеров. Это позволяет избежать ручной настройки компьютеров сети и уменьшает количество ошибок. Протокол DHCP используется в большинстве сетей TCP/IP.
DHCP является расширением протокола BOOTP (Bootstrap Protocol), использовавшегося ранее для обеспечения беpдисковых рабочих станций IP-адресами при их загрузке. DHCP сохраняет обратную совместимость с BOOTP.
Содержание
История
Стандарт протокола DHCP был принят в октябре 1993 года. Действующая версия протокола (март 1997 года) описана в RFC 2131. Новая версия DHCP, предназначенная для использования в среде IPv6, носит название DHCPv6 и определена в RFC 3315 (июль 2003 года).
Распределение IP-адресов
Протокол DHCP предоставляет три способа распределения IP-адресов:
Некоторые реализации службы DHCP способны автоматически обновлять записи DNS, соответствующие клиентским компьютерам, при выделении им новых адресов. Это производится при помощи протокола обновления DNS, описанного в RFC 2136.
Опции DHCP
Помимо IP-адреса, DHCP также может сообщать клиенту дополнительные параметры, необходимые для нормальной работы в сети. Эти параметры называются опциями DHCP. Список стандартных опций можно найти в RFC 2132.
Некоторыми из наиболее часто используемых опций являются:
Некоторые поставщики программного обеспечения могут определять собственные дополнительные опции DHCP.
В следующих таблицах перечислены доступные DHCP опции, как указано в RFC2132:
| Код | Название | Длина | Примечание |
|---|---|---|---|
| 0 | Pad | 0 октетов | Используется для дополнения других опций, чтобы они выравнивались по границе слова. |
| 1 | Subnet Mask | 4 октета | Должн быть отправлен после опции “router” (опция 3), если оба включены. |
| 2 | Time Offset | 4 октета | |
| 3 | Router | кратное 4 октетам | Доступные маршрутизаторы должны быть перечислены в порядке предпочтения. |
| 4 | Time Server | кратное 4 октетам | Доступные серверы для синхронизации должны быть перечислены в порядке предпочтения. |
| 5 | Name Server | кратное 4 октетам | Доступные IEN 116 – имена серверов, должны быть перечислены в порядке предпочтения. |
| 6 | Domain Name Server | кратное 4 октетам | Доступные DNS-сервера должны быть перечислены в порядке предпочтения. |
| 7 | Log Server | кратное 4 октетам | Доступные Log–сервера должны быть перечислены в порядке предпочтения. |
| 8 | Cookie Server | кратное 4 октетам | |
| 9 | LPR Server | кратное 4 октетам | |
| 10 | Impress Server | кратное 4 октетам | |
| 11 | Resource Location Server | кратное 4 октетам | |
| 12 | Host Name | минимум 1 октет | |
| 13 | Boot File Size | 2 октета | Длина загрузочного образа в 4-килобайтных блоках. |
| 14 | Merit Dump File | минимум 1 октет | Путь до места хранения аварийных дампов. |
| 15 | Domain Name | минимум 1 октет | |
| 16 | Swap Server | 4 октета | |
| 17 | Root Path | минимум 1 октет | |
| 18 | Extensions Path | минимум 1 октет | |
| 255 | End | 0 октетов | Используется для обозначения конца поля. |
|
|
|
|
|
|
Идентификация поставщика.
Опция существует, чтобы определить поставщика и функциональность клиента DHCP. Информация представляется строкой переменной длины, состоящей из символов или октетов, которые имеют значение, указанное поставщиком клиента DHCP. Один из методов позволяет DHCP клиенту оповещать сервер о том, что он использует определенный тип низкоуровневого обеспечения или прошивки для заполнения опции Vendor Class Identifier(VCI)(опция 60). Этот метод позволяет различать запросы клиентских машин и процессов. Значение опции VCI дает DHCP-серверу подсказку о любой необходимой дополнительной информации, которую необходимо отправить клиенту в ответ.
Устройство протокола
Протокол DHCP является клиент-серверным, то есть в его работе участвуют клиент DHCP и |сервер DHCP. Передача данных производится при помощи протокола UDP. По умолчанию запросы от клиента делаются на 67 порт к серверу, сервер в свою очередь отвечает на порт 68 к клиенту, выдавая адрес IP и другую необходимую информацию, такую, как сетевую маску, маршрутизатор и серверы DNS.
Структура сообщений DHCP
Все сообщения протокола DHCP разбиваются на поля, каждое из которых содержит определённую информацию. Все поля, кроме последнего (поля опций DHCP), имеют фиксированную длину.
| Поле | Описание | Длина (в байтах) |
|---|---|---|
| op | Тип сообщения. Например может принимать значения: BOOTREQUEST (1, запрос от клиента к серверу) и BOOTREPLY (2, ответ от сервера к клиенту). | 1 |
| htype | Тип аппаратного адреса. Допустимые значения этого поля определены в RFC1700 «Assigned Numbers». Например, для MAC-адреса Ethernet 10 Мбит/с это поле принимает значение 1. | 1 |
| hlen | Длина аппаратного адреса в байтах. Для MAC-адреса Ethernet — 6. | 1 |
| hops | Количество промежуточных маршрутизаторов (так называемых агентов ретрансляции DHCP), через которые прошло сообщение. Клиент устанавливает это поле в 0. | 1 |
| xid | Уникальный идентификатор транзакции, генерируемый клиентом в начале процесса получения адреса. | 4 |
| secs | Время в секундах с момента начала процесса получения адреса. Может не использоваться (в этом случае оно устанавливается в 0). | 2 |
| flags | Поле для флагов — специальных параметров протокола DHCP. | 2 |
| ciaddr | IP-адрес клиента. Заполняется только в том случае, если клиент уже имеет собственный IP-адрес и способен отвечать на запросы ARP (это возможно, если клиент выполняет процедуру обновления адреса по истечении срока аренды). | 4 |
| yiaddr | Новый IP-адрес клиента, предложенный сервером. | 4 |
| siaddr | IP-адрес сервера. Возвращается в предложении DHCP (см. ниже). | 4 |
| giaddr | IP-адрес агента ретрансляции, если таковой участвовал в процессе доставки сообщения DHCP до сервера. | 4 |
| chaddr | Аппаратный адрес (обычно MAC-адрес) клиента. | 16 |
| sname | Необязательное имя сервера в виде нуль-терминированной строки. | 64 |
| file | Необязательное имя файла на сервере, используемое бездисковыми рабочими станциями при удалённой загрузке. Как и sname, представлено в виде нуль-терминированной строки. | 128 |
| options | Поле опций DHCP. Здесь указываются различные дополнительные параметры конфигурации. В начале этого поля указываются четыре особых байта со значениями 99, 130, 83, 99 («волшебные числа»), позволяющие серверу определить наличие этого поля. Поле имеет переменную длину, однако DHCP-клиент должен быть готов принять DHCP-сообщение длиной в 576 байт (в этом сообщении поле options имеет длину 340 байт). | переменная |
Пример процесса получения адреса
Рассмотрим пример процесса получения IP-адреса клиентом от сервера DHCP. Предположим, клиент ещё не имеет собственного IP-адреса, но ему известен его предыдущий адрес — 192.168.1.100. Процесс состоит из четырёх этапов.
Обнаружение DHCP
Вначале клиент выполняет широковещательный запрос по всей физической сети с целью обнаружить доступные DHCP-серверы. Он отправляет сообщение типа DHCPDISCOVER, при этом в качестве IP-адреса источника указывается 0.0.0.0 (так как компьютер ещё не имеет собственного IP-адреса), а в качестве адреса назначения — широковещательный адрес 255.255.255.255.
Клиент заполняет несколько полей сообщения начальными значениями:
Сообщение DHCPDISCOVER может быть распространено за пределы локальной физической сети при помощи специально настроенных агентов ретрансляции DHCP, перенаправляющих поступающие от клиентов сообщения DHCP серверам в других подсетях.
Не всегда процесс получения IP адреса начинается с DHCPDISCOVER. В случае, если клиент ранее уже получал IP адрес и срок его аренды ещё не прошёл — клиент может пропустить стадию DHCPDISCOVER, начав с запроса DHCPREQUEST отправляемого с идентификатором сервера, который выдал адрес в прошлый раз. В случае же отсутствия ответа от DHCP сервера, выдавшего настройки в прошлый раз, клиент отправляет DHCPDISCOVER. Тем самым клиент начинает процесс получения с начала, обращаясь уже ко всем DHCP серверам в сегменте сети.
Предложение DHCP
Получив сообщение от клиента, сервер определяет требуемую конфигурацию клиента в соответствии с указанными сетевым администратором настройками. В данном случае DHCP-сервер согласен с запрошенным клиентом адресом 192.168.1.100. Сервер отправляет ему ответ (DHCPOFFER), в котором предлагает конфигурацию. Предлагаемый клиенту IP-адрес указывается в поле yiaddr. Прочие параметры (такие, как адреса маршрутизаторов и DNS-серверов) указываются в виде опций в соответствующем поле.
Это сообщение DHCP-сервер отправляет хосту, пославшему DHCPDISCOVER, на его MAC, при определенных обстоятельствах сообщение может распространяться как широковещательная рассылка. Клиент может получить несколько различных предложений DHCP от разных серверов; из них он должен выбрать то, которое его «устраивает».
Запрос DHCP
Выбрав одну из конфигураций, предложенных DHCP-серверами, клиент отправляет запрос DHCP (DHCPREQUEST). Он рассылается широковещательно; при этом к опциям, указанным клиентом в сообщении DHCPDISCOVER, добавляется специальная опция — идентификатор сервера — указывающая адрес DHCP-сервера, выбранного клиентом (в данном случае — 192.168.1.1).
Подтверждение DHCP
Наконец, сервер подтверждает запрос и направляет это подтверждение (DHCPACK) клиенту. После этого клиент должен настроить свой сетевой интерфейс, используя предоставленные опции.
Вид сообщений
Ниже приведены значения каждого поля для каждого из отправляемых в процессе сообщений DHCP.
|
|
|
| ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Прочие сообщения DHCP
Помимо сообщений, необходимых для первоначального получения IP-адреса клиентом, DHCP предусматривает несколько дополнительных сообщений для выполнения иных задач.
Отказ DHCP
Если после получения подтверждения (DHCPACK) от сервера клиент обнаруживает, что указанный сервером адрес уже используется в сети, он рассылает широковещательное сообщение отказа DHCP (DHCPDECLINE), после чего процедура получения IP-адреса повторяется. Использование IP-адреса другим клиентом можно обнаружить, выполнив запрос ARP.
Сообщение отмены DHCP (DHCPNAK). При получении такого сообщения соответствующий клиент должен повторить процедуру получения адреса.
Освобождение DHCP
Клиент может явным образом прекратить аренду IP-адреса. Для этого он отправляет сообщение освобождения DHCP (DHCPRELEASE) тому серверу, который предоставил ему адрес в аренду. В отличие от других сообщений DHCP, DHCPRELEASE не рассылается широковещательно.
Информация DHCP
Сообщение информации DHCP (DHCPINFORM) предназначено для определения дополнительных параметров стек протоколов TCP/IP|TCP/IP (например, адреса маршрутизатора по умолчанию, DNS-серверов и т. п.) теми клиентами, которым не нужен динамический IP-адрес (то есть адрес которых настроен вручную). Серверы отвечают на такой запрос сообщением подтверждения (DHCPACK) без выделения IP-адреса.
Реализации
Компания Microsoft впервые включила сервер DHCP в поставку серверной версии Windows NT 3.5, выпущенной в 1994 году. Начиная с Windows 2000 Server реализация DHCP-сервера от Microsoft позволяет динамически обновлять записи DNS, что используется в Active Directory.
Internet Systems Consortium выпустил первую версию ISC DHCP Server (для Unix-подобных систем) 6 декабря 1997 года. 22 июня 1999 года вышла версия 2.0, более точно соответствующая стандарту.
Компания Cisco включила сервер DHCP в Cisco IOS 12.0 в феврале 1999 года. (Sun) Sun Microsystems добавила DHCP-сервер в Solaris 8 в июле 2001 года.
В настоящее время существуют реализации сервера DHCP для ОС Windows в виде отдельных программ, в том числе открытых, позволяющих выполнять роль сервера DHCP компьютерам под управлением не серверных версий данной ОС.