Протокол динамического конфигурирования сервера - Dynamic Host Configuration Protocol - Wikipedia

«DHCP» перенаправляет сюда. Для использования в других целях см. DHCP (значения).
Набор интернет-протоколов
Уровень приложения
Транспортный уровень
Интернет-уровень
Связующий слой

В Протокол динамического конфигурирования сервера (DHCP) это протокол управления сетью используется на протокол Интернета (IP) сети, посредством чего DHCP сервер динамически присваивает айпи адрес и другие параметры конфигурации сети для каждого устройства в сети, чтобы они могли взаимодействовать с другими IP-сетями.[1] DHCP-сервер позволяет компьютерам запрос IP-адреса и сетевые параметры автоматически из интернет-провайдер (ISP), уменьшая потребность в сетевой администратор или Пользователь чтобы вручную назначить IP-адреса всем сетевым устройствам.[1] При отсутствии DHCP-сервера компьютеру или другому устройству в сети необходимо вручную назначить IP-адрес или назначить себе APIPA адрес, последний из которых не позволит ему общаться за пределами своего локального подсеть.

DHCP может быть реализован в сетях размером от домашние сети к большому сети кампусов и региональные сети Интернет-провайдеров.[2] А маршрутизатор или жилой шлюз можно включить в качестве DHCP-сервера. Большинство домашних сетевых маршрутизаторов получают глобально уникальный IP-адрес в сети Интернет-провайдера. В локальной сети DHCP-сервер назначает локальный IP-адрес каждому устройству, подключенному к сети.

История

В 1984 г. Протокол обратного разрешения адресов (RARP), определенный в RFC 903, был введен, чтобы позволить простые устройства, такие как бездисковые рабочие станции для динамического получения подходящего IP-адреса. Однако, поскольку он действовал в уровень канала передачи данных это затрудняло реализацию на многих серверных платформах, а также требовало наличия сервера на каждом отдельном сетевом соединении. RARP был заменен протоколом Bootstrap (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-сервер выдает частный IP-адрес, зависящий от каждого клиента. ID клиента (или, как правило, клиент MAC-адрес ) на основе предварительно заданного администратором сопоставления. Эта функция называется по-разному статическое назначение DHCP к DD-WRT, фиксированный адрес по документации dhcpd, Резервирование адресов от Netgear, Резервирование DHCP или же статический DHCP к Cisco и Linksys, и Резервирование IP-адреса или же Привязка MAC / IP-адреса различными другими производителями маршрутизаторов. Если нет соответствия для клиента ID клиента (если предусмотрено) или MAC-адрес (если не указан идентификатор клиента), сервер может или не может вернуться к динамическому или автоматическому распределению.

DHCP используется для Интернет-протокол версии 4 (IPv4) и IPv6. Хотя обе версии служат одной и той же цели, детали протокола для IPv4 и IPv6 достаточно различаются, чтобы их можно было рассматривать как отдельные протоколы.[7] Для работы IPv6 устройства могут альтернативно использовать автоконфигурация адреса без сохранения состояния. Хосты IPv6 также могут использовать локальная адресация для выполнения операций, ограниченных локальной сетью.

Операция

Иллюстрация типичного невозобновляемого сеанса DHCP; каждое сообщение может быть трансляцией или одноадресная передача, в зависимости от возможностей DHCP-клиента.[8]

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-адрес, используемый клиентом. Также установлены некоторые параметры.

Пример сообщения DHCPDISCOVER

Ethernet: источник = MAC-адрес отправителя; пункт назначения = FF: FF: FF: FF: FF: FF

IP: источник = 0.0.0.0; пункт назначения = 255.255.255.255
UDP: исходный порт = 68; порт назначения = 67

Октет 0Октет 1Октет 2Октет 3
OPHTYPEHLENХмель
0x010x010x060x00
XID
0x3903F326
SECSФлаги
0x00000x0000
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 (Список запросов параметров):
  • 1 (запрос маски подсети),
  • 3 (маршрутизатор),
  • 15 (доменное имя),
  • 6 (Сервер доменных имен)
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-адрес).

