✖


Jump to content

Протокол динамической конфигурации хоста

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

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

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

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

Службы DHCP существуют для сетей, использующих Интернет-протокол версии 4 (IPv4), а также версии 6 ( IPv6 ). Версия протокола DHCP IPv6 обычно называется DHCPv6 .

История

[ редактировать ]

Протокол обратного разрешения адресов (RARP) был определен в 1984 году для настройки простых устройств, таких как бездисковые рабочие станции , с подходящим IP-адресом. [3] Действуя на уровне канала передачи данных , он затруднял реализацию на многих серверных платформах. Требовалось, чтобы сервер присутствовал на каждом отдельном сетевом канале. На смену RARP пришел протокол Bootstrap (BOOTP), определенный в сентябре 1985 года. [4] Это привело к появлению концепции агента ретрансляции, который позволил пересылать пакеты BOOTP по сетям, позволяя одному центральному серверу BOOTP обслуживать хосты во многих IP-подсетях.

DHCP был впервые определен в октябре 1993 года. [5] [6] Он основан на BOOTP, но может динамически выделять IP-адреса из пула и возвращать их, когда они больше не используются. Его также можно использовать для доставки широкого спектра дополнительных параметров конфигурации IP-клиентам, включая параметры, специфичные для платформы. [7]

Четыре года спустя были добавлены тип сообщения DHCPINFORM (используемый для WPAD ) и другие небольшие изменения. Это определение, начиная с 1997 г., [8] остается ядром стандарта сетей IPv4.

DHCPv6 был первоначально определен в 2003 году. [9] После обновлений многих последующих RFC его определение было заменено в 2018 году. [10] где делегирование префиксов и автоконфигурация адресов без сохранения состояния теперь были объединены.

Обзор

[ редактировать ]

Интернет-протокол (IP) определяет, как устройства взаимодействуют внутри и между локальными сетями в Интернете. DHCP-сервер может управлять настройками IP для устройств в своей локальной сети, например, автоматически и динамически назначая IP-адреса этим устройствам. [11]

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

В больших сетях, состоящих из нескольких каналов, один DHCP-сервер может обслуживать всю сеть при помощи агентов ретрансляции DHCP, расположенных на соединяющихся маршрутизаторах. Такие агенты ретранслируют сообщения между DHCP-клиентами и DHCP-серверами, расположенными в разных подсетях.

В зависимости от реализации DHCP-сервер может иметь три метода выделения IP-адресов:

Динамическое размещение
Сетевой администратор резервирует диапазон IP-адресов для DHCP, и каждый DHCP-клиент в локальной сети настроен на запрос IP-адреса от DHCP- сервера во время инициализации сети. В процессе запроса и предоставления используется концепция аренды с контролируемым периодом времени, позволяющая DHCP-серверу восстанавливать, а затем перераспределять IP-адреса, которые не обновляются.
Автоматическое распределение
DHCP-сервер постоянно назначает IP-адрес запрашивающему клиенту из диапазона, определенного администратором. Это похоже на динамическое выделение, но DHCP-сервер хранит таблицу прошлых назначений IP-адресов, поэтому он может предпочтительно назначить клиенту тот же IP-адрес, который был у клиента ранее.
Распределение вручную
Этот метод также называется статическим распределением DHCP , выделением фиксированного адреса , резервированием и привязкой MAC/IP-адреса . Администратор сопоставляет уникальный идентификатор ( идентификатор клиента или MAC-адрес ) для каждого клиента с IP-адресом, который предлагается запрашивающему клиенту. DHCP-серверы могут быть настроены на возврат к другим методам в случае неудачи.

Службы DHCP используются для Интернет-протокола версии 4 (IPv4) и IPv6 . Детали протоколов IPv4 и IPv6 различаются настолько, что их можно считать отдельными протоколами. [12] Для работы 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-адрес в DHCPDISCOVER, который сервер может принять во внимание при выборе адреса для предложения.

Например, если для HTYPE установлено значение 1, чтобы указать, что используемой средой является Ethernet , для HLEN установлено значение 6, поскольку длина адреса Ethernet (MAC-адрес) составляет 6 октетов. CHADDR устанавливается на MAC-адрес, используемый клиентом. Некоторые параметры также установлены.

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

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

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

Октет 0 Октет 1 Октет 2 Октет 3
НА HTYPE ХЛЕН Хмель
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 (список запросов параметров):
  • 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 отправителя; пункт назначения = MAC-адрес клиента

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

