stringtranslate.com

Протокол динамического конфигурирования сервера

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

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

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

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

История

Протокол разрешения обратного адреса (RARP) был определен в 1984 году [3] для настройки простых устройств, таких как бездисковые рабочие станции , с подходящим IP-адресом. Действуя на уровне канала передачи данных , он затруднял реализацию на многих серверных платформах. Требовалось, чтобы сервер присутствовал на каждом отдельном сетевом канале. На смену 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-адрес, используемый клиентом. Некоторые параметры также установлены.

Предложение

Когда DHCP-сервер получает от клиента сообщение DHCPDISCOVER, которое представляет собой запрос на аренду IP-адреса, DHCP-сервер резервирует IP-адрес для клиента и делает предложение аренды, отправляя клиенту сообщение DHCPOFFER. Это сообщение содержит идентификатор клиента клиента (традиционно MAC-адрес), IP-адрес, предлагаемый сервером, маску подсети, продолжительность аренды и IP-адрес DHCP-сервера, делающего предложение. DHCP-сервер также может учитывать MAC-адрес аппаратного уровня на нижележащем транспортном уровне: согласно текущим RFC, MAC-адрес транспортного уровня может использоваться, если в пакете DHCP не указан идентификатор клиента.

DHCP-сервер определяет конфигурацию на основе аппаратного адреса клиента, указанного в поле CHADDR (аппаратный адрес клиента). В следующем примере сервер ( 192.168.1.1 ) указывает IP-адрес клиента в поле YIADDR (ваш IP-адрес).

Запрос

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

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

Подтверждение

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

Протокол ожидает, что DHCP-клиент настроит свой сетевой интерфейс с согласованными параметрами.

После того, как клиент получит IP-адрес, он должен проверить вновь полученный адрес [8] : сек. 2.2  (например, с протоколом разрешения адресов ARP ), чтобы предотвратить конфликты адресов, вызванные перекрытием пулов адресов DHCP-серверов. Если этот зонд обнаружит другой компьютер, использующий этот адрес, компьютер должен отправить широковещательную рассылку DHCPDECLINE на сервер.

Информация

Клиент 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]

Типы сообщений DHCP

В этой таблице перечислены типы сообщений DHCP, описанные в RFC 2132, RFC 3203, [15] RFC 4388, [16] RFC 6926 [17] и RFC 7724. [18] Эти коды представляют собой значение в расширении DHCP 53, показанном на рисунке. таблицу выше.

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

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

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

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

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

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

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

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

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

Надежность

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

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

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

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

Сети IPv6

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

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

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

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

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

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

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

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

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

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

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

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

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