Сообщение DHCPOFFER

Ethernet: источник = MAC-адрес отправителя; destination = MAC-адрес клиента

IP: источник = 192.168.1.1; пункт назначения = 255.255.255.255
UDP: исходный порт = 67; порт назначения = 68

Октет 0Октет 1Октет 2Октет 3
OPHTYPEHLENХмель
0x020x010x060x00
XID
0x3903F326
SECSФлаги
0x00000x0000
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-серверы):
  • 9.7.10.15,
  • 9.7.10.16,
  • 9.7.10.18

Запрос

В ответ на предложение DHCP клиент отвечает сообщением DHCPREQUEST, транслируемым на сервер,[а] запрашивая предложенный адрес. Клиент может получать предложения DHCP от нескольких серверов, но он будет принимать только одно предложение DHCP. Клиент создаст бесплатный ARP, чтобы определить, есть ли в сети какой-либо другой хост с таким же IP-адресом. Если от другого хоста нет ответа, значит, в сети нет хоста с такой же конфигурацией TCP, и сообщение транслируется на сервер, показывая принятие IP-адреса. На основании необходимых идентификация сервера в запросе и широковещательном обмене сообщениями, серверы информируются, чье предложение клиент принял.[10]:Раздел 3.1, пункт 3 Когда другие DHCP-серверы получают это сообщение, они отменяют все предложения, сделанные клиенту, и возвращают предложенный IP-адрес в пул доступных адресов.

Сообщение DHCPREQUEST

Ethernet: источник = MAC-адрес отправителя; пункт назначения = FF: FF: FF: FF: FF: FF

IP: источник = 0.0.0.0; пункт назначения = 255.255.255.255;[а]
UDP: исходный порт = 68; порт назначения = 67

Октет 0Октет 1Октет 2Октет 3
OPHTYPEHLENХмель
0x010x010x060x00
XID
0x3903F326
SECSФлаги
0x00000x0000
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-серверов.

Сообщение DHCPACK

Ethernet: источник = MAC-адрес отправителя; назначение = MAC клиента

IP: источник = 192.168.1.1; пункт назначения = 255.255.255.255
UDP: исходный порт = 67; порт назначения = 68

Октет 0Октет 1Октет 2Октет 3
OPHTYPEHLENХмель
0x020x010x060x00
XID
0x3903F326
SECSФлаги
0x00000x0000
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-серверы):
  • 9.7.10.15,
  • 9.7.10.16,
  • 9.7.10.18

Информация

Клиент DHCP может запрашивать больше информации, чем сервер, отправленный с исходным DHCPOFFER. Клиент также может запросить повторные данные для конкретного приложения. Например, браузеры используют DHCP Inform для получения настроек веб-прокси через WPAD.

Освобождение

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

Параметры конфигурации клиента

DHCP-сервер может предоставить клиенту дополнительные параметры конфигурации. RFC 2132 описывает доступные параметры DHCP, определенные Управление по присвоению номеров в Интернете (IANA) - ПАРАМЕТРЫ DHCP и BOOTP.[12]

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

Опции

Опции - это строки октетов различной длины. Первый октет - это код опции, второй октет - это количество следующих октетов, а остальные октеты зависят от кода. Например, опция типа сообщения DHCP для предложения будет отображаться как 0x35, 0x01, 0x02, где 0x35 - это код. 53 для «типа сообщения DHCP», 0x01 означает, что следует один октет, а 0x02 - значение «предложения».

Документировано в RFC 2132

В следующих таблицах перечислены доступные параметры DHCP, перечисленные в RFC 2132[13] и реестр IANA.[12]