Октет 0 Октет 1 Октет 2 Октет 3
НА HTYPE ХЛЕН Хмель
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-серверы):
  • 9.7.10.15,
  • 9.7.10.16,
  • 9.7.10.18

Запрос

[ редактировать ]

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

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

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

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

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

Октет 0 Октет 1 Октет 2 Октет 3
НА HTYPE ХЛЕН Хмель
0x01 0x01 0x06 0x00
XID
0x3903F326
СЕКС ФЛАГИ
0x0000 0x0000
CIADDR (IP-адрес клиента)
0x00000000
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-адрес, он должен проверить вновь полученный адрес. [8] : сек. 2.2 (например, с помощью протокола разрешения адресов ARP ), чтобы предотвратить конфликты адресов, вызванные перекрытием пулов адресов DHCP-серверов. Если этот зонд обнаружит другой компьютер, использующий этот адрес, компьютер должен отправить широковещательную рассылку DHCPDECLINE на сервер.

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

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

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

Октет 0 Октет 1 Октет 2 Октет 3
НА HTYPE ХЛЕН Хмель
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)
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 Release .

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

[ редактировать ]

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

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

Параметры

[ редактировать ]

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

В следующих таблицах перечислены доступные параметры DHCP. [14] [13]

Расширения поставщиков RFC 1497 (расширения информации о поставщиках BOOTP) [14] : Раздел 3
Код Имя Длина Примечания
0 Подушка 0 октетов Может использоваться для заполнения других параметров, чтобы они были выровнены по границе слова; не следует байт длины
1 Маска подсети 4 октета Маска подсети клиента согласно RFC 950 . Если включены и маска подсети, и опция маршрутизатора (вариант 3), опция маски подсети должна быть первой.
2 Смещение времени 4 октета Смещение подсети клиента в секундах от всемирного координированного времени (UTC). Смещение выражается как 32-битное целое число с дополнением до двух. Положительное смещение указывает на местоположение к востоку от нулевого меридиана, а отрицательное смещение указывает на местоположение к западу от нулевого меридиана.
3 Маршрутизатор Кратные 4 октетов Доступные маршрутизаторы должны быть перечислены в порядке предпочтения.
4 Сервер времени Кратные 4 октетов Доступные серверы протокола времени для синхронизации должны быть перечислены в порядке предпочтения.
5 Сервер имен Кратные 4 октетов Доступные серверы имен IEN 116 должны быть перечислены в порядке предпочтения.
6 Сервер доменных имен Кратные 4 октетов Доступные DNS- серверы должны быть перечислены в порядке предпочтения.
7 Сервер журналов Кратные 4 октетов Доступные серверы журналов должны быть перечислены в порядке предпочтения.
8 Сервер cookie Кратные 4 октетов Файл cookie в данном случае означает «печенье с предсказанием» или «цитату дня», содержательный или юмористический анекдот, который часто отправляется как часть процесса входа в систему на больших компьютерах; это не имеет ничего общего с файлами cookie, отправляемыми веб-сайтами .
9 ЛПР Сервер Кратные 4 октетов Список серверов протокола Line Printer Daemon , доступных клиенту, должен быть указан в порядке предпочтения.
10 Импресс сервер Кратные 4 октетов Список серверов Imagen Impress, доступных клиенту, должен быть указан в порядке предпочтения.
11 Сервер расположения ресурсов Кратные 4 октетов Список серверов Resource Location Protocol , доступных клиенту, должен быть указан в порядке предпочтения.
12 Имя хоста Минимум 1 октет Имя клиента. Имя может быть дополнено именем локального домена.
13 Размер загрузочного файла 2 октета Длина загрузочного образа в блоках по 512Б.
14 заслуг Файл дампа Минимум 1 октет Путь, по которому должны храниться аварийные дампы
15 Доменное имя Минимум 1 октет
16 Обмен-сервер 4 октета
17 Корневой путь Минимум 1 октет
18 Путь к расширениям Минимум 1 октет
255 Конец 0 октетов Используется для обозначения конца поля выбора поставщика.
Параметры уровня IP для каждого хоста [14] : Раздел 4
Код Имя Длина Примечания
19 IP-переадресация вкл./выкл. 1 октет
20 Включение/выключение маршрутизации нелокального источника 1 октет
21 Фильтр политики Кратные 8 октетов
22 Максимальный размер сборки датаграммы 2 октета
23 Время жизни IP по умолчанию 1 октет
24 Тайм-аут устаревания MTU пути 4 октета
25 Верхняя часть таблицы Path MTU Кратные 2 октетов
Параметры IP-уровня для каждого интерфейса [14] : Раздел 5
Код Имя Длина Примечания
26 Интерфейс ЧЕЛОВЕК 2 октета
27 Все подсети локальные 1 октет
28 Широковещательный адрес 4 октета
29 Выполнить обнаружение маски 1 октет
30 Поставщик масок 1 октет
31 Выполнить обнаружение маршрутизатора 1 октет
32 Адрес запроса маршрутизатора 4 октета
33 Статический маршрут Кратные 8 октетов Список пар пункт назначения/маршрутизатор
Параметры канального уровня для каждого интерфейса [14] : Раздел 6
Код Имя Длина Примечания
34 Вариант инкапсуляции прицепа 1 октет
35 Тайм-аут кэша ARP 4 октета
36 Инкапсуляция Ethernet 1 октет
TCP-параметры [14] : Раздел 7
Код Имя Длина Примечания
37 Срок жизни TCP по умолчанию 1 октет
38 Интервал поддержки активности TCP 4 октета
39 TCP Keepalive мусор 1 октет
Параметры приложения и сервиса [14] : Раздел 8
Код Имя Длина Примечания
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 System Кратные 4 октетов
64 Сетевая информационная служба + домен Минимум 1 октет
65 Серверы сетевой информационной службы+ Кратные 4 октетов
68 Домашний агент мобильного IP Кратные 4 октетов
69 Сервер простого протокола передачи почты (SMTP) Кратные 4 октетов
70 Сервер почтового протокола (POP3) Кратные 4 октетов
71 Сервер протокола передачи сетевых новостей (NNTP) Кратные 4 октетов
72 по умолчанию Сервер Всемирной паутины (WWW) Кратные 4 октетов
73 по умолчанию протокола Finger Сервер Кратные 4 октетов
74 по умолчанию (IRC) Интернет-чата Сервер Кратные 4 октетов
75 StreetTalk Сервер Кратные 4 октетов
76 Сервер StreetTalk Directory Assistance (STDA) Кратные 4 октетов
Расширения DHCP [14] : Раздел 9
Код Имя Длина Примечания
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, [15] RFC 4388, [16] RFC 6926 [17] и RFC 7724. [18] Эти коды представляют собой значения в расширении DHCP 53, показанном на рисунке.таблицу выше.

