Протокол динамической конфигурации хоста (DHCP146>) - это протокол управления сетью, использование в Интернет-протоколе (IP) посредством сетей, чего DHCP сервер динамически назначает IP-адрес и другие параметры сети каждому устройству в сети, чтобы они могли взаимодействовать с другими IP-сетями. Сервер DHCP позволяет компьютеру автоматически запрашивать IP-адрес и сетевые параметры у интернет-провайдера (ISP), уменьшая потребность в сетевом администраторе или пользователь, чтобы вручную назначить IP-адреса всем сетевым устройствам. При отсутствии DHCP-сервера компьютеру или другому устройству в сети необходимо вручную назначить IP-адрес или назначить себе адрес APIPA, что не позволит ему использовать с внешним миром. его локальная подсеть.
DHCP может быть реализован в сетях размером от домашних сетей до больших кампусных сетей и региональных сетей ISP. маршрутизатор или резидентный шлюз могут быть включены в качестве DHCP-сервера. Большинство домашних сетевых маршрутизаторов получают глобально уникальный IP-адрес в сети Интернет-провайдера. В локальной сети DHCP-сервер назначает локальный IP-адрес каждому устройству, подключенному к сети.
В 1984 году представлен протокол обратного разрешения адресов (RARP), определенный в RFC 903, чтобы разрешить использование простых устройств, таких как бездисковые рабочие станции для динамического получения подходящего IP-адреса. Поскольку он действовал на уровне канала передачи данных, это затрудняло на многих серверных платформах, а также требование наличия сервера на каждом отдельном сетевом канале. RARP был заменен протоколом начальной загрузки (BOOTP ), определенным в RFC 951 в сентябре 1985 года. Это ввело фактор ретрансляции, который позволяет пересылать пакеты BOOTP по сетям, позволяя один центральный сервер BOOTP для обслуживания хостов во многих IP-подсетях.
DHCP основан на BOOTP, но может динамически выделять IP-адреса из пула и восстанавливать их, когда они больше не используются. Его также можно использовать для доставки широкого дополнительных параметров конфигурации IP-клиенты, включая параметры для конкретной конфигурации платформы. Протокол DHCP был впервые определен в RFC 1531 в октябре 1993 г.; но из-за ошибок в процессе редактирования он был почти сразу переиздан как RFC 1541.
. Четыре года спустя тип сообщения DHCPINFORM и другие небольшие изменения были добавлены в RFC 2131 ; который с 2014 года остается стандартом для сетей IPv4.
DHCPv6 был представлен описан в RFC 3315 в 2003 году, но он был обновлен последующими RFC. RFC 3633 добавил механизм DHCPv6 для делегирования префикса состояния и Автоконфигурация без сохранения сохранения добавлена в RFC 3736.
Интернет -проте (ИП) определяет, как устройства взаимодействуют внутри и между локальными сетями в Интернете. DHCP-сервер может управлять настройками IP для устройств в этой локальной сети, например, назначая устройствам IP-адреса автоматически и динамически.
DHCP работает на основе модели клиент-сервер. Когда компьютер или другое устройство подключается к сети, программное обеспечение DHCP-клиент отправляет запрос DHCP broadcast, запрашивая специальную информацию. Любой DHCP-сервер в сети может обслуживать запрос. DHCP-сервер управляет пулом IP-адресов и информацией о параметрах конфигурации клиента, таких как шлюз по умолчанию, доменное имя, серверы имен и время. серверы. При запросе DHCP сервер может предоставить информацию для каждого клиента, как это было ранее настроено администратором, или конкретным адресом и любой другой информацией, действительной для всей сети и в течение периода времени, на который выделено (аренда) является действительным. Клиент DHCP обычно запрашивает эту информацию сразу после загрузки и периодически после этого до истечения срока действия информации. Когда DHCP-клиент обновляет назначение, он использует те же значения параметров, но DHCP-сервер может назначить новый адрес на основе политик назначения, службы администраторами.
В больших сетях, состоящих из нескольких каналов, один DHCP-сервер может обслуживать всю сеть при помощи агентов ретрансляции DHCP, расположенных на соединяющихся маршрутизаторах. Такие агенты ретранслируют сообщения между DHCP-клиентами и DHCP-серверами, расположенными в разных подсетях.
В зависимости от реализации DHCP-сервер может иметь три метода распределения IP-адресов:
DHCP используется для Интернет-протокола версии 4 (IPv4) и IPv6. Хотя обе версии одной и той же цели, детали протокола для IPv4 и IPv6 были рассмотрены как отдельные протоколы. Для работы устройства IPv6 можно альтернативно использовать сохранение автоконфигурации. Узлы IPv6 также могут использовать локальную адресацию канала для выполнения операций, ограниченных локальной сетью.
DHCP использует модель обслуживания без исключения соединения, используя протокол пользовательских дейтаграмм (UDP). Он реализован с двумя номерами портов UDP для своих операций, как для протокола загрузки (BOOTP ). UDP-порт номер 67 является портом назначения сервера, а UDP-порт номер 68 используется клиентом.
Операции DHCP делятся на четыре фазы: открытие сервера, предложение аренды IP, запрос IP аренды и подтверждение IP. Эти этапы часто обозначаются аббревиатурой DORA для обнаружения, предложения, запроса и подтверждения.
Работа DHCP начинается с того, что клиенты передают запрос. Если клиент и сервер находятся в разных подсетях, можно использовать DHCP Helper или DHCP Relay Agent. Клиенты, предлагающие продление существующей аренды, могут связываться напрямую через UDP unicast, так как в момент у клиента уже есть установленный IP-адрес. Кроме того, есть флаг BROADCAST (1 бит в 2-байтовом поле флагов, где все остальные биты зарезервированы и поэтому установлены в 0), клиент может использовать, чтобы указать, каким способом (одноадресный) он может получить DHCPOFFER: 0x8000 для трансляции, 0x0000 для одноадресной. Обычно 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. UDP : исходный порт = 68; порт назначения = 67 | |||
Октет 0 | Октет 1 | Октет 2 | Октет 3 |
---|---|---|---|
OP | HTYPE | HLEN | HOPS |
0x01 | 0x01 | 0x06 | 0x00 |
XID | |||
0x3903F326 | |||
SECS | FLAGS | ||
0x0000 | 0x0000 | ||
CIADDR (IP-адрес клиента) | |||
0x00000000 | |||
YIADDR (Ваш IP-адрес) | |||
0x00000000 | |||
SIADDR (IP-адрес сервера) | |||
0x00000000 | |||
GIADDR (IP-адрес шлюза) | |||
0x00000000 | |||
CHADDR (аппаратный адрес клиента) | |||
0x00053C04 | |||
0x8D590000 | |||
0x00000000 | |||
0x00000000 | |||
192 октета из нулей или переполнение пространства для дополнительных опций ; BOOTP устаревшая. | |||
Magic cookie | |||
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-адрес отправителя; назначение = MAC-адрес клиента | ||||
IP: источник = 192.168.1.1; назначение = 255.255.255.255. UDP : исходный порт = 67; порт назначения = 68 | ||||
Октет 0 | Октет 1 | Октет 2 | Октет 3 | |
---|---|---|---|---|
OP | HTYPE | HLEN | HOPS | |
0x02 | 0x01 | 0x06 | 0x00 | |
XID | ||||
0x3903F326 | ||||
SECS | FLAGS | |||
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 устаревшая. | ||||
Magic cookie | ||||
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, транслируемым на сервер, с запросом предложенного адреса. Клиент может получать предложения DHCP от нескольких серверов, но он будет принимать только одно предложение DHCP. На основе выбора опции сервера в запросе и широковещательном обмене сообщениями серверы информируются, чье предложение принимает клиент. Когда другие DHCP-серверы получают это сообщение, они отменяют все предложения, сделанные клиенту, и возвращают предложенный IP-адрес в пул доступных адресов.
Ethernet: источник = MAC-адрес отправителя; пункт назначения = FF: FF: FF: FF: FF: FF | ||||
IP: источник = 0.0.0.0; назначение = 255.255.255.255;. UDP : порт источника = 68; порт назначения = 67 | ||||
Октет 0 | Октет 1 | Октет 2 | Октет 3 | |
---|---|---|---|---|
OP | HTYPE | HLEN | HOPS | |
0x01 | 0x01 | 0x06 | 0x00 | |
XID | ||||
0x3903F326 | ||||
SECS | FLAGS | |||
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 устаревшая. | ||||
Magic cookie | ||||
0x63825363 | ||||
Параметры DHCP | ||||
53: 3 (запрос DHCP) | ||||
50: 192.168.1.100 запрошено | ||||
54 (DHCP-сервер): 192.168.1.1 |
Когда DHCP-сервер получает сообщение DHCPREQUEST от клиента, процесс настройки вступает в свою последнюю фазу. Фаза подтверждает включает отправку пакета DHCPACK клиенту. Этот пакет включает в себя аренду и любую другую информацию о конфигурации, которую может запросить клиент. На этом процесс настройки IP завершен.
Протокол ожидает, что DHCP-клиент настроит свой сетевой интерфейс с согласованным.
После того, как клиент получит IP-адрес, он должен проверить вновь полученный адрес (например, с помощью протокола разрешения адресов ARP ), чтобы предотвратить заражты, вызванные перекрытием пулов адресов DHCP- серверов.
Ethernet: источник = MAC-адрес отправителя; назначение = MAC-адрес клиента | |||
IP: источник = 192.168.1.1; назначение = 255.255.255.255. UDP : исходный порт = 67; порт назначения = 68 | |||
Октет 0 | Октет 1 | Октет 2 | Октет 3 |
---|---|---|---|
OP | HTYPE | HLEN | HOPS |
0x02 | 0x01 | 0x06 | 0x00 |
XID | |||
0x3903F326 | |||
SECS | FLAGS | ||
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 | |||
0x | |||
192 октеты нулей. BOOTP старый | |||
Magic cookie | |||
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, Гор Управление назначением номеров Интернета (IANA) - ПАРАМЕТРЫ DHCP и BOOTP.
DHCP-клиент может выбирать, проверять и перезаписывать параметры предоставленным DHCP-сервером. В Unix-подобных системах это уточнение на уровне клиента обычно происходит в соответствии с конфигурацией в файле /etc/dhclient.conf.
Параметры собой строки октетов длины длины. Первый октет - это код вариантов, второй октет - это количество следующих октетов, а остальные октеты зависят от кода. Например, параметр типа сообщения DHCP для предложения будет как 0x35, 0x01, 0x02, где 0x35 - это код 53 для «типа сообщения DHCP», 0x01 означает, что следует один октет, а 0x02 - значение «предложения».
В следующих таблицах доступных параметров DHCP, перечисленных в RFC 2132 и реестре IANA.
Код | Имя | Длина | Примечания |
---|---|---|---|
0 | Pad | 0 октеты | Можно использовать для заполнения других параметров, чтобы они были выровнены по границам слова; не следует за байтом длины |
1 | Маска подсети | 4 октета | Должен быть отправлен перед параметром маршрутизатора (вариант 3), если оба включены |
2 | Смещение времени | 4 октета | |
3 | Маршрутизатор | Количество, кратное 4 октетам | Доступные маршрутизаторы, должны быть перечислены в порядке предпочтения |
4 | Сервер времени | Кратные 4 октета | Доступные серверы времени для синхронизации должны быть перечислены в порядке предпочтения |
5 | Сервер имен | Число, кратное 4 октетам | Доступные IEN 116 серверы имен, должны быть перечислены в порядке предпочтения |
6 | Сервер доменных имен | Количество, кратное 4 октетам | Доступные DNS серверы, должны быть перечислены в порядке предпочтения |
7 | Сервер журналов | Число, кратное 4 октетам | Доступные серверы журналов должны быть перечислены в порядке предпочтения. |
8 | Сервер cookie | Число, кратное 4 октетам | Файл cookie в данном случае означает «печенье с предсказанием» или «цитата дня», содержательный или юмористический анекдот, часто отправляемый при входе в систему. обрабатывать на больших компьютерах; он не имеет ничего общего с файлами cookie, отправляемымивеб-сайтами. |
9 | Сервер LPR | Количество кратных 4 октета | |
10 | Сервер Impress | Количество кратных 4 октетов | |
11 | Сервер местоположения ресурсов | Количество, кратное 4 октетам | |
12 | Имя хоста | Минимум 1 октет | |
13 | Размер загрузочного файла | 2 октета | Длина загрузочного образа в Блоки по 4 КиБ |
14 | Merit файл дампа | Минимум 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 keepalive | 1 октет |
Код | Имя | Длина | Примечания |
---|---|---|---|
40 | Домен службы сетевой информации | Минимум 1 октет | |
41 | Серверы сетевой информации | Краткие 4 октета | |
42 | Серверы Network Time Protocol (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 | Диспетчер отображения системы XW indow | Краткость по 4 октета | |
64 | Сетевая информационная служба + домен | Минимум 1 октет | |
65 | Сетевая информационная служба + серверы | Число, кратное 4 октетам | |
68 | Домашний агент Мобильный IP | Краткое 4 октета | |
69 | Протокол простой передачи почты (SMTP) сервер | Число, кратное 4 октетам | |
70 | Протокол почтового отделения (POP3), сервер | Число, кратное 4 октетам | |
71 | Сервер протокола передачи сетевых новостей (NNTP) | Краткие 4 октета | |
72 | По умолчанию Сервер World Wide Web (WWW) | Краткие 4 октета | |
73 | По умолчанию Протокол пальца сервер | Краткое по 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 октет |
Код | Имя | Длина | Примечания |
---|---|---|---|
1 | DHCPDISCOVER | 1 октет | |
2 | DHCPOFFER | 1 октет | |
3 | DHCPREQUEST | 1 октет | |
4 | DHCPDECLINE | 1 октет | |
5 | DHCPACK | 1 октет | |
6 | DHCPNAK | 1 октет | |
7 | DHCPRELEASE | 1 о ктет | |
8 | DHCPINFORM | 1 октет |
Существует возможность идентифицировать поставщика и функциональность клиента DHCP. Информация представляет собой строку типоразмер из символов или октетов, значение которой указан поставщик DHCP-клиента. Один из методов, с помощью которого DHCP-клиент может сообщить серверу, что он использует определенный тип оборудования или микропрограмм, заключается в установке значений в его запросах DHCP, называемого используемым поставщиком класса поставщика (VCI) (опция 60). Этот метод позволяет DHCP-серверу различать два типа клиентских машин и соответствующим образом обрабатывать запросы от двух типов модемов. Некоторые типы телеприставок также устанавливают VCI (опция 60) для информирования DHCP-сервера о типе оборудования и функциональных возможностях устройства. Значение, установленное для этого параметра, дает серверу DHCP любую дополнительную информацию, которая требуется этому клиенту в ответе DHCP.
Код | Имя | Длина | RFC |
---|---|---|---|
82 | Информация агента ретрансляции | Минимум 2 октета | RFC 3046 |
85 | Серверы службы каталогов Novell (NDS) | Минимум 4 октета, кратные 4 октетам | RFC 2241 |
86 | Имя дерева NDS | Переменная | RFC 2241 |
87 | Контекст NDS | Переменная | RFC 2241 |
100 | Часовой пояс, POSIX | Переменная | стиль RFC 4833 |
101 | Часовой пояс, база данных тз стиль | Переменная | RFC 4833 |
119 | Поиск домена | Переменная | RFC 3397 |
121 | Бесклассовый статический маршрут | Переменная | RFC 3442 |
Параметр информации агента ретрансляции (опция 82) указать контейнер для присоединения подпараметров к запросу DHCP, передаваемым между ретранслятором DHCP и сервером DHCP.
Код | Имя | Длина | RFC |
---|---|---|---|
4 | Характеристики интерфейса службы передачи данных по кабелю (DOCSIS) класс устройства | 4 октета | RFC 3256 |
В небольших сетях, где управляется только одна подсеть 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.
DHCP обеспечивает надежность в нескольких способах: периодическое обновление, повторное связывание и отработка отказа. Клиентам DHCP выделяется аренда на период времени. Клиенты начать попытки продлить свои договоры по истечении половины интервала аренды. Они делают это, отправляя одноадресное сообщение DHCPREQUEST на сервер DHCP, который предоставил исходную аренду. Если этот сервер не работает или недоступен, он не сможет ответить на DHCPREQUEST. Однако в этом случае клиент от времени повторяет DHCPREQUEST, поэтому, если DHCP-сервер снова включится или снова станет доступным, DHCP-клиент сможет связаться с ним и продлить аренду.
Если DHCP-сервер недоступен в течение длительного периода времени, DHCP-клиент пытается выполнить повторную привязку, передает свой DHCPREQUEST, а не одноадресно. Это онлайн широковещательный, сообщение DHCPREQUEST достигнет всех доступных серверов DHCP. Если какой-либо другой DHCP-сервер может продлить аренду, он сделает это в это время.
Для работы повторной привязки, когда клиент должен связывается с резервным DHCP-сервером, этот сервер должен иметь точную информацию о привязке клиента. Поддержание точной информации о привязке между двумя серверами - сложная проблема; если оба сервера могут обновлять одну и ту же базу данных, должен быть механизм, позволяющий избежать конфликтов между обновлениями на независимых серверах. Предложение по внедрению отказоустойчивых DHCP-серверов было направлено в Инженерную группу Интернета, но так и не было оформлено официально.
Если повторное связывание не удается, истекает срок аренды. По истечении срока аренды клиент должен прекратить использовать IP-адрес, предоставленный ему в его аренде. В это время он перезапустит процесс DHCP с самого начала, передает сообщение DHCPDISCOVER
. Срок его аренды истек, он примет любой предложенный IP-адрес. Как только он получит новый IP-адрес (предположительно от другого DHCP-сервера), он снова сможет использовать сеть. Однако, поскольку его IP-адрес изменился, все текущие соединения будут прерваны.
По состоянию на 2018 год DHCP по-прежнему широко используется для IP-адресов автоматического назначения. Новые итерации для назначения IP-адреса включают DHCPv6 и SLAAC.
Базовый DHCP не включает никаких механизмов аутентификации. Из-за этого он уязвим для множества атак. Эти атаки делятся на три основные категории:
Срок действия сервера у клиента нет возможности проверить подлинность DHCP-сервера, неавторизованные DHCP-серверы (обычно называемые «мошенническим DHCP ») могут работать в сетях, предоставляя неверную информацию клиентов DHCP. Это может служить либо атакой типа «отказ в обслуживании», не позволяющей клиенту получить доступ к сетевому подключению, либо атакой типа «человек посередине». DHCP-сервер предоставляет DHCP-клиенту IP-адреса сервера, такие как IP-адрес одного или нескольких DNS-серверов, злоумышленник может убедить DHCP-сервер выполнить поиск в DNS через свой собственный DNS-сервер и, следовательно, может предоставить свои собственные ответы. на DNS-запросы от клиента. Это, в свою очередь, позволяет злоумышленнику перенаправлять сетевой трафик через себя, позволяя ему подслушивать соединения между клиентом и сетевыми серверами, с которыми он контактирует, или просто заменять эти сетевые серверы своими собственными.
Поскольку DHCP-сервер имеет Нет безопасного механизма для аутентификации клиента, клиенты могут получить несанкционированный доступ к IP-адресам, предоставив учетные данные, такие как идентификаторы клиентов, которые принадлежат другим клиентам DHCP. Это также позволяет клиентам DHCP исчерпать хранилище IP-адресов DHCP-сервера - представляя новые учетные данные каждый раз, когда он запрашивает адрес, клиент может использовать все доступные IP-адреса на конкретном сетевом канале, не позволяя другим клиентам DHCP получать обслуживание.
DHCP предоставляет некоторые механизмы для устранения этих проблем. Расширение протокола Relay Agent Information Option (RFC 3046, обычно обозначаемое в отрасли по его фактическому номеру как Option 82) позволяет операторам сети прикреплять теги к сообщениям DHCP по мере их поступления. в доверенной сети сетевого оператора. Затем этот тег используется в качестве токена авторизации для управления доступом клиента к сетевым ресурсам. Поскольку у клиента нет доступа к сети выше агента ретрансляции, отсутствие аутентификации не мешает оператору DHCP-сервера полагаться на токен авторизации.
Другое расширение, Аутентификация для сообщений DHCP (RFC 3118 ), обеспечивает механизм аутентификации сообщений DHCP. По состоянию на 2002 год RFC 3118 не получил широкого распространения из-за проблем с управлением ключами для большого количества клиентов DHCP. В книге 2007 года о технологиях DSL отмечалось, что:
было выявлено множество уязвимостей безопасности, связанных с мерами безопасности, предложенными в RFC 3118. Этот факт, в сочетании с введением 802.1x, замедлил развертывание и скорость использования аутентифицированного DHCP, и он никогда не получил широкого распространения.
В книге 2010 года отмечается, что:
[t ] здесь было очень мало реализаций аутентификации DHCP. Проблемы, связанные с управлением ключами и задержками обработки из-за вычисления хэша, были сочтены слишком высокой ценой, чтобы платить за ощутимые преимущества.
Архитектурные предложения от 2008 года включают аутентификацию запросов DHCP с использованием 802. 1x или PANA (оба транспортируют EAP ). Было сделано предложение IETF о включении EAP в сам DHCP, так называемый EAPoDHCP ; похоже, что дальше черновика IETF, последний уровень которых датируется 2010 годом, не наблюдается.