RFC 1497 (BOOTP Vendor Information Extensions) расширения поставщиков[13]:Раздел 3
КодИмяДлинаПримечания
0Pad[13]:Раздел 3.10 октетыМожет использоваться для дополнения других параметров, чтобы они были выровнены по границе слова; не следует за байтом длины
1Маска подсети[13]:Раздел 3.34 октетаДолжен быть отправлен перед вариантом маршрутизатора (вариант 3), если оба включены
2Смещение времени[13]:Раздел 3.44 октета
3МаршрутизаторКратное по 4 октетаДоступные маршрутизаторы должны быть перечислены в порядке предпочтения.
4Сервер времениКратное по 4 октетаДоступные серверы времени для синхронизации должны быть перечислены в порядке предпочтения.
5Сервер именКратное по 4 октетаИмеется в наличии IEN 116 DNS-серверы должны быть перечислены в порядке предпочтения
6Сервер доменного имениКратное по 4 октетаИмеется в наличии DNS серверы должны быть перечислены в порядке предпочтения
7Сервер журналаКратное по 4 октетаДоступные серверы журналов должны быть перечислены в порядке предпочтения.
8Сервер cookieКратное по 4 октетаCookie-файлы в данном случае означает «печенье с предсказанием» или «цитата дня», содержательный или юмористический анекдот, часто отправляемый как часть процесса входа в систему на больших компьютерах; это не имеет ничего общего с файлы cookie, отправленные веб-сайтами.
9LPR серверКратное по 4 октета
10Сервер ImpressКратное по 4 октета
11Сервер расположения ресурсовКратное по 4 октета
12Имя хостаМинимум 1 октет
13Размер загрузочного файла2 октетаДлина загрузочного образа в блоках по 4 КиБ
14Цена файл дампаМинимум 1 октетПуть, по которому должны храниться аварийные дампы
15Доменное имяМинимум 1 октет
16Сервер подкачки4 октета
17Корневой путьМинимум 1 октет
18Путь расширенийМинимум 1 октет
255Конец0 октетовИспользуется для обозначения конца поля опций поставщика
Параметры уровня IP на хост[13]:Раздел 4
КодИмяДлинаПримечания
19Включение / отключение переадресации IP1 октет
20Включение / отключение нелокальной маршрутизации от источника1 октет
21Фильтр политикиКратное 8 октетов
22Максимальный размер повторной сборки дейтаграммы2 октета
23Время жизни IP по умолчанию1 октет
24Таймаут устаревания MTU пути4 октета
25Таблица плато MTU путиКратное по 2 октета
Параметры уровня IP на интерфейс[13]:Раздел 5
КодИмяДлинаПримечания
26Интерфейс MTU2 октета
27Все подсети локальные1 октет
28Адрес трансляции4 октета
29Выполнить обнаружение маски1 октет
30Поставщик масок1 октет
31Выполнить обнаружение маршрутизатора1 октет
32Адрес запроса маршрутизатора4 октета
33Статический маршрутКратное 8 октетовСписок пар назначения / маршрутизатора
Параметры канального уровня для каждого интерфейса[13]:Раздел 6
КодИмяДлинаПримечания
34Вариант инкапсуляции прицепа1 октет
35Тайм-аут кеша ARP4 октета
36Инкапсуляция Ethernet1 октет
Параметры TCP[13]:Раздел 7
КодИмяДлинаПримечания
37TTL по умолчанию TCP1 октет
38Интервал поддержки активности TCP4 октета
39Мусор поддержки активности TCP1 октет
Параметры приложения и услуги[13]:Раздел 8
КодИмяДлинаПримечания
40Сетевая информационная служба доменаМинимум 1 октет
41Сетевые информационные серверыКратное по 4 октета
42Сетевой протокол времени (NTP) серверыКратное по 4 октета
43Информация о производителеМинимум 1 октет
44NetBIOS через сервер имен TCP / IPКратное по 4 октета
45NetBIOS через сервер распространения датаграмм TCP / IPКратное по 4 октета
46NetBIOS через тип узла TCP / IP1 октет
47NetBIOS через TCP / IPМинимум 1 октет
48X Window System сервер шрифтовКратное по 4 октета
49Диспетчер отображения системы X WindowКратное по 4 октета
64Сетевая информационная служба + доменМинимум 1 октет
65Сетевая информационная служба + серверыКратное по 4 октета
68Домашний агент мобильного IPКратное по 4 октета
69Простой протокол передачи почты (SMTP) серверКратное по 4 октета
70Почтовый протокол (POP3) серверКратное по 4 октета
71Протокол передачи сетевых новостей (NNTP) серверКратное по 4 октета
72Дефолт Всемирная паутина (WWW) серверКратное по 4 октета
73Дефолт Протокол пальца серверКратное по 4 октета
74Дефолт Интернет-чат (IRC) серверКратное по 4 октета
75StreetTalk серверКратное по 4 октета
76Сервер StreetTalk Directory Assistance (STDA)Кратное по 4 октета
Расширения DHCP[13]:Раздел 9
КодИмяДлинаПримечания
50Запрошенный IP-адрес4 октета
51Срок аренды IP-адреса4 октета
52Перегрузка опций1 октет
53Тип сообщения DHCP1 октет
54Идентификатор сервера4 октета
55Список запросов параметровМинимум 1 октет
56СообщениеМинимум 1 октет
57Максимальный размер сообщения DHCP2 октета
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, показанном в таблице выше.