Типы сообщений DHCP
Код Имя Длина RFC
1 DHCPОБНАРУЖИТЬ 1 октет rfc2132 [14] : Раздел 9.6
2 DHCPПредложение 1 октет rfc2132 [14] : Раздел 9.6
3 DHCPREQUEST 1 октет rfc2132 [14] : Раздел 9.6
4 DHCPDECLINE 1 октет rfc2132 [14] : Раздел 9.6
5 DHCPACK 1 октет rfc2132 [14] : Раздел 9.6
6 DHCPNAK 1 октет rfc2132 [14] : Раздел 9.6
7 DHCPRELEASE 1 октет rfc2132 [14] : Раздел 9.6
8 DHCPINFORM 1 октет rfc2132 [14] : Раздел 9.6
9 DHCPFORCERENEW 1 октет rfc3203 [15] : Раздел 4
10 DHCPLEASEQUERY 1 октет rfc4388 [16] : Раздел 6.1
11 DHCPLEASEUNASSIGNED 1 октет rfc4388 [16] : Раздел 6.1
12 DHCPLEASEUNKNOWN 1 октет rfc4388 [16] : Раздел 6.1
13 DHCPLEASEACTIVE 1 октет rfc4388 [16] : Раздел 6.1
14 DHCPBULKLEASEQUERY 1 октет rfc6926 [17] : Раздел 6.2.1
15 DHCPLEASEQUERYDONE 1 октет rfc6926 [17] : Раздел 6.2.1
16 DHCPACTIVELEASEQUERY 1 октет rfc7724 [18] : Раздел 5.2.1
17 DHCPLEASEQUERYSTATUS 1 октет rfc7724 [18] : Раздел 5.2.1
18 DHCPTLS 1 октет rfc7724 [18] : Раздел 5.2.1

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

[ редактировать ]

Существует возможность определить производителя и функциональные возможности DHCP-клиента. Информация представляет собой строку символов или октетов переменной длины , значение которой определяется поставщиком DHCP-клиента. Одним из методов, с помощью которого клиент DHCP может сообщить серверу, что он использует определенный тип оборудования или встроенного ПО, является установка в своих запросах DHCP значения, называемого идентификатором класса поставщика (VCI) (опция 60).