Примечания

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

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

  1. ^ Гиллис, Александр С. «Что такое DHCP (протокол динамической конфигурации хоста)?». TechTarget: SearchNetworking . Проверено 19 февраля 2021 г.
  2. ^ Петерсон, Ларри Л.; Дэви, Брюс С. (2011). Компьютерные сети: системный подход (5-е изд.). Эльзевир. ISBN 978-0123850607. Проверено 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. Устарело по RFC 1531.
  7. ^ Сертификация Network+, 2006 г., опубликовано Microsoft Press.
  8. ^ abcdefghijklmno Р. Дромс (март 1997 г.). Протокол динамического конфигурирования сервера. Сетевая рабочая группа. дои : 10.17487/RFC2131 . РФК 2131. Проект стандарта. Устаревший RFC 1541. Обновлен RFC 3396, 4361, 5494 и 6842.
  9. ^ Дж. Связанный; Б. Фольц; Т. Лемон; К. Перкинс; М. Карни (июль 2002 г.). Р. Дромс (ред.). Протокол динамической конфигурации хоста для IPv6 (DHCPv6). Сетевая рабочая группа. дои : 10.17487/RFC3315 . РФК 3315. Устаревший. Устарело RFC  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. ^ ab «Параметры протокола динамической конфигурации хоста (DHCP) и протокола начальной загрузки (BOOTP)» . iana.org . Проверено 16 октября 2018 г.
  14. ^ abcdefghijklmnop С. Александр; Р. Дромс (март 1997 г.). Опции DHCP и расширения поставщиков BOOTP. Сетевая рабочая группа. дои : 10.17487/RFC2132 . РФК 2132. Проект стандарта. Устаревший RFC 1533. Обновлен RFC 3442, 3942, 4361, 4833 и 5494.
  15. ^ аб Т'джоенс, Ив; Де Шрийвер, Питер (декабрь 2001 г.). Расширение перенастройки DHCP. IETF . дои : 10.17487/RFC3203 . РФК 3203 . Проверено 13 ноября 2020 г.
  16. ^ abcde Ранди, Рич; Киннер, Ким (февраль 2006 г.). Запрос аренды протокола динамической конфигурации хоста (DHCP). IETF . дои : 10.17487/RFC4388 . RFC 4388 . Проверено 13 ноября 2020 г.
  17. ^ abc Киннер, Ким; Стапп, Марк; Рао, ДТВ Рамакришна; Джоши, Бхарат; Рассел, Нил; Курапати, Паван; Волц, Берни (апрель 2013 г.). Массовый запрос аренды DHCPv4. IETF . дои : 10.17487/RFC6926 . РФК 6926 . Проверено 13 ноября 2020 г.
  18. ^ abcd Киннер, Ким; Стапп, Марк; Волц, Берни; Рассел, Нил (декабрь 2015 г.). Активный запрос аренды DHCPv4. IETF . дои : 10.17487/RFC7724 . РФК 7724 . Проверено 13 ноября 2020 г.
  19. ^ «Опция 60 DHCP Арубы» . 7 октября 2020 г.
  20. ^ abcd Патрик, Майкл (январь 2001 г.). «Опция информации агента ретрансляции DHCP». Документы IETF . IETF . дои : 10.17487/RFC3046 . Проверено 22 июля 2017 г.
  21. ^ abc Прован, Дон (ноябрь 1997 г.). «RFC 2241 – Параметры DHCP для служб каталогов Novell» . Документы IETF . IETF . дои : 10.17487/RFC3256 . Проверено 23 июля 2017 г.
  22. ^ ab Лир, Э.; Эггерт, П. (апрель 2007 г.). «Параметры часового пояса для DHCP». Документы IETF . IETF . дои : 10.17487/RFC4833 . Проверено 28 июня 2018 г.
  23. ^ Кумари, Уоррен (сентябрь 2020 г.). «RFC 8910 — Идентификация Captive-портала в объявлениях DHCP и маршрутизатора (RA)». ietf.org . IETF . Проверено 25 марта 2021 г.
  24. ^ Бернард, Абоба; Стюарт, Чешир (ноябрь 2002 г.). «RFC 3397 - Вариант поиска домена протокола динамической конфигурации хоста (DHCP)» . Документы IETF . IETF . дои : 10.17487/RFC3397 . Проверено 22 июля 2017 г.
  25. ^ Лемон, Т.; Чешир, С.; Волц, Б. (2002). «РФК 3442» . дои : 10.17487/RFC3442. {{cite journal}}: Требуется цитировать журнал |journal=( помощь )
  26. ^ abc Хэнкинс, Дэвид (декабрь 2007 г.). «RFC 5071 — Параметры протокола динамической конфигурации хоста, используемые PXELINUX». ietf.org . IETF. дои : 10.17487/RFC5071 . Проверено 25 марта 2021 г.
  27. ^ Дуг, Джонс; Рич, Ранди (апрель 2002 г.). «RFC 3256 - Подопция DOCSIS (спецификации интерфейса службы передачи данных по кабелю) класса устройства DHCP (протокол динамической конфигурации хоста)» . Документы IETF . IETF . дои : 10.17487/RFC3256 . Проверено 23 июля 2017 г.
  28. ^ Дромс, Ральф; Киннер, Ким; Стапп, Марк; Волц, Берни; Гонци, Стив; Рабиль, Грег; Дули, Майкл; Капур, Арун (март 2003 г.). Протокол аварийного переключения DHCP. IETF . Идентификатор Draft-ietf-dhc-failover-12 . Проверено 9 мая 2010 г.
  29. ^ Вайнберг, Нил (14 августа 2018 г.). «Почему дни DHCP могут быть сочтены». Сетевой мир . Проверено 7 августа 2019 г.
  30. ^ abc М. Патрик (январь 2001 г.). Информационная опция агента ретрансляции DHCP. Сетевая рабочая группа. дои : 10.17487/RFC3046 . РФК 3046. Предлагаемый стандарт. Обновлено RFC  6607.
  31. ^ abc Стапко, Тимофей (2011). Практическая встроенная безопасность: создание безопасных систем с ограниченными ресурсами. Ньюнес. п. 39. ИСБН 978-0-08-055131-9.
  32. ^ Раунтри, Деррик (2013). Сетевая безопасность Windows 2012 Server: защита сетевых систем и инфраструктуры Windows. Ньюнес. п. 22. ISBN 978-1-59749-965-1.
  33. ^ Руни, Тимоти (2010). Введение в управление IP-адресами. Джон Уайли и сыновья. п. 180. ИСБН 978-1-118-07380-3.
  34. ^ аб Голованов (Лаборатория Касперского), Сергей (июнь 2011 г.). «У погрузчика TDSS появились «ноги»». Архивировано из оригинала 25 января 2021 года.
  35. ^ Куры, Франциско Дж.; Кабальеро, Хосе М. (2008). Triple Play: построение конвергентной сети для IP, VoIP и IPTV. Джон Уайли и сыновья. п. 239. ИСБН 978-0-470-75439-9.
  36. ^ Рамирес, Дэвид Х. (2008). Безопасность IPTV: защита ценного цифрового контента. Джон Уайли и сыновья. п. 55. ИСБН 978-0-470-72719-5.
  37. ^ Р. Дромс; В. Арбо, ред. (июнь 2001 г.). Аутентификация для сообщений DHCP. Сетевая рабочая группа. дои : 10.17487/RFC3118 . РФК 3118. Предлагаемый стандарт.
  38. ^ Лемон, Тед (апрель 2002 г.). «Реализация RFC 3118».
  39. ^ Голден, Филип; Дедье, Эрве; Якобсен, Криста С. (2007). Внедрение и применение технологии DSL. Тейлор и Фрэнсис. п. 484. ИСБН 978-1-4200-1307-8.
  40. ^ Руни, Тимоти (2010). Введение в управление IP-адресами. Джон Уайли и сыновья. стр. 181–182. ISBN 978-1-118-07380-3.
  41. ^ Коупленд, Ребекка (2008). Конвергенция проводных и мобильных сетей NGN с помощью IMS. Тейлор и Фрэнсис. стр. 142–143. ISBN 978-1-4200-1378-8.
  42. ^ Прасад, Рамджи; Миховская, Албена (2009). Новые горизонты мобильной и беспроводной связи: сети, услуги и приложения. Том. 2. Артех Хаус. п. 339. ИСБН 978-1-60783-970-5.
  43. ^ «Draft-pruss-DHCP-auth-DSL-07 — Расширения аутентификации EAP для протокола динамической конфигурации хоста для широкополосной связи» . Архивировано из оригинала 3 апреля 2015 г. Проверено 12 декабря 2013 г.

Внешние ссылки