Типы сообщений DHCP
КодИмяДлинаRFC
1DHCPDISCOVER1 октетrfc2132[13]:Раздел 9.6
2DHCPOFFER1 октетrfc2132[13]:Раздел 9.6
3DHCPREQUEST1 октетrfc2132[13]:Раздел 9.6
4DHCPDECLINE1 октетrfc2132[13]:Раздел 9.6
5DHCPACK1 октетrfc2132[13]:Раздел 9.6
6DHCPNAK1 октетrfc2132[13]:Раздел 9.6
7DHCPRELEASE1 октетrfc2132[13]:Раздел 9.6
8DHCPINFORM1 октетrfc2132[13]:Раздел 9.6
9DHCPFORCERENEW1 октетrfc3203[14]:Раздел 4
10DHCPLEASEQUERY1 октетrfc4388[15]:Раздел 6.1
11DHCP НЕ НАЗНАЧЕН1 октетrfc4388[15]:Раздел 6.1
12DHCPLEASEUNKNOWN1 октетrfc4388[15]:Раздел 6.1
13DHCPLEASEACTIVE1 октетrfc4388[15]:Раздел 6.1
14DHCPBULKLEASEQUERY1 октетrfc6926[16]:Раздел 6.2.1
15DHCPLEASEQUERYDONE1 октетrfc6926[16]:Раздел 6.2.1
16DHCPACTIVELEASEQUERY1 октетrfc7724[17]:Раздел 5.2.1
17DHCPLEASEQUERYSTATUS1 октетrfc7724[17]:Раздел 5.2.1
18DHCPTLS1 октетrfc7724[17]:Раздел 5.2.1

Идентификация поставщика клиента

Существует возможность идентифицировать поставщика и функциональность DHCP-клиента. Информация - это строка переменной длины символов или октетов, значение которых указано поставщиком DHCP-клиента. Один из методов, с помощью которого DHCP-клиент может сообщить серверу, что он использует определенный тип оборудования или микропрограмм, заключается в установке значения в его запросах DHCP, называемого идентификатором класса поставщика (VCI) (опция 60). Этот метод позволяет DHCP-серверу различать два типа клиентских машин и соответствующим образом обрабатывать запросы от двух типов модемов. Некоторые виды телеприставки также установите VCI (опция 60) для информирования DHCP-сервера о типе оборудования и функциональных возможностях устройства. Значение, установленное для этого параметра, дает серверу 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]
119Поиск доменаПеременнаяRFC 3397[21]
121Бесклассовый статический маршрутПеременнаяRFC 3442[22]