Значение, присвоенное этому параметру, дает DHCP-серверу подсказку о любой необходимой дополнительной информации, которая требуется этому клиенту в ответе DHCP. Некоторые типы телеприставок настраивают VCI для информирования DHCP-сервера о типе оборудования и функциях устройства. своем . DHCPDISCOVER сообщении Например, точка беспроводного доступа кампуса Арубы предоставляет значение «ArubaAP» в качестве опции 60 в [19] Затем DHCP-сервер может дополнить свой DHCPOFFER IP-адресом беспроводного контроллера Aruba в опции 43, чтобы точка доступа знала, где зарегистрироваться.

Установка VCI клиентом позволяет DHCP-серверу различать клиентские машины и соответствующим образом обрабатывать запросы от них.

Другие расширения

[ редактировать ]
Документированные параметры DHCP
Код Имя Длина RFC
77 Класс пользователя Минимум 2 октета RFC 3004 [20]
82 Информация об агенте ретрансляции Минимум 2 октета RFC 3046 [21]
85 Серверы службы каталогов Novell (NDS) Минимум 4 октета, кратно 4 октетам РФК 2241 [22] : Раздел 2
86 Имя дерева NDS Переменная РФК 2241 [22] : Раздел 3
87 Контекст НСР Переменная РФК 2241 [22] : Раздел 4
100 Часовой пояс , стиль POSIX Переменная RFC 4833 [23]
101 Часовой пояс , базы данных tz стиль Переменная RFC 4833 [23]
114 DHCP Captive-портал Переменная RFC 8910 [24]
119 Поиск домена Переменная RFC 3397 [25]
121 Бесклассовый статический маршрут Переменная RFC 3442 [26]
209 Файл конфигурации Переменная RFC 5071 [27]
210 Префикс пути Переменная RFC 5071 [27]
211 Время перезагрузки Переменная RFC 5071 [27]

Подпараметры информации об агенте ретрансляции

[ редактировать ]

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

Дополнительные параметры агента ретрансляции
Код Имя Длина RFC
1 Идентификатор канала агента Минимум 1 октет RFC 3046 [21]
2 Удаленный идентификатор агента Минимум 1 октет RFC 3046 [21]
4 Класс устройства Спецификации интерфейса обслуживания данных по кабелю (DOCSIS) 4 октета RFC 3256 [28]

Ретрансляция

[ редактировать ]

В небольших сетях, где управляется только одна IP-подсеть, DHCP-клиенты напрямую взаимодействуют с DHCP-серверами. Однако DHCP-серверы также могут предоставлять IP-адреса для нескольких подсетей. В этом случае DHCP-клиент, который еще не получил IP-адрес, не может напрямую взаимодействовать с DHCP-сервером, находящимся не в той же подсети, поскольку широковещательная рассылка клиента может быть получена только в его собственной подсети.

Чтобы позволить DHCP-клиентам в подсетях, которые не обслуживаются напрямую серверами DHCP, взаимодействовать с серверами DHCP, в этих подсетях можно установить агенты ретрансляции DHCP. Агент ретрансляции DHCP работает на сетевом устройстве и может осуществлять маршрутизацию между подсетью клиента и подсетью DHCP-сервера. Клиент DHCP осуществляет широковещательную передачу по локальному каналу; агент ретрансляции получает широковещательную рассылку и передает ее на один или несколько DHCP-серверов с использованием одноадресной рассылки . IP-адреса DHCP-серверов настраиваются вручную в агенте ретрансляции.Агент ретрансляции сохраняет свой собственный IP-адрес с интерфейса, на котором он получил широковещательную рассылку клиента, в поле GIADDR пакета DHCP.DHCP-сервер использует значение GIADDR для определения подсети, а затем и соответствующего пула адресов, из которого можно выделить IP-адрес.Когда DHCP-сервер отвечает клиенту, он отправляет ответ на адрес GIADDR, опять же используя одноадресную рассылку.Затем агент ретрансляции повторно передает ответ по локальной сети, используя одноадресную рассылку (в большинстве случаев) на вновь зарезервированный IP-адрес, в Кадр Ethernet, направленный на MAC-адрес клиента.Клиент должен принять пакет как свой собственный, даже если этот IP-адрес еще не установлен на интерфейсе. [8] : 25  Непосредственно после обработки пакета клиент устанавливает IP-адрес на своем интерфейсе и сразу после этого готов к обычной IP-связи.

