Протокол динамической конфигурации хоста ( DHCP ) - это протокол управления сетью, используемый в сетях Интернет-протокола (IP) для автоматического назначения IP-адресов и других параметров связи устройствам, подключенным к сети с использованием архитектуры клиент-сервер . [1]
Технология устраняет необходимость индивидуальной настройки сетевых устройств вручную и состоит из двух сетевых компонентов, централизованно установленного сетевого DHCP- сервера и клиентских экземпляров стека протоколов на каждом компьютере или устройстве. При подключении к сети и периодически в дальнейшем клиент запрашивает набор параметров у DHCP-сервера, используя протокол DHCP.
DHCP может быть реализован в сетях размером от жилых сетей до крупных кампусных сетей и региональных сетей Интернет-провайдеров. [2] Многие маршрутизаторы и домашние шлюзы имеют возможность сервера DHCP. Большинство маршрутизаторов домашних сетей получают уникальный IP-адрес в сети Интернет-провайдера. В локальной сети сервер DHCP назначает каждому устройству локальный IP-адрес.
Службы DHCP существуют для сетей, использующих протокол Интернета версии 4 (IPv4), а также версии 6 ( IPv6 ). Версия протокола DHCP для IPv6 обычно называется DHCPv6 .
История
В 1984 году был введен протокол обратного разрешения адресов (RARP), определенный в RFC 903, чтобы позволить простым устройствам, таким как бездисковые рабочие станции, динамически получать подходящий IP-адрес. Однако, поскольку он действовал на уровне канала данных, это затрудняло реализацию на многих серверных платформах, а также требовало, чтобы сервер присутствовал на каждом отдельном сетевом канале. RARP был заменен протоколом начальной загрузки ( BOOTP ), определенным в RFC 951 в сентябре 1985 года. В нем была представлена концепция агента ретрансляции , который позволял пересылать пакеты BOOTP по сетям, позволяя одному центральному серверу BOOTP обслуживать хосты во многих IP-подсетях. [3]
DHCP основан на BOOTP, но может динамически выделять IP-адреса из пула и восстанавливать их, когда они больше не используются. Его также можно использовать для доставки широкого спектра дополнительных параметров конфигурации IP-клиентам, включая параметры, специфичные для платформы. [4] Протокол DHCP был впервые определен в RFC 1531 в октябре 1993 года, но из-за ошибок в редакционном процессе был почти сразу переиздан как RFC 1541.
Четыре года спустя тип сообщения DHCPINFORM [5] и другие небольшие изменения были добавлены в RFC 2131; которые по состоянию на 2014 год[Обновить] остается стандартом для сетей IPv4.
Первоначально DHCPv6 был описан в RFC 3315 в 2003 году, но он был обновлен во многих последующих RFC. [6] RFC 3633 добавил механизм DHCPv6 для делегирования префикса , а автоконфигурация адреса без сохранения состояния была добавлена RFC 3736.
Обзор
Интернет-протокол (IP) определяет, как устройства взаимодействуют внутри и между локальными сетями в Интернете. DHCP-сервер может управлять настройками IP для устройств в своей локальной сети, например, назначая этим устройствам IP-адреса автоматически и динамически.
DHCP работает по модели клиент-сервер . Когда компьютер или другое устройство подключается к сети, программное обеспечение DHCP-клиента отправляет широковещательный запрос DHCP, запрашивая необходимую информацию. Любой DHCP-сервер в сети может обслуживать запрос. DHCP-сервер управляет пулом IP-адресов и информацией о параметрах конфигурации клиента, таких как шлюз по умолчанию , имя домена , серверы имен и серверы времени . При получении запроса DHCP сервер DHCP может ответить конкретной информацией для каждого клиента, как это было ранее настроено администратором, или конкретным адресом и любой другой информацией, действительной для всей сети и в течение периода времени, на который выделено ( аренда ) действует. DHCP-клиент обычно запрашивает эту информацию сразу после загрузки и периодически после этого до истечения срока действия информации. Когда DHCP-клиент обновляет назначение, он первоначально запрашивает те же значения параметров, но DHCP-сервер может назначить новый адрес на основе политик назначения, установленных администраторами.
В больших сетях, состоящих из нескольких каналов, один DHCP-сервер может обслуживать всю сеть при помощи агентов ретрансляции DHCP, расположенных на соединяющихся маршрутизаторах. Такие агенты ретранслируют сообщения между DHCP-клиентами и DHCP-серверами, расположенными в разных подсетях.
В зависимости от реализации DHCP-сервер может иметь три метода выделения IP-адресов:
- Динамическое размещение
- А администратор сети резервирует диапазон от IP - адресов для DHCP, и каждый клиент DHCP на LAN сконфигурирован , чтобы запросить IP - адрес от DHCP - сервера во время инициализации сети. В процессе запроса и предоставления используется концепция аренды с контролируемым периодом времени, позволяющая DHCP-серверу восстанавливать, а затем перераспределять IP-адреса, которые не обновляются.
- Автоматическое распределение
- Сервер DHCP постоянно назначает запрашивающему клиенту IP-адрес из диапазона, определенного администратором. Это похоже на динамическое распределение, но DHCP-сервер хранит таблицу прошлых назначений IP-адресов, так что он может предпочтительно назначать клиенту тот же IP-адрес, который был у клиента ранее.
- Распределение вручную
- Этот метод также называют по- разному статическим распределением DHCP , фиксированным распределением адресов , резервированием и привязками MAC / IP - адрес . Администратор сопоставляет уникальный идентификатор (идентификатор клиента или MAC-адрес ) каждого клиента с IP-адресом, который предлагается запрашивающему клиенту. DHCP-серверы могут быть настроены на использование других методов в случае сбоя.
Службы DHCP используются для Интернет-протокола версии 4 (IPv4) и IPv6 . Детали протокола для IPv4 и IPv6 существенно различаются, поэтому их можно рассматривать как отдельные протоколы. [7] Для работы IPv6 устройства могут альтернативно использовать автоконфигурацию адреса без сохранения состояния . Узлы IPv6 могут также использовать локальную адресацию канала для выполнения операций, ограниченных локальной сетью.
Операция
DHCP использует модель обслуживания без установления соединения с использованием протокола дейтаграмм пользователя (UDP). Он реализован с двумя номерами портов UDP для своих операций, которые такие же, как для протокола начальной загрузки ( BOOTP ). UDP-порт номер 67 является портом назначения сервера, а UDP-порт номер 68 используется клиентом.
Операции DHCP делятся на четыре фазы: обнаружение сервера, предложение аренды IP, запрос аренды IP и подтверждение аренды IP. Эти этапы часто обозначаются аббревиатурой DORA для обнаружения, предложения, запроса и подтверждения.
Работа DHCP начинается с того, что клиенты рассылают запрос. Если клиент и сервер находятся в разных подсетях, можно использовать вспомогательную функцию DHCP или агент DHCP-ретрансляции . Клиенты, запрашивающие продление существующей аренды, могут общаться напрямую через одноадресную рассылку UDP , поскольку в этот момент у клиента уже есть установленный IP-адрес. Кроме того, есть флаг BROADCAST (1 бит в 2-байтовом поле флагов, где все остальные биты зарезервированы и поэтому установлены на 0), который клиент может использовать, чтобы указать, каким способом (широковещательный или одноадресный) он может получить DHCPOFFER: 0x8000 для широковещательной рассылки, 0x0000 для одноадресной рассылки. [8] Обычно DHCPOFFER отправляется одноадресной рассылкой. Для тех хостов, которые не могут принимать одноадресные пакеты до настройки IP-адресов, этот флаг можно использовать для решения этой проблемы.
Открытие
Клиент DHCP передает сообщение DHCPDISCOVER в сетевой подсети, используя адрес назначения 255.255.255.255 (ограниченная широковещательная рассылка) или адрес широковещательной рассылки конкретной подсети (направленная широковещательная рассылка). Клиент DHCP также может запросить свой последний известный IP-адрес. Если клиент остается подключенным к той же сети, сервер может удовлетворить запрос. В противном случае это зависит от того, настроен ли сервер как авторитетный или нет. Полномочный сервер отклоняет запрос, в результате чего клиент отправляет новый запрос. Неавторизованный сервер просто игнорирует запрос, что приводит к зависящему от реализации тайм-ауту для клиента, чтобы истечь срок действия запроса и запросить новый IP-адрес.
Например, если HTYPE установлен в 1, чтобы указать, что используемый носитель является Ethernet , HLEN устанавливается в 6, потому что адрес Ethernet (MAC-адрес) имеет длину 6 октетов. CHADDR устанавливается на MAC-адрес, используемый клиентом. Также установлены некоторые параметры.
Ethernet: источник = MAC-адрес отправителя; пункт назначения = FF: FF: FF: FF: FF: FF | |||
IP: источник = 0.0.0.0; назначение = 255.255.255.255 | |||
Октет 0 | Октет 1 | Октет 2 | Октет 3 |
---|---|---|---|
OP | HTYPE | HLEN | Хмель |
0x01 | 0x01 | 0x06 | 0x00 |
XID | |||
0x3903F326 | |||
СЕКУНДЫ | ФЛАГИ | ||
0x0000 | 0x0000 | ||
CIADDR (IP-адрес клиента) | |||
0x00000000 | |||
YIADDR (Ваш IP-адрес) | |||
0x00000000 | |||
SIADDR (IP-адрес сервера) | |||
0x00000000 | |||
GIADDR (IP-адрес шлюза) | |||
0x00000000 | |||
CHADDR (аппаратный адрес клиента) | |||
0x00053C04 | |||
0x8D590000 | |||
0x00000000 | |||
0x00000000 | |||
192 октета нулей или переполнение пространства для дополнительных опций; Наследие BOOTP . | |||
Волшебное печенье | |||
0x63825363 | |||
Параметры DHCP | |||
0x350101 53: 1 (обнаружение DHCP) | |||
0x3204c0a80164 50: 192.168.1.100 запрошено | |||
0x370401030f06 55 (Список запросов параметров):
| |||
0xff 255 (конечная отметка) |
Предложение
Когда DHCP-сервер получает сообщение DHCPDISCOVER от клиента, которое представляет собой запрос аренды IP-адреса, DHCP-сервер резервирует IP-адрес для клиента и делает предложение аренды, отправляя клиенту сообщение DHCPOFFER. Это сообщение содержит идентификатор клиента (обычно MAC-адрес), IP-адрес, который предлагает сервер, маску подсети, срок аренды и IP-адрес DHCP-сервера, который делает предложение. Сервер DHCP также может принимать во внимание MAC-адрес аппаратного уровня на нижележащем транспортном уровне: согласно текущим RFC может использоваться MAC-адрес транспортного уровня, если в пакете DHCP не указан идентификатор клиента.
Сервер DHCP определяет конфигурацию на основе аппаратного адреса клиента, указанного в поле CHADDR (аппаратный адрес клиента). Здесь сервер 192.168.1.1 указывает IP-адрес клиента в поле YIADDR (ваш IP-адрес).
Ethernet: источник = MAC-адрес отправителя; destination = MAC-адрес клиента | ||||
IP: источник = 192.168.1.1; назначение = 255.255.255.255 | ||||
Октет 0 | Октет 1 | Октет 2 | Октет 3 | |
---|---|---|---|---|
OP | HTYPE | HLEN | Хмель | |
0x02 | 0x01 | 0x06 | 0x00 | |
XID | ||||
0x3903F326 | ||||
СЕКУНДЫ | ФЛАГИ | |||
0x0000 | 0x0000 | |||
CIADDR (IP-адрес клиента) | ||||
0x00000000 | ||||
YIADDR (Ваш IP-адрес) | ||||
0xC0A80164 (192.168.1.100) | ||||
SIADDR (IP-адрес сервера) | ||||
0xC0A80101 (192.168.1.1) | ||||
GIADDR (IP-адрес шлюза) | ||||
0x00000000 | ||||
CHADDR (аппаратный адрес клиента) | ||||
0x00053C04 | ||||
0x8D590000 | ||||
0x00000000 | ||||
0x00000000 | ||||
192 октета нулей; Наследие BOOTP . | ||||
Волшебное печенье | ||||
0x63825363 | ||||
Параметры DHCP | ||||
53: 2 (предложение DHCP) | ||||
1 (маска подсети): 255.255.255.0 | ||||
3 (Маршрутизатор): 192.168.1.1 | ||||
51 (время аренды IP-адреса): 86400 с (1 день) | ||||
54 (DHCP-сервер): 192.168.1.1 | ||||
6 (DNS-серверы):
|
Запрос
В ответ на предложение DHCP клиент отвечает сообщением DHCPREQUEST, транслируемым на сервер, [a] запрашивая предложенный адрес. Клиент может получать предложения DHCP от нескольких серверов, но он будет принимать только одно предложение DHCP. Клиент произведет бесплатный ARP, чтобы определить, есть ли в сети какой-либо другой хост с таким же IP-адресом. Если от другого хоста нет ответа, значит, в сети нет хоста с такой же IP-конфигурацией, и на сервер транслируется сообщение, показывающее принятие IP-адреса. На основе требуемой опции идентификации сервера в запросе и широковещательном обмене сообщениями серверы информируются, чье предложение клиент принял. [10] : Раздел 3.1, пункт 3 Когда другие DHCP-серверы получают это сообщение, они отменяют все предложения, которые они сделали клиенту, и возвращают предложенный IP-адрес в пул доступных адресов.
Ethernet: источник = MAC-адрес отправителя; пункт назначения = FF: FF: FF: FF: FF: FF | ||||
IP: источник = 0.0.0.0; пункт назначения = 255.255.255.255; [a] | ||||
Октет 0 | Октет 1 | Октет 2 | Октет 3 | |
---|---|---|---|---|
OP | HTYPE | HLEN | Хмель | |
0x01 | 0x01 | 0x06 | 0x00 | |
XID | ||||
0x3903F326 | ||||
СЕКУНДЫ | ФЛАГИ | |||
0x0000 | 0x0000 | |||
CIADDR (IP-адрес клиента) | ||||
0xC0A80164 (192.168.1.100) | ||||
YIADDR (Ваш IP-адрес) | ||||
0x00000000 | ||||
SIADDR (IP-адрес сервера) | ||||
0xC0A80101 (192.168.1.1) | ||||
GIADDR (IP-адрес шлюза) | ||||
0x00000000 | ||||
CHADDR (аппаратный адрес клиента) | ||||
0x00053C04 | ||||
0x8D590000 | ||||
0x00000000 | ||||
0x00000000 | ||||
192 октета нулей; Наследие BOOTP . | ||||
Волшебное печенье | ||||
0x63825363 | ||||
Параметры DHCP | ||||
53: 3 (запрос DHCP) | ||||
50: 192.168.1.100 запрошено | ||||
54 (DHCP-сервер): 192.168.1.1 |
Подтверждение
Когда DHCP-сервер получает сообщение DHCPREQUEST от клиента, процесс настройки вступает в свою последнюю фазу. Фаза подтверждения включает отправку пакета DHCPACK клиенту. Этот пакет включает в себя продолжительность аренды и любую другую информацию о конфигурации, которую мог запросить клиент. На этом процесс настройки IP завершен.
Протокол ожидает, что DHCP-клиент настроит свой сетевой интерфейс с согласованными параметрами.
После того, как клиент получит IP-адрес, он должен проверить вновь полученный адрес [11] (например, с помощью протокола разрешения адресов ARP ), чтобы предотвратить конфликты адресов, вызванные перекрытием пулов адресов DHCP-серверов.
Ethernet: источник = MAC-адрес отправителя; destination = MAC клиента | |||
IP: источник = 192.168.1.1; назначение = 255.255.255.255 | |||
Октет 0 | Октет 1 | Октет 2 | Октет 3 |
---|---|---|---|
OP | HTYPE | HLEN | Хмель |
0x02 | 0x01 | 0x06 | 0x00 |
XID | |||
0x3903F326 | |||
СЕКУНДЫ | ФЛАГИ | ||
0x0000 | 0x0000 | ||
CIADDR (IP-адрес клиента) | |||
0x00000000 | |||
YIADDR (Ваш IP-адрес) | |||
0xC0A80164 (192.168.1.100) | |||
SIADDR (IP-адрес сервера) | |||
0xC0A80101 (192.168.1.1) | |||
GIADDR (IP-адрес шлюза, переключаемый реле) | |||
0x00000000 | |||
CHADDR (аппаратный адрес клиента) | |||
0x00053C04 | |||
0x8D590000 | |||
0x00000000 | |||
0x00000000 | |||
192 октета из нулей. Наследие BOOTP | |||
Волшебное печенье | |||
0x63825363 | |||
Параметры DHCP | |||
53: 5 (DHCP ACK) или 6 (DHCP NAK) | |||
1 (маска подсети): 255.255.255.0 | |||
3 (Маршрутизатор): 192.168.1.1 | |||
51 (время аренды IP-адреса): 86400 с (1 день) | |||
54 (DHCP-сервер): 192.168.1.1 | |||
6 (DNS-серверы):
|
Информация
Клиент DHCP может запрашивать больше информации, чем сервер, отправленный с исходным DHCPOFFER. Клиент также может запросить повторные данные для конкретного приложения. Например, браузеры используют DHCP Inform для получения настроек веб-прокси через WPAD .
Освобождение
Клиент отправляет запрос на DHCP-сервер, чтобы освободить информацию DHCP, и клиент деактивирует свой IP-адрес. Поскольку клиентские устройства обычно не знают, когда пользователи могут отключить их от сети, протокол не требует отправки DHCP Release .
Параметры конфигурации клиента
Сервер DHCP может предоставить клиенту дополнительные параметры конфигурации. RFC 2132 описывает доступные параметры DHCP, определенные Internet Assigned Numbers Authority (IANA) - ПАРАМЕТРЫ DHCP и BOOTP. [12]
Клиент DHCP может выбирать, изменять и перезаписывать параметры, предоставленные сервером DHCP. В Unix-подобных системах это уточнение на уровне клиента обычно происходит в соответствии со значениями в файле конфигурации /etc/dhclient.conf .
Параметры
Опции - это строки октетов различной длины. Первый октет - это код опции, второй октет - это количество следующих октетов, а остальные октеты зависят от кода. Например, параметр типа сообщения DHCP для предложения будет отображаться как 0x35, 0x01, 0x02, где 0x35 - это код 53 для «типа сообщения DHCP», 0x01 означает, что следует один октет, а 0x02 - значение «предложения».
В следующих таблицах перечислены доступные параметры DHCP, перечисленные в RFC 2132 [13] и реестре IANA. [12]
Код | Имя | Длина | Заметки |
---|---|---|---|
0 | Pad [13] : Раздел 3.1 | 0 октетов | Может использоваться для дополнения других параметров, чтобы они были выровнены по границе слова; не следует за байтом длины |
1 | Маска подсети [13] : раздел 3.3 | 4 октета | Должен быть отправлен перед вариантом маршрутизатора (вариант 3), если оба включены |
2 | Смещение времени [13] : Раздел 3.4 | 4 октета | |
3 | Маршрутизатор | Кратное по 4 октета | Доступные маршрутизаторы должны быть перечислены в порядке предпочтения. |
4 | Сервер времени | Кратное по 4 октета | Доступные серверы времени для синхронизации должны быть перечислены в порядке предпочтения. |
5 | Сервер имен | Кратное по 4 октета | Доступные серверы имен IEN 116 должны быть перечислены в порядке предпочтения. |
6 | Сервер доменного имени | Кратное по 4 октета | Доступные DNS- серверы должны быть перечислены в порядке предпочтения. |
7 | Сервер журнала | Кратное по 4 октета | Доступные серверы журналов должны быть перечислены в порядке предпочтения. |
8 | Сервер cookie | Кратное по 4 октета | Файл cookie в данном случае означает «cookie с предсказанием» или «цитата дня», содержательный или юмористический анекдот, часто отправляемый как часть процесса входа в систему на больших компьютерах; это не имеет ничего общего с файлами cookie, отправляемыми веб-сайтами . |
9 | LPR сервер | Кратное по 4 октета | |
10 | Сервер Impress | Кратное по 4 октета | |
11 | Сервер местоположения ресурсов | Кратное по 4 октета | |
12 | Имя хоста | Минимум 1 октет | |
13 | Размер загрузочного файла | 2 октета | Длина загрузочного образа в блоках по 4 КиБ |
14 | Файл дампа заслуг | Минимум 1 октет | Путь для хранения аварийных дампов |
15 | Доменное имя | Минимум 1 октет | |
16 | Сервер подкачки | 4 октета | |
17 | Корневой путь | Минимум 1 октет | |
18 | Путь расширений | Минимум 1 октет | |
255 | Конец | 0 октетов | Используется для обозначения конца поля опций поставщика |
Код | Имя | Длина | Заметки |
---|---|---|---|
19 | Включение / отключение переадресации IP | 1 октет | |
20 | Включение / отключение нелокальной маршрутизации от источника | 1 октет | |
21 год | Фильтр политики | Кратное 8 октетов | |
22 | Максимальный размер повторной сборки дейтаграммы | 2 октета | |
23 | Время жизни IP по умолчанию | 1 октет | |
24 | Таймаут устаревания MTU пути | 4 октета | |
25 | Таблица плато MTU пути | Кратное по 2 октета |
Код | Имя | Длина | Заметки |
---|---|---|---|
26 год | Интерфейс MTU | 2 октета | |
27 | Все подсети локальные | 1 октет | |
28 год | Адрес трансляции | 4 октета | |
29 | Выполнить обнаружение маски | 1 октет | |
30 | Поставщик масок | 1 октет | |
31 год | Выполнить обнаружение маршрутизатора | 1 октет | |
32 | Адрес запроса маршрутизатора | 4 октета | |
33 | Статический маршрут | Кратное 8 октетов | Список пар назначения / маршрутизатора |
Код | Имя | Длина | Заметки |
---|---|---|---|
34 | Вариант инкапсуляции прицепа | 1 октет | |
35 год | Тайм-аут кеша ARP | 4 октета | |
36 | Инкапсуляция Ethernet | 1 октет |
Код | Имя | Длина | Заметки |
---|---|---|---|
37 | TTL по умолчанию TCP | 1 октет | |
38 | Интервал поддержки активности TCP | 4 октета | |
39 | Мусор поддержки активности TCP | 1 октет |
Код | Имя | Длина | Заметки |
---|---|---|---|
40 | Сетевая информационная служба домена | Минимум 1 октет | |
41 год | Сетевые информационные серверы | Кратное по 4 октета | |
42 | Серверы протокола сетевого времени (NTP) | Кратное по 4 октета | |
43 год | Информация о поставщике | Минимум 1 октет | |
44 год | NetBIOS через сервер имен TCP / IP | Кратное по 4 октета | |
45 | NetBIOS через сервер распространения датаграмм TCP / IP | Кратное по 4 октета | |
46 | NetBIOS через тип узла TCP / IP | 1 октет | |
47 | NetBIOS через TCP / IP | Минимум 1 октет | |
48 | Сервер шрифтов X Window System | Кратное по 4 октета | |
49 | Диспетчер отображения системы X Window | Кратное по 4 октета | |
64 | Сетевая информационная служба + домен | Минимум 1 октет | |
65 | Сетевая информационная служба + серверы | Кратное по 4 октета | |
68 | Домашний агент мобильного IP | Кратное по 4 октета | |
69 | Сервер Simple Mail Transfer Protocol (SMTP) | Кратное по 4 октета | |
70 | Сервер почтового протокола (POP3) | Кратное по 4 октета | |
71 | Сервер протокола передачи сетевых новостей (NNTP) | Кратное по 4 октета | |
72 | Сервер World Wide Web (WWW) по умолчанию | Кратное по 4 октета | |
73 | Сервер протокола Finger по умолчанию | Кратное по 4 октета | |
74 | Сервер Internet Relay Chat (IRC) по умолчанию | Кратное по 4 октета | |
75 | StreetTalk сервер | Кратное по 4 октета | |
76 | Сервер StreetTalk Directory Assistance (STDA) | Кратное по 4 октета |
Код | Имя | Длина | Заметки |
---|---|---|---|
50 | Запрошенный IP-адрес | 4 октета | |
51 | Срок аренды IP-адреса | 4 октета | |
52 | Перегрузка опций | 1 октет | |
53 | Тип сообщения DHCP | 1 октет | |
54 | Идентификатор сервера | 4 октета | |
55 | Список запросов параметров | Минимум 1 октет | |
56 | Сообщение | Минимум 1 октет | |
57 год | Максимальный размер сообщения DHCP | 2 октета | |
58 | Срок действия продления (T1) | 4 октета | |
59 | Повторная привязка (T2) значения времени | 4 октета | |
60 | Идентификатор класса поставщика | Минимум 1 октет | |
61 | Идентификатор клиента | Минимум 2 октета | |
66 | Имя сервера TFTP | Минимум 1 октет | |
67 | Имя загрузочного файла | Минимум 1 октет |
Типы сообщений DHCP
В этой таблице перечислены типы сообщений DHCP, задокументированные в RFC 2132, RFC 3203, [14] RFC 4388, [15] RFC 6926 [16] и RFC 7724. [17] Эти коды являются значениями в расширении DHCP 53, показанном на таблица выше.
Код | Имя | Длина | RFC |
---|---|---|---|
1 | DHCPDISCOVER | 1 октет | rfc2132 [13] : Раздел 9.6 |
2 | DHCPOFFER | 1 октет | rfc2132 [13] : Раздел 9.6 |
3 | DHCPREQUEST | 1 октет | rfc2132 [13] : Раздел 9.6 |
4 | DHCPDECLINE | 1 октет | rfc2132 [13] : Раздел 9.6 |
5 | DHCPACK | 1 октет | rfc2132 [13] : Раздел 9.6 |
6 | DHCPNAK | 1 октет | rfc2132 [13] : Раздел 9.6 |
7 | DHCPRELEASE | 1 октет | rfc2132 [13] : Раздел 9.6 |
8 | DHCPINFORM | 1 октет | rfc2132 [13] : Раздел 9.6 |
9 | DHCPFORCERENEW | 1 октет | rfc3203 [14] : Раздел 4 |
10 | DHCPLEASEQUERY | 1 октет | rfc4388 [15] : Раздел 6.1 |
11 | DHCP НЕ НАЗНАЧЕН | 1 октет | rfc4388 [15] : Раздел 6.1 |
12 | DHCPLEASEUNKNOWN | 1 октет | rfc4388 [15] : Раздел 6.1 |
13 | DHCPLEASEACTIVE | 1 октет | rfc4388 [15] : Раздел 6.1 |
14 | DHCPBULKLEASEQUERY | 1 октет | rfc6926 [16] : Раздел 6.2.1 |
15 | DHCPLEASEQUERYDONE | 1 октет | rfc6926 [16] : Раздел 6.2.1 |
16 | DHCPACTIVELEASEQUERY | 1 октет | rfc7724 [17] : Раздел 5.2.1 |
17 | DHCPLEASEQUERYSTATUS | 1 октет | rfc7724 [17] : Раздел 5.2.1 |
18 | DHCPTLS | 1 октет | rfc7724 [17] : Раздел 5.2.1 |
Идентификация поставщика клиента
Существует возможность определить производителя и функциональные возможности DHCP-клиента. Информация представляет собой строку символов или октетов переменной длины, значение которой определяется поставщиком DHCP-клиента. Один из способов, с помощью которого DHCP-клиент может сообщить серверу, что он использует определенный тип оборудования или микропрограмм, - установить значение в его запросах DHCP, называемое идентификатором класса поставщика (VCI) (опция 60). Этот метод позволяет DHCP-серверу различать два типа клиентских машин и соответствующим образом обрабатывать запросы от двух типов модемов. Некоторые типы приставок также устанавливают VCI (опция 60) для информирования DHCP-сервера о типе оборудования и функциональных возможностях устройства. Значение, установленное для этого параметра, дает DHCP-серверу подсказку о любой необходимой дополнительной информации, которая требуется этому клиенту в ответе DHCP.
Прочие расширения
Код | Имя | Длина | RFC |
---|---|---|---|
82 | Информация об агенте ретрансляции | Минимум 2 октета | RFC 3046 [18] |
85 | Серверы службы каталогов Novell (NDS) | Минимум 4 октета, кратное 4 октетам | RFC 2241 [19] : Раздел 2 |
86 | Имя дерева NDS | Переменная | RFC 2241 [19] : Раздел 3 |
87 | Контекст NDS | Переменная | RFC 2241 [19] : Раздел 4 |
100 | Часовой пояс , стиль POSIX | Переменная | RFC 4833 [20] |
101 | Часовой пояс , стиль базы данных tz | Переменная | RFC 4833 [20] |
114 | Портал авторизации DHCP | Переменная | RFC 8910 [21] |
119 | Поиск домена | Переменная | RFC 3397 [22] |
121 | Бесклассовый статический маршрут | Переменная | RFC 3442 [23] |
209 | Конфигурационный файл | Переменная | RFC 5071 [24] |
210 | Префикс пути | Переменная | RFC 5071 [24] |
211 | Время перезагрузки | Переменная | RFC 5071 [24] |
Дополнительные параметры информации агента ретрансляции
Опция информации агента ретрансляции (опция 82) определяет контейнер для присоединения подпараметров к запросам DHCP, передаваемым между ретранслятором DHCP и сервером DHCP. [18]
Код | Имя | Длина | RFC |
---|---|---|---|
1 | Идентификатор цепи агента | Минимум 1 октет | RFC 3046 [18] |
2 | Удаленный идентификатор агента | Минимум 1 октет | RFC 3046 [18] |
4 | Спецификации интерфейса службы передачи данных по кабелю (DOCSIS), класс устройства | 4 октета | RFC 3256 [25] |
Реле
В небольших сетях, где управляется только одна IP-подсеть, клиенты DHCP взаимодействуют напрямую с серверами DHCP. Однако DHCP-серверы также могут предоставлять IP-адреса для нескольких подсетей. В этом случае DHCP-клиент, который еще не получил IP-адрес, не может напрямую связываться с DHCP-сервером, используя IP-маршрутизацию, потому что он не имеет маршрутизируемого IP-адреса, не знает адреса канального уровня маршрутизатора и не знает IP-адрес DHCP-сервера.
Чтобы разрешить клиентам DHCP в подсетях, не обслуживаемых напрямую серверами DHCP, связываться с серверами DHCP, в этих подсетях могут быть установлены агенты ретрансляции DHCP. Клиент DHCP осуществляет широковещательную рассылку по локальному каналу; агент ретрансляции принимает широковещательную рассылку и передает ее одному или нескольким DHCP-серверам с помощью одноадресной рассылки . Агент ретрансляции сохраняет свой собственный IP-адрес в поле GIADDR пакета DHCP. DHCP-сервер использует значение GIADDR для определения подсети, в которой агент ретрансляции получил широковещательную рассылку, и выделяет IP-адрес в этой подсети. Когда DHCP-сервер отвечает клиенту, он отправляет ответ на GIADDR-адрес, снова используя одноадресную рассылку. Затем агент ретрансляции повторно передает ответ в локальную сеть.
В этой ситуации для связи между агентом ретрансляции и DHCP-сервером обычно используются UDP-порт источника и назначения 67.
Состояния клиентов
Как описано в RFC 2131, [10] : Раздел 4.4, DHCP-клиент может получать следующие сообщения от сервера:
- DHCPOFFER
- DHCPACK
- DHCPNAK
Клиент перемещается по состояниям DHCP в зависимости от того, как сервер отвечает на сообщения, отправляемые клиентом.
Надежность
DHCP обеспечивает надежность несколькими способами: периодическое обновление, повторное связывание, [10] : раздел 4.4.5 и аварийное переключение. Клиентам DHCP выделяется аренда на определенный период времени. Клиенты начинают попытки продлить свои договоры аренды по истечении половины интервала аренды. [10] : Раздел 4.4.5 Параграф 3 Они делают это, отправляя одноадресное сообщение DHCPREQUEST на сервер DHCP, который предоставил исходную аренду. Если этот сервер не работает или недоступен, он не сможет ответить на запрос DHCPREQUEST . Однако в этом случае клиент время от времени повторяет DHCPREQUEST , [10] : раздел 4.4.5, параграф 8 [b], поэтому, если DHCP-сервер восстановится или снова станет доступным, DHCP-клиент сможет связаться с ним и продлить договор аренды.
Если DHCP-сервер недоступен в течение длительного периода времени, [10] : Раздел 4.4.5, Параграф 5, DHCP-клиент попытается выполнить повторную привязку, передав свой DHCPREQUEST, а не одноадресно. Потому что он транслируется , то DHCPREQUEST сообщение достигнет всех доступных серверов DHCP. Если какой-либо другой DHCP-сервер может продлить аренду, он сделает это в это время.
Чтобы повторная привязка работала, когда клиент успешно связывается с резервным DHCP-сервером, этот сервер должен иметь точную информацию о привязке клиента. Поддержание точной информации о привязке между двумя серверами - сложная проблема; если оба сервера могут обновлять одну и ту же базу данных аренды, должен быть механизм, позволяющий избежать конфликтов между обновлениями на независимых серверах. Предложение по внедрению отказоустойчивых DHCP-серверов было представлено Инженерной группе Интернета, но так и не было оформлено официально. [26] [c]
Если повторная привязка не удалась, срок аренды в конечном итоге истечет. По истечении срока аренды клиент должен прекратить использовать IP-адрес, предоставленный ему при аренде. [10] : Раздел 4.4.5 Параграф 9 В это время он перезапустит процесс DHCP с самого начала, передав DHCPDISCOVER
сообщение. Поскольку срок его аренды истек, он примет любой предложенный IP-адрес. Как только он получит новый IP-адрес (предположительно от другого DHCP-сервера), он снова сможет использовать сеть. Однако, поскольку его IP-адрес изменился, все текущие соединения будут прерваны.
Сети IPv6
Базовая методология DHCP была разработана для сетей на основе Интернет-протокола версии 4 (IPv4). С момента разработки и развертывания сетей IPv6 DHCP также использовался для назначения параметров в таких сетях, несмотря на присущие IPv6 функции для автоконфигурации адресов без сохранения состояния . Версия протокола IPv6 обозначается как DHCPv6 . [27]
Безопасность
Базовый DHCP не включает никаких механизмов аутентификации. [28] Из-за этого он уязвим для различных атак. Эти атаки делятся на три основные категории:
- Неавторизованные DHCP-серверы предоставляют клиентам ложную информацию. [29]
- Неавторизованные клиенты получают доступ к ресурсам. [29]
- Атаки исчерпания ресурсов со стороны вредоносных DHCP-клиентов. [29]
Поскольку у клиента нет возможности проверить подлинность DHCP-сервера, неавторизованные DHCP-серверы (обычно называемые « мошенническим DHCP ») могут работать в сетях, предоставляя неверную информацию DHCP-клиентам. [30] Это может служить либо атакой типа «отказ в обслуживании», не позволяющей клиенту получить доступ к сетевым соединениям [31], либо атакой типа «человек посередине» . [32] Поскольку DHCP-сервер предоставляет DHCP-клиенту IP-адреса сервера, такие как IP-адрес одного или нескольких DNS-серверов, [29] злоумышленник может убедить DHCP-клиента выполнить поиск в DNS через его собственный DNS-сервер, и поэтому может предоставлять свои собственные ответы на запросы DNS от клиента. [33] [34] Это, в свою очередь, позволяет злоумышленнику перенаправлять сетевой трафик через себя, позволяя ему подслушивать соединения между клиентом и сетевыми серверами, с которыми он контактирует, или просто заменять эти сетевые серверы своими собственными. [33]
Поскольку DHCP-сервер не имеет безопасного механизма для аутентификации клиента, клиенты могут получить несанкционированный доступ к IP-адресам, представив учетные данные, такие как идентификаторы клиента, которые принадлежат другим клиентам DHCP. [30] Это также позволяет DHCP-клиентам исчерпать хранилище IP-адресов DHCP-сервера - представляя новые учетные данные каждый раз, когда он запрашивает адрес, клиент может использовать все доступные IP-адреса на конкретном сетевом канале, предотвращая доступ других DHCP-клиентов. получение обслуживания. [30]
DHCP действительно предоставляет некоторые механизмы для смягчения этих проблем. Расширение протокола Relay Agent Information Option (RFC 3046, обычно обозначаемое в отрасли по его фактическому номеру как Option 82 [35] [36] ) позволяет операторам сети прикреплять теги к сообщениям DHCP по мере того, как эти сообщения поступают в доверенную сеть оператора сети. . Затем этот тег используется в качестве токена авторизации для управления доступом клиента к сетевым ресурсам. Поскольку у клиента нет доступа к сети выше агента ретрансляции, отсутствие аутентификации не мешает оператору DHCP-сервера полагаться на токен авторизации. [28]
Другое расширение, Аутентификация для сообщений DHCP ( RFC 3118 ), обеспечивает механизм аутентификации сообщений DHCP. По состоянию на 2002 год RFC 3118 не получил широкого распространения из-за проблем с управлением ключами для большого количества клиентов DHCP. [37] В книге 2007 года о технологиях DSL отмечалось, что:
Было обнаружено множество уязвимостей безопасности, связанных с мерами безопасности, предложенными RFC 3118. Этот факт, в сочетании с введением 802.1x , замедлил развертывание и скорость использования аутентифицированного DHCP, и он никогда не получил широкого распространения. [38]
В книге 2010 года отмечается, что:
[t] здесь было очень мало реализаций аутентификации DHCP. Проблемы, связанные с управлением ключами и задержками обработки из-за вычисления хэша, были сочтены слишком высокой ценой, чтобы платить за ощутимые преимущества. [39]
Предложения по архитектуре от 2008 года включают аутентификацию запросов DHCP с использованием 802.1x или PANA (оба из которых передают EAP ). [40] IETF было сделано предложение включить EAP в сам DHCP, так называемый EAPoDHCP ; [41] это, похоже, не продвинулось дальше уровня проекта IETF, последний из которых датируется 2010 годом. [42]
Документы стандартов IETF
- RFC 2131, протокол динамической конфигурации хоста
- RFC 2132, параметры DHCP и расширения поставщика BOOTP
- RFC 3046, Опция информации агента ретрансляции DHCP
- RFC 3397, опция поиска домена по протоколу динамической конфигурации хоста (DHCP)
- RFC 3942, Реклассификация параметров протокола динамической конфигурации хоста версии 4 (DHCPv4)
- RFC 4242, параметр времени обновления информации для протокола динамической конфигурации хоста для IPv6
- RFC 4361, специфичные для узла идентификаторы клиентов для протокола динамической конфигурации хоста версии четыре (DHCPv4)
- RFC 4436, Обнаружение сетевых подключений в IPv4 (DNAv4)
- RFC 3442, опция бесклассового статического маршрута для протокола динамической конфигурации хоста (DHCP) версии 4
- RFC 3203, расширение перенастройки DHCP
- RFC 4388, запрос аренды протокола динамической конфигурации хоста (DHCP)
- RFC 6926, запрос массовой аренды DHCPv4
- RFC 7724, активный запрос аренды DHCPv4
Смотрите также
- Протокол обнаружения службы загрузки (BSDP) - расширение DHCP, используемое Apple NetBoot.
- Сравнение программного обеспечения DHCP-сервера
- Привязка DHCP (RFC 2322)
- Среда выполнения предварительной загрузки (PXE)
- Протокол обратного разрешения адресов (RARP)
- Мошеннический DHCP
- UDP Helper Address - инструмент для маршрутизации DHCP-запросов через границы подсети.
- Zeroconf - Сеть с нулевой конфигурацией
Заметки
- ^ a b В качестве необязательного поведения клиента некоторые широковещательные рассылки, например те, которые передают сообщения об обнаружении и запросе DHCP, могут быть заменены одноадресными, если клиент DHCP уже знает IP-адрес DHCP-сервера. [9]
- ^ RFC призывает клиента подождать половину оставшегося времени до T2, прежде чем он повторно отправит пакет DHCPREQUEST.
- ^ Предложение предусматривало механизм, с помощью которого два сервера могли оставаться синхронизированными друг с другом, так что даже в случае полного отказа одного сервера другой сервер мог восстановить базу данных аренды и продолжить работу. Из-за длины и сложности спецификации она никогда не публиковалась в качестве стандарта; однако методы, описанные в предложении, широко используются с открытым исходным кодом и несколькими коммерческими реализациями.
Рекомендации
- ^ Гиллис, Александр С. "Что такое DHCP (протокол динамической конфигурации хоста)?" . TechTarget: SearchNetworking . Проверено 19 февраля 2021 года .
- ^ Петерсон, Ларри Л .; Дэви, Брюс С. (2011). Компьютерные сети: системный подход (5-е изд.). Эльзевир. ISBN 978-0123850607. Проверено 21 марта 2019 года .
- ^ Билл Крофт; Джон Гилмор (сентябрь 1985 г.). «RFC 951 - протокол начальной загрузки» . Сетевая рабочая группа .
- ^ Network + Certification 2006, опубликованный Microsoft Press.
- ^ используется для протокола автообнаружения веб-прокси Протокол автообнаружения веб-прокси (WPAD)
- ^ RFC 4361, RFC 5494, RFC 6221, RFC 6422, RFC 6644, RFC 7083, RFC 7227, RFC 7283
- ^ Дромс, Ральф; Лимон, Тед (2003). Справочник DHCP . Издательство САМС . п. 436. ISBN. 978-0-672-32327-0.
- ^ а б Дромс, Ральф. «Протокол динамической конфигурации хоста» . tools.ietf.org . Проверено 4 июля 2017 года .
- ^ Дромс, Ральф. «Протокол динамической конфигурации хоста» . tools.ietf.org . Проверено 4 июля 2017 года .
- ^ Б с д е е г Дромс, Ральф (март 1997). Параметры DHCP и расширения поставщика BOOTP . IETF . DOI : 10,17487 / RFC2131 . RFC 2131 . Проверено 9 сентября 2014 года .
- ^ «RFC2131 Протокол динамической конфигурации хоста: динамическое распределение сетевых адресов» . tools.ietf.org .
- ^ а б «Параметры протокола динамической конфигурации хоста (DHCP) и протокола начальной загрузки (BOOTP)» . iana.org . Проверено 16 октября 2018 .
- ^ Б с д е е г ч я J к л м п о р д р ы Александр, Стив; Дромс, Ральф (март 1997). Параметры DHCP и расширения поставщиков BOOTP . IETF . DOI : 10,17487 / RFC2132 . RFC 2132 . Проверено 10 июня 2012 года .
- ^ a b { Тьоенс, Ив; Де Шрайвер, Питер (декабрь 2001 г.). Расширение перенастройки DHCP . IETF . DOI : 10,17487 / RFC3203 . RFC 3203 . Проверено 13 ноября 2020 года .
- ^ a b c d e { Раненый, богатый; Киннер, Ким (февраль 2006 г.). Расширение перенастройки DHCP . IETF . DOI : 10,17487 / RFC4388 . RFC 4388 . Проверено 13 ноября 2020 года .
- ^ a b c { Киннер, Ким; Стэпп, Марк; Рао, ДТВ Рамакришна; Джоши, Бхарат; Рассел, Нил; Курапати, Паван; Волц, Берни (апрель 2013 г.). Расширение перенастройки DHCP . IETF . DOI : 10,17487 / RFC6926 . RFC 6926 . Проверено 13 ноября 2020 года .
- ^ a b c d { Киннер, Ким; Стэпп, Марк; Волц, Берни; Рассел, Нил (декабрь 2015 г.). Расширение перенастройки DHCP . IETF . DOI : 10,17487 / RFC7724 . RFC 7724 . Проверено 13 ноября 2020 года .
- ^ а б в г Патрик, Майкл (январь 2001 г.). «Опция информации агента ретрансляции DHCP» . Документы IETF . IETF . DOI : 10,17487 / RFC3046 . Проверено 22 июля 2017 года .
- ^ а б в Прован, Дон (ноябрь 1997 г.). «RFC 2241 - Опции DHCP для служб каталогов Novell» . Документы IETF . IETF . DOI : 10,17487 / RFC3256 . Проверено 23 июля 2017 года .
- ^ а б Лир, Э .; Эггерт, П. (апрель 2007 г.). «Параметры часового пояса для DHCP» . Документы IETF . IETF . Проверено 28 июня 2018 .
- ^ Кумари, Уоррен. «RFC 8910 - идентификация Captive-Portal в DHCP и объявлениях маршрутизатора (RA)» . ietf.org . IETF . Проверено 25 марта 2021 года .
- ^ Бернар, Абоба; Стюарт, Чешир (ноябрь 2002 г.). «RFC 3397 - Опция поиска домена по протоколу динамической конфигурации хоста (DHCP)» . Документы IETF . IETF . DOI : 10,17487 / RFC3397 . Проверено 22 июля 2017 года .
- ^ RFC 3442
- ^ а б в Хэнкинс, Дэвид. «RFC 5071 - Параметры протокола динамической конфигурации хоста, используемые PXELINUX» . ietf.org . IETF . Проверено 25 марта 2021 года .
- ^ Дуг, Джонс; Rich, Woundy (апрель 2002 г.). «RFC 3256 - DOCSIS (спецификации интерфейса службы передачи данных по кабелю) Класс устройства DHCP (протокол динамической конфигурации хоста) Подопция информации агента ретрансляции» . Документы IETF . IETF . DOI : 10,17487 / RFC3256 . Проверено 23 июля 2017 года .
- ^ Дромс, Ральф; Киннер, Ким; Стэпп, Марк; Волц, Берни; Гонци, Стив; Рабил, Грег; Дули, Майкл; Капур, Арун (март 2003 г.). Протокол аварийного переключения DHCP . IETF . Идентификатор draft-ietf-dhc-failover-12 . Проверено 9 мая 2010 года .
- ^ Вайнберг, Нил (14 августа 2018 г.). «Почему дни DHCP могут быть сочтены» . Сетевой мир . Проверено 7 августа 2019 .
- ^ а б Патрик, Майкл (январь 2001 г.). «RFC 3046 - Опция информации агента ретрансляции DHCP» . Сетевая рабочая группа .
- ^ а б в г Дромс, Ральф (март 1997). «RFC 2131 - протокол динамической конфигурации хоста» . Сетевая рабочая группа .
- ^ а б в Стапко, Тимати (2011). Практическая встроенная безопасность: построение безопасных систем с ограниченными ресурсами . Newnes. п. 39. ISBN 978-0-08-055131-9.
- ^ Раунтри, Деррик (2013). Сетевая безопасность Windows 2012 Server: защита сетевых систем и инфраструктуры Windows . Newnes. п. 22. ISBN 978-1-59749-965-1.
- ^ Руни, Тимоти (2010). Введение в управление IP-адресами . Джон Вили и сыновья. п. 180. ISBN 978-1-118-07380-3.
- ^ а б Голованов (Лаборатория Касперского), Сергей (июнь 2011 г.). «Загрузчик TDSS получил" ноги " » .
- ^ Санни, Акаш К. (октябрь 2015 г.). «Протокол DHCP и его уязвимости» .
- ^ Курицы, Франсиско Дж .; Кабальеро, Хосе М. (2008). Triple Play: построение конвергентной сети для IP, VoIP и IPTV . Джон Вили и сыновья. п. 239. ISBN. 978-0-470-75439-9.
- ^ Рамирес, Дэвид Х. (2008). Безопасность IPTV: защита ценного цифрового контента . Джон Вили и сыновья. п. 55. ISBN 978-0-470-72719-5.
- ^ Лимон, Тед (апрель 2002 г.). «Реализация RFC 3118» .
- ^ Голден, Филипп; Дедье, Эрве; Якобсен, Криста С. (2007). Внедрение и применение технологии DSL . Тейлор и Фрэнсис. п. 484. ISBN 978-1-4200-1307-8.
- ^ Руни, Тимоти (2010). Введение в управление IP-адресами . Джон Вили и сыновья. С. 181–182. ISBN 978-1-118-07380-3.
- ^ Коупленд, Ребекка (2008). Конвергенция проводных сетей NGN и мобильных сетей 3G с помощью IMS . Тейлор и Фрэнсис. С. 142–143. ISBN 978-1-4200-1378-8.
- ^ Прасад, Рамджи; Миховская, Албена (2009). Новые горизонты мобильной и беспроводной связи: сети, услуги и приложения . 2 . Артек Хаус. п. 339. ISBN. 978-1-60783-970-5.
- ^ «Архивная копия» . Архивировано из оригинала на 2015-04-03 . Проверено 12 декабря 2013 .CS1 maint: заархивированная копия как заголовок ( ссылка )
Внешние ссылки
- СМИ, относящиеся к протоколу динамической конфигурации хоста (DHCP) на Викискладе?