Дополнительные параметры информации агента ретрансляции

Опция информации агента ретрансляции (опция 82)[18] определяет контейнер для присоединения подпараметров к запросам DHCP, передаваемым между ретранслятором DHCP и сервером DHCP.

Дополнительные параметры агента ретрансляции
КодИмяДлинаRFC
4Спецификации интерфейса службы передачи данных по кабелю (DOCSIS), класс устройства4 октетаRFC 3256[23]

Реле

В небольших сетях, где управляется только одна 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-клиента на основе рисунка 5 RFC 2131.

Как описано в 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 были представлены Инженерной группе Интернета, но так и не были официально оформлены.[24][c]

Если повторная привязка не удалась, срок аренды в конечном итоге истечет. По истечении срока аренды клиент должен прекратить использовать IP-адрес, предоставленный ему в его аренде.[10]:Раздел 4.4.5 Пункт 9 В это время он перезапустит процесс DHCP с самого начала, передавая DHCPDISCOVER сообщение. Поскольку срок его аренды истек, он примет любой предложенный IP-адрес. Как только он получит новый IP-адрес (предположительно от другого DHCP-сервера), он снова сможет использовать сеть. Однако, поскольку его IP-адрес изменился, все текущие соединения будут прерваны.

Современное приложение

По состоянию на 2018 год DHCP по-прежнему широко используется для автоматического назначения IP-адресов.[25] Новые итерации для назначения IP-адресов включают DHCPv6 и SLAAC.[25]

Безопасность

Смотрите также: Отслеживание DHCP

Базовый DHCP не включает никаких механизмов аутентификации.[26] Из-за этого он уязвим для множества атак. Эти атаки делятся на три основные категории:

  • Неавторизованные DHCP-серверы предоставляют клиентам ложную информацию.[27]
  • Неавторизованные клиенты получают доступ к ресурсам.[27]
  • Атаки исчерпания ресурсов от вредоносных DHCP-клиентов.[27]

Поскольку у клиента нет возможности проверить подлинность DHCP-сервера, неавторизованные DHCP-серверы (обычно называемые "мошеннический DHCP ") могут работать в сетях, предоставляя клиентам DHCP неверную информацию.[28] Это может служить либо атакой типа «отказ в обслуживании», не позволяющей клиенту получить доступ к сетевому подключению, либо[29] или как атака "человек посередине".[30] Поскольку DHCP-сервер предоставляет DHCP-клиенту IP-адреса сервера, такие как IP-адрес одного или нескольких DNS-серверов,[27] злоумышленник может убедить DHCP-клиента выполнить поиск в DNS через свой собственный DNS-сервер и, следовательно, может предоставить свои собственные ответы на запросы DNS от клиента.[31][32] Это, в свою очередь, позволяет злоумышленнику перенаправлять сетевой трафик через себя, позволяя ему подслушивать соединения между клиентом и сетевыми серверами, с которыми он контактирует, или просто заменять эти сетевые серверы своими собственными.[31]

Поскольку DHCP-сервер не имеет безопасного механизма для аутентификации клиента, клиенты могут получить несанкционированный доступ к IP-адресам, предоставив учетные данные, такие как идентификаторы клиента, которые принадлежат другим клиентам DHCP.[28] Это также позволяет клиентам DHCP исчерпать хранилище IP-адресов DHCP-сервера - представляя новые учетные данные каждый раз, когда он запрашивает адрес, клиент может использовать все доступные IP-адреса на конкретном сетевом канале, не позволяя другим клиентам DHCP получать обслуживание.[28]