Если реализация стека IP клиента не принимает одноадресные пакеты, когда у него еще нет IP-адреса, клиент может установить бит широковещания в поле FLAGS при отправке пакета DHCPDISCOVER.Агент ретрансляции будет использовать широковещательный IP-адрес 255.255.255.255 (и MAC-адрес клиента) для информирования клиента о DHCPOFFER сервера.

Для связи между агентом ретрансляции и DHCP-сервером обычно используется UDP-порт источника и назначения 67.

Клиентские состояния

[ редактировать ]
Упрощенная диаграмма изменения состояния DHCP-клиента, основанная на рисунке 5 RFC 2131.

Клиент DHCP может получать эти сообщения от сервера: [8] : Раздел 4.4

  • DHCPПредложение
  • DHCPACK
  • DHCPNAK

Клиент перемещается по состояниям DHCP в зависимости от того, как сервер реагирует на сообщения, которые отправляет клиент.

Надежность

[ редактировать ]

DHCP обеспечивает надежность несколькими способами: периодическое обновление, перепривязка, [8] : Раздел 4.4.5 и аварийное переключение. DHCP-клиентам предоставляются аренды на определенный период времени. Клиенты начинают пытаться продлить аренду после истечения половины срока аренды. [8] : Раздел 4.4.5 Параграф 3 Они делают это, отправляя одноадресное сообщение DHCPREQUEST на DHCP-сервер, который предоставил первоначальную аренду. Если этот сервер не работает или недоступен, он не сможет ответить на DHCPREQUEST . Однако в этом случае клиент повторяет DHCPREQUEST . время от времени [8] : Раздел 4.4.5 Параграф 8 [б] поэтому, если DHCP-сервер снова заработает или станет доступным, DHCP-клиент сможет связаться с ним и продлить аренду.

Если DHCP-сервер недоступен в течение длительного периода времени, [8] : Раздел 4.4.5 Параграф 5 DHCP-клиент попытается перепривязаться, передавая DHCPREQUEST, а не одноадресно. Поскольку оно широковещательное , сообщение DHCPREQUEST достигнет всех доступных DHCP-серверов. Если какой-либо другой DHCP-сервер сможет продлить аренду, он сделает это в данный момент.

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

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

Сети IPv6

[ редактировать ]

Базовая методология DHCP была разработана для сетей на базе Интернет-протокола версии 4 (IPv4). С момента разработки и развертывания сетей IPv6 DHCP также использовался для назначения параметров в таких сетях, несмотря на присущие IPv6 возможности автоконфигурации адресов без сохранения состояния . Версия протокола IPv6 обозначается как DHCPv6 . [30]

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

[ редактировать ]
См. также: отслеживание DHCP

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

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

Поскольку у клиента нет возможности проверить личность DHCP-сервера, в сетях могут работать неавторизованные DHCP-серверы (обычно называемые « мошенническими DHCP »), предоставляющие DHCP-клиентам неверную информацию. [32] Это может служить либо атакой типа «отказ в обслуживании», не позволяющей клиенту получить доступ к сетевому подключению, либо [33] или как атака «человек посередине» . [34] Поскольку DHCP-сервер предоставляет DHCP-клиенту IP-адреса серверов, например IP-адрес одного или нескольких DNS-серверов, [8] : сек. 7 Злоумышленник может убедить DHCP-клиента выполнить поиск DNS через собственный DNS-сервер и, следовательно, предоставить собственные ответы на DNS-запросы от клиента. [35] Это, в свою очередь, позволяет злоумышленнику перенаправлять сетевой трафик через себя, позволяя ему подслушивать соединения между клиентом и сетевыми серверами, с которыми он контактирует, или просто заменять эти сетевые серверы своими собственными. [35]

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

DHCP предоставляет некоторые механизмы для решения этих проблем. Relay Agent Information Option Расширение протокола [31] (обычно в отрасли обозначается по фактическому номеру как Опция 82). [36] [37] ) позволяет сетевым операторам прикреплять теги к сообщениям DHCP, когда эти сообщения поступают в доверенную сеть оператора сети. Этот тег затем используется в качестве токена авторизации для контроля доступа клиента к сетевым ресурсам. Поскольку клиент не имеет доступа к сети выше агента ретрансляции, отсутствие аутентификации не мешает оператору DHCP-сервера полагаться на токен авторизации. [31] : сек. 7

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

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

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

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

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

Документы стандартов 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
  • RFC 7724 , Запрос аренды активного DHCPv4

См. также

[ редактировать ]

Примечания

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

Ссылки