DHCP действительно предоставляет некоторые механизмы для смягчения этих проблем. В Опция информации агента ретрансляции расширение протокола (RFC 3046, обычно обозначаемый в отрасли по его фактическому номеру как Вариант 82[33][34]) позволяет операторам сети прикреплять теги к сообщениям DHCP, когда эти сообщения поступают в доверенную сеть оператора сети. Затем этот тег используется в качестве токена авторизации для управления доступом клиента к сетевым ресурсам. Поскольку у клиента нет доступа к сети выше агента ретрансляции, отсутствие аутентификации не мешает оператору DHCP-сервера полагаться на токен авторизации.[26]

Другое расширение, аутентификация для сообщений DHCP (RFC 3118 ), обеспечивает механизм аутентификации сообщений DHCP. По состоянию на 2002 год RFC 3118 не получил широкого распространения из-за проблем с управлением ключами для большого количества клиентов DHCP.[35] В книге 2007 года о технологиях DSL отмечалось, что:

было обнаружено множество уязвимостей безопасности в отношении мер безопасности, предложенных RFC 3118. Этот факт в сочетании с введением 802.1x, замедлило развертывание и скорость использования аутентифицированного DHCP, и он никогда не получил широкого распространения.[36]

В книге 2010 года отмечается, что:

[t] здесь было очень мало реализаций аутентификации DHCP. Проблемы, связанные с управлением ключами и задержками обработки из-за вычисления хэша, были сочтены слишком высокой ценой, чтобы платить за предполагаемые преимущества.[37]

Архитектурные предложения от 2008 года включают аутентификацию запросов DHCP с использованием 802.1x или же ПАНА (оба транспорта EAP ).[38] Было сделано предложение IETF о включении EAP в сам DHCP, так называемый EAPoDHCP;[39] это, похоже, не продвинулось дальше уровня проекта IETF, последний из которых датируется 2010 годом.[40]

Документы стандартов IETF

  • RFC 2131, Протокол динамического конфигурирования сервера
  • RFC 2132, Параметры DHCP и расширения поставщика BOOTP
  • RFC 3046, Опция информации агента ретрансляции DHCP
  • RFC 3397, Параметр поиска домена по протоколу динамической конфигурации хоста (DHCP)
  • RFC 3942, Реклассификация параметров протокола динамической конфигурации хоста версии четыре (DHCPv4)
  • RFC 4242, Параметр времени обновления информации для протокола динамической конфигурации хоста для IPv6
  • RFC 4361, Специфические для узла идентификаторы клиентов для протокола динамической конфигурации хоста версии четыре (DHCPv4)
  • RFC 4436, Обнаружение сетевого подключения в IPv4 (DNAv4)
  • RFC 3442, Опция бесклассового статического маршрута для протокола динамической конфигурации хоста (DHCP) версии 4
  • RFC 3203, Расширение перенастройки DHCP
  • RFC 4388, Запрос аренды протокола динамической конфигурации хоста (DHCP)
  • RFC 6926, DHCPv4 Bulk Leasequery
  • RFC 7724, Активный запрос аренды DHCPv4

Смотрите также

Примечания

  1. ^ а б В качестве необязательного поведения клиента некоторые широковещательные рассылки, например, те, которые передают сообщения об обнаружении и запросе DHCP, могут быть заменены одноадресными, если клиент DHCP уже знает IP-адрес DHCP-сервера.[9]
  2. ^ RFC требует от клиента подождать половину оставшегося времени до T2, прежде чем он повторно отправит DHCPREQUEST пакет
  3. ^ Предложение предусматривало механизм, посредством которого два сервера могли оставаться синхронизированными друг с другом, таким образом, что даже в случае полного отказа одного сервера другой сервер мог восстановить базу данных аренды и продолжить работу. Из-за длины и сложности спецификации она никогда не публиковалась в качестве стандарта; однако методы, описанные в предложении, широко используются с открытым исходным кодом и несколькими коммерческими реализациями.

Рекомендации

  1. ^ а б Сеть TechTarget: DHCP (протокол динамической конфигурации хоста)
  2. ^ Петерсон, Ларри Л .; Дэви, Брюс С. (2011). Компьютерные сети: системный подход (5-е изд.). Эльзевир. ISBN  978-0123850607. Получено Двадцать первое марта, 2019.
  3. ^ Билл Крофт; Джон Гилмор (сентябрь 1985 г.). «RFC 951 - протокол начальной загрузки». Сетевая рабочая группа.
  4. ^ Сеть + Сертификация 2006, опубликованная Microsoft Press.
  5. ^ используется для протокола автообнаружения веб-прокси Протокол автообнаружения веб-прокси (WPAD)
  6. ^ RFC 4361, RFC 5494, RFC 6221, RFC 6422, RFC 6644, RFC 7083, RFC 7227, RFC 7283
  7. ^ Дромс, Ральф; Лимон, Тед (2003). Справочник DHCP. Издательство SAMS. п. 436. ISBN  978-0-672-32327-0.
  8. ^ а б Дромс, Ральф. "Протокол динамического конфигурирования сервера". tools.ietf.org. Получено 4 июля 2017.
  9. ^ Дромс, Ральф. "Протокол динамического конфигурирования сервера". tools.ietf.org. Получено 4 июля 2017.
  10. ^ а б c d е ж грамм Дромс, Ральф (март 1997). Параметры DHCP и расширения поставщика BOOTP. IETF. Дои:10.17487 / RFC2131. RFC 2131. Получено 9 сентября, 2014.
  11. ^ «RFC2131 Протокол динамической конфигурации хоста: динамическое распределение сетевых адресов». tools.ietf.org.
  12. ^ а б «Параметры протокола динамической конфигурации хоста (DHCP) и протокола начальной загрузки (BOOTP)». iana.org. Получено 2018-10-16.
  13. ^ а б c d е ж грамм час я j k л м п о п q р s Александр, Стив; Дромс, Ральф (март 1997). Параметры DHCP и расширения поставщиков BOOTP. IETF. Дои:10.17487 / RFC2132. RFC 2132. Получено 10 июня, 2012.
  14. ^ а б {Тьоенс, Ив; Де Шрайвер, Питер (декабрь 2001 г.). Расширение перенастройки DHCP. IETF. Дои:10.17487 / RFC3203. RFC 3203. Получено 13 ноября, 2020.
  15. ^ а б c d е {Раненый, богатый; Киннер, Ким (февраль 2006 г.). Расширение перенастройки DHCP. IETF. Дои:10.17487 / RFC4388. RFC 4388. Получено 13 ноября, 2020.
  16. ^ а б c {Киннер, Ким; Стэпп, Марк; Рао, Д.Т.В. Рамакришна; Джоши, Бхарат; Рассел, Нил; Курапати, Паван; Волц, Берни (апрель 2013 г.). Расширение перенастройки DHCP. IETF. Дои:10.17487 / RFC6926. RFC 6926. Получено 13 ноября, 2020.
  17. ^ а б c d {Киннер, Ким; Стэпп, Марк; Волц, Берни; Рассел, Нил (декабрь 2015 г.). Расширение перенастройки DHCP. IETF. Дои:10.17487 / RFC7724. RFC 7724. Получено 13 ноября, 2020.
  18. ^ а б Патрик, Майкл (январь 2001 г.). «Опция информации агента ретрансляции DHCP». Документы IETF. IETF. Дои:10.17487 / RFC3046. Получено 22 июля 2017.
  19. ^ а б c Прован, Дон (ноябрь 1997 г.). «RFC 2241 - Опции DHCP для служб каталогов Novell». Документы IETF. IETF. Дои:10.17487 / RFC3256. Получено 23 июля 2017.
  20. ^ а б Лир, Э .; Эггерт, П. (апрель 2007 г.). «Параметры часового пояса для DHCP». Документы IETF. IETF. Получено 28 июн 2018.
  21. ^ Бернар, Абоба; Стюарт, Чешир (ноябрь 2002 г.). «RFC 3397 - опция поиска домена по протоколу динамической конфигурации хоста (DHCP)». Документы IETF. IETF. Дои:10.17487 / RFC3397. Получено 22 июля 2017.
  22. ^ RFC 3442
  23. ^ Дуг, Джонс; Rich, Woundy (апрель 2002 г.). «RFC 3256 - DOCSIS (спецификации интерфейса службы передачи данных по кабелю) Класс устройства DHCP (протокол динамической конфигурации хоста) Подопция информации агента ретрансляции». Документы IETF. IETF. Дои:10.17487 / RFC3256. Получено 23 июля 2017.
  24. ^ Дромс, Ральф; Киннер, Ким; Стэпп, Марк; Волц, Берни; Гонци, Стив; Рабил, Грег; Дули, Майкл; Капур, Арун (март 2003 г.). Протокол аварийного переключения DHCP. IETF. I-D draft-ietf-dhc-failover-12. Получено 9 мая, 2010.
  25. ^ а б Вайнберг, Нил (14 августа 2018 г.). «Почему дни DHCP могут быть сочтены». Сетевой мир. Получено 2019-08-07.
  26. ^ а б Патрик, Майкл (январь 2001 г.). «RFC 3046 - Опция информации агента ретрансляции DHCP». Сетевая рабочая группа.
  27. ^ а б c d Дромс, Ральф (март 1997). «RFC 2131 - Протокол динамической конфигурации хоста». Сетевая рабочая группа.
  28. ^ а б c Стапко, Тимати (2011). Практическая встроенная безопасность: построение безопасных систем с ограниченными ресурсами. Newnes. п. 39. ISBN  978-0-08-055131-9.
  29. ^ Раунтри, Деррик (2013). Сетевая безопасность Windows 2012 Server: защита сетевых систем и инфраструктуры Windows. Newnes. п. 22. ISBN  978-1-59749-965-1.
  30. ^ Руни, Тимоти (2010). Введение в управление IP-адресами. Джон Вили и сыновья. п. 180. ISBN  978-1-118-07380-3.
  31. ^ а б Голованов (Лаборатория Касперского), Сергей (июнь 2011 г.). "Загрузчик TDSS получил" ноги"".
  32. ^ Санни, Акаш К. (октябрь 2015 г.). «Протокол DHCP и его уязвимости».
  33. ^ Hens, Francisco J .; Кабальеро, Хосе М. (2008). Triple Play: построение конвергентной сети для IP, VoIP и IPTV. Джон Вили и сыновья. п. 239. ISBN  978-0-470-75439-9.
  34. ^ Рамирес, Дэвид Х. (2008). Безопасность IPTV: защита ценного цифрового контента. Джон Вили и сыновья. п. 55. ISBN  978-0-470-72719-5.
  35. ^ Лимон, Тед (апрель 2002 г.). «Реализация RFC 3118».
  36. ^ Голден, Филипп; Дедье, Эрве; Якобсен, Криста С. (2007). Внедрение и применение технологии DSL. Тейлор и Фрэнсис. п. 484. ISBN  978-1-4200-1307-8.
  37. ^ Руни, Тимоти (2010). Введение в управление IP-адресами. Джон Вили и сыновья. С. 181–182. ISBN  978-1-118-07380-3.
  38. ^ Коупленд, Ребекка (2008). Конвергенция проводных сетей NGN и мобильных сетей 3G с помощью IMS. Тейлор и Фрэнсис. С. 142–143. ISBN  978-1-4200-1378-8.
  39. ^ Прасад, Рамджи; Миховская, Албена (2009). Новые горизонты мобильной и беспроводной связи: сети, услуги и приложения. 2. Артек Хаус. п. 339. ISBN  978-1-60783-970-5.
  40. ^ «Архивная копия». Архивировано из оригинал на 2015-04-03. Получено 2013-12-12.CS1 maint: заархивированная копия как заголовок (связь)

внешняя ссылка