[ редактировать ]
  1. ^ Гиллис, Александр С. «Что такое DHCP (протокол динамической конфигурации хоста)?» . TechTarget: SearchNetworking . Проверено 19 февраля 2021 г.
  2. ^ Петерсон, Ларри Л.; Дэви, Брюс С. (2011). Компьютерные сети: системный подход (5-е изд.). Эльзевир. ISBN  978-0-12-385060-7 . Проверено 21 марта 2019 г.
  3. ^ Р. Финлейсон; Т. Манн; Дж. Могул; М. Теймер (июнь 1984 г.). Протокол разрешения обратного адреса . Сетевая рабочая группа. дои : 10.17487/RFC0903 . СТД 38. RFC 903 . Интернет-стандарт 38.
  4. ^ Билл Крофт; Джон Гилмор (сентябрь 1985 г.). ПРОТОКОЛ БУТСТРАП (BOOTP) . Сетевая рабочая группа. дои : 10.17487/RFC0951 . РФК 951 . Проект стандарта. Обновлено RFC 1395 , 1497 , 1532 , 1542 и 5494 .
  5. ^ Р. Дромс (октябрь 1993 г.). Протокол динамической конфигурации хоста . Сетевая рабочая группа. дои : 10.17487/RFC1531 . РФК 1531 . Устаревший. Устарело RFC 1541 из-за ошибок в редакционном процессе.
  6. ^ Р. Дромс (октябрь 1993 г.). Протокол динамической конфигурации хоста . Сетевая рабочая группа. дои : 10.17487/RFC1541 . РФК 1541 . Устаревший. Устарело RFC 2131. Obsoletes РФК 1531 .
  7. ^ Сертификация Network+, 2006 г., опубликовано Microsoft Press.
  8. ^ Перейти обратно: а б с д и ж г час я дж к л м н тот Р. Дромс (март 1997 г.). Протокол динамической конфигурации хоста . Сетевая рабочая группа. дои : 10.17487/RFC2131 . РФК 2131 . Проект стандарта. Устаревшие RFC 1541. Updated by RFC 3396 , 4361 , 5494 и 6842 .
  9. ^ Дж. Баунд; Б. Фольц; Т. Лемон; К. Перкинс; М. Карни (июль 2002 г.). Р. Дромс (ред.). Протокол динамической конфигурации хоста для IPv6 (DHCPv6) . Сетевая рабочая группа. дои : 10.17487/RFC3315 . РФК 3315 . Устаревший. Устарело РФК   8415 . Обновлено RFC 4361 , 5494 , 6221 , 6422 , 6644 , 7083 , 7283 , 7227 и 7550 .
  10. ^ Т. Мругальский; М. Сиодельский; Б. Фольц; А. Юрченко; М. Ричардсон; С. Цзян; Т. Лемон; Т. Уинтерс (ноябрь 2018 г.). Протокол динамической конфигурации хоста для IPv6 (DHCPv6) . IETF . дои : 10.17487/RFC8415 . ISSN   2070-1721 . РФК 8415 . Предлагаемый стандарт. Устаревшие RFC 3315 , 3633 , 3736 , 4242 , 7083 , 7283 и 7550 .
  11. ^ «DHCP — протокол динамической конфигурации хоста» .
  12. ^ Дромс, Ральф; Лемон, Тед (2003). Руководство по DHCP . Издательство САМС . п. 436. ИСБН  978-0-672-32327-0 .
  13. ^ Перейти обратно: а б «Параметры протокола динамической конфигурации хоста (DHCP) и протокола начальной загрузки (BOOTP)» . iana.org . Проверено 16 октября 2018 г.
  14. ^ Перейти обратно: а б с д и ж г час я дж к л м н тот п С. Александр; Р. Дромс (март 1997 г.). Опции DHCP и расширения поставщиков BOOTP . Сетевая рабочая группа. дои : 10.17487/RFC2132 . РФК 2132 . Проект стандарта. Устаревшие RFC 1533. Updated by RFC 3442 , 3942 , 4361 , 4833 и 5494 .
  15. ^ Перейти обратно: а б Молодой человек, Ив; Писатель Питер (декабрь 2001 г.). Расширение перенастройки DHCP . IETF . дои : 10.17487/RFC3203 . РФК 3203 . Проверено 13 ноября 2020 г.
  16. ^ Перейти обратно: а б с д и Раненый, Рич; Киннер, Ким (февраль 2006 г.). Протокол динамической конфигурации хоста (DHCP) Leasequery . IETF . дои : 10.17487/RFC4388 . RFC 4388 . Проверено 13 ноября 2020 г.
  17. ^ Перейти обратно: а б с Киннер, Ким; Стапп, Марк; Рао, ДТВ Рамакришна; Джоши, Бхарат; Рассел, Нил; Курапати, Паван; Волц, Берни (апрель 2013 г.). Массовый запрос аренды DHCPv4 . IETF . дои : 10.17487/RFC6926 . РФК 6926 . Проверено 13 ноября 2020 г.
  18. ^ Перейти обратно: а б с д Киннер, Ким; Стапп, Марк; Волц, Берни; Рассел, Нил (декабрь 2015 г.). Активный запрос аренды DHCPv4 . IETF . дои : 10.17487/RFC7724 . РФК 7724 . Проверено 13 ноября 2020 г.
  19. ^ «Опция DHCP Арубы 60» . 7 октября 2020 г.
  20. ^ Стамп, Г.; Дромс, Р.; Парень.; Вьяграпури, Р.; Демирджис, А.; Бесер, Б.; Приват, Дж. (ноябрь 2000 г.). «Опция класса пользователя для DHCP» . Документы IETF . IETF . дои : 10.17487/RFC3004 . Проверено 2 апреля 2024 г.
  21. ^ Перейти обратно: а б с д Патрик, Майкл (январь 2001 г.). «Опция информации агента ретрансляции DHCP» . Документы IETF . IETF . дои : 10.17487/RFC3046 . Проверено 22 июля 2017 г. .
  22. ^ Перейти обратно: а б с Прован, Дон (ноябрь 1997 г.). «RFC 2241 – Параметры DHCP для служб каталогов Novell» . Документы IETF . IETF . дои : 10.17487/RFC3256 . Проверено 23 июля 2017 г.
  23. ^ Перейти обратно: а б Лир, Э.; Эггерт, П. (апрель 2007 г.). «Параметры часового пояса для DHCP» . Документы IETF . IETF . дои : 10.17487/RFC4833 . Проверено 28 июня 2018 г.
  24. ^ Кумари, Уоррен (сентябрь 2020 г.). «RFC 8910 — Идентификация Captive-портала в объявлениях DHCP и маршрутизатора (RA)» . ietf.org . IETF . Проверено 25 марта 2021 г.
  25. ^ Бернар, Абоба; Стюарт, Чешир (ноябрь 2002 г.). «RFC 3397 – Вариант поиска домена протокола динамической конфигурации хоста (DHCP)» . Документы IETF . IETF . дои : 10.17487/RFC3397 . Проверено 22 июля 2017 г. .
  26. ^ Лемон, Т.; Чешир, С.; Волц, Б. (декабрь 2002 г.). Опция бесклассового статического маршрута для протокола динамической конфигурации хоста (DHCP) . версия 4. doi : 10.17487/RFC3442 . РФК 3442 .
  27. ^ Перейти обратно: а б с Хэнкинс, Дэвид (декабрь 2007 г.). «RFC 5071 — параметры протокола динамической конфигурации хоста, используемые PXELINUX» . ietf.org . IETF. дои : 10.17487/RFC5071 . Проверено 25 марта 2021 г.
  28. ^ Дуг, Джонс; Рич, Ранди (апрель 2002 г.). «RFC 3256 - Подопция DOCSIS (спецификации интерфейса службы передачи данных по кабелю) класса устройства DHCP (протокол динамической конфигурации хоста)» . Документы IETF . IETF . дои : 10.17487/RFC3256 . Проверено 23 июля 2017 г.
  29. ^ Дромс, Ральф; Киннер, Ким; Стапп, Марк; Волц, Берни; Гонци, Стив; Рабиль, Грег; Дули, Майкл; Капур, Арун (март 2003 г.). Протокол аварийного переключения DHCP . IETF . Идентификатор Draft-ietf-dhc-failover-12 . Проверено 9 мая 2010 г.
  30. ^ Вайнберг, Нил (14 августа 2018 г.). «Почему дни DHCP могут быть сочтены» . Сетевой мир . Проверено 7 августа 2019 г.
  31. ^ Перейти обратно: а б с М. Патрик (январь 2001 г.). Информационная опция агента ретрансляции DHCP . Сетевая рабочая группа. дои : 10.17487/RFC3046 . РФК 3046 . Предлагаемый стандарт. Обновлено РФК 6607 .
  32. ^ Перейти обратно: а б с Стапко, Тимофей (2011). Практическая встроенная безопасность: построение безопасных систем с ограниченными ресурсами . Ньюнес. п. 39. ИСБН  978-0-08-055131-9 .
  33. ^ Раунтри, Деррик (2013). Сетевая безопасность Windows 2012 Server: защита сетевых систем и инфраструктуры Windows . Ньюнес. п. 22. ISBN  978-1-59749-965-1 .
  34. ^ Руни, Тимоти (2010). Введение в управление IP-адресами . Джон Уайли и сыновья. п. 180. ИСБН  978-1-118-07380-3 .
  35. ^ Перейти обратно: а б Голованов (Лаборатория Касперского), Сергей (июнь 2011 г.). «Теперь у погрузчика ТДСС появились «ноги» » . Архивировано из оригинала 25 января 2021 года.
  36. ^ Хенс, Франциско Дж.; Кабальеро, Хосе М. (2008). Triple Play: построение конвергентной сети для IP, VoIP и IPTV . Джон Уайли и сыновья. п. 239. ИСБН  978-0-470-75439-9 .
  37. ^ Рамирес, Дэвид Х. (2008). Безопасность IPTV: защита ценного цифрового контента . Джон Уайли и сыновья. п. 55. ИСБН  978-0-470-72719-5 .
  38. ^ Р. Дромс; В. Арбо, ред. (июнь 2001 г.). Аутентификация для сообщений DHCP . Сетевая рабочая группа. дои : 10.17487/RFC3118 . РФК 3118 . Предлагаемый стандарт.
  39. ^ Лемон, Тед (апрель 2002 г.). «Реализация RFC 3118» .
  40. ^ Голден, Филип; Дедье, Эрве; Якобсен, Криста С. (2007). Внедрение и применение технологии DSL . Тейлор и Фрэнсис. п. 484. ИСБН  978-1-4200-1307-8 .
  41. ^ Руни, Тимоти (2010). Введение в управление IP-адресами . Джон Уайли и сыновья. стр. 181–182. ISBN  978-1-118-07380-3 .
  42. ^ Коупленд, Ребекка (2008). Конвергенция проводных и мобильных сетей NGN 3G с помощью IMS . Тейлор и Фрэнсис. стр. 142–143. ISBN  978-1-4200-1378-8 .
  43. ^ Прасад, Рамджи; Миховская, Албена (2009). Новые горизонты мобильной и беспроводной связи: сети, услуги и приложения . Том. 2. Артех Хаус. п. 339. ИСБН  978-1-60783-970-5 .
  44. ^ «Draft-pruss-DHCP-auth-DSL-07 — Расширения аутентификации EAP для протокола динамической конфигурации хоста для широкополосной связи» . Архивировано из оригинала 3 апреля 2015 г. Проверено 12 декабря 2013 г.
[ редактировать ]
Retrieved from "https://en.wikipedia.org/w/index.php?title=Dynamic_Host_Configuration_Protocol&oldid=1236794073"
Arc.Ask3.Ru: конец переведенного документа.
Arc.Ask3.Ru
Номер скриншота №: faab3bd0c862ac69968fe83e11fa59b2__1721995860
URL1:https://arc.ask3.ru/arc/aa/fa/b2/faab3bd0c862ac69968fe83e11fa59b2.html
Заголовок, (Title) документа по адресу, URL1:
Dynamic Host Configuration Protocol - Wikipedia
Данный printscreen веб страницы (снимок веб страницы, скриншот веб страницы), визуально-программная копия документа расположенного по адресу URL1 и сохраненная в файл, имеет: квалифицированную, усовершенствованную (подтверждены: метки времени, валидность сертификата), открепленную ЭЦП (приложена к данному файлу), что может быть использовано для подтверждения содержания и факта существования документа в этот момент времени. Права на данный скриншот принадлежат администрации Ask3.ru, использование в качестве доказательства только с письменного разрешения правообладателя скриншота. Администрация Ask3.ru не несет ответственности за информацию размещенную на данном скриншоте. Права на прочие зарегистрированные элементы любого права, изображенные на снимках принадлежат их владельцам. Качество перевода предоставляется как есть. Любые претензии, иски не могут быть предъявлены. Если вы не согласны с любым пунктом перечисленным выше, вы не можете использовать данный сайт и информация размещенную на нем (сайте/странице), немедленно покиньте данный сайт. В случае нарушения любого пункта перечисленного выше, штраф 55! (Пятьдесят пять факториал, Денежную единицу (имеющую самостоятельную стоимость) можете выбрать самостоятельно, выплаичвается товарами в течение 7 дней с момента нарушения.)